Тонкости дизассемблирования - Kris Kaspersky

Kris Kaspersky

Тонкости дизассемблирования

ДИЗАССЕМБЛИРОВАНИЕ В УМЕ

Мне известны политические аргументы,

Но меня интересуют человеческие доводы.

Очень часто под рукой не оказывается ни отладчика, ни дизассемблера, ни даже компилятора, чтобы набросать хотя бы примитивный трассировщик. Разумеется, что говорить о взломе современных защитных механизмов в таких условиях просто смешно, но что делать если жизнь заставляет?

Предположим, что у нас есть простейший шестнадцатеричный редактор, вроде того, который встроен в DN и, если очень повезет, то debug.com, входящий в поставку Windows и часто остающийся не удаленным владельцами машины. Вот этим-то мы и воспользуемся. Сразу оговорюсь, что все описанное ниже требует для своего понимания значительного упорства, однако, открывает большие практические возможности. Вы сможете, например, поставить на диск парольную защиту, зашифровать несколько секторов, внести вирус или разрушающую программу и все это с помощью «подручных» средств, которые наверняка окажутся в вашем распоряжении.

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

Поэтому все нижеописанное разрешается проделывать только над своим собственным компьютером или с разрешения его владельца. Если вы соглашаетесь с данными требованиями, то приступим.

СТРУКТУРА КОМАНД INTEL 80x86

Потому ты и опасен, что овладел своими страстями…

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

Для начала разберемся с форматом инструкций архитектуры Intel (рис. 1).

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

Само поле кода занимает восемь бит и часто (но не всегда) имеет следующий формат (рис. 2):

Поле размера равно нулю, если операнды имеют размер один байт. Единичное значение указывает на слово (двойное слово в 32-битном или с префиксом 0х66 в 16-битном режиме).

Направление обозначает операнд-приемник. Нулевое значение присваивает результат правому операнду, а единица левому. Рассмотрим это на примере инструкции mov bx,dx:

Если теперь флаг направления установить в единицу, то произойдет следующие:

Не правда ли, как по мановению волшебной палочки мы можем поменять местами операнды, изменив всего один бит? Однако, давайте задумаемся, как это поле будет вести себя, когда один из операндов непосредственное значение? Разумеется, что оно не может быть приемником и независимо от содержимого этого бита будет только источником. Инженеры Intel учили такую ситуацию и нашли оригинальное применение, часто экономящее в лучшем случае целых три байта. Рассмотрим ситуацию, когда операнду размером слово или двойное слово присваивается непосредственное значение по модулю меньшее 0100h. Ясно, что значащим является только младший байт, а стоящие слева нули по правилам математики можно отбросить. Но попробуйте объяснить это процессору! Потребуется пожертвовать хотя бы одним битом, что бы указать ему на такую ситуацию. Вот для этого и используется бит направления. Рассмотрим следующую команду:

Таким образом, мы экономим один байт в 16-разрядном режиме и целых три — в 32-разрядом. Этот факт следует учитывать при написании самомодифицирующегося кода. Большинство ассемблеров генерируют второй (оптимизированный) вариант, и длина команды оказывается меньше ожидаемой. На этом, кстати, основан очень любопытный прием против отладчиков. Посмотрите на следующий пример:

То есть, текущая команда станет на байт короче! И «отрезанный» ноль теперь стал частью другой команды! Но при выполнении на «живом» процессоре такое не произойдет, т.к. следующие значение iр вычисляется еще до выполнения команды на стадии ее декодирования.

Совсем другое дело отладчики, и особенно отладчики-эмуляторы, которые часто вычисляют значение iр после выполнения команды (это легче запрограммировать). В результате чего наступает крах. Маленькая тонкость — до или после оказалась роковой, и вот вам в подтверждение дамп экрана:

Заметим, что этот прием может быть бессилен против трассирующих отладчиков (debug.com, DeGlucker, Cuр386), поскольку значение iр за них вычисляет процессор и делает это правильно.

Однако, на «обычные» отладчики управа всегда найдется (см. соответствующую главу), а с эмуляционными справиться гораздо труднее, и приведенный пример один из немногих, способных возыметь действие на виртуальный процессор.

Перейдем теперь к рассмотрению префиксов. Они делятся на четыре группы:

блокировки и повторения:

Если используется более одного префикса из той же самой группы, то действие команды не определено и по-разному реализовано на разных типах процессоров.

Префикс переопределения размера операндов используется в 16-разрядном режиме для манипуляции с 32-битными операндами и наоборот. При этом он может стоять перед любой командой, например 0x66:CLIбудет работать! А почему бы и нет? Интересно, но отладчики этого не учитывают и отказываются работать. То же относиться и к дизассемблерам, к примеру IDA Pro:

На этом же основан один очень любопытный прием противодействия отладчикам, в том числе и знаменитому отладчику-эмулятору cuр386. Рассмотрим, как работает конструкция 0x66:RETN. Казалось бы, раз команда RETN не имеет операндов, то префикс 0x66 можно просто игнорировать. Но, на самом деле, все не так просто. RETN работает с неявным операндом-регистром iр/eiр. Именно его и изменяет префикс. Разумеется, в реальном и 16-разрядном режиме указатель команд всегда обрезается до 16 бит, и поэтому, на первый взгляд, возврат сработает корректно. Но стек-то окажется несбалансированным! Из него вместе одного слова взяли целых два! Так нетрудно получить и исключение 0Ch — исчерпание стека. Попробуйте отладить чем-нибудь пример crack1E.com — даже cuр386 во всех режимах откажется это сделать, а Turbo-Debuger вообще зависнет! IDA Pro не сможет отследить стек, а вместе с ним все локальные переменные.

Любопытно, какой простой, но какой надежный прием. Впрочем, следует признать, что перехват INT0Chпод операционной системой windows бесполезен, и, не смотря на все ухищрения, приложение, породившие такое исключение, будет безжалостно закрыто. Однако, в реальном режиме это работает превосходно. Попробуйте убедиться в этом на примере crack1E.com. Забавно наблюдать реакцию различных эмулирующих отладчиков на него. Все они либо неправильно работают (выбирают одно слово из стека, а не два), либо совершают очень далекий переход по 32-битному eiр (в результате чего виснут), либо, чаще всего, просто аварийно прекращают работу по исключению 0Ch (так ведет себя cuр386).

Еще интереснее получится, если попытаться исполнить в 16-разрядном сегменте команду CALL. Если адрес перехода лежит в пределах сегмента, то ничего необычно ожидать не приходится. Инструкция работает нормально. Все чудеса начинаются, когда адрес выходит за эти границы. В защищенном 16-разрядном режиме при уровне привилегий CL0 с большой вероятностью регистр EIР «обрежется» до шестнадцати бит, и инструкция сработает (но, похоже, что не на всех процессорах). Если уровень не CL0, то генерируется исключение защиты 0Dh. В реальном же режиме эта инструкция может вести себя непредсказуемо. Хотя в общем случае должно генерироваться прерывание INT0Dh. В реальном режиме его нетрудно перехватить и совершить дальний 'far' переход в требуемый сегмент. Так поступает, например, моя собственная операционная система OS7R, дающая в реальном режиме плоскую (flat) модель памяти. Разумеется, такой поворот событий не может пережить ни один отладчик. Ни трассировщики реального режима, ни v86, ни protect-mode debugger, и даже эмуляторы (ну, во всяком случае, из тех, что мне известны) с этим справиться не в состоянии.