Введение в крэкинг с нуля, используя OllyDbg

[StopFreeLife]

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

Следующим упаковщиком на шкале сложности является aspack, очень похожий на UPX, и для которого у нас есть крэкми UnPackMe_ASPack2.12.exe, использовавшееся в главе 32.

Для практики установим OllyDump в директорию с плагинами, чтобы сделать дамп с его помощью.

Здесь была ссылка, но она устарела. Возможно, поможет вот эта.

Открываем OllyDbg, защищённый плагинами от обнаружения, и находим OEP с помощью метода PUSHAD.

http://www.wasm.ru/pub/23/pic/ollydbg35/1.png


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

http://www.wasm.ru/pub/23/pic/ollydbg35/2.png

Видим начальный PUSHAD, который проходим с помощью F7, а затем делаем
http://www.wasm.ru/pub/23/pic/ollydbg35/3.png

ESP-FOLLOW IN DUMP, чтобы установить в DUMP’е железную (hardware) точку останова на доступ к значениям двух регистров, которые сохраняются инструкцией PUSHAD.

http://www.wasm.ru/pub/23/pic/ollydbg35/4.png

Затем нажимаем F9.

http://www.wasm.ru/pub/23/pic/ollydbg35/5.png

И останавливаемся прямо после POPAD, который восстанавливает сохранённые в эти регистры значения. Трассируем с помощью F7, пока не прибудем в OEP.

http://www.wasm.ru/pub/23/pic/ollydbg35/6.png

Как видим, код был не понят, выходим из анализа.

http://www.wasm.ru/pub/23/pic/ollydbg35/7.png

И видим, что если проанализировать его ещё раз, всё становится гораздо лучше.

http://www.wasm.ru/pub/23/pic/ollydbg35/8.png

Затем приступаем к дампу файла. Идём в меню PLUGINS и ищем там OllyDump.

http://www.wasm.ru/pub/23/pic/ollydbg35/9.png

http://www.wasm.ru/pub/23/pic/ollydbg35/10.png

Нам открывается окно плагина, в котором уже отображено то, что можно модифицировать. Можно исправить базу кода без необходимости потом править её в заголовке. В окне видим, что база кода равна 4000, а если помним, то aspack выполняется не в первой секции, поэтому не меняем это значение, которое соответствует 404000, где находится OEP и выполняется программа.

Ещё одна важная фишка – это опция «REBUILD IMPORT», находящаяся внизу окна. OllyDbg пытается сделать работу IMP REC’а, для чего ему служат METHOD1 и METHOD2, которые могут работать для простых упаковщиков. Вы можете сделать два дампа, используя каждый из этих методов, и посмотреть, работает ли хотя бы один из них. Это не всегда срабатывает, но иногда может.

Мы снимаем галочку с «REBUILD IMPORT», так как мы будем использовать IMP REC для большей надёжности.

http://www.wasm.ru/pub/23/pic/ollydbg35/11.png

[StopFreeLife]

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

http://www.wasm.ru/pub/23/pic/ollydbg35/12.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/13.png

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

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

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

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

http://www.wasm.ru/pub/23/pic/ollydbg35/14.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/16.png

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

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

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

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

http://www.wasm.ru/pub/23/pic/ollydbg35/17.png

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

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

http://www.wasm.ru/pub/23/pic/ollydbg35/18.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/19.png


http://www.wasm.ru/pub/23/pic/ollydbg35/20.png

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

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

http://www.wasm.ru/pub/23/pic/ollydbg35/21.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/22.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/23.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/24.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/25.png

[StopFreeLife]

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

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

http://www.wasm.ru/pub/23/pic/ollydbg35/28.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/29.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/30.png

http://www.wasm.ru/pub/23/pic/ollydbg35/31.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/32.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/33.png

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

OEP=4000 RVA или НАЧАЛО IAT=119C РАЗМЕР = КОНЕЦ МИНУС НАЧАЛО = 401218-40119c = 7C

http://www.wasm.ru/pub/23/pic/ollydbg35/34.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/35.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/36.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/37.png
Видим, что теперь в логе нам говорят, что эти элемент похожи на элементы из kernel32.dll, и пакер может свободно менять их, что всё запутать и усложнить.

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

[StopFreeLife]

http://www.wasm.ru/pub/23/pic/ollydbg35/38.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/39.png

http://www.wasm.ru/pub/23/pic/ollydbg35/40.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/41.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/42.png

http://www.wasm.ru/pub/23/pic/ollydbg35/43.png

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

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

http://www.wasm.ru/pub/23/pic/ollydbg35/44.png

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

http://www.wasm.ru/pub/23/pic/ollydbg35/45.png

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

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

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

[GALIAFF]

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


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

[StopFreeLife]

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

[0x0c0de]

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

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

[GlOFF]

Цикл статей «Введение в крэкинг с нуля, используя OllyDbg» (http://wasm.ru/series.php?sid=17) (Прямая ссылка на wasm.ru)