Обычные проблемы хакера

Проще всего разбирать чужую программу, если она уже распечатана на бумаге на любом языке высокого уровня (Паскаль, Си и т.д.), но в крайнем случае сгодится и ассемблер (машинные коды заменены их мнемоническим изображением). В качестве универсального инструмента можно рекомендовать отладчик Turbo Debugger (TD), имеющий широкий сервис и удобный интерфейс. Автор программы применил шифрование и ее разновидность - архивацию. А потому непосредственное дизассемблирование уже не даст верных результатов. Опытный хакер быстро поймет, что вместо текста идет "мусор" и сразу же начнет поиск средств для снятия шифра. Обычно он достигает цели, так как рано или поздно программа сама производит нужную операцию (она ведь не подозревает, что ее запустил хакер). Определив момент завершения дешифрации, можно "снять" в файл содержимое памяти, занимаемой уже "нормальной" программой, и, прогнав его дизассеблером, получить желаемый результат. Даже если используется поэтапная дешифровка (то есть она разнесена по времени), полной гарантии защиты нет - дизассемблирование лишь несколько затянется. Впрочем, когда дешифрацией занимается несколько подпрограмм и каждая является результатом работы предыдущей, хакеру предстоит очень нудная и кропотливая работа по их анализу. Шифрование, хотя и не гарантирует полной безопасности программы, но вынуждает хакера запускать ее отдельные участки (без алгоритмов, разбираясь "на ходу"), таким образом, разработчику предоставляется возможность активно вмешиваться в процесс "взлома" (точнее, поручить это своей программе) и, в первую очередь, отобрать у хакера самый мощный инструмент - пошаговый режим отладки.

В режиме отладки больше всего забот доставляет стек: его расположение, размер, варианты применения. Достаточно тонкое его использование зачастую делает невозможным даже запуск стандартных отладочных средств. Например, назначение в тело выполняемой задачи: стековый сегмент совпадает с кодовым, а указатель вершины стека SP указывает на саму программу. Тогда отработка отладчиком хотя бы одного прерывания (трассировочного) обязательно сотрет участок размером не менее 3-х слов. Тем более, что популярные отладчики (TD, CodView и другие) применяют только пользовательский стек, затирая в нашем случае коды на большую глубину. Кроме того, старые версии TD имеют принципиальную ошибку - при начальной загрузке совершенно произвольно уменьшают стартовое значение указателя стека на 2. Более умеренно работают со стеком отладчики AFD и PERISCOPE. И наиболее выгодно себя проявляет обычный DEBUG, поставляемый вместе с DOS.

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

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

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