Бесплатный фрагмент - Низкоуровневый анализ машинного кода

За каждым успешным кодером стоит еще более успешный декодер, который понимает этот код.

Аноним

Введение

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

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

У читателя предполагаются базовые знания в области программирования на assembler для 16,32,64 разрядных архитектур микропроцессоров и умение читать/разрабатывать код на C++/C#, python. Материалы книги доступны по постоянной ссылке https://yadi.sk/d/gWbKFT4lyIjZKg.

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

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

ЛЕКЦИИ

1 Роспатент, основные функции, регистрация программ для эвм

1.1 Правовая основа в России

УК РФ Статья 273. Создание, использование и распространение вредоносных компьютерных программ (в ред. Федерального закона от 07.12.2011 N 420-ФЗ) (см. текст в предыдущей редакции)

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

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

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

Статья 1299. Технические средства защиты авторских прав

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

2. В отношении произведений не допускается:

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

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

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

За указанные нарушения предусмотрена гражданско-правовая (ст. 1301 ГК РФ) и административная (ст. 7.12 КоАП РФ) ответственность. Отмечается, что закон (часть четвёртая ГК РФ) обладает невысоким техническим уровнем и допускает неоднозначные трактовки. В частности, в том же Гражданском Кодексе (ч. IV, ст. 1280, п. 1) сказано:

Лицо, правомерно владеющее экземпляром программы для ЭВМ или экземпляром базы данных (пользователь), вправе без разрешения автора или иного правообладателя и без выплаты дополнительного вознаграждения:

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

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

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

2 Защита ПО

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

— Одноразовый платеж. За ваше ПО платят раз, после чего могут пользоваться неограниченное время;

— Функциональные ограничения. Дополнительные возможности пользователь может открыть за дополнительную плату;

— Временная лицензия. Вы «сдаете приложение в аренду», то есть речь идет о подписке;

— Многоуровневая. Представляет собой комбинацию названных методов. Пользователь получает Silver-, Gold- или Platinum-версию ПО при соответствующей оплате.

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

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

2.1 Виды защиты

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

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

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

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

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

2.2 Удобство пользователя

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

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

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

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

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

3 Геометрия диска

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

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

— Числом цилиндров/

— Числом дорожек в цилиндре/

— Числом секторов на дорожке

C/H/S (от первых букв соответствующих английских терминов: Cylinder/Head/Sector, т. е. цилиндр/головка/сектор). Эти три цифры называют «геометрией диска». Диск с геометрией C/H/S имеет объем C*H*S*512 байт.

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

4 Технические средства защиты от копирования

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

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

Одновременный доступ к воспроизведению и запрет на копирование — чрезвычайно сложная задача:

— воспроизведение — чтение информации ее обработка и запись на устройство вывода,

— копирование — чтение и запись информации на устройство хранения.

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

4.1 Звук и музыкальные произведения

Audio-CD

Первые методы защиты музыкальных компакт-дисков от копирования использовали нарушения стандарта записи Audio CD, которые не были заметны для большинства CD-проигрывателей, но не работали на более сложно устроенных компьютерных приводах CD-ROM. Компания Philips отказалась ставить на таких дисках знак Compact Disc Digital Audio, который доказывал соответствие стандарту. К тому же оказалось, что такие диски не могли прочитать некоторые плееры, и, наоборот, некоторые компьютеры уверенно их копировали.

В 2005 году Sony BMG стала использовать новую технологию DRM для защиты своих аудио-CD от копирования при прослушивании на персональном компьютере. Диск можно было воспроизводить на компьютере только с помощью специальной программы, записанной на нём; также можно было создать 3 резервных копии альбома. Помимо этого, на компьютер пользователя устанавливалась программное обеспечение, предотвращающее перехват аудиопотока во время воспроизведения. Устанавливалось это ПО без подтверждения пользователя. Устанавливаемое ПО содержало в себе руткит: оно скрывало файлы и каталоги, использовало вводящие в заблуждение названия процессов и сервисов, и не имело возможности удаления. Это создавало серьёзные уязвимости в безопасности системы пользователя. Поскольку программа представляла угрозу безопасности компьютера, Sony была вынуждена отозвать миллионы компакт-дисков. Позднее была обнаружена троянская программа, использующая уязвимость в DRM компании Sony. В результате подобного использования DRM на Sony было подано несколько коллективных судебных исков, которые, в большинстве своём, были разрешены путём выплаты финансовой компенсации пострадавшим потребителям, а также раздачей музыкальных альбомов в цифровом виде без DRM. При всех этих проблемах DRM от Sony слабо осуществляло свою основную цель — защиту от копирования, так как влияло лишь на проигрывание на компьютерах под управлением систем Microsoft Windows, оставляя «за бортом» другие устройства. Да и Windows-систему легко можно было обойти, например, банально выключив функцию автозапуска, не говоря уже об упомянутой аналоговой бреши.

В январе 2007 года EMI прекратили выпуск аудио-CD с DRM, объявив о нецелесообразности затрат на систему. Sony, после всех судов и проблем, также отказались от DRM-защиты. На данный момент ни один из четырёх крупнейших лейблов не поддерживает DRM.

Музыка в интернет

Многие интернет-магазины США, продающие музыку онлайн, используют DRM. Один из крупнейших — Apple iTunes Store — использовал систему DRM FairPlay вплоть до 2009 года. Система использует обычные аудиофайлы формата MP4. Каждый файл содержит звуковой поток в формате AAC, зашифрованный с помощью AES с использованием основного ключа, а также сам основной ключ, зашифрованный с помощью ключа пользователя. Ключи пользователя генерируются случайно для каждого сеанса, их копии хранятся на серверах Apple и в защищенном репозитории iTunes (клиентской программы, используемой для доступа к iTunes Store). Один и тот же аккаунт iTunes Store можно использовать не более чем на пяти компьютерах. iTunes позволяет копировать аудиофайл на неограниченное количество плееров iPod (при этом ключи пользователя также копируются во внутренний репозиторий плеера), однако на одном iPod можно использовать музыку, полученную не более чем из пяти различных аккаунтов. Apple не выдавала лицензии на собственный DRM сторонним компаниям, в результате чего только устройства от Apple, а также их медиа-проигрыватель QuickTime могли воспроизводить музыку из iTunes. iTunes также позволяет записывать аудиофайлы на компакт-диски. Один и тот же плей-лист можно записать не более семи раз, однако каждый отдельный файл можно записывать неограниченное число раз. Полученные аудио-CD не содержат DRM, поэтому несложно получить аудиофайлы без защиты, сделав копию компакт-диска, однако при этом качество звука может уменьшиться при перекодировании. Программа Requiem позволяет извлекать ключи пользователей из хранилища iTunes, однако Apple регулярно выпускает обновления, меняя способы хранения ключей.

Однако 6 февраля 2007 г. глава Apple Стив Джобс опубликовал открытое письмо «Мысли о музыке», в котором призвал звукозаписывающие компании продавать музыку без DRM. С начала 2009 года музыка в iTunes Store по соглашению с большинством издателей постепенно стала полностью доступна без DRM.

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

Помимо стандартных подходов к DRM, некоторые магазины предлагают DRM-схему подписки. Например, сервис Sony Music Unlimited или онлайн музыкальный магазин Napster. Пользователи могут скачивать и прослушивать неограниченное количество музыки до тех пор, пока действует подписка. Однако с окончанием подписки все файлы перестают воспроизводиться.

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

Так, в 2006 году Эндрю Гауэрс составил список предложений по улучшению политики защиты авторских прав Gowers Review of Intellectual Property, которая содержит 54 пункта. Этот список находится в открытом доступе, и ознакомиться с ним может любой желающий. Среди всех прочих поправок пункты с 8 по 12 содержат предложения по созданию некоторых исключений для добросовестного использования авторских прав, например, библиотеками, также рассматривается возможность перехода от одной схемы DRM к другой. Впоследствии планировалось ввести подобные исключения и для обычных пользователей. Вообще проблема с различными DRM в проигрывателях стояла достаточно остро, например, Apple отказались от DRM-защиты в музыке полностью, благодаря чему музыка из iTunes проигрывается спокойно на любом устройстве, поддерживающем формат AAC. Некоторые магазины, например, немецкий Musicload, также объявили об отказе от DRM, так как выяснилось, что 3 из 4 звонков в их службу поддержки поступало от недовольных системой DRM пользователей.

Рингтоны для мобильных телефонов

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

4.2 Изображения, фильмы и телевиденье

Content Scramble System

Первой технологией защиты DVD от копирования являлась Content Scramble System (CSS). Эта технология использовалась с 1996 года. Каждый производитель лицензировал свой ключ DVD-проигрывателя для использования в своих устройствах у DVD Copy Control Association — организации, основанной DVD Forum. Каждый DVD, защищенный CSS, содержал ключ диска, который расшифровывался с помощью ключа данного DVD-проигрывателя, после чего можно было расшифровать всю остальную информацию на диске. Ключи записывались в lead-in области диска, чтобы сделать невозможным их непосредственное копирование. В 1999 году Джон Лех Йохансен, также известный как DVD Jon, опубликовал программу DeCSS, позволявшую расшифровывать и воспроизводить DVD-диски, защищенные CSS, в операционной системе Linux, для которой ключи проигрывателей не были лицензированы. Он использовал ключи, переданные анонимным хакером, который извлек их из программы XingDVD, хранившей ключи в открытом виде. Позже была найдена уязвимость, которая позволяла взломать защиту методом полного перебора на любом компьютере, мощность которого достаточна для воспроизведения DVD. В этом же году на системах Microsoft Windows появилась своя схема DRM, которая считывала инструкции из мультимедийных файлов на языке управления правами, в которых описывались разрешённые пользователю действия. Язык может определять, сколько раз можно проигрывать файл, можно ли записать его на внешний носитель, распечатать, переслать по интернету или скопировать на жёсткий диск.

Regional Protection Code

Regional Protection Code или региональная защита DVD является средством DRM, позволяющим регулировать продажу DVD, HD DVD и Blu-Ray дисков в различных странах мира. Система призвана решить проблему распространения дисков в странах, где премьера фильма ещё не закончилась и он ещё не вышел на DVD. Однако данная технология позволяет также устанавливать разные цены для розничной продажи дисков в разных странах, что противоречит правилам свободной торговли. Подобный подход позволяет продавать продукцию с DRM-защитой в развивающихся странах, а также странах третьего мира по более низким ценам. Однако в Австралии и Новой Зеландии запрещена продажа DVD-проигрывателей, ограничивающих воспроизведение дисков в каких-либо регионах из-за противоречий, указанных выше.

Advanced Access Content System

Advanced Access Content System (AACS) или же улучшенная система доступа к содержимому — это система DRM, используемая для защиты HD DVD и Blu-ray дисков, опубликованная в апреле 2005 г. и окончательно принятая 5 июня 2009 года консорциумом AACS Licensing Administrator, включающим Disney, Intel, Microsoft, Panasonic, Warner Bros., IBM, Toshiba и Sony. Система сочетает в себе различные методы, предотвращающие незаконное копирование и распространение видеоматериалов.

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

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

Признак ограничения изображения позволяет ограничить максимальное разрешение для аналоговых выходов до 960×540. Полное разрешение 1920×1080 возможно только для выходов HDMI или DVI, которые поддерживают HDCP.

Функция контролируемого копирования, недавно включенная в стандарт AACS, позволяет создавать резервные копии на Blu-ray и DVD-дисках, в виде файлов, совместимых с DRM компании Microsoft, а также делать копии более низкого качества для портативных видеоплееров. Технология доступна только в сравнительно новых видеопроигрывателях и требует подключения к Интернет для учёта количества копий данного диска.

В настоящее время AACS взломана не полностью. В декабре 2006 года хакеры опубликовали в Интернете ключи к защищённому с помощью AACS содержимому HD DVD. После того, как были аннулированы взломанные ключи, постоянно публиковались новые. 16 апреля 2007 ключи плееров WinDVD и PowerDVD были отозваны, поскольку они ранее были опубликованы в Интернете, а соответствующие программы обновлены, однако вскоре в Сети появились новые, до сих пор действующие ключи. Также был произведен аппаратный взлом привода HD DVD, используемого с Xbox 360, для частичного обхода защиты, позволяющего осуществить взлом без использования ключей устройств.

Предотвращение перехвата аудио- и видеопотока.

Интерфейсы DVI и HDMI поддерживают технологию High-bandwidth Digital Content Protection (HDCP) — защита широкополосного цифрового содержимого, которая использует шифрование при передаче сигнала между видеопроигрывателем и монитором/телевизором для предотвращения перехвата видеопотока (например man-in-the-middle), а также позволяет осуществлять вывод только на сертифицированные устройства. Однако оказалось, что эта технология обладает низкой криптостойкостью и может быть взломана.

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

Телевизионные программы

Для защиты телепрограмм, передаваемых по телевидению высокой чёткости, предусматривается наличие флага передачи, позволяющего определить, разрешена ли запись. Эта концепция была разработана компанией Fox Broadcasting в 2001 году и была поддержана MPAA и Федеральным Агентством по связи (ФАС) США. Однако в мае 2005 года Апелляционный Суд США постановил, что ФАС не обладает достаточной властью для наложения подобных ограничений на телеиндустрию в США.

Куда большего успеха эта система добилась, когда была принята Проектом Цифрового Видео Вещания — консорциумом, включающим более 250 вещателей, производителей, операторов сети, разработчиков программного обеспечения и управляющих органов в более чем 35 странах. Этот консорциум пытался разработать новые цифровые стандарты для DRM в телевещании. Одним из наиболее перспективных стандартов является вариант с улучшенным флагом передачи, разработанный для европейского телевидения DVB-Content Protection and Copy Management (DVB-CPCM). Этот стандарт был предоставлен на рассмотрение европейским правительствам в 2007 году. Все нормативные части на данный момент уже одобрены для публикации Руководящим Советом DVB и будут опубликованы ETSI как официальный европейский стандарт ETSI TS 102 825-X (X — номер подразделения). На сегодняшний день ещё никто не взял на себя обеспечения Совместимости и Надёжности для данного стандарта, однако разработки в данном направлении ведутся многими компаниями, что не позволяет сегодня внедрить эту систему повсеместно.

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

4.3 Текст, документы и электронные книги

Управление цифровыми правами на предприятии — это применение технологий DRM для управления доступом к корпоративным документам (файлы Microsoft Word, PDF, AutoCAD, электронные письма, страницы внутренней сети интранет). Эти технологии, более известные как Управление Информационными Правами, в основном используются для предотвращения несанкционированного использования документов, являющихся интеллектуальной собственностью предприятия, например, в целях промышленного шпионажа или случайной утечки информации. Обычно эта система встроена в программное обеспечение системы управления содержимым, однако некоторые корпорации такие как Samsung Electronics разрабатывают свои собственные системы DRM.

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

На сегодняшний день в мире наибольшее распространение получили пять основных форматов электронных книг: Mobipocket, KF8, Topaz, ePub и PDF. Также существует четыре основных DRM-схемы для электронных книг, по одной от Amazon, Adobe, Apple и Martin Trust Management Organization (MTMO):

— DRM от Amazon является адаптацией изначальной кодировки Mobipocket, и используется в электронных книгах от Amazon, которые поддерживаются программой Amazon Kindle, форматы Mobipocket, KF8 и Topaz.

— DRM Adept от корпорации Adobe применяется к ePub и PDF, причём читать книги могут различные программы от сторонних разработчиков, а не только программное обеспечение от Adobe. Формат Adobe PDF поддерживает различные методы защиты содержимого: Полное криптостойкое шифрование документа, требующее ввод пароля для любых операций с документом, включая открытие и просмотр; защита документа, определяющая, возможно ли копирование, извлечение текста, печать или изменение документа. Хотя стандарт ISO требует, чтобы все программы просмотра PDF следовали установленным ограничениям, например, Okular имеет опцию, которая позволяет игнорировать ограничения в просматриваемых файлах; Adobe DRM — технология защиты, используемая в Adobe Reader версии 6.0 и выше. Используется в различных книжных интернет-магазинах, поддерживает привязку возможности просмотра к компьютеру пользователя или другому устройству (например, КПК или электронной книге), позволяет ограниченное количество раз копировать документ с одного устройства на другое авторизованное в Adobe Content Server, позволяет запретить извлечение текста и печать документа, а также ограничить срок, в течение которого возможен доступ к документу.

— DRM FairPlay от Apple Inc. Она применяется к формату ePub, причём прочитать такие файлы могут только устройства Apple с помощью приложения iBook.

— DRM Marlin была создана и поддерживается в открытой отраслевой группе Marlin Developer Community (MDC), основанной компаниями Intertrust, Panasonic, Philips, Samsung и Sony. Эта схема лицензирована MTMO.

Популярный в России открытый формат электронных книг FictionBook не поддерживает DRM.

4.4 Видео игры

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

Игровые приставки, такие, как Xbox 360, Xbox One, PlayStation 3 и Playstation 4, также содержат систему проверки диска на лицензионность.

Активация для ограничения количества установок

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

Примерно с середины 2008 года выпуск игры Mass Effect запустил целую волну продуктов, использующих DRM-схему SecuROM, которая требует онлайн-аутентификации на серверах издателя. В этом же году использование подобной защиты в игре Spore от Electronic Arts привело к тому, что большинство пользователей предпочло использование пиратской версии игры. Однако независимые исследователи с TweakGuides пришли к выводу, что подобное использование DRM не влияет на количество пиратских копий игры, отметив, что другие игры вроде Call of Duty 4: Modern Warfare, Assassin’s Creed и Crysis, использующие схему SafeDisc, не прибегающую к онлайн-аутентификации, также распространялись в сравнимых со Spore количествах среди пиратов. К тому же игры, использующие онлайн-аутентификацию так же, как и Spore — BioShock, Crysis и тот же Mass Effect, в списках самых скачиваемых игр на различных торрент-трекерах не значатся.

Постоянная онлайн-аутентификация

Многие издатели, среди которых, например, Electronic Arts, Ubisoft, Valve и Atari, использовали онлайн DRM-схемы вплоть до начала 2009 года. В конце 2008 года компания Ubisoft провела эксперимент, выпустив серию игр Prince of Persia без DRM-защиты на вебсайте GOG.com, с целью проверить, насколько правдиво общественное мнение в отношении того, что DRM только усугубляет пиратство и провоцирует людей использовать не лицензионные копии. Хоть сама компания так и не объявила результаты эксперимента, независимые эксперты с Tweakguides заметили, что всего лишь с двух торрентов на Mininova игру скачало более 23 тысяч людей в течение 24 часов после релиза.

Ubisoft официально объявили о возвращении онлайн-аутентификации 9 февраля 2010 года. Они представили свою новую онлайн игровую платформу Uplay, которую начали использовать в таких играх, как Silent Hunter 5, The Settlers 7 и Assassin’s Creed II. Silent Hunter 5 взломали в течение 24 часов с момента релиза. Однако, пользователи пиратской версии могли играть только в начальные уровни игры. Система Uplay работает таким образом, что на пользовательский ПК игра устанавливается не полностью, а докачивает содержимое с игровых серверов Ubisoft по мере прохождения игры. Чуть более, чем через месяц после релиза на ПК, в первую неделю апреля, было выпущено ПО, с помощью которого можно было обойти DRM-защиту в Assassin’s Creed II. ПО являло собой эмулятор сервера Ubisoft для игры. Чуть позже, в этом же месяце, была выпущена версия, которая убирала необходимость в соединении с серверами полностью.

В начале марта 2010 года сервера Ubisoft подверглись масштабной DDoS-атаке, что привело к закрытию доступа к играм для ~5% игроков. В качестве компенсации за принесённые неудобства, компания предоставила пострадавшим пользователям по бесплатной скачиваемой игре. С марта 2010 года сервера Ubisoft больше не падали.

Примеру Ubisoft последовали и другие разработчики, такие, как Blizzard Entertainment. Они также перешли на вариант защиты, когда большая часть игровой логики находится «на стороне», или обрабатывается серверами создателя игры. Blizzard использует подобный подход в своей игре Diablo III. Electronic Arts использовали такой подход в своей перезагрузке сериала SimCity. Надо сказать, что подобный подход отрицательно повлиял на обе компании, ибо они просто не смогли справиться с количеством игроков на серверах, что привело к многочисленным жалобам и растущему недовольству пользователей. Electronic Arts пытается убрать необходимость постоянного подключения к серверам, но пока это не представляется возможным, ибо вся игра была создана с учётом этого.

Вмешательство в ПО

Некоторые студии в качестве защиты используют не совсем стандартные подходы. Bohemia Interactive использует DRM-схему, которая при запуске нелегальной копии игры просто мешает играть, начиная с 2001 года, с выходом Operation Flashpoint: Cold War Crisis. Игра начинает создавать ситуации, в которых у игроков снижается точность оружия, или, например, сами игроки превращаются в птиц. Компания Croteam в своей игре Serious Sam 3: BFE использовала похожий подход, натравливая на игроков, использующих нелегальные копии игры, монстра, которого невозможно было убить.

5 Общий анализ средств защиты ПО от копирования

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

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

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

Недорогой софт, выпускаемый в промышленных масштабах (особенно компьютерные игры), проще всего защищать, привязывая к носителю (CD- или DVD-дискам). Там используются, по сути, те же методы, которыми раньше защищали дискеты: нестандартное форматирование, сбойные секторы на диске, специально закодированный таким образом ключ. В качестве дополнительной меры защиты в системе может устанавливаться специальный защищенный драйвер, призванный бороться с различными эмуляторами. Этот метод защиты сравнительно дешев и подходит для широко тиражируемых продуктов. К ограничениям можно отнести не самую высокую степень защиты и неудобство, вызванное привязкой к физическому носителю. Самые известные системы защиты по такой технологии: SecuROM, StarForce, SafeDisk, Tages.

5.1 Электронные ключи

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

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

5.2 Интернет-активация

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

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

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

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

5.3 Обфускация кода

Несмотря на то что ассемблер современных процессоров не так прост для понимания, как высокоуровневый С-код, опытный взломщик с большой долей вероятности сможет при наличии времени и сил воспроизвести любые алгоритмы в приложении, включая и те, что обеспечивают защиту от копирования. И если где-то существует заблуждение, что сама по себе компиляция в машинный код — это уже хорошая защита, то в современном мире это не так, не говоря уже о том, что множество технологий не предусматривает компиляции в машинный код, а анализировать байт-код или промежуточное представление куда легче (например,.NET, Java или ActionScript).

Здесь на помощь приходят технологии обфускации (запутывания) кода. Обфускация может выполняться на разных уровнях в зависимости от языка. Для Web-технологий (например, клиентского JavaScript) есть возможность только запутывания исходного кода. Если речь о языке с компиляцией в некий промежуточный код (например, у Java или. NET), то обфусцируется этот код. Но на сегодняшний день в большинстве своем коммерческий софт пишется на классических языках (например, С) и компилируется в машинный код, в связи с чем встает задача обфускации машинного кода.

5.4 Псевдокод и полиморфные технологии

Любая обфускация на уровне машинного кода уменьшает скорость выполнения программы. Ведь в лучшем случае для запутывания кода приходится добавлять туда ненужные инструкции (не влияющие, впрочем, на результат). А для более продвинутой защиты используется технология так называемого псевдокода. Так для обычного x86-процессора разрабатывается некий псевдоязык, оперирующий совершенно другими командами и логическими конструкциями, после чего исходный код защищенного приложения инструкция за инструкцией преобразуется в псевдокод. Для выполнения этого псевдокода генерируется «виртуальная машина», которая на лету преобразовывает команды псевдокода в машинные инструкции и исполняет их. Результат остается тот же, но код приложения меняется до неузнаваемости, и «отреверсить» искомые алгоритмы защищенного приложения можно лишь после вскрытия всей логики псевдокода.

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

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

5.5 Перспективы

За последние 30 лет появлялись и погибали различные технологии. И сейчас многим кажется, что с развитием Интернета и цифровой дистрибуции право на существование имеет только онлайн-активация для защиты от копирования и обфускация кода для защиты от реверсинга. Однако есть и противоположная тенденция — развитие рынка SaaS и переход приложений в «облако». Если считать эту тенденцию потенциальным победителем, то защита вообще никому не нужна, ведь приложение не распространяется. Для «облаков» важна аутентификация, безопасность передачи данных и доступность сети.

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

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

6 Исследование дизассемблирования и обфускации

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

Дизассемблирование — это процесс и/или способ получения исходного кода программы на ассемблере из программы в машинных кодах.

Ha сегодняшний день известно множество хороших дизассемблеров, таких как:

— IDA Pro,

— Periscope,

— Bubble

— Chamber,

— Sourcer,

И тому подобные.

Самой простой для освоения является IDA Pro (Interactive DisAssembler Pro),

В полученных с помощью программы ASM файлах менялось что необходимо, и затем из них снова собирали работающую программу. Наиболее умелые программисты часто из полученных исходных файлов пытаются собрать программы для языков высокого уровня, будь то С, Fortran или даже Basic и Pascal. Этот процесс называется декомпиляцией, из-за сложности этого процесса автоматические реализации встречаются крайне редко. Декомпилируют файлы обычно вручную, при этом ищут конец и начало функций. Например, встретив строки «push ebp; mov ebp, esp» можно утверждать, что это начало функции, а «pop ebp; retn» — ее конец. Такие продвинутые дизассемблеры как IDA уже выделяют все функции, и задача ставится только понять, что они делают.

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

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

— У Borland-овских языков (Turbo Assembler (TASM), Borland’s C++) — это серия TD (Turbo Debugger). TD — для DOS-овских программ, TDW — для программ под windows. Однако TDW не распознает программу с заголовком PE/NE 32bit. В этом случае стоит пользоваться TD32.

— У продуктов Microsoft (MicroSoft Assembler, MASM) можно найти отладчик CodeView (CV, CVW) и относительно недавно появился пакет утилит NuMega фирмы Compuware. Отладчик NuMega SoftIce позволяет отладить даже ядро системы, а также с легкостью просматривать все процессы и окна. Часто он входит в комплект BoundsChecker.

Для некоторого упрощения процесса можно пользоваться breakpint-ами, поставив breakpoint на выходе из цикла и запустив программу, передаст управлению отладчику перед выполнением инструкции, помеченной breakpoint-ом. Чаще всего breakpoint-ы представляют собой прерывания, которые заменяют помеченные инструкции. Однако не стоит терять бдительность, поскольку программа может заменила инструкцию, на которой стоит breakpoint, и в итоге так и не остановиться выполняясь до конца. Теперь можно сохранить полученный файл как EXE-шник. При этом стоит учитывать новую точку входа и позаботиться о том, чтобы значение регистров сохранилось. Заголовок можно посмотреть с помощью утилиты HIEW (Hacker’s View) by SEN. Если программа DOS-овская — заголовок должет быть MZ, если для Windows, то чаще всего PE.

Теперь рассмотрим некоторые способы защиты программ от дизассемблирования. Первое, что приходит на ум — это зашифровать ее. Можно пользоваться различными методами криптографии, но в итоге понять, что распаковщик слишком прост. Также можно не только зашифровать, но и запаковать информацию. Для этих целей лучше всего подходят модификации алгоритма LZW. Они используются во многих архиваторах (RAR, ZIP), в графических файлах GIF, даже в PDF, им часто запаковываются EXE-шники (PKLITE). Это была основа, далее необходимо задуматься о более серьезной защите.

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

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

Label1: mov ax,1ab8h

mov bx,06bbh

mov cx,00b9h

mov dx,01bah

mov si,0ffbeh

mov di,32bfh

jmp Label1+1

Результатом его работы будет:

bx = 0x0b906;

cx = 0x0ba00;

dx = 0x0be01;

si = 0x0bfff;

di = 0x0eb32.

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

push cs

pop ds

mov ch,0ebh

mov esi, offset $ или Label2: mov esi, offset Label2

add byte ptr [esi+07],08

sub byte ptr [esi+10],5

db Rel

Этот фрагмент выполняет относительный переход на Rel байтов (равносильно Jmp short ptr Rel). Защищать программы от трассирования это необходимость. Поскольку трассирование гораздо дольше обычного выполнения программы. Это и можно использовать против злоумышленника. Ниже приведен фрагмент, вызывающий функцию DOS «GetTime»:

mov ah,2ch; Get Time

int 21h; call DOS services

push dx; dh — seconds, dl — hundredths of a second (0—99)

mov ah,2ch; Get Time

int 21h; call DOS services

pop ax; ah — seconds

cmp dh, ah

jz continue;

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

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

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

fragment 1

xor ecx, ecx

xor edx, edx

mov ah,01

int 1ah

;установить счетчик тиков на 0

;каждую секунду происходит примерно 18.2 тика

;поэтому предположим, что 2 тика уже слишком много

;fragment 2

xor eax, eax; здесь можно использовать ax, bx, cx,

;но для 32х разрядной машины 32х разрядные регистры занимают меньше памяти

int 1ah; взять число тиков

mov ax, cx

shl eax,16

mov ax, dx; конвертируем 32-битное число CX: DX в EAX

and al, -1;Один тик — не страшно, очистим первый бит

mov edx, eax

mov ecx,31

Label3: shr edx,1

or eax, edx

loop Label3

and eax,2

shl eax,1

add ebx, eax; допустим, в ebx нами был рассчитан какой-то адрес

call [ebx+xxx]; ebx+xxx — по этому адресу — нормальная процедура

;ebx+xxx+4 — а по этому адресу происходит перехват трассировщиков

7 Исследование защиты ПО физическим ключом

Наиболее распространенным и надежным способом защиты дорогостоящего программного обеспечения от несанкционированного запуска стали программно-аппаратные ключи, подключаемые к COM-, LPT- или USB-портам.

Почти все коробочные варианты серьезного коммерческого ПО используют программно-аппаратные комплексы защиты, более известные как аппаратные ключи защиты или же ключ-флэшка (рисунок 3).

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

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

При попытке запустить программы без установленного драйвера видим следующее (рисунок 5):

Соответственно теперь необходимо приступить к установке драйвера (рисунки 6—7):

Далее подтверждаем согласие с установкой и ждем ее окончания.

По завершению установки пробуем запустить ПО без физического ключа и видим следующее (рисунок 8):

После этого пробуем запустить программы со вставленным в ПК ключом и как и ожидалось программа запускается без запинок (рисунок 9).

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

Что характерно в системе ключ-флэшка отображается не как хранилище информации, а как отдельное устройство.

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

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

Перехват и эмуляция

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

NTSTATUS HookDevice (LPWSTR lpDevice)

UNICODE_STRING DeviceName;

PDEVICE_OBJECT DeviceObject;

PFILE_OBJECT FileObject;

RtlInitUnicodeString (&DeviceName, lpDevice);

IoGetDeviceObjectPointer (&DeviceName,1u,&FileObject, &DeviceObject);

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

NTSTATUS HookDevice (LPWSTR lpDevice)

gDriverObject=DeviceObject-> DriverObject;

gDeviceControl=gDriverObject-> MajorFunction

[IRP_MJ_DEVICE_CONTROL];

gDriverObject-> MajorFunction

[IRP_MJ_DEVICE_CONTROL]

=HookDispatch;

gInternalDeviceControl=gDriverObject-> MajorFunction

[IRP_MJ_INTERNAL_DEVICE

_CONTROL];

gDriverObject-> MajorFunction

[IRP_MJ_INTERNAL_DEVICE

_CONTROL] =HookDispatch;

gDriverUnload=gDriverObject-> DriverUnload;

gDriverObject-> DriverUnload=HookUnload;

ObfDereferenceObject (FileObject);

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

Так как указатель на объект драйвера защиты сохранен, то чтобы снять ловушку, нужно просто восстановить прежние обработчики IRP-пакетов:

void UnhookDevice (void)

gDriverObject-> MajorFunction [IRP_MJ_DEVICE_CONTROL]

=gDeviceControl;

gDriverObject-> MajorFunction [IRP_MJ_INTERNAL_DEVICE

_CONTROL] =gInternalDeviceControl;

gDriverObject-> DriverUnload = gDriverUnload;

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

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

void HookUnload (PDRIVER_OBJECT DrvObj)

UnhookDevice ();

gDriverUnload (DrvObj);

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

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

Перехватчик

Теперь можно приступить к реализации перехватчика для дальнейшего анализа. Для этого создадим объект драйвера, который содержит символьное имя (например DosDevicesHook) и точки входа CREATE, CLOSE, READ.

IoCreateDevice (DriverObject,0,&usDeviceName, FILE_DEVICE_NULL,0,

0,&pDeviceObject);

IoCreateSymbolicLink (&usSymbolicDeviceName, &usDeviceName);

DriverObject-> MajorFunction [IRP_MJ_CREATE] = DriverDispatch;

DriverObject-> MajorFunction [IRP_MJ_CLOSE] = DriverDispatch;

DriverObject-> MajorFunction [IRP_MJ_READ] = DriverDispatch;

DriverObject-> DriverUnload = DriverUnload;

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

Код HookDispatch:

if (idlTail->IrpData.InputLength)

{

idlTail-> InputBuffer=ExAllocatePool (NonPagedPool, idlTail-

IrpData.InputLength);

RtlCopyMemory(idlTail->InputBuffer,Irp-AssociatedIrp.SystemBuffer,

idlTail->IrpData.InputLength);

}

if (IoSL-> MajorFunction == IRP_MJ_DEVICE_CONTROL)

Status=pHookedDriverDispatch [IRP_MJ_DEVICE_CONTROL]

(DeviceObject, Irp);

if (idlTail-> IrpData. OutputLength)

{

idlTail-> OutputBuffer=ExAllocatePool (NonPagedPool, idlTail->

IrpData. OutputLength);

RtlCopyMemory (idlTail-> OutputBuffer, lpBuffer,

idlTail-> IrpData. OutputLength);

}

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

Код DriverDispatch:

Length = IoSL->Parameters.Read. Length;

if (Length == sizeof (IRP_DATA) && idlHead)

RtlCopyMemory (Irp-> UserBuffer, &idlHead-> IrpData, Length);

else if (idlHead && Length == (idlHead-> IrpData.InputLength + idlHead->

IrpData. OutputLength))

{

RtlCopyMemory (Irp-> UserBuffer, idlHead-> InputBuffer, idlHead->

IrpData.InputLength);

RtlCopyMemory ((PVOID) ((ULONG) Irp-> UserBuffer+idlHead->

IrpData.InputLength),idlHead->

OutputBuffer, idlHead->

IrpData. OutputLength);

}

else if (Length == 1 && idlHead)

{

if (idlHead-> InputBuffer)

ExFreePool (idlHead-> InputBuffer);

if (idlHead-> OutputBuffer)

ExFreePool (idlHead-> OutputBuffer);

idlTemp = idlHead-> ldlNext;

ExFreePool (idlHead);

idlHead = idlTemp;

if (!idlTemp)

idlTail = NULL;

}

Когда перехватчик готов, запускаем сначала его, а затем — защищенное приложение с ключами и без. Из полученных логов становится видно, какие управляющие коды посылаются и их результаты. Также можно видеть, что запросы и ответы на два различных кода (9c402450, 9c4024a0) не изменяются. Казалось бы, можно построить табличный эмулятор, но после серии запусков убеждаемся, что это невозможно, так как содержимое буферов различно, и неизвестно, как оно образуется.

Затем возможны несколько вариантов дальнейших действий:

— Изучать дебри драйвера защиты;

— Воспользоваться информацией самих разработчиков системы.

Оба варианта дают необходимую информацию. Таким образом, оказывается, что содержимое пакетов шифруется публичным симметричным алгоритмом AES (Advanced Encryption Standard). Логичной целью является получение ключа шифрования.

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

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

unsigned short Key;

unsigned char RefKey [8], VerKey [8];

for (Key = 0; Key <= 0x7fff, Key++)

{

if (!HL_LOGIN (Key, 1, RefKey, VerKey))

{

HL_LOGOUT ();

Break;

}

}

return Key;

Далее ключ (MODAD) используется для снятия дампа: тип, идентификатор, порт подключения и так далее. Для этого есть функции, определенные разработчиками.

Функции HL_LOGIN, HL_LOGOUT доступны из HASP SDK для разработчиков приложений, защищенных на этой платформе, и имеют следующие прототипы:

WORD HL_LOGIN (WORD ModAd, Word Access, Byte *RefKey,

Byt *VerKey);

WORD HL_LOGOUT (void);

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

Новый API мало отличается от старого, и это никак не сказывается на принципе работы перебора.

Обработчик

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

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

Принципиально логика перехватчика будет иметь такой вид:

NTSTATUS HookDispatch ():

PIO_STACK_LOCATION Stack=Irp-> Tail.Overlay.CurrentStackLocation;

ULONG IoControlCode;

if (Stack-> MajorFunction == 14)

{

IoControlCode = Stack.DeviceIoControl.IoControlCode;

If (IoControlCode!= 0x9c402458)

{

Return gDeviceControl (DeviceObject, Irp);

}

else

{

Encrypt(Irp->AssociatedIrp.SystemBuffer);

Crypt(Irp->AssociatedIrp.SystemBuffer, Key, DumpMemory);

}

}

Return STATUS_FAILED;

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

Код Encrypt ():

void Encrypt (BYTE * Buffer)

{

WORD Seed = ((WORD) Buffer +0x5e);

WORD Ver = ((WORD) Buffer +0xba);

if (Ver)

{

for (int i = 0; i <0xB9; i++)

{

(WORD) (Buffer + i) += Seed;

Seed = (Seed>> 15) | (Seed <<1);

Seed -= (WORD) (Buffer + i) ^ i;

}

for (int i = 0xBE; i <0xFF; i++)

{

(WORD) (Buffer + i) -= Seed;

Seed = (Seed>> 15) | (Seed <<1);

Seed += (WORD) (Buffer + i) ^ i;

}

((WORD) Buffer +0xba) = Seed;

}

}

Видно, что алгоритм гораздо сложнее, чем обычный сдвиг и исключающее «или». Далее следует алгоритм дешифрования:

Код Decrypt ():

void Decrypt (BYTE* Buffer)

{

WORD Seed = ((WORD) Buffer +0x5e);

WORD Ver = ((WORD) Buffer +0xba);

if (Ver)

{

for (int i = 0xFE; i> 0xBD; i — )

{

Seed -= (WORD) (Buffer + i) ^ i;

Seed = (Seed <<15) | (Seed>> 1);

(WORD) (Buffer + i) += Seed;

}

for (int i = 0xB8; i> = 0; i — )

{

Seed += (WORD) (Buffer + i) ^ i;

Seed = (Seed <<15) | (Seed>> 1);

(WORD) (Buffer + i) -= Seed;

}

((WORD) Buffer +0xba) = Seed;

}

}

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

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

8 ОБРАТНАЯ РАЗРАБОТКА ПО

Reverse engineering

8.1 Основные задачи:

— Установить логику программы с закрытым исходным кодом.

— Воссоздать программу, аналогичную проприетарной.

— Избавить проприетарную программу от ненужного функционала (проверка производителя/лицензии).

8.2 Что такое программа?

— Исполняемый файл популярных ОС и архитектур.

— Байткод виртуальной машины (Java/.NET).

— Интерпретируемый код (PHP/Python/Perl).

8.3 Исполняемый файл

Это, собственно, набор инструкций процессора, смешанный с данными, необходимыми для работы программы. На разных ОС приняты разные форматы исполняемых файлов: для Windows это PE (Portable Executable), для Linux ELF (Executable and Linkable Format). Расширения файлов. exe и <ничего> для Windows и Linux соответственно.

Важно помнить, что разделяемые библиотеки (.dll/.so) имеют схожий формат, хотя их обратная разработка затруднена не столь простой отладкой.

8.4 Структура исполняемого файла

Исполняемый файл состоит из сегментов, секций и всего такого. Вкратце они позволяют понять, где код, где данные, где константы и все такое.

В Linux это всё можно посмотреть командой readelf, в Windows –это не очень нужно.

IDA (о ней далее) покрасит все секции разными цветами сам.

8.5 Как понять что происходит?

8.6 Interactive DisAssembler (IDA):

— Стоит всего лишь от $1200. И это без декомпиляторов.

— Умеет, тем не менее, дизассемблировать почти всё.

— Стандарт индустрии.

— Обладает декомпилятором HexRays.

— Его автор параноик и думает, все его покупатели — пираты.

— А они и правда пираты… ну или неудачники. В интернете доступна версия 6.8, которую украли у HackingTeam.

8.7 Hexrays

8.8 Что же теперь делать?

— Заходите в подозрительную функцию (обычно это main).

— Жмете F5.

— Готово, теперь вы можете читать «код».

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

8.9 Как, тем не менее, понять что происходит?

— Просто прочитать. Это же легко, правда?

— Загуглить встреченные константы.

— Загуглить названия функций. Макрос assert () выдает имена оригинальных файлов, их можно гуглить.

— Отладить подряд.

8.10 Отладчик

— Позволяет выполнять программу пошагово, смотреть регистры, инструкции и всё такое. Только ассемблер.

— Под Windows самыми известными являются OllyDbg и x64dbg (слышали о Denuvo? Его официальный «спонсор»).

— GNU Debugger (gdb). Вообще не только для Linux, но в винде не очень хорош. А вообще крут, еще и плагины есть (PEDA).

— IDA. Ходят слухи, она умеет отлаживать даже линукс через удаленный gdb, но это неточно. Под Windows отладчик даже и неплох.

ЛАБОРАТОРНЫЕ РАБОТЫ

ЛАБОРАТОРНАЯ РАБОТА №0

Тема: Дисассемблеры и отладчики

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

1) Используя отладчик AFD или TD пройти по программе, найти место, где происходит дешифровка пароля и расшифровать его, после чего снова запустить программу, ввести правильный пароль и получить подтверждение о правильности прохода через пароль.

2) Используя дизассемблер SOUSER

— дизассемблировать выданную программу

— автоматически построить блок схему алгоритма ее работы

— найти в тексте программы место проверки пароля и подавить проверку

— заново ассемблировать программу и представить ее преподавателю, продемонстрировав, что программа теперь не запрашивает пароль (или успешно завершается при любом пароле).

3) Оформить электронный отчет, в котором отразить:

— титульный лист;

— тему лабораторной работы и задание на лабораторную работу;

— описание этапов дешифровки пароля и экранные формы отладчика, использованные при дешифровке пароля;

— описание этапов дизассемблирования программы и экранные формы дизассемблера, использованные при этом, в отчет включить УЧАСТОК дизассемблированной программы, в котором происходит дешифровка и обработка пароля;

— описание этапов автоматического построения блок-схемы алгоритма программы, в отчет включить УЧАСТОК блок-схемы алгоритма, в котором происходит дешифровка и обработка пароля;

— описание приемов, примененных для подавления обработки пароля, в отчет включить УЧАСТОК дизассемблированной программы измененный Вами с целью подавления обработки пароля;

— описание порядка ассемблирования программы;

— вид экрана после срабатывания откорректированной программы.

Пример выполнения ЛАБОРАТОРНОЙ РАБОТЫ №0

Реверс программы OOO_07.COM

Введение

Цель работы: произвести обратную разработку программы OOO_07.COM.

Для выполнения цели поставлен ряд задач:

— Разобраться в структуре программы OOO_07.COM;

— Найти правильный пароль;

— Сделать вывод по результатам проведенной работы.

1 Знакомство с программой

Программа OOO_07.COM (в дальнейшем программа) представляет из себя консольное приложение для DOS. Запустим его в DOS-Box и введем пароль 123 (рисунок 17).

Давайте попробуем отладить программу при помощи AFD.

2 Отладка программы в AFD

Откроем программу в AFD и найдем то место, где обрабатывается пароль (рисунок 18).

Как видно из рисунка, то место, в котором обрабатывается пароль представляет из себя цикл, состоящий из 5-ти итерации. На каждой итерации регистру BL присваивается символ кодовой фразы, защитой в программу. Далее каждый символ складывается по модулю 2 со значением 0x76 (118). После чего результат операции сравнивается с очередным введенным символом и если они не равны, то выполнение программы завершается. Давайте посмотрим память, по смещению 0x201 (513) (рисунок 19).

Таким образом наш пароль представляет из себя 5 символов 0xF2 (242), 0xF8 (248), 0xFA (250), 0xFE (254), 0xFC (252), каждый из которых необходимо сложить по модулю 2 со значением 0x76 (118):

— 0xF2 ^ 0x76 = 0x84 (132 = «Д»);

— 0xF8 ^ 0x76 = 0x8E (142 = «О»);

— 0xFA ^ 0x76 = 0x8C (140 = «М»);

— 0xFE ^ 0x76 = 0x88 (136 = «И»);

— 0xFC ^ 0x76 = 0x8A (138 = «К»).

Мы получили кодовую фразу «ДОМИК». Введем ее, чтобы проверить нашу гипотезу (рисунок 20).

3 Работа с Sourcer

Дизассемблируем программу при помощи Sourcer (рисунок 22—24).

Сконвертируем полученный листинг в. asm файл (рисунки 25—26).

Исправим исходный код так, чтобы он всегда выводил правильный ответ без ввода пароля (рисунки 27—28).

Заключение

При выполнении работы на практике была произведена обратная разработка программы OOO_07.COM при помощи интерактивного дизассемблеро IDA Pro Freeware.

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

— Разобрался в структуре программы OOO_07.COM;

— Нашел правильный пароль;

— Сделал вывод по результатам проведенной работы.

ЛАБОРАТОРНАЯ РАБОТА №1

Тема: Olly dbg 32

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

Пример выполнения ЛАБОРАТОРНОЙ РАБОТЫ №1

Отладчик OllyDbg

Введение

Цель работы: рассмотреть функционал отладчика OllyDbg и выполнить его детальное описание.

Для выполнения цели поставлен ряд задач:

— Описать функционал отладчика OllyDbg;

— Рассмотреть возможности отладчика OllyDbg;

— Сделать вывод по результатам проведенной работы.

1 Описание

OllyDbg — shareware 32-битный отладчик уровня третьего кольца защиты (ring-3) для операционных систем Windows, предназначенный для анализа и модификации откомпилированных исполняемых файлов и библиотек, работающих в режиме пользователя (ring-3).

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

Последняя версия программы на старом движке — 1.10, не обновлялась с мая 2004 года. Однако 12 ноября 2006 года на официальном сайте был опубликован анонс новой, второй версии продукта. Со 2 июня 2010 года доступна первая новая версия OllyDbg 2.0 без приставки «бета».

В октябре 2013 года была анонсирована 64-битная версия отладчика. В декабре 2013 на сайте появилась информация о прогрессе в разработке.

Как уже было описано ранее, на данный момент имеется две версии программы: релизная старая версия 1.10 и новая, полностью переписанная c нуля, версия 2.01. В данной работе будет рассматриваться новая версия 2.01.

1.1 Возможности

— Поддерживаемые процессоры: вся серия 80x86, Pentium и совместимые; расширения MMX, 3DNow! И SSE до версии SSE4 включительно (SSE5 пока не поддерживается).

— Поддерживаемые форматы отображения данных: hex-код, ASCII, юникод, 16- и 32-битные целые числа со знаком и без знака, 32-, 64- и 80-битные числа с плавающей запятой (float).

— Способы отображения дизассемблированного кода: MASM, IDEAL, HDA.

— Мощный анализатор кода, распознающий процедуры, циклы, ветвления, таблицы, константы и текстовые строки.

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

— Распознание и расшифровка более двух тысяч типичных функций Windows API и языка C.

— Распознание и расшифровка PE-заголовка.

— Эвристический анализ стека, распознание адресов возврата в родительскую процедуру.

— Простые, условные и протоколирующие точки остановки (breakpoints).

— Пошаговая отладка с протоколированием хода выполнения (run trace).

— Индивидуальный файл конфигурации (UDD) для каждого отлаживаемого приложения.

— Поддержка большого количества плагинов.

2 Работа с отладчиком OllyDbg

2.1 Основная функциональность

2.1.1 Форматы данных

Окна дампа отображают данные во всех обычных форматах: шестнадцатеричный, ASCII, Unicode, 16-и 32-разрядные целые числа со знаком/без знака/шестнадцатеричные, дизассемблеры (MASM, IDEAL или HLA).

2.1.2 Запуск отладчика

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

2.1.3 Отладка DLL

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

2.1.4 Анализ

Анализатор — одна из наиболее значительных частей OllyDbg. Он распознает процедуры, циклы, таблицы, константы и строки, внедренные в код, хитрые конструкции, запросы к функциям API, номера параметров функции, секции импорта и так далее. Анализ делает двойной код намного более читаемым, облегчает отладку и уменьшает вероятность сбоев. Анализатор не ориентируется на компилятор и одинаково хорошо работает со всеми Windows программами.

2.1.5 Объектный сканер

OllyDbg просматривает объектные файлы или библиотеки (форматы OMF И COFF), извлекает из них код, сегментирует и определяет местонахождение их в отлаживаемой программе.

Полная поддержка Unicode`а. Почти все операции, доступные для строк ASCII также доступны для строк Unicode`а, и наоборот.

2.2 Горячие клавиши

Горячие клавиши позволяют уменьшить временные затраты на поиск нужной функциональности в меню. Без этой возможности отладчик потеряет свое удобство. Начнём с панели управления:

— Первая кнопка — открыть файл (гор. кл. F3)

— Вторая кнопка — перезапустить файл (гор. кл. Ctrl+F2)

— Третья кнопка — закрыть файл (гор. кл. Alt+F2)

— Четвёртая кнопка — запустить программу (гор. кл. F9)

— Пятая кнопка — приостановить запуск (гор. кл. F12)

— Шестая кнопка — трассировать с заходом в подпрограммы (гор. кл. F7)

— Седьмая кнопка — трассировать без захода в подпрограммы (гор. кл. F8)

— Восьмая кнопка — запустить автоматическую трассировку заходя в подпрограммы (гор. кл. Ctrl+F11)

— Девятая кнопка — запустить автоматическую трассировку без захода в подпрограммы (гор. кл. Ctrl+F12)

— Десятая кнопка — выполнить программу до выхода из подпрограммы (гор. кл. Ctrl+F9)

— Одиннадцатая кнопка — перейти на адрес (гор. кл. Ctrl+G)

Все остальные кнопки на панели управления будут рассмотрены позже.

Необходимые команды:

— Ctrl+A — провести анализ кода

— Ctrl+C — копировать данные

— Ctrl+F7 — включить режим, когда код будет выполняться, как будто бы мы нажали и не отпускаем кнопку F7

— Ctrl+F8 — включить режим, когда код будет выполняться, как будто бы мы нажали и не отпускаем кнопку F8

— Shift+F8 — продолжить трассировку программы, даже если возникла исключительная ситуация

— Shift+F9 — продолжить запуск программы, даже если возникла исключительная ситуация

— Ctrl+T — настройки авто-трейсера

— Ctrl+F11 — Запуск автоматической трассировки с заходом в подпрограммы

— Ctrl+F12 — Запуск автоматической трассировки без захода в подпрограммы

— F2 — Поставить брейкпоинт на выделенной строке

2.3 Плагины

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

— OllyExt — прячет отладчик от обнаружения при помощи различных техник.

— Olly Script — позволяет писать скрипты для помощи в отладке.

— Olly Dump — позволяет дампить отлаживаемый процесс и за одно восстанавливает у него импорт.

— Command Bar — в отладчике появляется строка, где можно вводить команды для отладчика. Справка приведена в приложении А.

2.4 Внешний вид

С отладчиком OllyDbg очень легко работать. На рисунке 29 приведен внешний вид с загруженной тестовой программой.

Детальное описание каждого пункта:

— (желтый) Виртуальные адреса.

— (зеленый) Машинный код.

— (синий) Дизассемблированный листинг (команды ассемблера).

— (красный) Комментарий отладчика.

— (фиолетовый) Регистры общего назначения.

— (серый) EIP регистр (показывает виртуальный адрес следующей выполняемой команды).

— (розовый) Флаги процессора.

— (оранжевый) Регистр флагов.

— (светло зеленый) Сегментные регистры.

— (бардовый) FPU (Floating Point Unit) регистры.

— (охра) Дамп памяти.

— (ультрамариновый) Стек.

2.4.1 Главное окно

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