прежде чем выдвигаться на топчан, решил замутить что-то такое, чтобы скорее уснуть. короче вот кряк-ми. https://www.openrce.org/repositories/users/nezumi/crackme-qux.zip http://nezumi.org.ru/souriz/temp/crackme-qux.zip (зеркало) взломать несложно, но всем известным мне отладчикам крышу рвет только так. написано на несколько минут, так что ногами не пинать. пускать из консоли. ломать не сложно - просто демонстрация трюка, некоторые защиты используют это более сложным путем.
kaspersky Он не только не отлазивается, но еще и не запускается (ошибка запуска приложения 0xC0000018) Windows Vista Home Premium без SP
Да не очень то понятно что там ломать. Тут использована какаято особенность загрузки файла и расположения его в памяти, думаю. Потому, что Код (Text): format PE console include '%fasminc%\win32ax.inc' section '.code' code readable executable entry $ jmp [baz] section '.idata' import data readable library dll,'dll.dll' import dll,baz,'baz' ничего не даёт.
KeSqueer мне просто было лень делать не через задницу. поэтому под вислой и не работает twgt ломать ничего не надо надо отладить. а отладить ты не сможешь, т.к. отладчик проскакивает Entry Point (которая чиста для прикола выходит за пределы файла и смотрит сразу в dll), но это не важно. как работает отладчик?! сначала загружает файл, ставит в EP точку останова CCh, после чего дает системе вызывать все dllmain. ну вот мы в нашей dll опредлеяем базовый адрес exe через GetModuleHandle, находим EP в памяти, юзаем VirtualProtect, и снимаем точку останова если там такая имеется. такой трюк работает и под вислой и заставляет дебаггер проскакивать точку останова
Фигня это детская, былобы что ломать. Оно ловится как и всегда - Открываю олей, процесс завершается. Ставлю точку останова на нужные функции, любые которые этот код юзает, например LdrLoadDll или ещё куданибудь, а оля их для модуля сохраняет. Запускаю олей ещё раз - о чудо - нас поймали
### quux-crack-me ### https://www.openrce.org/repositories/users/nezumi/quux-crackme.zip quux-crack-me is improved and fixed version of qux-crack-me. try to _debug_ it with your favorite debugger and see what happens. * added: + GDI interface; + Soft-Ice bypassing; * fixed: + XP/Vista incompatible; tested OSes: W2K SP4 -> OK; S2K3 SP1 -> OK; tested debuggers: Olly -> refuses to load the app; Syser -> refuses to load the app; Soft-Ice -> skips the EP, loses control; IDA-Pro -> depends on your hands... Clerk сломать можно все особенно если некоторые трюки демонстрируются в чистом виде.
kaspersky Пишет конечно, и не случайно Вот только не пойму зачем 0 из dllmain возвращать при обнаружении цц - чтобы с току сбить или наоборот подзказать, что копать нужно в сторону dllmain ? PS: Мысль интересная, но обходится в два счета путем поиска EP в стеке и установки хардварного бряка на запись
leo чтобы подсказать, конечно. я даже CRT убил, чтобы было проще дизасмить и до предела упросил код, чтобы выразить саму идею - подмену EP через стек и тогда управление получает совсем не тот код, куда отладчик автоматом впендюрил бряк, чтобы остановится. во всяком случае софт-айс хоть софтверных бряков на EP не ставит, теряет контроль над программой. конечно, все это можно захачить все хакеры знают, что такое dllmain и насколько она может быть коварной. но вот представь, если ты под отладчиком имеешь другое поведение программы... например, под отладчиком она пишет, что зарегистрирована, а без отладчика работать отказывается ес-но это не более как шутка. просто я сейчас коллекционирую всевозможные способы "прорыва" из-под отладчика. актуально для анализа малвари. иной раз бывает на рабочей тачке что-то хочется загрузить в отладчик, чтобы посмотреть что это за бяка такая, а она рррраз... и вырвалась из под его контроля...
kaspersky Ясно Кстати, оказывается в плагине Olly Advanced есть галочка Flexible Breakpoints при которой трюк с обнаружением бряка на EP не проходит PS: И в последней версии PhantOm тоже есть галка remove EP break. Хотя и то и другое просто убирает бряк с EP, а лучше было бы поставить хардварный бряк на доступ, тогда и проверку из dllmain можно было бы сразу обнаружить
Вот вы всё защищаетесь от отладчика... А я вот только что написал прогу с защитой от системы %) Т.е. под отладчиком прога пашет на ура, а при обычном вызове сразу падает =) Ибо на лету [должна по крайней мере, но сама Винда это, увы, предотвращает] переписывает свой код в главной секции. ЗЫ Кстати, этож новый способ обнаружения отладки! Меняем строчку, смотрим - если выполняемся дальше, значит отлаживают =)
kaspersky Неломаемая защита не существует, это нонсенс. Каки трюки ? Всем известно что поток начнёт своё выполнение с KiUserApcDispatcher, а из вызова любого сервиса возврат происходит на KiFastSystemCallRet(ну в SP1 это в разделяемой памяти и не экспортируется). Две эти точки останова ловят обсолютно всё и это обойти невозможно.
Clerk А разве кто-то утверждает обратное ? Или раз две точки останова "ловят абсолютно все", то теперь и коллекционировать "каки трюки" нельзя ?
) какой новый смысл неправильной фразе придали Итого: сколько ещё мест, отрабатывающих перед EP? TLS clbks, Dll инициализация, как насчёт delay/bound import? мож ещё что?
Clerk тебе asmfan за меня ответил понимаешь, в чем дело... вот если бы популярные отладчики ловили эти точки от рождения... да и не нужно им ловить, при создании отладочного процесса перед передачей ему управления отрабатывает NTDLL!DbgBreakPoint, которую ловит отладчик (или игнорирует - это уже его дело , правда, к этому моменту все dll загружены и dllmain выполнены... брякаться на dllmain несистемных библиотек - можно и совсем несложно. но - смысл?! замаскировать проверку ЦЦ можно кучей способов в том числе и таких на которых хардверный бряк не сработает. или сработает но не там хинт - вызов LoadLibrary(.exe) из dllmain, хотя ms и не рекомендует этого делать. стартовый адрес потока я менял через стек и делал это довольно грубо. можно изящнее и чтобы не так заметно. да еще и "разбавлено" посторонним кодом. или взять и слегка модифицировать CRT от dllmain. и усе. IDA распознает его по первым байтам, а кто из нас анализирует стандартный CRT?! в состоянии по умолчанию отладчики паляться quux-crackme в лет. ну а придумать как от них защититься - дык куча способов, реализуемых в рамках debug api и без всяких там KiUserApcDispatcher. вопрос - кто из отладчиков это реально делает?!