Оригинальный способ получения базы kernel32.dll

Подскажите, пожалуйста, можно ли найти базу образа kernel32.dll в памяти очень тупым, но, по моему, самым надежным методом: сканировать всю память от 00000000h до FFFFFFFFh, при этом установить внутри-поточный обработчик SEH на исключение "access violation". Второй вопрос: в каком диапазоне адресов Windows загружает системные DLL? Третий вопрос: если мы найдём kernel32.dll в памяти, то как можно проверить (кроме "MZ" и "PE"), что это действительно она? Знаю, что в ExportDirectory есть строка с именем DLL (в нашем случае KERNEL32.dll). Опишите также другие способы получения базы образа kernel32.dll, которые не были описаны ранее на сайте Заранее благодарен!

 

>>00000000h до FFFFFFFFh, при этом установить внутри-поточный обработчик SEH на >>исключение "access violation"

А зачем тебе от 00000000h? ищи от 400000h хотябы а еще лучше от FFFFFFFFh в сторону младших адесов.

Еще метод - составить таблицу соответствий:
версия\релиз - EP KERNEL32.dll

 

Спасибо, assorted, за подсказку! Есть у кого-нибудь еще предложения?

 

тогда уж не от FFFFFFFFh а от 7FF0000h

 

А в Windows 98, например, адрес kernel32.dll = BFF70000h. Поэтому думаю, что ты не прав, yuzvir.

 

гы, ты еще Win 3.11 вспомни, кому щяс нужна 98?

 

Чем больше систем будет заражено тем лучше, не так ли, PaCHER?

 

На 98 ты просто убьеш дополнительное время, а оно того не стоит. Возьми лучше вместо 98ой Vistu там вообще адрес кернела (по словам мелкомягких) и других системных библиотек с каждой перезагрузкой распределяется по рандомным разным базам.

 

большинство методов сводится к получению адреса где-то в kernel32, например можно так

Код (Text):

1. xor     eax,eax
2. mov     eax,dword ptr fs:[eax]
3. mov     eax,dword ptr [eax+4]

ну а потом просто искать по страницам сигнатуру MZ

 

yuzvir
Нет большинство сводится к более точному:

Код (Text):

1. ;-------------------------------------------------
2. ; Нахождение через PEB виртуального адреса загруки kernel32.dll
3. ;-------------------------------------------------
4.  
5. macro   KERNEL32_BASE {
6.   mov    eax,[fs:30h]   ; _PEB
7.   mov    eax,[eax+0ch]  ; _PEB_LDR_DATA
8.   mov    esi,[eax+1ch]  ; InInitializationOrderModuleList : _LIST_ENTRY
9.   lodsd                 ; Следующий элемент
10.   mov    eax,[eax+8h]   ; ImageBase - kernel32.dll
11. }

 

EvilsInterrupt
Всегда считал все методы которые сводятся к твоему за один и тотже
Правда то что я написал тоже можно считать за один, просто имхо там больше вариаций

 

Поколупался с предложенным мною способом (см. выше) И Вышла такая штука:

Код (Text):

1. ;===============================================================================
2.     .386
3.     .model flat, stdcall
4.     option casemap :none
5. ;-------------------------------------------------------------------------------
6. .code
7. start:
8.     call    $+5
9.     pop ebx
10.     sub ebx, $-1
11.     call    GetKernel
12.     ret
13. ;-------------------------------------------------------------------------------
14. GetKernel       proc
15. local   Result: dword
16.     pushad
17.     xor eax, eax
18.     mov Result, eax
19.     mov eax, esp
20.     sub eax, 14h
21.     push    eax
22.     push    ebp
23.     lea eax, dword ptr [ebx+SkipPage]
24.     push    eax
25.     lea eax, dword ptr [ebx+SehHandler]
26.     push    eax
27.     assume  fs:nothing
28.     push    fs:[0]
29.     mov fs:[0], esp
30.     mov ecx, 0FFFFh
31.     mov eax, ecx
32.     shl eax, 16
33. NextPage:
34.     cmp word ptr [eax], "ZM"
35.     jz  CheckPE
36. SkipPage:
37.     sub eax, 10000h
38.     loop    NextPage
39.     jmp ExitGetKernel32Base
40. CheckPE:mov edi, dword ptr [eax+3Ch]
41.     add edi, eax
42.     cmp dword ptr [edi], "EP"
43.     jnz SkipPage
44.     mov edi, dword ptr [edi+78h]
45.     add edi, eax
46.     mov edi, dword ptr [edi+0Ch]
47.     add edi, eax
48.     cmp dword ptr [edi], "NREK"
49.     jnz SkipPage
50.     cmp dword ptr [edi+4], "23LE"
51.     jnz SkipPage
52.     mov Result, eax
53. ExitGetKernel32Base:
54.     pop fs:[0]
55.     add esp, 10h
56.     popad
57.     mov eax, Result
58.     ret
59. GetKernel       endp
60. ;-------------------------------------------------------------------------------
61. SehHandler      proc    ExceptionRecord: dword,
62.                 Err: dword,
63.                 Context: dword,
64.                 Param: dword
65.     pushad
66.     mov eax, Err
67.     mov edi, Context
68.     push    dword ptr [eax+08]
69.     pop dword ptr [edi+0B8h]
70.     push    dword ptr [eax+0Ch]
71.     pop dword ptr [edi+0B4h]
72.     push    dword ptr [eax+10h]
73.     pop dword ptr [edi+0C4h]
74.     popad
75.     xor eax, eax
76.     ret
77. SehHandler      endp
78. end start
79. ;===============================================================================

Всё бы хорошо, но ... Если сканировать память начиная с 0FFFF0000h к 00000000h, то Windows XP виснет полностью и наглухо, а Win98 (на виртуальной машине) выдает ошибку об исключении где-то внутри kernel32.dll. А вот если сканировать начиная с 0BFFF0000h, то обе ОСи работают нормально, и в результате работы функции GetKernel в EAX возвращается база образа kernel32.dll. Способ, помоему, грубый и немного тормозливый, но надёжный на все 100%. Есть еще предложения?

P.S. Кстати, предложенные вами способы не подойдут для внедрения в DLL-файлы, т.к. в стеке могут лежать адреса где-то внутри NTDLL.dll (как для SEH так для PEB)!

 

нет, с PEB-ом всё нормально, какие ты адреса имеешь ввиду?

 

не может быть
или это на виртуалке?

 

Если это Native Приложение, то kernel32.dll может быть и не промаплен. Тогда ты никак не найдёшь его в своём процессе даже при всём желании. А если он есть, то просматривай таблицу импорта заражённого exeка. Так можно найти. Естьещё способ. Находишь заголовок. Роверяешь его валидность, идёшь в секцию ресурсов и ищешь там чо нибуть типа этого:

VALUE "CompanyName", "Корпорация Майкрософт"
VALUE "FileDescription", "Библиотека клиента Windows NT BASE API"
VALUE "FileVersion", "5.00.2195.6688"
VALUE "InternalName", "kernel32"
VALUE "LegalCopyright", "(C) Корпорация Майкрософт (Microsoft Corp.), 1981-1999"
VALUE "OriginalFilename", "kernel32"
VALUE "ProductName", "Операционная система Microsoft (R) Windows (R) 2000"
VALUE "ProductVersion", "5.00.2195.6688"

Ну тут сам подумаешь что лучше.

Ну или можешь поискать в нём известные уникальные экспортируемые функции.

 

PE лоадер подгружает указанные в таблице импорта библиотеки в память создаваемого процесса, значит зная таблицу импорта заражаемого файла мы знаем какие библиотеки присутствуют в памяти, мы также знаем адреса функций из этих библиотек (их в таблицу импорта записывает всё тот же PE лоадер), по этим адресам мы и определяем Image Base этих библиотек или я не прав?

 

Гон кернел32 грузиться всегда , даже если в импорте один узер32

 

sl0n
угу, ntdll и kernel32.dll вроде грузятся всегда, поскольку используются загрузчиком..

 

sl0n & Great
А при загрузке системы? Ничего, кроме ntdll.dll промаплено не будет.

 

При загрузке ты наверное имел в виду Native-приложения) Это, конечно, верно для них.