|benf.org : other : cfr : faq|
I guess the question hasn't been asked! Mail me...
As of 0.135, yes.
You can download it directly from the home page, or use a maven dependency
Class File Reader. Nothing more interesting than that. I'm just rubbish with names.
Not really. CFR has multiple fallback passes where it enables different sets of fallback options, but for full disclosure, I've exposed all of these options on the command line. This means that you should never have to set an option - CFR will do it for you if necessary!
..... with the exception of flags which rename members. If these are neccessary, CFR will emit a comment suggesting you use them. I don't do it automatically, as it breaks reflective use of decompiled code.
Not for decompilation. I've written everything from scratch - partly because I'm doing this for fun, partly because I'm half tempted to port it to C++ at some point, so I don't want dependencies.
There is a small reflective use of NIO, to allow the code to (still) require only Java6.
On Bitbucket, here
I'll try to announce updates on Twitter - @LeeAtBenf
*shame* I've been disorganised here, not got around to it yet..... any minute now...
For fun. That's the entire reason. I moved from a C++ job to a Java job, and writing a decompiler seemed like a good way to learn the java ecosystem... - there's a lot of published material out there on coin, etc, but not a vast amount on what's going on with the bytecode...
Java 6 is still amazingly widely installed. Because CFR has its own implementations of all of the class file features / jls understanding, it doesn't actually need java 8 to understand java 8 features! (Though occasionally I find myself missing syntactic sugar!)
Yup, probably. There are always going to be edge cases. Feel free to send me examples, IF THE INTELLECTUAL PROPERTY BELONGS TO YOU.
Absolutely. But I'm imagining a world where people lie, when they can. JVMs don't verify signature attributes - they can lie. Local type tables can lie. And I want to see what sort of a decompiler I can get if I don't trust information I can't verify..... (though I do use LocalVariableNameTable for hints. Hey, I'm weak.)
Paranoia. It's possible (and legal) to mark every method in your codebase synthetic, if you're feeling mean. CFR will only remove synthetic methods when it's validated what they're doing, (i.e. friend accessors)
The JRE used when decompiling doesn't have to support the needs of the class file. If you're decompiling Java 8 files using a Java 6 JRE, then the support classes will be unavailable to CFR. They're not strictly necessary, however they will improve the quality of the decompilation.
I find if the code hasn't been obfuscated (or more accurately, been madly rebuilt with dex2jar) then the bytecode straight out of javac is in a more sensible ordering than I get after a topsort. As such, I only apply the topsort if CFR can't produce sensible code off the basic ordering. (and ends up creating code that seems to contain Duff's device... :P )
Maybe. Probably. Possibly. But you'll end up with Java. Which isn't necessarily a bad thing - I've found it fascinating seeing what Scala/Kotlin/Groovy look like if you push them back into java! If you've got a pet JVM language that CFR particluarly sucks at, please let me know - but please don't expect CFR to generate anything but Java for now!
java -jar cfr.xxx.jar -cp myPath/myJar.jar myClassNamedoesn't work.
Nope - this a java cli behaviour - to work around this, you can specify
Prior to 0.135, CFR has been entirely self hosted, which means I kept doing the first thing that popped into my head. As of 0.135, I've let the project grow up a bit, and it's hosted on maven central. As such, it's good to play nice!
There are tonnes, but not many which support modern Java features.
| Last updated 03/2018 |