Методы и средства обеспечения целостности и достоверности используемого программного кода

ГЛАВА 13.Методы и средства обеспечения целостности и достоверности используемого программного кода

13.1.Методы защиты программ от
несанкционированных изменений

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

РПС могут быть внедрены в авторскую программу или эта программа может быть полностью заменена на программу-носитель РПС;
могут быть изменены характеристики (атрибуты) программы;
злоумышленник может выдать себя за настоящего владельца программы;
законный владелец программы может отказаться от факта правообладания ею.

Наиболее эффективными методами защиты от подобных злоумышленных действий предоставляют криптографические методы защиты. Это обусловлено тем, что хорошо известные способы контроля целостности программ, основанные на контрольной сумме, продольном контроле и контроле на четность, как правило, представляют собой довольно простые способы защиты от внесения изменений в код программ. Так как область значений, например, контрольной суммы сильно ограничена, а значения функции контроля на четность вообще представляются одним-двумя битами, то для опытного нарушителя не составляет труда найти следующую коллизию: f(k₁)=f(k₂), где k₁ - код программы без внесенной нарушителем закладки, а k₂ - с внесенной программным закладкой и f - функция контроля. В этом случае значения функции для разных аргументов совпадают при тестировании и, следовательно, РПС обнаружено не будет.

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

В первом случае аутентифицируемой программе ставится в соответствие некоторый аутентификатор, который получен при помощи стойкой криптографической функции. Такой функцией может быть криптографически стойкая хэш-функция (например, функция ГОСТ Р 34.11-94) или функция электронной цифровой подписи (например, функция изГОСТ Р 34.10-94). И в том, и в другом случае аргументами функции может быть не только код аутентифицируемой программы, но и время и дата аутентификации, идентификатор программиста и/или предприятия - разработчика ПО, какой-либо случайный параметр и т.п. Может использоваться также любой симметричный шифр (например, DES или ГОСТ 28147-89) в режиме генерации имитовставки. Однако это требует наличия секретного ключа при верификации программ на целостность, что бывает не всегда удобно и безопасно. В то время как при использовании метода цифровой подписи при верификации необходимо иметь только некоторую общедоступную информацию, в данном случае открытый ключ подписи. То есть контроль целостности ПО может осуществить любое заинтересованное лицо, имеющее доступ к открытым ключам используемой схемы цифровой подписи.

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

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

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

13.2.Схема подписи с верификацией по запросу

В работах Д. Шаума (см., например, [Ка5,Ка14]) впервые была предложена схема подписи с верификацией по запросу, в которой абонент V не может осуществить верификацию подписи без участия абонента S. Такие схемы могут эффективно использоваться в том случае, когда фирма - изготовитель поставляет потребителю некоторый информационный продукт (например, программное обеспечение) с проставленной на нем подписью указанного вида [КУ10]. Однако проверить эту подпись, которая гарантирует подлинность программы или отсутствие ее модификаций, можно только уплатив за нее. После факта оплаты фирма - изготовитель дает разрешение на верификацию корректности полученных программ.

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

Схема ПВЗ

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

Вместе с обозначениями секретного и открытого ключей x_RZ_q и y_RZ^*_p (взятых из отечественного стандарта на электронную цифровую подпись) введем также обозначения S₁=x и S₂=u, u_RZ_q, а также открытый ключ P=(g,y,w), где wg^u(mod p). Открытый ключ P публикуется в открытом сертифицированном справочнике.

Протокол ГП

Подпись кода m вычисляется следующим образом. Выбирается k_RZ_q и вычисляется . Затем вычисляется s[xr+mku](mod q). Пара (r,s) является подписью для кода m. Подпись считается корректной тогда и только тогда, когда , где wm^-1(mod q).

Проверка подписи (с участием подписывающего) осуществляется посредством следующего интерактивного протокола.

Протокол верификации ПВ

Абонент V вычисляет и просит абонента S доказать, что пара (r,s) есть его подпись под кодом m. Эта задача эквивалентна доказательству того, что дискретный логарифм  по основанию r равен (по модулю p) дискретному логарифму w по основанию g, то есть, что log_g⁽^p⁾wlog_r⁽^p⁾. Для этого:

Абонент V выбирает a,b_RZ_q, вычисляет и посылает  абоненту S.
Абонент S выбирает t_RZ_q, вычисляет , и посылает h₁ и h₂ абоненту V.
Абонент V высылает параметры a и b.
Если , то абонент S посылает V параметр t; в противном случае - останавливается.
Абонент V проверяет выполнение равенств и .

Если проверка завершена успешно, то подпись принимается как корректная.
Протокол ОП

В отвергающем протоколе S доказывает, что log_g⁽^p⁾wlog_r^(p⁾. Следующие шаги выполняются в цикле l раз.

Абонент V выбирает d,e_RZ_q, d1, _R{0,1}. Вычисляет , , если =0 и , , если =1. Посылает S значения a, b, d.
Абонент S проверяет соотношение . Если оно выполняется, то =0, в противном случае =1. Выбирает R_RZ_q, вычисляет и посылает V значение c.
Абонент V посылает абоненту S значение e.
Абонент S проверяет, что выполняются соотношения из следующих двух их пар: , и , . Если да, то посылает V значение R. Иначе останавливается.
Абонент V проверяет, что .

Если во всех l циклах проверка в п.5 выполнена успешно, то абонент V принимает доказательства.
Таблица 13.1. Протокол верификации является интерактивным протоколом доказательств с абсолютно нулевым разглашением.

Доказательство. Требуется доказать, что вышеприведенный протокол удовлетворяет трем свойствам: полноты, корректности и нулевого разглашения [Ка5, Ка14].

Полнота означает, что если оба участника (V и S) следуют протоколу и (r,s) - корректная подпись для сообщения m, то V примет доказательство с вероятностью близкой к 1. Из описания протокола верификации очевидно, что абонент S всегда может надлежащим образом ответить на запросы абонента V, то есть доказательство будет принято с вероятностью 1.

Корректность означает, что если V действует согласно протоколу, то какие действия не предпринимал бы S, он может обмануть V лишь с пренебрежимо малой вероятностью. Здесь под обманом понимается попытка S доказать, что log_g⁽^p⁾wlog_r^(p⁾, когда на самом деле эти логарифмы не равны.

Предположим, что log_g⁽^p⁾wlog_r^(p⁾. Ясно, что для каждого a существует единственное значение b, то которое дает данный запрос . Поэтому  не содержит в себе никакой информации об a. Если S смог бы найти h₁, h₂, t₁ и t₂ такие, что

и

,

где a₁a₂, то тогда выполнялось бы соотношение
log_g^(p⁾r[(a₁-a₂)^-1((b₂-b₁)+(t₂-t₁))](mod q)log_w⁽^p⁾.
Отсюда, очевидно, следует, что log_g⁽^p⁾wlog_r^(p⁾. В самом деле, пусть log_w⁽^p⁾log_g^(p⁾r . Тогда
,
что противоречит предположению. Следовательно, какие бы h₁, h₂, t₁ и t₂ не выбрал S, проверка, которую проводит V, может быть выполнена только для одного значения a. Отсюда вероятность обмана не превосходит 1/q. Отметим, что протокол верификации является безусловно стойким для абонента V, то есть доказательство корректности не зависит ни от каких предположений о вычислительной мощности доказывающего (S).

Свойство нулевого разглашения означает, что в результате выполнения протокола абонент V не получает никакой полезной для себя информации (например, о секретных ключах, используемых S). Для доказательства нулевого разглашения необходимо для любого возможного проверяющего V^* построить моделирующую машину , которая является вероятностной машиной Тьюринга, работает за полиномиальное в среднем время и создает на выходе (без участия S) такое же распределение случайных величин, которое возникает у V^* в результате выполнения протокола. В нашем случае, случайные величины, которые «видит» V^*, - это h₁, h₂, и t. Необходимо доказать, что протокол верификации является доказательством с абсолютно нулевым разглашением, то есть моделирующая машина создает распределение случайных величин (h₁,h₂,t), которое в точности совпадает с их распределением, возникающим при выполнении протокола. Моделирующая машина использует в своей работе V^* в качестве «черного ящика».

Моделирующая машина

Запоминает состояние машины V^*, то есть содержимое всех ее лент, внутреннее состояние и позиции головок на лентах. Затем получает от V^* значение  и после этого снова запоминает состояние машины V^*.
Выбирает _RZ_q и вычисляет и .
Получает от V^* значения a и b. Если , то останавливается.
Машина «отматывает» V^* на состояние, которое было запомнено в конце шага 1. Выбирает t_RZ_q и вычисляет и .
Машина передает V^* h₁, h₂ и получает ответ (a,b). Возможны два варианта:

5.1. a=a, b=b. В этом случае моделирование закончено и

записывает на выходную ленту тройку (h₁,h₂,t) и останавливается.

5.2. aa или bb. Отсюда следует, что . Предположим, что bb. Из этого следует, что aa. Следовательно, может вычислить . Отсюда (b-b)/(a-a)=l - дискретный логарифм r по основанию g.

6. Машина «отматывает» V^* на состояние, которое было заполнено в начале шага 1. Получает от V^* значение .

7. Выбирает _RZ_q вычисляет и и передает их V^*.

8. Получает от V^* значения a и b. Если , то останавливается. В противном случае вычисляет
t=[-al-b](mod q), выдает (h₁,h₂,t) на выходную ленту и останавливается.
К пп. 7 и 8 необходимо сделать следующее пояснение. Поскольку log_g⁽^p⁾wlog_r^(p⁾, из этого следует, что log_w⁽^p⁾log_g^(p⁾r. Отсюда

.

Из описания моделирующей машины очевидно, что она работает за полиномиальное время. Величины (h₁,h₂,t) на шаге 5.1 выбираются в точности как в протоколе и поэтому имеют такое же распределение вероятностей. Кроме того, значения (h₁,h₂), выбираемые на шаге 7, имеют такое же распределение, как и в протоколе. Чтобы показать что и t имеет одинаковое распределение, достаточно заметить, что машина V^* не может по h₁ и h₂ определить, с кем она имеет дело - с S или . Поэтому, даже если бы V^* могла каким-либо «хитрым» образом строить a и b с учетом (h₁,h₂), распределение вероятностей величин a и b в обоих случаях одинаковы. Но значение t определяется однозначно четверкой величин a, b, h₁, h₂, при условии выполнения проверки на шаге 5 протокола. 

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

Доказательство. Полнота протокола очевидна. Если абоненты S и V следуют протоколу, тогда абонент V всегда примет доказательства абонента S.

Для доказательства корректности прежде всего заметим, что если log_g⁽^p⁾wlog_r^(p⁾, то a и b, выбираемые абонентом V на шаге 1, не несут в себе никакой информации о значении . Поэтому, если S может “открыть” c, сгенерированное им на шаге 2, лишь единственным образом (то есть выдать на шаге 4 единственное значение R, соответствующее данному ), то проверка на шаге 5 будет выполнена с вероятностью 1/2 в одном цикле и с вероятностью 1/2^l во всех l циклах.

Если же S может сгенерировать c таким образом, что с вероятностью, которая не является пренебрежимо малой, он может на шаге 4 “открыть” оба значения , то есть найти R₁ и R₂ такие, что и , то алгоритм, который использует S для этой цели, можно использовать для вычисления дискретных логарифмов: log_gd=R₂-R₁. Так как при случайном выборе значения d логарифм log_gd может быть вычислен с вероятностью, которая не является пренебрежимо малой, это противоречит гипотезе о трудности вычисления дискретных логарифмов.

Далее доказывается, что отвергающий протокол является доказательством с абсолютно нулевым разглашением. Для этого необходимо для всякого возможного проверяющего V^* построить моделирующую машину , которая создает на выходе (без участия S) такое же распределение случайных величин (в данном случае, c и R), какое возникает у V^* в результате выполнения протокола.

Моделирующая машина

Следующие шаги выполняются в цикле l раз.

Машина запоминает состояние машины V^*.
Получает от V^* значения a, b и d.
Выбирает _R{0,1}, R_RZ_q и вычисляет . Посылает V^* значение c.
Получает от V^* значение e.
Проверяет, было ли «угадано» на шаге 2 значение  (это значение было «угадано», если , и =0, либо , и =1). Если да, то записывает на входную ленту значение (c,R). В противном случае «отматывает» V^* на то состояние, которое было запомнено на шаге 1, и переходит на шаг 2.

Легко видеть, что распределения случайных величин (c,R), возникающее в процессе выполнения протокола и создаваемые моделирующей машиной , одинаковы, поскольку R в обоих случаях - чисто случайная величина, а величина c записывается на выходную ленту машины только тогда, когда  совпало с .

Поскольку значение  выбирается машиной на шаге 3 случайным образом, а c не дает V^* никакой информации о значении , на каждой итерации  будет угадано с вероятностью 1/2. Отсюда следует, что машина работает за полиномиальное в среднем время. 

В работе [Ка14] показано, как строить схемы конвертируемой и селективно конвертируемой подписи с верификацией по запросу на основе отечественного стандарта ГОСТ Р 34.10-94. В таких схемах открытие определенного секретного параметра некоторой схемы подписи с верификацией по запросу позволяет трансформировать последнюю в обычную схему цифровой подписи. При этом открытие секретного параметра в конвертируемой схеме подписи с верификацией по запросу дает возможность верифицировать все имеющиеся и сгенерированные в дальнейшем подписи, в то время как в селективно конвертируемых схемах подписи с верификацией по запросу можно верифицировать лишь какую-либо одну подпись.

13.3.Примеры применения схемы подписи
с верификацией по запросу

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

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

www.kiev-security.org.ua

BEST rus DOC FOR FULL SECURITY

Особенности реализации подобных сценариев, а также злоумышленные действия в отношении предлагаемых схем защиты, рассмотрены в работах [КУ10,Ка5,Ка14].

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

ГЛАВА 14.Основные подходы к защите программ от
несанкционированного копирования

14.1.Основные функции средств защиты от копирования

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

Инсталлированная программа для защиты от копирования при каждом запуске должна выполнять следующие действия:

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

Этап проверки подлинности среды является одним из самых уязвимых с точки зрения защиты. Можно детально не разбираться с логикой защиты, а немного «подправить» результат сравнения, и защита будет снята.

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

Для снятия защиты от копирования применяют два основных метода: статический и динамический [РД].

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

14.2.Основные методы защиты от копирования

14.2.1.Криптографические методы

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

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

Преобразованные эталонные характеристики аппаратно-программной среды могут быть занесены в следующие области жесткого диска:

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

Можно выделить два основных метода защиты от копирования с использованием криптографических приемов:

с использованием односторонней функции;
с использованием шифрования (которое также может использовать односторонние функции).

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

Если эталонные характеристики программно-аппаратной среды представить в виде аргумента односторонней функции x, то y - есть «образ» этих характеристик, который хранится на винчестере и по значению которого вычислительно невозможно получить сами характеристики. Примером такой односторонней функции может служить функция дискретного экспоненцирования, описанная ранее, с размерностью операндов не менее 512 битов.

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

14.2.2.Метод привязки к идентификатору

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

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

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

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

14.2.3.Методы, основанные на работе с переходами и стеком

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

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

14.2.4.Манипуляции с кодом программы

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

включение в тело программы «пустых» модулей;
изменение защищаемой программы.

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

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

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

14.2.5.Методы противодействия динамическим способам снятия
защиты программ от копирования

Набор методов противодействия динамическим способам снятия защиты программ от копирования включает следующие методы [РД]:

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

- в случае если программу пытаются «раздеть», выявить контрольные точки, установленные отладчиком;

проверка количества свободной памяти и сравнение и с тем объемом, к которому задача «привыкла» или «приучена». Это действия позволит застраховаться от слишком грубой слежки за программой с помощью резидентных модулей;
проверка содержимого незадействованных для решения защищаемой программы областей памяти, которые не попадают под общее распределение оперативной памяти, доступной для программиста, что позволяет добиться «монопольного» режима работы программы;
проверка содержимого векторов прерываний (особенно 13h и 21h) на наличие тех значений, к которым задача «приучена». Иногда бывает полезным сравнение первых команд операционной системы, отрабатывающих этим прерывания, с теми командами, которые там должны быть. Вместе с предварительной очисткой оперативной памяти проверка векторов прерываний и их принудительное восстановление позволяет избавиться от большинства присутствующих в памяти резидентных программ;
переустановка векторов прерываний. Содержимое некоторых векторов прерываний (например, 13h и 21h) копируется в область свободных векторов. Соответственно изменяются и обращения к прерываниям. При этом слежение за известными векторами не даст желаемого результата. Например, самыми первыми исполняемыми командами программы копируется содержимое вектора 21h (4 байта) в вектор 60h, а вместо команд int 21h в программе везде записывается команда int 60h. В результате в явном виде в тексте программы нет ни одной команды работы с прерыванием 21h;
постоянное чередование команд разрешения и запрещения прерывания, что затрудняет установку отладчиком контрольных точек;
Контроль времени выполнения отдельных частей программы, что позволяет выявить «остановы» в теле исполняемого модуля.

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