И это при том, что не требуется помнить код команды MOV! (Хотя это очень распространенная команда и запомнить ее код все же не помешает).
Вызов 21-го прерывания 0CDh 21h легко отыскать, если запомнить его символьное представление '=!' в правом окне дампа. Как нетрудно видеть, следующий вызов INT21h лежит чуть правее по адресу 0Ch. При этом DX указывает на 0156h. Это соответствует смещению 056h в файле. Наверняка эта функция читает пароль. Что ж, уже теплее. Остается выяснить, кто и как к нему обращается. Ждать придется недолго.
При разборе байта 0Eh не забудьте, что адресации [BР] не существует в природе. Вместо этого мы получим [offset16]. На размер регистра и приемник результата указывают два младших бита байта 08Ah. Они равны 10b. Следовательно, мы имеем дело с регистром CL, в который записывается содержимое ячейки [0156h].
Все, знакомые с ассемблером усмотрят в этом действии загрузку длины пароля (первый байт строки) в счетчик. Неплохо для начала? Мы уже дизассемблировали часть файла и при этом нам не потребовалось знание ни одного кода операции, за исключением, быть может, 0CDh, соответствующего команде 'INT.
Вряд ли мы скажем, о чем говорит код 087h. (Впрочем, обращая внимание на его близость к операции NOP, являющейся псевдонимом 'XCHGAX,AX', можно догадаться, что 087h — это код операции XCHG). Обратим внимание на связанный с ним байт 0F2h:
Как не трудно догадаться, эта команда заносит в SI смещение пароля, содержащиеся в DX. Этот вывод мы делаем, только исходя из смыслового значения регистров, полностью игнорируя код команды. К сожалению, этого нельзя сказать о следующем байте — 0ACh. Это код операции LODSB, и его придется просто запомнить.
0x02 — это код ADD, а следующий за ним байт — это AH,AL(не буду больше повторять, как это было получено).
0xE2 — это код операции LOOP, а следующий за ним байт — это знаковое относительное смещение перехода.
Чтобы превратить его в знаковое целое, необходимо дополнить его до нуля, (операция NEG, которую большинство калькуляторов не поддерживают). Тот же самый результат мы получим, если отнимем от 0100h указанное значение (в том случае, если разговор идет о байте). В нашем примере это равно пяти. Отсчитаем пять байт влево от начала следующей команды. Если все сделать правильно, то вычисленный переход должен указывать на байт 0ACh (команда LODSB), впрочем, последнее было ясно и без вычислений, ибо других вариантов, по-видимому, не существует.
Почему? Да просто данная процедура подсчета контрольной суммы (или точнее хеш-суммы) очень типична. Впрочем, не стоит всегда полагаться на свою интуицию и «угадывать» код, хотя это все же сильно ускоряет анализ.
С другой стороны, хакер без интуиции — это не хакер. Давайте применим нашу интуицию, чтобы «вычислить», что представляет собой код следующей команды. Вспомним, что 0B4h (10110100b) — это MOV AH,imm8.
0BEh очень близко к этому значению, следовательно, это операция MOV. Осталось определить регистр-приемник. Рассмотрим обе команды в двоичном виде:
Как уже говорилось выше, младшие три бита — это код регистра. Однако, его невозможно однозначно определить без утончения размера операнда. Обратим внимание на третий (считая от нуля) бит. Он равен нулю для AH и единице в нашем случае. Рискнем предположить, что это и есть бит размера операнда, хотя этого явно и не уточняет Intel, но вытекает из самой архитектуры команд и устройства декодера микропроцессора.
Обратим внимание, что это, строго говоря, частный случай, и все могло оказаться иначе. Так, например, четвертый справа бит по аналогии должен быть флагом направления или знакового расширения, но увы — таковым в данном случае не является. Четыре левые бита это код операции 'mov reg,imm'. Запомнить его легко — это «13» в восьмеричном представлении.
Итак, 0BEh 03Bh 001h — это MOV SI,013Bh. Скорее всего, 013bh — это смещение, и за этой командой последует расшифровщик очередного фрагмента кода. А может быть и нет — это действительно смелое предположение. Однако, байты 030h 024h это подтверждают. Хакеры обычно так часто сталкиваются с функций xor, что чисто механически запоминают значение ее кода.
Не трудно будет установить, что эта последовательность дизассемблируется как XOR [SI],AH. Следующий байт 046h уже нетрудно «угадать» — INC SI. Кстати, посмотрим, что же интересного в этом коде:
Третий бит равен нулю! Выходит команда должна выглядеть как INC AH! (Что кстати, выглядит непротиворечиво смысле дешифровщика). Однако, все же это INC SI. Почему мы решили, что третий бит — флаг размера? Ведь Intel этого никак не гарантировала! А команда 'INC byte' вообще выражается через дополнительный код, что на байт длиннее.
Выходит, что как ни полезно знать архитектуру инструкций, все же таблицу кодов команд хотя бы местами надо просто выучить. Иначе можно впасть в глубокое заблуждение и совершить грубые ошибки. Хотя с другой стороны, знание архитектуры порой очень и очень помогает.
Kris
