Намучавшись с мной любимыми высокоуровневыми хуками, и поняв, что ничего хорошего не выйдет для моей задачи (нужный мне интерфейс не поддерживает стекинг хуков). Пришлось рассмотреть более жесткий метод хука - модификацию пролога функции. Замена IAT тоже не помогает т.к. мой код грузится уже после загрузки нужной библиотеки, и соответсвенно полагаться на IAT смысла нет. Итак остался только один метод - модификация пролога.
Следовательно возникло несколько вопросов :
Код начала функции :

HttpOpenRequestA
 text:6300D7C9 000 55                                      push    ebp
.text:6300D7CA 004 8B EC                                   mov     ebp, esp
.text:6300D7CC 004 83 EC 3C                                sub     esp, 3Ch        ; Integer Subtraction
.text:6300D7CF 040 53                                      push    ebx
.text:6300D7D0 044 33 DB                                   xor     ebx, ebx        ; Logical Exclusive OR
.text:6300D7D2 044 39 1D DC A0 07 63                       cmp     dword_6307A0DC, ebx ; Compare Two Operands
.text:6300D7D8 044 56                                      push    esi
 

Модифицироваться будут первые 5 байт (вставляться long jump)
Но перед этим, я проверяю первые 4 байта функции (55 8B EC 83 EC) - тот ли это пролог что мне нужен. Если байты равны вышеприведенной комбинации, то пролог "мой".
вопрос #1: насколько верно утверждение, что любая winapi функция будет начинаться с :

push    ebp
mov     ebp, esp
sub     esp, xxx

?
Вопрос #2: Насколько безопасно вызывать внутри подмененного пролога другие winapi функции? (как-то я хучил ws2_32 , и помню, что там категорически ничего нельзя вызывать...)
И последнее - Target OS : 98/Me/NT/2K/XP/2K3 т.е. нужно чтоб работало везде ...

#1 Неверно, возми, например lstrcmp:
push ebx
mov ebx,[esp+08]
push esi
.
.
но например, можно сделать заглушку с jmp (ради чего и трудимся) и в конце с нужными NOP для выравнивания. Страшнее, когда
push ecx
call edx
тут думать надо :)
#2 Рекомендуется сначала сделать PUSHFD & PUSHA, приче именно в этой последовательности, чтобы не по... флаги, а вообще черт её знает. Наверняка есть ф-ии от которых требуется возврашения выполнения ч/з определенный промежуток времени а у тя код минуту вып-ся... (например). И еще, если дело касаться ядра будет, то интереснее, придется нарываться на разные IRQ levels, а разные ф-ии требуют только определенных уровней, хотя эта тоже не проблемма.
З.Ы. if всё минуешь, то не попастся бы в свои же лапы... надо знать какая ф-я (твоя, в хуке) что вызавает вплоть до конца

вопрос #1: насколько верно утверждение, что любая winapi функция будет начинаться с :
push ebp
mov ebp, esp
sub esp, xxx
Думаю верно всегда т.к. они все на сях написаны.
Кстати а зачем оно тебе? Если хочешь посмотреть есть хук или нет, можно ведь со своим джампом сравнивать.

Вопрос #2: Насколько безопасно вызывать внутри подмененного пролога другие winapi функции? (как-то я хучил ws2_32 , и помню, что там категорически ничего нельзя вызывать...)
И последнее - Target OS : 98/Me/NT/2K/XP/2K3 т.е. нужно чтоб работало везде ...
Меня тоже интересует этот вопрос. Под nt/2k/xp никогда не было таких проблем, а под 9х например при вызове
push 0
call Sleep
из хука recv(wsock32.dll) приложение виснет :( Но я так и не стал разбираться в чем дело.

ЗЫ Вот вывесил последнюю версию своей библиотечки, вдруг поможет.

Только что поставил 98 . Проверил - на 98 первые 5 байт такие же как на ХР.
Касательно #1 - я здесь больше имел ввиду - может ли пролог ТАК СИЛЬНО отличаться у одной и той же функции в разных версиях винды.

но например, можно сделать заглушку с jmp (ради чего и трудимся) и в конце с нужными NOP для выравнивания.
Это имхо не нужно - NOPы. Т.к. достаточно просто jmp обратно в "правильное" место сделать.

Насчет дедлока - тут ты прав. Но мне это не особо страшно т.к. я собираюсь вызывать функции синхронизации.
Да. Это не ядро...

p.s. За ответ - громадное спасибо.

hello_world - попробую завтра с утра, посмотрю либу

Последнее о NOP.
Можно восстановить код заместо jmp и дальше его продолжить - конечно, согласен. можно не восстанавливать, а в себе выполнить затертое, а выполнений возобновить со следующих комманд. Вроде, последнее глупо, но If у захученой проги больше 1 потока, то после переправки jmp обратно планировщик зажмет пару квантов у тебя и отдаст соседнему потоку, и он пройдется мимо хука. Вот.
Хотя зависит от задачи.

PavPS -я планирую код выполнять в хуке, а не восстанавливать. Т.к. у меня там будет счетчик вызовов функции. Помимо кода ещё будет вызов InterlockedIncrement - т.е. даже с потоками беды не будет.
Но я здесь вспомнил о ещё одной проблеме - переключение контекста.
Замена 5 байт не есть атомарная операциия. И если можно "спастись" от того, чтоб функция получила управление, во время хука, усыпив все потоки, кроме своего. То гарантировать (опять же кроссплатформенно), что мы не получим потока уснувшего на push ebp нереально. Имхо.
Какие мысли на этот счет?

И у меня такие заморочки были, но правда, ни разу такой ситуации небыло (хотя потоков ... туча).
тут на первый взгля видно 2 наитупейших, но выхода - облазить все потоки и посмотреть (хотя это тоже не атомарно :))) или более "атомарно" но еще менее умно
mov eax,опкод jmp на самого себя
mov esi,адрес затераемого хука
xchg eax.dword ptr [esi]
xchg - вып-ся атомарно и любой заснувший поток будет крутится на месте. После полноценно вшиваешь хук, и отвязываешь jmp, пуская потоки(if таковые были) дальше
Хотя, тоже, нет гарантии, что по [esi] не спит не один поток.
Получилась конечно тупость.. %) Но.... радной авось лучше!

Просто после исролнения своегохука воставливай первые 5 байт. Возратный адрес меняешь на "hook_reinstall" который хук востановит. Настоящий возратный адрес можно в переменную записать (TLS). У меня так, вообще ничего записовать не надо:

	stdcall [VirtualProtect],[FreeLibrary],5,PAGE_EXECUTE_READWRITE,OFFSET dwOldFlags
	stdcall memcpy,OFFSET FreeLibraryAold,[FreeLibrary],5
	stdcall hook,[FreeLibrary],OFFSET kernel32!FreeLibrary


kernel32!FreeLibrary:
	stdcall [VirtualProtect],[FreeLibrary],5,PAGE_EXECUTE_READWRITE,OFFSET dwOldFlags
	stdcall memcpy,[FreeLibrary],OFFSET FreeLibraryAold,5
	; call
	stdcall [FreeLibrary],[esp+04h]
	push	eax
.quit:	stdcall hook,[FreeLibrary],OFFSET kernel32!FreeLibrary
	pop	eax
	retn	04h

memcpy:
	mov	esi,[esp+08h]
	mov	edi,[esp+04h]
	mov	ecx,[esp+0Ch]
	rep	movsb
	retn	0Ch
hook:
	mov	edx,[esp+04h]
	mov	eax,[esp+08h]
	sub	eax,edx
	sub	eax,5
	mov	byte [edx],0E9h
	mov	[edx+01h],eax
	retn	08h

FreeLibraryAold 	rb	05h

> после исролнения своегохука воставливай первые 5 байт

А вот это зря, туда сюда байты писать плохо.
Лучше учесть это в процедуре хука..

Интересная задача :)

Касательно #1 - я здесь больше имел ввиду - может ли пролог ТАК СИЛЬНО отличаться у одной и той же функции в разных версиях винды.

Может, еще как. Вместо функции может быть либо форвард в другую библиотеку, либо вызов
SetLastError(ERROR_CALL_NOT_IMPLEMENTED), либо еще какая-то фигня (например, вызов int 2e в 2K-системах, и что-нибудь другое в 9x-системах). Так что в идеале желательно (если есть такая возможность) проверить на всех версиях винды.

То гарантировать (опять же кроссплатформенно), что мы не получим потока уснувшего на push ebp нереально. Имхо.
Какие мысли на этот счет?

Есть вот такая мысль: раз ты "усыпил" поток, то можешь получить его контекст и проверить его EIP. Имхо. Если он, гадина, спит как раз там, установить ему флаг трассировки и дать сделать пару шагов вперед :) Помучиться, конечно, придется...

А вот это зря, туда сюда байты писать плохо.
Лучше учесть это в процедуре хука..

почему?

потому, что можешь напоростья на поток, который будет как раз на том участке, куда ты пишешь

comrade

Потому :-)
По словам Four-F драйвера, например, которые чего-то там хучат обычно делают невыгружаемыми, и соответственно хук тоже никогда не снимается, если в этом нет насущной необходимости.
Хукающую процедуру нужно писАть так чтоб она влияла только на то что нужно, а для всего остального была прозрачна, IMHO ;-)

ЗЫ: этот метод хука я собираюсь использовать в своём плагине ;-)

ничё не понимаю...