# головоломка от мыщъх'а

TermoSINteZ
Это работало? OrdinalTable просто содержит начиная с 1цы ординалы, 0 там нету ведь.

 

показывай)

 

TermoSINteZ
наверное работает, если не учитывать базу ординалов в упрощённом варианте /код здесь именно/, хотя её учитывать можно было бы, тогда надо было бы вычитать 1. Де жа вю, короче

 

kaspersky
гм я так и написал. что проверяется что похучены через экспорт ZwLoadDriver и CreateFileA. А ты написал что совсем не то. Начал про сохранение xor'a что-то писать :\

 

гыгы я сразу понял, что ксор определяет, в одном ли модуле лежат адреса, но думал, что там скрыт более тайный смысл +)

 

Зачетно. А я в свое время думал как определить похучена CreateFile или нет, пытался какие-то rdts мутить.. Все проще.

 

так что сие значит то?

 

тут хорошо бы диапазон вообще проверять не всяк код в 64К засунешь), а на/при границе пример не сработает.

 

Ну этот ксор же не всегда прокатит. Только хук подмены экспорта спалить.

 

Great
> Ну этот ксор же не всегда прокатит. Только хук подмены экспорта спалить.
это детект конкретного авера. с другими не прокатит.
универсального способа детекта перехвата увы нет.
тем более, под NT можно перехватывать W-функции,
т.к. A все равно - обертки вокруг них.
но любой авер можно задетектить и практически любой
(известный) хук можно снять или послать хучеру команду
на дезактивацию, ес-но для этого нужно знать что у него
за интерфейс там... но вообще-то можно и потрассить...
кстати, тут есть один прикольный момент. ring3 трассер
не может "нырнуть" в ядро (если это ядерный хук),
но может "уронить" кучу аверовский драйверов.
в частности, кал и нод не обрабатывают fault на single step'е.
т.е. мы трассируем до команды, передающий управление
ядру, запоминаем ее адрес, после чего выполняем xor eax,eax/mov eax,[eax]
в обработчике исключений подменяем контекст, устанавливая EIP
на команду передачи управления ядру и усе. вслед на экскепшеном
на mov eax, вылетает пошаговое исключение, только вылетает
оно уже в ядре. на непохученной машине ядро просто вызывает
наш обработчик еще раз, передавая ему адрес функции
KiUserExceptionDispatcher, точнее адрес следующей команды.
а вот кал kav7.0.1.325ch в такой ситуации дает BSOD

 

kaspersky

А под чековым ядром винды kav7.0.1.325ch пробовал кто запустить
Я надеюсь K7 получше будет

 

Great
А не проще сравнить с оригиналом хранящимся на диске ?
например так :

Код (Text):

1.   ExpandEnvironmentStrings(_T("%SYSTEMROOT%\\system32\\kernel32.dll"),kernel_fn,MAX_PATH);
2.   ExpandEnvironmentStrings(_T("%TEMP%\\_check.dll"),_check_fn,MAX_PATH);
3.   CopyFile(kernel_fn,_check_fn,false);
4.   HINSTANCE _check=LoadLibrary(_check_fn);
5.   HINSTANCE _kernel32=LoadLibrary(kernel_fn);
6.   FARPROC p1 = GetProcAddress(_kernel32,"CreateFileA");
7.   FARPROC p2 = GetProcAddress(_check,"CreateFileA");
8.   if (*(DWORD*)(p1) != *(DWORD*)(p2))

 

asmfan

Детект компилера. С enter далеко не каждый начинает.

Перехватчики обычно короткие, в сорцах, скорей всего, будут идти отдельным выровненым объектником, те вероятность попадания на границу очень мала.

 

_basmp_
так наобор - неужели ещё существуют такие которые начинают с enter? или вообще с прологом как таковым.

 

asmfan

Ну так видимо да (например старую длл-ю или объектник ленятся пересобрать, или спец компилер). Те детектится кой-то особый перехватчик имеющий длинную историю. Не исключено, что и атака на него родимого.

 

PROFi
я так не извращался он и не под чековым ни хвоста не работает. кстати, заметил, что если во время когда винда увеличивает файл подкачки, мы открываем какие-то файлы, то имеем BSOD при активном кале или падение его прикладного процесса. правда, при этом не только кал падет, но и куча всего, включая процесс эксплорер от руссиновича. заметил, когда из-за ошибки в программе попытался откомпильнуть файл с полугиговым статическим массивом, ms vc тут же отожрал всю память и начались падения всего и вся. хорошо хоть на тестовой машине

dag
так винда поддерживает хот-патчи, так что такое сравнение не катит, да и перехватчик не обязательно идет с первого байта. то есть в общем случае мы этим ничего не добьемся и ничего не обнаружим. тем паче, если мы юзаем LoadLibrary, которая может быть захучена и хучить все подгружаемые либы автоматом. тогда уж читать побайтово с диска файл и сверять его - надежнее будет, однако, опять-таки это только против тупых перехватичков прикладного уровня.

 

kaspersky
все-таки что было неправильно в моем ответе?

 

n0name
в какой он хоть кодировке? что-то до меня не доходит. ну похорил его по 11h - все равно не читабелен...