Error stringer.StringEncryptionTransformer

[Mepth]

Deobfuscation failed. Please open a ticket on GitHub
java.lang.NullPointerException
at java.lang.reflect.Array.get(Native Method)
at com.javadeobfuscator.deobfuscator.executor.MethodExecutor.executeArrayLoad(MethodExecutor.java:101)
at com.javadeobfuscator.deobfuscator.executor.MethodExecutor.execute(MethodExecutor.java:439)
at com.javadeobfuscator.deobfuscator.executor.MethodExecutor.execute(MethodExecutor.java:80)
at com.javadeobfuscator.deobfuscator.transformers.stringer.StringEncryptionTransformer.decrypt(StringEncryptionTransformer.java:204)
at com.javadeobfuscator.deobfuscator.transformers.stringer.StringEncryptionTransformer.transform(StringEncryptionTransformer.java:61)
at com.javadeobfuscator.deobfuscator.Deobfuscator.start(Deobfuscator.java:170)
at com.javadeobfuscator.deobfuscator.DeobfuscatorMain.run(DeobfuscatorMain.java:102)
at com.javadeobfuscator.deobfuscator.DeobfuscatorMain.main(DeobfuscatorMain.java:26)

[Eyremba]

The deobfuscator is outdated as fuck and no longer working. You will see such errors also when a jar is obfuscated using the latest version of Zelix or Allatori.

[FFY00]

The deobfuscator is outdated as fuck and no longer working. You will see such errors also when a jar is obfuscated using the latest version of Zelix or Allatori.

By all means, submit a pull request to the project and help.

[Eyremba]

By all means, submit a pull request to the project and help.

Why should I help....? I am pro Obfuscation and contra Deobfuscation, so I'm blissfully happy and overjoyed that all current Obfuscators can't be deobfuscated by tools like this. :)

[Janmm14]

Well there's a reason I do not publish my working deobfuscator changes too: People will find this project and report it to the obfuscation creators. Or obfuscazion creators are looking here directly.

Samczsun is btw. working on a full controllable jre written in java as far as I know.

[FFY00]

Well there's a reason I do not publish my working deobfuscator changes too: People will find this project and report it to the obfuscation creators. Or obfuscazion creators are looking here directly.

Samczsun is btw. working on a full controllable jre written in java as far as I know.

That's pretty cool, I will keep an eye out.

Why should I help....? I am pro Obfuscation and contra Deobfuscation, so I'm blissfully happy and overjoyed that all current Obfuscators can't be deobfuscated by tools like this. :)

Please close the page then, if you're not here to make constructive contributions stop wasting your time. And no, there are working deobfuscators but there's no point on releasing them as @Janmm14 said. I write my own deobfuscators as needed, java bytecode isn't that hard and bypassing obfuscators is just easy, it may take some time but still easy.

[Eyremba]

Please close the page then, if you're not here to make constructive contributions stop wasting your time. And no, there are working deobfuscators but there's no point on releasing them as @Janmm14 said. I write my own deobfuscators as needed, java bytecode isn't that hard and bypassing obfuscators is just easy, it may take some time but still easy.

This statement clearly shows that you have no knowledge at all. Bypassing them is really hard, if the obfuscation is done right. I would bet that you have never seen real obfuscation. Nearly 90% of the Java kids out there use demo versions of obfuscators, or leaked versions which are outdated for more than 4 years now. Real obfuscation is fucking hard to deobfuscate. Some very good Java developers got some examples from me weeks and months ago, and they are still biting their teeths out while they try to deobfuscate them.

[FFY00]

This statement clearly shows that you have no knowledge at all. Bypassing them is really hard, if the obfuscation is done right. I would bet that you have never seen real obfuscation. Nearly 90% of the Java kids out there use demo versions of obfuscators, or leaked versions which are outdated for more than 4 years now. Real obfuscation is fucking hard to deobfuscate. Some very good Java developers got some examples from me weeks and months ago, and they are still biting their teeths out while they try to deobfuscate them.

I wrote a metamorphic in assembly as my graduation thesis, why wouldn't I be able to bypass obfuscation? Java bytecode is just like a higher level assembly. I won't waste any more of my time talking to you, I know substantially more than you in this subject and what would be easy for me can be hard for you, I understand that and so should you. Have a nice day.

[Eyremba]

I know substantially more than you in this subject

Um.... No. :)

what would be easy for me can be hard for you

Nope. It's hard for you too because if someone obfuscates a JAR file really really hard, you will give up because you have no chance.

Hey @Eyremba, can I ask what your credentials here are? I mean, I like obfuscation as much as the next guy, and I don't really like deobfuscation tools either, but I mean, what have you done? Your github profile is 6 sources out of 171 repos, and 5 out of those 6 are minecraft plugins. I suppose you have a "string obfuscator" repository, but it does nothing except output some java source code. Is there anything you can show to back up your expertise? A linkedin profile maybe? At least make sure you know what you're talking about before you get into an argument.

[Eyremba]

@JoachimVandersmissen I know what I'm talking about, I also develop obfuscation tools, but of course private, if I would post them here on Github, it would be much more easy to deobfuscate their work.

[DarkSeraphim]

@Eyremba Even if you write the tools, it doesn't mean you know whether it can be cracked or not (or how hard it is). The reason is similar to why developers are not advised to roll out their own encryption algorithms: even if you think it's safe, you don't see all the issues concerning the algorithm.

Someone who's well versed in bytecode isn't stopped by obfuscation, since you can't obfuscate bytecode (unless you write native apps, but that's out of scope here), and reading bytecode is not a problem.

As long as obfuscation is a deterministic process (and yes, it pretty much always is in a sense, otherwise it's likely not reliable), it's not hard to crack.

(O, and "very good Java developers" is a bit of a meaningless term. 1) Do we really know / trust the skill of your testers, and 2) even if they're good Java developers, Java skills are not that important when analysing bytecode, since it's a lot lower level)

tl;dr; you're being way to narrow minded right now, the world is way bigger than you might guess 😛

(EDIT: I realised where I saw your name before: here and here, which doesn't really add to your credibility)

[Eyremba]

Someone who's well versed in bytecode isn't stopped by obfuscation, since you can't obfuscate bytecode

But if the Bytecode is 2000% times larger than before due to the obfuscation, it will be much harder and take much longer to understand everything. :)

[DarkSeraphim]

In most cases it's pretty repetitive, obfuscation generally requires you to find patterns, so you can replace them with it's smaller equivalent.

And as is known, practice makes perfect :P

[Eyremba]

In most cases it's pretty repetitive, obfuscation generally requires you to find patterns, so you can replace them with it's smaller equivalent.

But if everything is flow-obfuscated in different ways, and everything is replaced by InvokeDynamics and by Reflection API calls, and again flow-ofbsucated in different ways, then you can not dispute that it will be a very time consuming task ;)

[DarkSeraphim]

@Eyremba Well you're free to provide a sample (also, 2000% larger sounds like rather inefficient bytecode, or a lot of noise)

…

On 16 Apr 2017 1:10 p.m., "Eyremba" ***@***.***> wrote: In most cases it's pretty repetitive, obfuscation generally requires you to find patterns, so you can replace them with it's smaller equivalent. But if everything is flow-obfuscated in different ways, and everything is replaced by InvokeDynamics and by Reflection API calls, and again flow-ofbsucated in different ways, than you can not dispute that it will be a very time consuming task ;) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#90 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACjQff1lMJpMG4XvUrwBPWHuAOluayS1ks5rwfcSgaJpZM4M8j5c> .