hall.dll и KeGetCurrentIrql

Есть следующая задача, необходимо получить адрес функции KeGetCurrentIrql не используя апи.
Были опробованы следующие способы:
1) Через парсинг экспорта хала, база хала получалась через парсинг импорта ntoskrnl.exe т.к. импорт находится в .init этод метод не оправдался.
2) Была попытка рипнуть код функции из хала выше системы w 2003 sp2 код функции mov al,b[FS:0x24] в хп код функции который тоже можна рипнуть, но интересует вариант универсального решения.

Если у кого есть соображения по универсальному нахождения базы hall.dll или по 2ому пункту буду рад выслушать возможные варианты.

 

LDR_DATA_TABLE_ENTRY ?

 

KeGetCurrentIrql экспортируется ведь. Заюзать чтонибудь типа MmGetSystemRoutineAddress(), эта в экспорте ядра есть, или самому реализовать.

 

Всё намного проще.

Код (Text):

1. movzx eax,word ptr fs:[0x24]

 

Или тут какой-то другой тайный смысл, зачем её искать?

 

AntiFreeze
Может таблица для отображения IRQL на вектора прерываний нужна(HalpVectorToIRQL).

 

Может. Для того, чтобы не гадать, надо задачу конкретнее ставить.

 

AntiFreeze
А вам какая разница, задача поставлена чётко - найти экспорт.

 

функа MmGetSystemRoutineAddress вызывается только на пассив левеле а откуда мы узнаем текущий левел если мы еще хал ненашли.

 

кста в для каких версий вин этот способ
movzx eax, b_p [fs:KPCR.Irql]
может заменить вызов
KeGetCurrentIrql

 

doctor_Ice, работает во всех от Win 2000 до 7.

 

doctor_Ice
Вот оно - привязанность к среде и компилятору, иначе такой вопрос возникнуть не может, во первых KPCR/KPRCB содержат много информации, далее и ядерные структуры следующие отсюда(ETHREAD etc). А чтобы найти в памяти модуль либо экспорт в нём вовсе не нужен никакой сторонний функционал. Также незачем текущий IRQL определять обычно, ибо известно где код, откуда он вызывается и на каком IRQL. На крайний случай можно из APIC считать(TPR).

 

я не видел, чтобы изменялся когда-либо массив HalpVectorToIRQL
аналогично я не видел, чтобы менялся маппинг регистров APIC - FFFE0000
Смещение регистра TPR фиксировано и равно 80h
соответственно,

Код (Text):

1. mov eax, [0xFFFE0080]
2. shr eax, 4
3. movzx eax, byte [HalpVectorToIRQL + eax]
4. ret

есть, конечно, хал без апик, но таких машин я никогда не видел. один раз на виртуалке (почему-то) оказался хал без apic.

 

бывает так что код выполняется в случайном месте в р0 и в случайный момент. =)))

 

тоже такое наблюдал и хочу чтобы код работал и на виртуалке тоже.

 

А вот интересно, где-то сделают cli, какой IRQL покажет KeGetCurrentIrql и какой он будет на самом деле?

 

J0E
0xFF

 

Clerk
KeGetCurrentIrql вернет текущий иркл, который был до CLI.
А вот если при выключенных прерываниях происходит ошибка страницы, _KiTrap0E явно проверяет EFL.IF==0 и в этом случае в KeBugCheckEx передает соотв. параметр FF

Код (Text):

1.   KIRQL Irql;
2.  
3.   KeRaiseIrql (DISPATCH_LEVEL, &Irql);
4.  
5.   __asm cli;
6.   KdPrint(("Raised to Dispatch, previous %d, current %d\n", Irql, KeGetCurrentIrql()));
7.   __asm sti;
8.  
9.   KfLowerIrql (Irql);

 

DbgPrint на DISPATCH_LEVEL может вызвать BSOD :-D

 

AntiFreeze
Ой да ладно?

DbgPrint and DbgPrintEx can be called at IRQL<=DIRQL. However, Unicode format codes (%wc and %ws) can be used only at IRQL PASSIVE_LEVEL. Also, because the debugger uses interprocess interrupts (IPIs) to communicate with other processors, calling DbgPrint at IRQL>DIRQL can cause deadlocks.