• XSS.stack #1 – первый литературный журнал от юзеров форума

нахождение девайся мыши в физической памяти

Отслеживать

mddbs

RAID-массив
Пользователь
Регистрация
09.02.2024
Сообщения
98
Реакции
3
Здравствуйте, хотел бы получить мнение опытных людей касательно того, как я могу реализовать движение мыши, если у меня есть доступ к чтению и записи физической памяти. Я использую уязвимый драйвер, и с его помощью могу читать и записывать память, но я не могу редактировать код драйвера, так как он не мой. Единственный способ реализации движения мыши, о котором я подумал, это нахождение девайса мыши в физической памяти и отправление команды напрямую ему. Если вы знаете какой-то другой метод, буду рад его услышать.



Нужна помощь в реализации движения мыши я попробовал уже очень много способов и их всех блокируют(ntusersendinput и другие более низкоуровневые функции которые вызываются в usermode).

Как найти девайс мыши в физ памяти ? -_-

Заранее спасибо всем, кто поможет.
Пишу на С, С++
 
Попробуй через gptCursorAsync в win32kbase.sys - он торчит в экспортах ( структукра POINT )


С вин 11 например:

curs.png


Соответсвенно тебе просто надо пройтись по физ памяти найти win32kbase там распаришивая IMAGE_DOS_HEADER + IMAGE_NT_HEADERS64 и таблицу экспорта его распарсить
 
DoomSlayer2002 сказал(а):
Попробуй через gptCursorAsync в win32kbase.sys - он торчит в экспортах ( структукра POINT )


С вин 11 например:

Посмотреть вложение 96423

Соответсвенно тебе просто надо пройтись по физ памяти найти win32kbase там распаришивая IMAGE_DOS_HEADER + IMAGE_NT_HEADERS64 и таблицу экспорта его распарсить
Спасибо щас буду пробовать реализовать
 
DoomSlayer2002 сказал(а):
Попробуй через gptCursorAsync в win32kbase.sys - он торчит в экспортах ( структукра POINT )


С вин 11 например:

Посмотреть вложение 96423

Соответсвенно тебе просто надо пройтись по физ памяти найти win32kbase там распаришивая IMAGE_DOS_HEADER + IMAGE_NT_HEADERS64 и таблицу экспорта его распарсить
А ты знаешь какие-то нестандартные usermode методы для передвижения мышки ? Возможно я что то упустил
 
Проблема в том, что в Win для мыши предосмотрено 2 разных интерфейса - это PS/2 и USB. На нижнем уровне дров i8042prt.sys (мышь и клава), а выше класс-драйвер mouclass.sys. Если вы указанным выше способом сможете найти i8042prt.sys, то от имени mouclass.sys сможете передать ему запрос IOCTL_INTERNAL_I8042_MOUSE_WRITE_BUFFER. Это должно работать для обоих интерфейсов PS2/USB - на то и существуют класс-драйвера.

learn.microsoft.com

Human Interface Devices (HID) - Windows drivers

Learn more about: Human Interface Devices (HID)
learn.microsoft.com
learn.microsoft.com

IOCTL_INTERNAL_I8042_MOUSE_WRITE_BUFFER (ntdd8042.h) - Windows drivers

The IOCTL_INTERNAL_I8042_MOUSE_WRITE_BUFFER request writes data to the i8042 port controller to control operation of a mouse device.
learn.microsoft.com

Если в WinDbg чекнуть потроха mouclass.sys можно обнаружить, что дров и вправду имеет обработчик на IRP_MJ_INTERNAL_DEVICE_CONTROL (вызывать сквозным образом чз PassThrough), а так-же, что в стеке у него 2 девайса "termDD.sys + i8042prt". Можно было вычислить и имя внутренней функции, но у меня нет символов pdb на mouclass.sys (винда левая и сервер мягких не даёт):

Код: 
0: kd> !drvobj mouclass 3
   Driver object (fffffa8002ab2060) is for:  \Driver\mouclass
   Device Object list:
   fffffa8002b03cf0   fffffa8002a942d0

Dispatch routines:
[00] IRP_MJ_CREATE                      fffff88003bf2ca0    mouclass+0x1ca0
[02] IRP_MJ_CLOSE                       fffff88003bf3038    mouclass+0x2038
[03] IRP_MJ_READ                        fffff88003bf36cc    mouclass+0x26cc
[09] IRP_MJ_FLUSH_BUFFERS               fffff88003bf2bac    mouclass+0x1bac
[0e] IRP_MJ_DEVICE_CONTROL              fffff88003bf9940    mouclass+0x8940
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL     fffff88003bf92b4    mouclass+0x82b4
[12] IRP_MJ_CLEANUP                     fffff88003bf2afc    mouclass+0x1afc
[16] IRP_MJ_POWER                       fffff88003bfad14    mouclass+0x9d14
[17] IRP_MJ_SYSTEM_CONTROL              fffff88003bfb0a4    mouclass+0xa0a4
[1b] IRP_MJ_PNP                         fffff88003bf41b4    mouclass+0x31b4

0: kd> !devstack fffffa8002b03cf0
  !DevObj           !DrvObj            !DevExt           ObjectName
> fffffa8002b03cf0  \Driver\mouclass   fffffa8002b03e40  PointerClass1
  fffffa8002b36da0  \Driver\TermDD     fffffa8002b36ef0  Terminal Desktop Server Driver
  fffffa80018f14d0  \Driver\PnpManager fffffa80018f1620  0000005c

0: kd> !devstack fffffa8002a942d0
  !DevObj           !DrvObj            !DevExt           ObjectName
> fffffa8002a942d0  \Driver\mouclass   fffffa8002a94420  PointerClass0
  fffffa8002a939f0  \Driver\i8042prt   fffffa8002a93b40
  fffffa800222fc20  \Driver\ACPI       fffffa800186b2d0  00000076
 
..ещё пару идей на эту тему.
Для поиска модулей/драйверов в ядре лично мне известны 2 легальных способа:

1. Запросить у Ntdll.dll переменную PsLoadedModuleList - получим указатель на структуру KLDR_DATA_TABLE_ENTRY ядра Ntoskrnl.exe. В WinDbg это выглядит так (Win7 х64, фрагмент):

Код: 
0: kd> ? poi PsLoadedModuleList
Evaluate expression: -6047288645488 = fffffa80`01822890

0: kd> dt _LDR_DATA_TABLE_ENTRY fffffa80`01822890
ntdll!_LDR_DATA_TABLE_ENTRY
   +0x000 InLoadOrderLinks  : _LIST_ENTRY [ 0xfffffa80`018227a0 - 0xfffff800`02e5f730 ]
   +0x010 InMemoryOrderLinks: _LIST_ENTRY [ 0xfffff800`02e99000 - 0x2f7cc ]
   +0x020 InInitOrderLinks  : _LIST_ENTRY [ 0x00000000`00000000 - 0x0 ]
   +0x030 DllBase           : 0xfffff800`02c1d000 Void
   +0x038 EntryPoint        : 0xfffff800`02ecf6f0 Void
   +0x040 SizeOfImage       : 0x5e6000
   +0x048 FullDllName       : _UNICODE_STRING "\SystemRoot\system32\xNtKrnl.exe"
   +0x058 BaseDllName       : _UNICODE_STRING "ntoskrnl.exe"
   +0x068 Flags             : 0x8004000
   +0x06c LoadCount         : 0x78
..........

Как видим, данная структура LDR точно принадлежит файлу ядра offset(58h), а по смещению(30h) прописана его база. Можно чекнуть эту базу на валидность, тогда должны упереться в сигнатуру "MZ" - есть такая:

Код: 
0: kd> db 0xfffff800`02c1d000
fffff800`02c1d000   4d 5a 90 00 03 00 00 00 - 04 00 00 00 ff ff 00 00  MZ..............
fffff800`02c1d010   b8 00 00 00 00 00 00 00 - 40 00 00 00 00 00 00 00  ........@.......
fffff800`02c1d020   00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
fffff800`02c1d030   00 00 00 00 00 00 00 00 - 00 00 00 00 f8 00 00 00  ................
fffff800`02c1d040   0e 1f ba 0e 00 b4 09 cd - 21 b8 01 4c cd 21 54 68  ........!..L.!Th
fffff800`02c1d050   69 73 20 70 72 6f 67 72 - 61 6d 20 63 61 6e 6e 6f  is program canno
fffff800`02c1d060   74 20 62 65 20 72 75 6e - 20 69 6e 20 44 4f 53 20  t be run in DOS
fffff800`02c1d070   6d 6f 64 65 2e 0d 0d 0a - 24 00 00 00 00 00 00 00  mode....$.......

Теперь, чтобы найти сл.структуру в списке, достаточно взять первый-же qword = 0xfffffa80`018227a0 по смещению(0), и получаем аналогичную инфу уже о модуле Hal.dll. Крутим этот цикл, пока не обнаружим требуемый exe/sys/dll:

Код: 
0: kd> dt _LDR_DATA_TABLE_ENTRY 0xfffffa80`018227a0
ntdll!_LDR_DATA_TABLE_ENTRY
   +0x000 InLoadOrderLinks  : _LIST_ENTRY [ 0xfffffa80`018226c0 - 0xfffffa80`01822890 ]
   +0x010 InMemoryOrderLinks: _LIST_ENTRY [ 0xfffff800`03230000 - 0x2964 ]
   +0x020 InInitOrderLinks  : _LIST_ENTRY [ 0x00000000`00000000 - 0x0 ]
   +0x030 DllBase           : 0xfffff800`03203000 Void
   +0x038 EntryPoint        : 0xfffff800`03203000 Void
   +0x040 SizeOfImage       : 0x49000
   +0x048 FullDllName       : _UNICODE_STRING "\SystemRoot\system32\hal.dll"
   +0x058 BaseDllName       : _UNICODE_STRING "hal.dll"
   +0x068 Flags             : 0x8004000
   +0x06c LoadCount         : 0x29
.............
0: kd> dt _LDR_DATA_TABLE_ENTRY 0xfffffa80`018226c0
ntdll!_LDR_DATA_TABLE_ENTRY
   +0x000 InLoadOrderLinks  : _LIST_ENTRY [ 0xfffffa80`0181cf00 - 0xfffffa80`018227a0 ]
   +0x010 InMemoryOrderLinks: _LIST_ENTRY [ 0xfffff800`00bd6000 - 0x144 ]
   +0x020 InInitOrderLinks  : _LIST_ENTRY [ 0x00000000`00000000 - 0x0 ]
   +0x030 DllBase           : 0xfffff800`00bd1000 Void
   +0x038 EntryPoint        : 0xfffff800`00bd1000 Void
   +0x040 SizeOfImage       : 0xa000
   +0x048 FullDllName       : _UNICODE_STRING "\SystemRoot\system32\kdcom.dll"
   +0x058 BaseDllName       : _UNICODE_STRING "kdcom.dll"
   +0x068 Flags             : 0x8004000
   +0x06c LoadCount         : 3
.............

2. Этот способ самый простой, но не универсальный, т.к. смещения на системах х32/64 будут отличаться. Поэтому лучше использовать спец API RtlQueryModuleInformation(), которая за один выстрел возвращает инфу сразу о всех загруженных модулях ядра. Одна проблема - нужно возиться в выделением/освобождением памяти под приёмный буфер.

3. Ну и теперь немного хардкора на мышиную тему..
Известно, что система собирает сообщения в очереди "Queue", причём для синхронных из них очередей не существует, т.к. Win всё-равно не возвратит управление, пока не обработает мессагу. Таким образом, имеем отдельный пул очередей для асинхронных мессаг (у каждого потока Thread своя), и отдельно общую для аппаратных устройств, среди которых клава, мышь и таймер. Значит если найти адрес аппаратной очереди, можно будет запихать в неё своё сообщение (если получится).

Как ни странно, указатели на обе очереди лежат в пространстве модуля win32k.sys, который через порт ALPC напрямую общается с подсистемой клиент/сервера csrss.exe в юзер space. Асинхронную очередь описывает структура win32k!tagSMS, а хардвейрную win32k!tagQ. Вот их прототипы:

Код: 
0: kd> dt tagSMS
win32k!tagSMS
   +0x000 psmsNext          : Ptr64 tagSMS
   +0x008 psmsReceiveNext   : Ptr64 tagSMS
   +0x010 ptiSender         : Ptr64 tagTHREADINFO  <--- кто отправил
   +0x018 ptiReceiver       : Ptr64 tagTHREADINFO  <--- кому..
   +0x020 lpResultCallBack  : Ptr64     void
   +0x028 dwData            : Uint8B
   +0x030 ptiCallBackSender : Ptr64 tagTHREADINFO
   +0x038 lRet              : Int8B
   +0x040 tSent             : Uint4B
   +0x044 flags             : Uint4B
   +0x048 wParam            : Uint8B         <--- параметры
   +0x050 lParam            : Int8B
   +0x058 message           : Uint4B
   +0x060 spwnd             : Ptr64 tagWND
   +0x068 pvCapture         : Ptr64 Void

0: kd> dt tagQ
win32k!tagQ
   +0x000 mlInput          : tagMLIST      <---------- много полезной инфы..
   +0x018 ptiSysLock       : Ptr64 tagTHREADINFO
   +0x020 idSysLock        : Uint8B
   +0x028 idSysPeek        : Uint8B
   +0x030 ptiMouse         : Ptr64 tagTHREADINFO  <--- мышь?
   +0x038 ptiKeyboard      : Ptr64 tagTHREADINFO  <--- или клава?
   +0x040 spwndCapture     : Ptr64 tagWND
   +0x048 spwndFocus       : Ptr64 tagWND
   +0x050 spwndActive      : Ptr64 tagWND
   +0x058 spwndActivePrev  : Ptr64 tagWND
   +0x060 codeCapture      : Uint4B
   +0x064 msgDblClk        : Uint4B
   +0x068 xbtnDblClk       : Uint2B
   +0x06c timeDblClk       : Uint4B
   +0x070 hwndDblClk       : Ptr64 HWND__
   +0x078 ptDblClk         : tagPOINT         <------- координаты мыши
   +0x080 ptMouseMove      : tagPOINT
   +0x088 afKeyRecentDown  : [32] UChar
   +0x0a8 afKeyState       : [64] UChar
   +0x0e8 caret            : tagCARET
   +0x130 spcurCurrent     : Ptr64 tagCURSOR
   +0x138 iCursorLevel     : Int4B
   +0x13c QF_flags         : Uint4B
   +0x140 cThreads         : Uint2B
   +0x142 cLockCount       : Uint2B
   +0x144 msgJournal       : Uint4B
   +0x148 ExtraInfo        : Int8B
   +0x150 ulEtwReserved1   : Uint4B

0: kd> dt tagPOINT
win32k!tagPOINT
   +0x000 x                : Int4B
   +0x004 y                : Int4B
0: kd>

Указатели на обе эти структуры глубоко зарыты в нёдрах системы, причём даже WinDbg скрывает их, т.к. мягкие объявили, что они "Для внутреннего пользования". По сути, нужно просто найти поле Win32Thread внутри структуры KTHREAD планировщика, где и будет лежать линк на структуру win32k!tagTHREADINFO:

Код: 
0: kd> dt _KTHREAD Win32Thread
ntdll!_KTHREAD
   +0x270 Win32Thread : Ptr64 Void

Как видим, значение в этом поле WinDbg скрыл, обозвав его тупо "Ptr64" в космос, хотя обычно указывает явно на какую-либо именованную структуру. Ну и ладно.. главное конторы реверсеров ещё со-времён ХР открыли нам свои секреты. Сама-же структура win32k!tagTHREADINFO довольно объёмна (928 байт), а основные её поля представлены ниже:

Код: 
0: kd> dt win32k!tagTHREADINFO
   +0x048 pClientID        : Ptr64 Void
   +0x160 pq               : Ptr64 tagQ
   +0x188 ulClientDelta    : Uint8B
   +0x1a0 pstrAppName      : Ptr64 _UNICODE_STRING
   +0x1a8 psmsSent         : Ptr64 tagSMS
   +0x1b0 psmsCurrent      : Ptr64 tagSMS
   +0x1b8 psmsReceiveList  : Ptr64 tagSMS

Здесь внимание привлекает интересное поле "ulClientDelta". Поскольку часть памяти win32k.sys мапится в юзермод, то даже из юзера мы сможем найти через дельту эту структуру, но только на чтение.

ЗЫ: сорян за столька букаф.. что-то нахлынуло.
 
Roller сказал(а):
..ещё пару идей на эту тему.
Для поиска модулей/драйверов в ядре лично мне известны 2 легальных способа:

1. Запросить у Ntdll.dll переменную PsLoadedModuleList - получим указатель на структуру KLDR_DATA_TABLE_ENTRY ядра Ntoskrnl.exe. В WinDbg это выглядит так (Win7 х64, фрагмент):

Код: 
0: kd> ? poi PsLoadedModuleList
Evaluate expression: -6047288645488 = fffffa80`01822890

0: kd> dt _LDR_DATA_TABLE_ENTRY fffffa80`01822890
ntdll!_LDR_DATA_TABLE_ENTRY
   +0x000 InLoadOrderLinks  : _LIST_ENTRY [ 0xfffffa80`018227a0 - 0xfffff800`02e5f730 ]
   +0x010 InMemoryOrderLinks: _LIST_ENTRY [ 0xfffff800`02e99000 - 0x2f7cc ]
   +0x020 InInitOrderLinks  : _LIST_ENTRY [ 0x00000000`00000000 - 0x0 ]
   +0x030 DllBase           : 0xfffff800`02c1d000 Void
   +0x038 EntryPoint        : 0xfffff800`02ecf6f0 Void
   +0x040 SizeOfImage       : 0x5e6000
   +0x048 FullDllName       : _UNICODE_STRING "\SystemRoot\system32\xNtKrnl.exe"
   +0x058 BaseDllName       : _UNICODE_STRING "ntoskrnl.exe"
   +0x068 Flags             : 0x8004000
   +0x06c LoadCount         : 0x78
..........

Как видим, данная структура LDR точно принадлежит файлу ядра offset(58h), а по смещению(30h) прописана его база. Можно чекнуть эту базу на валидность, тогда должны упереться в сигнатуру "MZ" - есть такая:

Код: 
0: kd> db 0xfffff800`02c1d000
fffff800`02c1d000   4d 5a 90 00 03 00 00 00 - 04 00 00 00 ff ff 00 00  MZ..............
fffff800`02c1d010   b8 00 00 00 00 00 00 00 - 40 00 00 00 00 00 00 00  ........@.......
fffff800`02c1d020   00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
fffff800`02c1d030   00 00 00 00 00 00 00 00 - 00 00 00 00 f8 00 00 00  ................
fffff800`02c1d040   0e 1f ba 0e 00 b4 09 cd - 21 b8 01 4c cd 21 54 68  ........!..L.!Th
fffff800`02c1d050   69 73 20 70 72 6f 67 72 - 61 6d 20 63 61 6e 6e 6f  is program canno
fffff800`02c1d060   74 20 62 65 20 72 75 6e - 20 69 6e 20 44 4f 53 20  t be run in DOS
fffff800`02c1d070   6d 6f 64 65 2e 0d 0d 0a - 24 00 00 00 00 00 00 00  mode....$.......

Теперь, чтобы найти сл.структуру в списке, достаточно взять первый-же qword = 0xfffffa80`018227a0 по смещению(0), и получаем аналогичную инфу уже о модуле Hal.dll. Крутим этот цикл, пока не обнаружим требуемый exe/sys/dll:

Код: 
0: kd> dt _LDR_DATA_TABLE_ENTRY 0xfffffa80`018227a0
ntdll!_LDR_DATA_TABLE_ENTRY
   +0x000 InLoadOrderLinks  : _LIST_ENTRY [ 0xfffffa80`018226c0 - 0xfffffa80`01822890 ]
   +0x010 InMemoryOrderLinks: _LIST_ENTRY [ 0xfffff800`03230000 - 0x2964 ]
   +0x020 InInitOrderLinks  : _LIST_ENTRY [ 0x00000000`00000000 - 0x0 ]
   +0x030 DllBase           : 0xfffff800`03203000 Void
   +0x038 EntryPoint        : 0xfffff800`03203000 Void
   +0x040 SizeOfImage       : 0x49000
   +0x048 FullDllName       : _UNICODE_STRING "\SystemRoot\system32\hal.dll"
   +0x058 BaseDllName       : _UNICODE_STRING "hal.dll"
   +0x068 Flags             : 0x8004000
   +0x06c LoadCount         : 0x29
.............
0: kd> dt _LDR_DATA_TABLE_ENTRY 0xfffffa80`018226c0
ntdll!_LDR_DATA_TABLE_ENTRY
   +0x000 InLoadOrderLinks  : _LIST_ENTRY [ 0xfffffa80`0181cf00 - 0xfffffa80`018227a0 ]
   +0x010 InMemoryOrderLinks: _LIST_ENTRY [ 0xfffff800`00bd6000 - 0x144 ]
   +0x020 InInitOrderLinks  : _LIST_ENTRY [ 0x00000000`00000000 - 0x0 ]
   +0x030 DllBase           : 0xfffff800`00bd1000 Void
   +0x038 EntryPoint        : 0xfffff800`00bd1000 Void
   +0x040 SizeOfImage       : 0xa000
   +0x048 FullDllName       : _UNICODE_STRING "\SystemRoot\system32\kdcom.dll"
   +0x058 BaseDllName       : _UNICODE_STRING "kdcom.dll"
   +0x068 Flags             : 0x8004000
   +0x06c LoadCount         : 3
.............

2. Этот способ самый простой, но не универсальный, т.к. смещения на системах х32/64 будут отличаться. Поэтому лучше использовать спец API RtlQueryModuleInformation(), которая за один выстрел возвращает инфу сразу о всех загруженных модулях ядра. Одна проблема - нужно возиться в выделением/освобождением памяти под приёмный буфер.

3. Ну и теперь немного хардкора на мышиную тему..
Известно, что система собирает сообщения в очереди "Queue", причём для синхронных из них очередей не существует, т.к. Win всё-равно не возвратит управление, пока не обработает мессагу. Таким образом, имеем отдельный пул очередей для асинхронных мессаг (у каждого потока Thread своя), и отдельно общую для аппаратных устройств, среди которых клава, мышь и таймер. Значит если найти адрес аппаратной очереди, можно будет запихать в неё своё сообщение (если получится).

Как ни странно, указатели на обе очереди лежат в пространстве модуля win32k.sys, который через порт ALPC напрямую общается с подсистемой клиент/сервера csrss.exe в юзер space. Асинхронную очередь описывает структура win32k!tagSMS, а хардвейрную win32k!tagQ. Вот их прототипы:

Код: 
0: kd> dt tagSMS
win32k!tagSMS
   +0x000 psmsNext          : Ptr64 tagSMS
   +0x008 psmsReceiveNext   : Ptr64 tagSMS
   +0x010 ptiSender         : Ptr64 tagTHREADINFO  <--- кто отправил
   +0x018 ptiReceiver       : Ptr64 tagTHREADINFO  <--- кому..
   +0x020 lpResultCallBack  : Ptr64     void
   +0x028 dwData            : Uint8B
   +0x030 ptiCallBackSender : Ptr64 tagTHREADINFO
   +0x038 lRet              : Int8B
   +0x040 tSent             : Uint4B
   +0x044 flags             : Uint4B
   +0x048 wParam            : Uint8B         <--- параметры
   +0x050 lParam            : Int8B
   +0x058 message           : Uint4B
   +0x060 spwnd             : Ptr64 tagWND
   +0x068 pvCapture         : Ptr64 Void

0: kd> dt tagQ
win32k!tagQ
   +0x000 mlInput          : tagMLIST      <---------- много полезной инфы..
   +0x018 ptiSysLock       : Ptr64 tagTHREADINFO
   +0x020 idSysLock        : Uint8B
   +0x028 idSysPeek        : Uint8B
   +0x030 ptiMouse         : Ptr64 tagTHREADINFO  <--- мышь?
   +0x038 ptiKeyboard      : Ptr64 tagTHREADINFO  <--- или клава?
   +0x040 spwndCapture     : Ptr64 tagWND
   +0x048 spwndFocus       : Ptr64 tagWND
   +0x050 spwndActive      : Ptr64 tagWND
   +0x058 spwndActivePrev  : Ptr64 tagWND
   +0x060 codeCapture      : Uint4B
   +0x064 msgDblClk        : Uint4B
   +0x068 xbtnDblClk       : Uint2B
   +0x06c timeDblClk       : Uint4B
   +0x070 hwndDblClk       : Ptr64 HWND__
   +0x078 ptDblClk         : tagPOINT         <------- координаты мыши
   +0x080 ptMouseMove      : tagPOINT
   +0x088 afKeyRecentDown  : [32] UChar
   +0x0a8 afKeyState       : [64] UChar
   +0x0e8 caret            : tagCARET
   +0x130 spcurCurrent     : Ptr64 tagCURSOR
   +0x138 iCursorLevel     : Int4B
   +0x13c QF_flags         : Uint4B
   +0x140 cThreads         : Uint2B
   +0x142 cLockCount       : Uint2B
   +0x144 msgJournal       : Uint4B
   +0x148 ExtraInfo        : Int8B
   +0x150 ulEtwReserved1   : Uint4B

0: kd> dt tagPOINT
win32k!tagPOINT
   +0x000 x                : Int4B
   +0x004 y                : Int4B
0: kd>

Указатели на обе эти структуры глубоко зарыты в нёдрах системы, причём даже WinDbg скрывает их, т.к. мягкие объявили, что они "Для внутреннего пользования". По сути, нужно просто найти поле Win32Thread внутри структуры KTHREAD планировщика, где и будет лежать линк на структуру win32k!tagTHREADINFO:

Код: 
0: kd> dt _KTHREAD Win32Thread
ntdll!_KTHREAD
   +0x270 Win32Thread : Ptr64 Void

Как видим, значение в этом поле WinDbg скрыл, обозвав его тупо "Ptr64" в космос, хотя обычно указывает явно на какую-либо именованную структуру. Ну и ладно.. главное конторы реверсеров ещё со-времён ХР открыли нам свои секреты. Сама-же структура win32k!tagTHREADINFO довольно объёмна (928 байт), а основные её поля представлены ниже:

Код: 
0: kd> dt win32k!tagTHREADINFO
   +0x048 pClientID        : Ptr64 Void
   +0x160 pq               : Ptr64 tagQ
   +0x188 ulClientDelta    : Uint8B
   +0x1a0 pstrAppName      : Ptr64 _UNICODE_STRING
   +0x1a8 psmsSent         : Ptr64 tagSMS
   +0x1b0 psmsCurrent      : Ptr64 tagSMS
   +0x1b8 psmsReceiveList  : Ptr64 tagSMS

Здесь внимание привлекает интересное поле "ulClientDelta". Поскольку часть памяти win32k.sys мапится в юзермод, то даже из юзера мы сможем найти через дельту эту структуру, но только на чтение.

ЗЫ: сорян за столька букаф.. что-то нахлынуло.
Спасибо большое
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх