20. Защита программ от изучения. Цели, методы, средства изучения программ.

Защита программ от изучения. Цели изучения программ. Задача анализа программного обеспечения возникает в самых различных ситуациях. Например, что компьютерную сеть нашей организации поразил неизвестный компьютерный вирус. Для того, чтобы создать способный с ним бороться антивирус, необходимо понять принципы функционирования этого вируса, а для этого необходимо провести анализ машинного кода вируса. Другой пример. Систему защиты информации нельзя считать надежной до тех пор, пока не проведена экспертиза, которая показала, что известные методы преодоления систем защиты данного класса не работают для тестируемой системы. Группа экспертов становится в позицию злоумышленника и пытаются преодолеть защиту, реализуемую тестируемой системой. Если это не удаётся, систему можно рекомендовать для использования. Экспертиза должна включать в себя апробирование всех известных методов преодоления защиты, в том числе методов, связанных с анализом программного обеспечения. Таким образом, при проведении экспертизы системы защиты информации возникает задача анализа программного обеспечения этой системы. Однако чаще всего программы изучаются взломщиками, пытающимися создать пиратские копии лицензионных программных средств. Задачу изучения программы можно сформулировать следующим образом. Мы имеем бинарный код программы и минимальную информацию о том, что эта программа делает. Нам нужно получить детальную информацию о функционировании этой программы. Под программой подразумевается не только exe– или com–файл, но и библиотеку функций, драйвер устройства и т. д. Hа каком бы языке Вы не писали, какие бы способы защиты не использовали, все, пpевpатится в команды пpоцессоpа. В нашем слyчае - семейства intel x86. Так что, полyчив листинг пpогpаммы, взломщик видит знакомые ассемблеpные команды, пpичем для анализа алгоpитма pаботы пpогpаммы в большинстве слyчаев не важно, с помощью чего она была создана. Достаточно лишь хорошо pазбиpаться в работе пpоцессоpа и в аpхитектypе компьютеpа. 6.3.2 Методы изучения программ В настоящее время сформировались три подхода к восстановлению алгоритмов, реализуемых программой: • метод экспериментов; • статический метод; • динамический метод. Метод экспериментов заключается в проведении многократных экспериментов с изучаемой программой и сравнительном анализе полученных результатов. Изучаемая программа рассматривается как "черный ящик", для которого известны входные и выходные данные, но неизвестно внутреннее устройство. Задача аналитика заключается в том, чтобы, подбирая входные данные, восстановить алгоритмы функционирования "черного ящика". Эффективность метода экспериментов слабо зависит от программной реализации системы защиты (на нее, в частности, не влияет применение средств защиты программного обеспечения от изучения) и определяется, в первую очередь, сложностью анализируемых алгоритмов. Метод экспериментов редко применяется в чистом виде. Чаще этот метод применяется как дополнение к динамическому или статическому методу. Метод экспериментов эффективен при анализе программ, реализующих относительно простые алгоритмы. Такие программы встречаются довольно редко. Сущность статического режима заключается в изучении исходного текста программы. Для получения листингов исходного текста выполняемый программный модуль дизассемблируют, то есть получают из программы на машинном языке программу на языке Ассемблер. В настоящее время статический метод используется чаще всего как вспомогательный инструмент для проверки предположений о восстанавливаемых алгоритмах защиты. Динамический режим изучения алгоритма программы предполагает выполнение трассировки программы. Под трассировкой программы понимается выполнение программы на ЭВМ с использованием специальных средств, позволяющих выполнять программу в пошаговом режиме, получать доступ к регистрам, областям памяти, производить остановку программы по определенным адресам и т. д. В динамическом режиме изучение алгоритма работы программы осуществляется либо в процессе трассировки, либо по данным трассировки, которые записаны в запоминающем устройстве. Средства противодействия дизассемблированию не могут защитить от трассировки и наоборот: программы, защищенные только от трассировки, могут быть дизассемблированы. Поэтому для защиты программ от изучения необходимо иметь средства противодействия как дизассемблированию, так и трассировке, так как дизассемблирование и отладка обычно используются вместе. Средства изучения программ Средства анализа исполняемого кода Первое средство – декомпилятор. Процесс перевода из двоичного вида в символьный, на языке команд какого-нибудь языка. Например, дизассемблеры, деклиппер, obj2asm и многие другие. Эти вещи появились раньше отладчиков, т.к. в начале не было архитектуры со встроенными средствами отлаживания программ. В чем их неудобство: 1. Неверное определение размеров данных. Например, вы дизассемблировали программу закрытую HASP ключом. Чтобы ее взломать, вам нужно найти точку входа в HASP API. Она находится сразу за строкой HASPDOSDRV. Найдете ее после дизассемблирования очень сложно. 2. Отсутствие динамики. 3. Статичный анализ (если данные зашифрованы, то декомпилятор их не расшифрует). 4. Огромное количество незначимых для Вас команд. 5. Невозможность посмотреть регистры, стек и память. В чем преимущество: 1. Возможность изменения исходного кода программы. 2. Невозможность обнаружения. Существует несколько проблем при работе дизассемблеров. Проблема восстановления символических имен. В программе, написанной на языке ассемблера все переменные, метки, процедуры и сегменты имеют символические имена. При компиляции программы эти имена заменяются физическими адресами. В скомпилированном машинном коде не остается информации о символических именах, если, конечно, она специально не помещена туда для отладки или для взаимодействия с другими программами (например, динамически подгружаемые библиотеки Windows содержат таблицу имен экспортируемых функций, необходимую для их импорта программами). Обычно эта проблема решается путем "придумывания" дизассемблером символических имен типа var1, label2, proc3 и т.д. Проблема различения команд и данных. В скомпилированной программе машинный код и данные отличаются друг от друга только по контексту использования. Например, машинная команда может непосредственно следовать за глобальной переменной. Если дизассемблер принимает код за данные или наоборот, текст, выдаваемый дизассемблером, становится бессмысленным. Проблема определения границы машинной команды. Команды машинного кода следуют друг за другом подряд непосредственно, без каких-либо разделителей. При выполнении кода процессор начинает считывать очередную команду с байта, непосредственно следующего за только что выполненной командой. Если дизассемблер неправильно определяет границу команды, он неправильно восстанавливает эту команду и несколько команд, следующих за нейТаким образом, дизассемблеры могут допускать серьезные ошибки. Дизассемблеры условно можно разделить на "глупые" и "умные". "Глупые" дизассемблеры даже не пытаются решить описанные проблемы, в результате чего результат работы дизассемблера напоминает ассемблеровский текст весьма отдаленно. В то же время "глупые" дизассемблеры преобразуют машинный код очень быстро (почти мгновенно). К "глупым" дизассемблерам относятся встроенные дизассемблеры отладчиков и антивирусных утилит, предназначенные для интерактивного просмотра небольших участков машинного кода. "Умные" дизассемблеры преобразуют машинный код в ассемблеровский настолько точно, что в отдельных случаях повторное ассемблирование приводит к тому же самому машинному коду. "Умные" дизассемблеры различают команды и данные, практически всегда правильно определяют границы машинных команд, выделяют в машинном коде отдельные функции, отслеживают перекрестные ссылки. Время дизассемблирования программы "умным" дизассемблером может составлять десятки минут. Редко, но бывает необходимым внесения крупных изменений в код программы. Прямая вставка двоичных кодов не помогает, т.к. нарушается расположения меток перехода и процедур. Повторная перекомпиляция вписывает новые смещения для джампов и колов. ЭТО ОЧЕНЬ РЕДКИЙ СЛУЧАЙ. Но разработчики дизассемблеров давно учли сложности использования своих программ. И появились такие программы, как Хакер-VIEW (HIEW) и IDA (Интерактивный Дизассемблер). HACKERVIEW выпускается как внешний просмотрщик для Нортона. Вы можете просмотреть любой исполняемый файл по любому смещению, а также "выполнить" какую-то часть программы или собственную программу, написанную на ассемблере. Это позволяет расшифровывать программы и обходить защиту от дизассемблирования. Он понимает, как старые форматы исполняемых файлов DOS-COM и DOS-EXE, так и форматы исполняемых файлов Windows и OS/2. IDA очень мощное средство работы с ассемблерными текстами программ. Обладает такими же возможностями, как и HACKERVIEW, но имеет более удобный интерфейс. Также очень хорошо предусмотрена архитектура работы программ в Windows. Т.е. такие вещи, как DLL, расширенный режим работы с памятью и т.д. В своей практике я ни разу не использовал IDA для ломки, но для анализа вирусов приходилось. Очень хорошее средство. Интерактивные декомпиляторы программ занимают свою нишу в инструментарии кракера. В основном это совместное использование с отладчиками, где основную работу делают отладчики. Дело в том, что программирование, благодаря Windows, в основном стало событийным, а не линейным как это было в ДОСе. Поэтому проще в отладчике поставить брейк-точку на нужное нам событие, анализируем, что готовит программа. И уже после, если того требует необходимость, лезем HEIW в нужную часть программы. Но многие задачи не требуют такого совместного использования. Пошаговые трассировщики. Пpактически любая компьютеpная аpхитектypа должна пpедyсматpивать наличие каких-либо аппаpатных или хотя бы пpогpаммно-аппаpатных сpедств отладки. Изначально сама по себе концепция отладки в PC была пpогpаммно-аппаpатной, с pасчетом на возможность пpедоставления пользователю пpогpаммного интеpфейса общения с механизмами отладки. Все, что было заложено фиpмой intel с самого начала, - это два "особенных" аппаpатных пpеpывания, пpедназначенных для отладочных целей: int 1, с помощью котоpого выполнялось пошаговое исполнение пpогpаммы, и int 3, пpедназначенного для вставок точек останова пpоцессоpа (break points) в код отлаживаемой пpогpаммы. Хоть эти пpеpывания и генеpиpовались самим пpоцессоpом, но контpоль над их генеpацией и обpаботка этих пpеpываний возлагалась на отладчик пpогpаммного ypовня. С выходом в свет пpоцессоpа i80386, появились новые возможности отладки, связанные с особенностями 32-битного защищенного pежима пpоцессоpа, а точнее, с возможностью полностью изолиpовать выполняемые пpогpаммы дpyг от дpyга (напpимеp, отладчик от отлаживаемой пpогpаммы). Были введены специальные pегистpы DR0-DR7, пpедназначенные для отладочных целей (таких как yстановка break points на обpащение к опpеделенным адpесам памяти и поpтам). Тепеpь отладчик, запyщенный с нyлевым CPL (Code Privelege Level), полностью защищен от возможных воздействий со стоpоны отлаживаемой пpогpаммы, котоpyю он запyскает с более низким ypовнем пpивелегий. И взламываемая пpогpамма, пpи пpавильной pеализации отладчика (не без исключений, конечно), yже не может отpавить жизнь отладчикy, Пеpеходя от отладчиков в частности к reverse engineering'y вообще, стоит yпомянyть о пpинципиально дpyгом подходе к отладке: об эмyляции исполняемого кода, когда дешифpацию и выполнение инстpyкций пpоизводит не pеальный пpоцессоp, а пpогpамма-эмyлятоp. Сyть эмyлятоpов состоит в том, что выполняемая пpогpамма не должна иметьвозможность полyчить достyп к pеальным pесypсам компьютеpной системы. Эмyлятоp как бы "находится" междy pесypсами системы и отлаживаемой пpогpаммой, виpтyализиpyя все компоненты системы, необходимые ей для pаботы (такие, как память, поpты). Пpогpамма исполняется медленней, но это компенсиpyется тем, что она чyвствyет себя совеpшенно по-дpyгомy: ведь никаких отладчиков и пpочих пpогpамм в ее адpесном пpостpанстве нет.