I wanted to suggest Fernflower. I have a lot of experience with it, because it's what Jetbrains uses in Intellij. I have only seen it generate sensible code.
I took a quick peek at Vineflower first, and it's a fork of Fernflower. So would recommend that for anyone who might stumble on this in the future who is looking for a decompiler.
Any of these modern choices include features using LLMs to further decompile the decompiled code? Seems like an obvious direction, even just to infer variable names.
i have no idea why nobody is doing it - it is such an obvious use case of LLMs. i guess the reveng market is much smaller than most people realized?
then again, who needs reveng when you can use said LLMs to write new software "just in time" with the same API.
reveng also was one of those industries that always had a very suspicious crowd of people - i dont mean malicious, i mean... a lot of them drew a disturbing amount of pleasure from doing incredibly labourious work, sort of like someone who enjoys putting together an airfix model over many months with a microscopic brush and tweezers.
so i wonder if a lot of them perversely enjoy starting at reams of bytes and putting together this 10,000 piece puzzle, and having an llm solve it for them is a deep affront to their tastes.
Is it really an obvious use case of LLMs? Traditional byte code to source decompilers are faster, use less memory, and are deterministic. Using a LLM to decompile code makes as much sense as using a LLM to compile code.
That said there are probably ways a LLM could improve a decompiler in a way that does not impact its correctness. Like deriving class and variables names based on context, when symbols are missing or obfuscated.
... until you realize that the LLM-generated code doesn't even compile, or you need a PhD to write all the prompts needed to have a prototype instead of the real thing.
youre probably right... for the public market, anyway. blackhat state actors would probably not mind having something like that. but they'd never talk about it in public.
or maybe its not even neccesary, and doing something akin to fuzzing syscalls 'but smartly' probably yields more results.
if you want to an online java decompiler for a quick analysis, I recommend https://slicer.run/, it has a sleek UI and provides support for a variety of decompilers (including the likes of Vineflower, CFR, JASM, Procyon). For more in-depth analysis, https://github.com/Col-E/Recaf is probably my first choice
There are many real-world sideloading abuse cases in China. Attackers often trick victims with plausible stories—e.g., claiming a flight is delayed—and ask them to sideload an app (a remote‑meeting or remote‑control tool) to share their screen. Once installed, the attacker can view the victim’s screen and intercept SMS 2FA codes for online banking or other sensitive accounts.
Other schemes include impersonating sex workers to lure victims into nude video chats, then persuading them to install an app that harvests private content and contacts for blackmail.
Why should that mean anyone else should lose control of their device? Maybe at some point you have to accept that it's the user's responsibility? Maybe empower users to be aware of what the apps they install are doing, without take their control away?
This is how loss of autonomy always happens in every sphere: make an argument that it's for their own safety that individuals are losing autonomy, and the entity gaining control is superior in knowing what's best, and is taking control only out of the goodness of their heart.
These unfortunately gullible people would be tricked in many different other ways throughout their daily lives even if it wasn't for the ability to install something on a device that you paid for and outright own.
What's the Android situation there? Last I heard Google didn't license Android there and they were using Chinese app stores with forked AOSP Android. Which would seem to put the sideloading decision in the hands of the forked OS.
If by necessity you need to leave the door unlocked more, then you can expect more bandits to pass through. The frequency is a result of China's banning of all Google services, and the mess of Google Play alternatives making the universal option to request users to just install the APK off of a sketchy cloud link.
What they mean seems to be that one of their main developers was detained so their development slows down. Additionally GrapheneOS has made many breaking changes. So they need to start adapting Android 16 more earlier.
