Восстановить SDT

Вопрос детский, но ответа так и не нашел =(

Итак, анализирую SDT, иду по списку ServiceTable SST, получаю адреса всех функций ядра. Как узнать, какие из них перехвачены? Очевидно, нужно сравнить с эталоном. Но вот где взять оригинальные адреса (те, которые были в ServiceTable до перехвата)? Буду оч признателен за кусок кода.

 

Прочитать ядро с диска

 

поищи по форуму, тема обсуждалась не один раз, и код выкладывался тоже...

 

В догонку: а ядро всегда идет первым в списке модулей, получаемых ZqQuerySystemInformation?

 

да.

 

Ок, спасиба. Такой вопрос: реальные адреса NativeAPI искать в файле ядра на диске или в загруженном модуле?

 

найти в экспорте ядра на диске точку входа, сложить с базой реального ядра в памяти и радоваться жизни

 

Great

А в экспорте - RVA? Кстати, а база ядра всегда постоянна?

 

не помню) надо посмотреть. но, вроде бы rva

 

rva-rva
насчет базы вопрос до сих пор неясный

 

да, rva.

 

можно использовать давно опробованный способ - взять адрес любой функции ядра и листать страницами вниз до MZ-PE заголовка. хотя это както не красиво...

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

 

ИМХО - криво. А если функция перехвачена? Долго листать буду... =)

А базу ядра, при большом желании, получаем из списка модулей. Это при условии, что ядро всегда первым следует...

 

>> Это при условии, что ядро всегда первым следует...
всегда, можешь не парится)

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

 

Код (Text):

1. BOOL GetOriginalSDTs()
2. {    
3.     HMODULE     hKernel;
4.     DWORD       dwKSDT;
5.     DWORD       dwKiServiceTable;
6.     PMODULES    pModules=(PMODULES)&pModules;
7.     DWORD       dwNeededSize,rc;
8.     DWORD       dwKernelBase;
9.     PCHAR       pKernelName;
10.     PDWORD      pService;
11.     PIMAGE_FILE_HEADER    pfh;
12.     PIMAGE_OPTIONAL_HEADER    poh;
13.     PIMAGE_SECTION_HEADER    psh;
14.    
15.     HMODULE hntdll = GetModuleHandle("ntdll.dll");
16.     *(FARPROC *)&_NtQuerySystemInformation = GetProcAddress(hntdll, "ZwQuerySystemInformation");
17.     rc=_NtQuerySystemInformation(SystemModuleInformation,pModules,4,&dwNeededSize);
18.     if (rc==STATUS_INFO_LENGTH_MISMATCH)
19.     {
20.         pModules=(PMODULES)GlobalAlloc(GPTR,dwNeededSize);
21.         rc=_NtQuerySystemInformation(SystemModuleInformation,pModules,dwNeededSize,NULL);
22.     }
23.     else return FALSE;
24.     if (!NT_SUCCESS(rc)) return FALSE;
25.    
26.     dwKernelBase = (DWORD)pModules->smi.Base;
27.     pKernelName = pModules->smi.ModuleNameOffset+pModules->smi.ImageName;
28.    
29.     hKernel = LoadLibraryEx(pKernelName,0,DONT_RESOLVE_DLL_REFERENCES);
30.     if (!hKernel) return FALSE;        
31.  
32.     GlobalFree(pModules);
33.     if (!(dwKSDT = (DWORD)GetProcAddress(hKernel,"KeServiceDescriptorTable"))) return FALSE;
34.  
35.     dwKSDT -= (DWORD)hKernel;    
36.     if (!(dwKiServiceTable = FindKiServiceTable(hKernel,dwKSDT))) return FALSE;
37.  
38.     GetHeaders((PCHAR)hKernel,&pfh,&poh,&psh);
39.     pService = (PDWORD)((DWORD)hKernel + dwKiServiceTable);
40.  
41.     for (pService=(PDWORD)((DWORD)hKernel+dwKiServiceTable);
42.             *pService-poh->ImageBase<poh->SizeOfImage;
43.             pService++,dwServices++)
44.             TABLE[dwServices] = *pService - poh->ImageBase+dwKernelBase;  
45.  
46.     NEWTABLE = (DWORD)(dwKernelBase + dwKSDT);
47.  
48.     FreeLibrary(hKernel);
49.     return TRUE;
50. }

примерно так. далее пускашь цикл по восстановлению SDT.

 

Угу, r3 и восстановление SDT :\
SDTRestore AFAIK юзал PhysicalMemory, однако сейчас его проблематично использовать.

 

<В догонку: а ядро всегда идет первым в списке модулей, получаемых ZqQuerySystemInformation?
>

нет.

Элементарный пример. Простейший. Я могу перехватить данную функцию или список list_entry в ядре и отредактировать. Но видел системы, где модуль ядра на чистой системе не был первым в списке. Учти это.

 

что-то я не понимаю.. KeServiceDescriptorTable в образе - пустой массивчик, он заполняется динамически, а KiServiceTable не экспортируется..
остается толко привязываться к инструкциям, которые заполняют таблицу?

k3internal
а где это такое было, не помнишь?

ps логично, если ядро идет первым, но логично, если идет и последним. вообще привязываться к его порядку в списке правда не стоит, имхо

 

В 2к3 сп1 есть и другой метод, ничуть не хуже

 

ага