Защитные трюки
Иные документы об оценке качества рабочей программы дисциплины (при их наличии - ФЭПО, отзывы работодателей, студентов и пр.)
ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ Средства исследования программного кода Часто разработчик заинтересован, чтобы алгоритм реализации его продукта был в тайне или же проект коммерческий, и его требуется обезопасить от взлома его защитных модулей. И с другой стороны, обязательно находятся люди, которым либо интересно как реализована программа, либо её просто хотят получить бесплатно. Все сводится к тому, что программу собираются взломать, а чтобы это сделать, её нужно исследовать. Итак, нструменты исследования программы:
· отладчики реального режима (InSight, Meffistofel, Turbo Debugger (TD) и др.); · отладчики защищенного режима (Soft-Ice, DeGlucker и др.); автоматические дизассемблеры (Sourcer, Watcom Disassembler и др.); · интерактивные дизассемблеры (IDA, DisDoc и др.); · просмотровые программы с встроенным дизассемблированием и возможностью изменения кода (Hiew и др.); · распаковщики исполнимого кода (CUP386 и Generic Tracer); · программы для обмана типичных алгоритмов защиты; · различного рода вспомогательные утилиты.
Наиболее универсальными средствами, которые чаще всего используются для изучения кода программы без исходных текстов (для среды DOS) являются автоматические и интерактивные дизассемблеры (средства статического исследования) и отладчик реального и защищенного режима (средства динамического исследования). Первые преобразуют непонятный машинный код в удобочитаемый текст на языке Ассемблера. Вторые - информируют обо всех процессах, протекающих в недрах компьютера, после выполнения отдельного участка или даже каждой инструкции программы. Наша же задача, как разработчиков подсистемы обеспечения секретности кода, заключается в том, чтобы заставить все эти средства работать неправильно или парализовать их работу. В данной работе мы будем исследовать и защищаться от самого доступного нам отладчика реального режима Turbo Debugger. Данный отладчик очень удобен для исследования, однако как у средства взлома у него есть много недостатков, которые мы и используем, защищая нашу программу. Примите во внимание, что большинство из вышеперечисленных средств, справляются лучше с поставленной задачей, чем выбранный нами отладчик, но мы берем случай с Turbo Debugger для большей наглядности.
Защитные трюки
Защититься от исследования под отладчиком можно двумя путями:
- тем или иным способом обнаружить отладчик и передать управление на некоторую ветку реакции на отладчик; - "загрязнить" программу фрагментами кода, которые нормально выполняются без отладчика, но под отладчиком приводят к аварийному завершению, зависанию компьютера или искажению хода выполнения программы.
Пример. Пусть у нас есть программа, которая выводит строку на экран. CSEG segment org 100h begin: mov ah, 09h mov dx, offset message int 21h int 20h message db 'Hello, world!$' CSEG ends end begin
Чтобы собрать программу в исполнимый файл.com, в командной строке следует ввести команды: tasm <имя_файла> tlink <имя_файла> /t
Запускаем, видим сообщение. Далее, чтобы запустить полученную программу под отладчиком, следует набрать td <имя_файла>
Нажатиями F7 мы можем спокойно протрассировать программу до конца (до команды int 20h).
Большинство отладчиков используют для пошаговой трассировки программы специальные прерывания процессора. Такими прерываниями есть INT 1h и INT 3h. Ври включенном флаге TF=1 прерывание INT 1h вызывается автоматически после вызова каждой команды. Таким образом отладчик изменяет обработчик прерывания INT 1h для реализации алгоритма пошаговой отладки (для отладчика Turbo Debugger по нажатии клавиши F7). Вызов прерывания INT 3h занимает всего один байт, поэтому отладчики используют его для задания точки останова программы. Команда, на которой должна быть приостановлена работа программы сохраняется и заменяется вызовом прерывания INT 3h, таким образом коды последующих команд не изменяются при вставке однобайтового вызова. Отладчик таким же образом отладчик заменяет обработчик прерывания INT 3h для реализации алгоритма перехода к точке останова(для отладчика Turbo Debugger по нажатии клавиши F4). Таким образом для реализации защиты от отладчика необходимо во время работы программы заменить обработчики прерываний INT 1h и INT 3h на вызов команды IRET(машинный код команды IRET - 0CFh). Как известно, таблица векторов(адресов обработчиков) прерываний находится по адресу 0000:0000. Вектора прерываний в таблице размещены последовательно начиная с прерывания INT 00h. Размер каждого вектора прерывания 4 байта – первые 2 байта означают сегмент, а вторые - смещение. таким образом адрес вектора прерывания INT 03h будет равен [0000:4*03h] – 2 байта сегмента, [0000:4*03h+2] - 2 байта смещения. На основе всего этого получаем следующий код: xor ax, ax mov es, ax mov bx, es:[01h*4] mov es, es:[01h*4+2] mov ah, 0CFh mov es:[bx],ah
xor ax, ax mov es, ax mov bx, es:[03h*4] mov es, es:[03h*4+2] mov ah, 0CFh mov es:[bx],ah
соответственно замена байта в обработчиках прерываний INT 1h и INT 3h. Вставляем эти инструкции в начало нашей программы (сразу после метки begin) и пересобираем программу. Запускаем саму программу, видим тоже самое сообщение, и затем запустим уже под отладчиком. Теперь, если пошагово трассировать обновленную программу и наткнуться на этот участок кода, мы увидим, что трассировать дальше становится невозможным: отладчик либо выбрасывается на неизвестный участок кода, либо аварийно завершает исследуемую программу.
Можно вовсе подменять вектора отладочных прерываний (INT 1, INT 3). Здесь открывается широкий простор для фантазии разработчика - можно поменять их местами, заместить на вектор INT 19h, INT 20h или любой другой вектор, сдвигать сегмент или смещение в этих векторах, модифицировать код обработчика и т. д. Попытка трассировки программы при таких перестановках опять же приводит к повисанию отладчика или DOS.
Еще один способ выявления отладчика в процессе трассировки – определение времени между инструкциями. Очевидно, что трассировка – процесс намного длительнее, чем естественное выполнение программы. Предлагаем следующее решение:
mov ah,2ch; Get Time int 21h; вызов функции ДОС push dx; dh - секунды, dl – доли секунд mov ah,2ch; Get Time int 21h; вызов функции ДОС pop ax; ah – секунды cmp dh,ah; сравниваем jz continue; если время не изменилось, далее
Данный участок кода проверяет, не изменилось ли существенно время, за течение выполнения со второй по пятую строку, и если нет переходим по метке, где программа продолжает нормально работать, но если да, сразу за командой перехода будет идти код, реагирующий на отладчик. Можно просто добавить int 20h, можно сделать бесконечный цикл, спровоцировав зависание программы, или вовсе поместить действительно вредоносный код. Метку continue в нашем случае следует установить после begin, и между двумя этими метками поместить вышеуказанный код.
1.3 «Изощренное» программирование
Приемы защиты программ от отладчиков и дизассемблеров для программирования задач ответственного целевого назначения, конечно, хороши. Но, как уже отмечалось, абсолютно надежных защит не бывает, и поскольку задача разработчика защиты - вынудить противника потратить на взлом время, достаточное для принятия контрмер, только противоотладочными трюками ограничиваться не нужно. Нелишне также затруднить исследование программы и после того, как противник обойдет или устранит все ловушки для хакерского инструментария. Для этого необходимо сделать программу высокочитабельной для нас, но малопонятной в дизассемблированном виде, а под отладчиком - создающей впечатление хаотичного набора условных и безусловных переходов. Эта задача решается применением так называемого "изощренного" программирования. Можно выделить несколько основных направлений: · экзотическая, имеющая необычный вид реализация алгоритмов с использованием редких команд процессора или их нестандартных сочетаний; · реализация нескольких полностью эквивалентных вариантов одного и того же алгоритма, при каждом обращении к которому случайным образом выбирается один из вариантов его реализации; · засорение кода "мусором" - командами, не влияющими на обработку наших данных (кроме некоторого увеличения времени обработки на "засоренных" участках).
Рассмотрим эти приемы подробнее.
Экзотическая реализация алгоритмов. Допустим, у нас есть некоторый флаг (или переменная), для которого критически важна проверка на 0. Однако мы не желаем явно писать команду СМР АХ, 0 и вообще по возможности хотим обойтись без команд передачи управления. Первое, что приходит в голову - использовать команды, пригодные для неявной проверки на 0. Например, использовать команды двоично-десятичной арифметики. mov ах, OurFlag daa pushf pop ax; Неявная проверка флага нуля and ах, 40h jz FlaglsZero Разумеется, в реальной программе получение флагов и проверка наличия флага нуля должны быть разнесены для все того же затруднения исследования. Однако этот вариант, хотя и применимый, относительно прост для взлома. Взлом значительно усложняется, если мы установим обработчик нулевого значения флага на INT 0 (деление на 0), а проверку реализуем как деление чего-нибудь на значение флага, загруженное в любой допустимый регистр. В этом случае никакого перехода на обработчик нулевого значения флага нет вообще, а кроме того, некоторые отладчики аварийно завершают программу при выполнении деления на 0. Реализация эквивалентных ветвей. Для затруднения исследования программы под отладчиком польза от этого приема очевидна. В самом деле, если мы, находясь в отладчике, попадаем то на одну команду, то на несколько, это явно не упростит понимание алгоритма программы. Приведем простой пример. Операция NEG (преобразование числа в дополнительный код) эквивалентна исключающему ИЛИ со "всеми единицами" и инкременту результата Напишем макрос, реализующий алгоритм с двумя возможными ветвями его выполнения. XNEG16 MACRO Reg Local XNEG2, XNEGQ push ax;Используется ;процедурой Random
call Random;Некоторая ;подпрограмма ;генерации ;случайных или ;псевдослучайных ;чисел cmp al, 30 ja XNEG2 pop ax neg Reg jmps XNEGQ XNEG2: xor Reg, 0FFFFh inc Reg XNEGQ: ENDM
Это лишь простейший пример, относительно легко поддающийся анализу. Для затруднения анализа возможно: - увеличить число ветвей (реализуется не для всех алгоритмов); - реализовать ветви в виде обработчиков прерываний (INT 1, INT 3, INT 4, INT6 и т.д.) и обращаться к ним не напрямую, а путем создания соответствующих ситуаций (взведением флага TF, засылкой команды INT 3 на место заранее поставленного NOP, делением на 0 и пр.), что, кстати, еще и расширит противоотладочную подсистему; - увеличить число проверок случайного числа.
Засорение кода. Под засорением кода будем понимать искусственное внесение в него команд, не имеющих отношения к реализуемому алгоритму, которое либо затрудняет его анализ, либо делает этот анализ более канительным, более утомительным и, следовательно, требующим больше сил и времени. Речь идет о манипуляции незадействованными регистрами; установке/сбросе некоторых флагов, выполнении нескольких команд, на эти флаги не влияющих, с последующ, условным переходом, который на самом деле заведомо выполнится или заведомо не вы полнится; обработке нескольких одинаковых структур, из которых только одна содержит данные нашего алгоритма и т.д. Все это не только увеличивает объем дизассемблированного текста, но и отвлекает внимание от защищаемого алгоритма. Полезно засорять код еще и макросами или вызовами, эмулирующими ввод с клавиатуры команд Soft-Ice, TR или комбинаций клавиш распространенных отладчиков, или даже просто нажатие некоторых случайных клавиш. Очевидно, при этом нужно почистить буфер перед вызовом любой подпрограммы обращения к клавиатуре.
|
