http://www.wasm.ru/article.php?article=green2red02#_Toc100906478 Там приведён исходный текст функции CheckSumMappedFile, по её завершении в регистре EAX исходная сумма. Слов нет, разобраться непросто, да ни от кого это и не требуется. Просто скажите, кто знает, ошибочный это алгоритм или нет. Но всё же на некоторые э... несоответсвия я не могу не указать. 1) Натыкаемся в исходнике на строку Код (Text): mov ecx,dword ptr [eax].e_lfanew Смотрим в OllyDbg, что бы это значило. Видим Код (Text): MOV ECX,DWORD PTR DS:[EAX+3C] Угу. Смотрим там же значение EAX. Оно равно нулю. То есть процессор должен по считать с адреса 3C число типа DWORD и переслать его в регистр ECX. Всё бы ничего, но программа загружается начиная с адреса 400000, адреса 3C просто нет! Неудивительно поэтому, что в отладчике программа на этом месте стопорится. Ладно, я допускаю мысль, что иногда программа всё же заружается по адресу 0 и исходник писан именно для таких разов. Жму плечами и вручную переписываю (приготовившись отследить все подобные случаи). Получается. Код (Text): MOV ECX,DWORD PTR DS:[400000+3C] Жму на F9 2) Дальше ещё интереснее. Читаем в исходнике Код (Text): add esi, 00000058h mov edx, 00000001h mov eax, dword ptr [esi] ...То есть используется адрес 58. Я бы и здесь заменил его на 400058, но, думаю, дай-ка посмотрю, что по этому адресу находится. Посмотрел. Во всех исполняемых файлах по этому адресу находится такая вот строка Код (Text): am cannot be run in DOS mode Ну, то есть в DOS-MZзаголовках присутствует строка This program cannot be run in DOS mode. И почему-то адрес середины этой строки кладётся в esi, потом в eax и так далее. Я не стал дальше разбираться, какой интерес представляет адрес середины стоки, а решил спросить у вас, что вы знаете про этот исходник и стоит ли его использовать. Спасибо
тема - бред. просто файл не маппируется из-за жеско защитого имени файла в переменной Name1. советую сначала изучить матчасть, в том числе ассемблер, вызовы WinAPI, структуру PE.
А я что по-Вашему делаю, как не изучаю структуру PE? Статья-то как называется? "Формат исполняемого файла ОС Windows. PE32 и PE64" Но как бы то ни было- дело в исходнике, получается? Странно.
Не знаю я. Есть функция, передаём ей параметры, на выходе (в EAX) должны быть искомые данные. Что не так?
amvoz Найди в исходнике строку - Name1 db "C:\\kernel32.dll",0 И замени "C:\\kernel32.dll", на имя файла, сумму которого тебе надо найти.
Для этого файла мне надо найти. kernel32.dll Более того, полезно будет найти сумму именно этого файла, а не какого-нибудь другого. Потому, что она отображается (должна быть корректной, так в той же статье написано) в соответствующем поле опционального заголовка. Я смогу сравнить эти 2 цифры (значение EAX и IMAGE_OPTIONAL_HEADER.CheckSum ) и делать выводы. А если я предложенным Вами способом найду сумму какого-нибудь простенького экзешника... Как я буду знать, что она верна, что я не ошибся, если мне её не с чем сравнить? В соответствующем поле опционального заголовка может быть всё, что угодно. Да так оно и есть, у меня вот нули стоят для некоторых экзешников. Для CRACKME.EXE того же
Да... Моя вина, я не сказал. Я конечно же пути к файлам все свои указываю. Эта замена, про которую Вы говорите, несомненно, произведена. Давно.
Просто скопируй файл kernel32.dll из системного каталога в корневой каталог диска C: И вобще исходник в студию...
Я положил в папку с OllyDbg.exe Зря старался только. Расчётная сумма оказалась равной 4100E8, а в MAGE_OPTIONAL_HEADER.CheckSum одни нули... Зря я пыхтел, получается... Выходит, загрузчик это поле не проверяет... Опять не с чем ни сравнить. Попробую ещё потом функцию, встроенную в Windows... Да там тоже формулировочка, знаете ли "Контрольная сумма образа файла. Для обычных исполняемых файлов контрольная сумма не проверяется, т.е. может быть любой. Если она нулевая, то она тоже может быть любой." Спасибо, что... А исходник вот он, где-то посредине страницы. Там и пояснения к нему. Могу переоформить, кому надо... Он длинный, его трудно не заметить. Называется "Реализация собственной функции CheckSumMappedFile" Там кроме всего прочего нужно свои пути к файлам прописать... Это в инклудах и в библотеках... От зелёного к красному.
amvoz Я говорил про твой исходник, потому что ты 100% там напортачил... Да, и учение матчасти еще никому не повредило...
Я и учу. Начну я того же Крупника учить- нет-нет, да скажет кто-нибудь- изучай формат PE-файлов. Так что я ошибусь в любом случае, с чего бы не начинал. Моего исходника нет. Если моим не считать представленный с такими вот исправлениями: Код (Text): include C:\masm32\include\windows.inc includelib C:\masm32\lib\kernel32.lib include C:\masm32\include\kernel32.inc .data hFile dd 0 hMapping dd 0 hMap dd 0 Name1 db "kernel32.dll",0 HeaderSum dd 0fffh CheckSum dd 0 Я всего-навсего прописал свои абсолютные пути к файлам и изменил NAME 1 Теперь внимание! Вопрос возник другой! Неужели загрузчик и вправду не проверяет это поля и оно вопреки (!) автору может быть любым? Мне это очень странно, думаю и вам тоже. Оно у вас всех должно находиться по адресу 400102, размер DWORD- проверьте, кому интересно, там одни нули! А по автору "Для всех системных DLLдолжна быть корректная" Если бы не этот факт, стал бы я разве возиться? Любая да любая... Любая.
amvoz Не важно загрузчику значение этого поля, его можно смело выставлять в 0. Вот ты сначала пишешь: Потом пишешь: Положить его надо в папку с программой, или прописать абсолютный путь. И смотри, что возвращают API функции. CreateFile должна возвратить хендл файла, если возвращает INVALID_HANDLE_VALUE, значит вызов неудачен. CreateFileMapping должна возвращать отличное от 0 значение. MapViewOfFile должна возвратить указатель на спроецированный файл (по адресу, возвращенному MapViewOfFile должны располагаться байты "MZ"...), если возвращает 0, значит вызов неудачен. Если неудачен вызов любой из этих функций, то бесполезно трассировать дальше...
Всё верно, в папке OllyDbg лежат файлы: OllyDbg.exe kernel32.dll CheckSumMappedFile.exe Возвращаемые значения последовательно: 10, 1С, адрес MZP (410000)... При чём вот что интересно: этот адрес в OllyDbg открывается только по вызову MapViewOfFile! Но я не спрашиваю "Почему?" ибо это выходит за рамки нашей беседы. ...А вообще то, что я нашёл- 4100E8 (якобы найденная контрольная сумма)- бред. Это адрес сигнатуры PE. Но этот адрес содержится в EAX по выходу из CheckSumMappedFile (в этом месте по автору должна быть сумма). Вот в скриншоте всё видно. И где произошла остановка, и что находится в EAX и что находится по адресу, находящемуся в EAX. Потом ещё поразбираюсь. http://rapidshare.ru/916267 Это скриншот. Что-то он большой (3,8 мегабайт) и скачивается долго. Ну, кому интересно, тот посмотрит.
если это так уж важно чтобы проверить работоспособность того исходника, то чексуму можно проверить с помощью PETools.
