Сравнительный анализ некоторых Java-декомпиляторов

[y4ppieflu]

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

[SolarSecurity]

В начале статьи написано — если исходники не доступны. Например, такое может быть в случае с унаследованным ПО. Исходников нет, а проанализировать код на уязвимости нужно.

[y4ppieflu]

Хм, но ведь тогда теряется смысл сканирования — если исходников нет, то и исправить найденные уязвимости вряд ли получится.

[SolarSecurity]

В нашем продукте есть технологии анализа исполняемых файлов, позволяющие восстанавливать исходный код и указывать в нем уязвимости.

[turbanoff]

Таким образом можно подтолкнуть разработчиков к переходу на новую версию. Или задуматься о замене библиотеки на что-то другое.

[y4ppieflu]

Все равно не очень понятно, в чем тут профит, если это единственный кейс, для которого нужно было поддержать анализ скомпилированного кода.
Если библиотека внутренняя и для нее просто потерялись исходники — заменить или проапгрейдить ее не получится. Если библиотека сторонняя — скорее всего ее первым делом добавлят в исключения сканирования SAST'ом, анализ зависимостей — это задача для всяких composition analysis и dependency checking решений.

[brontozyablik]

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

Во-первых, часто компании хотят, чтобы код анализировался у нас/в облаке, но не хотят (или не могут из-за каких-нибудь регламентов) отдавать исходники наружу вообще.

Потом, есть довольно популярный воркфлоу: проанализировать приложение из Google Play и оценить его безопасность. Анализ происходит просто по ссылке на приложение. Никаких исходников тут нет, а какого рода ошибки выявлены — посмотреть надо.

Ну и кейс с легаси-библиотеками уже озвучивали: в таком случае если в библиотеке есть уязвимость, то ее можно либо поправить прямо в байткоде, либо настроить WAF в соответствие с теми уязвимостями, которые найдены, например.

[fusioneer]

Если ошибки в нюансах(а не архитектурные), то исправить можно в байт-коде. В этом плане декомпиляция полезна для анализа, но не для повторной сборки. Сомневаюсь, что декомпиляторы когда-нибудь смогут выдать 100% рабочего кода.

[olegchir]

Декомпилируешь тот кусок кода где баг, правишь баг, компилируешь его заново, подкладываешь в JAR-ку.

[Maccimo]

Итого, нам нужно уметь делать две вещи:

• декомпилировать байткод;
• строить соответствие между инструкциями в байткоде и строками исходного кода.

Спойлер: ни в одном из известных декомпиляторов нету инструментария для того, чтобы осуществить второе.

Так вот же оно: https://github.com/JetBrains/intellij-community/blob/master/plugins/java-decompiler/engine/testData/results/PrivateClasses.dec#L406-L473

[brontozyablik]

Действительно, оно. К сожалению, эта функциональность не доступна через cli, а я толком не игралась с Fernflower'ом как с библиотечкой, так что не заметила. Добавлю информацию в статью, спасибо за коммент!

[OLEG4120]

Почему вы говорите что у JD-Core не опубликованы исходники?
Вот же github.com/java-decompiler/jd-core

[brontozyablik]

Да, действительно, тогда, когда я смотрела на него (в начале мая как раз) их еще не было опубликовано. Наверное, надо будет еще раз на JD-Core взглянуть, хотя он не очень многообещающе выглядит: даже поддержки Java 6 не заявлено.

Спасибо за коммент. Сейчас добавлю ссылку в текст.

[Vest]

It support Java 1.1.8 to Java 12.0, including Lambda expressions, method references and default methods.

Вы не прочли README.md, там всё написано.

[brontozyablik]

Хм. Да. Действительно >.<

[Beholder]

Иногда хочется согласиться даже не на декомпиляцию в полноценные Java-исходники, а на удобный просмотр байт-кода. К сожалению, то, что выдаёт javap и "Show bytecode" в IDEA, читать бывает очень сложно. Нужен какой-нибудь "дизассемблер", но чтобы получался легко читаемый текст. А так же желателен "ассемблер", чтобы поправить полученные исходники и скомпилировать в байт-код обратно.

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

[Maccimo]

Вот вам ассемблер и дизассемблер: https://wiki.openjdk.java.net/display/CodeTools/asmtools

[VADemon]

Я не понял в чём заключается неподдерживаемость Java 8 в Krakatau? Судя по репозиторию, туда уже что-то из 14 добавили.

Также не могу не отметить патчи над FernFlower в ForgeFlower. Тот же 0025-Add-try-with-resource-support.patch есть.