search

java-deobfuscator / deobfuscator

The real deal
https://javadeobfuscator.com
Apache License 2.0
1.55k stars 289 forks source link

Pls update Zelix String/Reflection deobfuscator #909

Open LuckerCracker opened 2 years ago

LuckerCracker commented 2 years ago

The deobfuscator does not deobfuscate the new version of Zelix.

Janmm14 commented 2 years ago

Yeah, even the detection system knows that.

Unfortunaly for you, I don't want to publish my latest zkm deobfuscation in order to protect the intellectual property which is protected by ZKM obfuscation.

Col-E commented 2 years ago

I don't want to publish my latest zkm deobfuscation in order to protect the intellectual property which is protected by ZKM obfuscation

You could say this for any obfuscator. What's the point at supporting any obfuscator if this is a concern for the project? This seems like a rather silly take for a project with the sole purpose of deobfuscating code.

Janmm14 commented 2 years ago

I don't want to publish my latest zkm deobfuscation in order to protect the intellectual property which is protected by ZKM obfuscation

You could say this for any obfuscator. What's the point at supporting any obfuscator if this is a concern for the project? This seems like a rather silly take for a project with the sole purpose of deobfuscating code.

Sure. At that point I had a specific software in mind, as of now I wouldn't say that again tho.

Currently I'm lacking some motivation and the private copy I have has changes all over the place, is not as safe to use as it should be, it was just done based on one sample. It'd take time to implement the needed fixes (for example #873) and maybe some more besides needed expansions of jvmmethodprovider.

There is also still a bunch of unsolved things - how to handle zkm's class load order validation (lets call it clov)? I did not analyse zkm's code how it checks that, so there either needs to be another smart one who can extract this information without us getting into O(n!) or we need the user to input this (similar to hardcoded like in my private fork). Also I do not remove any zkm setup stuff yet, so clov could maybe prevent further transformers which emulate code to run.

Iirc zkm would just have to put some instructions before the class key call in clinit and my current transformer would collapse.

So theres a bunch of fixing needed. Maybe also some new peephole transformers. My transformer is no witchcraft, still I might adapt it to this branch and post it somewhere so others can improve it.

Col-E commented 2 years ago

Required updates to executor subsystem / jvmmethodprovider

From my limited knowledge of JavaVM, I believe it would require a lot of changes to fully support a generalized/peephole deobfuscation approach for ZKM (or any obfuscator, but ZKM is basically the king atm). While not directly tied to ZKM deobfuscation this is something we've actually been working on in Recaf 3X.

xxDark has done some excellent work in virtualization. We already have some limited scope peephole optimization support, and users can interactively virtually invoke methods to see what their return values are. In time we'd like to expand this into full application deobfuscation.

Janmm14 commented 2 years ago

@Col-E

I did not mean javavm, but the executor in this project.

I have never even tried to use javavm myself, I've just seen it failing here sometimes in the issues, which let me believe its quite buggy.

Edit: Maybe we can continue this on discord.