ItzSomebody/radon

Some of the obfuscation options break testing project

Olexorus opened this issue · 8 comments

Radon version: 1.0.2

I wanted to test Radon, and found this: https://github.com/JoachimVandersmissen/TestingProject It's a project that's specifically designed for testing obfuscators by using many different bytecode features. When trying to use Radon to obfuscate it, it breaks sometimes.

The transformers which don't work according to my testing:

  • String Encryption - Normal
  • Pool Strings
  • Renaming (I put "META-INF/MANIFEST.MF" in adapt resources, and it properly changed the file, so that's not the problem)
  • Flow Obfuscation - Light

Yeah, the renaming has been breaking on LambdaMetaFactory invokedynamics since build 0.3.x or 0.4.x (don't remember specifically). I'll make sure to check the other ones out, thanks!

Pooling Strings and Flow Obfuscation works now, but String Encryption on Normal is still broken, however instead of throwing a Exception it just makes the program print nonsense to the console.

That was actually supposed to be fixed. I guess the commit got lost somehow.

With latest commits it's fixed now, however normal string encryption is very slow, without obfuscation the benchmark runs in ~230ms, with light string encryption it's ~290ms, heavy is ~290ms too, but normal is ~730ms
Not sure if that's supposed to be like that...

The normal string encryption is actually much faster for for me than it is for you. Try running the test multiple times.

Ok, I tested it again, 10 times each:
No obfuscation: Avg. between 229ms and 269ms
Heavy string encryption: Avg. between 290ms and 304ms
Normal string encryption: Avg. between 727ms and 743ms

I didn't have anything CPU intensive running in the background, and even if I had, it would have affected all tests. I got a i7-6700 (non K), my OS is Windows 10 Pro (64 bit) and my Java version is 1.8.0_181.

On my PC, the normal string encryption actually runs at close to the same speed as the unobfuscated jar, so I don't know what's going on in your end.

Ok, then I guess this can be considered fixed, and I suppose you won't fix the renaming thing (since it has been in Radon for so long already), so I'll close this.