Особенности дизассемблирования под LINUX на примере tiny-crackme
Исследование tiny-crackme извне и изнутри - часть 6
LOAD:002002F0 sub_2002F0 proc near ; CODE XREF: start:loc_200046^p
LOAD:002002F0 jmp near ptr 202077E1h ; угробленная команда
LOAD:002002F1 in al, dx ; угробленная команда
Листинг 6 процедура расшифровки, пожирающая сама себя
Теперь, когда весь код расшифрован, мы можем продолжить его анализ. Возвращаемся к месту вызова процедуры расшифровщика call sub_2002F0, расположенной по адресу 00200046h. Мы видим полную фигню:
LOAD:00200046 call sub_2002F0 ; процедура расшифровки
LOAD:0020004B B8 mov eax, 20019Eh ; заслать в eax число 20019Eh
LOAD:0020004C 9E 01 sahf ; \
LOAD:0020004E 20 and [eax], al ; + - бессмысленный мусор
LOAD:0020004F 00 add [ebx+0F4h], bh ; /
Листинг 7 внешний вид дизассемблера после распаковки
Код выглядит полной бессмыслицей. Какие тут еще sahf, and и add? Но это еще что! Присмотревшись повнимательнее (Options-> Text representation -> Number of opcode bytes - >4), мы обнаруживаем, инструкции MOV EAX,2019Eh соответствует… однобайтовый код B8h (во всяком случае, IDA Pro уверяет нас так), чего никак не может быть! В действительности, это всего лишь багофича ИДЫ, не обновившей дизассемблерный листинг после расшифровки. Подгоняем курсор к строке 20004Bh и нажимаем <U>, чтобы перевести его в неопределенную (undefined) форму. Тоже самое необходимо проделать и с массивом байт, начинающимся со строки 00200053h (см. листинг 4). Но это еще не все! Ведь после расшифровки этот массив стал частью нашей процедуры, а IDA ошибочно оборвала функцию на адресе 200050h, влепив сюда "endp" (end of procedure). Чтобы восстановить статус-кво, необходимо подогнать курсор к концу массива и нажать <E> (Edit->Functions->Set Function End). После этого можно вернуться в начало строки 20004Bh и нажать "C", чтобы превратить неопределенные байты в CODE.
