кстати, а проверить мы можем что именно загрузилось по первому LOAD_DLL_DEBUG_EVENT ? Я что-то не соображу, а под рукой даже нет справки по API %) на поверку сам OllyDbg не в состоянии отловить момент загрузки ntdll.dll, т.е. при первом LOAD_DLL_DEBUG_EVENT в списке модулей имеем сразу несколько модулей и ни одного не выделено красным
Я для наглядности выводил имена библиотек по event.LoadDll.lpImageName Только это указатель на указатель и нужно сделать два ReadProcessMemory - cначала прочитать dword=указатель на строку, а затем саму строку по этому указателю. Но если нужно просто проверить что это ntdll, то можно по базовому адресу lpBaseOfDll, т.к. по идее он должен быть один и тот же в дебагере и дебажном процессе Хотя не знаю, нужно ли это проверять. Я смотрел переделанным под дельфи MiniDebug'ом bogrus'а и в XP первым делом грузится ntdll, а затем уже на подготовленную почву грузятся kernel32, user32, gdi32 и т.п.
leo Проверил на Olly, метод работает, причем убивает всех зайцев сразу, заодно удалось избавиться от еще одного метода определения дебаггера, в частности OllyDbg
В w2k екзешник и ntdll размаплен уже при CREATE_PROCESS_DEBUG_EVENT, после первого LOAD_DLL_DEBUG_EVENT он "проинициализировался", посмотрел PEB.BeingDebugged и записал в PEB.NtGlobalFlag 0x70 (после второго LOAD_DLL_DEBUG_EVENT загружен kernel32), почему ты говоришь нельзя обнулить PEB.BeingDebugged сразу, или это в плугине нельзя? В минидебуге по CREATE_PROCESS_DEBUG_EVENT без проблем прошло, в олли как я заметил модули красным выделяются и получают имена только после system breakpoint (первый EXCEPTION_BREAKPOINT)
В плагине можно без проблем, вот только процесс потом идет сразу на выход, т.е. нормальная процедура загрузки файла в OllyDbg срывается, но если делать так как предложил leo то все нормально. Вобщем нужно еще немного оттестить на побочные эффекты и дописать плагин, сейчас под рукой исходники только версии 1.2.2
кстати, как обозвать новую опцию? защита от PEB checks tricks или может кто предложит название получше или исправит мой вариант
Asterix Если речь идет об NtGlobalFlag и куче, то ИМХО PEB checks tricks в данном случае неточно отражает суть, т.к. PEB это лишь способ доступа к интересующим параметрам. А сами эти параметры (флаги и маркеры) связаны с debug heap checking - контролем операций с кучей в режиме отладки в NT-системах. Поэтому опцию можно было бы обозвать как-то типа Disable NT heap checking
имхо, если обнуляется один PEB.BeingDebugged (как это раньше и делалось в плугине против IsDebuggerPresent), то так и должно остатся, изменение только в том, что это делается на самом раннем этапе, а хип и остальное просто следствие, смысла нет придумывать новое название, лучше жестче утвердить старое
leo у меня с названиями, особенно на аглицком, всегда проблемы %) была еще мысль назвать пункт по названию протектора в котором это используется, но решил что негоже пиарить чужой прот
bogrus ну вот, ты внес сумятицу должна быть отдельная опция, вдруг будут какие-то подводные камни и в некоторых случаях защиту придется отключать
Asterix Согласен. Оля сделана по уму и предоставляет набор разных возможностей чего-то включить\отключить. Наверное и тут также - плагин может быть один, а галочки две - сброс BeingDebugged и Disable heap checking. Ведь сбросив BeingDebugged "на раннем этапе" его можно и восстановить в любой момент, или наоборот сбрасывть BeingDebugged не отключая heap checking - мало ли что придет в голову проверить, поэтому не стоит ограничивать возможности. Кстати можно еще и опцию простого обнуления \ восстановления HeapFlags добавить
Asterix Там народ чето не реагирует на мой пост о неработоспособности метода в W2K SP4. мож кто тут проверит и поделиться результатами?
bogrus а чего там того аттача - берите мой. метод достаточно ясно и прозрачно описан в первом посте топика.
Broken Sword твой пример говорит Debugger found при запуске без отладчика(XP sp2) =) тот что из первого поста топика на экзетулз вроде работает