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

1) определение аномалий потока управления: «мертвого» (неисполняемого) [1] кода;

2) определение аномалий потока данных: побочного эффекта функций программного средства – изменения значений глобальных переменных в подпрограммах [1][2], неинициализированных переменных.

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

Введем основные соглашения и обозначения.

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

x – переменные;

v – выражения;

b – логические выражения;

Q – операторы;

C – списки операторов.

Пусть Х – множество всех возможных переменных, а Z – множество всех возможных значений переменных. Каждое из них может быть конечным или счетным. Неопределенное значение Λ также принадлежит Z: Λ ∈ Z.

Состояние памяти s определим как конечную функцию из Х в Z. Множество всех значений памяти обозначим через S, а его элементы – символами s, s1 и т. д. Множество S включает три подмножества состояний: Sл, Sн, S` – соответственно легитимное, нелегитимное и неустойчивое состояние (одновременное присутствие Sл и Sн).

Введем частичную функцию change:

Change: S × X × Z → S,

такую, что для всех s, s1, x и z:

s1 = change (s, x, z) ≡ s1 (x) = z & s =× s1.

Функция change описывает эффект изменения значения переменной х = z, когда машина находится в состоянии s. Эффект заключается в том, что переменной x теперь приписывается значение z, а значения остальных переменных не изменяются.

Семантическую структуру каждого оператора q представим в виде:

q = {fi; x1, …, xn; y1, …, ym}, (1)

где fi – одна из следующих функций (тип оператора):

function q:

x: = v → f1 (x, v);

b * q → f2 (b, q);

(C) → f3 (C).

f1, f2, f3 – выражения, определяющие желаемый результат в каждом случае;

x1, x2, …, xn – множество переменных, получающих новые значения при выполнении оператора q;

y1, y2, …, ym – множество переменных, используемых в операторе q и не изменяющих своего значения.

Условное выражение b может быть записано в виде:

(b → …

d → …).

Если b – истина, то результат берется из первой строчки, а в противном случае – из второй. Пустой оператор обозначим как Ω.

Опишем процесс вычисления программы в терминах модели-вычислителя [4][5]. В этой модели состояние машины не включает состояние «управление» как в модели-интерпретаторе. Состояние «управление», представляющее собой список операторов, которые предстоит выполнить после q, не влияет на семантику состояния si , получаемого в результате выполнения q. Модель определяется заданием функции, отображающей программу в ее вычислении. Под вычислением понимается конечная последовательность состояний памяти. Функция имеет следующий вид:

comp: S×Q → S* (S* = Sл ⋃ Sн ⋃ S`) (2)

comp: (s, Q) =

function Q:

Λ → (s`)

x: = v → (s; change (s, x, vs))

b * q → (bs → comp (s, Q),

d → (s))

(C) → comp (s, C)

Ω → (s).

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

Comp: S → S.

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

S = {Xд, Xз, Xи, Xп},

где Xд = {xд1, xд2, …, хдn} – множество контролируемых глобальных системных переменных по критерию доступа (системные адреса, таблицы данных и т. п.);

Xз = {xз1, xз2, …, хзm} – множество контролируемых глобальных системных переменных по критерию запуска (значения системных регистров, размера свободной оперативной и виртуальной памяти, появления дополнительных переменных программы и т. п.);

Xи = {xи1, xи2, …, хиw} – множество контролируемых глобальных системных переменных по критерию использования ресурсов среды;

Xп = {xп1, xп2, …, хпt} – множество переменных программы.

Операционное определение исследуемой программы дадим в терминах функции Comp от двух аргументов – текста программы и вектора состояния, представляющего текущее состояние вычислений. Кроме того, введем дополнительно следующие функции:

Подстановку значения в вектор состояния будем записывать следующим образом: если z – это значение, то вектор состояния s [x ← z] определяется как:

s [x ← z] {x} = z,

s [x ← z] {y} = s (y) для всех y ≠ x.

Смысл записи – «присвоить компоненте х вектора s значение z».

Функция Comp определяется для каждого из типов fi операторов:

Comp (x: = v, s) = s [x ← Znach (v, s)]; (3)

Comp (sл, sн; s) = Comp (sл, s) || Comp (Comp (sн, s), s);

Comp (s1; s2, s) = Comp (s1, s) || Comp (s2, End (Comp (s1, s))),

где || используется для обозначения конкатенации последовательностей состояний. Использование функцией Comp векторов состояний позволяет достаточно просто описать процесс функционирования программного средства.

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

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

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

План проведенного эксперимента:

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

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

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