Форум администраторов игровых серверов - Защита Java байт-кода шифрованием

- Java (https://forum.zone-game.info/forumdisplay.php?f=126)

- - Защита Java байт-кода шифрованием (https://forum.zone-game.info/showthread.php?t=14632)

Защита Java байт-кода шифрованием

На прошлой неделе довелось реверсить декстопную прогу на java от Microsoft. С виду обычный дистрибутив - папки bin/lib/tmp.

Первым делом бросилось в глаза - был только один jar файл: examengine.jar в папке bin с которого запускалась программа. В папке lib лежали несколько файлов jar и файл exam.exj.set содержащий в себе какие-то-то сериализованные данные.

Первым делом вскрыл examengine.jar. В нем оказались всего 3 привычных .class файла с нормальной сигнатурой (EClassLoader, ExamEnter, ESettings) и ещё несколько десятков .eclass с бинарными данными (ATable.eclass, EEngine.eclass, EEngine$Source.eclass, и так далее).

Первым делом запускаем наш любимый Java Decompiler и вскрываем файл ExamEnter и видим такую конструкцию

Код:

  private void loadMain() throws Exception {

    EClassLoader eclassloader = new EClassLoader();

    Class var_class = eclassloader

      .loadClass("com.mypai.examengine.ETestEngine");

    Object object = var_class.newInstance();

    Field field = var_class.getDeclaredField("examinatorTime");

    field.set(object, new Long(examinatorTime));

    Method method = var_class.getDeclaredMethod("createAndShowGUI", null);

    method.invoke(object, null);

  }

так как используемый ресурс класса ETestEngine находится в виде бинарных данных в ETestEngine.eclass то это означает что вся магия находится в EClassLoader.

Вскрываем EClassLoader.

Код:

final class EClassLoader extends ClassLoader

{

  Key ekey = getEKey();



  private static native Key getEKey();

  ....

}

и самое интересное - загрузка класса.

Код:

 private byte[] loadClassBytes(String string) throws IOException {

    String string_0_ = string.replace('.', '/') +  ".eclass";

    JarFile jarfile = new JarFile("./bin/examengine.jar");

    ZipEntry zipentry = jarfile.getEntry(string_0_);

    if (zipentry != null)

    {

      try {

        Cipher cipher = Cipher.getInstance("AES");

        cipher.init(2, this.ekey);

        CipherInputStream cipherinputstream = new CipherInputStream(  jarfile.getInputStream(jarfile.getEntry(string_0_)),  cipher);

        ByteArrayOutputStream bytearrayoutputstream = new ByteArrayOutputStream();

        int i;

        while ((i = cipherinputstream.read()) != -1)

        {

          bytearrayoutputstream.write(i);

        }

        cipherinputstream.close();



        is = bytearrayoutputstream.toByteArray();

      }

      catch (Exception exception)

      {

        exception.printStackTrace();

        return null;

      }

      return is;

    }

    return null;

  }

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

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

Таким образом у меня появилась идея создания относительно стойкой к декомиляции сборки дистрибутива:

1) Обычная компиляция исходных файлов в бинарники и нативных библиотек.
2) Формирование ключа AES / или любого другого алгоритма.
3) Шифрование всех class файлов за исключением загрузчика.
4) Обфускация классов загрузчика и оптимизация остальных классов.
5) Сборка jar-архива приложения с ключом.
6) Создание архива с дистрибутивом.

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

Сейчас несколько модифицированная система успешно работает на тестовом проекте.

Здесь мой копирайт (с)

P.S. Защитил диплом в этот вторник на "отлично" xD

Re: Защита Java байт-кода шифрованием

Цитата:

Сообщение от Aquanox (Сообщение 126777)

P.S. Защитил диплом в этот вторник на "отлично" xD

гц:)

а если все в exe файл запилить?

Re: Защита Java байт-кода шифрованием

А теперь внимание. Время на снятие данной защиты стремится к 0. Знать ключи при этом совершенно не обязательно. Увы, но данный механизм защиты (в прочем, как и любой другой механизм защиты байткода) малоэффективен. Причина - это Java, и рано или поздно придется передать нешифрованный байткод JVM. А данная защита еще плоха тем что не прикрывает одну критичную "дыру".
P.S. К тому же, данное решение затрудняет использование ваших jar в "легальных" целях, например для подключения их к IDE с целью своей разработки и получение нормального code-completition.
P.P.S. Боле эффективная защита (но опять же, не идеальная, т.к. Java есть Java) уже реализована, лишенная вышеперечисленных недостатков.

Re: Защита Java байт-кода шифрованием

Цитата:

Сообщение от Azagthtot (Сообщение 126829)

А теперь внимание. Время на снятие данной защиты стремится к 0. Знать ключи при этом совершенно не обязательно.

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

Цитата:

P.S. К тому же, данное решение затрудняет использование ваших jar в "легальных" целях, например для подключения их к IDE с целью своей разработки и получение нормального code-completition.

Этот метод используется для продуктов которые не подлежат изменению/модификации сторонними лицами (в примере была рассмотрено декстопное приложение). Если требуется возможность использования классов из зашифрованного JAR то это делается путем разделения на открытый API и закрытую реализацию (что успешно применяется в большинстве случаев).

Цитата:

P.P.S. Боле эффективная защита (но опять же, не идеальная, т.к. Java есть Java) уже реализована, лишенная вышеперечисленных недостатков.

Название?

Добавлено через 1 минуту

Цитата:

Сообщение от linliss (Сообщение 126781)

а если все в exe файл запилить?

Sayōnara кроссплатформенность

Re: Защита Java байт-кода шифрованием

Цитата:

Сообщение от Aquanox (Сообщение 126850)

Разговор идет о том, что вскрытие "без анализа кода". Т.е. какрой бы вы не изобретали ключ, какое бы шифрование не делали, механизм снятия будет один и тот же. Write once - run anymore :)

Цитата:

Если требуется возможность использования классов из зашифрованного JAR то это делается путем разделения на открытый API и закрытую реализацию (что успешно применяется в большинстве случаев).

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

Цитата:

Название?

CatsByteGuard. Используется лючерой, скорией, эмурт и некоторыми другими разработчиками. (не сочтите за саморекламу :D )

Re: Защита Java байт-кода шифрованием

Цитата:

Сообщение от Azagthtot (Сообщение 126862)

Write once - run anymore :)

* anywhere

Цитата:

CatsByteGuard

посмотрим.

Re: Защита Java байт-кода шифрованием

Не-не.. именно anymore (сколько угодно) в данном контексте. Это перефразировка.

Re: Защита Java байт-кода шифрованием

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

К примеру после старта приложения
1) запустить сканирование classpath на все файлы классов,
2) каждый найденный класс загружать в javassist.ClassPool ( ClassClassPath ), так как внутри приложения работает модифицированный ClassLoader то после ClassLoader#defineClass мы получим чистые классы.
3) и напоследок выгружать дампы в файлы CtClass#save

главное подобрать точку маунта для функции выполняющую дамп.

Во время работы открыл для себя много нового :]

P.S. Не пойму только смысл наименования jsr167.jar, по логике вещей который должен был ссылаться на jsr167. Только вот кому интересна Portlet Specification под Java 1.4.

Re: Защита Java байт-кода шифрованием

Вот по приведенному вами методу, а еще конкретнее с использованием механизма ClassTransformation снимается описанная вами защита. C CastByteGuard сложнее. Через ClassTransforamtion это не выйдет, на трансформацию передается шифрованный байткод.

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

А почему jsr167? Имя либы не имеет никакого отношения к SR, номер был взят "от балды".

P.S. Интесно, что нового открыли для себя? :)

Re: Защита Java байт-кода шифрованием

Цитата:

Сообщение от Azagthtot (Сообщение 126988)

А почему jsr167? Имя либы не имеет никакого отношения к SR, номер был взят "от балды".

ну я так и подумал.

Цитата:

и это тоже я понял. магия с ClassLoader не даст защиты от дампа. Зато сильная обфускация поможет частично от декомпиляции.

Добавлено через 4 минуты

Цитата:

Сообщение от Azagthtot (Сообщение 126988)

P.S. Интесно, что нового открыли для себя? :)

ну к примеру алгоритм работы. я бы не додумался шифровать тела методов.

К сожалению я не силен в реинженеринге dll, однако очень интересно узнать как работает jsr167.dll