CC BY
23Исследование атаки обфускацией на байт-код java-приложения с целью разрушения или повреждения цифрового водяного знака
Шариков Павел Иванович
соискатель ученой степени кандидата технических наук, аспирант кафедры защищенных систем связи Санкт-Петербургского университета телекоммуникаций им. проф. М.А. Бонч-Бруевича, г. Санкт-Петербург, Россия, sharikov.pavel@ro.ru.
АННОТАЦИЯ_
Введение: Язык программирования Java используется во многих сферах деятельности. Язык является кроссплатформен-ным, в следствии чего, легко поддающимся декомпиляции и обфускации. Для защиты исходного кода, разрабатываются различные методики, позволяющие произвести создание и вложение цифровых водяных знаков в исполняемые файлы. Цель исследования: целью исследования является проверка устойчивости вложенного в байт-код class-файла цифрового водяного знака. Анализ принципов обфускации java-приложений, а также применение инструментов обфускации для повреждения или уничтожения цифрового водяного знака. Методы: в данной работе исследуется устойчивость цифрового водяного знака, созданного и вложенного в class-файл на основе методики создания и вложения цифровых водяных знаков, разработанной ранее. Также, в работе используется разработанная методика для проведения атак обфускацией на class-файл с вложенным цифровым водяным знаком. Результаты: полученные результаты исследования обфускации class-файлов с цифровым водяным знаком и их последующей декомпиляции, позволяют сделать вывод о том, что методика атаки обфускацией не целесообразна для цифровых водяных знаков, основанных на структуре байт-кода. Результаты исследования демонстрируют незначительное изменение семантики байт-кода class-файла после его обфускации, что недостаточно для уничтожения цифрового водяного знака. Помимо этого, при применении данной методики обфускации, class-файл не поддается декомпиляции в силу запутанного обфускатором исходного кода и невозможностью работы с ним декомпилятором. Практическая значимость: Использование методики создания и вложения цифрового водяного знака на основе анализа структуры байт-кода гарантирует его устойчивость к атакам обфускацией. Обсуждение: необходимы дополнительные исследования для получения результатов устойчивости цифрового водяного от комбинированных атак различными инструментами.
КЛЮЧЕВЫЕ СЛОВА: байт-код; атака обфускацией; цифровой водяной знак; цвз; декомпиляция; java; обфускация.
Введение
На текущий момент, язык программирования Java один из самых популярных. С помощью данного языка программирования создано множество программных продуктов. Приложения на Java используются в сферах торговли, доставки товаров, банковской, телекоммуникационной, нефтегазовой и многих других. Язык программирования Java достаточно легко декомпилируется, в силу большого ряда причин. Одной из этих причин принято считать изначально заложенную в архитектуру языка программирования - кроссплатформен-ность.
На основе вышеизложенного следует, что если в силу принципов работы виртуальной машины Java, нельзя зашифровать файл, содержащий java-приложение, то необходимо защищать java-приложения и проходящие через них транзакции другими способами.
Существует множество различных инструментов обфускации для затруднения деком-пиляции и понимания байт-кода Java и, соответственно, получения исходного кода приложения. Большинство данных инструментов производят скремблирование имен идентификаторов хранящихся в байт-коде class-файлов путем замены идентификаторов бессмысленными именами. Однако данные инструменты можно использовать и для других целей. Таким образом, атаку обфускацией можно считать успешной, если она способна произвести обфускацию таким образом, чтобы работа java-приложения не нарушилась, но цифровой водяной знак был разрушен.
С помощью виртуальной машины Java, приложение компилируется в машинный код. Большая часть символьной информации отсекается при компиляции приложения. Идентификаторы, обозначающие переменные и функции в исходном коде становятся адресами в скомпилированном java-приложении. Обфускация преобразует читаемые и верный байт-код в более неясный байт-код.
В данной работе исследуется атака обфускацией на java-приложение, содержащее цифровой водяной знак. Используемые методики обфускации основаны на подходе чрезмерного использования идентификатора. Иными словами, идентификатор может одновременно обозначать несколько сущностей, таких как типы, поля или методы.
Критерии применяемые к цифровому водяному знаку
Ниже представлены критерии, которым должен удовлетворять цифровой водяной знак.
1. Цифровой водяной знак не должен изменять спецификацию программы, способ ее работы [1].
2. Должен иметься способ просмотра цифрового водяного знака в java-приложении. Однако способ извлечения. В идеальном варианте создание водяного знака проходит автоматически, также, как и его вложение в программу. В данном случае, наилучшим вариантом будет возможность автоматического декодирования цифрового водяного знака, для экономии времени и средств.
3. Цифровой водяной знак должен размещаться в java-приложении везде, где это возможно. Однако существует ряд ограничений. Функционал программы не должен быть изменен, ее графическое отображения для пользователя, быстродействие, а также размер занимаемого места на жестком диске [2].
4. Функционал для удаления, изменения, проверки или вложения водяного знака не может быть получен на основании функционала кодирования водяного знака.
5. Цифровые водяные знаки в java-приложении не должны уменьшать эффективность выполнения java-приложения. Так как есть приложения, которые крайне чувствительны к сокращению скорости работы, данное свойство вынесено в отдельный пункт.
6. Изменение или преобразование java-приложения не должно сказываться на цифровых водяных знаках. Злоумышленники могут дизассемблировать программу, а затем повторно произвести ее сборку. Водяные знаки должны быть надежно защищены от данного рода воздействий на программу [3].
Создание цифрового водяного знака
Процедура создания цифрового водяного знака состоит из трех фаз, показанных на рисунке 1.
Рис. 1. Процедура создания и вложения цифрового водяного знака
Фаза 1. Инъекция покрывающего метода
В первой фазе создания водяных знаков, используется поддельный метод (из класса), который никогда не будет выполняться, «присоединяется» к целевой начальной программе Java. Этот поддельный метод - пространство для ключевого слова водяного знака [4]. Содержимое фальшивого метода нас не волнует, но он должен иметь достаточный размер для инъекции водяного знака. Ниже представлен пример, демонстрирующий один из вариантов вызова метода:
if (Условие) fictitiousMethod();
«Условие» - это выражение, которое никогда не должно стать истинным. Таким образом, фиктивный метод практически никогда не вызывается. Практически, потому что все зависит от выражения (условия). Если условие достаточно сложное, то вызов метода никогда не произойдет, и пользователи программы не будут никогда осведомлены о фиктивном методе [5].
Фаза 2. Компиляция
Изначальная программа Java с вставкой фиктивного метода компилируется. Для этой фазы не важен компилятор. Вполне уместно использовать стандартный Java-компилятор.
Фаза 3. Инъекция водяного знака
В данной фазе необходимо обратить внимание на байт-код верификатор. Когда мы выполняем апплет Java, байт-код верификатор проверяет синтаксическую правильность кода и правильность использования типов в программе. Для того чтобы сохранить синтаксическую правильность и правильность использования типов в программе, необходимо использовать два следующих подхода [6].
Замена операционных кодов. Производится замена некоторых из опкодов: iadd,,ifnull,,and iflt, на другие операционные коды байт-кода с теми же свойствами. Замена опкода iadd опкодом isub не нарушает синтаксическую корректность и не создает ошибок использования. Кроме того, операционный код iadd может быть заменен любым опкодом среди isub, imul, idiv. Это указывает на то, что приведенные выше операционные коды в JVM являются взаимозаменяемыми [7,8]. Используя эту способность взаимной замены, мы можем кодировать 3 разрядную информацию в этих опкодах. Для примера можно присвоить 0002 для add, 0012 для isub, 0102 для imul, ..., и 1112 для ixor. Какой бы из перечисленных опкодов не появился в фиктивном методе, мы заменим его одним из указанных выше опко-дов, в зависимости от того какое количество бит мы хотим закодировать. Такое информационное присвоение и замена кода операции может быть также сделано для других операционных кодов [9].
Принцип обфускации java-приложения
В Java приложение состоит из одного или нескольких пакетов. Существует возможность разделить приложение на пакеты [10]. Часть программы, которая будет обфусцирова-на методиками обфускации, называются областью обфускации.
Варианты скремблинга идентификаторов
Согласно спецификации Java, идентификатор в программе Java может обозначать:
• пакет
• тип верхнего уровня (либо класс, либо интерфейс)
• вложенный тип (класс или интерфейс)
• поле
• метод
• параметр (метода, конструктора или обработчика исключений)
• локальная переменная
Только идентификаторы, обозначающие первые пять элементов в приведенном выше списке, хранятся в байт-коде. По умолчанию, параметры и локальные переменные удалены из байт-кода и стали памятью адреса массива локальных переменных в соответствующем стековом фрейме [11].
При запуске приложения виртуальная машина Java динамически загружает и связывает указанные типы со средой выполнения. Class-файл, в котором хранится указанный тип, находится по символической ссылке - полному имени класса или интерфейса. Данные символические ссылки не могут быть изменены [12]. Следовательно, будут обфусцированы
только кандидаты, которые ссылаются на сущности в области обфускации. Кандидаты, которые ссылаются на сущности за пределами области обфускации не должны обфусциро-ваться. Следующие четыре группы идентификаторов (иначе группы исключений) не должны маскироваться:
Группа исключений 1:
Метод экземпляра, реализующий абстрактный метод суперкласса (или суперинтерфейса), который выходит за рамки обфускации.
Группа исключений 2:
Метод экземпляра, который переопределяет унаследованный метод суперкласса, находящийся за пределами области обфускации.
Группа исключений 3:
Сущности, которые явно обозначены программистом, остаются неизменными.
Группа исключений 4:
Метод экземпляра, который служит функцией обратного вызова.
Основным методом является точка входа в java-приложение. Следовательно, название основного метода следует сохранить. Кроме того, проприетарная библиотека может экспортировать определенные типы и определенные методы как интерфейс библиотеки. Считается, что эти сохраненные объекты принадлежат к группе исключений 3. Механизм обратного вызова активно используется в случае модели библиотеки графического пользовательского интерфейса (GUI) Java. Когда вызывающий метод экземпляра N, обслуживающий функцию обратного вызова находится за пределами области обфускации, имя N не должно быть обфуцированно. В противном случае вызывающий метод не сможет найти метод N во время выполнения. С другой стороны, если вызывающий метод также находится в области обфускации, символическая ссылка может быть изменена на новую, обфуцированное имя N. В этом случае имя N может быть скрыто [13].
Определение того, является ли метод функцией обратного вызова является сложной задачей. Сначала необходимо построить граф вызовов изучив все java-приложение и все библиотеки, на которые есть ссылки. Через граф вызовов можно идентифицировать методы обратного вызова. Однако такая конструкция займет много времени. Как правило, class-файл, содержащий методы обратного вызова, реализует определенные интерфейсы или расширяет определенный класс. Вызывающий метод обратного вызова принимает параметр чей тип -суперинтерфейс или суперкласс. Фактический объект, содержащий метод обратного вызова, передается в качестве параметра и вызывается в методе обратного вызова через механизм полиморфизма. Основываясь на этом предположении, все методы обратного вызова, имена которых должны быть сохранены, будут принадлежать к группе исключений 1 или 2. Поля, статические методы и вложенные типы статически разрешаются компилятором Java [14]. Как только байт-код сгенерированный, виртуальной машиной Java не изменит разрешение.
Следовательно, имена полей, статических методов и вложенных типов, которые находятся в области обфускации, может быть изменено произвольно. Таким образом, цели
обфускации включают имена сущностей в области обфускации, кроме тех, что находятся в группах исключений 1, 2 и 3.
Методика атаки обфускацией
Основной подход к обфускации в данной работе - как можно более частое повторное использование идентификатора. Данный подход делает идентификатор сильно перегруженным и, следовательно, сбивает с толку злоумышленника. Идентификатор может обозначать несколько типов, полей, и методы одновременно, после обфускации. Когда обфуцированный байт-код декомпилируется, значение идентификатора определяется не только его именем, но и по контексту, в котором он существует. Злоумышленник сбит с толку, потому что он должен определить контекст, в котором идентификатор существует. Дополнительным преимуществом является то, что размер байт-кода сокращается, потому что имен используется меньше и они короче.
В java-приложении есть две иерархические структуры. Во-первых, это структура пакета. Приложение состоит из одного или нескольких пакетов. Пакет может содержат ноль или более подпакетов и типов верхнего уровня (т.е. классы и интерфейсы). Подпакеты и типы верхнего уровня в пакете не могут иметь одно и то же имя. Однако подпакет или тип верхнего уровня могут иметь то же имя, что и прилагаемый пакет. Предположим, что в инструменте обфускации используются последовательно сгенерированные идентификаторы. Генерацию идентификаторов можно перезапустить на каждый пакет, класс, метод, переменную [15].
Вторая структура - это структура наследования. Каждый класс, кроме класса Object, имеет прямой суперкласс. Класс может реализовывать ноль или более интерфейсов. Интерфейс может наследовать ноль или более интерфейсов. Интерфейс и класс неявно наследуют класс Object если они не наследуют никакие другие интерфейсы и другие классы соответственно. Глубина иерархии наследования не ограничена. Через структуру наследования существует возможность идентифицировать методы экземпляра, которые принадлежат к группам исключений 1 и 2. Данные методы экземпляра не будут переименованы. Кроме того, методы экземпляра, которые имеют преимущественные отношения и находятся в области обфускации, должны быть переименованы последовательно [16].
Структура пакетов и структура наследования интерфейсов показаны на рисунках 2 и 3. Затененная область обозначает область обфускации.
Базисный подход к атаке обфускацией состоит из следующих пяти шагов:
1. Анализ всех class-файлов, содержащих байт-код, которые находятся в области обфускации, создание структуру пакета и структуру наследования пакетов и классов [17].
2. Разбор структуры пакета от корня. Во время прохода по структуре пакета, используется последовательно сгенерированные имена для замены имен пакетов и имен типов верхнего уровня. Генерация имен перезапускается для каждого узла пакета. Для примера, предположим, что генерирующая последовательность имен - a, b, c..;
3. Далее необходимо при проходе по структуре наследования от корня к листу выполнить следующие шаги для каждого типа T.
Рис. 2. Структура пакетов java-приложения
Рис. 3. Структура интерфейсов java-приложения
3.1 Перезапуск генерации имен. Замена наименования всех полей с последовательно сгенерированными новыми именами.
3.2 Перезапуск генерации имен. Замена наименований всех вложенных типов с последовательно генерируемыми новыми именами. В данном случае, под типом понимается класс или интерфейс. Тип, который объявлен в другом типе, называется вложенным типом. Нет ограничений на глубину вложенности типов. Согласно спецификации языка Java, вложенный тип не мо-
жет иметь то же имя, что и любой из входящих в него типов. Следовательно, следует избегать имен, используемых вложенными типами.
3.3 Перезапуск генерации имен. Заменить имя метода М с последовательно генерируемыми новыми именами. Когда М - метод экземпляра, осуществить проверку, что М не принадлежит к группе исключений 1 или 2. Если да, то первоначальное наименование М должно остаться без изменений. В противном случае супертип S типа Т должен также быть в области обфускации. Если в S есть метод экземпляра N с той же исходной подписью, что и М, необходимо использовать то же имя N для М. В противном случае необходимо использовать новое сгенерированное имя для М. Необходимо обратить внимание, что новое сгенерированное имя не может совпадать с именем метода в S. Если это так, то это может привести к новому преобладающему отношению. Метод унаследованного экземпляра не может быть произвольно переопределен. В противном случае вызванный метод может неожиданно претерпеть изменения. Далее необходимо рекурсивно повторить шаги с 3а по 3с для каждого вложенного типа java-приложения.
4. Необходимо обновить все символьные ссылки в области обфускации измененными наименованиями [18].
5. Сохранить обфуцированный код в каждый class-файл байт-кода в области обфуска-
ции.
Сжатие структуры пакета
Обычно типы (классы и интерфейсы), предоставляющие связанные функции, группируются в пакет. Это цель введения структуры пакетов в Java. Пакеты помогают программистам организовывать свои программы. Однако пакеты также помогают злоумышленнику анализировать байт-код. Функции типов в пакете легче понять после того, как некоторые из них были проанализированы.
Другая цель структуры пакета - контролировать доступность элементов (т.е. полей, методов и вложенных типов) в типе объекта. Члены, объявленные как защищенные в типе T, могут быть доступны типам в том же пакете, к которому принадлежит T, и подтипам T. Члены, объявленные с доступом по умолчанию (то есть модификатор доступа не указан) в классе T, могут быть доступны типам в том же пакете, к которому принадлежит T.
Выравнивание структуры пакета заключается в том, чтобы объединить все типы, составляющие приложение, в один пакет. Злоумышленник не может использовать структуру пакета для взлома приложения. Хотя выравнивание структуры пакета расширит доступный диапазон защищенных участников и участников с доступом по умолчанию для всего java-приложения. Расширение доступного диапазона в байт-коде, а не в исходном коде, не изменит поведение приложения. Компилятор Java уже проверил доступность членов. Хотя виртуальная машина Java снова проверит доступность при запуске приложения, на поведение программы это не повлияет.
Проблема динамической загрузки
Java поддерживает динамическую загрузку и reflection API. С помощью метода Class.forName («MyClassName») витуальная машина Java может загружать именованный класс во время выполнения. Имя класса может быть определено во время выполнения. Поэтому мы не можем определить, следует ли сохранить имя типа или изменить значение па-
раметра с помощью статического анализа во время проведения обфускации. Поэтому имена типов, которые будут динамически загружаться, следует сохранить и указать вручную.
Члены динамически загружаемого типа нуждаются в дальнейшем исследовании. Большинство методов в классе - Class возвращают открытые члены динамически загружаемого типа. В связи с этим открытые члены динамически загружаемого типа не следует переименовывать. Могут быть шансы использовать защищенные и доступные по умолчанию члены динамически загружаемого типа посредством Reflection API. Такая ситуация случается редко и должна рассматриваться как проблемная. Тем не менее, защищенные и доступные по умолчанию члены динамически загружаемого типа не следует переименовывать. Только закрытые члены динамически загружаемого типа могут быть переименованы произвольно.
Недопустимые идентификаторы
Идентификатор должен быть буквой, за которой следуют буквы или цифры. Идентификатор не может быть идентичен ключевому слову, логическому литералу или нулевому литералу. Эти правила помогают лексическому анализатору и синтаксическому анализатору анализировать программу. Однако эти правила не обязательно должны соблюдаться в байт-коде. Обратите внимание, что, когда виртуальная машина Java загружает байт-код, она не проверяет, соответствуют ли имена в пуле констант определению идентификатора. Поэтому имена в пуле констант байт-кода могут быть изменены для использования недопустимых символов, ключевых слов, логических литералов или нулевого литерала. Когда обфуциро-ванный байт-код декомпилируется, а затем компилируется, эти недопустимые идентификаторы приведут к ошибкам компиляции.
Например, существует возможность переименовать идентификатор в байт-коде в логический литерал «false» или символ «<>?!#». Измененный байт-код по-прежнему работает. Однако декомпиляторы столкнутся с проблемами из-за этого изменения. Проведем тестирование.
Многие декомпиляторы используют JAD [19-20] в качестве механизма декомпиляции и добавляют свои собственные пользовательские интерфейсы. Для эксперимента выбраны только декомпиляторы, основанные на различных механизмах декомпиляции. Результат показан в таблице 1. JAD и jAscii адаптивнее других при обработке ключевых слов в качестве идентификаторов. Они автоматически меняют идентификатор ключевого слова на обычный идентификатор. Другие декомпиляторы используют ключевое слово в качестве имени идентификатора непосредственно в декомпилированной программе. С другой стороны, все протестированные декомпиляторы обмануты незаконным символом. JReverse Pro и Jode даже не могут декомпилировать измененный байт-код.
Не все символы могут использоваться в качестве идентификатора или в качестве идентификатора в пуле констант. Некоторые символы имеют особое значение для виртуальной машины Java и для хост-системы. Все конструкторы типа называются «<init>» в байт-коде. Поэтому при запутывании следует избегать имени «<init>». В противном случае виртуальная машина Java может быть сбита с толку при вызове конструктора. Символ «<clinit>» - это имя статического инициализатора типа. JVM вызовет его для инициализации статических членов типа.
Переименование идентификаторов в байт-коде, работа с декомпиляторами
Использованное ключе- Использованные недопу-
Декомпилятор вое слово в качестве стимые символы в иден-
идентификатора тификаторах
JAD «_field_false» «< 3Е 3F 21 23 »
jAscii «_field_false» «*Л%< >?!#»
Mocha «false» «*л%< >?!#»
deClassify «false» «*л%< >?!#»
JReverse Pro «false» ОШИБКА
ClassSpy «false» «*л%< >?!#»
Jode «false» ОШИБКА
Символы «/», «п» и «:» не должны использоваться в имени типа. Эти три символа используются в качестве разделителей путей в файловых системах хоста на разных платформах. В настоящее время большинство реализаций системы выполнения Java используют файловую систему хоста для хранения файлов байт-кода. Единственное известное исключение - это IBM VisualAge для Java, которая использует систему баз данных (называемую ENVY) для управления файлами байт-кода. Если в именах типов используются данные три символа, а типы хранятся в файловой системе хоста, эти разделители заставят JVM неверно интерпретировать типы. Символ «$» используется в качестве разделителя типа и его вложенных типов. Произвольное использование «$» в имени идентификатора может привести к некоторым неожиданным результатам. Однако его можно умело использовать для введения другого вида защиты.
Заключение
К инструментам обфускации предъявляется ряд требований. Таких как:
• Сохранение семантики байт-кода
• Стойкость к действиям злоумышленника, как можно большее количество времени
• Стойкость к взлому извне
• Как минимум, сохранение объема class-файла на прежнем уровне
• Возможность повышения эффективности исполнения байт-кода java-приложения
Исследуемая в данной работе методика атаки обфускацией на байт-код java-приложения удовлетворяет указанным выше требованиям, однако, в большинстве случаев семантика байт-кода сохраняется и остается неизменной, что в свою очередь гарантирует устойчивость цифрового водяного знака к атакам подобного рода. Сохранение семантики байт-кода при атаке обфускацией на байт-код java-приложения - является темой для дальнейшего исследования.
Многие методики делают декомпилированную java-программу некомпилируемой. Эффекты обфускации не могут быть легко устранены другими инструментами взлома. Злоумышленник должен потратить много времени и ресурсов на отладку декомпилированной программы с ошибками вручную.
Основная цель методик обфускации, предложенных в статье, состоит в том, чтобы разрушить цифровой водяной знак в java-приложении. Исследование продемонстрировало, что
предложенные методики не справляются с поставленными задачами и наоборот, выдерживают только критерии направленные на сохранение семантики и правильности байт-кода, что в свою очередь гарантирует сохранность и устойчивость цифрового водяного знака java-приложения.
Литература
1. Шариков П.И., Красов А.В., Штеренберг С.И. Методика создания и вложения цифрового водяного знака в исполняемые java файлы на основе замен опкодов // T-Comm: Телекоммуникации и транспорт. Т.11. 2017. №3. С. 66-70.
2. Герлинг Е. Ю., Ахрамеева К. А. Обзор современного программного обеспечения, использующего методы стеганографии // Экономика и качество систем связи. 2019. №. 3 (13). С. 51-58.
3. Штеренберг С.И., Полтавцева М.А. Распределенная система обнаружения вторжений с защитой от внутреннего нарушителя // Проблемы информационной безопасности. Компьютерные системы. 2018. № 2. С. 59-68.
4. Shterenberg S.I., Krasov A.V., Ushakov I.A. Analysis of using equivalent instructions at the hidden embedding of information into the executable files // Journal of Theoretical and Applied Information Technology (ISSN19928645-Pakistan-Scopus) 2015. Т. 80. № 1. P. 28-34.
5. Andrey Vladimirovich Krasov, Aleksander Sergeevich Arshinov and Igor Aleksandrovich Ushakov. Embedding the hidden information into java byte code based on operands' interchanging // ARPN Journal of Engineering and Applied Sciences April 2018. Vol. 13. No. 8.
6. Красов А.В., Штеренберг С.И. Разработка методов защиты от копирования ПО на основе цифровых водяных знаков внедряемых в исполняемые и библиотечные файлы // В сборнике: Актуальные проблемы инфотелекоммуникаций в науке и образовании II Международная научно-техническая и научно-методическая конференция. 2013. С. 847-852.
7. Sharikov P.I., Krasov A.V., Shterenberg S.I. (2017). Method of creation and attachments digital watermark into an executable Java file by means of substitutions opcode. T-Comm, vol. 11. no.3. pр. 66-70
8. Шариков П.И., Красов А.В., Штеренберг С.И. Методика создания и вложения цифрового водяного знака в исполняемые java файлы на основе замен опкодов // T-Comm: Телекоммуникации и транспорт. Т.11. 2017, №3. С. 66-70.
9. Красов А. В., Верещагин А. С., Цветков А. Ю. Аутентификация программного обеспечения при помощи вложения цифровых водяных знаков в исполняемый код // Телекоммуникации. 2013. № S7. С. 27-29.
10. Шариков П.И., Красов А.В., Иванов А.В., Исследование возможностей методики скрытого вложения цифрового водяного знака в class-файлы на виртуализированных платформах с отличающейся архитектурой // Вестник СПб университета ГПС МЧС России. 2018. № 2. С. 79-88.
11. Хомяков И. Н., Красов А. В. Возможность скрытого вложения информации в байт-код java // Информационные технологии моделирования и управления. 2014. № 2 (86). С. 185-191.
12. Коржик В. И., Небаева К. А., Герлинг Е. Ю., Догиль П. С., Федянин И.А. Цифровая стеганография и цифровые водяные знаки / Под общей редакцией профессора В.И. Коржика. СПб.: СПбГУТ. 2016. 226 с.
13 Красов А. В. и др. Алгоритмы и методы защиты программного кода на базе обфускации // I-methods. 2020. Т. 12. №. 1. С. 1-12.
14. Sharikov P. I. et al. Research of the possibility of hidden embedding of a digital watermark using practical methods of channel steganography // International Symposium on Intelligent and Distributed Computing. - Springer. Cham. 2019. С. 203-209.
15. Sharikov P. I., Krasov A. V., Volkogonov V. N. A study of the correctness of the execution of a class file with an embedded digital watermark in different environments // IOP Conference Series: Materials Science and Engineering. IOP Publishing. 2020. Т. 862. №. 5. С. 052052.
16. Andrey K., Pavel S. A Technique for Analyzing Bytecode in a Java Project for the Purpose of an Automated Assessment of the Possibility and Effectiveness of the Hidden Investment of Information and its Volumes in a Java Project // 2020 12th International Congress on Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT). IEEE. 2020. С. 258-263.
17. Свидетельство 2020617872. Анализатор байт-кода java - программы для скрытого вложения цифрового водяного знака посредством автоматического редактирования байт-кода class-файла : программа для ЭВМ / А. В. Красов, А. И. Пешков, П. И. Шариков (RU) ; правообладатель Федеральное государственное бюджетное образовательное учреждение высшего образования «Санкт-Петербургский государственный университет телекоммуникаций им. проф. М.А. Бонч-Бруевича» (СПбГУт) (RU). №2020616770; заявл. 29.06.2020 : опубл. 15.07.2020, Бюл. № 7, 30 Кб.
18. Свидетельство 2020664301. Модификатор байт-кода java-программы для скрытого вложения цифрового водяного знака посредством автоматического редактирования байт-кода class-файла : программа для ЭВМ / Красов Андрей Владимирович (RU), Пешков Андрей Иванович (RU), Шариков Павел Иванович (RU), Жиркова Галина Петровна (RU); правообладатель Федеральное государственное бюджетное образовательное учреждение высшего образования «Санкт-Петербургский государственный университет телекоммуникаций им. проф. М.А. Бонч-Бруевича» (СПбГУТ) (RU). № 2020663386; заявл. 30.10.2020 : опубл. 11.11.2020, Бюл. № 11, 20 Кб.
19. Harrand N. et al. The strengths and behavioral quirks of Java bytecode decompilers // 2019 19th International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE. 2019. С. 92-102.
20. Harrand N. et al. Java decompiler diversity and its application to meta-decompilation //Journal of Systems and Software. 2020. Т. 168. С. 110645.
INVESTIGATION OF AN OBFUSCATION ATTACK ON THE BYTECODE OF A JAVA APPLICATION IN ORDER TO DESTROY OR DAMAGE A DIGITAL WATERMARK
PAVEL I. SHARIKOV
Doctoral Student. Postgraduate at the Department of Protected Communication Systems of St. Petersburg University of Telecommunications. prof. M.A. Bonch-Bruevich.
St. Petersburg, Russia, sharikov.pavel@ro.ru
ABSTRACT
Introduction: The Java programming language is used in many fields of activity. The language is cross-platform, which makes it easy to decompile and obfuscate. To protect the source code, various techniques are being developed to create and embed digital watermarks in executable files. Problem statement: the purpose of the study is to test the stability of the digital watermark class file embedded in the bytecode. Analysis of the principles of obfuscation of java applications, as well as the use of obfuscation tools to damage or destroy a digital watermark. Methods: This paper investigates the stability of a digital watermark created and nested in a class file based on the digital watermark creation and nesting methodology developed earlier. Also, the work uses the developed technique for carrying out obfuscation attacks on a class file with an embedded digital watermark. Results: The obtained results of the study of obfuscation of class files with a digital watermark and their subsequent decompilation allow us to conclude that the ob-fuscation attack technique is not appropriate for digital watermarks based on the bytecode structure. The results of the study demonstrate a slight change in the semantics of the class file bytecode after its obfuscation, which is not enough to destroy the digital watermark. In addition, when applying this obfuscation technique, the class file cannot be decompiled due to the source code obfuscated by the obfuscator and the impossibility of working with it by the decompiler. Practical significance: Using the technique of creating and embedding a digital watermark based on the analysis of the bytecode structure guarantees its resistance to obfuscation attacks. Discussion: More research is needed to obtain results of digital watermark resilience against combined attacks by different tools.
Keywords: bytecode; obfuscation attack; digital watermark; color; decompilation; java; obfuscation.
REFERENCES
1. Sharikov P.I., Krasov A.V., Shterenberg S.I. The method of creating and embedding a digital watermark in executable java files based on opcode substitutions. T-Comm: Telekommunikacii i transport [T-Comm: Telecommunications and transport]. T.11, 2017, No. 3. pp. 66-70. (In Rus)
2. Gerling E. Yu., Akhrameeva K. A. Overview of modern software using steganography methods. Jekonomika i kachestvo sis-tem svjazi [Economics and quality of communication systems]. 2019. №. 3 (13). C. 51-58. (In Rus)
3. Shterenberg S.I., Poltavtseva M.A. Distributed intrusion detection system with internal intruder protection. Problemy infor-macionnoj bezopasnosti. Komp'juternye si-stemy [Problems of information security. Computer systems]. 2018. No. 2. S. 59-68. (In Rus)
4. Shterenberg S.I., Krasov A.V., Ushakov I.A. Analysis of using equivalent instructions at the hidden embed-ding of information into the executable files // Journal of Theoretical and Applied Information Technology (ISSN19928645-Pakistan-Scopus) 2015. T. 80. № 1. P. 28-34
5. Andrey Vladimirovich Krasov, Aleksander Sergeevich Arshinov and Igor Aleksandrovich Ushakov. Embedding the hidden information into java byte code based on operands' interchanging // ARPN Journal of Engineering and Applied Sciences April 2018. Vol. 13. No. 8
6. Krasov A.V., Shterenberg S.I. Development of software copy protection methods based on digital watermarks embedded in executable and library files. V sbornike: Aktu-al'nye problemy infotelekommunikacij v nauke i obrazovanii II Mezhdunarodnaja nauchno-tehnicheskaja i nauchno-metodicheskaja konferencija [In the collection: Actual problems of infotelecommunications in science and education II International scientific-technical and scientific-methodical conference]. 2013. S. 847-852. (In Rus)
7. Sharikov P.I., Krasov A.V., Shterenberg S.I. (2017). Method of creation and attachments digital watermark into an executable Java file by means of substitutions opcode. T-Comm, vol. 11, no.3, pp. 66-70
8. Sharikov P.I., Krasov A.V., Shterenberg S.I. The method of creating and embedding a digital watermark in executable java files based on opcode substitutions. T-Comm: Telekommunikacii i transport [T-Comm: Telecommunications and transport]. T.11, 2017, No. 3. pp. 66-70. (In Rus)
9. Krasov A. V., Vereshchagin A. S., Tsvetkov A. Yu. Software authentication by embedding digital watermarks in the executable code. Telekommunikacii [Telecommunications]. 2013. No. S7. pp. 27-29. (In Rus)
10. Sharikov P.I., Krasov A.V., Ivanov A.V., Investigation of the possibilities of the method of hidden embedding of a digital watermark in class-files on virtualized platforms with different architecture. Vestnik SPb universiteta GPS MChS Rossii [Bulletin of St. Petersburg University of the State Fire Service of the Ministry of Emergency Situations of Russia]. 2018. No. 2. S. 79-88 (In Rus)
11. Khomyakov I. N., Krasov A. V. Possibility of hidden embedding of information in java bytecode. Informacionnye tehnologii modelirovanija i upravlenija [Information technologies of modeling and control]. 2014. No. 2 (86). pp. 185-191. (In Rus)
12. Korzhik V. I., Nebaeva K. A., Gerling E. Yu., Dogil P. S., Fedyanin I. A. Cifrovaja steganogra-fija i cifrovye vodjanye znaki [Digital steganography and digital watermarks] / Under the general editorship of Professor V.I. Korzhika. SPb.: SPbGUT. 2016. 226 p. (In Rus)
13. Sharikov P.I., Krasov A.V., Exploring the vulnerability of data serialization and deserialization in Java. Regional'naja informat-ika i informacionnaja bezopasnost'. Sbornik nauchnyh trudov. Sankt-Peterburgskoe Obshhestvo informatiki, vychislitel'noj tehniki, sistem svjazi i upravlenija. Trudy RIIB [Regional Informatics and Information Security. Collection of scientific papers. St. Petersburg Society for Informatics, Computer Engineering, Communication and Control Systems. Proceedings of the RIIB] 2017. 3rd edition. (In Rus)
14. Sharikov P. I. et al. Research of the possibility of hidden embedding of a digital watermark using practical methods of channel steganography //International Symposium on Intelligent and Distributed Computing. - Springer, Cham, 2019. - C. 203-209.
15. Sharikov P. I., Krasov A. V., Volkogonov V. N. A study of the correctness of the execution of a class file with an embedded digital watermark in different environments //IOP Conference Series: Materials Science and Engineering. - IOP Publishing, 2020. - T. 862. - №. 5. - C. 052052.
16. Andrey K., Pavel S. A Technique for Analyzing Bytecode in a Java Project for the Purpose of an Automat-ed Assessment of the Possibility and Effectiveness of the Hidden Investment of Information and its Volumes in a Java Project //2020 12th International Congress on Ultra Modern Telecommunications and Con-trol Systems and Workshops (ICUMT). - IEEE, 2020. - C. 258-263.
17. Certificate 2020617872. Analizator bajt-koda java - programmy dlja skrytogo vlozhe-nija cifrovogo vodjanogo znaka posredstvom avtomaticheskogo redaktirovanija bajt-koda class-fajla : programma dlja JeVM [Java bytecode analyzer - programs for hidden embedding of a digital watermark by automatically editing class-file bytecode: computer program]. A. V. Krasov, A. I. Peshkov, P. I. Sharikov (RU) ; copyright holder Federal State Budgetary Educational Institution of Higher Education "St. Petersburg State University of Telecommunications. prof. M.A. Bonch-Bruevich (SPbSUT) (RU). No. 2020616770; dec. 06/29/2020 : publ. 07/15/2020, Bull. No. 7, 30 Kb. (In Rus)
18. Certificate 2020664301. Modifikator bajt-koda java-programmy dlja skrytogo vlozhe-nija cifrovogo vodjanogo znaka posredstvom avtomaticheskogo redaktirovanija bajt-koda class-fajla : programma dlja JeVM [Java program bytecode modifier for hidden embedding of a digital watermark by automatically editing the class file bytecode: computer program]. Krasov An-drey Vladimirovich (RU), Peshkov Andrey Ivanovich (RU), Shari- kov Pavel Ivanovich (RU), Zhirkova Galina Petrovna (RU); Federal State Budgetary Educational Institution of Higher Education "St. Petersburg State University of Telecommunications named after V.I. prof. M.A. Bonch-Bruevich (SPbSUT) (RU). No. 2020663386; dec. 10/30/2020 : publ. 11/11/2020, Bull. No. 11, 20 Kb. (In Rus)
19. Harrand, N., Soto-Valero, C., Monperrus, M., & Baudry, B. (2019, September). The strengths and behavioral quirks of Java bytecode decompilers. In 2019 19th International Working Conference on Source Code Analysis and Manipulation (SCAM) (pp. 92102). IEEE.
20. Harrand N. et al. Java decompiler diversity and its application to meta-decompilation //Journal of Systems and Software. -2020. - T. 168. - C. 110645.
