Threadtear is a multifunctional deobfuscation tool for java. Android application support is coming soon (Currently working on a dalvik to java converter).Suitable for easier code analysis without worrying too much about obfuscation.Even the most expensive obfuscators like ZKM or Stringer are included. For easier debugging there are other tools included.Insert debug line numbers to better understand where exceptions originate, or add .printStackTrace() to try catch blocks without re-compiling your code.Reverse compatibility is not a problem anymore, if no version specific methods are used. Analyze code flow in a graph, to better understand algorithms.
An "execution" is a task that is executed and modifies all loaded class files.There are multiple types of executions, varying from bytecode cleanup to string deobfuscation.Make sure to have them in the right order. Cleanup executions for example should be executed at last, but also can help other executions if executed first.If you are ready, click on the "Run" button, and they will be executed in order.
Use this tool at your own risk. Some executions use implemented ClassLoaders to run code from the jar file. An attacker could tweak the bytecode so that malicious code could be executed.Affected executions use the classme.nov.threadtear.asm.vm.VM.These are mostly used for decrypting string or resource / access obfuscation, as it is much easier to execute the decryption methods remotely.
Threadtear tries its best to protect you from malicious calls (arbitrary code executions) using its ownSecurityManager, but there is no guarantee.Especially with deobfuscators like for ZKM or Stringer you have to be very careful, as reflection has to be allowed, otherwise they would not function.If you discover an ACE, please open an issue. I will try to fix them as soon as possible.
First, rungradle build, thengradle fatJar. Inbuilds/libs a runnable jar file should then have been created. If you don't want to download the repo, you can use the latest release.
You can easily create your own execution task. Just extendme.nov.threadtear.execution.Execution:
publicclassMyExecutionextendsExecution {publicMyExecution() {super(ExecutionCategory.CLEANING/* category */,"My execution"/* name */,"Executes something"/* description, can use html */);}/*** This method is invoked when the user clicks on the Run button* @return true if success, false if failure*/@Overridepublicbooleanexecute(Map<String,Clazz>classes,booleanverbose) {classes.values().stream().map(c ->c.node).forEach(c -> {//transform the classes here using the tree-API of ASM});returnfalse;}}To load ClassNodes at runtime, use theme.nov.threadtear.asm.vm.VM class and implementme.nov.threadtear.asm.vm.IVMReferenceHandler:
publicclassMyExecutionextendsExecutionimplementsIVMReferenceHandler {publicMyExecution() {super(ExecutionCategory.GENERIC,"My execution","Loads ClassNodes at runtime");}@Overridepublicbooleanexecute(Map<String,Clazz>classes,booleanverbose) {classes.values().stream().map(c ->c.node).forEach(c -> {VMvm =VM.constructVM(this);//transform bytecode to java.lang.ClassClass<?>loadedClass =vm.loadClass(c.name.replace('/','.'),true);//do stuff with your class hereloadedClass.getMethods()[0].invoke(...);returntrue;});}/*** Will get invoked by VM, when VM.loadClass is called*/@OverridepublicClassNodetryClassLoad(Stringname) {//try to find the class to be loaded in open jar archivereturnclasses.containsKey(name) ?classes.get(name).node :null;}}Using the ConstantTracker (me.nov.threadtear.analysis.stack.ConstantTracker) you can analyze methods and keep track of non-variable stack values.If for exampleiconst_0 is pushed to the stack, the value itself isn't lost like in the basic ASM analyzer, and you can use it to predict things later on in the code.
publicclassMyExecutionextendsExecutionimplementsIConstantReferenceHandler {publicMyExecution() {super(ExecutionCategory.GENERIC,"My execution","Performs stack analysis and replaces code.");}@Overridepublicbooleanexecute(Map<String,Clazz>classes,booleanverbose) {classes.values().stream().map(c ->c.node).forEach(this::analyzeAndRewrite);returntrue;}publicvoidanalyzeAndRewrite(ClassNodecn) {cn.methods.forEach(m -> {// this analyzer keeps known stack values, e.g. can be useful for jump predictionAnalyzer<ConstantValue>a =newAnalyzer<ConstantValue>(newConstantTracker(this,Access.isStatic(m.access),m.maxLocals,m.desc,newObject[0]));try {a.analyze(cn.name,m);}catch (AnalyzerExceptione) {logger.severe("Failed stack analysis in " +cn.name +"." +m.name +":" +e.getMessage());return;}Frame<ConstantValue>[]frames =a.getFrames();InsnListrewrittenCode =newInsnList();Map<LabelNode,LabelNode>labels =Instructions.cloneLabels(m.instructions);// rewrite method instructionsfor (inti =0;i <m.instructions.size();i++) {AbstractInsnNodeain =m.instructions.get(i);Frame<ConstantValue>frame =frames[i];// replace / modify instructions, etc...if (frame.getStackSize() >0) {ConstantValuetop =frame.getStack(frame.getStackSize() -1);if (top.isKnown() &&top.isInteger()) {intknownTopStackValue =top.getInteger();// use the known stack to remove jumps, simplify code, etc...// if(...) { rewrittenCode.add(...); }continue;}}rewrittenCode.add(ain.clone(labels));}// update instructions and fix try catch blocks, local variables, etc...Instructions.updateInstructions(m,labels,rewrittenCode);});}/** * Use this method to predict stack values if fields are loaded */@OverridepublicObjectgetFieldValueOrNull(BasicValuev,Stringowner,Stringname,Stringdesc) {returnnull;}/** * Use this method to predict stack values if methods are invoked on known objects */@OverridepublicObjectgetMethodReturnOrNull(BasicValuev,Stringowner,Stringname,Stringdesc,List<?extendsConstantValue>values) {if (name.equals("toCharArray") &&owner.equals("java/lang/String")) {if (!values.get(0).isKnown()) {// invocation target is not known, we can't compute the returnreturnnull;}return ((String)values.get(0).getValue()).toCharArray();}returnnull;}}Don't forget to add your execution to the tree inme.nov.threadtear.execution.ExecutionLink!
There are some tricks that can help you identify and deobfuscate jar files successfully. Before running executions, decompile the code to find out what needs to be used.You can use the implemented decompiler for that.
The best order for a deobfuscation isgeneric executions > access deobfuscation > string deobfuscation > cleaning executions.
Obfuscators exhibit patterns which you can use to identify obfuscators. The easiest way to identify an obfuscator is to skim theMETA-INF/MANIFEST.MF file.It's possible that there is anObfuscated-By: XXX orProtected-By: XXX attribute.
Extremely (flow-) obfuscated code, often noticeable by a string decryption method in the static initializer containing switches,or string decryption methods with a very long switch block (about 250 cases).ZKM is one of the best (and oldest) obfuscators for java, and very expensive. As ancient as the obfuscator is their website.
If your jar file contains some special classes with huge decryption algorithms that are used by string obfuscation and access obfuscation, it's probably Stringer.The protection is not bad and Stringer is one of the most expensive obfuscators. Unlike normal obfuscators it does not come with name obfuscation.It is rather used as "second layer". Probably 90% of people that use this obfuscator are using a crack, as it costs more than a car.If your file has been obfuscated with multiple obfuscators, and Stringer is one of them, you should begin your deobfuscation with Stringer, as Stringer obfuscation cannot be overwritten.(Due to custom JAR signature and usage of method names during string decryption)
Class names like IiIlIlIiIl or aUx, cOn, PrX indicate Allatori obfuscation.Allatori is very common amongst obfuscated jar files, because it offers a free demo that accessible within a few clicks. The obfuscation is not that hard to reverse.
Paramorphism is like the little brother of stringer, as it looks similar, but isn't as good as it. It also has some interesting features that aim to crash reverse engineering tools, which can be removed easily.The obfuscation strength is comparable to Allatori.
For other obfuscators you can try generic executions or open an issue, and I'll see what I can do.
Before selecting an execution, check out the tool-tip texts while hovering.They contain a small description about what they do, but also tags that help you understand how the behavior of your JAR file will be changed.
Threadtear is licensed under the GNU General Public License 3.0
This tool was a ton of work.If I saved your time, and you want to buy me a coffee you can do so here:
Use Threadtear for legal purposes only. Threadtear is not aiming to be a cracking tool, but rather to be a malware analysis toolkit.Please open an issue or email me if a transformer doesn't work properly and attach the log.
Note that output files are most likely not runnable. If you still want to try to run them use-noverify as JVM argument!
This tool intends to be used with Java 8, but it will probably run on higher versions too.
