Win98.. Гружу DLL из EXE.. В DLL определяю адрес функции CreateFileA через GetProcAddress, начинаю просматривать импорт EXE в поисках CreateFileA нахожу, но в таблице импорта EXE'шника адрес функции CreateFileA почему-то отличается от ранее найденного(через GetProcAddress из DLL). Это какие-то особенности win98 или глюки??
Asterix из-за того что в Win9x код kernel32 размещен в shared memory, система не позволяет его дебажить(user mode отладчиком) т.к. установка брейкпоинта повлияла бы на работу других процессов. вставляется специальная debug-прокладка для АПИшных вызовов.
> Ну код самой kernel32.dll никто и не дебажил.. Ты дебажил хост - вот система при запуске его под отладчиком на все АПИ функции в таблице импорта сделала переходники в виде jmp, чтобы в них можно было ССh втыкать для бряков. А GetProcAddress естественно возвращает нормальный адрес в kernel32.dll Типа учите мат. часть =)
> А GetProcAddress естественно возвращает нормальный адрес в kernel32.dll Нормальные адреса в kernel32(в Win98) начинаются с BFF.., ничего подобного GetProcAddress под OllyDbg не возвращает, только под SoftIce всё нормально. А бряки на API OllyDbg под Win98 ставить не даёт, так что..
Этот вопрос уже не раз поднимался, в частности в Is debugger present по таблице импорта и твоем же IsDebuggerPresent в 9x А суть такая: под отладчиком ring3 в таблице импорта вместо реального адреса функции kernel32.CreateFileA стоит адрес такой вот фишки: push kernel32.CreateFileA jmp kernel32.BFF957CA ;переход ес-но относительный rel32 Причем, если мы несколько раз объявим импорт CreateFileA, то на каждое обявление будет своя фишка, а GetProcAddress выдаст указатель на свою фишку, которая не будет совпадать со всеми остальными (все эти фишки сидят по адресам 8хх). Чтобы "выцепить" настоящий адрес CreateFileA под отладчиком нужно взять его из PUSH-а, т.е. если GetProcAddress выдала нам адрес в EAX и он меньше BFF.., значит мы под отладчиком и настоящий адрес будет mov EAX,[EAX+1]
