Open ItzSomebody opened 4 years ago
Interesting, didn't know you could bypass the security manager like that. Check out the latest commit.
If you find another bypass, let me know!
Your latest commit will actually break your other executions in certain cases (notably, the ones for Stringer) as some decryptor methods actually make use of some of the classes you prohibited with that commit.
Examples:
java.lang.reflect
to check parts of the JAR to compute a key.java.lang.reflect
to produce either CallSite or a java.lang.reflect.{Method/Field}
to the appropriate class member.Furthermore, the presence of the VM can still be found with something such as if (PoC.class.getClassLoader().getClass().getName().startsWith("me.nov")) throw new RuntimeException("Found deobfuscator instance")
.
Oops, didn't notice that. You can't really hide the VM instance, but that's not that important IMO. Gotta find a workaround for that.
It is gonna be pretty hard to block bypasses using reflection, as ReflectPermission
does not provide a way to get the context (e. g. allow reflection for everything, except java.lang.System
). For now I'm disabling reflection checks for these executions you listed.
Java doesn't allow me to redefine java.lang.reflect.AccessibleObject
either. Still haven't found any way to only block certain reflection.
Saw your warning @ https://github.com/GraxCode/threadtear#warning and thought it would be cool if people could see what an example of a successful arbitrary code execution would look like on threadtear as well as how the deobfuscator's instances are exposed to the program.
The PoC below specifically is targeted against Allatori's transformer; however, it can easily be adapted to fool threadreaper into executing it in any of the other transformers which utilize the VM.