PEB

пытался из DriverEntry получить kernel32.dll base

Код (Text):

1. mov eax, fs:[30h]
2.  
3. eax <- FFFFFFFF
4.  mov eax, [eax+0Ch]
5.  mov eax, [eax+1Сh]

потом попытался через другие процессы

Код (Text):

1.         pListHead = &pSystemProcess->ActiveProcessLinks;
2.         pNextEntry = pListHead->Flink;
3. while(pNextEntry != pListHead)
4.         {
5.             pSystemProcess = CONTAINING_RECORD(pNextEntry,EPROCESS,ActiveProcessLinks);
6.             if(pSystemProcess->ActiveThreads)
7.             {
8.                 if(!IsListEmpty(&pSystemProcess->ThreadListHead))
9.   {
10. //--------------------------------------------------------------------------
11.                         if (!kernel)
12.                         {
13.                             __asm
14.                             {
15.                                     int 3
16.                                 mov         eax,    pSystemProcess
17.                                 mov     eax,    [eax+01b0h]
18. здесь в eax ptr PEB но дальше получается фигня и bsod
19.                                 mov         eax, [eax + 0Ch]   <-  3
20.                                 mov         esi, [eax + 1Ch] //kernel32.dll

что не так ?

xp sp2

 

Ээээ йопта.... ахинея o_O
Тему эту тут уже поднимали 100500 раз
Заходишь в поиск вбиваешь
PEB
NT.KERNEL

 

+1
Поиск рулит

 

1. __readfsdword в ядре читает из PCR, а не откуда вы думаете.
2. Если вбить в поиск очевидный ответ на вопрос - PsGetProcessPeb - то при ее упоминании не сказано, что эта функция не экспортируется в 2000 винде.

 

Вот, нормальный код

Код (Text):

1. ProcessId = PsGetCurrentProcessId();
2. PsLookupProcessByProcessId(ProcessId,&pEProcess);
3. KeStackAttachProcess(pEProcess,&KapcState);
4. PEB = (PPEB) pEProcess->Peb;
5.   __try {
6.         pListEntry = (PLIST_ENTRY) &PEB->LoaderData->InMemoryOrderModuleList;
7.         for(pListEntryNext = pListEntry->Flink;pListEntryNext != pListEntry;pListEntryNext=pListEntryNext->Flink)
8. {
9.             LdrModule = (PLDR_MODULE) pListEntryNext;
10.             if(_stricmp((PWCHAR) LdrModule->FullDllName.Buffer, L"kernel32.dll") == 0)
11.                 Kernel32Base = (ULONG) LdrModule->BaseAddress;
12. }

 

В ядре FS тычет в Processor Control Region (KPCR)

 

Это не будет компилироваться, нет определения pEProcess (а EPROCESS для каждого билда системы разная).

 

J0E

Да ладно? Уфффф, дык, если ты заметил, там нет и определений PEB, KapcState, LdrModule и много еще чего. Или все-таки не заметил?
Если такой наблюдательный, то почему бы сразу не сообразить, что это здесь приведена простая *вырезка* из кода? У ТС наверняка хватит сообразительности в данном случае найти соответствующие определенному билду и сервиспаку определения указанных в коде структур. А здесь я привел общий вид кода, который поможет ТС решить его проблему.

 

JhanGhuangxi
Отложите колкости в сторону, J0E прав. EPROCESS сильно варьируется от билда к билду, недокументирована и вообще внутренняя структура.
А между тем есть экспортируемая апи - PsGetProcessPeb(). Принимает PEPROCESS, возвращет PPEB. Почему бы не воспользоваться?

 

Ядро не доложно юзать базу данных загрузчика. Вы собираете бсодогенератор или решето. Там может быть что угодно. В ядре инфа извлекается на основе файла/секции связанной с проекцией. Иначе решение плохое.

 

Соглашусь, что ли.

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

 

x64
Способов куча. Что вы прицепились к этому мсдн'у ?
Не способны какойто не описанный там способ(механизм) придумать ?

 

Clerk
позволю себе ответить: как бы так помягче, это не всегда приемлимо. вот

 

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

 

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

 

Уткнулся в другую проблему:

Код (Text):

1. if (!kernel)
2. {
3.     KeStackAttachProcess(pSystemProcess,&KapcState);
4.     pPEB    =   pSystemProcess -> Peb;
5.     pListEntry = (PLIST_ENTRY) &pPEB->LoaderData.InMemoryOrderModuleList;
6.     for(pListEntryNext = pListEntry->Flink; pListEntryNext != pListEntry; pListEntryNext=pListEntryNext->Flink)
7.     {
8.         PLDR_TABLE = pListEntryNext;
9.                 if(_stricmp((PWCHAR) PLDR_TABLE->FullDllName.Buffer, L"kernel32.dll",12) == 0)
10.                     kernel = (ULONG) PLDR_TABLE->DllBase;
11.     }
12.     mGetApiAddr(strWE);
13.     KeUnstackDetachProcess(&KapcState);
14. }//if (!kernel)

PLDR_TABLE->FullDllName.Buffer не всегда присутствует в памяти, прошелся по Mmxxxx в МСДН, ничего подходящего не нашел ( ну наподобие MmIsAddressValid)
подскажите куда копать

 

MmProbeForRead не подойдет?
И еще - цитата: "Независимо от использования Probe, доступ к чужой памяти нужно всегда оборачивать в try/except, ибо с момента последней проверки адреса могли успеть стать невалидными. Probe просто позволяет проверить валидность блока"

 

at0s
если иркл меньше 2, то обращаться к выгруженной памяти можно и она сама подгрузится.
если больше или равен 2 (DISPATCH_LEVEL), то никак нельзя обращаться.
вот и всё
JhanGhuangxi
а смысл ее юзать?

 

Great
Согласен, смысла не особо...

 

Great

Итого проблема всего в одной/двух(IF) проверках ?
Дык это даже пропатчить можно без последствий, ну либо перехваты на багчеки ставить. Это альтернатива KiDebugRoutine. И мониторьте что угодно, без разницы IRQL.