ANTICHAT — форум по информационной безопасности, OSINT и технологиям

Ок, сейчас сделаем дамп и посмотрим, что из этого выйдет.



Вот дамп, если запустим его без починки IAT, то может запуститься без проблем, но только на моей машине, а может выдать ошибку. Посмотрим.



Ок, не закрывая упакованный архив, который остановлен на точке входа, открываем IMP REC и выбираем вышеуказанный процесс в выпадающем меню.

Возвращаемся в OllyDbg, чтобы найти значения начала IAT, её размера и OEP.

OEP равна 404000, то есть в IMP REC это будет 4000, так как нужно отнять базу образа, равную 400000.

Ищем начало и конец IAT, для этого нам нужно найти вызов какой-нибудь API-функции. Прямо под OEP есть вызов GetModuleHandleA.



Отмечаем данную строку, затем правая кнопка мыши и FOLLOW.



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

Это значит, что здесь используется косвенный вызов для перехода на функцию, поэтому выяснить, откуда считывается адрес API (а он считывается из IAT), легко.

Легко видеть, что 4011F4 – это элемент IAT, где сохраняется адрес API-функции GetModuleHandleA.

Те, кто хочет увидеть косвенные переходы, могут поискать FF 25, чтобы их найти.



И получаем тот же результат, так как JMP к GetModuleHandleA читает значения из того же элемента IAT.

Идём в DUMP, чтобы посмотреть данный элемент в частности и IAT в общем.



Здесь видимо, что все элементы соответствующие тем, что мы видели в начале, все идут в секцию кода той же DLL. Посмотрим с помощью VIEW-M, какой DLL они соответствуют.






Все находятся внутри указанной секции, поэтому видим, что эти элементы, относящиеся к Kernel32.dll, указывают на секцию CODE.

Здесь же можем посмотреть конец IAT. Снизу от 401218 особенно ничего нет, так что конец IAT – это 401218, и теперь нам осталось найти начало.



Видим разделяющие нули, а после них другую группу элементов.



Которые точно являются элементами, смотрим адреса, куда на которые они указывают (10xx или 11xx), Это не DLL, ни что-нибудь ещё, так как самый нижний адрес в карте памяти – это 10000.



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



Видим, что среди нулей есть другая группа элементов, указывающих на адреса 77Dxxxxx. Смотрим в карте памяти, какой DLL они соответствуют.

Видим, что есть вызовы 3-х DLL, две из них – те, которые мы нашли, и другая – это Ntdll. Смотрим.

Если, например, перейдём к вызовам этой DLL.



Видим, что соответствующий элемент находится в 401200, то есть это смешение (mezclada – чего-то я не совсем понял, о чём он толкует, кто понял – отпишитесь – прим. пер.) с kernel32.dll.



То же самое относится и к другой из указанных DLL, которая смешана с kernel32.dll. Мы не заметили, что эти две секции кода находятся рядом друг с другом, но это так.





Ок, посмотрим какие проблемы могут быть из-за подобного начала IAT. Вот все эти элементы:



Начала IAT находится в 40119C, которое совпадает с меньшим значением, найденным в таблице переходов.



Видим, что оно самое маленькое из всех этих значений, так что у нас получается:



Задаём эти значения в IMP REC, чтобы посмотреть, что получится, видим, что оба смешанных элемента относятся к ntdll и kernel32.



Видим, что указанная часть не та, которая соответствует мусорным элементам, и внизу видим, что у нас есть только элементы для kernel32, и если посмотрим редко встречающиеся элементы, соответствующие 401200 b 401210, то увидим, что:



Заменяем его на похожие элементы, соответствующие kernel32.dll, и что это будет означать?


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

Хорошо, теперь нам осталось убрать мусор из середины. Проверяем эти элементы и смотрим, если написано NO, то это мусор. Чтобы убедиться в этом, идём к одному из них.

Отмечаем первый, нажимаем правую кнопку мыши и выбираем DISASSEMBLE-HEX VIEW.





Здесь видим, что это не приводит нас к реально существующему месту, так что отмечаем все элементы как мусор.



Нажимаем SHOW INVALID, а затем, держа все эти элементы отмеченными, нажимаем на правую кнопку мыши и выбираем CUT THUNKS.





Таким образом мы аннулировали все эти неверные элементы, чтобы система при загрузке не выдавала ошибку, пытаясь загрузить несуществующие API-функции.

Теперь можно нажать FIX DUMP, так как все элементы отмечены как YES, то есть как правильные.



И создаётся dumpaspack_.exe, файл, который предположительно должен быть починен, запускаем и смотрим, так ли это.



Работает превосходно!!!

[C] Рикардо Нарваха, пер. Aquila

P.S. Поделил на несколько сообщений потому что форум не принимает так много картинок в одном сообщении.

Зачем ты это скопипастил?


0x0c0de: свою критику формулируйте более развернуто в следующий раз и без нецензурной лексики (или юзайте ***, если не можете свою мысль выразить без нелитературных форм языка). [мат из сообщения удален]

1. следи за лексикой
2. Для продвижения форума и людей которые єто прочитают,потому что 90% сайта не видели и не знаю єтого и не найдут. А авторство и другое я указал.

Думаю, копировать статьи с васма нецелесообразно. Эта серия в подветке уже упоминалась, поэтому посетители в курсе (я полагаю, GALIAFF именно это хотел сказать). Постить копии статей дальше не стоит.

Спасибо за внимание.

Цикл статей «Введение в крэкинг с нуля, используя OllyDbg» (Прямая ссылка на wasm.ru)