-
Notifications
You must be signed in to change notification settings - Fork 299
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
java.lang.UnsupportedOperationException on radon v1 #921
Comments
I'd try rightlcickingthe radon transformer and changing its config options, for example try disabling fastIndy. Otherwise the jar you sent is unfortunaly incomplete, not all classes used during decryption are inside, so attempts in fixing this are not possible. I think there might also be stringer involved here, judging on a not-sent-class-name. If you cannot provide the full jar file while respecting #653, I cannot help you, maybe some other maintainer wants to but they are usually even less active here. |
Thanks for fast reply! I've turned off as you recommended (well, actually I did off the Indy, not fastIndy) and yeah, it did not crash now -
the jar is indeed incomplete as I tried to narrow down the issue... Could I ask more about dependent classes - does the tool require all of them in order to do the good job?
|
If you turn off whole "indy" it just will not attempt to decrypt invokedynamic. Yes, you are right, with just these two classes alone, the error does pop up and it is a legitimate error. However there is still a layer of stringer below this, and that one would need additional classes. |
Oh, I see, indy must be shorten of "Invoke dynamic" then :) I dont have luck to run stringer though... each time I'm getting OOM one more question: how do I set the indy off in the detect.yml config file? I"ve tried this one but it's not accepted...
|
iirc in the config yml transformer options are like transformer:
- xxx.yyy.zzz:
indy: false The gui config were originally the program arguments, how you start the deobfuscator, back then there were no transformer options. You can also start the gui with increased xmx. Running stringer transformer on the project as its right now might not do much, because the radon stuff is still there. |
Thanks! I might have missed that part how to customize some specific transformer in the .yml file The GUI has a nice Save Config button, but for transofrmer customization it shows the format which is not OK for .yml and about -Xmx - I'm having hard time setting this value in the GUI, each and every time it says OOM, so thats why I switched to the command line tool Are you saying that I need to start the GUI passing -Xmx2G and this value will be propagated later on to transformers runs? |
the config save button is only useful if you want to load it into the gui Yes, the gui runs the deobfuscator in the same java process as itself, so when you start the gui with higher Xmx it also affects the deobfuscation. |
Took me some time to figure out why yaml parser was not happy, its all about indents :)
there are 4 spaces from letter 'c' in com... to 'i' in indy :) TAB not accepted |
@greenozon I merged Jan's PR that should fix this. Feel free to holler if it still doesn't work. |
Thanks for update! src\com\javadeobfuscator\deobfuscator\executor\defined\ReflectiveProvider.java:26: error: package sun.invoke.util does not exist src\com\javadeobfuscator\deobfuscator\executor\defined\ReflectiveProvider.java:58: error: cannot find symbol I'm using old good JDK 1.8.0.331 x32 with NB 12.6 |
Forget to add that testing went fine - no exceptions at all (having indy flags on and off) |
I think your JDK somehow does not expose Alternatively just delete
The radon transformer thought that the class was originally added by the radon obfuscation: code If that creates a potential problem later on when you try to remove BisGuard obfuscation, we could add options to the radon transformer to not delete methods / classes. |
Thanks for reply I'm using the standard JDK8 from Oracle (java -version
that exports sun.invoke.util?
so I plan to unpack it by hands, radon already did a great job, but now I see that BG is a tricky guy, as it encrypts all the rest of app's classes and in order to get the decription key it does very smart stuff- it enumerates all the classes/methods/fields and even reads out some info from Linenumbertable ... so long story short - could we make sure that after radon's work that info is kept as is? anyway, I've decomplied the BG service classes (shown on above pic) but I hit the error when it creates the decryption key... so one of my ideas was that it needs all the original classes (but now I"m not sure) sorry for long writeup, just having noone to share thoughts with... |
Java 8 from Oracle should expose those classes as well. Maybe these errors are from netbeans ide and not from maven build? Well you can try to edit the transformers yourself (and build it yourself). maybe also try bisguard transformer before radon. |
BG has a stopper like this:
I"ve read in another issue that this is a show stopper, right? |
Some errors during RADON1 deobfuscation:
https://www.sendspace.com/file/63xtq1
java -jar deobfuscator.jar -input C:\temp\deobfuscator\o.jar -output c:\temp\deobfuscator\o2.jar -transformer special.Radon -libraries C:\Java\jdk1.8.0_331\jre\lib\rt.jar
The text was updated successfully, but these errors were encountered: