Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fernflower Java Decompiler

github.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Fernflower Java Decompiler

#31

Post by BobbyTables2 »

viraptor wrote: post #19
Hackbraten wrote: post #12

Earlier quoted context omitted.

There’s some prior art on this [0] [1], and it’s worked decently well for me on obfuscated JS. [0]: https://thejunkland.com/blog/using-llms-to-reverse-javascrip... [1]: https://github.com/jehna/humanify/blob/main/README.md#exampl...

It's also good as picking up patterns which are common enough, but may not be known to everyone. For example I couldn't tell that some function was doing CRC via a lookup table - but Claude knew.

Often googling the first few entries of such tables will show CRC implementations. Same for SHA hash constants…

Re: Fernflower Java Decompiler

#32

Post by wokkel »

vbezhenar wrote: post #30
rhdunn wrote: post #24

Earlier quoted context omitted.

https://www.jetbrains.com/help/idea/annotating-source-code.h... > When you compile your project with IntelliJ IDEA build tool, the IDE adds assertions to all code elements annotated with @NotNull. These assertions will throw an error if the elements happen to be null at runtime.

That's not java compiler. That's intellij compiler. I'd say that's very weird anti-feature, because your build in IDE and maven will work differently.

When using Lombok it will use a compiler plugin for this so maven builds have @nonnull generated as if-statements. I dont know if intellij uses their own plugin but they do support Lombok in maven projects, so maybe thats where this is coming from. Afaik intellij has no built in compiler but relies on java .

Re: Fernflower Java Decompiler

#33

Post by viraptor »

BobbyTables2 wrote: post #31
viraptor wrote: post #19

Earlier quoted context omitted.

It's also good as picking up patterns which are common enough, but may not be known to everyone. For example I couldn't tell that some function was doing CRC via a lookup table - but Claude knew.

Often googling the first few entries of such tables will show CRC implementations. Same for SHA hash constants…

The tables depend on the CRC parameters and in my case there would be no Google hits - a unique setup was used.

Re: Fernflower Java Decompiler

#36

Post by dunham »

nunobrito wrote: post #28

Can the decompiled result be compiled again?

I've actually had this fix a bug before. An O(n^2) issue adding a character at time to a string inside a loop.

I had decompiled the class, fixed the issue, checked in the original decompiled source and then the change. Then a coworker pointed out that the original decompiled source also fixed the issue.

After a bit of digging, I learned that hotspot compiler had code to detect and fix the issue, but it was looking for the pattern generated by a modern compiler, and the library was compiled with an older compiler.

(It's been a while, but I think it was the JAI library, and the issue was triggered by long comments in a PNG.)

Re: Fernflower Java Decompiler

#39

Post by gf000 »

p0w3n3d wrote: post #10

Is it only me or fernflower does not put the code in the correct lines, and the debugging fails to navigate over the code in the IntelliJ IDEA?

I mean, in the general case is it not impossible to "put the code in the correct lines"?

Maybe I'm just misunderstanding you, but even if the bytecode sequence is reconstructed as the original code that produced it, stuff like whitespace and comments are simply lost with no ways to recover.

(Also, local variable names, certain annotations depending on their retention level, etc)

Post reply on HN