EXEC_DEFAULT = 1;
NO_EXEC_DEFAULT = 0;

Проверка в коде патчера на 1 не есть хорошо. Нужно сравнивать с нулём. Так работает тип bool: 0 = ложь, остальное - истина.

Ещё не хватает возможности в параметрах записи высокоуровневого перехватчика пользовательский указатель, который будет сохранён в структуре перехватчика и по которому можно было бы определить, с какой целью ставился перехват и кто его клиент. Что=то вроде HiHool->UserData.

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

Quote:Ужаснулся, глянув в код низкоуровневого перехватчика. Регистры не в стеке сохраняются и передаются, а в глобальной памяти. Это значит, что рекурсивный вызов перезатрёт их подчистую!

Code:

MOV [DWORD 4978BC8],EAX
   MOV [DWORD 4978BCC],ECX
   MOV [DWORD 4978BD0],EDX
   MOV [DWORD 4978BD4],EBX
   MOV [DWORD 4978BD8],ESP
   MOV [DWORD 4978BDC],EBP
   MOV [DWORD 4978BE0],ESI
   MOV [DWORD 4978BE4],EDI
   MOV EAX,74C6FC
   MOV [DWORD 4978BE8],EAX
   PUSH 4978BC8

я так понял речь о мосте LoHook хука.

во-первых, регистры сохраняются не в глобальной памяти а в памяти выделенной для конкретного объекта LoHook.
точно так же и память под мост выделена для каждого конкретного LoHook объекта и сам мост уникален для каждого экземпляра LoHook.
То есть получается что каждый мост каждого LoHook объекта работает со своей областью памяти для хранения значений регистров.

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

в-третьих, один патч (с собственным одним мостом и объектом HookContext) невозможно применить дважды ни к одному и тому же адресу ни к разным адресам. то есть рекурсивное выполнение кода моста невозможно.

На практике все прекрасно, что подтверждает правильность реализации.

т.е. HookContext передаваемый в высокоуровневую LoHook функцию на самом деле является частью LoHook, но доступен он только из высокоуровневой функции, ибо в другое время доступ к нему не имеет смысла.

Quote:Проверка в коде патчера на 1 не есть хорошо. Нужно сравнивать с нулём. Так работает тип bool: 0 = ложь, остальное - истина.

поправил в версии 2.1

Quote:Ещё не хватает возможности в параметрах записи высокоуровневого перехватчика пользовательский указатель, который будет сохранён в структуре перехватчика и по которому можно было бы определить, с какой целью ставился перехват и кто его клиент. Что=то вроде HiHool->UserData.

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


позже опубликую версию 2.1

Quote:во-вторых, я не понимаю о какой рекурсии может идти речь.

Процедура Х (...)
команда 1
низкоуровневый перехватчик №1
команда 2...

Низкоуровневый перехватчик №1(...)
вызвать процедуру Х(...); рекурсия !!!
другие команды...

Многие АПИ и часть алгоритмов требует рекурсии. Нельзя, чтобы перехватчик по одному адресу сохранял контекст в одной и той же области памяти. В такой перехватчик невозможно зайти дважды, не затерев предыдущий контекст. В Эре контекст сохраняется через PUSHAD и таких проблем нет.

Quote:не совсем понял зачем это нужно. можно абстрактный пример?...

Положим, есть скриптовый язык, для примера будет ЕРМ, но только для примера. Ему предоставляется АПИ для установки перехватчика SetHook(Addr, ERM_FUNC_ID).

Реально вызывается WriteHiHook на одну общую функцию: CallErmFunc. Но так как это именно функция без привязки к данным, она не может определить, какой ERM_FUNC_ID вызывать в свою очередь ей. Для этого в ЯП используют делегаты - связку: адрес объекта + адрес метода объекта.

Иначе говоря, одна функция обслуживает десятки перехватов. Чтобы определить, кому дальше передавать управление, ей нужно проанализировать какое-то поле данных, но ничего передать не получается. А с другой стороны, всегда передаётся-таки объект Hi/LoHook. Однако он бесполезен, в нём нельзя сохранить пользовательский указатель (h->UserData = ...).

Quote:Процедура Х (...)
команда 1
низкоуровневый перехватчик №1
команда 2...

Низкоуровневый перехватчик №1(...)
вызвать процедуру Х(...); рекурсия !!!
другие команды...

Многие АПИ и часть алгоритмов требует рекурсии. Нельзя, чтобы перехватчик по одному адресу сохранял контекст в одной и той же области памяти. В такой перехватчик невозможно зайти дважды, не затерев предыдущий контекст. В Эре контекст сохраняется через PUSHAD и таких проблем нет.

понял о какой рекурсии идет речь, но это изврат - вызывать из лоухука код, в который установлен этот лоухук.
хочу реального примера. Но посмотрю, конечно, что можно сделать.

В HiHook UserData добавлю

А так к версии 2 в патчере появились две вкусные вещи
WriteLoHookEx и WriteHexHook.


WriteLoHookEx работает так же как WriteLoHook, но позволяет полноценно работать со стеком контекста, т.е. возможно выполнение такой штуки:
вот на такое эровский лоу-хук точно не способен.



а WriteHexHook устанавливает LoHook без использования высокоуровневой функции, тело хука пишется прямо в вызове WriteHexHook в машинных кодах, подобно тому как патч пишется с помощью WriteCodePatch
пример:

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

Quote:понял о какой рекурсии идет речь, но это изврат - вызывать из лоухука код, в который установлен этот лоухук.
   хочу реального примера. Но посмотрю, конечно, что можно сделать.

Например, FindFileInLod. А в нём if FindFileInLod(файл с альтернативным расширением или изменённым именем, то вернуть его), иначе действие по умолчанию. У меня были и другие примеры, но нужно лезть в код и искать те, где была рекурсия. При чём порой рекурсия была косвенной, когда ты вызываешь АПИ, которое дёргает ту же функцию, в которой перехват. Это нормально, ибо рекурсия не бесконечная, а ограничена условиями и проверками.

Quote:с->esp -= 4;
IntAt(c->esp) = x;

Я обычно пишу так: dec(Context.esp, 4) и pinteger(context.esp)^ := x; Вряд ли можно чем-то упростить работу с обычными адресами в памяти, но посмотрим.

Quote:В HiHook UserData добавлю

Спасибо.

Quote:Но посмотрю, конечно, что можно сделать.

PUSHAD PUSH ESP? ))

(25.10.2013 17:42)Berserker Wrote:  

Quote: хочу реального примера.
Например, FindFileInLod. А в нём if FindFileInLod(файл с альтернативным расширением или изменённым именем, то вернуть его), иначе действие по умолчанию. У меня были и другие примеры, но нужно лезть в код и искать те, где была рекурсия. При чём порой рекурсия была косвенной, когда ты вызываешь АПИ, которое дёргает ту же функцию, в которой перехват. Это нормально, ибо рекурсия не бесконечная, а ограничена условиями и проверками.

в приведенном примере напрашивается использование хай хука на FindFileInLod. Но в любом случае я уже сделал сохранение регистров в стэке.

(25.10.2013 17:42)Berserker Wrote:  

Quote:с->esp -= 4;
IntAt(c->esp) = x;

Я обычно пишу так: dec(Context.esp, 4) и pinteger(context.esp)^ := x; Вряд ли можно чем-то упростить работу с обычными адресами в памяти, но посмотрим.

ты не понял о чем речь.
мой и твой код идентичны, дело не в простоте.
В твоем хуке по адресу (Context.esp - 4) храниться значение одного из регистров. Т.е. с каждым таким push в хуке ты будешь портить значения регистров, которые возможно соберешься использовать после такого пуша, и которые потом заPOPADишь в мосте, а за регистрами пойдут указатель на экземпляр THookHandlerArgs и адрес возврата в мост. Надеюсь, проблема понятна.

(25.10.2013 17:42)Berserker Wrote:  

Quote:Но посмотрю, конечно, что можно сделать.

PUSHAD PUSH ESP? ))

не так все просто.
В структуре HookContext патчера регистры в обратном порядке нежели в THookHandlerArgs и чтобы сохранить обратную совместимость
пушить регистры надо в обратном PUSHADу порядке.
плюс в новой версии патчера в HookContext еще и доступен для чтения/изменения регистр флагов, а он для той же обратной совместимости добавлен после поля return_address.

сама длл 2.1 и хэдер для с++ с комментариями уже готовы.
дополню твой PatchApi.pas и опубликую.

Отлично.

версия 2.1

библиотека + SDK + исходники

чейнджлог:

Добавил SetUserData и GetUserData к HiHook, но функцию установки HiHook хука с одновременным указанием UserData писать не стал.
Ее можно быстро написать самому, используя PatcherInstance::CreateHiHook, HiHook::SetUserData и HiHook::Apply

Есть один нюанс.
В хота 1.2 и в ХД+ версий ниже 3.59 есть критический баг в использовании патчера, который прощали старые версии, но не прощает 2.1

Quote:Добавил SetUserData и GetUserData к HiHook, но функцию установки HiHook хука с одновременным указанием UserData писать не стал.
   Ее можно быстро написать самому, используя PatcherInstance::CreateHiHook, HiHook::SetUserData и HiHook::Apply

Согласен. Не стал писать это же предложение.

Quote:В хота 1.2 и в ХД+ версий ниже 3.59 есть критический баг в использовании патчера, который прощали старые версии, но не прощает 2.1

Если есть двоичная несовместимость, можно было и в LoHook использовать PUSHAD (что быстрее ручного порегистрового сохранения). А с другой стороны, это нужно кучу всего обновлять. Меня просто всё время точит червь оптимизации )))

Кстати, использовал уже несколько раз исходники ХД при поиске информации. Так что открытые материалы имеют таки синергетический эффект.

версия 2.2

библиотека + SDK + исходники

чейнджлог:

версия 2.3

библиотека + SDK + исходники

чейнджлог:

patcher_x86.hpp для С++ дополнен еще и методами Patcher::VarGetValue(name, default_value) и Patcher::VarValue(name), которых
нет в PatchApi.pas
но подобные методы можно написать самому.

HD версии 3.660 теперь использует патчер 2.3 и использует его общие "переменные".
Экспортируемые _HD3_.dll методы HdCommon_Get и HdCommon_Set оставлены для обратной совместимости, но теперь являются оболочками новых методов патчера.
напомню, с помощью [SHIFT]+[CTRL]+[ALT]+[DEL] в ХД вызывается краш c генерацией логов,
и в сгенерированном patcher_x86 dump.txt можно посмотреть все общие "переменные" и их значения
Теперь чтобы использовать "переменные" ХД, не нужно грузить _HD3_.dll и импортировать ее функции.

еще один шаг для взаимодеийствия и дружбы модов.

Аналог общей библиотеки-реестра выходит (хранение ключей-значений с интерфейсом доступа к ним).

У меня, может, немного нубский вопрос, но я пока не понял, как выглядит система с патчером в действии.
Вот если я хочу использовать вместе свой мод, который будет прописывать какие-то значения в игре с помощью патчера, и HD Mod.
Как, что и к чему нужно подключать?
И второй вопрос про jump хуки в код. Если я правильно понимаю, то функции патчера просто позволяют извлечь текущий контекст в ассеблеровском виде, то есть нужно доподлинно знать, что именно сейчас лежит в регистрах и за что отвечает?

Погляди что-ли плагины Феанора с исходным кодом в качестве примеров.