Ну вот новая тема.
А как мне точно определить обфусцировали или нет?

http://mindprod.com/jgloss/obfuscator.html

Каким декомпилятором мне воспользоваться?
Я тут jad из интернета скачала, пойдет?

Всем СПАСИБО ,
код они не обфусцировали, jad.exe работает хорошо так что все получилось.

Цитата(kashka @ 3.3.2005, 12:15)

Я тут jad из интернета скачала, пойдет?

Вполне. Очень неплохая тулза. Но против обфускаторов не потянет само собой

А чем можно воспользоваться для обс... офс... обфуксации? Там много ссылок, но чем пользуются специалисты?

jad.exe декомпилирует вроде нормально, вот только внутренних классов не видет, знает кто нибудь еще декомпиляторы?

Ошиблась внутренние классы он все таки видет

kashka
Mocha - старый декомпилятор раньше был... поищи - может, где и остался, вдруг, он поможет?

P.S. А мне бы кто бы обфускатор посоветовал бесплатный?..

Смотреть тут:
http://java-source.net/open-source/obfuscators
(tnx to Domestic Cat )
Сам лично пользовался RetroGuard-ом

Пользую jad, вроде работает

Цитата(Domestic @ 3.3.2005, 18:30)

Пользую jad, вроде работает

Так jad - это декомпилятор или обфускатор? Или и то, и другое?

я не пользовал - но вроде тока декомпилятор...

Цитата(Lamer @ 3.3.2005, 18:35)

Так jad - это декомпилятор или обфускатор?

Это просто декомпилятор. Просто преобразует байт-код в код на java.

Обфускатор по сути "запутывальщик". Он преобразует код в запутанную систему внутренних классов, методов. И после декомпиляции перед глазами эдакий монстр, разобраться в работе которого крайне сложно. Дешевле становиться купить нужный пакет с исходниками

Цитата(Lamer @ 3.3.2005, 18:35)

Так jad - это декомпилятор или обфускатор? Или и то, и другое?

jad - декомпилятор...
JODE - обфускатор

Цитата(AntonSaburov @ 3.3.2005, 18:40)

Обфускатор по сути "запутывальщик".

Значит, это все-таки не абсолютная защита, да? Он не закрывает код, а старается изменить его до неузнаваемости, и, зная алгоритмы его работы и ключи (если он их использует), можно раскрыть код. Получается, что задача "деобфускации" - это криптоатака?

Цитата

Пользую jad, вроде работает

это я к

Цитата

jad.exe декомпилирует вроде нормально, вот только внутренних классов не видет, знает кто нибудь еще декомпиляторы?

Абсолютной защиты не будет никогда.

Цитата(Lamer @ 3.3.2005, 18:50)

Получается, что задача "деобфускации" - это криптоатака?

Нет, это больше напоминает, что первоначальный маршрут от Питера до Москвы шел напрямую, но его выдали в виде "через Владивосток". При этом заменяются имена классов и методов на абсолютно бессмысленные - a1, b32, f4 и так далее.

Ну предположим у класса есть 25 методов из них 18 закрыты. Можно изменить имена этих методов. Можно сделать промежуточный класс, который будет создаваться и уже внутри себя вызывать нужный метод. Можно вырезать какие-то методы в отдельный класс, назвать его страшно непонятным именем. Ну и прочая. Т.е. получается код. который читать можно, но понимать который (и вносить какие-либо изменения) приносит головной боли столько, что это никто делать не будет. Разве что за большие-большие деньги, которые будут сравнимы со стоимостью пакета.

я тут еще один декомпилятор нашла, может пригодится кому нибудь:
http://members.fortunecity.com/neshkov/dj.html

Цитата

Значит, это все-таки не абсолютная защита, да? Он не закрывает код, а старается изменить его до неузнаваемости, и, зная алгоритмы его работы и ключи (если он их использует), можно раскрыть код. Получается, что задача "деобфускации" - это криптоатака?

Нет, обфускатор делает код практичски бессмысленным для того, кто его декомпилит. И знаниe алгоритмa нe поможет, т.к. будут уничтожны все несущие смысл именa переменных, классов, и пр. А без этого понять как работаеt код сложновато.

Ясно. Спасибо за разъяснения.

Насчет jad (и других тоже), он то в принципе работает, вот только иногда try/catch не распознает и странние конструкции такого вида создает:

Код

buf = new byte[256]; _L2:        if(conn != null || port >= 9940)            break; /* Loop/switch isn't completed */        conn = new Socket("localhost", port);        BufferedInputStream in = new BufferedInputStream(conn.getInputStream());        BufferedOutputStream out = new BufferedOutputStream(conn.getOutputStream());        buf[0] = 63;        out.write(buf);        out.flush();        Thread.sleep(50L);        if(in.available() <= 0)            break MISSING_BLOCK_LABEL_113;        in.read(buf, 0, 256);        if(buf[0] == 33)            return conn;        continue; /* Loop/switch isn't completed */        return null;        IOException exception;        exception;        port = 9940;        continue; /* Loop/switch isn't completed */        exception;        port++;        if(true) goto _L2; else goto _L1 _L1:

Цитата(Lamer @ 3.3.2005, 18:50)

Значит, это все-таки не абсолютная защита, да? Он не закрывает код, а старается изменить его до неузнаваемости, и, зная алгоритмы его работы и ключи (если он их использует), можно раскрыть код. Получается, что задача "деобфускации" - это криптоатака?

В том то и проблемма байт кода что его можно однозначно декомпилировать. То есть абсолютной защиты для байт кода как таковой нет.
Ключей при обфускации нет. нО криптоатака деобфускации не поможет
Тут такой момент. В процессе обфускации происходит 3-и основных действия:
1. Удаяляется дебаговая информация (это может быть пропущенно если компилировалось без нее)
2. переименовываеются классы, методы и переменные (за некоторым исключением, связонные с рефлексией). То есть:

Код

class Foo {    private String fooStr;    public String fooFunction()    {         return fooStr;    } }

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

Код

class if {    private String for;    public String if()    {         return for;    } }

или

Код

class а {    private String а;    public String а()    {         return а;    } }

Что будет затруднять разбор программы.

3. добавляются "логические бомбы" (это делают не все обфускаторы).
к примеру самая простая логическая бомба:

Код

class if {    private String for;    public String if()    {         return for;    } }

->

Код

class if {    private String for;    public String if()    {         return for;         catch(e)         {         }    } }

Катч вставлен в данном случае в байт код после ретурна (точнее вставленна последовательность инструкций, которая обозначет катч). При работе программы она никак на будет влиять на выполнение данной функции. При декомпиляции же не всякий декомпилятор сможет это "переварить".
Добавлено @ 19:13

Цитата(kashka @ 3.3.2005, 19:07)

Насчет jad (и других тоже), он то в принципе работает, вот только иногда try/catch не распознает и странние конструкции такого вида создает:

jad - работает как декомпилятор. как обфускатор не работает

Я имею ввиду что, после декомпиляции появляются иногда странные структуры,
например:

Код

return true;        Exception exception;        exception;        new HuginGUIError(exception);        return false;

а
Добавлено @ 19:21
я так думаю, что jad try/catch иногда в такои форме записивает. По краинеи мере после соответствующего исправления, все работало .

Там просто неоднозначная ситуация. И поэтому не до конца переводится в ява код.
По этому поводу советую почитать Работем с Байткодом (с)Domestic Cat.

В каком смысле неоднозначная?

try/catch при компиляции превращается в несколько запутанный байткод, видимо декомпилер и колбасит по этому поводу

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

Добавлено @ 19:42
ЗЫ. Кстати. Внешне катч в байт коде выглядит еще более запутанно
Так что неоднозначностей там хватает.

Ну ладно try/catch можно легко исправить а вот что означает:

Код

if(rootFrame == null || !rootFrame.containsInstances())            break MISSING_BLOCK_LABEL_104;        int answer = JOptionPane.showConfirmDialog(this, "This network contains instances of other networks.\nDo you want all instance networks to be reloaded as well?", "Reload subnets?", 0, 3, null);        if(answer != 0)            break MISSING_BLOCK_LABEL_73;

Цитата(AntonSaburov @ 3.3.2005, 18:56)

При этом заменяются имена классов и методов на абсолютно бессмысленные - a1, b32, f4 и так далее.

А как же библиотеки???

Цитата

А как же библиотеки???

Паблик интерфейс и обращения к внешнним библиотекам не обфусцируются, иначe ничего б нe работало.

Цитата(DarkDS @ 3.3.2005, 19:10)

В том то и проблемма байт кода что его можно однозначно декомпилировать.

Не совсем, дезасемблирровать да, а вот с декомпиляцией не все так просто. Где то я читал статейку, в которой мужик показал, что не всякий байткод соответствует Java программе. И есть вещи реализуемые на ассемблере для JVM и не реализуемые на Java.

Цитата(kashka @ 3.3.2005, 19:49)

Ну ладно try/catch можно легко исправить а вот что означает:

Тут надо смотреть дизасемблированный код и пытаться его восстановить. Получить его можно jad -dis. Если метод не очень большой то можно попробовать.

P.S. Кстати мы тут все обсуждаем не совсем законную тему, но, учитывая что мы делаем это только с теоретической точки зрения, все в порядке

Цитата(LSD @ 3.3.2005, 22:00)

Не совсем, дезасемблирровать да, а вот с декомпиляцией не все так просто. Где то я читал статейку, в которой мужик показал, что не всякий байткод соответствует Java программе. И есть вещи реализуемые на ассемблере для JVM и не реализуемые на Java.

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

Добавлено @ 22:28

Цитата(LSD @ 3.3.2005, 22:00)

P.S. Кстати мы тут все обсуждаем не совсем законную тему, но, учитывая что мы делаем это только с теоретической точки зрения, все в порядке

ЗЫ. Я кстати обсуждаю вполне законную - как защитить код с помощью обфускации
Добавлено @ 22:29

Цитата

А как же библиотеки???

А это как раз и есть рефлексия

Цитата(DarkDS @ 3.3.2005, 22:27)

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

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

Цитата

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

Пo-моему эта штука "взрывала" первую Mocha?

Цитата(LSD @ 3.3.2005, 22:00)

Не совсем, дезасемблирровать да, а вот с декомпиляцией не все так просто. Где то я читал статейку, в которой мужик показал, что не всякий байткод соответствует Java программе. И есть вещи реализуемые на ассемблере для JVM и не реализуемые на Java.

Я читал в Java CookieBook, что Mocha сама себя обфусцировать не может - и Jad тоже её разобрать не может... И вообще исходникии Mocha не сохранились из-за смерти автора, поэтому Mocha впринципе не могут вскрыть - ни в каком запутанном виде...

Ошибся, Mocha ложилась на таком:

Код

Method void main(java.lang.String[])      0 new #4      3 invokespecial #10      6 return      7 pop

Цитата(Domestic @ 3.3.2005, 23:18)

Пo-моему эта штука "взрывала" первую Mocha?

Не. Mocha на попе после ретурна умирала вообще...
Качт она просто не переваривала. Либо метод не декомпилила, либо декомпилила очень ошибочно (так как трая в начале не было)

А кто имеет опыт работы JBuilder + RetroGuard?
Если есть, поделитесь.
В моем случае (JBuilderX+RetroGuard 1.1) кроме изменения наименования приват переменных и методов в числовую последовательность ничего не делает.

Чесно говоря я работал только с модифицированным ретрогардом.
У нас все (что не входило игноре лист) переименовывалось. Включая имена констант, классов, методов.
В игнор листе было то, что было подвержено рефлексии.
Ксатати. Ретрогард вроде как не добавлял логических бомб...
+ еще кстати. Советую взять последную версию (она вроде как 2.0 или выше).

http://www.retrologic.com/retroguard-main.html

Последняя 2.0.1
пробовал и с ней.. думаю, что-то не так просто настраиваю в билдере

Может. У меня отдельно батником запускалось

Отдельно может помочь только для jar файлов. В моем случае необходимы натив исполняемые файлы. Хотя не получается через билдер для всех типов)