Как я себе это представляю:
1. Прога ставит бряки и внедряет либу в процесс-жертву
2. Либа устанавливает VEH
3. Когда возникает исключение, прога должна каким-то образом получить от внедренной DLL-ки EXCEPTION_RECORD с кодом исключения и прочей инфой. Прога должна проверить, а наш ли это бряк (а, может, совсем даже не бряк ) и неведомым образом сообщить внедренной либе, что делать дальше (CONTINUE_SEARCH или CONTINUE_EXECUTION вернуть, например).

По первым двум пунктам вопросов нет. С 3 пунктом посложнее. Есть именованный FileMapping да event-ы, есть сокеты. А КРАСИВЫХ решений, я так понимаю, нет?

| Сообщение посчитали полезным:

Колбек зарегать.

| Сообщение посчитали полезным:

Шаред мем нормальное решение

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным:

PE_Kill

Зачем, если стек есть ?

| Сообщение посчитали полезным:

Т.е. вопрос - как организовать обмен инфой между процессами?
Все, что уже предложили + вообще нафиг обработчик эксепшена делать в другом процессе? Можно весь код засунуть в либу.

| Сообщение посчитали полезным:

Затем, что ТС хочет сделать подобие отладчика на технологии VEH, вот и спрашивает, как управлять ядром отладчика внутри процесса.

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным:

PE_Kill

Вызываем в длл функу RegisterCallback(). Она сохраняет в переменной указанную ссылку. Потом при нужно событии вызывает эту ссылку как процедуру, передавая через стек контекст и инфу про фолт. Тоже самое что и VEH. Это если всё в текущем процессе выполнять, ну я думал что нужно с текущим.

Если в другом процессе, то нужно какойто IPC механизм, самый простейший это как сказали секция + евентпейр(EventPair), что реализовано в ядре как LPC специально для этого. Хотя андок и PE_Kill брызгая слюной будет доказывать что не тру и механизм изменится(чего не произошло в W8)

| Сообщение посчитали полезным:

Зачем мне что то доказывать тому, кто даже не понял сразу ТЗ? И зачем использовать андок, да еще и LPC, когда можно использовать документированные и отточеные метода, которые и в W50 не изменятся?

Мапь проекцию и через локи сделай протокол общения, вот и всё.

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным: sys_dev

1. ТС хочет "КРАСИВОЕ решение".
2. Ядро отладчика это видимо вех хендлер, который передает 2 структуры другому процессу? Круто.

| Сообщение посчитали полезным:

q1nex пишет:
Ядро отладчика это видимо вех хендлер, который передает 2 структуры другому процессу? Круто
А разве Debug API делают больше?

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным:

PE_Kill пишет:
ТС хочет сделать подобие отладчика на технологии VEH

q1nex пишет:
Ядро отладчика это видимо вех хендлер, который передает 2 структуры другому процессу? Круто
Даже трейсить можно, если подумать. VirtualProtect с опцией PAGE_READWRITE (можно читать и писать, но выполнять нельзя) на первый байт инструкции. Затем на первый байт следующей инструкции и так далее. Правда, для этого нужен дизасм длин.
Можно еще хуков наставить и перехватывать загрузку DLL-ок, создание потоков, да что угодно.
К тому же такой отладчик не палится протами (теоретически) в отличии от отладчика на Debug API.
PE_Kill пишет:
Мапь проекцию и через локи сделай протокол общения, вот и всё
Что еще за локи?

| Сообщение посчитали полезным:

GoldenJoe пишет:
Даже трейсить можно, если подумать. VirtualProtect с опцией PAGE_READWRITE (можно читать и писать, но выполнять нельзя) на первый байт инструкции.
Что за изврат, если есть Trap flag?

GoldenJoe пишет:
Что еще за локи?
LOCK - префикс ассемблерных инструкций.

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным:

PE_Kill пишет:
Trap flag
Палевно же.

| Сообщение посчитали полезным:

А VirtualProtect не палево? Ещё и на 1 байт. Мне очень интересно, как ты это сделаешь. И да, будет пахать всё это медленно.

| Сообщение посчитали полезным:

PE_Kill

> LOCK - префикс ассемблерных инструкций.

Бредятина.

> PAGE_READWRITE (можно читать и писать, но выполнять нельзя)

Как это так. У меня пае выключен. Посему вообще атрибут PAGE_EXECUTE не робит

| Сообщение посчитали полезным:

PE_Kill пишет:
Шаред мем
Ну, так и быть, заюзаю. А чтоб красиво, можно класс-обертку над апишками запилить.

А VirtualProtect не вариант, да. Как спалить его использование, кстати? Самим же VirtualProtect'ом?

| Сообщение посчитали полезным:

bowrouco пишет:
Бредятина
Клерк ..., аминь.

От модератора: на сутки... ну ты понял

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным: SegFault

Вместо PAGE_READWRITE ставьте PAGE_GUARD, тогда при любом обращении будет EXCEPTION_PAGE_GUARD, а самое интересное что этот флаг будет автоматически сниматься при срабатывании.
Но как уже сказали это медленно.
Если не нравится trap flag, можно ставить аппаратные бряки на начало инструкций, ловить EXCEPTION_SINGLE_STEP и смотреть context.Dr6 и другие context.Dr* регистры, какой сработал. Если не наш, отдаем проге.
Только придется перехватить ZwGet/ZwSetContextThread чтоб не палить бряки.

Кстати надеюсь после установки векторного прерывания делаете хук AddVectoredExceptionHandler? Тк отлаживаемая прога может воткнуть свой обработчик вперед вашего

P.S.
в отличии от отладчика на Debug API.
Если немного пропатчить пару функций в ntdll, то почти все проты, за исключением некоторых, идут лесом


пусть trap flag тогда уж. Чтоб не спалиться, надо, как и в случаи с аппаратными бряками, перехватывать ZwGetThreadContext
Trap flag можно считать простой последовательностью PUSHFD/POP REG. Однако при трейсе можно сравнить следующий опкод команды с 0x9C и если это он то поставить Int3 или еще какой бряк за ней, чтоб не попасться.
Заодно и POPFD(0x9D), на случай если tf будет выставлять программа

| Сообщение посчитали полезным: GoldenJoe, bowrouco

Veliant, для трассировки пусть trap flag тогда уж. Чтоб не спалиться, надо, как и в случаи с аппаратными бряками, перехватывать ZwGetThreadContext, я так понимаю.
Veliant пишет:
хук AddVectoredExceptionHandler
Когда с шаред мем разберусь, и все будет работать, тогда уж займусь хуками.

| Сообщение посчитали полезным:

Veliant пишет:
Вместо PAGE_READWRITE ставьте PAGE_GUARD, то

на многоядерниках проблемы + GUARD_PAGE_VIOLATION генерируется частенько системой (сторож стек).
К тому-же если перехватывать Nt/Zw может уже перехватить KiUserExceptionDispatcher?

| Сообщение посчитали полезным:

0x90h, чем VEH хуже?

| Сообщение посчитали полезным:

0x90h пишет:
К тому-же если перехватывать Nt/Zw может уже перехватить KiUserExceptionDispatcher?

И то, и то, т.к. разные механизмы, тут не надо выбирать, первые чисто читают контекст, а вторая дотягивается до него, когда он копируется ядром.

на многоядерниках проблемы + GUARD_PAGE_VIOLATION генерируется частенько системой (сторож стек)

А вы думаете, как олли работает? Сравнивать надо, куда поставили, если вы собрались так делать трейс, но не будете ставить бряки ниже ImageBase. (или очень хитрый прот)

GoldenJoe пишет:
для трассировки пусть trap flag тогда уж. Чтоб не спалиться, надо, как и в случаи с аппаратными бряками, перехватывать ZwGetThreadContext, я так понимаю

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

Veliant пишет:
Заодно и POPFD(0x9D), на случай если tf будет выставлять программа

Как общее решение не заработает.
После выполнения pop ss следующая за ней инструкция будет выполнена, но отладчик не остановится на ней (Из Антиотладочных трюков)

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным: GoldenJoe

> Чтоб не спалиться..

Гиблая затея. Обнаружить установленный TF есть овер 9000 способов.

> Сравнивать надо, куда поставили, если вы собрались так делать трейс, но не будете ставить бряки ниже ImageBase. (или очень хитрый прот)

Очень содержательное выражение.. хз что это значит, но как по мне так нету разницы какой адрес, лиш бы за пределами стека. Если загрузить диапазон адресов в TEB, на которых возникнет останов, то ядро не развернёт фолт при доступе к сторожевой странице.

| Сообщение посчитали полезным:

Объясните, кто-нибудь, пожалуйста, в чем проблема с гвард пейдж на многоядерниках?

PE_Kill
А разве Debug API - ядро отладчика?

bowrouco
Гляньте личку плиз

| Сообщение посчитали полезным:

q1nex
Тут порченая лк, сообщения не доставляются, посему ничего не пришло.

| Сообщение посчитали полезным:

q1nex пишет:
А разве Debug API - ядро отладчика?
Debug API - интерфейс ядра отладчика.

bowrouco пишет:
Гиблая затея. Обнаружить установленный TF есть овер 9000 способов.
Видать никто кроме клерка их не знает, ну собственно как обычно.

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным:

Обычным pushfd насколько я помню нельзя спалить флаг Т. Потому что
ARCHANGEL пишет:
Трап флаг сам сбрасывается каждый раз

А вот так можно

При трейсе pop ss следующая остановка будет на инструкции после pushfd и в стек попадет значение с взведенным флагом Т.
Детали не помню, но в мане описано почему.
У Securom'а помнится был такой антитрейс.

| Сообщение посчитали полезным:

Это всё баяны, которые описаны 100 лет назад. В данном случае это обходится установкой int 3 бряка на pushfd. Есть еще try, который обходится хуком диспетчера, Get/Set ThreadContext, что тоже лечится.

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным:

PE_Kill

Ну например при вызове сискола с TF возникает задержка, гдето в полтора раза медленее. Или например баг приводящий к дедлоку(генерация любого исключения, кроме #DB с TF) позволяет определить TF. Вот есчо пример - хардварный сброс RPL на каждой инструкции. Или напрямую получить контекст. А есчо можно через теневые колбеки.. Хадварный останов на память - почему бы через ядро не читать(через сервисы, где Dr-контекст ядерный). Способов сколько угодно, это даже в ядре не решается.

| Сообщение посчитали полезным:

PE_Kill

Гдеже ответ то ?

| Сообщение посчитали полезным: