Справедливо будет сказать, что в большинстве отраслей наиболее известным применением обратной разработки является создание конкурирующих продуктов. Любопытно, что в программной индустрии она далеко не настолько распространена, как можно было бы ожидать. Причин тому несколько, но главная состоит в чрезвычайной сложности программного обеспечения: во многих случаях обратная разработка в конкурентных целях считается настолько трудоёмкой, что просто не имеет финансового смысла.

Для чего же обратную разработку обычно применяют в мире программного обеспечения? В целом её применения делятся на две категории: связанные с безопасностью и связанные с разработкой программ. В следующих разделах представлены разные варианты реверсинга из обеих категорий.

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

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

Чтобы стать опытным специалистом по обратной разработке, необходимо приобрести основательное понимание низкоуровневого программного обеспечения и низкоуровневого программирования. Дело в том, что при реверсинге низкоуровневые особенности программы нередко остаются единственным доступным материалом: высокоуровневые подробности почти всегда удаляются до поставки программы клиентам. Для настоящего мастерства понимание низкоуровневого программного обеспечения и различных принципов программной инженерии столь же важно, как владение самими методами реверсинга.

Один из ключевых принципов обратной разработки, который далее в книге проявится со всей болезненной ясностью, состоит в том, что такие инструменты, как дизассемблеры и декомпиляторы, никогда не дают готовых ответов. Они лишь представляют сведения. Извлекать из этих сведений смысл в конечном счёте всегда приходится самому исследователю. Чтобы успешно получать информацию в ходе реверсинга, необходимо понимать разные стороны низкоуровневого программного обеспечения.

Так что же именно относится к низкоуровневому программному обеспечению? Компьютеры и программы построены из множества наложенных друг на друга слоёв. На самом нижнем находятся миллионы микроскопических транзисторов, пульсирующих с непостижимой скоростью. На верхнем - изящная графика, клавиатура и мышь, то есть всё, с чем взаимодействует пользователь. Большинство разработчиков применяет языки высокого уровня с легко понятными командами, которые затем исполняются. Например, команды создания окна, загрузки веб-страницы или вывода изображения являются чрезвычайно высокоуровневыми: в нижележащих слоях они превращаются в тысячи или даже миллионы команд.

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

Язык ассемблера занимает самый нижний уровень в программной цепочке, а потому исключительно хорошо подходит для реверсинга: ничто не происходит без его участия. Если программа выполняет операцию, та обязательно должна быть видна в коде на языке ассемблера. Язык ассемблера - это язык обратной разработки. Чтобы овладеть миром реверсинга, необходимо хорошо понимать язык ассемблера выбранной платформы. Отсюда следует самый основной факт, который нужно помнить: язык ассемблера представляет собой класс языков, а не один язык. У каждой компьютерной платформы есть собственный язык ассемблера, обычно заметно отличающийся от всех остальных.

Стоит сразу разобраться и с другим важным понятием - машинным кодом, который часто называют двоичным или объектным кодом. Иногда ошибочно полагают, будто машинный код «быстрее» языка ассемблера или находится на «более низком уровне». Это заблуждение: машинный код и язык ассемблера являются двумя разными представлениями одного и того же. Центральный процессор читает машинный код, представляющий собой не что иное, как последовательности битов со списком предназначенных для процессора инструкций. Язык ассемблера - всего лишь текстовое представление этих битов: элементам последовательностей кода дают имена, чтобы сделать их понятными человеку. Вместо загадочных шестнадцатеричных чисел можно видеть текстовые названия инструкций, например MOV (переместить), XCHG (обменять) и другие.

Каждая команда языка ассемблера представлена числом, называемым кодом операции, или опкодом. По существу, объектный код является последовательностью опкодов и других чисел, используемых вместе с ними для выполнения операций. Центральный процессор постоянно читает объектный код из памяти, декодирует его и действует в соответствии с содержащимися в нём инструкциями. Когда разработчики пишут код на языке ассемблера, что в наши дни случается довольно редко, они используют программу-ассемблер для преобразования текстового ассемблерного кода в двоичный, который способен декодировать процессор. В обратном направлении, более важном для нашего рассказа, действует дизассемблер. Он читает объектный код и создаёт текстовое отображение каждой содержащейся в нём инструкции. Это сравнительно простая операция, поскольку текст на языке ассемблера представляет собой лишь иную форму объектного кода. Дизассемблеры относятся к ключевым инструментам обратной разработки и подробнее рассматриваются далее в этой главе.

Поскольку язык ассемблера зависит от платформы, для его изучения и практики реверсинга нам необходимо сосредоточиться на какой-то одной платформе. Я выбрал архитектуру Intel IA-32, лежащую в основе каждого 32-разрядного персонального компьютера. С учётом популярности таких компьютеров и самой архитектуры выбор очевиден. IA-32 относится к самым распространённым процессорным архитектурам мира. Если вы собираетесь изучать обратную разработку и язык ассемблера, но не отдаёте предпочтения конкретной платформе, выбирайте IA-32. Архитектура и язык ассемблера процессоров на базе IA-32 представлены в главе 2.

Если центральный процессор способен выполнять лишь машинный код, каким же образом в него превращаются популярные языки программирования, например C++ и Java? Текстовый файл с инструкциями, описывающими программу на языке высокого уровня, передаётся компилятору. Компилятор - это программа, которая принимает исходный файл и создаёт соответствующий файл машинного кода. В зависимости от языка высокого уровня этот машинный код может быть обычным объектным кодом для конкретной платформы, непосредственно декодируемым центральным процессором, либо записываться в особом, не зависящем от платформы формате, который называется байт-кодом и рассматривается в следующем разделе.

Компиляторы традиционных языков программирования, не основанных на байт-коде, таких как C и C++, непосредственно создают из текстового исходного кода пригодный для процессора объектный код. Это означает, что полученный объектный код после преобразования дизассемблером в язык ассемблера, по существу, оказывается машинно-сгенерированной ассемблерной программой. Разумеется, он создан машиной не полностью, ведь разработчик на языке высокого уровня описал компилятору, что требуется сделать. Но подробности выполнения задачи в полученном объектном коде определяет компилятор. Это важно, поскольку такой код не всегда легко понять даже по сравнению с ассемблерной программой, написанной человеком: машины мыслят иначе, чем люди.

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

Значительная часть книги посвящена искусству расшифровки машинно-сгенерированного ассемблерного кода. В главе 2 мы изучим некоторые основы работы компиляторов, а затем перейдём к конкретным методам извлечения осмысленных сведений из созданного ими кода.

Компиляторы языков высокого уровня, например Java, создают не объектный, а байт-код. Байт-код похож на объектный, но обычно декодируется программой, а не центральным процессором. Идея состоит в том, чтобы компилятор создавал байт-код, после чего программа, называемая виртуальной машиной, декодировала его и выполняла описанные в нём операции. Разумеется, на каком-то этапе сама виртуальная машина должна преобразовать байт-код в обычный объектный код, совместимый с нижележащим процессором.

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

Эта книга главным образом посвящена обратной разработке обычных исполняемых программ, созданных компиляторами в машинный код целевой платформы. Исследование программ, написанных на языках с байт-кодом, представляет собой совершенно иной процесс, который зачастую намного проще обратной разработки обычных исполняемых файлов. Глава 12 посвящена методам реверсинга программ для платформы Microsoft .NET, где применяются виртуальная машина и низкоуровневый язык байт-кода.

Операционная система - это программа, управляющая компьютером, включая оборудование и прикладное программное обеспечение. Она решает множество различных задач, и её можно считать своего рода координатором между разными элементами компьютера. Операционная система является настолько важной частью компьютера, что любой специалист по обратной разработке должен хорошо понимать её назначение и принципы работы. Как мы увидим далее, многие методы реверсинга строятся вокруг операционной системы, поскольку она играет роль привратника, управляющего связью между приложениями и внешним миром. Глава 3 знакомит с архитектурой и внутренним устройством современных операционных систем и показывает их связь с методами обратной разработки.

С чего начинать реверсинг? Существует множество действенных подходов, и на протяжении книги я постараюсь рассмотреть как можно больше. Для начала я обычно разделяю сеанс обратной разработки на два самостоятельных этапа. Первый, который представляет собой своего рода крупномасштабное наблюдение за исследуемой программой, называется реверсингом на уровне системы. Методы системного уровня помогают определить общую структуру программы, а иногда даже найти интересующие области внутри неё. Получив общее представление об устройстве программы и определив участки, заслуживающие особого внимания, можно переходить к более глубокому исследованию методами реверсинга на уровне кода. Они дают подробные сведения о выбранном фрагменте кода. В следующих разделах описаны оба подхода.

Реверсинг на уровне системы предполагает запуск различных инструментов и использование служб операционной системы для получения сведений, исследования исполняемых файлов, отслеживания ввода и вывода программы и решения других подобных задач. Большая часть этих сведений поступает от операционной системы, поскольку по определению любое взаимодействие программы с внешним миром должно проходить через неё. Именно поэтому исследователю необходимо понимать операционные системы: во время сеанса реверсинга с их помощью можно получить богатейшие сведения об изучаемой целевой программе. Основы операционных систем будут рассмотрены в главе 3, а распространённые инструменты реверсинга на системном уровне - в главе 4.

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

Прежде чем переходить к практическим методам, необходимо познакомиться с некоторыми основами программной инженерии. При реверсинге на уровне кода программа рассматривается с очень низкого уровня, и мы будем видеть каждую мельчайшую подробность её работы. Многие такие детали автоматически создаются компилятором, а не пишутся разработчиком вручную, поэтому их связь с программой и её функциями иногда трудно понять. Именно по этой причине обратная разработка требует глубокого знания низкоуровневых аспектов программного обеспечения, в том числе связи между высокоуровневыми и низкоуровневыми программными конструкциями, языка ассемблера и внутренней работы компиляторов. Эти темы рассматриваются в главе 2.

Реверсинг неразрывно связан с инструментами. В следующих разделах описаны основные категории средств, используемых в обратной разработке. Многие из них не создавались специально для реверсинга, но всё же могут оказаться весьма полезными. В главе 4 подробно рассматриваются разные виды инструментов и представлены конкретные средства, которые будут применяться на протяжении книги. А пока кратко познакомимся с тем, с чем вам предстоит работать.

Для реверсинга на уровне системы требуется множество инструментов, которые перехватывают данные, ведут наблюдение, исследуют и иными способами раскрывают работу изучаемой программы. Большинство таких средств показывает сведения, собранные операционной системой о приложении и его окружении. Поскольку почти всё взаимодействие между программой и внешним миром проходит через операционную систему, её обычно можно использовать для извлечения соответствующих данных. Средства наблюдения за системой способны отслеживать сетевую активность, обращения к файлам и реестру и многое другое. Существуют также инструменты, показывающие, как программа использует объекты операционной системы, например мьютексы, каналы и события. Многие из этих средств рассматриваются в главе 4 и далее в книге.

Как уже говорилось, дизассемблеры - это программы, которые получают на вход исполняемый двоичный файл и создают текстовые файлы с кодом на языке ассемблера для всей программы или её частей. Процесс сравнительно прост, поскольку ассемблерный код представляет собой всего лишь текстовое отображение объектного кода. Дизассемблирование зависит от процессора, однако некоторые дизассемблеры поддерживают несколько процессорных архитектур. Качественный дизассемблер является важнейшей частью набора инструментов исследователя, хотя некоторые специалисты предпочитают пользоваться лишь встроенными дизассемблерами определённых низкоуровневых отладчиков, описанных далее.

Если вы занимались хотя бы простейшей разработкой программ, то почти наверняка пользовались отладчиком. В основе отладки лежит мысль о том, что программист не способен заранее представить абсолютно всё, что может сделать его программа. Обычно программы слишком сложны, чтобы человек мог предсказать каждый возможный исход. Отладчик позволяет разработчику наблюдать за программой во время её работы. Две самые основные возможности отладчика - установка точек останова и пошаговое выполнение кода.

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

Отладчики дают возможность пошагово проходить работающую программу; это также называют выполнением по одной инструкции. При таком прохождении программа исполняет одну строку кода и замирает, позволяя пользователю изучить или даже изменить её состояние. Затем пользователь может выполнить следующую строку и повторить процесс. Так разработчик видит точный ход программы в темпе, более подходящем для человеческого восприятия, то есть примерно в миллиард раз медленнее обычной скорости её работы.

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

Для специалиста по обратной разработке отладчик почти столь же важен, как для разработчика программы, хотя причины несколько отличаются. Прежде всего исследователи используют отладчики в режиме дизассемблирования. В этом режиме встроенный дизассемблер на лету преобразует объектный код в ассемблерный. Исследователь может выполнять дизассемблированный код по шагам и, по существу, «наблюдать» за центральным процессором, пока тот исполняет программу по одной инструкции. Как и при отладке исходного кода, исследователь способен устанавливать точки останова в интересующих местах дизассемблированного кода, а затем изучать состояние программы. Для некоторых задач обратной разработки вам потребуется только хороший отладчик с качественным встроенным дизассемблером. Возможность проходить код по шагам и наблюдать за его выполнением - поистине бесценная часть процесса реверсинга.

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

Правовые споры вокруг обратной разработки продолжаются много лет. Обычно в их центре находится вопрос о том, какое общественное и экономическое влияние она оказывает на общество в целом. Разумеется, оценка такого влияния во многом зависит от того, для чего применяется обратная разработка. В следующих разделах рассмотрены правовые стороны разных вариантов её использования с особым вниманием к Соединённым Штатам.

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

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

Программная платформа - это любая программа или аппаратное устройство, поверх которых могут работать другие программы. Например, программными платформами являются и Microsoft Windows, и Sony PlayStation. Для разработчика платформы решение о публикации сведений о её программных интерфейсах имеет критическое значение. С одной стороны, открытые интерфейсы позволят другим разработчикам создавать программы, работающие на этой платформе. Это может повысить продажи платформы, однако поставщик, возможно, предлагает и собственные приложения для неё. Публикация интерфейсов тем самым создаст новых конкурентов собственным приложениям поставщика. Разные правовые нормы, влияющие на такую обратную разработку, в том числе авторское право, охрана коммерческой тайны и патенты, рассматриваются в следующих разделах.

Когда обратная разработка применяется ради совместимости, она явно приносит пользу обществу, поскольку упрощает или делает возможным создание новых и усовершенствованных технологий. При использовании обратной разработки для создания конкурирующих продуктов положение несколько сложнее. Её противники обычно утверждают, что реверсинг препятствует новаторству: у создателей новых технологий остаётся мало стимулов вкладываться в исследования и разработку, если конкуренты могут легко «украсть» их технологии посредством обратной разработки. Это подводит нас к вопросу о том, что именно следует считать реверсингом с целью создания конкурирующего продукта.

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

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

Законы об авторском праве предназначены для защиты программного обеспечения и другой интеллектуальной собственности от любого несанкционированного копирования и подобных действий. Самый наглядный пример влияния авторского права на обратную разработку - создание конкурирующего программного обеспечения. Как отмечалось выше, в программной сфере граница между прямым похищением кода конкурента и его самостоятельной повторной реализацией очень тонка. Непосредственное копирование защищённых последовательностей кода из продукта конкурента в собственный продукт обычно считается нарушением авторского права, однако существует немало гораздо менее определённых случаев.

Как авторское право влияет на обратную разработку кода конкурента с целью заново реализовать его в собственном продукте? В прошлом противники реверсинга утверждали, что такой процесс нарушает авторское право из-за создания промежуточных копий. Рассмотрим в качестве примера декомпиляцию программы. Чтобы декомпилировать программу, её необходимо хотя бы один раз скопировать в память, на диск или в оба места. Согласно этому доводу, даже если сама декомпиляция законна, промежуточное копирование нарушает авторское право. Однако суды это утверждение не поддержали. В нескольких делах, включая Sega против Accolade и Sony против Connectix, промежуточное копирование было признано добросовестным использованием прежде всего потому, что итоговый продукт не содержал ничего непосредственно скопированного из первоначального.

С технической точки зрения это совершенно логично: промежуточные копии всегда создаются при использовании программы независимо от обратной разработки. Вспомните, что происходит при установке программы с оптического носителя, например DVD-ROM, на жёсткий диск: создаётся копия программного обеспечения. То же повторяется при запуске программы: исполняемый файл с диска копируется в память, чтобы его код мог выполняться.

При создании новой технологии разработчик обычно выбирает один из двух основных способов защиты её уникальных особенностей. Иногда правильным решением становится патент. Преимущество патентования состоит в том, что изобретатель или владелец патента получает контроль над изобретением на срок почти до двадцати лет. Главные условия для изобретателя заключаются в необходимости опубликовать подробности изобретения и в том, что после окончания срока патента оно, по существу, переходит в общественное достояние. Разумеется, обратная разработка запатентованных технологий не имеет смысла, поскольку сведения о них и так общедоступны.

Новая технология, которая не была запатентована, автоматически получает правовую охрану как коммерческая тайна, если в её разработку и сохранение конфиденциальности вложены значительные усилия. Закон защищает разработчика коммерческой тайны от случаев её «неправомерного присвоения», например от продажи секрета конкуренту недобросовестным сотрудником. Однако статус коммерческой тайны не защищает владельца продукта, если конкурент исследует этот продукт методами обратной разработки при условии, что продукт продаётся на открытом рынке и приобретён законным способом. Коммерческая тайна также не даёт защиты в случае, когда конкурент независимо изобретает ту же технологию: именно для этого существуют патенты.

В последние годы Закон об авторском праве в цифровую эпоху (Digital Millennium Copyright Act, DMCA) получил широкую известность. Как бы забавно это ни звучало, основное назначение DMCA, принятого в 1998 году, состоит в защите технологий защиты авторских прав. Предполагается, что сами технологии охраны авторских прав уязвимы и потому нуждаются в законодательной защите. Если говорить серьёзно, главная идея DMCA заключается в правовой защите систем охраны авторских прав от обхода. Разумеется, «обход систем защиты авторских прав» почти всегда связан с реверсингом, поэтому DMCA ближе любого другого положения Свода законов США к закону против обратной разработки. Однако следует подчеркнуть, что DMCA распространяется только на системы защиты авторских прав, то есть, по существу, на технологии DRM. Он не относится к другим видам охраняемого авторским правом программного обеспечения, поэтому вовсе не затрагивает многие применения реверсинга. Что же именно запрещает DMCA?

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

• Разработка технологий обхода. Человек не вправе разрабатывать или предоставлять какой-либо продукт либо технологию, обходящие DRM. Если вам интересно, обычная программа-генератор ключей тоже подпадает под это определение. Фактически разработчик генератора ключей нарушает данное положение, а пользователь такого генератора - предыдущее.

• Если вы действительно законопослушный гражданин, поясним: генератор ключей - это программа, которая на лету создаёт серийный номер для приложения, запрашивающего его при установке. В Интернете незаконно доступны генераторы ключей почти для любой программы, требующей серийный номер. Защита от копирования и генераторы ключей подробно рассматриваются в части III.

К счастью, DMCA предусматривает несколько исключений, при которых обход разрешён. Кратко рассмотрим каждое из них:

• Совместимость. Обратная разработка и обход технологий DRM могут быть разрешены, если такая работа необходима для взаимодействия с соответствующим программным продуктом. Например, если программа зашифрована для защиты от копирования, разработчик вправе расшифровать её, когда это единственный способ обеспечить взаимодействие.

• Исследование шифрования. DMCA содержит положение с очень строгими ограничениями, позволяющее исследователям технологий шифрования обходить средства защиты авторских прав в продуктах с функциями шифрования. Обход допускается лишь тогда, когда средства защиты мешают оценить технологию шифрования.

• Проверка безопасности. Человек вправе исследовать и обходить программную защиту авторских прав с целью оценки или повышения безопасности компьютерной системы.

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

• Государственное расследование. Неудивительно, что на государственные органы, проводящие расследования, DMCA не распространяется.

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

• Защита неприкосновенности частной жизни. Продукты, собирающие или передающие личные сведения, разрешается исследовать, а содержащиеся в них технологии защиты - обходить.

По меркам законодательства DMCA сравнительно нов, поэтому пока не применялся особенно широко. Тем не менее было несколько получивших большую огласку дел, в которых ссылались на этот закон. Кратко рассмотрим два из них.

Фелтен против RIAA. В сентябре 2000 года организация Secure Digital Music Initiative (SDMI) объявила конкурс Hack SDMI. Он предлагал исследователям безопасности проверить уровень защиты SDMI - системы управления цифровыми правами для охраны аудиозаписей, основанной на водяных знаках. Профессор Принстонского университета Эдвард Фелтен и его исследовательская группа обнаружили слабые места системы и написали статью с описанием результатов [Craver]. Первоначально участникам Hack SDMI предлагалось вознаграждение в 10 000 долларов в обмен на отказ от прав собственности на собранные сведения. Команда Фелтена решила отказаться от денег и сохранить права на сведения, чтобы иметь возможность опубликовать результаты. После этого SDMI и Ассоциация звукозаписывающей индустрии Америки (Recording Industry Association of America, RIAA) пригрозили исследователям судебным преследованием за нарушение DMCA. Команда отозвала статью с первоначальной конференции, куда та была направлена, но позднее всё же смогла опубликовать её на симпозиуме USENIX Security.

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

США против Склярова. В июле 2001 года российский программист Дмитрий Скляров был арестован ФБР за действия, которые сочли нарушением DMCA. Работая в московской программной компании ElcomSoft, Скляров исследовал методами обратной разработки формат файлов Adobe eBook. Полученные сведения использовали при создании программы Advanced eBook Processor, способной расшифровывать такие файлы eBook. По существу, это зашифрованные файлы .pdf, применяемые для распространения охраняемых авторским правом материалов, например книг. После расшифровки их мог читать любой просмотрщик PDF. При этом обходились первоначальные ограничения на просмотр, печать и копирование файлов eBook, которые тем самым оставались без защиты. Adobe подала жалобу, утверждая, что создание и распространение Advanced eBook Processor нарушает DMCA, после чего государство предъявило обвинения и Склярову, и ElcomSoft. В конечном итоге обоих оправдали, поскольку присяжные поверили, что разработчики изначально не осознавали незаконный характер своих действий.

Поскольку, кроме DMCA, законов, непосредственно запрещающих или ограничивающих реверсинг, нет, а сам DMCA относится лишь к продуктам DRM или программам с технологиями DRM, поставщики добавляют запрет обратной разработки в лицензионные соглашения на готовое программное обеспечение. Это тот самый очень длинный документ, который вам предлагают «принять» при установке практически любого программного продукта в мире. Следует отметить, что в большинстве случаев уже само использование программы юридически равнозначно подписанию её лицензионного соглашения при условии, что пользователю дали возможность с ним ознакомиться.

Главный правовой вопрос относительно запрета обратной разработки в лицензионных соглашениях состоит в том, можно ли обеспечить его принудительное исполнение. В Соединённых Штатах, по-видимому, нет единого авторитетного ответа: всё зависит от конкретных обстоятельств, в которых проводится обратная разработка. В Европейском союзе вопрос ясно определён Директивой о правовой охране компьютерных программ [EC1]. Она разрешает декомпиляцию программ для обеспечения совместимости. По крайней мере в этом вопросе Директива имеет преимущество перед условиями лицензионных соглашений на готовое программное обеспечение.

Повторим несколько основных понятий разработки программного обеспечения в том виде, в каком их воспринимают обычные программисты. Хотя этот взгляд заметно отличается от картины, возникающей при реверсинге, полезно ещё раз обратиться к данным темам и освежить их в памяти, прежде чем обсуждать низкоуровневое программное обеспечение.

В следующих разделах приведён краткий обзор фундаментальных понятий программной инженерии: структуры программы, включая процедуры, объекты и тому подобное, управления данными, включая типичные структуры данных, роль переменных и прочее, а также основных конструкций потока управления. Наконец, мы вкратце сравним наиболее популярные языки программирования высокого уровня и оценим их «обратимость». Если вы профессиональный разработчик и все эти темы совершенно вам ясны, можете сразу перейти к разделу «Низкоуровневый взгляд» далее в главе. В любом случае учтите, что перед вами чрезвычайно сжатый обзор материала, которым можно было бы заполнить немало книг. Этот раздел не задумывался как введение в разработку программного обеспечения: такое введение выходит за рамки книги.

Чтобы по-настоящему понять программу при обратной разработке, почти всегда приходится расшифровывать операторы потока управления и пытаться восстановить стоящую за ними логику. Такие операторы изменяют ход программы в зависимости от определённых значений и условий. В языках высокого уровня они представлены основными условными блоками и циклами, которые компилятор преобразует в низкоуровневые операторы управления. Кратко рассмотрим основные высокоуровневые конструкции потока управления:

• Условные блоки. В большинстве языков условные блоки кода реализуются оператором if. Они позволяют задать одно или несколько условий, определяющих, будет ли выполняться блок.

• Блоки выбора. Блоки switch, также называемые условными конструкциями с несколькими вариантами, обычно получают входное значение и определяют несколько блоков кода, выполняемых при разных его значениях. Каждому блоку сопоставляется одно или несколько значений, а во время работы программа переходит к нужному блоку на основании поступившего входного значения. Компилятор реализует эту возможность кодом, который принимает значение и ищет соответствующий блок, обычно обращаясь к таблице с указателями на все варианты.

• Циклы. Циклы позволяют программе многократно выполнять один блок кода произвольное количество раз. Обычно цикл управляет счётчиком, показывающим число уже выполненных или ещё оставшихся итераций. Каждый цикл содержит некоторое условие, определяющее момент его прекращения. На цикл можно взглянуть и как на условный оператор, тождественный обычному условному блоку, но выполняемый неоднократно. Процесс останавливается, когда условие перестаёт выполняться.

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

Поток управления относится к тем областям, где представление в исходном коде делает программу по-настоящему удобной для человека. Разумеется, большинство процессоров и низкоуровневых языков просто не знает смысла слов if и while. Низкоуровневая реализация простого оператора управления часто сбивает с толку, поскольку применяемые на этом уровне конструкции весьма примитивны. Задача состоит в том, чтобы снова преобразовать их в удобные высокоуровневые понятия.

Одна из проблем заключается в том, что большинство высокоуровневых условных операторов слишком длинно для низкоуровневых языков, например ассемблера, поэтому разбивается на последовательности операций. Чтобы понять эти последовательности, связь между ними и породившие их высокоуровневые операторы, необходимо знать низкоуровневые конструкции управления и способы представления с их помощью высокоуровневого потока. Подробности зависят от платформы и языка. Операторы управления в ассемблере IA-32 будут рассмотрены в следующем разделе.

Чтобы понимать низкоуровневое программное обеспечение, необходимо знать язык ассемблера. Для большинства задач это язык реверсинга, и овладение им является обязательным шагом на пути к настоящему специалисту, поскольку в большинстве программ ассемблер остаётся единственной доступной связью с первоначальным исходным кодом. К сожалению, между исходным кодом большинства программ и машинно-сгенерированным ассемблерным кодом, с которым приходится работать при обратной разработке, лежит немалая дистанция. Но не бойтесь: в книге собрано множество методов, позволяющих выжать из ассемблерных программ каждый возможный бит сведений!

Следующие разделы дают краткое введение в мир ассемблера, сосредоточенное на IA-32 - 32-разрядной архитектуре Intel, которая лежит в основе всех процессоров Intel x86, от исторического 80386 до современных реализаций. Я выбрал ассемблер Intel IA-32, поскольку он используется во всех персональных компьютерах мира и является самой популярной процессорной архитектурой. Совместимые с Intel процессоры, например выпускаемые Advanced Micro Devices (AMD), Transmeta и другими компаниями, с точки зрения реверсинга почти не отличаются, поскольку их объектный код совместим с процессорами Intel.

Прежде чем рассматривать даже простейший ассемблерный код, необходимо познакомиться с регистрами IA-32: ссылки на них будут встречаться почти в каждой инструкции. Для большинства задач IA-32 предоставляет восемь универсальных регистров: EAX, EBX, ECX, EDX, ESI, EDI, EBP и ESP. Кроме них архитектура поддерживает стек регистров с плавающей запятой и множество других регистров для специальных системных задач, но приложения используют их редко, поэтому здесь они не рассматриваются. Обычный программный код работает только с восемью универсальными регистрами.

В таблице 2.1 кратко описаны эти регистры и их наиболее распространённое назначение.

Обратите внимание, что все имена начинаются с буквы E, означающей extended, то есть «расширенный». Они унаследованы от старой 16-разрядной архитектуры Intel, где регистры назывались точно так же, но без E: например, EAX назывался AX. Это важно, поскольку иногда встречается 32-разрядный код, который обращается к регистрам в такой форме: MOV AX, 0x1000 и тому подобное. На рисунке 2.3 показаны все регистры общего назначения и разные варианты их имён.

Таблица 2.1. Универсальные регистры IA-32 и их назначение

Рисунок 2.3. Регистры общего назначения IA-32.

Процессоры IA-32 имеют особый регистр EFLAGS, содержащий всевозможные флаги состояния и системные флаги. Системные применяются для управления различными режимами и состояниями процессора и к нашему обсуждению отношения не имеют. Флаги состояния, напротив, позволяют процессору записывать текущее логическое состояние. Многие логические и целочисленные инструкции обновляют их, фиксируя результат своих действий. Кроме того, некоторые инструкции работают в зависимости от значений этих флагов, благодаря чему можно строить последовательности, выполняющие разные операции при разных входных значениях.

В коде IA-32 флаги являются основным средством создания условного выполнения. Арифметические инструкции проверяют операнды на определённые условия и устанавливают флаги процессора в соответствии с их значениями. Затем другие инструкции читают эти флаги и выполняют разные действия в зависимости от записанного состояния. Популярная группа инструкций, работающих на основании флагов, - Jcc (Conditional Jump, условный переход). Они проверяют определённые значения флагов в зависимости от конкретной команды и переходят по указанному адресу кода, если флаги установлены в соответствии с заданным условием.

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

Как будет выглядеть эта строка на языке ассемблера? Обычно проверить значение переменной и сразу выполнить соответствующее действие одной инструкцией невозможно: большинство инструкций для этого слишком примитивно. Сначала необходимо проверить значение bSuccess, которое, вероятно, будет загружено в регистр, и установить флаги, отражающие, равно ли оно нулю. Затем вызывается инструкция условного перехода, проверяющая нужные флаги и выполняющая переход, если они показывают, что операнд последней инструкции был нулевым. Об этом сообщает флаг нуля ZF. В противном случае процессор просто продолжит с инструкции, следующей за переходом. Компилятор может поступить и иначе: обратить условие и перейти, если bSuccess не равна нулю. Решение об обращении условия зависит от многих факторов. Подробно эта тема рассматривается в приложении A.

Прежде чем обсуждать отдельные ассемблерные инструкции, познакомимся с общим устройством инструкций IA-32. Обычно они состоят из кода операции, или опкода, и одного либо двух операндов. Опкод - это имя инструкции, например MOV, а операнды - получаемые ею «параметры», хотя у некоторых инструкций их нет. Естественно, разным инструкциям требуются разные операнды, поскольку они решают разные задачи. Операнды представляют данные, обрабатываемые конкретной инструкцией, подобно параметрам функции. В ассемблере данные принимают три основные формы:

• Имя регистра. Имя регистра общего назначения, из которого нужно прочитать или в который следует записать значение. В IA-32 это, например, EAX, EBX и другие.

• Непосредственное значение. Константа, встроенная прямо в код. Она часто указывает, что в первоначальной программе имелась жёстко заданная константа.

• Адрес памяти. Если операнд находится в оперативной памяти, его адрес заключается в квадратные скобки. Это может быть жёстко заданное непосредственное значение, точно указывающее процессору адрес чтения или записи, либо регистр, содержимое которого используется как адрес. Можно также сочетать регистр с арифметической операцией и константой: тогда регистр представляет базовый адрес объекта, а константа - смещение внутри него или индекс массива.

Общий формат инструкции выглядит так:

Некоторые инструкции принимают только один операнд, назначение которого зависит от конкретной команды. Другие не имеют операндов и работают с предопределёнными данными. В таблице 2.2 приведено несколько типичных примеров операндов и объяснено их значение.

Таблица 2.2. Примеры типичных операндов инструкций и их значение

Инструкция MOV, вероятно, самая распространённая в IA-32. Она принимает два операнда - назначение и источник - и просто переносит данные из источника в назначение. Операндом назначения может быть адрес памяти, заданный непосредственно или через регистр, либо регистр. Источником может служить непосредственное значение, регистр или адрес памяти. Обратите внимание, что адрес памяти разрешён только в одном из двух операндов, но никогда сразу в обоих. Это общее правило инструкций IA-32: за редкими исключениями большинство из них принимает лишь один операнд в памяти. Вот «прототип» инструкции MOV:

Чтобы увидеть применение MOV и других инструкций в настоящем коде, обратитесь к разделу «Примеры» далее в этой главе.

Для основных арифметических операций набор инструкций IA-32 содержит шесть целочисленных команд: ADD, SUB, MUL, DIV, IMUL и IDIV. В следующей таблице приведены распространённый формат каждой инструкции и краткое описание. Обратите внимание, что многие из них поддерживают иные варианты с другим набором операндов. В таблице 2.3 показана наиболее распространённая форма каждой команды.

Таблица 2.3. Типичные формы основных арифметических инструкций IA-32

Операнды сравниваются инструкцией CMP, которая принимает два операнда:

CMP записывает результат сравнения во флаги процессора. По существу, она просто вычитает Operand2 из Operand1 и отбрасывает результат, но устанавливает все соответствующие флаги так, чтобы они правильно отражали итог вычитания. Например, если получен ноль, устанавливается флаг нуля ZF, означающий равенство двух операндов. Тот же флаг позволяет определить неравенство: достаточно проверить, что ZF не установлен. CMP устанавливает и другие флаги, по которым можно выяснить, какой операнд больше, с учётом того, являются значения знаковыми или беззнаковыми. Подробнее эти флаги рассматриваются в приложении A.

Условные переходы реализуются группой инструкций Jcc. Эти инструкции при выполнении определённых условий передают управление по указанному адресу. Jcc - обобщённое имя, за которым скрывается довольно много вариантов. Каждый из них проверяет свой набор значений флагов и на основании результата решает, выполнять ли переход. Конкретные варианты рассматриваются в приложении A.

Основной формат инструкции условного перехода выглядит так:

Если указанное условие выполнено, Jcc просто изменяет указатель инструкции на TargetCodeAddress, не сохраняя прежнее значение. Если условие ложно, Jcc ничего не делает, и выполнение продолжается со следующей инструкции.

Вызов функций реализуется двумя основными инструкциями языка ассемблера. CALL вызывает функцию, а RET возвращает управление вызывающему коду. CALL помещает текущий указатель инструкции в стек, чтобы позднее можно было вернуться, а затем переходит по указанному адресу. Адрес функции задаётся как любой другой операнд: непосредственным значением, регистром или адресом памяти. Общая форма CALL выглядит так:

Завершая работу и возвращаясь к вызывающему коду, функция обычно исполняет RET. Эта инструкция извлекает из стека указатель, ранее помещённый туда CALL, и возобновляет выполнение с соответствующего адреса. Кроме того, RET можно приказать после извлечения указателя увеличить ESP на заданное количество байтов. Это требуется для возвращения ESP в положение, которое он занимал до вызова текущей функции и помещения в стек её параметров. В некоторых соглашениях о вызовах за корректировку ESP отвечает вызывающий код. Тогда RET применяется без операндов, а вызывающая сторона должна самостоятельно увеличить ESP на число байтов, занятых параметрами. Подробные сведения о соглашениях о вызовах приведены в приложении C.

Кратко рассмотрим несколько небольших фрагментов ассемблерного кода, чтобы убедиться в понимании основных понятий. Вот первый пример:

Первая инструкция - CMP, сравнивающая два указанных операнда. Здесь текущее значение регистра EBX сопоставляется с константой 0xf020; префикс 0x обозначает шестнадцатеричное число, равное 61 472 в десятичной системе. Как уже известно, CMP установит флаги, отражающие результат сравнения. Следующая инструкция - JNZ, один из ранее описанных вариантов группы Jcc, то есть условных переходов. Этот вариант выполняет переход, если флаг нуля ZF не установлен, поэтому инструкция называется JNZ (jump if not zero, перейти, если не ноль). По существу, она переходит по заданному адресу кода, если операнды, ранее сравненные CMP, не равны. Поэтому JNZ также называют JNE (jump if not equal, перейти, если не равно). JNE и JNZ - две мнемоники одной инструкции, имеющие один и тот же опкод в машинном языке.

Перейдём к другому примеру, показывающему перемещение данных и арифметическую операцию.

Последовательность начинается с MOV, которая читает адрес из памяти в регистр EDI. Квадратные скобки показывают, что выполняется обращение к памяти, а внутри них задан конкретный читаемый адрес. В данном случае MOV возьмёт значение ECX, прибавит 0x5b0, то есть 1456 в десятичной системе, и использует результат как адрес памяти. Инструкция прочитает оттуда 4 байта и запишет их в EDI. Число читаемых байтов известно по регистру назначения. Если бы инструкция ссылалась на DI, а не EDI, читались бы только 2 байта. EDI является полным 32-разрядным регистром; регистры IA-32 и их размеры показаны на рисунке 2.3.

Следующая инструкция читает другой адрес памяти: на этот раз значение по адресу ECX плюс 0x5b4 помещается в EBX. Нетрудно заключить, что ECX указывает на некоторую структуру данных, а 0x5b0 и 0x5b4 являются смещениями её элементов. В настоящей программе, вероятно, стоило бы попытаться узнать об этой структуре больше. Для этого можно проследить код назад и выяснить, где в ECX загружается текущее значение. Так обнаружится источник адреса структуры и, возможно, прояснится её природа. На протяжении книги в практических примерах будут показаны всевозможные методы исследования структур данных.

Последняя инструкция последовательности - IMUL, то есть знаковое умножение. У неё есть несколько форм, но вариант с двумя операндами, использованный здесь, означает, что первый операнд умножается на второй, а результат записывается в первый. Следовательно, значение EDI будет умножено на EBX, после чего результат вернётся в EDI.

Рассмотрев три инструкции вместе, можно довольно хорошо понять их назначение. По существу, они берут два разных элемента одной структуры данных, адрес которой находится в ECX, и перемножают их. Применение IMUL также показывает, что элементы являются знаковыми целыми числами, по всей видимости 32-разрядными. Неплохой результат для трёх строк ассемблерного кода!

В последнем примере посмотрим, как выглядит обычная последовательность вызова функции в ассемблере IA-32.

Эта последовательность помещает в стек пять значений инструкциями PUSH. Первые четыре берутся из регистров. Пятое, последнее, считывается по адресу памяти ESP плюс 0x24. В большинстве случаев это адрес в стеке, поскольку ESP является указателем стека, а значит, речь идёт либо о параметре, переданном текущей функции, либо о локальной переменной. Чтобы точно установить назначение адреса, потребуется рассмотреть функцию целиком и изучить использование стека. Методы такого анализа будут показаны в главе 5.

Можно с уверенностью сказать, что 99 процентов всего современного программного обеспечения создаётся на языках высокого уровня и перед поставкой клиентам проходит через тот или иной компилятор. Поэтому столь же уверенно можно утверждать, что большинство, если не все, встречающиеся вам сценарии реверсинга будут связаны с расшифровкой результата работы задней части какого-либо компилятора.

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

Код, созданный компилятором, может быть труден для чтения. Иногда он настолько отличается от первоначальной структуры программы, что определить исходные намерения разработчика становится непросто. Похожая проблема возникает с арифметическими последовательностями: их часто перестраивают ради эффективности, и в результате получается странно выглядящий ряд операций, понять который бывает очень трудно. Иными словами, знание процессов, выполняемых компилятором, и того, как он «воспринимает» код, в конечном счёте помогает расшифровать результат.

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

Необходимо подчеркнуть, что компиляторы - чрезвычайно сложные программы, объединяющие множество областей исследований в информатике и способные содержать миллионы строк кода. Следующие разделы ни в коей мере не являются исчерпывающими: они лишь затрагивают поверхность. Если вы хотите углубить знания о компиляторах и оптимизациях, обратитесь к хорошо читаемому учебнику по методам компиляции [Cooper] Keith D. Copper and Linda Torczon, Engineering a Compiler, Morgan Kaufmann Publishers, 2004, либо к более подробному рассмотрению сложных тем, включая оптимизации, в книге [Muchnick] Steven S. Muchnick, Advanced Compiler Design and Implementation, Morgan Kaufmann Publishers, 1997.

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

В процессе перевода компилятор обычно выполняет множество улучшений или оптимизаций, используя своё «понимание» программы и различные алгоритмы повышения эффективности кода. Как уже отмечалось, у таких оптимизаций есть серьёзный «побочный эффект»: они значительно ухудшают читаемость полученного кода. Машинно-сгенерированный код просто не предназначен для человеческого восприятия.

Файл листинга - созданный компилятором текстовый файл с полученным ассемблерным кодом. Разумеется, такие сведения можно добыть дизассемблированием созданных компилятором двоичных файлов, однако листинг вдобавок удобно показывает соответствие каждой строки ассемблера первоначальному исходному коду. Файлы листинга являются не столько инструментом реверсинга, сколько исследовательским средством: с их помощью изучают поведение конкретного компилятора, передавая ему разный код и наблюдая выходной результат.

Большинство компиляторов поддерживает создание файлов листинга во время компиляции. Для некоторых, например GCC, это обычная часть процесса, поскольку компилятор не создаёт объектный файл непосредственно, а сначала выдаёт ассемблерный файл, который затем обрабатывает ассемблер. В таком компиляторе запрос листинга означает лишь, что файл не следует удалять после завершения ассемблера. В других компиляторах, например Microsoft или Intel, листинг является необязательной возможностью, которую нужно включить параметром командной строки.

Все рассматриваемые в книге примеры скомпилированного кода, не считая исследуемого стороннего кода, созданы одним из трёх компиляторов:

• GCC и G++ версии 3.3.1. GNU C Compiler (GCC) и GNU C++ Compiler (G++) - популярные компиляторы с открытым исходным кодом, создающие программы для множества разных процессоров, включая IA-32. Компиляторы GNU, которые доступны и для других языков высокого уровня, широко применяются разработчиками на платформах Unix, например Linux; с их помощью фактически собрана большая часть систем Unix. Следует отметить, что компиляторы GNU позволяют писать код и для Microsoft Windows. Они обладают мощным механизмом оптимизации, обычно выдающим результаты, похожие на два других компилятора из списка. Однако генератор кода IA-32 у GNU, по-видимому, не особенно агрессивен, вероятно из-за поддержки столь большого числа разных процессоров. С одной стороны, поэтому создаваемый ими код IA-32 часто оказывается немного менее эффективным, чем у некоторых других популярных компиляторов этой архитектуры. С другой стороны, для обратной разработки это преимущество: такой код нередко чуть легче читать, по крайней мере по сравнению с результатом других обсуждаемых здесь компиляторов.

• Microsoft C/C++ Optimizing Compiler версии 13.10.3077. Оптимизирующий компилятор Microsoft - один из наиболее распространённых на платформе Windows. Он поставляется с разными версиями Microsoft Visual Studio; в книге используется вариант из Microsoft Visual C++ .NET 2003.

• Intel C++ Compiler версии 8.0. Компилятор Intel C/C++ создавался прежде всего для тех, кому необходимо выжать из процессоров Intel IA-32 абсолютно максимальную производительность. Его хороший этап оптимизации, по-видимому, находится на одном уровне с двумя другими компиляторами списка, но особенно Intel отличается задней частью. Неудивительно, что компания сосредоточилась на создании высокооптимизированного кода IA-32 с учётом особенностей архитектуры Intel NetBurst и других архитектур Intel. Компилятор также поддерживает расширенные наборы SSE, SSE2 и SSE3, доступные в современных процессорах IA-32.

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

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

Прежде чем углубляться в работу Windows, вкратце посмотрим, как система пришла к современной архитектуре, и перечислим её наиболее фундаментальные особенности.

Как вам, вероятно, известно, когда-то существовали две разные операционные системы с названием Windows: Windows и Windows NT. Первая продавалась под именами Windows 95, Windows 98 и Windows Me и происходила от старых 16-разрядных версий Windows. Windows NT была представлена как Windows 2000, а позднее - как Windows XP и Windows Server 2003. Это более новая архитектура, разработку которой Microsoft начала в первые годы 1990-х. Windows NT изначально проектировалась как 32-разрядная операционная система с виртуальной памятью, многопоточностью и поддержкой нескольких процессоров, поэтому она гораздо лучше подходит современному оборудованию и программному обеспечению.

Обе операционные системы сделали совместимыми с API Win32, чтобы приложения могли работать в каждой из них. В 2001 году Microsoft наконец решила отказаться от старого продукта Windows, что, по моему мнению, следовало сделать намного раньше, и предлагать только системы на основе NT. Первой общедоступной потребительской версией Windows NT стала Windows XP. Для пользователей Windows 9x она была крупным шагом вперёд, а для пользователей предшествующей системы на основе NT, Windows 2000, - значительно меньшим. В этой главе в основном описывается Windows XP, однако большая часть материала посвящена фундаментальным понятиям, которые почти не менялись между Windows NT 4.0, выпущенной в 1996 году, и Windows Server 2003. Можно с уверенностью предположить, что материал будет в равной степени применим и к следующему выпуску Windows, который сейчас носит кодовое имя Longhorn.

Ниже перечислены основные возможности архитектуры Windows NT.

• Полностью 32-разрядная архитектура. Теперь, когда переход к 64-разрядным вычислениям уже идёт полным ходом, это может звучать не особенно впечатляюще, однако Windows NT представляет собой чистую 32-разрядную вычислительную среду, свободную от старых 16-разрядных пережитков. Современные версии операционной системы также доступны в 64-разрядном варианте.

• Поддержка виртуальной памяти. Диспетчер памяти Windows NT использует полноценную модель виртуальной памяти, которая подробно рассматривается далее в этой главе.

• Переносимость. В отличие от первоначального продукта Windows, Windows NT написана на сочетании C и C++, поэтому её можно заново скомпилировать для работы на разных процессорных платформах. Кроме того, все обращения к физическому оборудованию проходят через особый уровень аппаратных абстракций (Hardware Abstraction Layer, HAL), который изолирует систему от оборудования и упрощает перенос на новые аппаратные платформы.

• Многопоточность. Windows NT является полностью вытесняющей многопоточной системой. Хотя поздние версии первоначальной Windows тоже поддерживали многопоточность, в них оставались невытесняющие компоненты, например 16-разрядные реализации USER и GDI, то есть частей графического интерфейса Windows. Эти компоненты отрицательно влияли на способность системы обеспечивать параллельное выполнение.

• Поддержка нескольких процессоров. Ядро Windows NT способно работать с несколькими процессорами, поэтому лучше подходит для высокопроизводительных вычислительных сред, например крупных серверов центров обработки данных и других приложений с большой нагрузкой на центральный процессор.

• Безопасность. В отличие от старых версий Windows, Windows NT проектировалась с учётом безопасности. С каждым объектом системы связан список управления доступом (Access Control List, ACL), определяющий, каким пользователям разрешено им управлять. Файловая система Windows NT (NTFS) также поддерживает ACL для каждого отдельного файла и позволяет шифровать отдельные файлы или целые тома.

• Совместимость. Windows NT достаточно хорошо совместима со старыми приложениями и способна выполнять 16-разрядные программы Windows, а также некоторые программы DOS. Старые приложения запускаются в специальной изолированной виртуальной машине, откуда не могут поставить под угрозу остальную систему.

Первоначально Windows NT проектировалась как межплатформенная операционная система и выпускалась для нескольких процессорных архитектур, включая IA-32, DEC Alpha и другие. В последних версиях единственной поддерживаемой 32-разрядной платформой оставалась IA-32, однако теперь Microsoft также поддерживает 64-разрядные архитектуры AMD64, Intel IA-64 и Intel EMT64.

Это обсуждение относится именно к 32-разрядным версиям Windows. С точки зрения обратной разработки 64-разрядные варианты существенно отличаются, поскольку 64-разрядные процессоры независимо от конкретной архитектуры используют другой язык ассемблера. Сосредоточиться исключительно на 32-разрядной Windows разумно, ведь книга рассматривает только ассемблер IA-32. По-видимому, 64-разрядным системам понадобится ещё несколько лет, чтобы стать массовым товаром. Обещаю обновить книгу, когда это произойдёт!

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

1. Сначала создаются объект процесса и новое адресное пространство. Когда процесс вызывает Win32 API CreateProcess, этот API создаёт объект процесса и выделяет процессу новое адресное пространство памяти.

2. CreateProcess отображает NTDLL.DLL и исполняемый файл программы, то есть файл .exe, в только что созданное адресное пространство.

3. CreateProcess создаёт первый поток процесса и выделяет для него пространство стека.

4. Первый поток процесса возобновляется и начинает исполнение с функции LdrpInitialize внутри NTDLL.DLL.

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

6. Затем управление передаётся внутренней процедуре NTDLL.DLL с именем LdrpRunInitializeRoutines, которая отвечает за инициализацию всех статически скомпонованных DLL, загруженных в адресное пространство. Процесс инициализации состоит в вызове точки входа каждой DLL с константой DLL_PROCESS_ATTACH.

7. После инициализации всех DLL функция LdrpInitialize вызывает настоящую процедуру инициализации потока - функцию BaseProcessStart из KERNEL32.DLL. Та, в свою очередь, вызывает точку входа WinMain исполняемого файла, и в этот момент процесс завершает последовательность инициализации.

Исключение - особое состояние программы, заставляющее её немедленно перейти к специальной функции, называемой обработчиком исключения. Обработчик решает, как поступить с исключением: он может устранить проблему и продолжить программу с той же позиции кода либо возобновить исполнение с другой позиции. Если разрешить исключение невозможно, обработчик также может принять решение завершить программу.

Существует два основных типа исключений: аппаратные и программные. Аппаратные исключения создаёт процессор, например когда программа обращается к недействительной странице памяти, вызывая страничное нарушение, или выполняет деление на ноль. Программное исключение создаётся, когда программа явно возбуждает исключение, чтобы сообщить об ошибке. Например, в C++ исключение можно возбудить ключевым словом throw; это распространённый способ распространения сведений об ошибке, альтернативный возврату кодов ошибок через значения функций. В Windows ключевое слово throw реализовано посредством Win32 API RaiseException, который обращается к ядру и далее проходит по пути кода, похожему на аппаратное исключение, а в конце возвращается в пользовательский режим, чтобы уведомить программу об исключении.

Структурная обработка исключений (structured exception handling, SEH) означает, что операционная система предоставляет механизмы упорядоченной "доставки" исключений приложениям. Каждому потоку назначается список обработчиков исключений - перечень процедур, способных реагировать на возникающие исключения. Когда происходит исключение, операционная система вызывает каждый зарегистрированный обработчик, а тот решает, следует ли ему обработать исключение или система должна продолжить поиск.

Список обработчиков исключений хранится в структуре блока информации о потоке (thread information block, TIB), которая доступна из пользовательского режима и содержит следующие поля:

TIB хранится в обычной закрытой области памяти пользовательского режима. Мы уже знаем, что один процесс может иметь несколько потоков, однако все потоки видят одну память: они совместно используют одно адресное пространство. Значит, у каждого процесса может быть несколько структур TIB. Как поток находит собственную TIB во время выполнения? В процессорах IA-32 Windows использует сегментный регистр FS как указатель на активные в данный момент структуры данных конкретного потока. TIB текущего потока всегда доступен по адресу FS:[0].

Нас интересует элемент ExceptionList: это начало списка обработчиков исключений текущего потока. Когда создаётся исключение, процессор вызывает зарегистрированный в IDT обработчик. Возьмём в качестве примера страничное нарушение. При обращении к недействительному адресу памяти, то есть адресу без действительной записи таблицы страниц, процессор создаёт прерывание страничного нарушения - прерывание номер 14 - и вызывает обработчик, указанный в записи 14 IDT. В Windows эта запись обычно указывает на функцию KiTrap0E в ядре Windows. KiTrap0E определяет тип возникшего страничного нарушения и передаёт его надлежащему обработчику. При страничных нарушениях пользовательского режима, которые не разрешил диспетчер памяти, например вызванных обращением приложения к недействительному адресу памяти, Windows вызывает пользовательскую диспетчерскую процедуру исключений KiUserExceptionDispatcher из NTDLL.DLL. KiUserExceptionDispatcher вызывает RtlDispatchException, которая обходит связанный список по адресу ExceptionList и ищет обработчик, способный справиться с исключением. Связанный список по существу представляет собой цепочку структур данных _EXCEPTION_REGISTRATION_RECORD, определённых следующим образом:

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

Эта последовательность просто добавляет запись _EXCEPTION_REGISTRATION_RECORD в список обработчиков исключений текущего потока. Элементы хранятся в стеке.

На практике простые последовательности установки обработчика, подобные только что показанной, встречаются редко. Причина в том, что компиляторы обычно расширяют механизм операционной системы, чтобы поддерживать вложенные блоки обработки исключений и несколько таких блоков внутри одной функции. В компиляторах Microsoft исключение для этого направляется обработчику _except_handler3, который затем вызывает правильный фильтр и обработчик исключения с учётом устройства текущей функции. Для реализации этой возможности компилятор обслуживает дополнительные структуры данных, управляющие иерархией обработчиков исключений внутри одной функции. Ниже приведена типичная последовательность установки SEH, создаваемая компилятором Microsoft C/C++:

Как видно, компилятор расширил структуру данных _EXCEPTION_REGISTRATION_RECORD и добавил два новых элемента. _except_handler3 использует их, чтобы определить, какой обработчик следует вызвать.

Помимо кадровых обработчиков исключений, новые версии операционной системы поддерживают также вектор обработчиков - линейный список процедур, вызываемых при каждом исключении независимо от того, какой код его создал. Векторные обработчики исключений устанавливаются посредством Win32 API AddVectoredExceptionHandler.

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

Автономный анализ кода означает, что двоичный исполняемый файл преобразуется дизассемблером или декомпилятором в понятную человеку форму. Затем реверс-инжиниринг выполняется посредством ручного чтения и анализа частей полученного текста. Автономный анализ кода - мощный подход, поскольку даёт хорошее общее представление о программе и позволяет легко искать интересующие функции.

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

В некоторых случаях, особенно связанных со взломом защиты, автономный анализ кода невозможен. Обычно это происходит, когда программа "упакована": код зашифрован или сжат и распаковывается только во время выполнения. В таких случаях возможен лишь анализ работающего кода.

Анализ работающего кода тоже предполагает преобразование кода в понятную человеку форму, но преобразованный код не просто читают статически: программу запускают в отладчике и наблюдают за её поведением в действующей системе. Такой подход даёт гораздо больше сведений, поскольку позволяет видеть внутренние данные программы и их влияние на ход исполнения. Можно наблюдать содержимое отдельных переменных и происходящее при чтении или изменении этих данных. В целом анализ работающего кода лучше подходит начинающим, потому что предоставляет намного больше материала для работы. Инструменты такого анализа рассматриваются далее в этой главе, в разделе об отладчиках.

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

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

На рис. 4.1 показано, как дизассемблер преобразует последовательность байтов кода операции IA-32 в понятную человеку инструкцию языка ассемблера. Обычно сначала дизассемблер ищет код операции в таблице преобразования, где содержатся текстовое имя и формат каждой инструкции. В данном случае код операции равен 8B, а инструкция - MOV. Инструкции IA-32 похожи на функции: каждая принимает свой набор "параметров", которые обычно называются операндами. Затем дизассемблер определяет, какие именно операнды использованы в данной инструкции.

Рисунок 4.1. Преобразование инструкции IA-32 из машинного кода в понятный человеку язык ассемблера.

IDA (Interactive Disassembler) компании DataRescue (www.datarescue.com) - чрезвычайно мощный дизассемблер, поддерживающий множество процессорных архитектур, в том числе IA-32, IA-64 (Itanium), AMD64 и многие другие. IDA также работает с различными форматами исполняемых файлов: PE (Portable Executable, применяемый в Windows), ELF (Executable and Linking Format, применяемый в Linux) и даже XBE, используемый в Microsoft Xbox. IDA недёшева: стандартная редакция стоит 399 долларов, а расширенная, которая на момент написания стоила 795 долларов, поддерживает больше процессорных архитектур. И всё же, если вам предстоит много заниматься реверс-инжинирингом крупных программ, она определённо стоит своих денег. Во время написания книги DataRescue предлагала бесплатную пробную версию IDA с ограниченным сроком действия. Если вы всерьёз интересуетесь реверс-инжинирингом, настоятельно рекомендую испытать IDA: это один из лучших доступных инструментов. На рис. 4.2 показан обычный экран IDA Pro.

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

IDA способна строить наглядные блок-схемы заданной функции. По существу это логические графы с фрагментами дизассемблированного кода, которые наглядно показывают влияние каждого условного перехода на поток исполнения функции. Каждый прямоугольник представляет фрагмент кода или этап исполнения функции. Прямоугольники соединены стрелками, показывающими движение кода в зависимости от выполнения или невыполнения условия перехода. На рис. 4.3 приведена блок-схема функции, созданная IDA.

Рисунок 4.2. Обычный экран IDA Pro с дизассемблированным кодом, списком функций и списком строк.

Рисунок 4.3. Блок-схема функции, созданная IDA.

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

В IDA также есть множество небольших функций, делающих работу с ней очень удобной, например подсветка всех вхождений выбранного в данный момент операнда. Если щёлкнуть слово EAX в инструкции, на текущей странице дизассемблированного кода будут подсвечены все ссылки на EAX. Это значительно упрощает чтение дизассемблированных листингов и понимание движения данных в коде.

Рисунок 4.4. Созданный IDA внутрипрограммный граф вызовов, который показывает связи внутренних подпрограмм и то, какие API вызывает каждая из них.

ILDasm - дизассемблер для Microsoft Intermediate Language (MSIL), низкоуровневого языка, похожего на ассемблер и применяемого в программах .NET. Он упомянут здесь потому, что в этой книге также рассматривается реверс-инжиниринг .NET, а ILDasm является одним из основных инструментов для такой работы.

На рис. 4.5 показано обычное представление ILDasm. Слева находится отображаемая ILDasm структура классов текущей программы и их внутренних элементов. Справа приведён дизассемблированный листинг одной из функций. Разумеется, этот язык ассемблера отличается от рассматривавшегося до сих пор IA-32: перед нами MSIL. Он будет подробно описан в главе 12. Обратите внимание на довольно загадочные имена функций и классов, показанные ILDasm. Причина в том, что дизассемблируемая программа была обфусцирована средством DotFuscator компании PreEmptive Solutions.

Рисунок 4.5. Снимок ILDasm, дизассемблера Microsoft для промежуточного языка .NET.

Главное назначение отладчиков - помогать разработчикам программ находить и исправлять ошибки, однако их можно использовать и как мощные инструменты реверс-инжиниринга. Большинство отладчиков машинного кода в той или иной форме поддерживают пошаговое исполнение кода на языке ассемблера, когда исходный код недоступен. Отладчики с таким режимом работы являются превосходными инструментами реверс-инжиниринга; некоторые из них с самого начала проектировались именно для отладки на уровне языка ассемблера.

Идея состоит в том, что отладчик показывает дизассемблированное представление исполняемой в данный момент функции и позволяет пользователю пошагово проходить по коду, наблюдая действия программы на каждой строке. Во время пошагового исполнения отладчик обычно отображает состояние регистров ЦП и дамп памяти, как правило с активной в данный момент областью стека. Ниже перечислены основные возможности отладчика, необходимые специалисту по реверс-инжинирингу.

• Мощный дизассемблер. По очевидным причинам это обязательная возможность хорошего отладчика для реверс-инжиниринга. Крайне важно ясно видеть код и перекрёстные ссылки, которые показывают, куда ведёт каждая ветвь и откуда вызывается определённая инструкция. Необходимо также вручную управлять эвристическими правилами распознавания данных и кода на случай, если они ошибочно примут код за данные или наоборот. Неоднозначности кода и данных в дизассемблерах рассматривались в разделе о дизассемблерах этой главы.

• Программные и аппаратные точки останова. Точки останова - основная возможность отладки, без которой не существует ни одного отладчика, однако важно уметь устанавливать как программные, так и аппаратные точки. Программные точки останова представляют собой инструкции, которые отладчик во время выполнения добавляет в код программы. Дойдя до такой инструкции, процессор приостанавливает исполнение программы и передаёт управление отладчику. Аппаратные точки останова - специальная возможность ЦП, позволяющая процессору приостановить исполнение при обращении к определённому адресу памяти и передать управление отладчику. Для реверс-инжиниринга это особенно мощный инструмент, поскольку он способен значительно упростить отображение и расшифровку структур данных программы. Достаточно найти интересующую структуру и установить аппаратные точки останова на определённые важные области внутри неё. Эти точки выявят участки кода, которые отвечают за изменение соответствующей структуры данных.

• Просмотр регистров и памяти. Хороший отладчик для реверс-инжиниринга должен наглядно отображать важные регистры ЦП и системную память. Полезен также постоянно обновляемый вид стека, включающий как интерпретацию содержимого отладчиком, так и исходное представление данных.

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

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

В современных операционных системах отладчики можно приблизительно разделить на два совершенно разных вида: отладчики пользовательского режима и режима ядра. Первые являются более традиционными и обычно используются разработчиками программ. Как следует из названия, они работают как обычные приложения в пользовательском режиме и могут отлаживать только обычные приложения пользовательского режима. Отладчики режима ядра намного мощнее: они предоставляют неограниченное управление целевой системой и полное представление обо всём происходящем независимо от того, выполняется ли код приложения или операционной системы.

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

Исправление двоичных файлов не является деятельностью, относящейся исключительно к реверс-инжинирингу. Исправление - процесс изменения кода в двоичном исполняемом файле, который тем или иным образом меняет его поведение. Оно связано с реверс-инжинирингом потому, что для выбора места исправления нужно понимать исправляемую программу. Почти всегда исправлению предшествует сеанс реверс-инжиниринга, во время которого программа анализируется и находится позиция кода, требующая изменения.

Обычно исправления выполняют взломщики защиты, когда приходит время "починить" защищённую программу. В этой книге инструменты исправления понадобятся вам для взлома нескольких учебных программ crackme.

Hex Workshop компании BreakPoint Software, Inc. - неплохой инструмент шестнадцатеричного дампа и исправления файлов и даже целых дисков. Он позволяет просматривать данные в разных форматах и произвольно изменять их. К сожалению, Hex Workshop не поддерживает дизассемблирование и ассемблирование инструкций, поэтому для изменения инструкции в программе я обычно рекомендую OllyDbg, где исправления можно вносить на уровне языка ассемблера.

Помимо исправления Hex Workshop прекрасно подходит для реверс-инжиниринга данных, поскольку умеет преобразовывать данные в организованные структуры. К сожалению, программа не бесплатна; её можно было приобрести по адресу www.bpsoft.com.

На снимке рис. 4.12 показан обычный экран Hex Workshop. Справа видны исходные данные дампа одновременно в шестнадцатеричном и текстовом представлениях. Слева находится средство просмотра структур. Оно принимает определение структуры данных и применяет его для форматированного отображения данных текущего файла. Пользователь может выбрать положение этих структурированных данных внутри файла.

Рисунок 4.12. Снимок Hex Workshop компании BreakPoint Software.

Ниже рассмотрены различные инструменты, которые не относятся ни к одной из предыдущих категорий.

Как уже говорилось, в этой главе вы возьмёте группу недокументированных API Windows и на их примере попрактикуетесь в реверс-инжиниринге. Прежде чем представить конкретные API, с которыми предстоит работать, вкратце рассмотрим, как я нашёл их и как вообще искать недокументированные функции или API независимо от того, принадлежат ли они операционной системе или другой сторонней библиотеке.

В следующем разделе описаны первые шаги при работе с недокументированным кодом: как находить недокументированные API и код, который их использует.

Обычно поиск недокументированного кода начинается с некоторой потребности. Какой возможности не хватает? От какого программного компонента можно ожидать её предоставления? Здесь пригодится общее знание соответствующей программы. Нужно представлять себе основные исполняемые модули, из которых она состоит, и знать интерфейсы между ними. Интерфейсы двоичных модулей легко наблюдать, просто выгрузив их каталоги импорта и экспорта; подробно это описано в главе 3.

В данном случае я решил найти интересный API Windows для подробного разбора. Зная, что большинство недокументированных служб пользовательского режима Windows реализовано в NTDLL.DLL, поскольку именно там находится собственный API, я просто выгрузил каталог экспорта NTDLL.DLL и визуально просмотрел список в поисках групп API, которые, судя по именам, связаны друг с другом.

Разумеется, это несколько необычный случай. Обычно недокументированные API ищут не просто потому, что они не документированы, если только сама возможность пользоваться скрытыми API не кажется вам особенно привлекательной и вы не хотите её испытать, а ради конкретной функции. Тогда в каталоге экспорта следует искать соответствующие ключевые слова. Предположим, например, что требуется найти особый API выделения памяти. Достаточно поискать в списке экспорта NTDLL.DLL или любой другой DLL, где, по вашему предположению, реализован API, подходящие слова: memory, alloc и т. д.

Найдя имя недокументированного API и экспортирующей его DLL, пора искать двоичные файлы, которые им пользуются. Исполняемый файл, вызывающий API, послужит двум целям. Во-первых, он способен дополнительно прояснить назначение API. Во-вторых, он даёт живой пример применения: какие именно данные API получает на входе и что возвращает на выходе. Пример использования функции настоящим кодом может оказаться бесценным, когда вы пытаетесь научиться ею пользоваться.

Существует много подходов к поиску API и использующего их кода. Традиционный подход основан на отладчике режима ядра, например Numega SoftICE или Microsoft WinDbg. Такие отладчики значительно упрощают поиск вызовов определённой функции во всей системе, даже если интересующая функция не относится к режиму ядра. Идея состоит в установке общесистемных точек останова, которые срабатывают при вызове функции любым процессом. Это существенно облегчает поиск кода, использующего конкретную функцию. Теоретически то же самое можно сделать в отладчике пользовательского режима наподобие OllyDbg, однако результат будет гораздо менее эффективным: он покажет лишь вызовы внутри отлаживаемого в данный момент процесса.

Давайте с головой погрузимся в наш первый практический сеанс реверс-инжиниринга. Я возьму недокументированную группу API Windows и буду анализировать её, пока не соберу достаточно сведений, чтобы применять эти API в собственном коде. Более того, я действительно написал небольшую программу, которая пользуется ими, чтобы показать, что это возможно. Разумеется, цель главы не в том, чтобы служить руководством именно по этому API, а в наглядной демонстрации реверс-инжиниринга настоящего программного кода.

Для главы выбран API универсальных таблиц (generic table API). Он считается частью собственного API Windows, рассмотренного в главе 3.

Собственный API содержит множество функций с различными префиксами для разных групп. Для этого упражнения я выбрал набор из группы RTL. Это функции библиотеки времени выполнения, которые обычно не служат для взаимодействия с операционной системой, а представляют собой набор часто требующихся средств: обработки строк, управления данными и т. д.

Определившись с API универсальных таблиц, следует просмотреть список экспортируемых символов NTDLL.DLL, где реализован этот API, и найти все функции, которые могут иметь к нему отношение. В данном случае интерес, вероятно, представляет любая функция, имя которой начинается с Rtl и упоминает универсальную таблицу. Выгрузив экспорт NTDLL.DLL посредством DUMPBIN, см. соответствующий раздел главы 4, я нашёл все API Rtl, содержащие строку GenericTable. Получился следующий список:

• RtlNumberGenericTableElements

• RtlDeleteElementGenericTable

• RtlGetElementGenericTable

• RtlEnumerateGenericTable

• RtlEnumerateGenericTableLikeADirectory

• RtlEnumerateGenericTableWithoutSplaying

• RtlInitializeGenericTable

• RtlIsGenericTableEmpty

• RtlInsertElementGenericTable

• RtlLookupElementGenericTable

Если вы самостоятельно просмотрите список экспорта NTDLL.DLL, то, вероятно, заметите варианты большинства этих API с суффиксом Avl. API универсальных таблиц и без того достаточно велик, поэтому в данном обсуждении я просто не стану рассматривать эти функции.

Уже по одним именам можно сделать обоснованные предположения об этих API. Очевидно, перед нами группа функций, управляющих некоторым универсальным списком, где "универсальный", вероятно, означает возможность хранить элементы с данными любого типа. Есть API для вставки, удаления и поиска элемента. RtlNumberGenericTableElements, скорее всего, возвращает общее число элементов списка, а RtlGetElementGenericTable, вероятно, предоставляет прямой доступ к элементу по его индексу. Прежде чем пользоваться универсальной таблицей, почти наверняка требуется вызвать RtlInitializeGenericTable, чтобы инициализировать некоторую корневую структуру данных.

В общем случае сеанс реверс-инжиниринга начинается с данных: необходимо определить основные структуры, которыми управляет код. Поэтому разумно начать с RtlInitializeGenericTable в надежде, что эта функция прольёт свет на структуры данных универсальной таблицы.

Как я уже объяснял, мы будем полагаться исключительно на автономный анализ кода, а не на отладку работающей программы. Если вы хотите исследовать код универсальной таблицы в отладчике, можно воспользоваться GenericTable.EXE - небольшой программой, которую я написал на основании результатов реверс-инжиниринга этого API. Без GenericTable.EXE пришлось бы либо полностью положиться на статический листинг, либо найти другой код, использующий универсальную таблицу. Быстрый поиск обнаружил только компоненты режима ядра, где также имеется реализация универсальной таблицы внутри ядра Windows, но не компоненты пользовательского режима. GenericTable.EXE вместе с исходным кодом доступна на сайте книги по адресу www.wiley.com/go/eeilam.

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

Как уже говорилось, исследование API универсальных таблиц лучше всего начинать со структур данных. Хотя знать все подробности их устройства необязательно, общее представление о содержимом может помочь понять назначение API. Поэтому начнём с функции, которая, судя по имени, с большой вероятностью даст некоторые подсказки об этих структурах: в листинге 5.1 приведён созданный OllyDbg дизассемблированный код RtlInitializeGenericTable.

Листинг 5.1. Дизассемблированный код RtlInitializeGenericTable.

Прежде чем определять назначение и работу функции, начнём с основ: какое соглашение о вызовах она использует и сколько принимает параметров? Соглашение о вызовах задаёт способ передачи параметров функции и определяет, кто отвечает за очистку стека после её завершения. Существует несколько стандартных соглашений, однако Windows по умолчанию обычно применяет stdcall. Функции stdcall сами очищают свой стек и принимают параметры из стека в первоначальном порядке слева направо, а значит, вызывающий код должен помещать их в стек в обратном порядке. Соглашения о вызовах подробно рассмотрены в приложении C.

Чтобы ответить на вопросы о соглашении этой функции, можно начать с поиска завершающей её инструкции RET. Здесь в конце быстро обнаруживается RET 14. Это RET с числовым операндом, который даёт два важных сведения. Переданный RET операнд сообщает процессору, сколько байтов следует удалить из стека помимо возвращаемого адреса. Сам факт того, что функция очищает собственный стек, показывает: это не cdecl, поскольку функции cdecl всегда оставляют очистку вызывающему коду. Так какое же это соглашение?

Продолжим исключать варианты. Функция не принимает никаких регистров от вызывающего кода, потому что каждый используемый регистр инициализируется внутри неё. Следовательно, это не соглашение _fastcall: такие функции получают параметры через ECX и EDX, тогда как оба регистра инициализируются в самом начале данной функции.

Другие распространённые варианты - stdcall и соглашение о вызове функций-членов C++. Мы знаем, что это не функция-член C++, поскольку её имя взято из каталога экспорта и не декорировано. Имена функций C++ всегда декорируются именем класса и точным типом каждого принимаемого параметра. Декорированные имена C++ легко распознать: обычно они содержат множество небуквенно-цифровых символов и более одного имени, как минимум имя класса и метода.

Методом исключения установлено, что функция использует stdcall, а число 14 после RET сообщает объём её параметров. OllyDbg выводит числа в шестнадцатеричном виде, поэтому 14 в шестнадцатеричной системе равно 20 в десятичной. Мы работаем в 32-разрядной среде, где параметры выровнены по 32 битам, то есть 4 байтам, и можем предположить, что функция принимает пять параметров. Возможно, один из них занимает больше 4 байт, и тогда параметров будет меньше пяти, но больше пяти их быть не может из-за 32-разрядного выравнивания.

В прологе видно, что функция использует стандартный стековый кадр EBP. Текущее значение EBP сохраняется в стеке, после чего в EBP записывается значение ESP. Это обеспечивает удобный доступ к переданным через стек параметрам независимо от текущего значения ESP во время работы функции: ESP постоянно меняется, когда функция помещает параметры в стек при вызове других функций. В этой чрезвычайно распространённой схеме первый параметр находится по адресу [EBP+8], второй - [EBP+C] и т. д. Если причина непонятна, подробное объяснение стековых кадров приведено в приложении C.

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

Разберём функцию из листинга 5.1 по одной инструкции и посмотрим, что она делает. Как упоминалось ранее, можно выполнить анализ работающего кода, пошагово пройдя его в отладчике и наблюдая исполнение посредством GenericTable.EXE. Если вы уже достаточно уверенно чувствуете себя с языком ассемблера, вероятно, сможете просто прочитать код листинга 5.1 без GenericTable.EXE.

Углубимся в функцию и определим её устройство и назначение.

Первая строка загружает [EBP+8] в EAX. Мы уже установили, что [EBP+8] - первый параметр функции. Вторая строка выполняет логическую операцию XOR регистра EDX с самим собой, фактически обнуляя его. Компилятор применяет XOR, потому что машинный код xor edx, edx короче, чем более понятный mov edx, 0. Это хорошо показывает, с чем постоянно сталкивается специалист по реверс-инжинирингу: оптимизирующие компиляторы всегда предпочитают читаемому коду маленький и быстрый.

Перед адресом в стеке стоит SS:. Это означает, что адрес читается с использованием SS, регистра сегмента стека. Процессоры IA-32 поддерживают особые механизмы управления памятью, называемые сегментами, однако в Windows они не используются и в большинстве случаев их можно без опасений игнорировать. В IA-32 имеется несколько сегментных регистров: CS, DS, FS, ES и SS. В Windows любое их упоминание можно игнорировать, кроме FS, который предоставляет доступ к небольшой области локальной для потока памяти. Обращения к памяти, начинающиеся с FS:, обычно относятся к этой области. В остальных листингах книги имена сегментных регистров приводятся только тогда, когда они имеют конкретное значение.

Третья инструкция, LEA, при первом взгляде может сбить с толку. LEA (load effective address, загрузка эффективного адреса) по существу является арифметической инструкцией: она не обращается к памяти, но часто служит для вычисления адресов, хотя с её помощью можно вычислять и обычные целые числа. Не позволяйте префиксу DWORD PTR ввести вас в заблуждение: это чисто арифметическая операция. В нашем случае инструкция LEA эквивалентна выражению ECX = EAX + 4.

Пока о встреченных типах данных известно немного. Важнее всего, что мы не уверены в типе первого полученного параметра [EBP+8]. Перейдём к следующему фрагменту и посмотрим, что ещё удастся выяснить.

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

Интересная особенность структуры данных - обращение к ней через два разных регистра. По существу функция хранит два указателя внутрь структуры: EAX и ECX. В EAX остаётся первоначальное значение, переданное первым параметром, а в ECX - адрес EAX + 4. К одним элементам обращаются через EAX, к другим - через ECX.

Предыдущий код по шагам выполняет следующее:

1. Записывает ноль из EDX в первый элемент структуры. Обращение к структуре выполняется через EAX.

2. Записывает в третий элемент адрес второго элемента, то есть хранящееся в ECX значение EAX + 4. На этот раз структура адресуется через ECX, а не EAX.

3. Записывает тот же адрес из ECX во второй элемент.

4. Записывает тот же адрес из ECX в четвёртый элемент.

Если перевести фрагмент на C, получится примерно следующий код:

На первый взгляд это почти ничего не сообщает о структуре, кроме того, что элементы 2, 3 и 4 со смещениями +4, +8 и +C являются указателями. Последние три элемента инициализируются довольно необычно: все они начинают указывать на адрес второго элемента. Что бы это могло означать? По существу это говорит, что каждый из них является указателем на группу из трёх указателей, ведь именно на неё указывает UnknownStruct->Member2. Несколько сбивает с толку то, что структура указывает сама на себя, но, скорее всего, это лишь временная заглушка. Я бы предположил, что позднее элементы изменятся и будут указывать в другие места.

Перейдём к следующим четырём строкам дизассемблированной функции:

Первые две строки копируют значение второго параметра функции в смещение +18 текущей структуры, то есть в седьмой элемент. Следующие две строки копируют третий параметр в смещение +1C, восьмой элемент структуры. После преобразования в C предыдущий код выглядел бы следующим образом.

Перейдём к следующей части RtlInitializeGenericTable.

Здесь происходит практически то же самое: инициализируется оставшаяся часть структуры. В смещение +20 записывается четвёртый параметр, смещения +14 и +10 обнуляются, а в смещение +24 помещается значение пятого параметра.

На этом последовательность инициализации структуры в RtlInitializeGenericTable завершается. К сожалению, не наблюдая в отладчике настоящие значения, переданные функции, мы почти ничего не знаем о типах параметров или элементов структуры. Но известно, что длина структуры, вероятнее всего, равна 40 байтам. Последнее используемое смещение - +24, поэтому размер составляет 28 байт в шестнадцатеричном виде, то есть 40 байт в десятичном. Если предположить, что каждый элемент занимает 4 байта, структура содержит 10 элементов. Теперь можно составить её приблизительное определение, которое, как мы надеемся, позднее удастся улучшить.

Перейдём к исследованию функции, которая, будем надеяться, окажется простой: RtlNumberGenericTableElements. Если корневая структура данных содержит элемент с общим числом элементов таблицы, функция должна его открыть. В противном случае ей придётся обойти и пересчитать все элементы. Ниже приведён вывод OllyDbg для RtlNumberGenericTableElements.

Что ж, ответ получен. Функция просто принимает указатель на, как можно предположить, ту же структуру и возвращает значение из смещения +14. Очевидно, там хранится количество элементов универсальной таблицы. Обновим определение структуры TABLE.

В API универсальных таблиц есть ещё одна, будем надеяться, тривиальная функция, которая может кое-что рассказать о структуре данных: RtlIsGenericTableEmpty. Разумеется, возможно, она просто использует тот же элемент NumberOfElements, что и RtlNumberGenericTableElements. Посмотрим.

Как мы и надеялись, RtlIsGenericTableEmpty оказалась довольно простой. Функция загружает в ECX значение первого параметра, которым должна быть прежняя корневая структура данных, и обнуляет EAX. Затем она сравнивает первый элемент со смещением +0 с EAX и инструкцией SETE записывает в AL единицу, если значения равны. Дополнительные сведения об инструкции SETE приведены в приложении A.

Фактически функция проверяет, равно ли нулю смещение +0 структуры данных. Если да, возвращается TRUE, иначе - ноль. Теперь мы знаем, что по смещению +0 находится важный элемент, который всегда ненулевой при наличии элементов в таблице. Снова добавим полученные сведения в определение структуры.

Теперь посмотрим, как в таблицу добавляется элемент, исследовав RtlInsertElementGenericTable. В листинге 5.5 приведён дизассемблированный код этой функции.

Листинг 5.5. Дизассемблированный код RtlInsertElementGenericTable, полученный в OllyDbg.

Первые две инструкции мы уже обсуждали: они создают стековый кадр. Следующая помещает EDI в стек. В общем случае инструкция PUSH применяется в функции в трёх распространённых ситуациях:

• Для сохранения значения регистра, который функция собирается использовать как локальную переменную. Обычно ближе к концу функции значение извлекается из стека. Это легко распознать, поскольку его необходимо вернуть в тот же регистр.

• Для помещения параметра в стек перед вызовом функции.

• Для копирования значения: иногда сразу после PUSH следует POP, загружающий это значение в другой регистр. Такая последовательность довольно необычна, но некоторые компиляторы время от времени её создают.

Нужно определить, помещается ли EDI как последний параметр вызываемой сразу после этого функции ntdll.7C92147B или сохраняется значение регистра. Поскольку непосредственно после PUSH в EDI записывается новое значение, а в самом конце функции прежнее значение извлекается из стека, известно, что компилятор просто сохраняет EDI, чтобы использовать регистр как локальную переменную.

Следующие две инструкции функции довольно интересны:

Первая строка загружает в локальную переменную EDI значение первого параметра функции; мы уже установили, что [EBP+8] - адрес первого параметра. Вторая строка помещает в EAX указатель на первый параметр. Обратите внимание на разницу между MOV и LEA в этой последовательности. MOV действительно обращается к памяти и извлекает значение по адресу [EBP+8], тогда как LEA просто вычисляет EBP + 8 и загружает это число в EAX.

Сразу возникает вопрос, не является ли EAX ещё одной локальной переменной, подобной EDI. Чтобы ответить, рассмотрим непосредственно следующий код.

Видно, что первым в стек помещается значение EAX. Это убедительно показывает, что EAX не был выделен под локальную переменную, а использовался компилятором как временное хранилище, поскольку для помещения указателя на первый параметр в стек требовались две инструкции. Это очень распространённое ограничение языка ассемблера: большинство инструкций не способно принимать сложные аргументы так, как LEA и MOV. Поэтому компилятор должен сначала применить MOV или LEA, сохранить результат в регистре, а затем использовать регистр в следующей инструкции.

Возвращаясь к коду, легко увидеть функцию ntdll.7C92147B, которая принимает два параметра. Напомним, что в соглашении stdcall, используемом большей частью кода Windows, параметры всегда помещаются в стек в обратном порядке. Поэтому первая инструкция PUSH, помещающая EAX, на самом деле передаёт второй параметр. Первым параметром ntdll.7C92147B получает [EBP+C], то есть второй параметр, переданный RtlInsertElementGenericTable.

Помните, как перед началом исследования универсальной таблицы я упомянул две функции, которые, по-видимому, извлекают элементы: RtlGetElementGenericTable и RtlLookupElementGenericTable? Теперь известно, что первая ищет элемент по индексу, а значит, вторая должна предоставлять некоторую возможность поиска в универсальной таблице. Рассмотрим RtlLookupElementGenericTable, см. листинг 5.8.

Рисунок 5.1. Двоичное дерево после добавления нового элемента. Он присоединён в наиболее подходящей позиции, но остальные элементы ещё не перемещались.

Рисунок 5.2. Двоичное дерево после первого шага splay-перестройки. Новый элемент поднялся на один уровень к корню, а его прежний родитель теперь стал его потомком.

Рисунок 5.3. Двоичное дерево после второго шага splay-перестройки. Новый элемент поднялся ещё на один уровень.

Рисунок 5.4. Двоичное дерево после третьего шага splay-перестройки. Новый элемент поднялся ещё на один уровень.

Листинг 5.8. Дизассемблированный код RtlLookupElementGenericTable.

Рисунок 5.5. Двоичное дерево после завершения splay-перестройки. Новый элемент стал корневым узлом, и остальная часть дерева сосредоточена вокруг него.

По имени можно предположить, что RtlLookupElementGenericTable выполняет поиск в двоичном дереве универсальной таблицы и, вероятно, принимает параметрами структуру TABLE и указатель на данные элемента. Фактическая реализация, по-видимому, находится по адресу ntdll.7C9215DA; рассмотрим эту функцию. Обратите внимание на изобретательное использование стека при вызове. Первые два параметра совпадают с переданными RtlLookupElementGenericTable. Следующие два, по всей видимости, являются указателями на некоторые выходные значения, возвращаемые ntdll.7C9215DA. Они, вероятно, не используются, но вместо выделения локальных переменных компилятор просто задействует область стека, через которую функции передавались параметры. После чтения и передачи в ntdll.7C9215DA эти ячейки больше не нужны. В листинге 5.9 приведён дизассемблированный код ntdll.7C9215DA.

Листинг 5.9. Дизассемблированный код ntdll.7C9215DA, предварительно названной RtlLookupElementGenericTableWorker.

К этому моменту мы уже настолько знакомы с универсальной таблицей, что подробно исследовать функцию почти не требуется: обсуждены две основные используемые ею функции - RtlLocateNodeGenericTable (ntdll.7C92147B) и RtlSplay. Первая фактически находит нужный элемент точно так же, как при вставке. После её возврата вызывается RtlSplay, потому что, как отмечалось ранее, splay-дерево перестраивается после добавления, удаления или поиска элемента. Разумеется, RtlSplay вызывается лишь в том случае, если RtlLocateNodeGenericTable действительно нашла искомый элемент.

По параметрам, переданным RtlLocateNodeGenericTable, сразу видно, что RtlLookupElementGenericTable принимает указатель TABLE и указатель Element. Что касается возвращаемого значения, инструкция ADD EAX, 18 показывает, что функция берёт найденный узел

и пропускает его заголовок, чтобы получить возвращаемое значение. Как и следовало ожидать, функция возвращает указатель на данные найденного элемента.

Итак, мы рассмотрели основные случаи добавления, извлечения и поиска элементов универсальной таблицы. Осталось удаление. Как элементы удаляются из универсальной таблицы? Быстро рассмотрим RtlDeleteElementGenericTable.

Листинг 5.10. Дизассемблированный код RtlDeleteElementGenericTable.

RtlDeleteElementGenericTable выполняет три основных действия. Сначала знаменитая RtlLocateNodeGenericTable (ntdll.7C92147B) находит удаляемый элемент. Затем экспортируемая функция RtlDelete фактически удаляет его. Я не стану углубляться в реализованный RtlDelete алгоритм удаления из дерева, но важно, что после удаления она также вызывает RtlSplay для перестройки таблицы.

Последний вызов RtlDeleteElementGenericTable довольно интересен. По-видимому, это обратный вызов пользовательского кода, указатель которого извлекается из смещения +20 структуры TABLE. Нетрудно догадаться, что это обратная функция освобождения элемента, которая освобождает память, ранее выделенную TABLE_ALLOCATE_ELEMENT. Вот прототип TABLE_FREE_ELEMENT:

Здесь следует отметить два обстоятельства. Во-первых, TABLE_FREE_ELEMENT явно не имеет возвращаемого значения, а если имеет, RtlDeleteElementGenericTable его определённо игнорирует: сразу после возврата обратной функции в AL записывается 1. Во-вторых, помните, что указатель Element ведёт к началу структуры NODE, а не к началу данных элемента, как во всех предыдущих случаях. Вызывающий код выделил весь блок памяти вместе с заголовком, поэтому теперь именно он должен освободить весь блок.

RtlDeleteElementGenericTable возвращает логическое значение TRUE, если RtlLocateNodeGenericTable нашла элемент, и FALSE, если та вернула NULL.

Один из базовых и сравнительно простых шагов, способный многое рассказать о работе Cryptex, - выяснить, как программа определяет правильность введённого пароля. Это также станет хорошим показателем безопасности Cryptex в зависимости от того, хранится ли пароль или какая-либо его версия непосредственно в архиве.

Проще всего исследовать проверку пароля Cryptex следующим образом: создать архив, для чего вполне подойдёт использованный ранее Test1.crx, а затем запустить Cryptex в отладчике с неправильным паролем. После этого нужно перехватить место, где программа сообщает пользователю о неверном пароле. Задача проста, поскольку из листинга 6.2 известно, что Cryptex использует функцию printf библиотеки времени выполнения. Скорее всего, удастся поймать вызов printf со строкой о неверном пароле, а затем пройти назад от него и увидеть, как Cryptex решила вывести это сообщение.

Сначала загрузите программу в любой отладчик, желательно пользовательского режима, например WinDbg или OllyDbg; лично я выбрал OllyDbg. Установите точку останова на функции printf из MSVCR71.DLL. Обратите внимание: в отличие от предыдущего исследования, где мы полагались исключительно на статический дизассемблированный листинг, теперь у нас есть настоящая программа, поэтому весь сеанс реверс-инжиниринга легко провести в отладчике.

Перед запуском программы нужно также задать параметры, чтобы Cryptex знала, какой архив требуется открыть. Пароль должен быть неправильным, иначе сообщение об ошибке не появится. В качестве команды лучше всего попросить Cryptex просто перечислить файлы архива, чтобы ничего в него не записывалось, хотя при неверном пароле программа вряд ли вообще что-либо изменит. Я использовал команду Cryptex l test1 6666666665 и установил точку останова на printf из MSVCR71.DLL: в OllyDbg для этого открыл окно Executable Modules, а затем вывел экспорт модуля в окне Names.

После запуска были перехвачены три вызова printf. Первый содержал сообщение Cryptex 1.0..., второй - Listing all file..., а третий - искомую строку ERROR: Invalid password.... Теперь остаётся лишь вернуться к вызывающему коду и найти логику, решающую, принять или отклонить переданный пароль. Остановившись на третьем вызове printf, можно нажать в OllyDbg Ctrl+F9, перейти к инструкции RET и попасть прямо в вызвавшую printf функцию. Она приведена в листинге 6.3.

Листинг 6.3. Функция проверки заголовка Cryptex, которая читает заголовок архива и проверяет заданный пароль.

Похоже, функция из листинга 6.3 выполняет некоторую проверку заголовка архива. Сначала она перемещает указатель файла в нулевую позицию с помощью API SetFilePointer, затем читает первые 0x28 байта архивного файла через ReadFile. Данные заголовка помещаются в структуру по адресу 00406058. Нетрудно увидеть, что это, по существу, какая-то глобальная переменная, а не адрес в куче или стеке, поскольку она расположена очень близко к самому коду. Беглый взгляд на окно Executable Modules показывает, что исполняемый файл Cryptex.exe загружен по адресу 00400000. Следовательно, адрес 00406058 находится внутри модуля Cryptex.exe, вероятно в секции данных. Это можно проверить, посмотрев RVA секции данных модуля в средстве просмотра исполняемых файлов, но вывод и без того очевиден.

Затем функция сравнивает первые два двойных слова заголовка с жёстко заданными значениями 70597243 и 39586554. Если хотя бы одно не совпадает, управление передаётся по адресу 0040123C и выводится сообщение ERROR: Invalid Cryptex9 signature in file header!. Быстрая проверка показывает, что шестнадцатеричное значение 70597243 соответствует символам CrYp, а 39586554 - символам TeX9. Иными словами, Cryptex просто проверяет заголовок и при несовпадении выводит ошибку.

Следующая последовательность кода - именно та, которую мы искали, поскольку она решает, вернуть ли функции 1 или вывести сообщение о неверном пароле. Последовательность сравнивает две 16-байтовые области памяти и при несовпадении печатает ошибку. Первая начинается по адресу 00405038 и является ещё одной глобальной переменной, содержимое которой пока неизвестно. Вторая начинается по адресу 00406070 и является частью уже рассмотренной глобальной переменной заголовка с началом по адресу 00406058. Это следует из того, что ранее ReadFile считывала по этому адресу 0x28 байта: 00406070 находится всего в 0x18 байта от начала, поэтому в буфере остаётся ещё 0x10, или 16 в десятичной системе, байт.

Само сравнение выполняется инструкцией REPE CMPS, которая последовательно сопоставляет пары двойных слов: на одно указывает EDI, на другое - ESI; после каждой итерации оба индексных регистра увеличиваются. Число итераций задаёт ECX. Здесь в него записано 4, то есть инструкция сравнит четыре двойных слова, или 16 байт, и при полном совпадении буферов передаст управление по адресу 00401234. Если буферы различаются, выполнение продолжится с 0040121E, где мы и оказались.

Очевидный вопрос: что именно сравнивает Cryptex в этих буферах? Не сами ли пароли? Беглый просмотр в OllyDbg показывает содержимое обоих. Вот данные глобальной переменной по адресу 00405038, с которой сравнивается буфер заголовка архива:

А буфер из заголовка архива содержит следующее:

Эти последовательности явно различаются и столь же явно не являются паролями в открытом виде. Похоже, Cryptex хранит в файле некоторую преобразованную версию пароля и сравнивает её с, вероятно, преобразованной версией введённого сейчас пароля. Чтобы схема работала, обе версии должны быть получены одним и тем же алгоритмом. Интересно выяснить, как преобразуются пароли и безопасно ли это преобразование: нельзя ли восстановить пароль, имея только изменённую версию? Если можно, пароль удастся извлечь из заголовка архива.

Проще всего найти алгоритм, превращающий открытый пароль в эту 16-байтовую последовательность, установив точку останова по обращению к памяти на глобальной переменной, где хранится введённый сейчас пароль. Это переменная по адресу 00405038, с которой в листинге 6.3 сравнивались данные заголовка. В OllyDbg точка останова по обращению к памяти устанавливается так: откройте адрес 00405038 в окне Dump, щёлкните его правой кнопкой мыши и выберите Breakpoint > Hardware > On write > Dword. Помните, что перед этим программу нужно перезапустить: к моменту вывода сообщения о неверном пароле переменная уже инициализирована.

Перезапустите программу, поставьте аппаратную точку останова на 00405038 и продолжите выполнение с прежними параметрами командной строки. Отладчик остановится где-то внутри RSAENH.DLL, Microsoft Enhanced Cryptographic Provider. Почему этот поставщик записывает данные в глобальную переменную из Cryptex.exe? Вероятно, потому, что Cryptex.exe передала ему её адрес. Посмотрим на стек и попробуем пройти назад до вызова механизма шифрования из Cryptex. При обратном просмотре стека в окне Stack видно, что сейчас выполняется API CryptGetHashParam, вызванный из функции Cryptex. Код этой функции показан в листинге 6.4.

Листинг 6.4. Функция Cryptex, вызывающая поставщика криптографических служб; 16-байтовый идентификатор пароля записывается из этой функции.

Расшифровать код листинга 6.4 будет непросто, если сначала не прочитать о назначении всех этих API хеширования. Для этого достаточно зайти на http://msdn.microsoft.com и найти функции CryptCreateHash, CryptHashData и другие. MSDN определяет хеш как "результат фиксированного размера, полученный применением математической функции (алгоритма хеширования) к произвольному объёму данных". Функция CryptCreateHash "начинает хеширование потока данных", CryptHashData "добавляет данные в заданный объект хеша", а CryptGetHashParam "получает данные, управляющие операциями объекта хеша". Обладая этим самым общим пониманием, проанализируем функцию из листинга 6.4 и попытаемся определить, что она делает.

Сначала код создаёт объект хеша вызовом CryptCreateHash. Обратите внимание на второй параметр: он выбирает алгоритм хеширования. Здесь жёстко задано значение 0x8003. Проще всего выяснить его смысл, отыскав идентификатор какого-нибудь известного алгоритма, например CALG_MD2, в заголовочном файле Crypto WinCrypt.H. Оказывается, подобные идентификаторы складываются из нескольких частей: класса алгоритма (ALG_CLASS_HASH), его типа (ALG_TYPE_ANY) и, наконец, точного подтипа (ALG_SID_MD2). Вычислив состав значения 0x8003, можно установить, что в действительности выбран алгоритм ALG_SID_MD5.

MD5, где MD означает message digest, или дайджест сообщения, - чрезвычайно популярный криптографический алгоритм хеширования, создающий из сообщения переменной длины длинный 128-разрядный хеш, или контрольную сумму. Впоследствии такой хеш позволяет однозначно идентифицировать конкретное сообщение. Два основных свойства MD5 и других криптографических хешей состоят в том, что появление двух разных сообщений с одним хешем считается крайне маловероятным, а создать сообщение с заранее заданным значением хеша практически невозможно.

Теперь определим природу хешируемых Cryptex данных. Для этого достаточно изучить вызов CryptHashData. Согласно MSDN, её второй параметр указывает на хешируемые данные. В листинге 6.4 Cryptex передаёт значение EDX, ранее загруженное из [ESP+C]. Третий параметр задаёт длину буфера, равную 0x14, или 20 байтам. Беглый просмотр буфера, на который указывает [ESP+C], показывает следующее:

Ничего очевидного: это не текст, а очередные неопознанные данные. Затем Cryptex вызывает для объекта хеша CryptGetHashParam, передавая во втором параметре значение 2. Быстрый поиск в WinCrypt.H показывает, что 2 означает HP_HASHVAL. Следовательно, Cryptex запрашивает само значение хеша, то есть результат MD5 для 20 байт по адресу 0012F5E8. Третий параметр CryptGetHashParam сообщает функции, куда его записать. Угадайте куда? В глобальную переменную по адресу 00405038, которая ранее использовалась при проверке совпадения пароля.

Подведём итог: по-видимому, Cryptex хеширует неизвестные нетекстовые данные алгоритмом MD5 и записывает результат в глобальную переменную. Позднее её содержимое сравнивается со значением, хранящимся в архиве Cryptex. При несовпадении программа сообщает о неправильном пароле. Очевидно, что хешируемые функцией из листинга 6.4 данные каким-то образом связаны с введённым паролем, однако характер этой связи пока непонятен. Неизвестные данные были переданы функции в качестве параметра вызывающим кодом.

На этом этапе происхождение буфера, хешированного в листинге 6.4, вероятно, остаётся для вас загадкой. В таких случаях обычно лучше всего идти по программе назад, пока не обнаружится источник буфера. Здесь он поступил из вызывающей функции по адресу 00402300, показанной в листинге 6.5.

Листинг 6.5. Функция Cryptex, формирующая ключ.

Функция из листинга 6.5 очень похожа на функцию из листинга 6.4. Сначала она создаёт объект хеша и хеширует некоторые данные. Одно различие состоит в параметрах инициализации объекта. В листинге 6.4 идентификатором алгоритма служило значение 0x8003, а эта функция использует 0x8004, соответствующее CALG_SHA. SHA - ещё один алгоритм хеширования со свойствами, похожими на MD5, но хеш SHA имеет длину 160 бит, тогда как MD5 - 128 бит. Можно заметить, что 160 бит составляют ровно 20 байт, то есть длину данных, хешируемых в листинге 6.4. Совпадение? Скоро выясним...

Следующая последовательность снова вызывает CryptHashData, но сначала выполняет некоторую обработку блока данных. Если поставить точку останова на этой функции и перезапустить программу, легко увидеть, что обрабатывается текст пароля, в данном случае 6666666665. Рассмотрим последовательность:

Цикл очень прост. Он читает каждый символ строки и проверяет, равен ли тот нулю. Если нет, цикл переходит к следующему символу. После его завершения EAX указывает на завершающий строку символ NULL, а ESI - на второй символ строки. Следующая инструкция даёт окончательный результат:

Здесь указатель на второй символ вычитается из указателя на завершающий NULL. Результат фактически равен длине строки без NULL, поскольку ESI содержал адрес второго символа, а не первого. Эта последовательность по существу эквивалентна функции strlen библиотеки времени выполнения C. Возникает вопрос, зачем программе реализовывать собственную strlen, а не вызывать библиотечную. Скорее всего, она всё же вызывает библиотеку, но компилятор заменяет вызов встроенной реализацией. Некоторые компиляторы поддерживают встроенные реализации популярных функций: вместо вызова функции помещают её непосредственную реализацию внутрь вызывающего кода. Это повышает производительность, устраняя накладные расходы вызова.

Измерив длину строки, функция хеширует пароль с помощью CryptHashData и извлекает полученный хеш через CryptGetHashParam. Затем значение передаётся функции по адресу 00402280, исследованной в листинге 6.4. Это любопытно: как мы уже знаем, та функция снова хеширует данные, на этот раз алгоритмом MD5. Зачем повторно обрабатывать результат одного алгоритма хеширования другим, пока неясно.

После возврата функции MD5, если она вернула ненулевое значение, код вызывает интересный API CryptDeriveKey. Согласно документации Microsoft, CryptDeriveKey "создаёт криптографические сеансовые ключи, производные от базового значения данных". Базовое значение берётся из объекта хеша; здесь это 160-разрядный хеш SHA, вычисленный из открытого пароля. При создании объекта ключа вызывающий код должен также указать применяемый алгоритм шифрования во втором параметре CryptDeriveKey. Как видно в листинге 6.5, Cryptex передаёт 0x6603. Вернувшись к WinCrypt.H, обнаруживаем, что 0x6603 означает CALG_3DES. Всё сходится и подтверждает заявленное поведение Cryptex: данные шифруются алгоритмом 3DES.

Немного подумав, можно понять, зачем Cryptex вычисляет дополнительный хеш MD5. По существу сформированный хеш SHA используется как ключ шифрования и расшифрования данных: 3DES - симметричный алгоритм, то есть обе операции выполняются одним ключом. Кроме того, Cryptex нужен простой способ определить правильность заданного пароля. Для этого программа вычисляет из хеша SHA ещё один хеш алгоритмом MD5 и сохраняет результат в заголовке файла. При открытии архива заданный пароль хешируется дважды, сначала SHA, затем MD5, и результат MD5 сравнивается с сохранённым в заголовке. Совпадение означает, что пароль правильный.

Можно спросить, почему Cryptex не записывает прямо в заголовок результат SHA и зачем тратить усилия на дополнительное хеширование. Причина в том, что хеш SHA непосредственно служит ключом шифрования; его хранение в заголовке сделало бы расшифровку архивов Cryptex невероятно простой. Это может показаться странным, поскольку извлечь исходный открытый пароль из хеша SHA невозможно, однако в таком извлечении нет нужды: для расшифровки достаточно самого хеша. Поэтому Cryptex вычисляет из значения SHA дополнительный хеш и хранит его как уникальный идентификатор пароля. Последовательность показана на рисунке 6.1.

Наконец, может возникнуть вопрос, почему проверочный хеш MD5 вычисляется не прямо из открытого пароля, а из значения SHA. Вероятная причина - пусть и отдалённая возможность того, что кто-либо сумеет преобразовать хеш MD5 в эквивалентный хеш SHA и фактически получить ключ расшифрования. Математически это почти гарантированно невозможно, но зачем рисковать? Исходные данные, то есть сформированный SHA ключ расшифрования, определённо невозможно получить из записанного в заголовке значения MD5. При разработке защитных технологий излишняя паранойя - вполне разумный образ мыслей.

Рисунок 6.1. Процесс формирования ключа и проверки пароля в Cryptex.

Получив общее представление об управлении паролями и ключами шифрования в Cryptex, можно перейти к структуре каталога. В реальной программе этот этап был бы несколько менее важен для анализа уровня безопасности Cryptex, но имел бы огромное значение для тех, кто хочет читать или создавать совместимые с Cryptex архивы. Поскольку мы выполняем упражнение по реверс-инжинирингу данных, структура каталога - именно та сложная структура данных, которую нам и нужно заполучить.

Чтобы расшифровать структуру каталога, необходимо найти в Cryptex код, который читает зашифрованные данные каталога, расшифровывает их, а затем разбирает. Для этого достаточно поставить точку останова на API ReadFile и пройти по программе вперёд, наблюдая за обработкой данных. Перезапустим программу в OllyDbg, не забыв исправить пароль в параметре командной строки, установим точку останова на ReadFile и продолжим выполнение.

Первая остановка происходит из-за внутреннего системного вызова из ADVAPI32.DLL. После продолжения отладчик снова попадает в ReadFile, но и на этот раз функция вызвана из системного кода. Очень быстро становится ясно, что вызовов ReadFile слишком много и такой подход не сработает: система интенсивно использует этот API.

Здесь в зависимости от конкретного приложения можно выбрать множество других подходов. Один из них - ограничить точку останова ReadFile вызовами для архивного файла. Сначала установите точку останова на API, который открывает или создаёт архив, вероятнее всего CreateFile, и получите из вызова дескриптор архива. Затем поставьте на ReadFile условную точку останова, срабатывающую только при передаче конкретного дескриптора архива Cryptex; большинство отладчиков поддерживает такие условия. Это резко сократит число остановок: будут видны лишь относящиеся к делу операции чтения архива, а не сотни системных вызовов.

С другой стороны, Cryptex - довольно простая программа, поэтому можно разрешить ей выполняться до функции формирования ключа из листинга 6.5. Затем достаточно пошагово пройти оставшийся код до интересных участков, разбирающих структуры каталога. Помните, что в большинстве настоящих программ придётся придумать более удачное место для точки останова: последовательный обход всей программы был бы непозволительно утомительным.

Начните с точки останова в конце функции формирования ключа по адресу 00402416. Достигнув её, вернитесь в вызывающую функцию и пройдите несколько несущественных последовательностей, включая вызов функции, которая, по-видимому, открывает архив и в итоге обращается к 004011C0, исследованной в листинге 6.3. Следующий вызов ведёт к 004019F0, и беглый просмотр показывает, что это именно искомая функция. В листинге 6.6 приведён созданный OllyDbg дизассемблированный код.

Листинг 6.6. Дизассемблированный код функции, перечисляющей все файлы архива Cryptex.

Функция начинается со знакомой последовательности чтения заголовка Cryptex в память. Это очевидно, поскольку она читает 0x28 байта от смещения 0 в файле. Затем вызывается функция по адресу 00401030, которая после входа в неё выглядит очень важной. Её дизассемблированный код приведён в листинге 6.7.

Листинг 6.7. Дизассемблированный код функции Cryptex, расшифровывающей кластер.

Функция читает из архива фрагмент фиксированного размера 4104 байта. Интересно, как вычисляется начальный адрес чтения. Полученный функцией параметр умножается на 4104, к нему прибавляется 0x28, а результат используется как смещение в файле. Это раскрывает важную деталь внутренней организации Cryptex: по-видимому, файлы делятся на блоки данных длиной 4104 байта. Прибавление 0x28 просто пропускает заголовок файла. Второй параметр функции, судя по всему, является номером блока, который требуется прочитать.

После чтения в память данные расшифровываются функцией CryptDecrypt. Как и ожидалось, параметр длины данных, шестой параметр этой функции, снова жёстко равен 4104. Интересно сообщение, печатаемое при ошибке: из него следует, что функция пытается прочитать и расшифровать кластер, вероятно просто так причудливо названы выделенные нами блоки фиксированного размера. При успешном выполнении CryptDecrypt функция возвращается к вызывающему коду и выдаёт адрес только что расшифрованного блока.

Мы предполагаем, что только что прочитанный блок представляет каталог файлов архива или другую часть его заголовка. Следующий шаг - изучить расшифрованный блок и установить его структуру. Ниже показан дамп памяти с содержимым блока, полученного при попытке перечислить файлы созданного ранее архива Test1.crx.

Как видно, мы попали куда нужно: блок памяти содержит имя asterisks.txt, ранее зашифрованное в этом архиве. Но что находится в 28 байтах перед именем? Сразу стоит попробовать другое представление данных. В предыдущем дампе применялся вид ASCII, чтобы было видно имя файла, однако остальные поля, возможно, проще различить в 32-разрядном представлении. Вот первые 28 байт как последовательность 32-разрядных шестнадцатеричных чисел:

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

Код чтения таблицы файлов и вывода списка показан в листинге 6.6. Анализировать его довольно просто, поскольку прочитанные поля выводятся на экран и легко понять их назначение. Вернёмся к этой последовательности и посмотрим, что она делает с записью файла.

Сначала последовательность загружает в ESI начальный адрес только что расшифрованного блока, прибавляет 8 и читает находящийся там 32-разрядный элемент в EAX. В предыдущем дампе третье двойное слово равно 00000001. Код убеждается, что EAX не равен нулю, а затем выполняет над ним любопытную серию арифметических операций.

Сначала EDX сдвигается влево на 0xA, или 10 бит, после чего из результата вычитается исходное значение из EAX. Затем значение EDX складывается с самим собой, что равносильно умножению на два. Эта операция повторяется по адресу 00401A82, после чего выполняется сдвиг вправо на 0xA, или 10 бит. Разберём действия по порядку и попытаемся определить их назначение.

1. EDX сдвигается влево на 10 разрядов, что эквивалентно edx = edx * 1024.

2. Исходное число из EAX вычитается из EDX. Следовательно, вместо умножения на 1024 фактически выполняется edx = edx * 1024 - edx, то есть edx = edx * 1023.

3. Затем EDX дважды складывается с самим собой. Это эквивалентно edx = edx * 4, поэтому к этому моменту фактически вычислено edx = edx * 4092.

4. Наконец, EDX сдвигается вправо на 10 разрядов, что равносильно делению на 1024. Итоговая формула: edx = edx * 4092 / 1024.

Можно спросить, почему Cryptex не применила MUL, чтобы умножить EDX на 4092, а затем DIV для деления результата на 1024. Причина в том, что такой код выполнялся бы гораздо медленнее только что рассмотренного. Обе инструкции, MUL и DIV, сравнительно медленны, тогда как ADD, SUB и сдвиги намного быстрее. Последовательность раскрывает интересный факт о Cryptex: скорее всего, при компиляции был выбран режим оптимизации по скорости, а не по размеру. Прямые арифметические инструкции деления и умножения создали бы меньший, но более медленный код. Компилятор явно стремился к высокой производительности даже ценой некоторого увеличения исполняемого файла.

Результат этой небольшой арифметической последовательности передаётся прямо в printf, которая выводит текущую запись файла. Это многое объясняет: Cryptex вычисляла размер файла. Поскольку тот печатается в килобайтах, очевидно, что итоговое деление на 1024 просто преобразует байты в килобайты. Но что представляло собой исходное число и зачем программа умножала его на 4092? По-видимому, размер файла хранится через некоторое количество блоков фиксированного размера, вероятно связанных с кластером, встреченным при расшифровке буфера. Проблема в том, что прежний кластер имел длину 4104 байта, а теперь речь идёт о кластерах по 4092 байта. Причина различия пока неясна.

Исходное число кластеров было взято со смещения +8 текущей структуры записи, значит, там хранится размер файла в кластерах. Тогда где Cryptex хранит точный размер? Восстановить зашифрованный файл без первоначальной точной длины невозможно, поэтому она должна быть записана где-то ещё в архиве.

Помимо размера, printf получает имя файла. Его адрес легко вычисляется как смещение +14 от ESI. Следует помнить, что ранее ESI уже был увеличен на 8, поэтому в исходной структуре это фактически смещение +1C. Оно совпадает с дампом данных, где строка начиналась по смещению +1C.

После вывода имени и размера программа возвращается к началу цикла для следующей записи. Чтобы перейти к ней, Cryptex увеличивает ESI на 0x98, то есть 152 байта, что явно является длиной записи. Следовательно, под имя каждого файла отведено фиксированное число символов. Поскольку строка начинается в структуре со смещения +14, можно предположить, что после неё других элементов нет. Тогда максимальная длина имени файла в Cryptex равна 152 - 20, или 132 байтам.

После завершения цикла происходит нечто интересное. Проверяется первый элемент ранее прочитанного и расшифрованного буфера. Если он ненулевой, Cryptex вызывает функцию 00401030 из листинга 6.7, читающую и расшифровывающую уже исследованный фрагмент данных. Второй параметр, используемый как номер кластера, ведь функция умножает его на 4104, берётся непосредственно из первого элемента. Очевидно, программа читает и расшифровывает следующий блок, а затем ищет в нём файлы. Похоже, список файлов может занимать произвольное число кластеров и реализован как своего рода связный список. Возникает вопрос: не задан ли первый кластер жёстко как кластер номер один? Посмотрим на первоначальный вызов чтения первого кластера списка файлов из листинга 6.6.

Индекс первого кластера берётся из глобальной переменной со знакомым адресом. Оказывается, 00406064 является частью заголовка Cryptex, загруженного в 00406058 несколькими строками выше. Значит, смещение +0C в заголовке Cryptex хранит индекс первого кластера таблицы файлов.

Вернёмся к листингу 6.7. После возврата из 00401030 значение ESI снова проверяется на ненулевое, хотя оно уже проверялось и не могло измениться. Если оно ненулевое, Cryptex возвращается к коду чтения таблицы файлов. Теперь известно, что первый элемент кластеров таблицы файлов указывает на следующий кластер с последующими записями, если тот существует. Поскольку каждая запись имеет фиксированный размер, их число в кластере также должно быть постоянным. Локальная переменная [ESP+14] считает оставшиеся элементы текущего кластера. Легко найти инструкцию 00401A67, которая присваивает ей 0x1A, или 26 в десятичной системе. Следовательно, каждый кластер вмещает до 26 записей.

Наконец, важно обратить внимание на три до сих пор проигнорированные строки листинга 6.6.

Похоже, чтобы Cryptex обработала запись, значение по смещению +8 должно быть ненулевым. Как мы недавно установили, там хранится размер файла в кластерах, то есть программа просто проверяет, что размер не равен нулю. Возможность пропускать записи означает, что Cryptex допускает пустоты в списке файлов: при удалении она лишь помечает запись и не копирует остальные. Встретив удалённую запись, программа просто игнорирует её, что и видно в этом коде.

Именно такого, вероятно, не встретишь в надёжном коммерческом защитном продукте. Не стирая блоки данных, Cryptex создаёт небольшую угрозу безопасности. Конечно, "удалённые" кластеры, вероятно, остаются зашифрованными, поскольку Cryptex вообще не должна помещать открытые данные в архивы, но в них может храниться конфиденциальная информация. Предположим, вы отправляете архив Cryptex человеку, которому известен пароль. Поскольку удалённые файлы способны оставаться внутри архива, вместе с нужными материалами можно невольно передать то, что вы считали удалённым.

Что нужно сделать, чтобы действительно вывести список файлов архива Cryptex? Задача не так сложна. Для правильного получения списка требуется выполнить следующие шаги:

1. Инициализировать Crypto API и открыть файл архива.

2. Проверить 8-байтовую сигнатуру заголовка.

3. Вычислить хеш SHA введённого пароля, а затем хеш MD5 от результата.

4. Убедиться, что вычисленный хеш MD5 совпадает с сохранённым в заголовке Cryptex по смещению +18.

5. Сформировать ключ 3DES с помощью объекта хеша SHA.

6. Прочитать первый кластер списка файлов, индекс которого хранится в заголовке Cryptex по смещению +0C, так же, как это делает Cryptex: прочитать 4104 байта и расшифровать их ключом 3DES.

7. Обойти 152-байтовые записи и вывести имя каждой, если её значение по смещению +8, то есть размер файла в кластерах, ненулевое.

8. Если присутствуют дополнительные кластеры списка файлов, прочитать и расшифровать их, а затем вывести все содержащиеся там записи.

Код, реализующий эту последовательность, сравнительно прост. Если вы хотите его посмотреть, он доступен на веб-сайте книги: www.wiley.com/go/eeilam.

Без возможности расшифровывать и извлекать файлы из зашифрованных архивов Cryptex была бы не слишком полезна. Для этого служит команда x: она создаёт файл с тем же именем, что у первоначально зашифрованного, но без пути, и расшифровывает в него исходные данные. Реверс-инжиниринг процесса извлечения должен прояснить структуру данных списка файлов и способ хранения самих файлов в архиве. Довольно длинный листинг 6.8 содержит процедуру извлечения файлов Cryptex.

Листинг 6.8. Дизассемблированный код процедуры Cryptex, расшифровывающей и извлекающей файл.

Начнём с краткого обзора важнейших операций функции из листинга 6.8. Сначала она открывает архив вызовом функции по адресу 00401670, которая затем обращается к функции проверки заголовка и пароля 004011C0, исследованной в листинге 6.3. После возврата из 00401670 создаётся объект хеша того же вида, который ранее использовался для вычисления хеша пароля. На этот раз тип алгоритма равен 0x8003, то есть ALG_SID_MD5. Назначение объекта пока неясно. Затем код читает заголовок Cryptex в уже встречавшуюся глобальную переменную 00406058 и ищет в списке файлов нужную запись.

Список файлов просматривается вызовом функции по адресу 004017B0. Она идёт уже знакомым путём: обходит список и сравнивает каждое имя с именем извлекаемого файла. Найдя нужный элемент, функция получает несколько полей записи. Ниже приведён код, выполняемый процедурой поиска после обнаружения записи.

Прежде всего рассмотрим явно оптимизированную арифметическую последовательность в начале. Из-за применения LEA она может показаться запутанной, но эта инструкция необязательно работает именно с адресами. LEA по адресу 00401885 фактически умножает ESI на 5 и сохраняет результат в EAX. Вернувшись к началу функции, легко заметить, что ESI используется как счётчик: сначала равен нулю, затем увеличивается на единицу при обходе каждого элемента. После просмотра всех записей текущего кластера, которых, как мы помним, 0x1A, он снова обнуляется. Следовательно, ESI является индексом текущей записи в текущем кластере.

Вернёмся к арифметике. Мы уже установили, что первая LEA умножает ESI на 5. За ней следуют две ADD, каждая фактически удваивает полученное значение. В итоге ESI умножается на 20, а затем из результата вычитается его исходное значение, что равносильно умножению на 19. Прелестно, правда? Следующая строка по адресу 0040188E использует результат в EAX как индекс, но перед этим умножает его на 8. То есть индекс текущей записи ESI умножается на 19 * 8 = 152. Число знакомое: 152 байта составляет длина записи файла. Вычисляя [ECX+EAX*8+8], Cryptex получает значение по смещению +8 текущей записи.

Уже известно, что смещение +8 содержит размер файла в кластерах. Это значение возвращается вызывающему коду через переданный для него параметр: размер нужен Cryptex для извлечения файла. Загрузив его, программа проверяет ещё один, по-видимому выходной, параметр по адресу [ESP+28]. Если тот ненулевой, Cryptex копирует в переданный указатель значение записи со смещения +C, затем копирует смещение +10 по смещению +4 указателя и так далее, пока не будут перенесены четыре двойных слова, или 16 байт. Напомним, именно эти 16 байт выглядели как мусор в дампе списка файлов. Перед возвратом функция загружает смещение +4 текущей записи в EAX, тем самым возвращая его вызывающему коду.

Итак, последовательность ищет в списке заданное имя и после обнаружения возвращает три отдельных элемента: размер файла в кластерах, неизвестную на вид случайную 16-байтовую последовательность и ещё одно неизвестное двойное слово со смещения +4. Посмотрим, как процедура извлечения использует эти данные.

После возврата из 004017B0 Cryptex ищет в заданном имени файла обратные косые черты, пока не достигнет последней. Поиск выполняет функция strchr библиотеки времени выполнения C, которая возвращает адрес первого вхождения символа, если он найден. Адрес за последней обратной косой чертой сохраняется в [ESP+20]; это "чистое" имя без пути. В этой в остальном тривиальной последовательности привлекает внимание инструкция по адресу 00401C9E.

Возможно, вы помните похожую инструкцию из предыдущей главы. Там она служила инфраструктурой для перехвата системных API Windows. Здесь это объяснение не подходит, так зачем компилятор вставил в середину функции ничего не делающую инструкцию? Ответ прост: адрес её начала не выровнен, то есть не находится на 32-разрядной границе. Выполнение невыровненных инструкций, как и вообще обращение к невыровненным адресам памяти, занимает у 32-разрядного процессора больше времени. Поместив эту инструкцию перед циклом, компилятор обеспечил выровненное начало цикла. Он снова мог использовать NOP, но выбрал бездействующую инструкцию, точно заполняющую двухбайтовый промежуток.

Получив имя без обратных косых черт, функция создаёт новый файл для извлечённых данных. Затем она проверяет, нашла ли 004017B0 запись, исследуя EBP, где хранится возвращённое значение. Если оно нулевое, Cryptex выводит сообщение о ненайденном файле и завершает работу. При ненулевом EBP вызывается знакомая функция 00401030, которая читает и расшифровывает сектор. EBP, то есть результат 004017B0, передаётся вторым параметром и рассматривается как номер кластера.

Теперь известно, что 004017B0 возвращает индекс кластера, хотя пока не установлено, какого именно. Нетрудно догадаться, что это индекс кластера извлекаемого файла или по меньшей мере его первого кластера, поскольку большинство файлов, вероятно, занимают больше одного. В функции поиска это возвращаемое значение поступало со смещения +4 записи, что видно по инструкции 004018BC. Значит, смещение +4 содержит индекс первого кластера данных.

В отладчике видно, что третий параметр является указателем на место расшифрования данных, а после возврата функции буфер содержит наши замечательные звёздочки. Важно, что им предшествует четырёхбайтовое значение 0000046E. Быстрое преобразование показывает: это 1134, точный размер исходного файла asterisks.txt, зашифрованного ранее.

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

Последовательность необычна из-за множества ещё не встречавшихся инструкций. Что они означают? Быстрое обращение к справочнику Intel IA-32 Instruction Set Reference [Intel2], [Intel3] показывает, что большинство выполняет арифметику с плавающей точкой. Сначала FILD загружает обычное 32-разрядное целое из [ESP+2C], где хранится общее число кластеров файла, преобразует его в 80-разрядное число двойной расширенной точности и помещает в специальный стек плавающей точки. Этот стек представляет собой набор регистров для используемых процессором значений с плавающей точкой. Его можно считать простой группой регистров, распределением которых управляет ЦП.

Следующая такая инструкция, FADD, выполняется только при отрицательном значении [ESP+2C]. Она прибавляет к вершине стека непосредственное число с плавающей точкой из 00403BA0. В отличие от FILD, загружающей целое, FADD использует число с плавающей точкой в памяти. Поэтому обычный дамп 00403BA0 как 32-разрядного целого показывает 4F800000, но это не имеет смысла: операнд нужно представить как 32-разрядное число с плавающей точкой. В таком виде OllyDbg показывает 4.294967e+09.

Значение может казаться бессмыслицей, но это не так. Тренированный глаз сразу заметит подозрительное сходство с 2^32, то есть 4 294 967 296. На самом деле числа идентичны. Идея проста: по-видимому, FILD всегда считает целые знаковыми, тогда как исходная программа объявила преобразуемое значение беззнаковым. Чтобы процессор получил правильное значение, компилятор сгенерировал код, прибавляющий 2^32, когда установлен старший бит. Так отрицательное знаковое число в стеке превращается в положительное значение, которым оно должно было быть изначально.

Исправив число, Cryptex инструкцией FDIVR делит константу из 00403B98 на вершину стека. Согласно документации Intel, на этот раз константа является 64-разрядным числом с плавающей точкой. Если попросить OllyDbg показать данные с 00403B98 в таком виде, получится 100.0000000000000. Следовательно, Cryptex делит 100,0 на общее число кластеров.

Следующая инструкция загружает адрес имени файла из [ESP+24] в EAX, а затем выполняется необычная XORPS с операндом XMM0. Эта инструкция относится к отдельному набору SSE2, который поддерживается большинством современных реализаций IA-32. SSE2 содержит инструкции Single Instruction Multiple Data (SIMD), способные одновременно обрабатывать несколько групп операндов. Они значительно ускоряют требовательные вычисления, например в мультимедийных приложениях и программах создания содержимого. XMM0 - первый из восьми специальных 128-разрядных регистров XMM0-XMM7. Доступ к ним возможен лишь инструкциями SSE, а содержимое обычно состоит из нескольких меньших операндов. Здесь XORPS выполняет XOR всего содержимого первого регистра SSE с ним самим, то есть просто обнуляет XMM0.

Следующая FSTP сохраняет значение с вершины стека плавающей точки в [ESP+34]. Предшествующее адресу DWORD PTR показывает, что память рассматривается как 32-разрядная, поэтому значение преобразуется в 32-разрядное представление с плавающей точкой. Напомним, сейчас на вершине находится результат предыдущего деления.

Теперь начинается очевидный цикл, который последовательно читает и расшифровывает дополнительные кластеры через 00401030, хеширует данные функцией CryptHashData и записывает блок в ранее открытый файл посредством API WriteFile.

Здесь легко понять назначение всей арифметики с плавающей точкой. После расшифрования каждого кластера Cryptex печатает точное значение процента уже записанной части файла. Разделив 100,0 на общее число кластеров, она вычислила шаг, на который после каждой записи увеличивается текущая доля выполнения.

Интересно, как Cryptex узнаёт индекс следующего кластера. Поскольку программа разрешает удалять файлы из архивов, их кластеры необязательно расположены последовательно. Поэтому при чтении следующего кластера Cryptex всегда получает его индекс из 00405050 и передаёт функции 00401030. Адрес 00405050 является началом буфера текущего кластера. Значит, как и в списке файлов, первое двойное слово хранит индекс следующего кластера цепочки. Одна любопытная сторона схемы раскрывается следующими строками.

В любой момент цикла EDI содержит число оставшихся кластеров. Если осталось больше одного, то есть EDI > 1, количество читаемых байт в EAX жёстко равно 0xFFC, или 4092 байтам, вероятно максимальному объёму данных кластера. При записи последнего кластера Cryptex берёт число байт из первого двойного слова, оттуда же, где обычно хранится индекс следующего кластера. Понимаете? Поскольку программа знает, что кластер последний, место для следующего индекса не используется, и там можно сохранить фактическое число байт. Так Cryptex обходит отсутствие непосредственно записанного размера файла, храня лишь количество занимаемых им кластеров.

Расшифровав и записав последний кластер, Cryptex вызывает CryptGetHashParam, чтобы получить MD5, вычисленный по всем расшифрованным данным. Он сравнивается с 16-байтовой последовательностью, возвращённой из 004017B0; напомним, она была взята из записи файла в таблице. При несовпадении Cryptex сообщает, что файл повреждён. Очевидно, MD5 используется как обычная контрольная сумма: для каждого шифруемого файла вычисляется хеш, а при извлечении программа убеждается, что данные внутри архива не изменены.

Уязвимость - по существу ошибка или изъян программы, нарушающий безопасность самой программы и обычно всего компьютера, где она выполняется. Иными словами, это дефект, которым может воспользоваться злоумышленник. Чаще всего уязвимости начинаются с кода, принимающего сведения из внешнего мира. Это могут быть любые пользовательские данные: параметры командной строки, загруженный файл или сетевой пакет.

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

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

Во многих случаях уязвимость подвергает риску целую сеть: проникновение через её внешнюю оболочку часто означает преодоление последней линии обороны.

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

Ещё один вид переполнения, позволяющий захватить программу или всю систему, - malloc exploit, или переполнение кучи [anonymous], [Kaempf], [jp]. Общая идея та же, что у переполнения стека: программа получает данные неожиданной длины и копирует в слишком маленький буфер. В результате перезаписывается всё, что следует в памяти за блоком кучи. Обычно кучи организованы как связные списки, а указатели на следующий и предыдущий блоки находятся непосредственно перед данными или после них. Выход за границу повреждает список. Чаще всего программа аварийно завершается, как только диспетчер кучи обходит его, например при освобождении блока, но тщательно выполненное переполнение позволяет захватить систему.

Атакующий может воспользоваться структурой связного списка кучи, чтобы перезаписать некоторый адрес в пространстве процесса. Реализация сложна, но принцип довольно прост. Каждый блок имеет элементы next и prev; изменив их, можно записать произвольное значение по произвольному адресу.

Представьте удаление элемента из двусвязного списка. Система должна исправить связи двух соседей, предыдущего и следующего, чтобы они указывали друг на друга, а не на удаляемый элемент. При удалении код записывает адрес next в заголовок предыдущего элемента, причём оба адреса берёт из заголовка удаляемого, и адрес prev - в заголовок следующего. Осторожно подменив значения next и prev одного элемента, атакующий в некоторых случаях может перезаписать стратегически важные адреса процесса. Конечно, запись происходит не сразу, а только при освобождении повреждённого элемента.

Следует отметить, что переполнения кучи встречаются реже стековых, поскольку размеры её блоков почти всегда вычисляются динамически так, чтобы вместить входные данные. В отличие от стековых буферов с заранее заданным размером, буферы кучи динамические, в этом и состоит её смысл. Поэтому программисты редко жёстко задают размер блока при входе переменной длины. Обычно проблема возникает из-за неверного расчёта числа байт, необходимого для пользовательского буфера.

Исторически значительная доля атак переполнения связана со строками. Самый распространённый пример - применение функций библиотеки времени выполнения для копирования или иной обработки строк с предоставлением самой функции определять объём записи. Это уже показанный случай strcpy, когда внешняя сторона задаёт строку, копируемую в буфер фиксированного размера. Поскольку strcpy останавливается лишь на завершающем NULL, вызывающий код может передать слишком длинную строку и вызвать переполнение.

Что произойдёт, если строка атакующего до достижения уязвимой функции внутренне преобразуется в Unicode, как большинство строк Win32? Тогда нужно передать последовательность символов ASCII, которая превратится в работоспособный shellcode после преобразования. Фактически между каждыми двумя заданными байтами кода появится нулевой байт. Возможно, вы удивитесь, но написать shellcode, работающий после преобразования в Unicode, действительно можно. Процесс его разработки в столь враждебной среде рассматривается в [Obscou]. Что тут скажешь: атаковать нелегко.

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

Вирусы - самовоспроизводящиеся программы, обычно имеющие злонамеренную цель. Это старейшая разновидность malware, ставшая несколько менее популярной с появлением Интернета. Уникальная черта вируса, отличающая его от обычных программ, - самовоспроизведение. Какая ещё программа при каждой возможности создаёт собственные копии? За прошедшие годы существовало множество вирусов: вредные удаляли ценную информацию или блокировали компьютер, а безобидные просто выводили раздражающие сообщения, пытаясь привлечь внимание пользователя.

Обычно вирусы присоединяются к исполняемым файлам, например .exe в Windows, и постепенно копируют себя во многие программы заражённой системы. Как только заражённый файл передают и запускают на другом компьютере, тот также становится инфицированным. Поэтому вирусам почти всегда требуется какое-либо участие человека: они не могут просто "перетечь" на соседнюю машину. Настоящие вирусы сегодня довольно редки. Интернет является настолько привлекательной средой распространения, что почти всякая вредоносная программа так или иначе им пользуется. Malware, распространяющееся через Интернет, обычно называют червём.

По существу червь похож на вирус: это самовоспроизводящаяся вредоносная программа. Различие в том, что червь копирует себя по сети, например через Интернет, без непосредственного участия человека. Всё может происходить в фоновом режиме, пользователю даже не нужно прикасаться к компьютеру. Нетрудно представить, что черви обладают уже доказанной способностью бесконтрольно распространяться за удивительно короткое время. В мире, где почти все системы подключены к одной сети, им очень легко искать и заражать новые машины.

Черви используют несколько методов распространения. Современный червь может воспользоваться уязвимостью операционной системы или приложения, позволяющей спрятаться в с виду безобидном пакете данных. Такие дефекты рассматривались в главе 7. Атакующие применяют их по-разному, но чаще всего именно для создания червей. Другой распространённый путь - электронная почта. Черви массовой рассылки обычно просматривают список контактов и отправляют себя каждому адресату. Конкретное поведение зависит от почтовой программы, однако чаще всего получатель должен вручную открыть заражённое вложение. Атаки через уязвимости, напротив, редко требуют действий пользователя.

Наверняка вы слышали историю троянского коня. Общая идея такова: безобидный предмет открыто вносят через главные ворота, хотя внутри скрывается нечто вредоносное. В мире ПО это с виду невинные файлы с тайным вредоносным кодом. Большинство троянских программ действительно выполняет полезную функцию, поэтому пользователь не замечает проблемы: видимая часть работает нормально, а скрытая за его спиной продвигает интересы атакующего.

Спрятать нежелательную функцию внутри полезной программы очень просто. Элегантный способ - встроить вредоносный элемент в остальном безобидное приложение. Жертва получает заражённую программу, запускает её и остаётся в полном неведении. Первоначальная функция продолжает работать, не вызывая подозрений.

Менее изящный, но эффективный способ - заставить пользователя поверить, что вредоносная программа является обычным файлом, например видеороликом или изображением. Особенно легко сделать это в Windows, где тип определяется расширением, а не фактическим анализом заголовка. Работает даже нелепый трюк: скрыть настоящее расширение после пары сотен пробелов. Рассмотрим имя "A Great Picture.jpg .exe". Программа просмотра может не вместить его целиком и показать что-то вроде "A Great Picture.jpg ...", скрыв, что это исполняемый файл, а не JPEG. Windows обычно всё же показывает значок приложения, но иногда использует значок, встроенный в исполняемый файл. Достаточно создать программу со стандартным значком изображения Windows и дать ей похожее имя.

Лазейка, или backdoor, - вредоносное ПО, создающее обычно скрытый канал, через который атакующий подключается к системе жертвы, управляет ею, наблюдает или иным способом взаимодействует. Некоторые лазейки являются отдельными программами: после запуска они позволяют удалённо подключиться и выполнять различные действия. Другие изначально внедряет в исходный код недобросовестный разработчик. Если вы думаете, что поставщики тщательно проверяют исходники перед выпуском продукта, подумайте ещё раз. Общее правило гласит: если работает, беспокоиться не о чем. Даже при ручной проверке лазейку можно спрятать настолько глубоко, что заметит её лишь чрезвычайно острый глаз. Именно такие проблемы делают открытое ПО привлекательным: в продуктах с открытым кодом подобное случается редко.

Мобильный код - класс безобидных программ, специально предназначенных для перемещения и выполнения на множестве систем без явной установки конечным пользователем. Большинство современных мобильных программ делает просмотр веб-страниц более активным. Сюда относятся интерактивные апплеты Java и элементы ActiveX, позволяющие сайтам встраивать быстро реагирующую анимацию, трёхмерные презентации и другое содержимое. В зависимости от платформы такие программы позволяют сайту быстро загрузить и запустить код в системе пользователя. В большинстве, но не во всех случаях появляется подтверждение локальной установки и запуска. Тем не менее, как уже говорилось, многие нажимают кнопку "автоматически", даже не задумываясь, что загружаемый код может быть вредоносным.

Термин "мобильный код" определяет лишь способ распространения, а не технические детали выполнения. Некоторые виды, например сценарии Java, передаются как исходный код и потому разбираются намного легче. Другие, например компоненты ActiveX, являются обычными исполняемыми PE-файлами с машинным кодом IA-32; вероятно, их анализировать сложнее всего. Наконец, апплеты Java и некоторые другие компоненты распространяются в виде байт-кода, весьма уязвимого для декомпиляции и реверс-инжиниринга.

Это сравнительно новая, но чрезвычайно популярная категория. В неё входит несколько видов программ, из которых, вероятно, самые распространённые относятся к adware. Рекламное ПО принудительно показывает пользователям нежелательные объявления. Оно собирает статистику просмотра сайтов и покупательских привычек, иногда отправляя её на центральный сервер, а затем демонстрирует целевую рекламу. Adware распространяется разными способами, но главным остаётся включение в бесплатное ПО, которое фактически финансируется показом объявлений.

У таких программ есть несколько проблем, превращающих их в серьёзную неприятность и способных полностью испортить работу на заражённой системе. Во-первых, реклама может появляться из ниоткуда независимо от действий пользователя, сильно отвлекая и раздражая. Во-вторых, взаимодействие с операционной системой и браузером обычно настолько агрессивно и плохо реализовано, что снижает производительность и устойчивость. Например, Internet Explorer на заражённой машине нередко надолго зависает лишь потому, что шпионская DLL написана небрежно и неправильно использует многопоточность. Интересно, что это не намеренно: разработчики adware/spyware просто неосторожны и создают ошибочный код.

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

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

Другой подход - разбросать копии вредоносного механизма по различным компонентам системы, например дополнениям браузера. Каждый компонент постоянно проверяет наличие остальных и немедленно переустанавливает повреждённый или удалённый.

Многие уже говорили следующее, и это становится очевидным: сегодняшнее malware - лишь вершина айсберга, оно может быть намного разрушительнее. В будущем вредоносные программы способны захватывать системы на столь низком уровне, что создать противоядие будет трудно: malware станет владеть платформой и сможет управлять самим антивирусом. Кроме того, однажды реальностью могут стать черви, похищающие сведения, позволяя украсть ценную информацию жертвы и потребовать за неё выкуп.

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

Криптография прекрасна, но иногда её можно использовать во зло. Современное malware применяет её не слишком часто, однако это легко изменится. Асимметричное шифрование открывает новые возможности для червей, похищающих сведения [Young]. Такие программы распространялись бы подобно обычным червям, но находили в заражённой системе ценные данные, например документы и базы, и похищали их. Кража осуществлялась бы посредством асимметричного шифра, использующего пару ключей. Один, открытый, шифрует данные, другой, закрытый, расшифровывает. Получить один ключ из другого невозможно.

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

Реализовать идею, конечно, сложно. Вероятно, главная задача с точки зрения атакующего - потребовать выкуп и обменять на него ключ, сохранив полную анонимность. В [Young] обсуждаются несколько теоретических подходов, включая доказательства с нулевым разглашением, которые позволяют подтвердить обладание ключом расшифрования, не раскрывая его.

Большинство стратегий защиты исходит из существования в системе доверенного элемента. Как антивирусу обнаруживать malware, если нельзя доверять основе? Представим программу, которая сканирует диск и читает файлы высокоуровневыми службами файловой системы. Умная вредоносная программа сравнительно легко установит себя как фильтр и перехватит вызовы антивируса, показывая поддельные версии файлов, обычно первоначальные незаражённые копии. Так она скроет факт заражения множества файлов.

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

Именно здесь всё может стать по-настоящему плохо. Что произойдёт, если вредоносная программа изменит компонент чрезвычайно низкого уровня? Антивирус выполнялся бы поверх заражённой основы и не смог бы определить, видит ли настоящую систему или искусственную картину, нарисованную скрывающейся программой. Рассмотрим, как это возможно.

Теоретически самый низкий уровень заражения - процессор или другое устройство с обновляемой микропрограммой. Большинство современных ЦП фактически выполняет низкоуровневый код, реализующий каждую ассемблерную инструкцию посредством микроопераций, micro-ops, или µ-ops. Работающий внутри процессора код называется firmware и обычно обновляется на месте специальной программой. Это разумное решение: ошибки исправляются программно без физической замены процессора. То же относится ко многим устройствам, например сетевым адаптерам и контроллерам хранения, основанным на программируемых микроконтроллерах с обновляемой пользователем микропрограммой.

Не вполне ясно, что именно способна сделать вредоносная микропрограмма, но перспективы пугают. Теоретически она станет частью более крупного malware и поможет скрывать его от средств защиты, нарушая целостность единственного доверенного компонента компьютера - аппаратуры. На практике реализовать атаку нелегко. Файлы обновлений процессоров Intel, по-видимому, зашифрованы, причём ключ надёжно спрятан внутри процессора, а точное содержимое неизвестно. Подробнее тема рассматривается в книге Ed Skoudis и Lenny Zeltser Malware: Fighting Malicious Code [Skoudis].

Людей побуждают создавать malware разные мотивы. Одни разработчики руководствуются интересом и получают от распространения финансовую выгоду. Других ведут психологические импульсы или детское желание победить систему. Классифицировать программу по её действиям трудно. Обнаружив лазейку, открывающую доступ к файлам заражённых машин, невозможно понять, создана ли она для кражи ценных корпоративных данных или чтобы подсматривать личные файлы отдельного человека.

Рассмотрим самые типичные цели вредоносных программ и мотивы их авторов.

Это распространённая конечная цель. Атакующий получает неограниченный доступ к заражённой машине и использует её для самых разных задач.

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

Иногда люди действуют из чистого вандализма. Удаление ценных файлов жертвы или иной ущерб дают атакующему удовлетворение и чувство собственной значимости. Людям свойственно стремление повлиять на мир, но, к сожалению, некоторым безразлично, будет воздействие положительным или отрицательным.

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

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

Malware страдает той же основной проблемой, что технологии защиты от копирования: оно выполняется на недоверенной платформе и потому уязвимо для реверс-инжиниринга. Логика и функции вредоносной программы фактически открыты для всеобщего просмотра. Шифрование не решает проблему, поскольку процессор системы всегда должен иметь возможность расшифровать код и данные. Как только это сделано, исследователь может анализировать поведение; простого способа избежать этого нет.

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

После обнаружения malware исследователи начинают анализировать и препарировать его. Большая часть работы представляет обычный реверс-инжиниринг, но часто применяются системные средства наблюдения за сетью и файлами, раскрывающие действия без ручного изучения кода. Всё же самым мощным методом остаётся анализ на уровне кода, поэтому авторы иногда пытаются ему помешать антиреверсивными приёмами. Они запутывают и усложняют программу, увеличивая время исследования. Важно помнить, что большинство таких методов ограничено: они способны лишь затруднить процесс, но не предотвратить его. Подробно они рассматриваются в главе 10.

Проще всего антивирусу опознавать вредоносные программы по уникальным сигнатурам. Он хранит часто обновляемую базу, стремящуюся содержать уникальный идентификатор каждого известного malware. Идентификация основывается на характерной последовательности, найденной в конкретном варианте программы.

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

У решения есть две серьёзные слабости. Во-первых, многие антивирусы ищут сигнатуры в памяти, где программа обычно присутствует в исходном незашифрованном виде. Во-вторых, статичным остаётся сам код расшифрования. Чтобы выполняться, программа обязана раскрыть себя в памяти, и теоретически сигнатурой может стать этот механизм.

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

Почти тривиальный способ затруднить обнаружение - случайно менять используемые регистры. Последовательность применяет их независимо на нескольких этапах. Например, инструкции 00403448 и 0040344E загружают в EAX значения для последующих действий. Легко сделать так, чтобы первая использовала один регистр, а вторая другой. Столь же просто заменить базовый указатель кадра стека EBP другим регистром общего назначения.

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

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

В качестве практического примера выбрана троянская лазейка Backdoor.Hacarmy.D. Это сравнительно простое malware, которое легко исследовать и, самое важное, не имеет автоматического механизма самовоспроизведения. Поэтому изучение не приведёт к дальнейшему распространению. Однако пренебрегать описанными мерами безопасности нельзя: программа остаётся вредоносной и требует уважительного обращения.

По существу это троян, часто распространяемый как безобидная картинка под разными именами. Моя копия называлась Webcam Shots.scr. Расширение SCR предназначено для экранных заставок, но те являются обычными программами; теоретически можно создать текстовый процессор .scr, и он будет работать. Трюк эффективен потому, что некоторые программы, например почтовые клиенты, по глупости показывают для таких файлов значок картинки, а не приложения. Пользователь может принять программу за изображение. Простое решение - специальное предупреждение при загрузке исполняемого файла через веб или почту. Конкретные имена различаются. В одних сообщениях, обычно отправленных в группы новостей, файл выдавали за фотографию футболиста Дэвида Бекхэма; в других утверждалось, что он доказывает, будто американец Nick Berg, убитый в Ираке в мае 2004 года, всё ещё жив. И сообщение, и имя должны убедить ничего не подозревающего пользователя открыть вложение и активировать лазейку.

Как для любого исполняемого файла, сначала следует вывести основные заголовки и таблицы импорта/экспорта через DUMPBIN или похожую программу. Сокращённый результат приведён в листинге 8.1.

Листинг 8.1. Сокращённый вывод DUMPBIN для Backdoor.Hacarmy.D.

У вывода несколько необычных свойств. Во-первых, многие DLL имеют только одну импортируемую функцию, что крайне нетипично и бессмысленно. Что программа сможет сделать с WS2_32.DLL, вызывая лишь bind? Почти ничего. То же относится к CRTDLL.DLL, ADVAPI32.DLL и остальным. Разгадка находится в разделе Summary. Обычно ожидается секция .text с кодом, но её нет. Вместо неё присутствует стандартная ресурсная .rsrc и две неизвестные секции UPX0 и UPX1.

Быстрый поиск показывает, что UPX - упаковщик исполняемых файлов с открытым исходным кодом. Упаковщик сжимает или шифрует программу на месте, прозрачно для пользователя: после запуска она автоматически восстанавливается в памяти. Некоторые упаковщики являются антиреверсивными средствами, шифруют программу и противодействуют отладчикам и дизассемблерам. Другие только уменьшают размер. UPX относится ко второй группе. Для такой троянской лазейки логично применять его, чтобы файл был как можно меньше.

Предположение можно проверить последней бета-версией UPX для Windows. Обратите внимание, лазейка использует именно новейшую beta; актуальный на момент написания выпуск 1.25 файл не распознавал. Запустим UPX с параметром -l, чтобы получить сведения о сжатии:

Как и ожидалось, файл упакован UPX и благодаря этому примерно на 9 Кбайт меньше. Исследовать его в сжатом виде несколько неудобно, поэтому попросим UPX окончательно распаковать программу и будем работать с результатом. Параметр -d заменяет сжатый файл функционально идентичной распакованной версией. После этого стоит снова запустить DUMPBIN. Его результат приведён в листинге 8.2.

Листинг 8.2. Вывод DUMPBIN для распакованной версии лазейки.

Теперь всё выглядит правильнее: видны точные функции, и исследование станет проще. Иногда автоматически распаковать программу невозможно, и приходится работать с упакованной версией; эта тема подробно рассматривается в части III. Пока запустим образец и выясним, что он делает. Разумеется, только в контролируемой изолированной среде без ценных данных и программ. Нельзя предсказать, на что способно malware.

После запуска Webcam Shots.scr сначала не происходит ничего. Так и задумано: программа не хочет никак показывать себя пользователю, она создана невидимой. Авторы могли бы сделать её убедительнее, встроив настоящее изображение, а при первом запуске извлекая и показывая его. Тогда пользователь не заподозрил бы неладное. Но здесь после щелчка ничего не происходит, и это может вызвать подозрение.

Впрочем, типичные жертвы подобных программ - нетехнические пользователи, которые не всегда понимают, чего ожидать от компьютера. Скорее всего, они решат, что изображение не появилось по их собственной вине.

Первое настоящее изменение после запуска: первоначальный исполняемый файл исчезает из каталога. В списке задач появляется новый неизвестный процесс ZoneLockup.exe. Я проводил опыт на чистой Windows 2000 почти без дополнительных программ, поэтому заметить его было легко. Имя явно выбрано, чтобы наивный пользователь принял процесс за компонент безопасности.

В более мощном средстве, например Sysinternals Process Explorer с сайта www.sysinternals.com, можно увидеть полный путь процесса. Программа поместила себя в каталог SYSTEM32 текущей ОС, в моём случае C:\WINNT\SYSTEM32.

Рассмотрим код первого запуска: это ближайший аналог установочной программы. Он приведён в листинге 8.3.

Листинг 8.3. Функция установки лазейки.

При первом запуске программа проверяет, установлена ли она, и при необходимости устанавливает себя. GetModuleFileName получает имя основного исполняемого файла, после чего проверяется наличие имени системного каталога SYSTEM32 в пути. Если установка ещё не выполнена, программа копирует себя в SYSTEM32 под именем ZoneLockup.exe, запускает копию и завершает исходный процесс через ExitProcess.

Новый экземпляр выполняет тот же код, но проверка обнаруживает запуск из SYSTEM32 и передаёт управление на 00402736. Здесь выясняется, впервые ли программа запущена из постоянного места. В параметрах командной строки ищется специальный флаг qwer вместе с полным путём и именем исходного троянского файла, например Webcam Shots.scr. Эти сведения нужны, чтобы удалить оригинал: после создания и запуска ZoneLockup.exe хранить его незачем.

Почему имя передаётся новому экземпляру, а не удаляется прежним? Windows блокирует загруженные исполняемые файлы. Поэтому программа должна запустить копию, завершить первый процесс и лишь затем удалить исходник.

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

Следующая часть функции слишком длинна для публикации, но читается легко. Она собирает сведения об узле, включая точную версию ОС и имя вошедшего пользователя. Затем начинается основной цикл программы, показанный в листинге 8.4.

Листинг 8.4. Основной цикл лазейки, проверяющий сетевое соединение.

Это явно бесконечный цикл, например while (1). Сначала он многократно вызывает InternetGetConnectedState и при результате FALSE засыпает на 30 секунд. API якобы проверяет соединение с Интернетом, хотя в действительности лишь наличие допустимого IP-адреса. Программа ждёт появления сетевого подключения.

После успеха вызывается 004029B1: первый параметр указывает на жёстко заданную строку g.hackarmy.tk, второй равен 0x1A0B, или 6667. Внутри вызывается 0040129C, которая передаёт строку функции Winsock2 gethostbyname, а затем соединяется с адресом через connect. Порт равен 6667. На сайте IANA, Internet Assigned Numbers Authority, www.iana.org, видно, что порты 6665-6669 зарегистрированы для IRCU, служб Internet Relay Chat.

Похоже, троян хочет с кем-то поговорить. Догадаетесь с кем? Подсказка: на нём чёрная шляпа, по крайней мере на иллюстрациях в книгах по безопасности; на деле это, вероятно, просто скучающий подросток в бейсболке. Программа явно подключается к IRC-серверу для общения с атакующим, скорее всего собственным автором. Адрес g.hackarmy.tk к моменту написания уже не работал и, вероятно, не заработает. Его, скорее всего, закрыли вскоре после обнаружения антивирусными компаниями. Изначально он указывал либо на специально созданный IRC-сервер, либо на один из общедоступных.

Чтобы проверить возможности лазейки, я настроил IRC-сервер в отдельной виртуальной машине и присвоил ему имя g.hackarmy.tk, после чего троян подключился к нему. Вы можете повторить опыт, но, вероятно, достаточно прочитать описание. Для эффективности я сочетал обычный реверс-инжиниринг с живым общением через IRC.

После подключения сокета обнаруживается интересная и необычная функция из листинга 8.5.

Листинг 8.5. Функция генерации случайной строки.

Она создаёт случайные данные, используя текущий счётчик тиков как seed. Длина буфера тоже несколько случайна: по умолчанию 5 байт, но может составлять от 2 до 8 в зависимости от знака результата rand. В основном цикле для каждого байта вычисляется случайное число, берётся остаток по модулю 0x1A, или 26, прибавляется 0x61, или 97, а результат записывается в буфер.

Наблюдение в OllyDbg показывает, что получается короткая случайная строка из строчных букв, помещённая в переданный вызывающим кодом буфер.

Обратите внимание, что остаток вычисляется крайне неэффективной IDIV. Это указывает на компиляцию с параметром вроде Minimize Size, если исходник был на высокоуровневом языке. При оптимизации скорости компилятор применил бы умножение на обратную величину, создав более длинный, но быстрый код. Это неудивительно: программа поставлялась упакованной UPX, и автор явно стремился минимизировать размер. Распознавание оптимизированного деления и других арифметических операций рассматривается в приложении B.

Следующая последовательность берёт случайную строку и формирует сообщение для IRC-сервера.

Поскольку EAX содержит адрес случайной строки, теперь понятно её назначение: это имя пользователя лазейки при подключении к серверу. Последовательность создаёт сообщение, в котором меняется лишь случайное имя:

Согласно RFC 1459, спецификации IRC, на сервере регистрируется новый пользователь vsorpy. Имя представляет конкретную заражённую систему в чате. Случайная схема, вероятно, позволяет множеству клиентов подключаться без конфликтов и удобно общаться сразу с несколькими заражёнными машинами.

После соединения программа и сервер выполняют обычное рукопожатие IRC. Следующее важное событие - уведомление о наличии MOTD, Message of the Day. На его основе код выбирает способ входа в канал связи с атакующим.

Первый sprintf вызывается при наличии MOTD, второй - при отсутствии. Обе команды входят в канал ##g##, но в первом случае с паролем grandad. Подключившись к этому каналу частного сервера от имени атакующего, можно увидеть помимо собственного ника случайное имя лазейки. Команды управления приходится определять по коду их обработки: простой сетевой монитор списка не покажет.

Особенно важен код обработки личных сообщений: именно через них атакующий управляет программой. Единственная прямая ссылка на строку PRIVMSG ведёт к следующей проверке.

После подтверждения PRIVMSG программа пропускает двоеточие начала сообщения и сравнивает первый символ с жёстко заданным в 004050C5 восклицательным знаком. При несовпадении функция возвращается к ожиданию. Значит, команды начинаются с !. Далее выполняется ещё одна проверка.

Строка [EBP-60], ник отправителя, сравнивается с массивом глобальных строк по 0x50, или 80, символов. Сначала все четыре пусты, поэтому вместо функции 00403016 выполняется следующий код.

sprintf создаёт строку morris tounge, которая сравнивается с сообщением. При команде !morris tounge ник отправителя сохраняется в свободном элементе массива 004051C5. Это секретный пароль: программа принимает команды лишь от прошедшего проверку пользователя. Раздельное хранение слов - примитивный антиреверсивный приём, мешающий найти пароль простым поиском по двоичному файлу.

Получив пароль, легко определить команды в функции 00403016, отыскивая вызовы сравнения строк. Типичная последовательность:

Все строки сравниваются с командой из [EBP-200] без восклицательного знака. Вместо разбора каждой ветви попробуем очевидную !info.

После входа в канал и передачи пароля команда возвращает версию ОС заражённого узла, скорость и модель процессора, IP-адрес, имя системы и пользователя.

Есть и более опасные команды. !execute запускает локальный исполняемый файл, а !webfind64 загружает файл с удалённого сервера и при необходимости запускает. Вместе они дают атакующему полный контроль.

Команда !socks4 создаёт поток, ожидающий соединений протокола SOCKS4, известного прокси-протокола для косвенного доступа к сети. Лазейка поддерживает несколько потоков на заданных атакующим портах. Если заражённая система имеет открытый интернет-порт, её можно превратить в прокси и подключаться к другим серверам под личностью законного владельца. Такие соединения пригодны для веба, почты и любых преступных задач, а проследить настоящий источник крайне трудно, особенно при кратком использовании и тщательной очистке каждого прокси.

Команда самоуничтожения !?dontuseme удаляет запись автозапуска и исполняемый файл. Поскольку работающий файл удалить нельзя, функция 00401AA0 создаёт rm.bat, запускает его и завершает программу.

Пакетный файл циклически пытается удалить основной исполняемый файл и заканчивает лишь после его исчезновения, дождавшись завершения ZoneLockup.exe.

Собранные сведения стоит свести в таблицу.

Таблица 8.1. Поддерживаемые команды Trojan/Backdoor.Hacarmy.D

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

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

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

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

Технические подходы вряд ли когда-нибудь дадут идеальное решение. Некоторые из них создают серьёзные неудобства конечным пользователям, наделяя владельцев авторских прав всей полнотой власти, а законных покупателей оставляя беспомощными. Возможно, проблему хотя бы частично удастся решить на общественном уровне: объяснять ценность творчества и убеждать людей, что художники и другие правообладатели заслуживают оплаты. Стоит задуматься, что станет с музыкальной и киноиндустрией через 20 лет, если пиратство будет бесконтрольно расти. Чья это проблема: правообладателя или каждого из нас?

В исследовании глобального программного пиратства, проведённом авторитетной компанией IDC в июле 2004 года, оценивалось, что в 2003 году во всём мире незаконно установили ПО более чем на 30 миллиардов долларов; см. BSA and IDC Global Software Piracy Study Business Software Alliance и IDC [BSA1]. Это 36 процентов всех установленных за период продуктов. В другом исследовании IDC утверждала, что снижение пиратства на 10 процентных пунктов за четыре года добавит более миллиона рабочих мест и 400 миллиардов долларов мирового экономического роста.

Следует помнить, что исследования заказала Business Software Alliance (BSA), некоммерческая организация по борьбе с программным пиратством. Она частично финансируется правительством США, но главным образом мировыми гигантами ПО: Adobe, Apple, IBM, Microsoft и многими другими. Эти компании несомненно несут огромные убытки, однако исследования выглядят несколько предвзятыми и игнорируют параметры, не совпадающие с интересами спонсоров. Например, для оценки пиратства сравнивается число проданных ПК с количеством установленного ПО, но, по-видимому, не учитываются бесплатные продукты с открытым кодом. Получается, любой компьютер с Linux или OpenOffice считается "незаконным".

Тем не менее пиратство остаётся огромной проблемой. Несколько лет назад для незаконного копирования требовалась физическая копия на дискете или другом носителе. Интернет радикально изменил положение: простой и анонимный обмен информацией стал кошмаром правообладателей. Больше не нужен дружелюбный сосед с нужной программой и даже знакомство с таким человеком. Достаточно поискать в Интернете warez, и найдутся готовые к загрузке копии большинства популярных продуктов. Особенно невероятно, что почти все они первоначально имели некоторую защиту. Огромное число взломщиков неустанно снимает её с любого полезного ПО сразу после выпуска.

Техническая борьба с программным пиратством продолжается дольше, чем большинство из нас желает помнить. Патенты на соответствующие технологии подавались уже в 1977 году, см. Computer Software Security System Richard Johnstone и Microprocessor for Executing Enciphered Programs Robert M. Best [Johnstone, Best], а журнал Byte посвятил пиратству целый выпуск в мае 1981 года. Определим задачу: какова цель защиты от копирования и почему её так трудно достичь?

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

Логически очевидно: по-настоящему надёжной технологии нужен доверенный компонент, обеспечивающий ограничения. Современный компьютер "открыт": программы выполняются процессором без проверки, и тот ничего не знает об их "правах". Пока код способен выполняться, взломщик может его получить, поскольку ЦП не создавался для запрета доступа к работающей программе.

Ближайший аналог авторизованного кода в существующих процессорах - привилегированный и непривилегированный режимы, обычно изолирующие ядро ОС от программ. Теоретически на разделении можно построить мощную защиту, см. Strategies to Combat Software Piracy Jayadeve Misra [Misra], но ядра большинства современных ОС полностью доступны конечным пользователям. Система обязана разрешать установку компонентов уровня ядра, потому что там работают драйверы. Запрет не позволит устанавливать оборудование. Разрешение же даёт взломщику возможность загрузить отладчик ядра вроде SoftICE и наблюдать или изменять системные компоненты.

Не заблуждайтесь: открытая архитектура современных ПК делает невзламываемую защиту невозможной. Значительные изменения аппаратуры позволяют создать механизм, который нельзя взломать на программном уровне, но атаки на оборудование всё равно остаются.

Одна из крупнейших проблем почти любой защиты - уязвимость к class break; см. второе издание Applied Cryptography Bruce Schneier [Schneier1]. Такой взлом происходит, когда отказ технологии затрагивает не одну атакованную систему, а каждого её пользователя. Проблема быстро распространяется: один человек находит изъян, публикует сведения, и уязвимыми становятся все. Для защиты от копирования это почти всегда именно так.

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

Как показано в главе 11, взлом - это путешествие. Исследование сложной защиты занимает очень много времени. Если бы результат давал доступ только самому взломщику, серьёзной проблемы не было бы: немногие способны справиться со сложными схемами, и большинство пользователей продолжило бы покупать продукт законно. Катастрофа начинается, когда злоумышленники массово продают или распространяют свою работу.

Рассмотрим разные подходы и их эффективность: защиту на основе носителя, серийных номеров, схемы challenge-response и онлайн-активацию, аппаратные средства и предоставление ПО как услуги.

В 1980-е это был основной подход. Программа проверяла поставляемый носитель и подтверждала его оригинальность. На дискетах создавали специальные "плохие" секторы и при запуске проверяли их наличие. Копия на новую дискету таких секторов не имела, поэтому исполняемый файл отказывался работать.

Появились программы, пытавшиеся дублировать и специальные секторы, в частности CopyWrite и Transcopy. Законность их применения активно обсуждалась; сегодня их, вероятно, признали бы незаконными.

Использование серийных номеров продуктов для сдерживания программных пиратов - один из самых распространённых способов борьбы с пиратством ПО. Идея проста: поставщик снабжает каждый экземпляр программы уникальным серийным номером, напечатанным где-либо на упаковке продукта или на самом носителе. Затем программа установки требует, чтобы пользователь ввёл этот номер во время установки. Она проверяет его действительность с помощью секретного алгоритма проверки и, если номер верен, устанавливает программу и регистрирует её в системе конечного пользователя. Обычно в процессе установки серийный номер или некоторое производное от него значение добавляется к регистрационным данным пользователя, чтобы при обращении в службу поддержки поставщик мог убедиться, что у пользователя установлена законная копия продукта.

Нетрудно понять, почему подход, основанный исключительно на обычном серийном номере, несовершенен. Пользователи легко могут обмениваться номерами, и, пока они не связываются с поставщиком, тот никак не узнает о незаконных установках. Кроме того, Интернет значительно усугубил проблему: одному злоумышленнику достаточно опубликовать действительный серийный номер, после чего он позволяет выполнить бесчисленное множество незаконных установок всем, кто найдёт его в сети.

Простое усовершенствование схемы с серийным номером - заставить программу обмениваться с поставщиком сообщениями по протоколу challenge-response [Tanenbaum1]. Challenge-response - известный протокол аутентификации, обычно применяемый для проверки конкретных пользователей или компьютеров в вычислительных сетях. Идея заключается в том, что обе стороны, назовём их по традиции Алисой и Бобом, владеют общим секретным ключом, известным только им. Боб отправляет Алисе случайную незашифрованную последовательность, Алиса шифрует это сообщение и возвращает его Бобу в зашифрованном виде. Получив сообщение, Боб расшифровывает его секретным ключом и убеждается, что результат совпадает с первоначально отправленной случайной последовательностью. Если совпадение есть, он знает, что разговаривает с Алисой, поскольку только у неё имеется секретный ключ шифрования.

В механизмах защиты программ от копирования challenge-response можно применять для регистрации пользователя у поставщика и для гарантии того, что продукт нельзя использовать в данной системе без одобрения поставщика. Реализаций существует множество, но основная идея такова: во время установки конечный пользователь, как и в исходной схеме, вводит серийный номер. Отличие в том, что вместо простой проверки введённого номера установщик получает уникальный идентификатор машины, например идентификатор ЦП, и формирует уникальное значение из сочетания серийного номера с идентификатором машины. Затем это значение отправляется поставщику по Интернету или передаётся вручную по телефону. Поставщик проверяет законность данного серийного номера и наличие у пользователя права установить программу; он может, например, ограничивать разрешённое число установок. После этого поставщик возвращает ответ, который вводится в программу установки и математически проверяется ею на действительность.

Этот подход, хотя его, безусловно, можно взломать, заметно превосходит обычные схемы с серийными номерами: поставщик получает сведения об использовании продукта, а пираты не могут бесконтрольно применять одни и те же номера. Обычный способ взлома такой защиты - создать программу-генератор ключей, которая имитирует серверный механизм challenge-response и по запросу выдаёт действительный ответ. Генераторы ключей подробно рассматриваются в главе 11.

Аппаратные схемы определённо превосходят обычную защиту от копирования на основе серийных номеров. Их идея - добавить устойчивый к вмешательству непрограммный компонент, который участвует в аутентификации выполняемой программы. Вместе с программой покупатель получает электронный ключ, небольшой модуль, подключаемый к компьютеру, обычно через один из внешних разъёмов. В наши дни такие ключи чаще всего подключают к порту USB, а прежде для этого использовали параллельный порт.

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

Разработчики электронных ключей решают проблему, помещая в ключ нечто необходимое программе для работы. Обычно всё сводится к шифрованию. Поставщик распространяет двоичные файлы программы в зашифрованном виде. Ключа расшифровки нет нигде на установочном компакт-диске: он надёжно хранится внутри аппаратного ключа. При запуске программы сначала выполняется загрузчик или распаковщик, обычно предоставленный изготовителем ключа. Загрузчик связывается с устройством и получает ключ расшифровки, затем расшифровывает им настоящий программный код и запускает программу.

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

Однако даже защищённая программа, разделённая на сотни фрагментов с разными ключами, скрытыми в аппаратном устройстве, остаётся уязвимой для взлома. По сути, взломщику достаточно получить из устройства все ключи, вероятно, просто проследив за обменом данными между программой и ключом во время выполнения. После этого можно написать эмулятор, который воспроизводит работу аппаратного ключа и во время выполнения предоставляет программе все необходимые ключи. Обычно такие эмуляторы представляют собой драйверы устройств, имитирующие поведение драйвера настоящего электронного ключа и заставляющие защищённую программу думать, будто она взаимодействует с подлинным устройством, хотя на деле она общается с эмулятором. Программа работает и по мере необходимости расшифровывает каждый компонент. Изменять саму защищённую программу не требуется: она исправно выполняется, считая, что аппаратный ключ установлен. Конечно, для такой атаки взломщику обычно нужен доступ к настоящему ключу.

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

Со временем всё больше компьютеров получают постоянное подключение к Интернету, а соединения становятся быстрее и надёжнее. Это привело к естественному переходу к серверному ПО. Такая модель подходит не каждому виду программ, но определённым приложениям она действительно выгодна. Она упомянута здесь потому, что обеспечивает очень надёжную защиту, хотя защитной моделью её считают редко. Получить доступ к услуге вне контроля поставщика фактически невозможно, поскольку он владеет серверами, на которых выполняется программа, и обслуживает их.

В действительности программное решение невозможно сделать невзламываемым. Пока защищённое содержимое должно читаться в незашифрованном виде в целевой системе, взломщик так или иначе способен его похитить. Следовательно, для невзламываемого или хотя бы почти невзламываемого решения необходимо специализированное оборудование, помогающее технологии защиты.

Основа любой хорошей защиты - шифрование. Нужно найти способ зашифровать защищаемое содержимое стойким шифром и безопасно его расшифровать. Именно этап безопасной расшифровки почти всегда оказывается слабым местом. Компьютеры по своей природе открыты: платформа не предназначена для сокрытия каких-либо данных от конечного пользователя. Поэтому любая защищённая информация, поступившая в компьютер, станет доступна атакующему, если хотя бы однажды будет сохранена в системе в незашифрованном виде.

Проблему легко сформулировать: поскольку любую операцию расшифровки в конечном счёте должен выполнить ЦП, скрыть от него ключ и расшифрованные данные невозможно. Решение, независимо от того, что именно требуется защитить, состоит в добавлении к компьютеру конечного пользователя специализированного оборудования для расшифровки. Оно должно содержать скрытый ключ, извлечь который невозможно или очень трудно. Когда пользователь покупает защищённое содержимое, поставщик шифрует его так, чтобы расшифровать его можно было только встроенным аппаратным механизмом.

Криптопроцессор - известный подход к защите ПО от копирования, первоначально предложенный Robert M. Best в патенте Microprocessor for Executing Enciphered Programs [Best]. Исходная разработка касалась только программного пиратства, но современные реализации усовершенствовали её и сделали пригодной как для защиты ПО, так и для более общей защиты содержимого в системах управления цифровыми правами. Идея проста: создать микропроцессор, который способен непосредственно выполнять зашифрованный код, расшифровывая его на лету. Защищённое от копирования приложение для такого микропроцессора трудно взломать, поскольку при правильной реализации расшифрованный код никогда не становится доступен атакующему, по крайней мере без аппаратной атаки.

Ниже перечислены основные этапы защиты программы с помощью криптопроцессора.

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

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

3. Двоичные файлы программы шифруются открытым ключом и доставляются или передаются конечному пользователю.

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

5. Код выполняется непосредственно из этой теоретически недоступной памяти.

Поначалу может показаться, что для безопасности достаточно зашифровать защищаемую программу и расшифровывать её внутри процессора, но это не так. Проблема в том, что созданные программой данные тоже способны раскрыть сведения о зашифрованной программе; см. работу Markus G. Kuhn "Cipher Instruction Search Attack on the Bus-Encryption Security Microcontroller" [Kuhn]. Атака пытается обнаружить изменения среды, например операции записи в память, происходящие при поступлении в процессор определённых закодированных значений.

Для сокрытия данных процессоры должны уметь создавать своего рода изолированные отсеки между программами и полностью запрещать процессам доступ к данным друг друга. Изящное решение этой проблемы предложили David Lie и соавторы в работе "Architectural Support for Copy and Taper Resistant Software" [Lie]. Сходный подход реализован в Intel LeGrande Technology (LT), доступной в новейшем поколении процессоров компании; дополнительные сведения о LT приведены в документе Intel LaGrande Technology Architectural Overview [Intel4].

Эта книга не об аппаратуре, а мы, специалисты по программам, часто бываем ослеплены аппаратной безопасностью. Она кажется несокрушимой, хотя на самом деле таковой не является. Чтобы составить представление о существующих подходах к атакам, рассмотрите анализ энергопотребления, например дифференциальный анализ, предложенный Paul Kocher, Joshua Jaffe и Benjamin Jun в работе "Differential Power Analysis" [Kocher]. При таких атаках отслеживают энергопотребление микросхемы расшифровки и извлекают закрытый ключ, наблюдая небольшие изменения потребляемой мощности и используя их как показатель процессов внутри микросхемы. Этот пример показывает, насколько трудно защищать информацию даже при наличии специализированной криптографической микросхемы.

За последние несколько лет компьютерная отрасль, несомненно, изменилась. У этих изменений много сторон, и одна из интересных заключается в том, что теперь компьютеры намного лучше работают с мультимедийным содержимым. Обычный ПК способен легко хранить, записывать и воспроизводить защищённые авторским правом материалы, например музыкальные записи и фильмы.

Эта перемена привлекла в сферу защиты новых участников: внутри персональных компьютеров появились новые виды охраняемого содержимого, и правообладатели, в том числе звукозаписывающие компании и киностудии, пытаются контролировать его использование. К сожалению, управлять распространением мультимедийных файлов ещё труднее, чем распространением программ, потому что такие файлы, в отличие от ПО, не способны защищать себя сами. Ограничивать воспроизведение защищённых мультимедийных файлов должна программа-проигрыватель.

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

В основе практически всех технологий DRM лежит шифрование защищаемого содержимого тем или иным способом. Без шифрования обойти любой механизм DRM пугающе легко: данные превращаются в неподвижную мишень, которую остаётся лишь извлечь из файла. Поэтому большинство технологий DRM шифрует защищаемое содержимое, старается как можно надёжнее скрыть ключ расшифровки и управлять путём, по которому содержимое проходит после расшифровки.

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

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

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

Windows Media Rights Manager - попытка создать централизованную инфраструктуру управления цифровыми правами на уровне ОС, обеспечивающую безопасное воспроизведение и обработку охраняемого содержимого. Основная идея состоит в отделении мультимедийного файла, который, разумеется, зашифрован, от файла лицензии, фактически содержащего ключ шифрования, необходимый для расшифровки и воспроизведения.

Основной подход заключается в разделении мультимедийного файла и лицензии на воспроизведение, которая одновременно является ключом расшифровки этого файла. Когда пользователь запрашивает определённый материал, поставщику содержимого передаётся идентификатор ключа Key ID, однозначно определяющий систему или проигрыватель пользователя. Key ID служит начальным значением для создания ключа, которым будет зашифрован файл. Это важно: файл шифруется непосредственно в этот момент особым ключом данного пользователя. После этого пользователь получает от поставщика зашифрованный файл.

Когда система пользователя пытается воспроизвести файл, программа-проигрыватель связывается с издателем лицензии. Тот должен выдать файл лицензии, точно определяющий разрешённые действия с мультимедийным файлом. Именно лицензия несёт ключ расшифровки.

Важно понимать: если пользователь распространит файл содержимого, получатели не смогут им воспользоваться. Издатель лицензии обнаружит, что Key ID проигрывателя, пытающегося воспроизвести файл, не совпадает с Key ID исходного проигрывателя, для которого была куплена лицензия, и просто не выдаст действительную лицензию. Без правильного ключа расшифровать файл невозможно.

Модель Secure Audio Path пытается управлять потоком охраняемого, незашифрованного звука в Windows. Проблема в том, что любой человек может написать имитацию драйвера звукового устройства, которая будет похищать расшифрованное содержимое во время его передачи программой-проигрывателем на звуковую плату. Secure Audio Path гарантирует, что охраняемый звук остаётся в ядре и передаётся только звуковым драйверам, подписанным доверенным органом.

Водяной знак - это дополнительный "канал" незаметных данных, добавленный к видимому потоку данных. Представьте файл изображения или звукозапись. Водяной знак представляет собой скрытый внутри файла невидимый, а для звука неслышимый поток данных. Способ извлечения этих сведений обычно держат в секрете; более того, как правило, скрывают само существование водяного знака. Хорошая схема водяных знаков обладает следующими основными свойствами:

• Водяной знак трудно удалить. Проблема в том, что, обнаружив его, атакующие всегда могут исключить его из данных; см. работу Nasir Memon и Ping Wah Wong "Protecting Digital Media Content" [Memon].

• Он содержит как можно больше информации.

• Он незаметен и не влияет на видимую часть потока данных.

• Его трудно обнаружить.

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

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

Рассмотрим некоторые применения водяных знаков:

• Они позволяют авторам встраивать идентификационные сведения в свою интеллектуальную собственность.

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

• С помощью проверочной метки они идентифицируют исходные, неизменённые данные.

Исследования проводились и в области водяных знаков для программ. При этом двоичный файл программы изменяется так, чтобы не затронуть её работу, но создать в двоичном коде скрытый канал хранения данных; см. работу J. Nagra, C. Thomboroson и C. Colberg "A Functional Taxonomy for Software Watermarking" [Nagra]. Их применение сходно с применением обычных водяных знаков в мультимедийном содержимом.

Поскольку значительная часть реверс-инжиниринга часто выполняется в отладчике, иногда полезно встроить в программу специальный код, который запрещает или затрудняет пошаговое выполнение и установку точек останова. Антиотладочные методы особенно эффективны в сочетании с шифрованием кода, потому что зашифрованную программу исследователь вынужден запускать в отладчике, чтобы она сама себя расшифровала. Как уже говорилось, иногда программу можно автоматически распаковать специальным средством, не запуская её, однако схему шифрования кода можно построить так, чтобы автоматическая распаковка зашифрованного исполняемого файла стала невозможной.

За многие годы появилось несколько десятков антиотладочных уловок, но важно понимать, что почти все они зависят от платформы и особенно от конкретной операционной системы, в которой работает программа. Такие уловки также рискованны: иногда они дают ложные срабатывания, и программа работает неправильно даже без отладчика. С обфускацией кода дело обстоит иначе. Она обычно увеличивает объём программы или снижает быстродействие, однако эти издержки можно заранее рассчитать, и непредсказуемых побочных эффектов нет.

В оставшейся части раздела объясняются основы работы отладчиков, необходимые для понимания антиотладочных уловок, а затем обсуждаются конкретные, достаточно эффективные приёмы, совместимые с операционными системами семейства NT.

Для понимания последующих антиотладочных уловок необходимо знать основы работы отладчиков. Не углубляясь в подробности присоединения отладчиков пользовательского режима и режима ядра к целевым процессам, обсудим, как отладчик приостанавливает исследуемую программу и управляет ею. Когда пользователь ставит точку останова на инструкции, отладчик обычно заменяет её инструкцией int 3. Это специальное прерывание точки останова, которое сообщает отладчику о достижении заданного места. Получив уведомление о выполнении int 3, отладчик возвращает на место исходную инструкцию программы и останавливает её, чтобы оператор, обычно разработчик ПО, мог изучить состояние.

Другой способ расставить точки останова - использовать аппаратные точки. Аппаратной точкой останова управляет сам процессор. Она ничего не изменяет в целевой программе: процессор просто знает, что при обращении к определённому адресу памяти нужно остановиться. Это может быть адрес данных, например некоторой переменной, либо адрес кода в исполняемом файле. Во втором случае аппаратная точка предоставляет те же возможности, что и программная.

После срабатывания точки останова пользователь обычно анализирует код путём пошагового выполнения. Каждая инструкция выполняется отдельно, а после неё управление возвращается отладчику. В процессорах IA-32 пошаговый режим реализован посредством флага трассировки TF в регистре EFLAGS. Когда этот флаг установлен, процессор генерирует прерывание после каждой выполненной инструкции. В данном случае это прерывание номер 1, то есть прерывание одиночного шага.

Windows API IsDebuggerPresent можно использовать как простое средство обнаружения отладчиков пользовательского режима, например OllyDbg или WinDbg, если последний работает в этом режиме. Функция обращается к блоку окружения текущего процесса Process Environment Block (PEB) и определяет, присоединён ли пользовательский отладчик. Программа может вызвать этот API и завершиться, если он вернёт TRUE, но против исследователя такой способ не слишком эффективен, потому что его очень легко обнаружить и обойти. Имя API почти не оставляет сомнений: исследователь быстро найдёт вызов и удалит или пропустит его.

Сделать этот API несколько эффективнее в качестве антиотладочной меры можно, реализовав его непосредственно в коде программы. Тогда вызов не будет выделяться как часть антиотладочной логики. Разумеется, нельзя просто встроить API: его код действительно придётся скопировать в программу. К счастью, для IsDebuggerPresent это не проблема, поскольку реализация тривиальна и состоит из четырёх строк ассемблерного кода.

Вместо прямого вызова IsDebuggerPresent программа может выполнить следующий код:

Если настоящее завершение работы выполнено достаточно незаметно, этот способ несколько эффективнее выявляет отладчики пользовательского режима, поскольку обнаружить его труднее. Существенный недостаток заключается в опоре на конкретную реализацию API IsDebuggerPresent и предположении, что два внутренних смещения в структурах данных NT не изменятся в будущих выпусках операционной системы. Во-первых, код получает из структуры данных Thread Environment Block (TEB) значение по смещению +30, указывающее на PEB текущего процесса. Затем последовательность читает байт по смещению +2, который сообщает о наличии отладчика. Встраивать её в программу рискованно, поскольку трудно предсказать последствия изменения Microsoft одной из этих структур в будущем выпуске ОС. Программа может аварийно завершиться или прекратить работу даже при отсутствии отладчика.

Оценить вероятность изменения этих структур данных можно лишь по предыдущим версиям операционной системы. В действительности этот конкретный API не менялся между Windows NT 4.0, выпущенной в 1996 году, и Windows Server 2003. Это хорошо: реализация будет работать во всех актуальных версиях системы. Кроме того, это веский признак того, что структуры статичны и вряд ли изменятся. Однако всегда помните слова вашего инвестиционного консультанта: "прошлые результаты не служат показателем будущих". Если Microsoft не меняла структуры последние семь лет, это ещё не означает, что она не изменит их в следующие семь.

Наконец, для реализации подхода необходимо каким-либо образом включить в программу код на языке ассемблера. Для большинства компиляторов C/C++ это не проблема: компилятор Microsoft поддерживает ключевое слово _asm для вставки ассемблерного кода. Но такая возможность есть не в каждом языке программирования или на каждой платформе разработки.

Низкоуровневый API NtQuerySystemInformation позволяет определить, присоединён ли к системе отладчик ядра. Функция поддерживает несколько типов информационных запросов. Код запроса SystemKernelDebuggerInformation получает из ядра сведения о том, присоединён ли к системе отладчик ядра в данный момент.

Ниже дано определение структуры данных, возвращаемой запросом SystemKernelDebuggerInformation:

Чтобы определить наличие отладчика ядра, нужно проверить DebuggerEnabled. Обратите внимание, что эта схема не обнаруживает SoftICE, а выявляет только отладчик ядра с последовательным подключением, например KD или WinDbg. Для непосредственного обнаружения SoftICE можно просто проверить наличие его устройства ядра. Для этого откройте файл \\.SIWVID и считайте SoftICE установленным на машине, если файл удалось открыть.

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

Это ещё одна уловка для конкретного отладчика, которую я не рекомендовал бы применять, если только вас не беспокоят именно исследователи, использующие NuMega SoftICE. Хотя большинство взломщиков действительно пользуются незаконными копиями NuMega SoftICE, обнаружить и обойти такую схему обычно настолько легко, что усилия едва ли оправданны. Единственное преимущество состоит в том, что уловка способна озадачить исследователя, прежде с ней не знакомого, и ему действительно может понадобиться несколько часов, чтобы разобраться в происходящем.

Идея проста. Поскольку SoftICE использует int 1 для пошагового выполнения программы, он обязан установить собственный обработчик int 1 в таблице дескрипторов прерываний Interrupt Descriptor Table (IDT). Программа устанавливает обработчик исключения и вызывает int 1. Если код исключения отличается от обычного нарушения доступа STATUS_ACCESS_VIOLATION, можно считать, что работает SoftICE.

Ниже приведена реализация этого подхода для компилятора Microsoft C:

Этот подход похож на предыдущий, но здесь в текущем процессе устанавливается флаг трассировки и проверяется возникновение исключения. Если исключения нет, можно считать, что отладчик "проглотил" его за нас и программа выполняется под трассировкой. Прелесть подхода в том, что он обнаруживает любой отладчик, пользовательского режима или режима ядра, поскольку все они используют флаг трассировки. Ниже показан пример реализации. Код вновь написан на C для компилятора Microsoft C/C++.

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

Вычисление во время работы контрольных сумм фрагментов кода или всего исполняемого файла может стать довольно мощным антиотладочным методом, поскольку для установки точек останова отладчики вынуждены изменять код. Общая идея заключается в том, чтобы заранее рассчитать контрольную сумму функций программы, возможно только особенно важных, и заставить каждую функцию в случайные моменты проверять отсутствие изменений. Метод эффективен не только против отладчиков, но и против исправления кода, см. главу 11. Недостаток состоит в том, что постоянный перерасчёт контрольных сумм - сравнительно дорогая операция.

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

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

Обман дизассемблеров как средство предотвращения или затруднения реверс-инжиниринга нельзя назвать особенно надёжным подходом, но тем не менее он популярен. Стратегия довольно проста. В процессорных архитектурах с инструкциями переменной длины, например IA-32, можно заставить дизассемблер ошибочно принять недопустимые данные за начало инструкции. Он потеряет синхронизацию и будет неправильно разбирать оставшийся код, пока вновь не синхронизируется.

Прежде чем обсуждать конкретные методы, я кратко напомню два распространённых подхода к дизассемблированию, рассмотренных в главе 4. Линейный проход - простейший подход, последовательно разбирающий инструкции во всём модуле. Рекурсивный обход более интеллектуален: инструкции анализируются при перемещении по потоку управления программы. Когда программа ветвится на определённый адрес, дизассемблирование также продолжается с этого адреса. Дизассемблеры с рекурсивным обходом надёжнее и гораздо устойчивее к различным антидизассемблерным уловкам.

Кратко рассмотрим инструменты реверс-инжиниринга, обсуждаемые в этой книге, и выясним, какие из них действительно применяют рекурсивный обход. Это поможет предсказать влияние каждого метода на самые распространённые средства. В таблице 10.1 указаны способы дизассемблирования, используемые наиболее известными инструментами.

Таблица 10.1. Распространённые инструменты реверс-инжиниринга и архитектура их дизассемблеров

Начнём эксперименты с простых последовательностей, вводящих дизассемблеры в заблуждение. Сначала сосредоточимся исключительно на линейном проходе, который обмануть легче, а затем перейдём к более сложным последовательностям, рассчитанным на оба типа дизассемблеров.

Рассмотрим, например, следующую вставку на языке ассемблера:

После загрузки в OllyDbg эта последовательность остаётся полностью читаемой, поскольку OllyDbg выполняет рекурсивный обход. Байт 0F не дизассемблируется, а следующие за ним инструкции разбираются правильно. Ниже показан вывод OllyDbg для предыдущей последовательности:

В отличие от него, дизассемблер NuMega SoftICE несколько сбивается на этой последовательности и выводит следующее:

Как видите, дизассемблер SoftICE с линейным проходом полностью сбит с толку нашим мусорным байтом, хотя безусловный переход перескакивает через него. Выполнение поверх безусловного JMP по адресу 0040101D устанавливает EIP равным 401020, и SoftICE использует это значение как подсказку, откуда начать дизассемблирование. В результате получается следующая, разумеется, гораздо лучшая распечатка:

В целом распечатка верна, но байт 0F всё ещё смущает SoftICE: по адресу 40101F, где расположен этот байт, показана инструкция JNP. Возникает противоречие: JNP - длинная шестибайтовая инструкция, однако сразу после неё, по адресу 401020, SoftICE показывает правильную инструкцию MOV, как будто длина JNP равна одному байту. Это почти похоже на ошибку дизассемблера, но она едва ли важна, поскольку все настоящие инструкции, начинающиеся с 401020, распознаны правильно.

Предыдущий метод способен досаждать исследователям и вводить их в заблуждение, но не вполне эффективен, поскольку не обманывает более интеллектуальные дизассемблеры, такие как IDA Pro, и даже умные отладчики вроде OllyDbg.

Перейдём к методам, которые могут обмануть и дизассемблер с рекурсивным обходом. Чтобы заставить его ошибочно принять данные за инструкции, необходимо подать ему непрозрачный предикат. Непрозрачные предикаты - по существу, ложные ветвления: переход выглядит условным, но фактически является безусловным. Как и при любом ветвлении, код разделяется на два пути. Один ведёт к настоящему коду, другой - к мусору. На рисунке 10.1 показан случай с условием, которое никогда не истинно. На рисунке 10.2 представлено обратное условие, всегда принимающее истинное значение.

Рисунок 10.1. Тривиальный непрозрачный предикат, который во время выполнения всегда принимает значение False.

Рисунок 10.2. Обратный непрозрачный предикат, который во время выполнения всегда принимает значение True.

К сожалению, разные дизассемблеры выдают для таких последовательностей разные результаты. Рассмотрим следующий пример:

Он похож на ранее применявшийся против линейных дизассемблеров метод, но теперь вместо безусловного перехода используется простой непрозрачный предикат. Он всего лишь сравнивает 2 с 2 и выполняет переход при равенстве. Следующую распечатку создала IDA Pro:

Как видите, IDA попалась на уловку и выдала неверный код. Значит ли это, что IDA Pro, имеющая репутацию одного из самых мощных дизассемблеров, в чём-то ущербна? Совершенно нет. Если задуматься, корректное дизассемблирование подобных последовательностей нельзя обеспечить универсальным способом: дизассемблеру нужны специальные эвристические правила для таких ситуаций. Вместо этого дизассемблеры вроде IDA и OllyDbg предоставляют особые команды, позволяющие указать, является определённый байт кодом или данными. Для правильного разбора в этих продуктах пользователь должен сообщить, что мусорный байт на самом деле представляет собой данные, а не код. После этого проблема исчезнет и дизассемблер выдаст правильный результат.

Вернёмся к предыдущему примеру и посмотрим, как на него реагирует OllyDbg:

Olly явно игнорирует мусорный байт и использует условный переход как указатель на начало настоящего кода, поэтому распечатка верна. Возможно, Olly содержит специальный код для обработки подобных уловок. Как бы то ни было, теперь ясно, что использование целевого адреса перехода можно обратить против Olly. Если OllyDbg по условным переходам отмечает начало правильных последовательностей кода, достаточно создать условный переход, указывающий на начало неправильной последовательности. Следующий фрагмент демонстрирует эту идею:

Это улучшенная реализация того же подхода. Она с большей вероятностью запутает дизассемблер с рекурсивным обходом, потому что ему придётся произвольно выбирать, какой из двух переходов считать указателем на правильный код. Задача нетривиальна, поскольку с точки зрения дизассемблера оба варианта "правильны". Это теоретическая проблема: дизассемблер не знает, что именно считать настоящим кодом. Единственный доступный ему критерий - наличие недопустимых кодов операций. Обнаружив их, умный дизассемблер, вероятно, должен признать текущий начальный адрес неправильным и поискать другой.

Посмотрим на распечатку, которую Olly создаёт для приведённого кода:

На этот раз OllyDbg заглатывает приманку и использует недопустимый адрес 0040103D как начало дизассемблирования, создавая бессмысленную распечатку на языке ассемблера. Более того, IDA Pro выдаёт столь же нечитаемый результат: обе главные программы с рекурсивным обходом попадаются на уловку. Само собой, дизассемблеры с линейным проходом, такие как SoftICE, реагируют точно так же.

Один дизассемблер с рекурсивным обходом, который не поддался уловке, - PEBrowse Professional. Вот созданная им распечатка:

По-видимому, хотя трудно сказать, вызвано ли это особыми эвристиками для противодействия таким последовательностям или простой случайностью, PEBrowse Professional пытается дизассемблировать код и с адреса 40103D, и с 40103E, показывая оба варианта. Похоже, метод нужно немного усовершенствовать: чтобы обмануть каждый дизассемблер, прямого перехода на адрес правильного кода быть не должно. Решение состоит в косвенном переходе через значение, загруженное в регистр. Следующий код сбивает с толку все проверенные мной дизассемблеры, как с линейным, так и с рекурсивным обходом.

Причина успеха уловки совершенно проста. Дизассемблер не понимает, что последовательность mov eax, After, jmp eax эквивалентна jmp After, поэтому даже не пытается начать разбор с адреса After.

Недостаток всех этих уловок в том, что они рассчитывают на сравнительную глупость дизассемблера. К счастью, большинство дизассемблеров Windows достаточно глупы, чтобы их обмануть. А что будет при встрече с умным дизассемблером, который действительно анализирует каждую строку кода и отслеживает поток данных? Он не попадётся ни на одну из уловок, потому что обнаружит непрозрачный предикат. Разве трудно понять, что условный переход при равенстве 2 и 3 никогда не будет выполнен? Более того, простой анализ потоков данных покажет, что последняя последовательность с JMP фактически эквивалентна JMP After, чего, вероятно, уже достаточно для исправления дизассемблирования.

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

Посмотрим, как использовать предыдущие методы в настоящей программе. Я создал простой макрос OBFUSCATE, который добавляет к программе на C небольшую последовательность на языке ассемблера, см. листинг 10.1. Она временно запутывает большинство дизассемблеров, пока те не восстановят синхронизацию. Число инструкций до повторной синхронизации зависит не только от конкретного дизассемблера, но и от кода, следующего за макросом.

Листинг 10.1. Простой макрос обфускации кода, предназначенный для введения дизассемблеров в заблуждение.

Этот макрос проверен с компилятором Microsoft C/C++ версии 13 и содержит псевдослучайные значения, немного затрудняющие поиск и замену: инструкции MOV и CMP, а также сам мусорный байт случайны и рассчитываются по номеру текущей строки кода. Обратите внимание, что мусорный байт находится в диапазоне от D8 до DF. Эти коды операций хорошо подходят, потому что все они многобайтовые. Макрос __LINE__ создаёт уникальные имена символов на случай многократного применения макроса в одной функции. Каждое вхождение определит символы с разными именами. Макросы paste и pastesymbols необходимы, поскольку иначе компилятор неправильно разрешит константу __LINE__ и вместо неё использует строку __LINE__.

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

Важно понимать ограниченную эффективность всех этих методов. Они определённо не остановят опытного и решительного исследователя от анализа или взлома приложения, но способны несколько усложнить процесс. При ручной работе с таким обфусцированным кодом дизассемблеру указывают, где в действительности начинается код. Современные дизассемблеры, такие как IDA Pro и даже встроенный дизассемблер OllyDbg, позволяют пользователю добавлять подсказки, благодаря которым программа правильно интерпретирует код.

Главная проблема этих макросов - повторяемость, делающая их чрезвычайно уязвимыми перед автоматическими средствами, которые просто находят и уничтожают шаблоны. Целеустремлённый атакующий обычно может за 20 минут написать программу или сценарий для их удаления. Кроме того, созданы специальные дизассемблеры, преодолевающие большинство подобных методов обфускации; см. работу Christopher Kruegel и соавторов "Static Disassembly of Obfuscated Binaries" [Kruegel]. Стоит ли применять такие приёмы? В некоторых случаях, возможно, да, но если вам нужны мощные способы противодействия реверс-инжинирингу, вероятно, лучше остановиться на рассматриваемых далее преобразованиях, обфусцирующих поток управления и поток данных.

Вероятно, вы заметили, что все описанные до сих пор методы противодействия - зависящие от платформы "уловки", которые, на мой взгляд, лишь повышают для атакующего "коэффициент раздражения". Настоящая обфускация кода преобразует его так, чтобы значительно снизить читаемость для человека, сохранив функциональность. Обычно это не зависящие от платформы преобразования: они изменяют код, скрывая его первоначальное назначение и погружая исследователя в море несущественной информации. Уровень сложности, добавленной обфусцирующим преобразованием, принято называть силой. Её можно измерять обычными метриками сложности ПО, например числом предикатов в программе и глубиной вложенности определённой последовательности кода.

Помимо дополнительной сложности, вносимой в программу новой логикой и арифметикой, обфусцирующее преобразование должно обладать стойкостью, то есть его нельзя легко обратить. Поскольку многие преобразования добавляют несущественные инструкции, не создающие действительно ценных данных, можно разрабатывать деобфускаторы. Деобфускатор - программа, применяющая к обфусцированной программе различные алгоритмы анализа потоков данных. Иногда они позволяют отделить зёрна от плевел, автоматически удалить все несущественные инструкции и восстановить исходную структуру кода. Создание стойких преобразований, устойчивых к деобфускации, - серьёзная задача и главная цель многих обфускаторов.

Наконец, обфусцирующее преобразование обычно имеет определённую стоимость: увеличение размера кода, замедление выполнения или рост потребления памяти во время работы. Следует понимать, что некоторые преобразования вообще не влекут затрат времени выполнения, поскольку лишь реорганизуют программу прозрачным для машины образом, делая её менее читаемой для человека.

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

Возможно, вы заметили, а возможно, и нет, что в сообщении об успехе KeygenMe-3 говорилось: "Great, You are ranked as Level-3 at Keygening now", а не "Great, you are ranked as level 3 at patching now". У crackme тоже есть правила, и обычно их создатели определяют, каким способом следует решать задачу. Одни предназначены для исправления, другие - для создания генератора ключей. Генерация ключей - процесс разработки программ, которые воспроизводят алгоритм формирования ключей из технологии защиты и фактически предоставляют неограниченное число действительных ключей для всех желающих.

Вы можете спросить, зачем вообще нужна такая программа. Разве пираты не могут совместно использовать один ключ? Обычно нет. Для усиления защиты разработчики избегают алгоритмов, зависящих только от пользовательского ввода, и создают ключи по сочетанию введённых данных со сведениями о конкретном компьютере. Типичный подход - запросить полное имя пользователя и объединить его с серийным номером тома основного раздела жёсткого диска.^[1] Серийный номер тома - случайное 32-разрядное число, назначаемое разделу при форматировании. Благодаря ему ключ продукта действителен только на компьютере, где был установлен, и пользователи не могут обмениваться ключами.

Для решения проблемы программные пираты применяют генераторы ключей, обычно содержащие точные копии алгоритмов формирования серийного номера из защищённых программ. Генератор принимает входные данные, например серийный номер тома и имя пользователя, и выдаёт ключ продукта, который нужно ввести в защищённую программу для активации. Другой вариант использует запрос: защищённая программа берёт серийный номер тома и имя пользователя и формирует из них запрос, представляющий собой просто длинное число. Пользователь получает его, должен позвонить поставщику ПО и запросить действительный ключ продукта, который будет создан по переданному числу. В таком случае генератор ключей просто преобразует запрос в ключ продукта.

Как следует из названия, KeygenMe-3 предназначена для создания генератора ключей, поэтому, исправив её, мы фактически схитрили. Исправим положение и создадим для KeygenMe-3 генератор.

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

Первоначальная задача - найти алгоритм формирования ключа внутри crackme. Способов много, но один из почти безотказных - отыскать код, считывающий содержимое двух полей, куда вводятся имя пользователя и серийный номер. Если главное окно KeygenMe-3 является диалогом, что легко проверить по API создания диалогов в коде инициализации, программа, вероятно, использует GetDlgItemText либо отправляет полю сообщение WM_GETTEXT. Предположим, что нас интересует GetDlgItemText. Вернитесь к окну Names в OllyDbg и найдите ссылки на GetDlgItemTextA или GetDlgItemTextW. Как и ожидалось, программа вызывает GetDlgItemTextA, а окно Find References to Import показывает два обращения к API, не считая прямого JMP, то есть записи таблицы адресов импорта.

Листинг 11.1. Алгоритм преобразования первого поля ввода в KeygenMe-3. Продолжение следует.

Листинг 11.1. Продолжение.

Прежде чем извлекать алгоритм преобразования из приведённого кода, посмотрим также на функцию по адресу Key4.00401388, которая, по-видимому, является частью алгоритма.

Листинг 11.2. Алгоритм преобразования второго поля ввода в KeygenMe-3. Продолжение следует.

Листинг 11.2. Продолжение.

По коду ясно, что алгоритм формирования ключа, вероятно, находится в двух областях. Первая - участок Key4.0040130B из листинга 11.1, вторая - вся функция из листинга 11.2. Часть листинга 11.1 формирует значение в ESI, а функция листинга 11.2 возвращает значение в EAX. Эти значения сравниваются и для сообщения об успехе должны быть равны; именно это сравнение мы исправили ранее.

Начнём с определения входных данных, необходимых фрагменту Key4.0040130B. В начале ECX содержит длину первой входной строки из верхнего текстового поля, известен адрес этой строки 40303F, а также неизвестный жёстко заданный адрес 40351F. Сразу заметно, что последовательность не перебирает каждый символ строки. Вместо этого первые четыре символа рассматриваются как одно двойное слово. Для переноса кода в собственный генератор нужно выяснить, что хранится по адресу 40351F. Во-первых, перед обращением к памяти к адресу всегда прибавляется EAX. В начальной итерации EAX равен 1, поэтому фактически используется адрес 403520. В следующих итерациях EAX устанавливается в 4, и обращение идёт к 403524. Дамп 403520 в OllyDbg показывает следующие данные:

Обратите внимание, что обращающаяся к этому адресу строка использует лишь один байт, а не целое двойное слово. Поэтому в действительности программа обращается только к первому байту 0x25 и четвёртому 0x65.

При взгляде на первый алгоритм из листинга 11.1 совершенно ясно, что это некоторый алгоритм формирования ключа, преобразующий имя пользователя в 32-разрядное число, которое в конце оказывается в ESI. А что делает второй алгоритм из листинга 11.2? Беглый осмотр показывает, что сложной обработки там нет. Он перебирает каждую цифру серийного номера, вычитает из неё 0x30, то есть код цифры 0 в ASCII, и многократно умножает результат на 10, пока ECX не достигнет нуля. Для каждой цифры исходной строки умножение выполняется во внутреннем цикле, а число повторений определяется позицией цифры.

Пошаговое выполнение в отладчике покажет то, что опытный исследователь видит уже по самой функции: она преобразует переданную в параметре строку в двоичное двойное слово. Это эквивалент функции atoi из библиотеки времени выполнения C, но, по-видимому, является частной реализацией. atoi несколько сложнее; кроме того, OllyDbg умеет распознавать библиотечные функции, если ему предоставить библиотеку, однако в KeygenMe-3 он, похоже, ничего не нашёл.

Итак, первый алгоритм из листинга 11.1 особым способом преобразует имя пользователя в 32-разрядное двойное слово, а второй просто преобразует цифры из нижнего текстового поля. В нижнем поле должно находиться число, полученное первым алгоритмом. Значит, достаточно извлечь первый алгоритм в программу-генератор, чтобы он создавал для нас серийный номер. Проверим.

В листинге 11.3 показана перенесённая мной процедура для генератора ключей. По существу это функция C, скомпилированная компилятором Microsoft C/C++, со вставкой на языке ассемблера, скопированной из дизассемблера OllyDbg. Все инструкции в нижнем регистре добавлены вручную, как и имя LoopStart.

Листинг 11.3. Перенесённый алгоритм преобразования первого поля ввода из KeygenMe-3. Продолжение следует.

Листинг 11.3. Продолжение.

Я вставил эту функцию в крошечное консольное приложение, которое принимает имя пользователя и показывает возвращаемое ComputeSerial значение в десятичном виде. Оно лишь вызывает ComputeSerial и печатает результат. Ниже приведена точка входа программы-генератора.

Казалось бы, достаточно ввести в верхнее поле любое имя, совпадающее с переданным ComputeSerial, а в нижнее - возвращённое функцией значение, и KeygenMe-3 примет данные. Проверим. Передадим генератору параметр "John Doe" и запишем полученный серийный номер. Результат работы генератора показан на рисунке 11.9.

Рисунок 11.9. Генератор ключей KeygenMe-3 в работе.

Полученный серийный номер равен 580695444. Запустите исходную, неисправленную версию KeygenMe-3 и введите "John Doe" в первое поле, а 580695444 - во второе. Снова успех! KeygenMe-3 принимает оба значения как действительные. Поздравляю, на этом второй урок взлома завершён.

Теперь, когда у вас есть приличное понимание основных принципов защиты, пора испачкать руки и попытаться преодолеть более мощный механизм. Для этого я создал специальную crackme под названием Defender. Она предназначена для демонстрации нескольких сильных приёмов защиты, похожих на встречающиеся в настоящих коммерческих технологиях. Предупреждаю: если до Defender вы никогда не сталкивались с серьёзной системой защиты, она может показаться невзламываемой. Это не так; нужны лишь большие знания и много терпения.

Defender тесно интегрирована с базовой операционной системой и специально разработана для Windows семейства NT. Она работает во всех доступных на момент написания системах этого семейства, в том числе Windows XP, Windows Server 2003, Windows 2000 и Windows NT 4.0, но не запускается в системах, не основанных на NT, например Windows 98 или Windows Me.

Для начала просто запустим Defender.EXE и посмотрим, что произойдёт. Обратите внимание, что это консольное приложение, поэтому обычно его следует запускать из окна командной строки. Я выбрал консольный режим, потому что он значительно упростил программу. Столь же мощную защиту можно было создать в обычном приложении с графическим интерфейсом, но написание заняло бы больше времени. Важно помнить: консольное приложение - не программа DOS! Системы семейства NT могут выполнять программы DOS в виртуальной машине NTVDM, но здесь это не так. Консольные приложения вроде Defender - обычные 32-разрядные программы Windows, которые лишь обходятся без API графического интерфейса Windows, сохраняя полный доступ к Win32 API, и взаимодействуют с пользователем через простое текстовое окно.

Запустите Defender.EXE из командной строки, и программа выведет общее сообщение об использовании. Оно показано на рисунке 11.10.

Рисунок 11.10. Defender.EXE, запущенная без параметров командной строки.

Defender принимает имя пользователя и 16-разрядный шестнадцатеричный серийный номер. Просто чтобы увидеть результат, передадим ей фиктивные значения. На рисунке 11.11 показана реакция Defender на имя John Doe и серийный номер 1234567890ABCDEF.

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

Загрузим Defender.EXE в OllyDbg и впервые взглянем на неё. Сначала следует открыть окно Executable Modules и посмотреть, какие DLL статически связаны с Defender. Это окно показано на рисунке 11.12.

Рисунок 11.11. Defender.EXE, запущенная с именем John Doe и серийным номером 1234567890ABCDEF.

Рисунок 11.12. Исполняемые модули, статически связанные с Defender, в OllyDbg.

Рисунок 11.13. Импорт и экспорт Defender.EXE в OllyDbg.

Список действительно очень короток: только NTDLL.DLL и KERNEL32.DLL. Помните, у crackme KeygenMe-3 с графическим интерфейсом список был намного длиннее, но Defender является консольным приложением. Перейдём к окну Names, чтобы определить вызываемые Defender API. Окно Names для Defender.EXE показано на рисунке 11.13.

Очень странно. Похоже, единственный API, вызываемый Defender.EXE, - IsDebuggerPresent из KERNEL32.DLL. Нетрудно понять, что это едва ли правда. Программа должна каким-либо образом взаимодействовать с операционной системой, а не только вызывать IsDebuggerPresent. Например, как она печатает сообщения в окне консоли без обращения к ОС? Это просто невозможно. Пропустим программу через DUMPBIN и посмотрим, что он сообщит об импорте Defender. В листинге 11.4 приведён вывод DUMPBIN при запуске с параметром /IMPORTS.

Листинг 11.4. Вывод DUMPBIN для Defender.EXE с параметром /IMPORTS. Продолжение следует.

Листинг 11.4. Продолжение.

Новостей немного. DUMPBIN тоже утверждает, что Defender.EXE вызывает только IsDebuggerPresent. Однако в разделе Summary есть немного интересного: DUMPBIN перечисляет секции модуля. По-видимому, у Defender нет секции .text, куда обычно помещают код исполняемых файлов PE. Вместо неё имеются две странные секции: .h3mf85n и .h477w81. Это не означает, что в программе нет кода, а лишь указывает, что он, скорее всего, спрятан в одной из секций с необычным именем.

Теперь разумно запустить DUMPBIN с параметром /HEADERS, чтобы лучше понять устройство Defender, см. листинг 11.5.

Листинг 11.5. Вывод DUMPBIN для Defender.EXE с параметром /HEADERS. Продолжение следует.

Листинг 11.5. Продолжение.

Листинг 11.5. Продолжение.

Листинг 11.5. Продолжение.

Параметр /HEADERS предоставляет намного больше сведений о программе. Например, легко увидеть, что секция номер 1, .h3mf85n, является секцией кода. Она помечена как Code, и в ней расположена точка входа программы: точка входа находится по адресу 404232, а .h3mf85n занимает диапазон от 401000 до 4042FF, поэтому адрес явно принадлежит этой секции. Другая секция со странным именем, .h477w81, по-видимому, представляет собой небольшую секцию данных, вероятно содержащую несколько переменных. Стоит также упомянуть, что флаг подсистемы равен 3. Он обозначает программу Windows CUI с консольным пользовательским интерфейсом, и при запуске Windows автоматически создаст для неё окно консоли.

Все необычно названные секции указывают, что программа, возможно, каким-либо образом упакована. Упаковщики создают особые секции с упакованным кодом или кодом распаковки. Стоит запустить программу в PEiD и проверить, не упакована ли она известным упаковщиком. PEiD распознаёт популярные сигнатуры исполняемых файлов и сообщает, был ли файл упакован одним из распространённых упаковщиков или продуктов защиты от копирования. PEiD можно загрузить с http://peid.has.it/. На рисунке 11.14 показан результат обработки Defender.EXE. К сожалению, PEiD сообщает "Nothing found", поэтому можно уверенно считать, что Defender либо не упакована, либо упакована неизвестным средством. Перейдём к дизассемблированию программы и выясним, откуда появляется сообщение "Sorry... Bad key, try again.".

Рисунок 11.14. При обработке Defender.EXE программа PEiD сообщает "Nothing found".

В отличие от программ с собственным машинным кодом, приложения .NET требуют специальной среды выполнения. Эта среда, называемая .NET Framework, служит своего рода посредником между программами .NET и остальным миром. По существу, это программная среда, внутри которой выполняются все приложения .NET. Она состоит из двух основных компонентов: общеязыковой среды выполнения Common Language Runtime (CLR) и библиотеки классов .NET. CLR загружает и проверяет сборки .NET и фактически является виртуальной машиной, внутри которой программы безопасно выполняются. Библиотека классов позволяет им взаимодействовать с внешним миром. Эта иерархия предоставляет самые разные службы: пользовательский интерфейс, сеть, файловый ввод-вывод, работу со строками и многое другое. На рисунке 12.2 показана связь компонентов, образующих платформу .NET.

Двоичный модуль .NET называется сборкой. Сборки содержат сочетание кода IL и связанных с ним метаданных. Метаданные - особый блок, который хранит сведения о типах данных, описывающие различные объекты сборки, а также точное определение каждого объекта программы, включая локальные переменные, параметры методов и так далее. Сборки выполняются CLR, которая загружает метаданные в память и компилирует код IL в собственный код с помощью JIT-компилятора.

Управляемым называется любой код, который CLR во время выполнения проверяет с точки зрения безопасности, типобезопасности и использования памяти. Он состоит из двух основных элементов .NET: кода MSIL и метаданных. Именно их сочетание позволяет CLR выполнять управляемый код. В каждый момент CLR знает, с какими типами данных работает программа. Например, в традиционных компилируемых языках C и C++ доступ к структуре данных получают, загружая указатель в память и вычисляя требуемое смещение. Процессор не знает, что представляет эта структура и допустим ли фактически используемый адрес.

При выполнении управляемого кода CLR полностью осведомлена почти обо всех типах данных программы. Метаданные содержат определения классов, сведения о методах и принимаемых ими параметрах, а также тип каждой локальной переменной любого метода. Благодаря этому CLR может проверять операции кода IL и убеждаться в их допустимости. Например, когда сборка с управляемым кодом обращается к элементу массива, CLR легко проверяет размер и просто возбуждает исключение, если индекс выходит за границы.

Рисунок 12.2. Связь общеязыковой среды выполнения, IL и различных языков программирования .NET.

.NET не привязана к конкретному языку, кроме IL, и для неё созданы компиляторы множества языков программирования. Ниже перечислены самые популярные в среде .NET.

C#. C Sharp является языком программирования .NET в том смысле, что изначально проектировался как "собственный" язык платформы. Его синтаксис напоминает C++, но функционально он ближе к Java. И C#, и Java объектно-ориентированы и допускают лишь один уровень наследования. Оба языка типобезопасны, то есть не разрешают неверное обращение с типами данных, например небезопасное приведение. Кроме того, оба работают со сборщиком мусора и не поддерживают явное удаление объектов. Более того, ни один язык .NET не поддерживает такое удаление: все основаны на сборке мусора.

Управляемый C++. Это расширение компилятора Microsoft C/C++ (cl.exe), способное создавать из кода C++ управляемый исполняемый файл IL.

Visual Basic .NET. Microsoft создала для .NET компилятор Visual Basic и тем самым фактически устранила прежний компонент виртуальной машины Visual Basic (VBVM), в котором выполнялись все программы предыдущих версий платформы. Теперь приложения Visual Basic .NET работают в CLR, а их исполняемые файлы по существу идентичны файлам C# и управляемого C++: все состоят из управляемого кода IL и метаданных.

J#. J Sharp - просто реализация Java для .NET. Microsoft предоставляет совместимый с Java компилятор, который создаёт исполняемые файлы IL вместо байт-кода Java. Очевидная цель - позволить разработчикам легко переносить приложения Java на .NET.

Замечательное свойство .NET и всех этих языков - простое взаимодействие. Благодаря метаданным, точно описывающим исполняемый файл, программы могут взаимодействовать на уровне объектов независимо от языка создания. Например, одна программа способна прозрачно унаследовать класс другой, даже если первая написана на C#, а вторая - на Visual Basic .NET.

Общая система типов Common Type System (CTS) управляет организацией типов данных в программах .NET. Существуют два основных типа: значения и ссылки. Значения представляют настоящие данные, тогда как ссылочные типы представляют ссылку на настоящие данные, во многом подобно обычному понятию указателей. Значения, как правило, размещаются в стеке или внутри какого-либо другого объекта, тогда как сами объекты, на которые указывают ссылки, обычно размещаются в блоке кучи, автоматически освобождаемом сборщиком мусора (признаю, это объяснение несколько упрощено, но пока его достаточно).

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

Наконец, в отличие от значений, ссылочные типы являются самоописывающими: ссылка содержит сведения о точном типе объекта, на который она указывает. Этим они отличаются от значимых типов, не несущих никаких идентификационных сведений.

Одна интересная особенность CTS - понятия упаковки и распаковки. Упаковка представляет собой процесс преобразования структуры данных значимого типа в объект ссылочного типа. Внутри это реализуется путём дублирования соответствующего объекта и создания ссылки на его копию. Идея состоит в том, что такой упакованный объект можно использовать с любым методом, который ожидает на входе ссылку на объект общего типа. Помните, что ссылочные типы несут с собой сведения для идентификации типа, поэтому метод, принимающий на входе ссылку объектного типа, действительно может проверить тип объекта во время выполнения. Со значимым типом это невозможно. Распаковка - просто обратный процесс, преобразующий объект обратно в значимый тип. Она необходима, если объект был изменён, пока находился в объектной форме: поскольку при упаковке объект дублируется, никакие изменения упакованного объекта не отразятся в исходном значении, пока не будет явно выполнена распаковка.

Как уже говорилось, исполняемые файлы .NET редко поставляются в виде исполняемых файлов с собственным машинным кодом.^[1] Вместо этого они распространяются в промежуточной форме, называемой Common Intermediate Language (CIL) или Microsoft Intermediate Language (MSIL), но для краткости мы будем называть её просто IL. В программах .NET по существу два этапа компиляции: сначала исходный код программы компилируется в код IL, а во время выполнения этот код вновь компилируется JIT-компилятором в собственный машинный код. В следующих разделах описаны некоторые базовые низкоуровневые понятия .NET, например стек вычислений и запись активации, а также представлен IL и его важнейшие инструкции. Наконец, я приведу несколько образцов кода IL и проанализирую их.

Стек вычислений применяется для управления сведениями о состоянии программ .NET. Код IL использует его примерно так же, как инструкции IA-32 используют регистры: для хранения непосредственных данных, например входных и выходных значений инструкций. Вероятно, самое важное, что следует понимать о стеке вычислений, - в действительности он не существует! Поскольку код IL никогда не интерпретируется во время выполнения, а перед исполнением всегда компилируется в собственный код, стек вычислений существует только в процессе JIT-компиляции. Во время выполнения он не имеет никакого значения.

В отличие от стеков IA-32, к которым вы уже успели так привыкнуть, стек вычислений состоит не из 32-разрядных или каких-либо иных записей фиксированного размера. Одна запись стека может содержать данные любого типа, включая целые структуры данных. Многие инструкции набора IL являются полиморфными: они способны принимать данные разных типов и правильно работать с множеством типов. Это значит, например, что арифметические инструкции могут корректно обрабатывать как операнды с плавающей точкой, так и целочисленные. Явно сообщать инструкциям, какие типы данных им следует ожидать, не нужно: JIT-компилятор проведёт необходимый анализ потока данных и определит типы операндов, переданных каждой инструкции.

Чтобы как следует понять философию IL, нужно привыкнуть к мысли, что CLR является стековой машиной: инструкции IL используют стек вычислений так же, как инструкции языка ассемблера IA-32 используют регистры. Практически каждая инструкция либо снимает значение со стека, либо помещает в него какое-либо значение. Именно так инструкции IL получают доступ к своим операндам.

Записи активации - элементы данных, представляющие состояние выполняющейся в данный момент функции, подобно кадрам стека в программах с собственным машинным кодом. Запись активации содержит параметры, переданные текущей функции, а также все локальные переменные этой функции. Для каждого вызова функции выделяется и инициализируется новая запись активации. В большинстве случаев CLR размещает записи активации в стеке, а значит, по существу они ничем не отличаются от кадров стека, с которыми вы работали в собственном ассемблерном коде. Набор инструкций IL включает специальные инструкции для доступа к параметрам функции и локальным переменным в текущей записи активации (см. ниже). Записи активации автоматически выделяются инструкцией IL call.

Рассмотрим наиболее распространённые и интересные инструкции IL, чтобы получить представление об этом языке и его внешнем виде. В таблице 12.1 описаны некоторые из самых популярных инструкций набора IL. Обратите внимание, что набор содержит более 200 инструкций, поэтому это далеко не полный справочник. Подробные сведения об отдельных инструкциях приведены в разделе III спецификации Common Language Infrastructure (CLI) [ECMA].

Таблица 12.1. Краткое описание наиболее распространённых инструкций IL

Рассмотрим несколько тривиальных последовательностей кода IL, чтобы почувствовать этот язык. Помните, что исследовать необработанный, необфусцированный код IL таким способом почти никогда не требуется: декомпилятор выдаст намного более приятный результат. Здесь я делаю это исключительно в учебных целях. Читать необработанный код IL понадобится лишь тогда, когда программа обфусцирована и не поддаётся правильной декомпиляции.

Приведённая ниже подпрограмма получена с помощью ILdasm - дизассемблера IL, входящего в пакет .NET Framework SDK. Исходная подпрограмма была написана на C#, хотя это едва ли имеет значение. Другие языки программирования .NET обычно создают идентичный или очень похожий код. Начнём с листинга 12.1.

Листинг 12.1. Пример программы IL, полученной из исполняемого файла .NET с помощью дизассемблера ILdasm.

Листинг 12.1 начинается с нескольких базовых определений перечисленного метода. Метод объявлен как .entrypoint, а значит, его код выполняется первым при запуске программы. Директива .maxstack задаёт максимальное число элементов, которые эта подпрограмма загружает в стек вычислений. Обратите внимание, что конкретный размер элемента здесь не важен: не следует предполагать 32 бита или любую иную величину; это количество отдельных элементов независимо от их размера. Следующая строка определяет локальные переменные метода. У этой функции лишь одна локальная переменная типа int32 с именем V_0. Имена переменных относятся к тем сведениям, которые компилятор обычно удаляет (в зависимости от конкретного компилятора).

Подпрограмма начинается с инструкции ldc, загружающей константу 1 в стек вычислений. Следующая инструкция, stloc.0, снимает значение с вершины стека и помещает его в локальную переменную номер 0 (названную V_0), которая является первой и единственной локальной переменной программы. Таким образом, фактически мы только что загрузили значение 1 в локальную переменную V_0. Обратите внимание, что эта последовательность даже длиннее аналога в собственном коде IA-32: чтобы загрузить константу в локальную переменную, нужны две инструкции. CLR является стековой машиной - всё проходит через стек вычислений.

Затем процедура выполняет безусловный переход по адресу IL_000e. Целевая инструкция задаётся относительным адресом от конца текущей инструкции. Здесь используется инструкция перехода br.s, то есть краткая форма, в которой относительный адрес задаётся одним байтом. Если бы расстояние между текущей и целевой инструкциями превышало 255 байт, компилятор применил бы обычную инструкцию br, использующую значение int32 для относительного адреса перехода. Краткая форма служит для максимальной компактности кода.

Код по адресу IL_000e начинает с загрузки в стек вычислений двух значений: содержимого локальной переменной 0, только что инициализированной значением 1, и константы 10. Затем эти значения сравниваются инструкцией ble.s. Это инструкция "переход, если меньше или равно", которая выполняет и сравнение, и сам переход, в отличие от кода IA-32, где нужны две инструкции: одна для сравнения и другая для перехода. CLR сравнивает второе значение в стеке со значением на его вершине, поэтому "меньше или равно" здесь означает, что переход будет выполнен, если значение локальной переменной 0 меньше или равно 10. Поскольку вам известно, что только что в эту локальную переменную было загружено значение 1, вы точно знаете: по крайней мере при первом выполнении этого кода переход состоится. Наконец, важно помнить, что для вычисления аргументов, переданных ble.s, их необходимо снять со стека. Это верно практически для любой инструкции IL, принимающей аргументы через стек вычислений: после завершения инструкции этих аргументов в стеке уже не будет.

Если предположить, что переход выполнен, исполнение продолжается с IL_0004, где подпрограмма вызывает WriteLine - часть библиотеки классов .NET. WriteLine выводит строку текста в консольном окне приложений консольного режима. Функция получает единственный параметр - значение нашей локальной переменной. Как и следовало ожидать, параметр передаётся через стек вычислений. Стоит упомянуть одну деталь: код передаёт целое число функции, которая выводит текст. Если посмотреть на строку вызова, мы увидим следующее: void [mscorlib]System.Console::WriteLine(int32). Это прототип конкретной вызываемой функции. Обратите внимание, что она принимает параметр int32, а не строку, как можно было ожидать. Подобно многим другим функциям библиотеки классов, WriteLine перегружена и имеет множество версий, принимающих строки, целые числа, числа с плавающей точкой и так далее. В данном случае вызывается версия для int32: как и в C++, автоматический выбор правильной перегруженной версии выполнил компилятор.

После вызова WriteLine подпрограмма вновь загружает в стек два значения: локальную переменную и константу 1. Затем вызывается инструкция add, которая складывает два значения из стека вычислений и записывает результат обратно в него. Таким образом, код прибавляет 1 к локальной переменной и сохраняет в неё результат (в строке IL_000d). После этого мы возвращаемся к IL_000e, где остановились перед началом рассмотрения этого цикла.

Очевидно, это очень простая подпрограмма. Всё, что она делает, - выполняет цикл между IL_0004 и IL_0011 и выводит текущее значение счётчика. Она остановится, когда значение счётчика станет больше 10 (вспомните условный переход в строках с IL_000e по IL_0011). Ничего сложного, но этот пример определённо кое-что показывает о работе IL.

Из-за изначальной уязвимости исполняемых файлов .NET их обфускация для предотвращения быстрой декомпиляции программы применяется очень широко. С собственными исполняемыми файлами ситуация совершенно иная: процессорные архитектуры наподобие IA-32 сами по себе обеспечивают неплохую защиту, поскольку читать ассемблерный код трудно. Код IL чрезвычайно подробен и легко декомпилируется в очень удобное для чтения представление на языке высокого уровня. Прежде чем обсуждать конкретные обфускаторы, кратко рассмотрим распространённые стратегии обфускации исполняемых файлов .NET.

Поскольку исполняемые файлы .NET содержат полноценные, понятные человеку имена символов для параметров методов, классов, полей и методов, при попытке помешать реверс-инжинирингу эти строки необходимо устранить из исполняемого файла. Фактически удалить их невозможно, потому что они нужны для идентификации элементов внутри программы. Вместо этого символы переименовывают, присваивая им загадочные, бессмысленные имена вместо исходных. Например, ListItem может превратиться в d или даже в xc1f1238cfa10db08. Это никогда не помешает исследовать программу, но определённо усложнит жизнь тем, кто попытается это сделать.

Обфускацию потока управления я уже рассматривал в главе 10. Она заключается в изменении структуры потока управления программы, чтобы сделать её менее удобной для чтения. В исполняемых файлах .NET такая обфускация прежде всего направлена на нарушение работы декомпиляторов и предотвращение получения пригодного результата для обфусцированной программы. Сделать это может быть довольно легко, поскольку декомпиляторы ожидают, что программы будут содержать осмысленные графы потока управления, которые просто преобразовать обратно в высокоуровневые управляющие конструкции вроде циклов и условных операторов.

Многие популярные обфускаторы, в том числе Dotfuscator, XenoCode и обфускатор Spices.Net, поддерживают возможность попытаться полностью воспрепятствовать дизассемблированию обфусцированного исполняемого файла. В зависимости от конкретной программы, используемой для открытия такого файла, она может аварийно завершиться или показать особое сообщение об ошибке, например приведённое на рисунке 12.3 сообщение ILDasm 1.1.

Рисунок 12.3. Сообщение ILDasm об ошибке при попытке открыть обфусцированную сборку.

Существуют две общие стратегии предотвращения дизассемблирования и декомпиляции сборок .NET. Если цель состоит именно в нарушении работы ILDasm, можно воспользоваться некоторыми недокументированными записями метаданных, которые ILDasm проверяет при загрузке сборки. Обфускаторы изменяют эти записи так, что ILDasm показывает сообщение об авторских правах с рисунка 12.3.

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

В следующих разделах показаны некоторые последствия работы популярных обфускаторов .NET и предпринята попытка оценить их эффективность против реверс-инжиниринга. Для тех, кому нужна точная мера влияния обфускации на сложность процесса реверс-инжиниринга, такой меры в настоящее время не существует. Традиционные подходы к метрикам программного обеспечения, например метрика сложности Маккейба [McCabe], не отражают всей картины, поскольку учитывают лишь структурную сложность программы, полностью игнорируя её представление. В действительности большинство протестированных мной обфускаторов .NET, вероятно, вообще не повлияли бы на метрику наподобие показателя Маккейба, потому что в основном изменяют представление программы, а не её структуру. Разумеется, методы обфускации потока управления способны несколько увеличить сложность графа потока управления программы, но это лишь одна часть общей картины.

Рассмотрим влияние нескольких популярных обфускаторов .NET на пример связного списка и попробуем определить, насколько эффективно эти программы противодействуют декомпиляции и ручному анализу кода IL.

В качестве первого испытания я взял рассмотренный ранее пример связного списка и обработал его обфускатором XenoCode 2005 (XenoCode Corporation, www.xenocode.com), включив функции переименования строк и обфускации потока управления. Была также включена функция "Suppress Microsoft IL Disassembler", которая не позволила ILDasm дизассемблировать код, однако его всё ещё можно было дизассемблировать другими инструментами, например Decompiler.NET (Jungle Creatures Inc., www.junglecreature.com) или Spices.Net. Обратите внимание, что оба продукта поддерживают как дизассемблирование IL, так и полноценную декомпиляцию в языки высокого уровня. В листинге 12.6 показан полученный Spices.Net дизассемблированный код IL функции AddItem из листинга 12.4.

Листинг 12.6. Дизассемблированный код IL обфусцированной версии функции AddItem из листинга 12.4.

Первое, что следует заметить в листинге 12.6, - переименованы все символы. Вместо набора приятных имён классов, методов и полей теперь имеются довольно длинные, выглядящие случайными сочетания цифр и букв. Это чрезвычайно раздражает, и злоумышленнику, возможно, имеет смысл переименовать эти символы в короткие имена вроде a, b и так далее. Смысла у них по-прежнему не будет, но устанавливать связи между отдельными символами станет намного легче.

Помимо загадочных имён символов, в методе обфусцированы и операторы потока управления. По существу, это означает, что фрагменты кода переставлены с помощью безусловных переходов. Например, безусловный переход в IL_0007 - это всего лишь исходный оператор if, перенесённый в более позднюю точку функции. Следующий за этой инструкцией код, который достигается безусловным переходом из IL_0024, представляет собой настоящее тело оператора if. Проблема таких преобразований в том, что для опытного исследователя, работающего на уровне IL, они едва ли создают даже небольшое неудобство. На самом деле они эффективнее против декомпиляторов, которые могут запутаться и преобразовать их в операторы goto. Это происходит, когда декомпилятору не удаётся построить правильный граф потока управления метода. Дополнительные сведения о процессе декомпиляции и графах потока управления приведены в главе 13.

Посмотрим, что произойдёт, если передать обфусцированный код из листинга 12.6 подключаемому модулю декомпилятора Spices.Net. Ниже приведена декомпилированная версия этого обфусцированного метода IL на языке C#.

Интересно, что Spices почти не впечатлён работой обфускатора и правильно распознаёт обфускацию потока управления функции. Разумеется, переименованные символы делают анализ функции гораздо менее приятным, но он определённо возможен. Важную роль играют длинные, выглядящие случайными имена символов, применяемые XenoCode. Я считаю этот подход особенно эффективным, поскольку поиск перекрёстных ссылок требует усилий. Просматривать такие длинные строки и искать различия нелегко.

DotFuscator (PreEmptive Solutions, www.preemptive.com) - ещё один обфускатор с возможностями, похожими на XenoCode. Он поддерживает переименование символов и обфускацию потока управления, а также способен мешать некоторым инструментам создавать дампы и дизассемблировать обфусцированные исполняемые файлы. DotFuscator предоставляет агрессивные функции переименования символов, которые устраняют пространства имён и используют перегруженные методы, чтобы внести дополнительную путаницу (это функция Overload-Induction). Рассмотрим, например, класс с тремя отдельными методами: один не принимает параметров, другой принимает целое число, а третий - логическое значение. Прелесть Overload-Induction состоит в том, что все три метода, скорее всего, получат одно имя, а конкретный метод будет выбираться по количеству и типам переданных параметров. Исследователей это сильно запутывает, поскольку различать отдельные методы становится трудно. В листинге 12.7 приведён код IL метода LinkedList::Dump из листинга 12.4.

Листинг 12.7. Версия метода LinkedList::Dump из листинга 12.4, обработанная DotFuscator.

Первая отличительная особенность DotFuscator - эти короткие однобуквенные имена символов. Они могут чрезвычайно раздражать, особенно если учесть, что в каждом классе есть по меньшей мере один метод с именем a. Если проследить инструкции потока управления в листинге 12.7, можно заметить, что они едва напоминают исходный поток LinkedList::Dump: в зависимости от настроек пользователя DotFuscator способен выполнять довольно агрессивную обфускацию потока управления.

Прежде всего, условие цикла перемещено вверх, в начало цикла, а в его конец, в IL_001e, добавлен безусловный переход обратно к началу. Сама по себе эта структура по существу является обычным циклом с предусловием, но здесь присутствуют дополнительные элементы, призванные запутать декомпиляторы. Если взглянуть на само условие цикла, окажется, что оно перестроено необычным образом: если условие инструкции brtrue выполняется, она пропускает инструкцию безусловного перехода и попадает в тело цикла. В противном случае следующая инструкция представляет собой безусловный переход, который пропускает тело цикла и направляется к концу метода.

Перед условием цикла находится необычная последовательность по адресу IL_0007, которая с помощью инструкции безусловного перехода просто переходит к следующей инструкции по адресу IL_0009. IL_0009 является первой инструкцией цикла, и к ней же возвращается безусловный переход в конце цикла. По-видимому, назначение безусловного перехода в IL_0007 - усложнить граф потока управления и направить два безусловных перехода в одну точку, что, вероятно, собьёт с толку алгоритмы анализа потока управления некоторых декомпиляторов.

Пропустим этот метод через декомпилятор и посмотрим, влияют ли столь агрессивные методы обфускации потока управления на его результат. Ниже приведён код, полученный мной для подпрограммы из листинга 12.7 в декомпиляторе Spices.Net:

Spices.Net полностью сбит с толку необычными конструкциями потока управления этой подпрограммы и создаёт неверный код. Ему не удаётся правильно определить тело цикла, и он фактически помещает оператор return внутрь цикла, хотя тот выполняется после него. Операторы d.a(); и d = d.b; размещены перед циклом, хотя по существу являются его телом. Наконец, условие цикла обращено: цикл должен продолжаться, пока d не равно null, а не наоборот.

Разные декомпиляторы применяют различные алгоритмы анализа потока управления и обычно по-разному реагируют на такие виды его обфускации.

Передадим тот же обработанный DotFuscator код из листинга 12.7 другому декомпилятору, Decompiler.Net, и посмотрим, как он отреагирует на обфускацию потока управления DotFuscator.

Здесь никаких проблем нет: Decompiler.Net хорошо справляется с задачей, и обфусцированная структура потока управления подпрограммы, судя по всему, никак не влияет на результат. Дело в том, что обфускация потока управления имеет характер игры в кошки-мышки: авторы декомпиляторов всегда могут вернуться и добавить специальные эвристические правила для правильной обработки различных искажённых структур потока управления, встречающихся в обфусцированных методах. Важно помнить об этом и не переоценивать влияние подобных приёмов на общую читаемость программы. Правильно декомпилировать код с обфусцированным потоком управления почти всегда будет возможно: в конце концов, для корректного выполнения программы код обязан сохранять исходный смысл.

Возвращаясь к переименованию символов, обратите внимание, насколько запутанной может оказаться эта простая схема с именами в алфавитном порядке. Наш метод a принадлежит классу b, и имеются две ссылки на a: ссылка this.a и вызов метода theD.a. Одна из них является полем класса b, а другая - методом класса d. Это превосходный пример того, как переименование символов способно изрядно досаждать исследователям.

Раз уж речь идёт о переименовании символов, у DotFuscator есть ещё один параметр, способный создать дополнительные неудобства злоумышленникам, пытающимся исследовать обфусцированные сборки. Он может переименовать символы с помощью недопустимых знаков, которые невозможно правильно отобразить. Это значит, что в зависимости от инструмента просмотра кода отличить одно имя символа от другого может оказаться вообще невозможно, а в некоторых случаях такие знаки могут помешать определённым инструментам открыть сборку. Следующий фрагмент представляет наш метод AddItem, обфусцированный DotFuscator с включённой функцией Unprintable Symbol Names. Этот код получен с помощью Decompiler.Net:

В приведённом виде эту функцию практически невозможно расшифровать: различать символы чрезвычайно трудно. И всё же декомпилятору явно не должно быть сложно преодолеть проблему: достаточно выявить такие имена символов и произвольно переименовать их, чтобы код стал понятнее. Следующий пример демонстрирует это решение для той же обработанной DotFuscator сборки с непечатаемыми именами. Он получен декомпилятором Spices.Net, который, по-видимому, выполняет такое преобразование автоматически.

После автоматического переименования нечитаемых символов в Spices.Net метод становится понятнее. То же верно и для многих других, менее агрессивных схем переименования. Декомпилятор всегда может просто переименовать каждый символ на этапе декомпиляции и сделать код максимально удобным для чтения. Например, многократное использование имён a, b и c, обсуждавшееся ранее, можно заменить уникальными именами. Вывод состоит в том, что многие преобразования обфускаторов можно частично отменить подходящими автоматизированными средствами. Именно в этом заключается главная уязвимость таких инструментов: пока результаты их преобразований можно отменить частично или полностью, они бесполезны. Задача разработчиков обфускаторов - создавать необратимые преобразования.

Продукт Remotesoft Obfuscator (Remotesoft, www.remotesoft.com) основан на понятиях, сходных с другими рассмотренными обфускаторами, но отличается наличием компонента Linker, способного добавить обфусцированным сборкам ещё один уровень защиты. Компоновщик может объединить несколько сборок в один файл. Эта функция полезна в нескольких различных случаях, но с точки зрения реверс-инжиниринга интересна тем, что способна предоставить дополнительный уровень защиты от исследования.

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

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

Решение состоит в обфускации библиотеки классов .NET и распространении её обфусцированной версии вместе с обфусцированной программой. Тогда при обращении к объекту System все имена будут искажены, и определить настоящее имя системного вызова станет довольно трудно.

Один подход, иногда позволяющий обнаружить такие системные классы даже после переименования, использует иерархическое представление графа вызовов, показывающее взаимодействие различных методов. Поскольку класс System содержит большой объём кода, по существу изолированного от основной программы (например, он никогда не вызывает основную программу), выявить системные ветви и по крайней мере понять, что определённый класс является частью пространства имён System, становится довольно легко. Графы вызовов для сборок .NET умеют создавать несколько инструментов, в том числе IDA Pro (которая, к слову, полностью поддерживает дизассемблирование IL).

Первый этап декомпиляции - перевод каждой отдельной низкоуровневой инструкции в промежуточное представление, дающее более высокоуровневый взгляд на программу. Обычно такое представление является просто универсальным набором инструкций, способным описать всё, что относится к коду.

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

У некоторых декомпиляторов, например dcc [Cifuentes2], имеется несколько промежуточных представлений: одно даёт низкоуровневое представление программы на ранних этапах процесса, а другое позднее отображает программу на более высоком уровне. Иные декомпиляторы применяют одно представление на протяжении всего процесса и просто постепенно удаляют из кода низкоуровневые детали, одновременно добавляя высокоуровневые.

В общем случае промежуточные представления состоят из крошечных наборов инструкций в отличие от огромных наборов некоторых процессорных архитектур, например IA-32. Малый набор становится возможен благодаря сложным выражениям, используемым почти в каждой инструкции.

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

Присваивание. Очень общая инструкция, представляющая операцию присваивания регистру, переменной или другому участку памяти, например глобальной переменной. Инструкция присваивания обычно может содержать сложные выражения с обеих сторон.

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

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

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

Возврат. Возвращается из подпрограммы. Обычно поддерживает сложное выражение, представляющее возвращаемое процедурой значение.

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

Безусловный переход. Является непосредственным переводом инструкции безусловного перехода исходной программы. Он используется при построении графа потока управления. Смысл безусловных переходов анализируется на этапе анализа потока управления.

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

В C это считается одним оператором, однако при переводе программы на язык ассемблера компилятор вынужден разбить его на довольно большое количество ассемблерных инструкций. Один из важнейших аспектов декомпиляции - восстановление осмысленных выражений из этих отдельных инструкций. Для этого промежуточное представление декомпилятора должно уметь описывать сложные выражения различной степени сложности. Возможность реализуется с помощью деревьев выражений, подобных применяемым компиляторами. На рисунке 13.1 показано дерево, описывающее приведённое выше выражение.

Рисунок 13.1. Дерево выражения, представляющее приведённое выше высокоуровневое выражение C. Операторы записаны именами инструкций IA-32, чтобы показать перевод выражения из представления машинного кода в дерево выражений.

Идея такого дерева в том, что оно даёт изящное структурированное представление последовательности арифметических инструкций. Каждая ветвь дерева приблизительно соответствует одной инструкции декомпилированной программы. Декомпилятор должен провести анализ потока данных этих инструкций и построить такое дерево. После построения дерева получить выражение языка высокого уровня довольно просто: достаточно обойти его. Процесс построения деревьев выражений из отдельных инструкций рассматривается ниже, в разделе об анализе потока данных.

Входные части декомпиляторов выполняют функцию, обратную выходным частям компиляторов. Выходная часть компилятора берёт промежуточное представление и преобразует его в собственный язык ассемблера целевой машины, тогда как входная часть декомпилятора берёт тот же собственный ассемблерный код и преобразует обратно в промежуточное представление декомпилятора. Первый этап процесса - пройти исходный исполняемый файл байт за байтом и проанализировать каждую инструкцию вместе с её операндами. Затем инструкции анализируются и переводятся в промежуточное представление декомпилятора. На этапе анализа кода это представление постепенно улучшается, чтобы подготовить его к преобразованию выходной частью в представление на языке высокого уровня.

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

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

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

Рассмотрим пример подобной последовательности. На раннем этапе развития архитектуры IA-32 блок операций с плавающей точкой не являлся неотъемлемой частью процессора, а был реализован отдельной микросхемой, которую обычно называли математическим сопроцессором и устанавливали в собственный разъём на системной плате. Это означало, что два набора инструкций были сильно изолированы друг от друга, а потому имели определённые ограничения. Например, при сравнении двух значений с плавающей точкой нельзя было просто выполнить сравнение и условный переход стандартными инструкциями. Проблема состояла в том, что математический сопроцессор не мог непосредственно обновлять регистр EFLAGS (сегодня это просто, поскольку оба блока реализованы в одной микросхеме). Поэтому результат сравнения чисел с плавающей точкой записывался в отдельный регистр состояния сопроцессора, который затем требовалось загрузить в один из регистров общего назначения; только после этого можно было проверить его значение и выполнить условный переход. Рассмотрим пример.

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

Итог состоит в том, что для перевода этой последовательности в промежуточное представление декомпилятора, где не должно быть никаких архитектурно-зависимых деталей, входная часть обязана "понять" её смысл и устранить код проверки конкретных флагов, константу 0x41 и тому подобное. Обычно это реализуют, добавляя во входную часть специальный код, способный расшифровывать последовательности такого рода.

Код, созданный входной частью декомпилятора, представлен в виде графа, каждый фрагмент кода в котором называется базовым блоком (basic block, BB). Эта графовая структура просто отображает инструкции потока управления, присутствующие в низкоуровневом машинном коде. Каждый BB заканчивается инструкцией потока управления, например переходом, вызовом или ret, либо меткой, на которую ссылается какая-либо инструкция перехода в другом месте кода, поскольку метки представляют точки слияния потока управления.

Блоки определяются для каждого фрагмента кода, на который имеются ссылки из других участков, обычно со стороны инструкции перехода. Кроме того, BB создаётся после каждой инструкции условного перехода, чтобы такая инструкция могла передать управление либо BB, представляющему целевой адрес перехода, либо BB с кодом, непосредственно следующим за условием. Эта идея показана на рисунке 13.3. Обратите внимание: для удобства чтения настоящий код на рисунке приведён на языке ассемблера IA-32, тогда как в большинстве декомпиляторов BB представлены внутренним набором инструкций декомпилятора.

Рисунок 13.3. Неструктурированный граф потока управления, представляющий ветвления исходной программы. Пунктирные стрелки обозначают инструкции условного перехода, а сплошные - случаи сквозного выполнения, то есть путь исполнения, когда переход не выполняется.

Граф потока управления на рисунке 13.3 довольно примитивен. По существу, это графическое представление низкоуровневых операторов потока управления программы. Такой простой анализ важно провести на раннем этапе декомпиляции, чтобы правильно разделить программу на базовые блоки. Фактическое структурирование графов в представление, более близкое к языкам высокого уровня, выполняется позднее, на этапе анализа потока управления.

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

На этапе анализа кода происходит большая часть интересного. Литературы о декомпиляции довольно мало, и официального названия у этапа, по-видимому, нет, поэтому я буду называть его анализом кода, хотя некоторые исследователи декомпиляторов говорят просто "средняя часть".

Этап анализа кода начинается с промежуточного представления программы, довольно близкого к исходному ассемблерному коду. Программа представлена набором инструкций, похожим на рассмотренный в предыдущем разделе, но в ней пока нет настоящих выражений. Анализ кода включает анализ потока данных, где формируются эти выражения; анализ типов, где выявляются сложные и примитивные типы данных; и анализ потока управления, где из созданного входной частью неструктурированного графа восстанавливаются высокоуровневые управляющие конструкции. Эти этапы подробно рассмотрены в следующих разделах.

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

Подробное описание этих управляющих конструкций и способов их реализации большинством современных компиляторов дано в приложении A. Конкретные алгоритмы преобразования неструктурированных графов в структурированные графы потока управления выходят за рамки книги. Их обстоятельное изложение можно найти в [Cifuentes2] и [Cifuentes3].

Значительная часть анализа потока управления проста, но некоторые идиомы компиляторов на этом этапе могут потребовать особого внимания. Например, многие компиляторы склонны преобразовывать циклы с предусловием в циклы с постусловием, добавляя перед началом цикла специальную проверку, которая не позволяет войти в него при невыполненном условии. Это делается как оптимизация, но с точки зрения декомпиляции способно несколько снизить читаемость кода, если конструкция не обработана правильно. Декомпилятор буквально переведёт такую схему и представит начальную проверку как дополнительный оператор if, которого, очевидно, никогда не было в исходном тексте, а за ним поместит цикл do...while. Автору декомпилятора имеет смысл выявить этот случай и правильно структурировать граф как обычный цикл с предусловием. Нет нужды говорить, что, вероятно, существуют и другие подобные ситуации, где оптимизации компилятора меняют структуру потока управления программы так, что декомпилированный результат становится менее читаемым.

Большинство исполняемых файлов содержит значительный объём библиотечного кода, скомпонованного с программой. При декомпиляции имеет смысл выявить эти функции, пометить их и не декомпилировать. Это полезно по нескольким причинам:

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

• Правильное выявление библиотечных вызовов даёт программе дополнительные "символы", поскольку теперь известны имена всех внутренних вызовов библиотеки, что значительно повышает читаемость декомпилированного результата.

• После правильного выявления библиотечных вызовов можно воспользоваться точными сведениями об их типах. Эти данные распространяются по программе (см. раздел о распространении типов ранее в этой главе) и значительно повышают читаемость.

Методы точного выявления библиотечных вызовов описаны в [Emmerik1]. Не углубляясь в подробности, основная идея состоит в создании сигнатур библиотечных файлов. Сигнатуры представляют собой простые последовательности первых нескольких байтов каждой функции библиотеки. При декомпиляции исполняемый файл просматривается в поисках этих сигнатур с использованием хеша для эффективности, а адреса всех библиотечных функций записываются. Обычно декомпилятор не декомпилирует такие функции, а лишь включает сведения об их типах данных в процесс анализа типов.

Подавляющее большинство логических выражений связано со сравнением двух или нескольких операндов. Обычно за ним следует код, действия которого зависят от результата сравнения. В следующих разделах показан механизм сравнения операндов на языке ассемблера IA-32. Для знаковых и беззнаковых операндов этот процесс несколько различается.

Основная инструкция сравнения операндов - CMP. По существу, она вычитает второй операнд из первого и отбрасывает результат. Флаги процессора сообщают следующим инструкциям итог вычитания. Как и для многих других инструкций, интерпретация флагов зависит от того, являются операнды знаковыми или беззнаковыми.

В таблице A.1 показано поведение инструкции CMP при сравнении знаковых операндов. Помните, что таблица также относится к инструкции SUB.

Таблица A.1. Результаты знакового вычитания для инструкций CMP и SUB (X обозначает левый операнд, Y - правый)

При рассмотрении таблицы A.1 становятся ясны основные правила определения результатов сравнения знаковых целых чисел. Кратко их можно сформулировать так:

• Если установлен ZF, результат вычитания равен нулю, а значит, операнды равны.

• Если все три флага сброшены, первый операнд больше второго, поскольку получен положительный результат без переполнения.

• Если результат отрицателен и переполнения нет (SF=1, OF=0), второй операнд больше первого.

• Если возникло переполнение, а результат положителен, второй операнд должен быть больше первого: по существу, получен отрицательный результат, слишком малый для представления операндом назначения, откуда и возникает переполнение.

• Если возникло переполнение, а результат отрицателен, первый операнд должен быть больше второго: по существу, получен положительный результат, слишком большой для представления операндом назначения, откуда и возникает переполнение.

Обычно запоминать таблицы результатов сравнения A.1 и A.2 не требуется, однако их всё же стоит изучить и убедиться, что вы правильно понимаете роль каждого флага при сравнении операндов. Это поможет в некоторых случаях реверс-инжиниринга, когда флаги используются необычным образом. Знание того, как флаги устанавливаются при сравнении и вычитании, очень полезно для правильного понимания логических последовательностей и быстрой расшифровки их смысла.

В таблице A.2 показано поведение инструкции CMP при сравнении беззнаковых операндов. Помните, что, как и таблица A.1, она относится также к инструкции SUB.

Таблица A.2. Результаты беззнакового вычитания для инструкций CMP и SUB (X обозначает левый операнд, Y - правый)

При рассмотрении таблицы A.2 становятся ясны основные правила определения результатов сравнения беззнаковых целых чисел, и очевидно, что с беззнаковыми операндами работать проще. Кратко правила выглядят так:

• Если установлен ZF, результат вычитания равен нулю, а значит, операнды равны.

• Если оба флага сброшены, первый операнд больше второго, поскольку получен положительный результат без переполнения.

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

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

Исследователю важно понимать эти мнемоники, поскольку практически каждая последовательность условного кода включает одну или несколько из них. Иногда их смысл интуитивно очевиден. Рассмотрим следующий код:

В этом примере очевидно, что JE (переход при равенстве) передаст управление SomePlace, если EAX равен 7. Это один из самых простых случаев, где понимать подробности инструкций наподобие CMP и кодов условий на самом деле не требуется. К сожалению для исследователей, существует довольно много случаев, где коды условий применяются неинтуитивно. Чтобы правильно понимать логику программы, важно знать, как они используют флаги. В следующих разделах перечислен каждый код условия и объяснено, какие флаги и почему он использует.

В таблице A.3 приведены коды условий IA-32, определённые для знаковых операндов. Обратите внимание, что во всех знаковых кодах переполнение обнаруживается по флагу OF, поскольку арифметические инструкции обозначают им знаковое переполнение.

Таблица A.3. Коды условий для знаковых операндов инструкций CMP и SUB

В таблице A.4 приведены коды условий IA-32, определённые для беззнаковых операндов. Обратите внимание, что во всех беззнаковых кодах переполнение обнаруживается по флагу переноса CF, поскольку арифметические инструкции обозначают им беззнаковое переполнение.

Таблица A.4. Коды условий для беззнаковых значений

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

На процессорах IA-32 функции почти всегда вызываются инструкцией CALL, которая сохраняет текущий указатель инструкции в стеке и переходит по адресу функции. Благодаря этому вызовы функций легко отличить от других безусловных переходов.

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

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

Вызовы импортированных функций реализуются с помощью каталога импорта и таблицы адресов импорта (см. главу 3). Во время выполнения каталог сопоставляет имя функции с соответствующей функцией целевого исполняемого файла, а IAT хранит её настоящий адрес. Вызывающая сторона загружает указатель функции из IAT и вызывает её. Ниже приведён пример типичного вызова импортированной функции:

Обратите внимание на DWORD PTR перед указателем: эта часть важна, поскольку предписывает процессору перейти не по адресу IAT_Pointer, а по адресу, на который указывает IAT_Pointer. Помните также, что указатель обычно не будет иметь имени, в зависимости от дизассемблера, и будет просто содержать адрес внутри IAT.

Импортированные вызовы легко обнаружить, поскольку кроме них функции редко вызываются косвенно через жёстко заданный указатель. Однако я рекомендую в самом начале сеанса реверс-инжиниринга определить расположение IAT и с её помощью подтверждать, что функция действительно импортирована. Найти IAT довольно легко: это можно сделать различными инструментами, которые выгружают заголовок PE модуля и сообщают адрес IAT. Инструменты для выгрузки заголовков PE рассмотрены в главе 4.

Некоторые дизассемблеры и отладчики автоматически обозначают вызов импортированной функции, внутренне проверяя адрес IAT, и тем самым избавляют вас от этой работы.

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

Рисунок A.4. Высокоуровневое и низкоуровневое представления условного кода с несколькими альтернативными путями выполнения.

В языках высокого уровня существуют специальные операторы, позволяющие использовать составные условия в одном условном выражении. При указании нескольких условий код должен определять способ их объединения.

Два самых распространённых оператора объединения нескольких логических выражений - AND и OR, которые не следует путать с операторами побитовой логики.

Как следует из названия, AND, обозначаемый в C и C++ как &&, означает, что для истинности условия должны выполняться оба выражения. Обнаружить такой код на языке ассемблера обычно очень легко, поскольку будут видны две последовательные проверки, условно переходящие к одному адресу. Вот пример:

Показательный элемент этого фрагмента - оба условных перехода указывают на один адрес в коде (AfterCondition). Идея проста: проверить первое условие и перейти к концу условного блока, если оно не выполняется. Если первое условие истинно, проверить второе и снова перейти к концу блока, если оно ложно. Условный блок кода располагается сразу после второго условного перехода, поэтому, если ни один переход не выполнен, управление немедленно начинает исполнять этот блок. Настоящие условия расшифровываются так же, как в одиночном условном выражении, то есть они тоже обращены. Здесь проверка того, что Variable1 не равна 100, означает, что исходный код проверял её на равенство 100. По этим сведениям можно восстановить исходный код фрагмента:

На рисунке A.5 показано, как приведённый высокоуровневый код соответствует рассмотренному ранее ассемблерному.

Рисунок A.5. Высокоуровневое и низкоуровневое представления составного условного оператора с двумя условиями, объединёнными оператором AND.

Другой распространённый логический оператор - OR, применяемый для создания условных выражений, где достаточно выполнения одного из заданных условий. OR означает, что условие считается истинным, если истинно первое или второе выражение. В C и C++ он обозначается символом ||. Выявлять при реверс-инжиниринге условные операторы с OR несколько сложнее, чем с AND. Прямой способ реализации OR состоит в условном переходе для каждого выражения без обращения условий и добавлении завершающего перехода, который пропускает условный блок, если ни одно условие не выполнено. Вот пример этой стратегии:

На рисунке A.6 показано соответствие предыдущего фрагмента исходному коду.

Рисунок A.6. Высокоуровневое и низкоуровневое представления составного условного оператора с двумя условиями, объединёнными оператором OR.

И снова наиболее заметный элемент фрагмента - последовательность условных переходов, указывающих на один и тот же код. Помните, что при таком подходе условные переходы направлены в условный блок, в отличие от рассмотренных ранее случаев, где они указывали на код после условных блоков. Этот подход применяют GCC и некоторые другие компиляторы; его преимущество, по крайней мере с точки зрения реверс-инжиниринга, в довольно высокой читаемости и интуитивности. Небольшой недостаток производительности создаёт завершающий JMP, который достигается, если не выполнено ни одно условие.

Другие оптимизирующие компиляторы, например компиляторы Microsoft, избавляются от лишнего JMP немного иным способом реализации OR. Обращается только второе условие, и его переход направляется к коду после условного блока, тогда как первое условие по-прежнему указывает в сам блок. На рисунке A.7 показан результат компиляции той же логики таким способом.

Первое условие проверяет равенство Variable1 значению 100 точно как в исходном коде. Второе обращено и теперь проверяет, что Variable2 не равна 50. Причина в том, что первое условие должно перейти к условному коду, если оно истинно, а второе не должно выполнять переход, если истинно его обращённое условие. Второе условие пропускает условный блок, когда исходное условие не выполняется.

Рисунок A.7. Высокоуровневое и низкоуровневое представления условного оператора с двумя условиями, объединёнными более эффективной реализацией OR.

Что происходит, если логический оператор объединяет более двух условий? Обычно стратегия для двух условий просто расширяется. Для GCC это означает добавление ещё одного условия перед безусловным переходом.

Во фрагменте на рисунке A.8 Variable1 и Variable2 сравниваются с теми же значениями, что в исходном примере, но здесь добавлена Variable3, сравниваемая с нулём. Пока все условия связаны оператором OR, компилятор просто добавляет условные переходы в условный блок. И снова сразу после последней инструкции условного перехода всегда помещается безусловный переход. Если ни одно условие не выполняется, он пропускает условный блок и направляется к следующему коду.

В более оптимизированном варианте подход тот же, но вместо безусловного перехода обращается последнее условие. Остальные реализованы прямыми условными переходами к условному блоку. На рисунке A.9 показано, что происходит при компиляции примера с рисунка A.8 вторым способом.

Рисунок A.8. Высокоуровневое и низкоуровневое представления составного условного оператора с тремя условиями, объединёнными оператором OR.

Рисунок A.9. Высокоуровневое и низкоуровневое представления условного оператора с тремя условиями, объединёнными более эффективной реализацией OR.

Идея проста. При использовании нескольких операторов OR компилятор создаёт ряд последовательных условных переходов, каждый из которых при истинном условии направляется в условный блок. Последнее условие обращается и переходит к коду сразу после условного блока, поэтому при выполнении исходного условия переход не происходит и управление достигает блока, расположенного непосредственно после последней условной инструкции. В предыдущем примере завершающая проверка устанавливает, что Variable3 не равна нулю, поэтому используется JE.

Теперь рассмотрим, что происходит при объединении оператором AND более двух условий (см. рисунок A.10). Здесь компилятор просто добавляет всё новые обращённые условия, которые при выполнении пропускают условный блок, поскольку сами условия обращены, а при невыполнении переходят к следующему условию или к самому условному блоку.

Языки высокого уровня позволяют программистам объединять логическими операторами любое количество условий. Поэтому можно создавать сложные сочетания условных выражений, связанных логическими операторами.

Рисунок A.10. Высокоуровневое и низкоуровневое представления составного условного оператора с тремя условиями, объединёнными оператором AND.

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

Этот пример совпадает с предыдущим образцом оптимизированной реализации OR, но добавлено условие, проверяющее равенство Variable3 нулю. Если она равна нулю, условный блок не выполняется. Ниже приведено высокоуровневое представление предыдущего ассемблерного фрагмента на C.

Определить по-настоящему универсальные правила чтения составных условий на языке ассемблера нелегко, но основной параметр, на который следует смотреть, - целевой адрес каждого условного перехода. Условия, объединённые оператором OR, обычно переходят непосредственно к условному блоку и не обращаются, кроме последнего условия, которое указывает на код после блока и является обращённым. В отличие от них условия, объединённые AND, обычно обращены и переходят к блоку после условного кода. При анализе сложных составных условий нужно применять эти базовые правила, выясняя смысл каждого условия и способ их соединения.

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

У компиляторов есть несколько способов обработки блоков switch в зависимости от их размера и диапазона принимаемых значений. В следующих разделах показаны две самые распространённые реализации многосторонних операторов: табличная и древовидная.

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

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

На рисунке A.11 показана табличная реализация многостороннего условного оператора. Первая константа case в исходном коде равна 1, а последняя - 5, поэтому таблица должна поддерживать пять различных блоков. Блок default не входит в таблицу, поскольку его не запускает конкретное значение: любое значение вне диапазона 1-5 приводит программу к этому блоку. Для эффективного поиска компилятор вычитает 1 из ByteValue и сравнивает результат с 4. Если ByteValue больше 4, выполняется безусловный переход к default. В противном случае управление достигает безусловного JMP, вызывающего конкретный условный блок. Именно этот JMP отличает табличные многосторонние операторы и сильно упрощает их выявление. Вместо непосредственного жёстко заданного адреса, как почти во всех других безусловных переходах, он использует динамически вычисленный адрес памяти, обычно заключённый в дизассемблере в квадратные скобки, чтобы получить целевой адрес. По существу, это и есть поиск в таблице.

В коде каждого условного блока обратите внимание, что почти каждый case заканчивается безусловным JMP обратно к коду после switch. Исключение - case 3, который не завершается инструкцией break. Поэтому после его выполнения управление непосредственно переходит в case 4. В табличной реализации это работает естественно, поскольку компилятор последовательно размещает отдельные варианты в памяти. Код case 4 всегда находится сразу после case 3, и компилятор просто не добавляет безусловный переход.

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

Рисунок A.11. Табличная реализация блока switch.

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

Чтобы реализовать двоичный поиск для блоков switch, компилятор должен внутренне представить блок в виде дерева. Вместо сравнения заданного значения с каждым возможным вариантом во время выполнения он создаёт код, который сначала проверяет, находится ли значение в первой или второй группе. Затем компилятор переходит к другому участку кода, где значение сравнивается с допустимыми значениями меньшей подгруппы. Процесс продолжается до обнаружения правильного элемента или выхода из условного блока, если для искомого значения не найдено ни одного case.

Рассмотрим обычный блок switch на C и проследим, как компилятор преобразует его в дерево.

На рисунке A.12 показано, как компилятор может представить предыдущий блок switch деревом, а также приведён созданный им ассемблерный код, реализующий каждый узел дерева.

Рисунок A.12. Древовидная реализация блока switch, включая ассемблерный код.

Одна относительно необычная особенность древовидных многосторонних операторов, которая немного облегчает их распознавание в дизассемблированном коде, - многочисленные вычитания, часто выполняемые над одним регистром. Обычно за ними следуют условные переходы к конкретным блокам case (эта схема хорошо видна в блоке 501_Or_Below на рисунке A.12). Как правило, компилятор начинает с исходного значения, переданного условному блоку, и постепенно вычитает из него определённые величины, обычно значения case, постоянно проверяя результат на ноль. Это просто эффективный способ определить нужный блок с помощью минимального кода.

Если задуматься, цикл - всего лишь фрагмент условного кода наподобие рассмотренных ранее, но выполняемый многократно, обычно до тех пор, пока условие не перестанет быть истинным. Циклы, как правило, хотя и не всегда, содержат некоторый счётчик, управляющий количеством оставшихся итераций. По существу, циклы любого языка высокого уровня делятся на две категории: с предусловием, где логическая проверка предшествует телу, то есть многократно выполняемому коду, и с постусловием, где сначала расположено тело, а затем логика.

Рассмотрим различные виды циклов и их представление на языке ассемблера.

Циклы с предусловием, вероятно, являются самой распространённой конструкцией, хотя немного уступают циклам с постусловием по эффективности. Проблема в том, что для представления такого цикла ассемблерный код должен содержать две инструкции перехода: условный переход в начале, завершающий цикл при невыполненном условии, и безусловный переход в конце, возвращающийся к началу. Рассмотрим простой цикл с предусловием и его реализацию компилятором:

Легко увидеть, что это цикл с предусловием: он сначала проверяет, что c меньше 1000, а затем выполняет тело. Вот ассемблерный код, который большинство компиляторов создаст из предыдущего фрагмента:

Оказывается, хотя условие в исходном коде находилось перед циклом, компилятор счёл нужным перенести его. Причина в небольшом повышении производительности при проверке счётчика после тела. Как я уже объяснял, преобразование цикла в конструкцию с постусловием позволяет компилятору устранить безусловный JMP в конце.

У такой реализации есть один потенциальный риск. Что произойдёт, если начальное значение счётчика выходит за границы? Это может вызвать проблемы, поскольку тело использует счётчик для обращения к массиву. Программист ожидал, что счётчик будет проверен до выполнения тела, а не после него! В данном случае проблемы нет, потому что перед началом цикла счётчик явно инициализируется нулём, поэтому компилятор знает его значение и понимает, что проверка не нужна. Если бы счётчик поступал из неизвестного источника, например как параметр другой неизвестной функции, компилятор, вероятно, поместил бы логику на положенное место, в начало последовательности.

Проверим это, изменив предыдущий цикл C так, чтобы значение счётчика c поступало из внешнего источника, и повторно скомпилируем последовательность. В этом случае компилятор Microsoft выдаёт следующий код:

По-видимому, даже здесь компилятор стремится избежать двух переходов. Вместо переноса сравнения в начало цикла и добавления безусловного перехода в конец он оставляет всё как есть и просто добавляет ещё одно условие перед циклом. Эта начальная проверка, выполняемая лишь однажды, не позволяет войти в цикл при недопустимом значении счётчика. Остальная часть остаётся прежней.

Для целей данного обсуждения цикл for эквивалентен рассмотренному ранее циклу с предусловием.

Какое же влияние циклы с постусловием из языка высокого уровня оказывают на ассемблерный результат, если компилятор и без того создаёт последовательности с постусловием? Неудивительно, что очень небольшое.

Если программа содержит цикл do...while(), компилятор создаёт последовательность, очень похожую на код из предыдущего раздела. Единственная разница в том, что для do...while() ему не нужно беспокоиться о том, должно ли условие выполняться при первой итерации. Оно в любом случае расположено в конце цикла и там же обязательно проверяется. В отличие от предыдущего случая, где неизвестное начальное значение счётчика заставило компилятор добавить ещё одну проверку перед циклом, для do...while() это просто не требуется. Поэтому в цикле с постусловием логика всегда находится после тела, как и в исходном коде.

Условие прерывания возникает, когда код внутри тела завершает цикл; в C и C++ для этого служит ключевое слово break. Оно просто прерывает цикл и переходит к следующему за ним коду. Ниже приведён уже рассмотренный цикл с добавленным условным оператором break:

Этот код немного отличается от предыдущих примеров: хотя счётчик поступает из неизвестного источника, условие проверяется только в конце цикла. Это признак постусловия. Кроме того, добавлена новая проверка текущего элемента массива перед инициализацией, которая переходит к AfterLoop, если элемент не равен нулю. Это и есть оператор break - просто изящное имя старой доброй команды goto, столь популярной в "менее совершенных" языках программирования.

По этому коду легко вывести, что исходный текст имел примерно следующий вид:

Пропуск итерации цикла в C и C++ реализуется ключевым словом continue. Оператор пропускает текущую итерацию и сразу переходит к условию цикла, которое решает, выполнять ли следующую или выйти. В зависимости от вида цикла счётчик, если он используется, обычно не увеличивается, поскольку соответствующий код пропускается вместе с остальным телом. Здесь циклы for отличаются от while: в for увеличение счётчика считается частью логического выражения цикла, поэтому continue его не пропускает. Рассмотрим созданный компилятором ассемблерный фрагмент цикла с оператором пропуска:

Этот пример представляет тот же цикл, но теперь условие вызывает continue вместо break. Обратите внимание, что оно переходит к NextCycle и пропускает увеличение счётчика. Затем программа проверяет его значение и возвращается к началу цикла, если оно меньше 1000.

Вот тот же код с небольшим изменением:

Единственная разница состоит в том, что теперь NextCycle расположен раньше, перед кодом увеличения счётчика. Поэтому, в отличие от предыдущего случая, continue увеличит счётчик и выполнит логику цикла. Это указывает, что цикл, вероятно, реализован ключевым словом for. Ту же последовательность можно получить без for, используя while или do...while и увеличивая счётчик оператором ++ внутри условного выражения. Тогда логический оператор выглядел бы так:

Разворачивание цикла - оптимизация уровня формирования кода, не привязанная к процессору или набору инструкций. По существу, это перестройка высокоуровневого кода для получения более эффективного машинного. Ниже приведён ассемблерный пример частично развёрнутого цикла:

Это явно частично развёрнутый цикл, и лучший признак - увеличение счётчика на три при каждой итерации. По существу, компилятор трижды продублировал тело, поэтому одна итерация выполняет работу трёх. Код счётчика скорректирован и прибавляет 3 вместо 1. Это эффективнее благодаря значительному сокращению накладных расходов: вместо выполнения CMP и JL 0x3e7 (999) раз они исполняются лишь 0x14d (333) раза.

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

У некоторых оптимизирующих компиляторов есть специальные методы создания логики без ветвлений. Их главная цель - устранить или по крайней мере сократить количество условных переходов, необходимых для реализации заданного логического выражения. Причины стремления свести число переходов к абсолютному минимуму объяснены в разделе "Аппаратная среда выполнения современных процессоров" главы 2. Кратко говоря, из-за конвейера при встрече с условным переходом процессор должен угадать или предсказать, произойдёт ли он, и на основе прогноза решить, какие инструкции добавить в конец конвейера: следующие непосредственно за ветвлением или находящиеся по целевому адресу. При ошибке весь конвейер опустошается и должен быть заполнен заново. Потерянное время сильно зависит от внутреннего устройства процессора, прежде всего от длины конвейера, но для большинства конвейерных процессоров повторное заполнение чрезвычайно дорого.

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

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

Некоторые логические выражения можно непосредственно преобразовать в ряд арифметических операций вообще без условного выполнения. Это изящные математические приёмы, позволяющие компилятору перевести логику с ветвлениями из исходного кода в простую последовательность арифметических действий. Рассмотрим следующий код:

Предыдущий созданный компилятором фрагмент довольно часто встречается в программах IA-32, и многим исследователям трудно расшифровать его смысл. Учитывая распространённость таких последовательностей, стоит внимательно изучить пример и убедиться, что вы понимаете его работу.

Код начинается с простого логического AND локальной переменной и 0x00001000; результат сохраняется в EAX (инструкция AND всегда помещает результат в первый, левый операнд). Затем выполняется несколько менее распространённая инструкция NEG. Это простое отрицание, обращающее знак операнда; операцию иногда называют получением дополнительного кода. Математически NEG выполняет следующее:

Интересная часть последовательности - инструкция SBB, вычитание с заёмом. Она прибавляет значение CF ко второму, правому операнду, а затем вычитает результат из первого. Вот псевдокод SBB:

Обратите внимание, что в предыдущем примере SBB используется с одним и тем же операндом. По существу, она вычитает EAX из самого себя, что математически бессмысленно, если не учитывать CF. Поскольку CF прибавляется ко второму операнду, результат зависит только от этого флага. Если CF == 1, EAX станет равен -1. Если CF == 0, EAX станет нулём. Очевидно, что значение EAX после первой NEG несущественно: следующая SBB немедленно уничтожает его, вычитая EAX из самого себя. Возникает вопрос, зачем компилятор вообще добавил NEG.

В документации Intel сказано, что помимо обращения знака операнда NEG устанавливает CF в зависимости от его значения. Если при выполнении NEG операнд равен нулю, CF сбрасывается; если не равен, CF устанавливается. По-видимому, некоторые компиляторы используют эту дополнительную возможность NEG как хитроумный способ проверить операнд на нулевое или ненулевое значение. Кратко разберём каждый этап последовательности:

• С помощью NEG проверить исходный операнд на ноль. Результат сохраняется в CF.

• С помощью SBB перенести результат из CF обратно в пригодный для использования регистр. Из-за природы SBB ненулевое значение CF превратится в -1, а не в 1. Является ли это проблемой, зависит от языка высокого уровня: некоторые языки обозначают истину единицей, другие - значением -1.

• Поскольку код примера получен компилятором C/C++, где истина обозначается единицей, требуется дополнительная NEG. На этот раз она действительно применяется для обращения знака: -1 превращается в 1, а ноль остаётся нулём.

Следующий псевдокод поможет прояснить описанные этапы:

По существу, последовательность проверяет определённый бит EAX (0x00001000) и возвращает 1, если он установлен, или 0, если нет. Она довольно изящна, поскольку является чисто арифметической и не содержит инструкций условного перехода. Быстро переведём её обратно в высокоуровневое представление C:

Так намного понятнее, не правда ли? И всё же исследователям часто приходится работать с менее читаемыми и непривлекательными последовательностями, подобными только что разобранной. Знание и понимание таких низкоуровневых приёмов очень полезно, поскольку они чрезвычайно часто встречаются в коде, созданном компилятором.

Рассмотрим ещё один, немного более сложный пример реализации высокоуровневых логических конструкций чистой арифметикой:

Вы заметите, что эта последовательность тоже использует сочетание NEG/SBB, но её назначение несколько сложнее. Сначала вызывается функция, и из возвращённого ею значения вычитается 4. Затем NEG и SBB проверяют результат на ноль точно как в предыдущем примере. Если после вычитания возвращаемое SomeFunc значение равно нулю, SBB присвоит EAX ноль. Если оно не равно нулю, SBB задаст EAX значение -1, или 0xffffffff в шестнадцатеричной форме.

Следующие две инструкции - самая хитрая часть последовательности. Начнём с AND. Поскольку SBB устанавливает EAX либо в ноль, либо в 0xffffffff, следующую AND можно считать аналогом инструкции условного присваивания, подобной рассматриваемой позднее CMOV. Выполняя AND EAX с константой, код по существу говорит: "Если результат SBB равен нулю, ничего не делай. Если результат равен -1, задай EAX указанную константу". Затем код безусловно прибавляет к EAX 54 и возвращает управление вызывающей стороне.

Теперь задача состоит в выяснении общего смысла. Очевидно, последовательность каким-либо образом преобразует возвращаемое SomeFunc значение и передаёт преобразованный результат вызывающей стороне. Проанализируем итог. Возвращается одно из двух значений: если результат SBB равен нулю, то есть SomeFunc вернула 4, EAX получает 54. Если SBB выдаёт 0xffffffff, EAX станет равен 2, поскольку AND задаст -52, а ADD увеличит значение до 2.

Эта последовательность сравнивает два целых числа и без ветвлений создаёт одно значение при их равенстве и другое при неравенстве. Вот версия предыдущего ассемблерного фрагмента на C:

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

Обычная форма настройки основана на перестройке расположения функций. Программа запускается, а средство настройки рабочего набора наблюдает, какие функции выполняются чаще всего. Затем порядок функций в двоичном файле перестраивается по этим сведениям: самые популярные переносятся в начало модуля, а менее популярные размещаются ближе к концу. Благодаря этому операционная система может держать область "популярного кода" в памяти, а остальную часть модуля загружать лишь по необходимости и снова выгружать, когда она больше не нужна.

В большинстве сценариев настройка на уровне функций не влияет на процесс реверс-инжиниринга, кроме одной небольшой подсказки о программе: адрес функции относительно начала модуля показывает её популярность. Чем ближе функция к началу, тем чаще она используется. Функции почти в самом конце модуля, то есть с высокими адресами, выполняются очень редко и, вероятно, отвечают за необычные случаи вроде обработки ошибок или редко используемых возможностей. Эта идея показана на рисунке A.13.

Рисунок A.13. Влияние настройки рабочего набора на уровне функций на размещение кода в двоичных исполняемых файлах.

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

Для исследователя такая настройка полезна тем, что показывает вероятность выполнения конкретного условия при обычной работе. Однако невозможность увидеть всю функцию как единое целое создаёт серьёзные неудобства. Поскольку блоки кода переносятся за пределы функций, которым принадлежат, сеансы реверс-инжиниринга таких модулей имеют некоторые особенности. Важно помнить, что функции разделены и разбросаны по модулю, а понять, что перед вами отсоединённый фрагмент неизвестной функции на другом конце модуля, бывает трудно. Код непосредственно перед фрагментом и после него может вообще не иметь к нему отношения. Один приём, иногда позволяющий установить связи между изолированными фрагментами, - поиск безусловного JMP в конце. Нередко отсоединённый код возвращается переходом к основному телу функции и тем самым раскрывает его расположение. В других случаях фрагмент просто выполняет возврат, и его связь с основной функцией остаётся неизвестной. На рисунке A.14 показано влияние настройки на уровне строк на размещение кода.

Рисунок A.14. Влияние настройки рабочего набора на уровне строк на размещение кода в том же образце двоичного исполняемого файла.

Прежде чем обсуждать умножение и деление, рассмотрим несколько основ. Обе операции считаются в компьютерах довольно сложными, намного сложнее сложения и вычитания. Процессоры IA-32 предоставляют инструкции для нескольких видов умножения и деления, но все они относительно медленны. Поэтому компиляторы довольно часто реализуют обе операции другими способами.

Деление или умножение числа на степени двойки очень естественно для компьютера, поскольку хорошо согласуется с двоичным представлением целых. Это подобно тому, как людям легко делить и умножать на степени десяти: достаточно переместить несколько нулей. Интересно, что компьютеры работают с делением и умножением во многом так же. Общая стратегия - максимально приблизить делитель или множитель к удобному числу, легко представленному системой счисления. Затем выполняется относительно простое вычисление, после чего оставшаяся часть делителя или множителя вносится в результат. Для IA-32 эквивалент перемещения нулей - двоичные сдвиги инструкциями SHL и SHR. SHL сдвигает влево, что соответствует умножению на степени двойки. SHR сдвигает вправо, что соответствует делению на степени двойки. После сдвига компиляторы обычно корректируют результат сложением и вычитанием.

При умножении одной переменной на другую наиболее эффективным инструментом обычно является MUL/IMUL. Однако большинство компиляторов полностью избегает этих инструкций, если множитель является константой. Например, умножение переменной на 3 обычно реализуется сдвигом числа на один бит влево и прибавлением исходного значения. Это можно сделать сочетанием SHL и ADD либо с помощью LEA:

В более сложных случаях компиляторы используют сочетание LEA и ADD. Например, следующий код по существу выполняет умножение на 32:

По существу, здесь вычисляется y=x*2*2*2*2*2, что эквивалентно y=x*32. Если задуматься, этот код, созданный компилятором Intel, довольно удивителен. Во-первых, он велик по размеру: одна LEA и четыре ADD намного длиннее одной SHL. Во-вторых, неожиданно, что последовательность действительно быстрее простого сдвига SHL на 5, особенно если учесть высокую производительность SHL. Объяснение в том, что LEA и ADD имеют очень малую задержку и высокую пропускную способность. Вероятно, вся последовательность способна выполниться менее чем за три такта, хотя это зависит от конкретного процессора и других условий среды. В отличие от неё задержка SHL равна четырём тактам, поэтому использовать её не столь эффективно.

Рассмотрим ещё одну последовательность умножения:

Эта последовательность, созданная GCC, с помощью LEA умножает ESI на 3, а затем SAL (та же инструкция, что и SHL, у них один код операции) дополнительно умножает результат на 4. Вместе две операции умножают операнд на 12. Затем код вычитает из результата исходный операнд. По существу, последовательность умножает его на 11. Математически это можно записать так: y=(x+x*2)*4-x.

По существу, остаток - та же операция, что и деление, но используется другая часть результата. Ниже приведён самый распространённый и интуитивный способ вычислить остаток для знакового 32-разрядного целого:

Этот код делит Divisor на 100 и помещает результат в EDX. Это самая тривиальная реализация, поскольку остаток получается простым делением двух значений с помощью IDIV, процессорной инструкции знакового деления. Обычное поведение IDIV состоит в помещении частного в EAX, а остатка в EDX, поэтому следующий код может просто взять остаток из EDX. Обратите внимание: поскольку IDIV получает 32-разрядный делитель EDI, она использует 64-разрядное делимое в EDX:EAX, поэтому применяется CDQ. Эта инструкция просто преобразует значение EAX в 64-разрядную величину EDX:EAX. Дополнительные сведения о CDQ приведены далее в этом приложении, в разделе о преобразовании типов.

Такой подход хорош для исследователя благодаря высокой читаемости, но не является самым быстрым при выполнении. IDIV довольно медленна, это одна из самых медленных инструкций всего набора. Данный код создан компилятором Microsoft.

Некоторые компиляторы действительно используют для вычисления остатка умножение на обратную величину (см. раздел о делении).

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

MOVSX эквивалентна MOVZX, но при увеличении целого вместо расширения нулями выполняет расширение знака. Инструкцию можно применять для преобразования 8-разрядного операнда в 16- или 32-разрядный либо 16-разрядного в 32-разрядный.

Инструкция CDQ используется для преобразования знакового 32-разрядного целого в EAX в 64-разрядное значение EDX:EAX с расширением знака. Во многих случаях её присутствие можно считать доказательством того, что хранящееся в EAX значение является знаковым целым, а следующий код будет совместно трактовать EDX и EAX как знаковое 64-разрядное число, где EDX содержит старшие 32 бита, а EAX - младшие. Аналогично, если непосредственно перед инструкцией, совместно использующей EDX и EAX как 64-разрядную величину, EDX устанавливается в ноль, можно наверняка утверждать, что EAX содержит беззнаковое целое.

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

Прежде чем обсуждать отдельные соглашения, следует рассмотреть основные инструкции вызова функций - CALL и RET. Инструкция CALL помещает в стек текущий указатель инструкции (на самом деле она сохраняет указатель на инструкцию, следующую за CALL) и выполняет безусловный переход по новому адресу кода.

Инструкция RET является парной для CALL и служит последней инструкцией практически каждой функции. RET извлекает из стека адрес возврата, ранее сохранённый CALL, помещает его в регистр EIP и продолжает выполнение с этого адреса.

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

cdecl - стандартное соглашение о вызовах C и C++. Его отличительная особенность состоит в том, что функции могут получать динамическое число параметров. Это возможно потому, что после вызова функции указатель стека восстанавливает вызывающая сторона. Кроме того, в cdecl функции получают параметры в порядке, обратном порядку в остальных соглашениях о вызовах. Первый параметр помещается в стек первым, а последний - последним. Вызовы cdecl довольно легко распознать: любая функция, которая принимает один или несколько параметров и завершается простой инструкцией RET без операндов, вероятнее всего, является функцией cdecl.

Как следует из названия, fastcall - несколько более производительное соглашение о вызовах, использующее регистры для передачи первых двух параметров функции. Остальные параметры передаются через стек. Изначально fastcall было соглашением, специфичным для Microsoft, но теперь его поддерживает большинство крупных компиляторов, поэтому в современных программах оно встречается довольно часто. fastcall всегда использует ECX и EDX для хранения соответственно первого и второго параметров функции.

Соглашение stdcall очень распространено в Windows, поскольку применяется всеми функциями Windows API и системными функциями. В отношении способа и порядка передачи аргументов stdcall противоположно cdecl. Функции stdcall получают параметры в порядке, обратном cdecl: последний параметр функции stdcall помещается в стек первым. Ещё одно важное различие состоит в том, что функции stdcall сами очищают свой стек, тогда как в cdecl это обязанность вызывающей стороны. Для очистки стека функции stdcall обычно используют инструкцию RET. Она может принимать необязательный операнд, задающий число байтов, которые следует удалить из стека после перехода обратно к вызывающей стороне. Поэтому в функциях stdcall переданный RET операнд часто раскрывает число байтов параметров: разделив его на 4, можно получить число принимаемых функцией параметров. Это очень полезная подсказка как для выявления функций stdcall при реверс-инжиниринге, так и для определения числа их параметров.

Это соглашение применяется компиляторами Microsoft и Intel при вызове метода C++ со статическим числом параметров. Быстро распознать такой вызов можно по следующему признаку: любая последовательность вызова функции, которая загружает допустимый указатель в ECX и помещает параметры в стек, но не использует EDX, является вызовом метода C++. Смысл в том, что каждый метод C++ должен получать указатель на класс, называемый указателем this, и, вероятно, интенсивно его использовать, поэтому компилятор применяет более эффективный способ передачи и хранения именно этого параметра.

Для функций-членов с динамическим числом параметров компиляторы обычно используют cdecl и просто передают указатель this как первый параметр в стеке.

Локальные переменные программисты используют для хранения любых непосредственных значений, необходимых текущей функции. К ним относятся счётчики, указатели и прочие кратковременные данные. У компиляторов есть два основных варианта управления локальными переменными: их можно разместить в стеке или сохранить в регистре. Оба варианта рассматриваются далее.

Во многих случаях компиляторы просто заранее выделяют место для переменной в стековой области функции. Это область стека непосредственно под адресом возврата и сохранённым указателем базы, то есть перед ними. В большинстве кадров стека EBP указывает на конец этой области, поэтому любой код, которому нужна локальная переменная, должен использовать EBP и вычитать из него определённое смещение, например:

Этот код читает по адресу EBP - 4, который обычно является началом области локальных переменных. Конкретный тип данных переменной из этой инструкции неизвестен, однако по использованию EAX, а не одного из регистров меньшего размера, очевидно, что компилятор считает её полным 32-разрядным значением. Обратите внимание: поскольку доступ к переменной выполняется с помощью по существу жёстко заданного смещения относительно EBP, она и соседние переменные должны иметь фиксированный, заранее определённый размер.

Картирование и именование локальных переменных функции - критически важный шаг реверс-инжиниринга. После него расшифровка логики и потока управления функции становится удивительно проще!

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

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

С точки зрения производительности компиляторы всегда стремятся хранить все локальные переменные в регистрах. Регистры неизменно служат самым эффективным способом хранения непосредственных значений, а их использование всегда даёт наиболее быстрый и компактный код. Компактность объясняется тем, что у большинства инструкций есть короткие заранее назначенные коды для обращения к регистрам. Обычно в компиляторе имеется отдельный компонент распределения регистров, который оптимизирует их использование генерируемым кодом. Разработчики компиляторов нередко прилагают значительные усилия к оптимизации этих компонентов, чтобы распределять регистры как можно эффективнее, поскольку это способно существенно повлиять на общий размер и эффективность программы.

На способность компилятора разместить локальную переменную в регистре влияет несколько факторов. Важнейший из них - наличие места. В процессорах IA-32 восемь регистров общего назначения, два из которых используются для управления стеком. Остальные шесть обычно как можно эффективнее распределяются между локальными переменными. Исследователю важно помнить, что большинство переменных не используется на протяжении всего времени жизни функции, поэтому регистры можно применять повторно. Это может сбивать с толку: после перезаписи переменной трудно определить, представляет ли регистр всё ту же сущность, то есть прежнюю переменную, или уже совершенно новую. Наконец, ещё один фактор, вынуждающий компилятор использовать для локальных переменных адреса памяти, возникает при получении адреса переменной оператором &: в таком случае у компилятора нет выбора, кроме как поместить локальную переменную в стек.

Обобщённая структура данных - любой блок памяти, представляющий набор полей разных типов, каждое из которых находится на постоянном расстоянии от начала блока. Это очень широкое определение, охватывающее всё, что объявлено ключевым словом struct в C и C++ или class в C++. Важно помнить, что такие структуры имеют статическую компоновку, определённую во время компиляции, и обычно статический размер. Можно создать структуру данных, последним членом которой является массив переменного размера; тогда генерируется код, динамически выделяющий структуру во время выполнения на основе вычисленного размера. Такие структуры редко находятся в стеке, потому что обычно стек содержит только элементы фиксированного размера.

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

Хорошим примером служит логический член структуры, выровненной по 32-разрядной границе. Логическое значение занимает 1 бит, но большинство компиляторов выделяет для него полное 32-разрядное слово. Дело в том, что потеря 31 бита пространства несущественна по сравнению с узким местом производительности, возникающим из-за нарушения выравнивания остальной структуры данных. Помните, что наименьшая единица, к которой 32-разрядные процессоры обычно могут обращаться непосредственно, - 1 байт. Если создать член данных длиной 1 бит, для доступа к нему и ко всем последующим членам процессору придётся не только выполнять невыровненные обращения к памяти, но и проделывать довольно много сдвигов и операций AND, чтобы добраться до нужного члена. Это оправданно лишь тогда, когда снижению потребления памяти придаётся большое значение.

Даже если выделить логическому значению полный байт, всё равно придётся понести значительные издержки производительности, поскольку члены утратят 32-разрядное выравнивание. По всем этим причинам при исследовании кода большинства компиляторов можно ожидать преимущественно 32-разрядно выровненные структуры данных.

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

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

Массивы обобщённых типов обычно представляют собой массивы указателей, целых чисел или любых других элементов размером в одно слово. Управлять ими очень просто, поскольку индекс всего лишь умножается на размер машинного слова. Для 32-разрядных процессоров это означает умножение на 4: обращаясь к массиву 32-разрядных слов, программа должна лишь умножить нужный индекс на 4 и прибавить результат к начальному адресу массива, чтобы получить адрес нужного элемента в памяти.

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

Этот фрагмент взят из середины цикла. Локальная переменная по адресу ebp - 0x20, по-видимому, служит счётчиком цикла. Это довольно очевидно: значение по адресу ebp - 0x20 загружается в EAX, который сдвигается влево на 4, что равносильно умножению на 16 (см. приложение B). Указатели редко умножают таким образом, зато с индексами массивов это происходит гораздо чаще. Обратите внимание: при исследовании в интерактивном отладчике назначение двух локальных переменных определить немного проще, поскольку можно просто посмотреть их значения.

После умножения ECX загружается значением по адресу ebp - 0x24, которое, по-видимому, является базовым указателем массива. Наконец, указатель складывается с умноженным индексом и числом 4. Это классическая последовательность для структуры данных в массиве. Первая переменная, ECX, служит базовым указателем массива. Вторая, EAX, содержит текущее байтовое смещение в массиве. Оно получено умножением текущего логического индекса на размер каждого элемента, поэтому теперь известно, что каждый элемент массива имеет длину 16 байт. Наконец, программа прибавляет 4, чтобы обратиться к конкретному члену структуры. В данном случае выбирается второй элемент структуры.

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

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

Односвязные списки - простые структуры данных, содержащие сочетание "полезной нагрузки" и указателя next, который ссылается на следующий элемент. Идея состоит в том, что положение каждого элемента в памяти никак не связано с логическим порядком элементов списка, поэтому при изменении порядка, добавлении или удалении элементов копировать память не требуется. На рисунке C.2 показано, как связанный список организован логически и в памяти.

Рисунок C.2. Логическая организация односвязного списка и его размещение в памяти.

Следующий код показывает обход связанного списка и обращение к его элементам в программе:

Этот фрагмент кода представляет распространённый цикл обхода связанного списка. В данном примере компилятор поместил указатель текущего элемента в ESI; в исходном коде он, должно быть, назывался pCurrentItem или как-то похоже. В начале программа загружает в переменную текущего элемента значение из ebp + 0x10. Это параметр, переданный текущей функции, и, вероятнее всего, указатель на голову списка.

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

В конце виден код, который обращается к члену next текущего элемента и заменяет им указатель текущего элемента. Заметьте, что смещение до следующего элемента равно 196. Это довольно большое число, указывающее на крупные элементы - вероятно, крупную структуру данных. После загрузки указателя next код проверяет его на NULL и прерывает цикл, если он равен NULL. Скорее всего, это цикл while, проверяющий значение pCurrentItem. Ниже приведён исходный код предыдущего фрагмента на языке ассемблера.

Обратите внимание: в исходном коде используется цикл while, хотя в версии на языке ассемблера явно применялись оператор if в начале, а затем цикл do...while(). Это типичный способ оптимизации цикла, упомянутый в приложении A.

Двусвязный список совпадает с односвязным за исключением того, что каждый элемент также содержит указатель previous, ссылающийся на предыдущий элемент списка. Благодаря этому очень легко удалить элемент из середины списка, что для односвязных списков далеко не тривиально. Ещё одно преимущество состоит в том, что при необходимости программа может обходить список назад, к его началу. На рисунке C.3 показано логическое размещение двусвязного списка и его размещение в памяти.

Рисунок C.3. Компоновка двусвязного списка логически и в памяти.

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

Сразу должно быть очевидно, что это возможность времени выполнения. Когда функция принимает указатель на базовый класс как входной параметр, вызывающая сторона может передать ей и потомка этого базового класса. Во время компиляции компилятор никак не может знать, какой конкретный потомок рассматриваемого класса будет передан функции. Поэтому он должен включить в объект информацию времени выполнения, которая определяет, какой именно метод вызывается при обращении к переопределённому методу базового класса.

Компиляторы реализуют механизм виртуальных функций с помощью таблицы виртуальных функций. Такие таблицы создаются во время компиляции для классов, объявляющих виртуальные функции, и для классов-потомков, предоставляющих переопределённые реализации виртуальных функций из других классов. Обычно эти таблицы помещаются в .rdata, раздел доступных только для чтения данных исполняемого образа. Таблица виртуальных функций содержит жёстко заданные указатели на все реализации виртуальных функций конкретного класса. По этим указателям находится нужная функция, когда кто-либо вызывает один из виртуальных методов.

Во время выполнения компилятор добавляет в начало объекта, обычно перед первым членом данных, новый указатель VFTABLE. При создании экземпляра объекта указатель VFTABLE инициализируется сгенерированным компилятором кодом так, чтобы ссылаться на правильную таблицу виртуальных функций. На рисунке C.6 показано размещение в памяти объектов с виртуальными функциями.

Рисунок C.6. Размещение в памяти объектов с таблицами виртуальных функций. Эта компоновка более или менее универсальна и используется всеми компиляторами.

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

Показательный элемент здесь - использование регистра ECX и тот факт, что CALL не применяет жёстко заданный адрес, а обращается к структуре данных, чтобы получить адрес функции. Обратите внимание: эта структура данных по существу совпадает со структурой, загруженной в ECX, хотя читается из отдельного регистра ESI. Это говорит о том, что указатель на функцию находится внутри экземпляра объекта, а это очень сильный признак того, что перед нами действительно вызов виртуальной функции.

Рассмотрим ещё один вызов виртуальной функции, на этот раз принимающей несколько параметров.

Здесь нет ничего принципиально нового. Последовательность идентична предыдущей, но перед вызовом в стек помещаются два параметра. Подведём итог: выявлять вызовы виртуальных функций часто очень легко, однако это зависит от реализации конкретного компилятора. В целом любая последовательность вызова функции, которая загружает допустимый указатель в ECX и косвенно вызывает функцию, адрес которой получен через тот же указатель, вероятно, является вызовом виртуальной функции-члена C++. Это справедливо для кода компиляторов Microsoft и Intel.

В коде других компиляторов, например G++, которые не используют ECX для передачи указателя this, распознавание может быть несколько сложнее, поскольку у вызова нет определённых признаков, позволяющих быстро установить его природу. В таких случаях того факта, что и указатель функции, и обрабатываемые ею данные находятся в одной структуре данных, должно быть достаточно, чтобы убедиться: перед нами класс. Разумеется, это верно не всегда, но если кто-то реализовал собственное частное понятие "класса" с помощью обобщённой структуры данных, содержащей члены данных и указатели на функции, такую конструкцию с тем же успехом можно считать классом - с низкоуровневой точки зрения это одно и то же.