On the Automatic Analysis of the Practical Resistance of Obfusting Transformations

Abstract

A method is developed for assessing the practical persistence of obfuscating transformations of programs based on the calculation of the similarity index for the original, obfuscated and deobfuscated programs. Candidates are proposed for similarity indices, which are based on such program characteristics as the control flow graph, symbolic execution time and degree of coverage for symbolic execution. The control flow graph is considered as the basis for building other candidates for program similarity indicators. On its basis, a new candidate is proposed for the similarity index, which, when calculated, finds the Hamming distance between the adjacency matrices of control flow graphs of compared programs. A scheme for estimating (analyzing) the persistence of obfuscating transformations is constructed, according to which for the original, obfuscated and deobfuscated programs, the characteristics of these programs are calculated and compared in accordance with the chosen comparison model. The developed scheme, in particular, is suitable for comparing programs based on similarity indices. This paper develops and implements one of the key units of the constructed scheme - a block for obtaining program characteristics compiled for the x86/x86 64 architecture. The developed unit allow to find the control flow graph, the time for symbolic execution and the degree of coverage for symbolic execution. Some results of work of the constructed block are given.

On Characteristics of Symbolic Execution in the Problem of Assessing the Quality of Obfuscating Transformations

“…В [11] предложена схема нахождения характеристик символьного исполнения, которые предполагается использовать для оценки эффективности обфусцирующих преобразований. В этом разделе кратко описывается эта схема, отмечаются некоторые особенности, связанные с шагами трансляции машинного кода в биткод LLVM, а также описывается упрощенная схема.…”

“…В соответствии с моделью [11], программа проходит следующие шаги: 1) компиляция с помощью обфусцирующего компилятора Hikari [16] с различными опциями обфусцирующих преобразований (выбраны 10 различных обфусцирующих преобразований), а также компиляция без применения преобразований; 2) построение графа потока выполнения скомпилированной программы с помощью инструмента mcsema-disass [17]; 3) трансляция полученного на предыдущем шаге представления в биткод LLVM c помощью инструмента mcsema-lift [17]; 4) оптимизация полученного биткода с помощью оптимизатора opt из состава LLVM; 5) символьное исполнение полученных версий биткода с помощью символьного интерпретатора KLEE [18]; 6) обработка полученных характеристик символьного исполнения. Последовательность шагов показана на рис.…”

“…В [11] предложена схема оценки стойкости запутывающих преобразований, основанная на сравнении признаков подобия, вычисленных по характеристикам программ. Основным блоком этой схемы является блок оценки стойкости, который делает вывод о сходстве программ.…”

“…Для этого необходимо иметь характеристики программы, описывающие ее с разных сторон анализа: при статическом анализе (структура графа потока управления, полнота дизассемблирования, понятность кода программы и другие) и при динамическом анализе (поведение программы во время выполнения). Для схемы из [11] набор характеристик, предложенных в [4][5][6][7][8], а также характеристик из области понимания программ [9] может быть построен путем статического анализа программы. В то же время собрать характеристики программы с помощью динамического анализа сложнее, так как требуется запустить программу и проанализировать ее поведение, которое может зависеть от среды исполнения и/или входных параметров.…”

“…Целью настоящей работы является, с одной стороны, получение и оценка характеристик символьного исполнения обфусцированной/деобфусцированной/исходной программ, с другой -оценка схемы получения характеристик символьного исполнения программ, построенной в [11]. Для оценки схемы рассматривается ее упрощенная версия, в которой отсутствуют шаги компиляции в бинарное представление и трансляции обратно в биткод LLVM [14].…”