13.3Хуки

Хуки ("крючья") - изящный, но ныне практически забытый прием программирования. Его суть заключается в совмещении нескольких разнотипных данных в одном аргументе. Например, если значение аргумента по модулю меньше 0x400000, функция считает его непосредственным значением, в противном случае - указателем на функцию, результат выполнения которой следует поставить на его место. Это увеличивает гибкость программы, но и затрудняет ее анализ, не позволяя быстро определить, происходит ли передача переменной по значению или по указателю. Указатели на переменную, в свою очередь, становятся неотличимы от указателей на функцию. Разумеется, отказ от строгой типизации может приводить к ошибкам, но вероятность их появления в тщательно продуманной программе невелика.

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

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

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

58. Противодействие анализу двоичного кода

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

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

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

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

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

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

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

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

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

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

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

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