Как модифицировать IOPM ?

Я вот, что тут случайно в сети нашел

Manipulating the IOPM (I/O Permission Bitmap)

Changing the IOPM within your Kernel Mode Drivers requires the knowledge of a couple of undocumented calls. These are Ke386IoSetAccessProcess, Ke386SetIoAccessMap and PsLookupProcessByProcessId

Т.е. нужно использовать не документированные процедурd, функции. А что по другому никак нельзя? Я просто с драйверами не сталкивался, но просто интересно стало, как можно было на
писать драйвер если про эти функции нигде в DDK не написано?Или я ошибаюсь?

 

Что никто не знает? 0_O

 

Great, ну хоть ты ответь то.

 

это описано в куче источников.
причём разжевано до невозможности.

 

ajak
Логически подумать никак не получается ?
Если смещение битмапы находится за пределами сегмента TSS, то она не используется, а доступ к портам определят IOPL в регистре флагов. Если битмапа в пределах сегмента, то доступ к порту определяется соответствующим битом в ней. Это голая матчасть в манах описана досконально.
Так как VDM процессов может быть несколько, а битмапа для них только и используется(тоесть для юзермодных VDM процессов), значит смещение битмапы в TSS для этих процессов изменяется. Изменяться смещение может только шедулером, следовательно гдето в инфе связанной с процессом это смещение должно храниться. Всем известно что описатель процесса(непосредственно обьект) это структура EPROCESS. Взглянув на неё сразу находим нужное поле:

Код (Text):

1. typedef struct _KPROCESS {
2.  
3.     //
4.     // The dispatch header and profile listhead are fairly infrequently
5.     // referenced.
6.     //
7.  
8.     DISPATCHER_HEADER Header;
9.     LIST_ENTRY ProfileListHead;
10.  
11.     //
12.     // The following fields are referenced during context switches.
13.     //
14.  
15.     ULONG_PTR DirectoryTableBase[2];
16.  
17. #if defined(_X86_)
18.  
19.     KGDTENTRY LdtDescriptor;
20.     KIDTENTRY Int21Descriptor;
21.     USHORT IopmOffset;
22.     UCHAR Iopl;
23.     BOOLEAN Unused;
24.  
25. #endif

Смещение поля 0x30. Открываем код шедулера и обнаруживаем то, что и предполагалось:

Код (Text):

1. ; Set the IOPM map offset value.
2. ;
3. ; N.B. This may be a redundant load of this value if the process did not
4. ;      change during the context switch. However, always reloading this
5. ;      value saves several instructions under the context swap lock.
6. ;
7.  
8.         mov     ax, [ebp]+PrIopmOffset  ; set IOPM offset
9.         mov     [ecx]+TssIoMapBase, ax  ;

Далее так как у каждого процессора свой TSS, то битмапа должна бать настроена в каждом TSS. Иначе на первом процессоре будет одна битмапа, на другом другая. Так как одновременно потоки одного процесса могут исполняться на разных процессорах, то также как и битмапа, должно быть загружено смещение её в TSS. Загрузка достигается с помощью IPI или DPC. Смотрим реализацию тех функций и видим что используется DPC: http://indy-vx.narod.ru/Temp/iopm.c
Для подтверждения можно загрузить IOPM в TSS и установить смещение её в KPROCESS, после чего обождать пока произойдёт свопинг посредством NtYieldExecution. После этого окажется что порт доступен, так как смещение будет загружено в TSS(разумеется на текущем процессоре). Ведь так просто :P

 

Clerk

Welcome back.

ajak

Зачем вы хочете это сделать? Открыть доступ к _своей_ задаче имея одновременно возможность загрузить сначала _свой_ драйвер который может делать все что угодно не делая извращений?

 

Не, просто я прочел, что при написании драйвера исп не документированные функции. Меня заинтересовало как эти функции были найдены. И возможно ли модифицировать карту доступа с помошью драйвера, но только с помошью документированных функций

 

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

 

Что за школота такая?

 

Где сурсы ядра?

 

wrk гуглится за пару минут, исходники NT и 2000 есть на любом торент трекере

 

А можно ссылочку если не трудно :_)