Вы запутываете свой коммерческий Java-код?[закрыто]

StackOverflow https://stackoverflow.com/questions/12088

  •  08-06-2019
  •  | 
  •  

Вопрос

Интересно, использует ли кто-нибудь коммерческие / бесплатные java-обфускаторы в своем собственном коммерческом продукте.Я знаю только об одном проекте, который на самом деле имел запутывающий этап на этапе сборки ant для релизов.

Вы что-то путаете?И если да, то почему вы все запутываете?

Действительно ли это способ защитить код или это просто лучшее чувство для разработчиков / менеджеров?

Редактировать: Хорошо, я буду точен в своей точке зрения:Используете ли вы обфускацию для защиты своего IP-адреса (ваших алгоритмов, работы, которую вы вложили в свой продукт)?Я не буду запутывать по соображениям безопасности, это кажется неправильным.Итак, я говорю только о защите кода вашего приложения от конкурентов.

@стаффан в этом есть хороший смысл:

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

Это было полезно?

Решение

Если вы выполняете обфускацию, держитесь подальше от обфускаторов, которые модифицируют код, изменяя поток кода и / или добавляя блоки исключений и тому подобное, чтобы затруднить его разборку.Чтобы сделать код нечитаемым, обычно достаточно просто изменить все названия методов, полей и классов.

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

Другие советы

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

В настоящее время главное - защитить не какие-то алгоритмы, а конфиденциальные данные:Логины API / пароли / ключи, код, который отвечает за лицензирование (пиратство все еще здесь, особенно в Западной Европе, России, Азии, ИМХО), идентификаторы рекламных аккаунтов и т.д.

Интересный факт:у нас есть все эти конфиденциальные данные в виде строк.На самом деле Strings - это примерно 50-80% логики наших приложений.Мне кажется, что будущее запутывания - это "Инструменты шифрования строк".

Но теперь функция "Строкового шифрования" доступна только в коммерческих обфускаторах, таких как: Аллатори, Зеликс КлассМастер, Дымовая завеса, Инструментарий для обфускации Stringer Java, Дашо.

Н.Б.Я генеральный директор ООО "Лайсел".Разработчик Stringer Java Obfuscator.

Я использую proguard для разработки JavaME.Это не только очень хорошо позволяет уменьшить размер файлов jar (что важно для мобильных устройств), но и полезно как более приятный способ выполнения кода для конкретного устройства, не прибегая к недружественным для IDE инструментам предварительной обработки, таким как antenna.

Например.

public void doSomething()
{
    /* Generated config class containing static finals: */
    if (Configuration.ISMOTOROLA)
    {
        System.out.println("This is a motorola phone");
    }
    else
    {
        System.out.println("This is not a motorola phone");
    }
}

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

public void doSomething()
{
    System.out.println("This is a motorola phone");
}

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

Я полагаю, что некоторые коммерческие обфускаторы также могут в определенных случаях объединять файлы классов вместе.Это полезно, потому что чем больше у вас классов, тем больше размер накладных расходов в zip-файле (jar).

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

    if(i < ll1) goto _L6; else goto _L5
_L5:
    char ac[] = run(stop(lI1l));
    l7 = (long)ac.length << 32 & 0xffffffff00000000L ^ l7 & 0xffffffffL;
    if((int)((l7 & 0xffffffff00000000L) >> 32) != $5$)
    {
        l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
    } else
    {
        for(l3 = (long)III & 0xffffffffL ^ l3 & 0xffffffff00000000L; (int)(l3 & 0xffffffffL) < ll1; l3 = (long)(S$$ + (int)(l3 & 0xffffffffL)) ^ l3 & 0xffffffff00000000L)
        {
            for(int j = III; j < ll1; j++)
            {
                l2 = (long)actionevent[j][(int)(l3 & 0xffffffffL)] & 65535L ^ l2 & 0xffffffffffff0000L;
                l6 = (long)(j << -351) & 0xffffffffL ^ l6 & 0xffffffff00000000L;
                l1 = (long)((int)(l6 & 0xffffffffL) + j) & 0xffffffffL ^ l1 & 0xffffffff00000000L;
                l = (long)((int)(l1 & 0xffffffffL) + (int)(l3 & 0xffffffffL)) << 16 & 0xffffffff0000L ^ l & 0xffff00000000ffffL;
                l = (long)ac[(int)((l & 0xffffffff0000L) >> 16)] & 65535L ^ l & 0xffffffffffff0000L;
                if((char)(int)(l2 & 65535L) != (char)(int)(l & 65535L))
                {
                    l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
                }
            }

        }

    }

Вы не знали, что у Java есть goto?Ну, JVM их поддерживает =)

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

Я думаю, что по большей части запутывание бессмысленно:даже с полным исходным кодом, как правило, достаточно сложно понять, в чем, черт возьми, заключалось намерение (при условии, что нет комментариев и значимых имен для локальных переменных - что имеет место при повторной генерации источников из байтового кода).Запутывание просто украшает торт.

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top