Борьба с отладчиком

Mario555

Спецвыпуск: Хакер, номер #057, стр. 057-084-1

Основные антиотладочные фишки в user mode

Многим программам, особенно упакованным, не очень нравится, когда их запускают под отладчиком. От них можно ждать чего угодно: могут ограничиться выводом сообщения вроде "Debugger dtected", могут завершиться вместе с отладчиком, а могут и жесткий диск попортить. В этой статье я хочу рассказать, как обычно реализуется обнаружение user mode отладчиков (OllyDbg, к примеру) и как избежать этого обнаружения.

Антиотладка

Использование API-функции IsDebuggerPresent

Пожалуй, древнейший способ обнаружения отладчика. "The IsDebuggerPresent function indicates whether the calling process is running under the context of a debugger". Тут все просто: запускаем, смотрим результат, в зависимости от него делаем какую-нибудь гадость. Такое встречается почти в любом протекторе. Минус этой проверки в том, что поймать ее легче легкого: ставим бряк на функцию, подменяем результат - и все, антиотладка идет лесом. Избежать такого простого обхода проверки можно, если разобраться в том, откуда IsDebuggerPresent берет информацию о наличии отладчика. Лезем дизассемблером в библиотеку и видим ее код:

77E72740 MOV EAX,DWORD PTR FS:[18] ; TEB

77E72746 MOV EAX,DWORD PTR [EAX+30] ; EAX <- адрес PEB из TEB

77E72749 MOVZX EAX,BYTE PTR [EAX+2] ; EAX <- BeingDebugged

77E7274D RETN

PEB содержит информацию о некоторых параметрах процесса. Если посмотреть описание этой структуры, можно заметить, что третий байт в ней - это BeingDebugged, то есть флаг присутствия отладчика. Это значит, что для обнаружения отладчика можно не вызывать API, а просто где угодно в коде проверять значение BeginDebugging. Обход этой штуки напрашивается сам собой: сразу после загрузки в отладчик обнулить флаг BeingDebugged. Какое нападение, такая и защита :).

Поиск окна (или класса окна) отладчика

FindWindow вернет хэндл окна, если оно найдено, либо null, если оно не найдено. С помощью этой замечательной функции можно искать, естественно, не только отладчик, но и любую оконную программу, которой пользуются при взломе (это могут быть, к примеру, мониторы FileMon и RegMon). Такая проверка может осуществляться в отдельном трейде, тогда поиск получится не только до OEP запакованной программы, но и после него, то есть не выйдет даже запустить отладчик одновременно с программой (так, например, прибивают некоторые наиболее распространенные дамперы). Соответственно, обходом этого защитного приема будет подмена результата вызова FindWindow, либо, более удобный вариант - замена имени и класса окна отладчика. Используется поиск окна во многих протекторах: ActiveMark, ACProtect (не путать с ASProtect), SoftDefender и др.

Поиск по имени процесса

Производится с помощью ToolHlp API, функций CreateToolhelp32Snapshot, Process32First и Process32Next, которые перечисляют все доступные процессы и получают для них структуру PROCESSENTRY32, содержащую полезную информацию о процессе. Получив список можно, например, закрыть непонравившийся процесс (скажем, если его имя равно имени процесса какого-нибудь известного отладчика). Еще есть параноидальная проверка у ACProtect: он считает допустимым свой запуск только от explorer.exe и еще пары учтенных программ. Проверка работает элементарно. В структуре PROCESSENTRY32 есть поле DWORD th32ParentProcessID, в котором указан PID процесса-родителя. Если вдруг это поле равно идентификатору неучтенного протектором процесса, то защита просто-напросто убивает своего родителя (печальная история, особенно когда хочешь запустить программу из-под какого-нибудь не очень популярного файлового менеджера).