Данил Шеховцов

Вы просто получите функционально эквивалентный код на Java. Ровно то же самое с .NET языками, которые декомпилируются в C# (даже в описании dotPeek сказано, что поддерживается только вывод на C# независимо от языка исходника). Машинные языки декомпилируются в C. Всё это связано с уничтожением и раскрытием синтаксического сахара во время компиляции нестандартного языка вроде Kotlin, F# и тому подобных. Машинные же коды вообще становятся процедурными после компиляции, какая бы парадигма ни была в начале, соответственно код на C тоже процедурный.

На примере Ghidra: сперва идёт поиск паттернов машинного кода (должны совпасть ключевые значения вроде опкодов, для этого составляется маска инструкции, затем необходимое целевое значение, полученное побитовым И с маской), затем подходящий паттерн преобразуется в две строки. Первая - заголовок, подаётся в дизассемблер, содержит мнемонику и операнды, в Ghidra используются спецификации на языке Sleigh. Но это так, для разминки, поскольку дизасм читать нереально, вот тут и было придумано промежуточное представление. Суть в том, что каждая инструкция - микрофункция, содержащая код (например, на языке Pcode, как в Ghidra). Затем он посылается в декомпилятор и поднимается до финального кода на C.

Вообще есть 2 разные вещи: программа на компилируемом языке (C/C++/Golang/etc), т.е. исходник; и программа на одном из языков CPU (для GPGPU - GPU), так называемая release версия (либо debug, но суть не меняется, т.к. в отладочных бинарниках информации не сильно больше), она то и попадает на компьютеры клиентов/потребителей софта. Языков CPU (GPU - тем более) существует множество. Код на них необходимо перевести на IR/IL - выдуманный вспомогательный язык, затем в C-подобный функционально эквивалентный декомпилированный код. Так что исходники не раздобыть, но для модов/кряков/etc это лучше, чем ассемблер. Но минус в том, что с таким кодом могут потребоваться танцы с бубном, перед тем, как скомпилировать его снова. Для байткодов всё не так сложно, там декомпилированный код часто совпадает с исходным. Для первых (кроме GPU - в разработке) есть Ghidra, для байткодов: JVM байткод - Fernflower/CFR, C# байткод - JB dotPeek, Python байткод - Uncompiler. Вообще нет никакой защиты в большинстве случаев, по сути вся проблема в разнице между исходником и тем, что способен понять процессор. Поэтому никогда не пытайтесь оттранслировать CPU (x86/PPC/MIPS/ARM/AARCH64/...) в C++, только в C.

Для apk подойдёт хоть 7zip. Для кода (тот, что бинарный/двоичный, язык Dalvik) 2 варианта: либо в JVM байткод при помощи dex2jar, затем JVM в Java при помощи любого Java декомпилятора (могу посоветовать Fernflower и CFR). Второй способ поинтереснее, но надо иметь низкоуровневое мышление, особенно с Ghidra. Смысл в том, что Dalvik конвертируется во внутреннее представление Pcode (возможно это даже язык, т.к. есть эмулятор, хотя работа над ним не завершена). Затем Pcode сразу конвертируется в нечто среднее между Java и C# (в основном из-за goto). Но мне кажется что первый способ для вас будет проще, т.к. исключения в Гидре отображаются только после патчинга, и может ещё что-нибудь всплыть лишнее.

Если бы игра была написана на c++, то НЕ было бы тех замечательных модов, как например Divine RPG. А вот почему, сами догадывайтесь, но я могу посоветовать начать с того, что java можно декомпилировать, а с c++ такое не получится.