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

Mario555

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

Хорошо, что авторы ACProtect все-таки образумились и в последних версиях такую проверку убрали, однако ACPR - не единственный протектор, в котором она была :). Обход - переименовать отладчик, к примеру, OllyDbg.exe в explorer.exe. Правда, тут возникает одна проблемка: плагины будут искать именно OllyDbg.exe, так как там находятся функции, которые они импортируют, поэтому в папке должен остаться OllyDbg.exe, будем переименовывать и запускать его копию.

Поиск сигнатур в памяти процесса

Фактически это модификация предыдущего способа, только хитрее - тут уже переименование exe'шника отладчика не поможет. Так же, как и в предыдущем способе, перечисляются процессы с помощью ToolHlp API, потом каждый открывают с помощью OpenProcess и по некоторым адресам ищут сигнатуры неугодных программ, используя ReadProcessMemory. Чтобы защититься от такого обнаружения, можно либо отлавливать вызовы вышеназванных API и подменять значения, которые они возвращают, либо попробовать убрать из exe'шника сигнатуры, по которым его могут найти. Последнее позволит запускать целевую программу (например дампер или импрек), даже если ее поиск осуществляется в отдельном трейде. Применяется в Execryptor2, ActiveMark.

Проверка присутствия отладчика с использованием SetUnhandledExceptionFilter и CheckRemoteDebuggerPresent

Довольно-таки интересная штука. До детального рассмотрения она казалась мне особенно страшной и труднообходимой.

Из справочника по API: "After calling this function, if an exception occurs in a process that is not being debugged, and the exception makes it to the Win32 unhandled exception filter, that filter will call the exception filter function specified by the lpTopLevelExceptionFilter parameter". Следовательно, API по-разному ведет себя в присутствии отладчика и без него. И, что хуже, это не изменение возвращаемого значения, которое можно было бы легко подменять, а обработка исключения. Если процесс не отлаживают, то на финальном исключении (не обработанном SEH), которое намеренно делает протектор (к примеру деление на ноль), управление переходит на установленный с помощью SetUnhandledExceptionFilter обработчик, после которого программа спокойно продолжает выполнять свои действия. Если же это происходит во время отладки, то управление передастся не на финальный обработчик, а отладчику, и программа падает, так как отладчик не знает, что делать. Посмотрим на код SetUnhandledExceptionFilter:

77E7E5A1 MOV ECX,DWORD PTR [ESP+4]

77E7E5A5 MOV EAX,DWORD PTR [77ED73B4]