Скорее всего этот метод уже бородатый и его все знают, но я его не знал и придумал сам. Даже название придумал Берем exe-шник. Нас интересует скажем с какими параметрами вызывается CreateFileA в этом exe-шнике. Делаем следующее. Пишем dll-ку с названием скажем "kernel33.dll" такого содержания: Код (Text): ... _CreateFileA: jmp [CreateFileA] _CloseHandle: jmp [CloseHandle] ... Тоесть она экспортирует функции с теми же названиями что и системный kernel32.dll, и эти функции заключаются в том, что передают управление системной kernel32.dll. Теперь нас интересует CreateFileA. Вот в метке _CreateFileA мы и сохраняем параметры, а потом передаем управление системной CreateFileA. Так можно отмониторить / обмануть любую функцию. А в exe-шнике kernel32 меняем на kernel33. Теперь в чем проблемма. Вчера столкнулся с пакнутым exe-шникром который еще ко всему и контрольную сумму своего содержания сверяет и поэтому таблицу импорта править не дает. Закинул МОЙ kernel32.dll к нему в директорию. А грузится всеравно системный. Открыл MSDN LoadLibrary. Вот порядок поиска dll при LoadLibrary: 1. The directory from which the application loaded. 2. The current directory. 3. The system directory. 4. и т.д. Значит у загрузки dll из таблицы импорта порядок другой. Вот хотелось бы узнать какой и как в этом случае не трогая exe-шник заставить его загрузить мою dll?
может он базу кернела снимает и потом по эскпорту кернела находит адреса функций,и юзает их. Вот и всё а твой кернел ему побоку Ж))
Я правда сам такое не пробовал, но можно попытаться сделать с помощью двух "Forward DLL". Первую называем kernel32.dll кидаем в папку с прогой и делаем в ней форвардинг на вторую, называющуюся как угодно, но находящуюся в другой папке, а уже из неё вызываем системную.
если ты обзавёшь её kernel32.dll то при загрузки этой длл она то экспортит из ОРИГЕНАЛЬНОЙ kernel32.dll будет опять подгружаться твоя... и тди тп... то бишь не гуд... есть такой способ... при загрузки своей длл ... делаешь следующие.. получаешь путь к папке виндовс .. далее грузишь ЛоадЛайбрари оригенальный кернел... или любую дургую ДЛЛ что ты фейкаешь... далее гет проц адресом берёшь адреса нужных функций и всё... проще всего конечно макрос навоять.... +) а ещё можно внедрить свою длл в процесс и пропатчить таблицу импорта на свою дллку...
Fallout Ты имееш ввиду то, что подмененная kernel32.dll может вызывать свои же функции? Но мне непонятно в чем здесь траблы. А вообще, если какая-нибудь прога пытается посчитать свою контрольную сумму в файле, то можно использовать тот же метод с "kernel33.dll" и изменением импорта, обрабатывая в ней GetCommandLine или какие-нибудь ещё ф-ии отвечающие за получение имени файла, возвращая имя не изменённой копии файла. Однажды я так обманул Штирлица. bober Если не трудно, просвети насчет ключа.
sl0n Со стека чтоли? Если да то тут проблемма... Хотя можно мою Forward DLL поставить на место системной kernel32.dll, а системную уже переименовать. Только тут гемороя много возникнет. Fallout Не парься. У меня в таблице импорта МОЕЙ kernel32.dll написано "C:\WINDOWS\SYSTEM32\Kernel32.dll" bober Как называется?
bober Не этот ли ключ ты имел ввиду "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs". Все таки загрузить свою Kernel32.dll врядли получится, ведь оригинальная грузиться ещё на стадии загрузки системы, а значит виндовос будет отображать в память процесса именно её, а не находящуюся в папке проги.
Я имел ввиду не эту, сейчас немогу посмотреть. Но мысль о том что Kernel32.dll загружается в память практически раньше всех - мне кажется самая правильная. LoadLibrary всегда проверяет если в памяти вновьзагружаемая либа. Корочече два кернела незагрузиш.
Booster А кто занимается тем чтобы загружать dll-ки из таблицы импорта? Если сама kernel32 то тогда врядли получится, а иначе я думаю можно попробовать... Ну хорошо, kernel32 мы не можем. А как насчет остальных? user32, shell32, etc?
Всё правильно. Если либа уже загружена другим процессом, то лоадер подгрузит её из какого-то внутренного кеша. Уже попробовал с user32.dll - та же история. _DEN_ А метод действительно не нов, я о нём уже знал Именно так когда-то хакнул одну программу, защищённую flexlm'ом.
_DEN_ >Вчера столкнулся с пакнутым exe-шникром который еще ко >всему и контрольную сумму своего содержания >сверяет и поэтому таблицу импорта править не дает Если он код в памяти проверяет, вставь в инициализацию своей dll замену измененных байтов на оригинальные, если файл проверяет, то ты же все-равно перехватываешь функции, ну и подмени в какой-нить createfilea путь на копию оригинального файла.
Madness Вот это уже интересная мысль. Надо попробовать. Правда там еще одна проблемма есть. Там часть импорта не видна. Как я понимаю она появляется после распаковки. Quantum Получается тогда надо свою версию винды собирать со всеми отфорварденными системными dll-ками
Лоадер сперва ищет dll в system32 и без оригинального kernel32.dll прога не запустится, вернее запустить код можно (со своим kernel32.dll) если напрячься, но тогда оригинальный не загрузится т.к. его imagebase будет занят (это недопустимо для системных длл)
Так... Предположим ситуацию: exe-шник запакован. Из kernel-а видны только скажем LoadLibrary и GetProcAddress. Остальной импорт идет либо динамически либо... либо как-то еще Насколько я понимаю, если я смогу отфорвардить самый первый кернел, значит по идее я смогу и после распаковки отконтролись весь оставшийся кернел?
_DEN_ >после распаковки отконтролись весь оставшийся кернел? С таким раскладом все можно отфорвадить не напрягаясь. Подсовываешь свой GetProcAddress и меняешь выход на свои адреса
_DEN_ Если я правильно понял, что тебе нужно, то проще всего это делается под 2к и дальше - просто в каталог с файлом.exe кладёшь файл.exe.local с тем же именем. и оно будет грузить сначала dll-ки из каталога программы, а потом уже из системы.
bsl_zcs Не понял про имена? Вот у меня есть: prog.exe Ты предлагаешь переименовать его в prog.exe.local Так он не запускается. Или что ты имел ввиду?
prog.exe.local действительно можно запустить через "start prog.exe.local". Только она всеравно системные dll-ки грузит.