Windows: постарайтесь не продвигать полный x86 контекст на стеке

Обработка исключений Windows называется SEH. IIRC, вы можете отключить его, но среда выполнения используемого вами языка может не понравиться.

В основном вам потребуется повторно реализовать множество обработчиков прерываний, то есть подключиться к таблице дескрипторов прерываний (IDT). Проблема в том, что вам также потребуется повторно реализовать обратный вызов режима ядра -> пользовательского режима (для SEH этот обратный вызов находится в ntdll.dll и называется KiuserExceptionDispatcher , это запускает все Логика SEH). Дело в том, что остальная часть системы полагается на работу SEH так, как она работает сейчас, и ваше решение сломало бы вещи, потому что вы делали это в масштабе всей системы. Может быть, вы могли бы проверить, в каком процессе вы находитесь во время прерывания. Однако общая концепция подвержена ошибкам и очень плохо влияет на стабильность системы imho.
На самом деле это методы, подобные руткитам.

Редактировать:
Еще несколько деталей: причина, по которой вам потребуется повторно реализовать обработчики прерываний, заключается в том, что исключения (например, деление на ноль) по сути являются программными прерываниями, и они всегда выполняются через IDT. Когда возникло исключение, ядро ​​собирает контекст и сигнализирует об исключении обратно в пользовательский режим (через вышеупомянутый KiUserExceptionDispatcher в ntdll). На этом этапе вам нужно будет вмешаться, и поэтому вам также потребуется предоставить механизм для возврата в пользовательский режим. (В ntdll есть функция, которая используется как точка входа из режима ядра - я не помню имя, но это что-то с KiUserACP .....)

Если Windows использует оборудование x86 для реализации своего кода прерывания, вам потребуется доступ по кольцу 0 (через драйвер или API), чтобы изменить вентиль, используемый для прерываний.

Концепция x86 точек шлюза один из:

• адрес прерывания (сегмент кода + указатель смещения), который вызывается, когда весь контекст регистра, включая адрес возврата, помещается в текущий стек (= текущий esp), или
• дескриптор задачи, который переключает для другой задачи (можно рассматривать как поток с аппаратной поддержкой). Вместо этого все соответствующие данные помещаются в стек (особенно) этой задачи.

Вы, конечно, хотите последнее. Я бы посмотрел, как это реализовано в Wine , это может оказаться более эффективным, чем запрос в Google.

Я предполагаю, что вам, к сожалению, необходимо реализовать драйвер, чтобы заставить его работать на x86, и согласно Википедии драйверы не могут изменить его на платформе IA64. Второй лучший вариант - это чередование пространства в ваших стеках, чтобы контекстное нажатие из ловушки всегда соответствовало?

У меня закончилось место в поле для комментариев ...

В любом случае, я не уверен, куда указывает вектор, я основывал комментарий на ответе SDD и упоминании «KiUserExceptionDispatcher» "... если не считать дальнейшего поиска ( http://www.nynaeve.net/?p=201 ), похоже, что сейчас уже слишком поздно.

SIDT может выполняться в кольце 3 ... это покажет содержимое таблицы прерываний, и вы сможете загрузить сегмент и, по крайней мере, прочитать содержимое таблицы. Если повезет, вы можете затем прочитать запись для (например) вектора 0 / делить на ноль и прочитать содержимое обработчика.

На этом этапе я бы попытался сопоставить шестнадцатеричные байты, чтобы сопоставить код с системой файл, но может быть лучший способ определить, к какому файлу принадлежит код (это ' s не обязательно DLL, это может быть win32k.sys, или он может быть динамически сгенерирован, кто знает). Я не знаю, есть ли способ выгрузить схему физической памяти из пользовательского режима.

Если ничего не помогает, вы можете либо настроить отладчик режима ядра, либо эмулировать Windows ( Bochs ), где вы можете напрямую просматривать таблицы прерываний и структуру памяти. Затем вы можете отслеживать, пока не будет выдвинут КОНТЕКСТ, и искать возможность получить контроль до того, как это произойдет.