Как правильно написать SEH-обработчик на ассемблере под win32?

Question

[KrD]

Пишу на ассемблере поиск базы kernel32.dll в памяти своего процесса. Взял указатель на дебри секции .text оной библиотеки с вершины стека, дальше ищу "обратным" поиском сигнатуру MZ. Есть реализация с выравниванием адреса по 64K и она работает, но, по моему разумению, это не корректно, т.к. страница памяти равна 4K. Соответственно, при таком раскладе я обязательно попадаю на "пустые" регионы памяти после заголовков файла и перед секцией .text, что требует установки своего SEH-обработчика для возврата управления в свой код.

Проблема в работе моего обработчика: при попытке отладить через user-mode отладчик, оный падает при срабатывании исключения в основном коде; без отладки процесс/поток прибивается тихо и без ошибок. Иным способом отладить не получается, только долгим и вдумчивым взглядом.

Прошу Вашей помощи в написании правильного SEH-обработчика.

Версия с блоками по 64к и без SEH (рабочая):
[ pastebin.com/XbQMZriF ]

Версия с блоками по 4к и с SEH (нерабочая):
[ pastebin.com/Utkywj68 ]

Answer 1

[KrD]

Прошу прощения: вероятно, был невнимателен при прочтении материалов, или материалы были не те (уже и не упомню).

Нашёл документацию, где выяснилось, что контекст потока передаётся в SEH-обработчик не вторым, а третьим параметром. Поправил код, и оно заработало как часы.

Answer 2

[none7]

К чему искать проблем с исключениями, если способ через PEB работает от Win2k до Win10?

mov eax, fs:[18]
mov eax, [eax+30h]
mov eax, [eax+0ch]
mov eax, [eax+0ch]

Так находится структура описывающая основный .exe файл.
+0h Next
+18h HANDLE
+24h UNICODE_STRING FullFileName
+2Ch UNICODE_STRING ShortName
Через Next можно перечислить все загруженные модули, следующим после .exe файла гарантировано будет ntdll. От вас требуется только написание stricmp для структур UNICODE_STRING, ну или импортировать RtlEqualUnicodeString из ntdll.

Comments

[KrD]

Знаете, я сейчас пишу аналогичный код под win64, где SEH вообще не применим. Сегодня-завтра проверю, как оно там поживает, и, похоже, что отмечу именно Ваш ответ как решение. Спасибо! :)

[none7]

KrD: Ну смещения на x64 естественно не совпадут, да и к fs:[18] доступ запрещён. Можете попробовать дизасемблироать kernel32:K32EnumProcessModules код там вроде не сложный. Способ перечисления библиотек в процессах как раз основан на PEB читаемом через ReadProcessMemory. Расположение самого PEB придётся выяснять создав копию NtQueryInformationProcess.

[none7]

KrD: Всё даже проще чем я думал
mov rax, gs:[30h] ; Teb
mov rax, [rax+60h] ; Peb
mov rax, [rax+18h]
mov rax, [rax+10h]

+30h HANDLE
+48h UNICODE_STRING FullName
+58h UNICODE_STRING ShortName