P
jadx умеет декомпилировать в проект градла прямо сразу, но едва ли получится идеально декомпилировать прямо всё
спасибо
Size: a a a
2018 February 19
VZ
но он работает сильно лучше, чем другие декомпиляторы, потому что использует напрямую dex
От того что он использует dex и качеством нету логической взаимосвязи
GK
От того что он использует dex и качеством нету логической взаимосвязи
ну как-то мне казалось, что конвертация байткода далвика в обычные классы делает декомпиляцию сложнее
GK
потому что она наверняка не совсем однозначная
VZ
потому что она наверняка не совсем однозначная
Несколько я знаю - однозначная. Но я в этом не уверен
NK
Конечно, не однозначная
NK
К тому же, как минимум, количество кодов dalvik и байткода отличается
GD
ну как-то мне казалось, что конвертация байткода далвика в обычные классы делает декомпиляцию сложнее
это так, как минимум из-за того, что дофига всего криво декомпилируется
GD
видел сотни примеров когда декомпилировалось в какое-то дерьмо, хотя на деле всё было тривиально
GK
это так, как минимум из-за того, что дофига всего криво декомпилируется
ну вот исходя из моего опыта dex напрямую декомпилируется качественнее, чем после dex2jar
VZ
Хм. Значит я все это время думал неправильно. Сейчас подумал, пару раз пользовался jadx в онлайне и вроде и правда результат был лучше. Он как минимум оставляет куски с байткодом закомментированные, если не смог справиться, насколько я помню. Такая малочь, а работать намного приятней. А может кто носом ткнуть где почитать, чтобы убедиться окончательно, что dex в jar неоднозначно компилируется-декомпилируется?
R
Почитай список опкодов далвика и сравни его со списком обычных джавайских опкодов. @zhukVladislav
VZ
Почитай список опкодов далвика и сравни его со списком обычных джавайских опкодов. @zhukVladislav
Да читал на самом деле. Но разница в колличестве ведь не говорит же о том, что они не однозначны
GK
по-моему должно быть достаточно просто того факта, что обычная JVM на стеке, а далвик на регистрах
VZ
по-моему должно быть достаточно просто того факта, что обычная JVM на стеке, а далвик на регистрах
Почему этого факта достаточно?
GK
Почему этого факта достаточно?
потому что при преобразовании регистров в стек может как раз таки быть неоднозначность 🤔
VZ
А может и не быть
GK
ну то есть у обычной JVM все операции вида "взять N данных со стека и сделать с ними что-то и положить результат на стек обратно", что, имхо, даёт меньше гибкости, чем регистры, которых может быть сразу много и нет никакого ограничения на порядок их использования
GK
поэтому я подозреваю, что dex2jar может обходить это созданием промежуточных локальных переменных, которых изначально в коде не было
GK
и это, естественно, непосредственно влияет на качество декомпиляции, хоть и полученный байткод делает то же самое, что изначальный в дексе