How to get a heart attack while using JEB decompiler (2022) | Hacker News Reader

How to get a heart attack while using JEB decompiler (2022)

blog.stmcyber.com

127 pointstodsacerdoti19 comments

Gosh, that's really, really bad. The absolute last thing I need is for my reverse engineering tools to wantonly execute code out of the (very very likely up-to-no-good) binary I'm reversing.

In general the state of reverse engineering tool security seems pretty bad. Common tools like binutils (objdump, readelf, gdb, etc.), IDA, and even Wireshark have had memory corruption bugs. For example, it's pretty easy to get Wireshark to crash on a NULL pointer dereference in some random dissector when fed arbitrarily naughty pcap data. It's bad enough that I do almost all of my reverse engineering work inside various VMs that have strict isolation from the host. I'd have expected a Java-based program like JEB to be better at this, but apparently they got lazy and decided to just eval() the untrusted binaries...

I would not be entirely surprised if some state-level actor somewhere booby-traps their binaries with exploits like these to figure out who's looking at their stuff.

Yeah, when I was studying ELF format I used gdb to inspect hand-crafted ELF files to better understand what actual semantics some fields actually have (or how they're supposed to validated) and I was quite surprised when it would segfault on disassembly attempt — not the program under inspection but the gdb itself. IMHO for a debugger to segfault when attempting to inspect the program under it because the program has wrong headers/corrupted memory layout or whatever is completely inexcusable: the reason you attach debugger to a program is generally because it went (spectacularly) spoiled and curdled and now you try to figure out what the hell happened.

When I debug gui/gtk2 programs, gdb manages to sometimes freeze my entire desktop

I have to kill gdb from outside the X server to do anything else

>The absolute last thing I need is for my reverse engineering tools to wantonly execute code out of the (very very likely up-to-no-good) binary I'm reversing.

Given things like Log4Shell and Spring4Shell seems like there is a lot of software written in Java where authors just willingly add capability to execute random code and see nothing wrong with it.

We really just need hard native application isolation like Android and iOS offer. Other than zero-day sandbox escapes, there's very little a malicious Android app can do if it has been granted no permissions and no file system or internet access.

Seems pretty wild that JEB would _default_ to just turning the sandbox off when `SecurityManager` is missing.

Agreed, I would have expected this to fail shut and require some flag to function. Inconvenient, but in this case, I'd prefer to be inconvenienced and safe rather than conveniently owned.

Yeah. This should have been a HUGE INCREDIBLY LOUD FLASHING RED WARNING SIGN when they implemented the code execution feature. Like, "wait what if the in-built jvm sandboxing isn't available" should have been among the first questions. And it isn't too terribly difficult to implement your own sandboxed interpreter if you don't have access to the SecurityManager.

Heck, SecurityManager has been basically a dead feature for ages. I'm stunned that JEB didn't start with a different solution.

From the headline, I worried that the author may have been live-debugging their own pacemaker. But this is still pretty bad.

Why would a decompiler execute code that has decompiled?

For further deobfuscation you might want to record runtime stats and code flow.

The context of the log messages seems to imply that it's part of an automated (or semi-automated) string decryption system. Many binaries obfuscate strings using some simple encryption algorithm to defeat trivial analysis (i.e. "strings"), and manually reversing those is tedious. It's nice to have an automated decryption routine, but not so nice if it consists of just eval() with no sandbox...

Even if the binary isn't malicious executing random parts of a program has high risk of breaking or at least polluting the current system. Most executables will have some side effects on the system due to interactions with file system or other processes. There is no point in having executable which only crunches numbers in a loop with no sideeffects (unless it's a benchmark or something like ls executable) so in most cases there will be sideffects. And doing them in uncontrolled manner will be pure chaos. Something as seemingly harmless as backuping software can overwrite stuff if not executed in correct way.

Assuming sandbox is working correctly any parts with sideffects will probably not be very productive for deobfuscation anyway. Such automated decryption strategy would work best for purely functional parts of code. But the parts that interact with os and filesystem are either not part of decryption code (so no point executing) or if they are part of decryption they are probably the parts which try to defeat such automated decryption by detecting sandboxed/emulated environment and stopping decryption (again no point executing it without some manual intervention or very carefully designed fake environment simulating a specific target).

> And since Java Security Sandbox doesn't work on Java 18 without an additional console flag - it executes code without any sandboxing on your host machine.

Whoever changed Java 18 to indirectly cause sandboxes to stop working - do they bear some responsibility here? Don't know the details of this particular case but have been burnt before by defaults changing to insecure before.

No, they don't have responsibility here. The security manager is deprecated and will throw UnsupportedOperationException when trying to set it in Java 18. This means the developers of JEB willfully ignored this.

No. SecurityManager has been a defunct feature forever and its removal was widely communicated.

Please clap.

None of this information is required for the article to be written and would be a distraction from the point of the article.

Reply on news.ycombinator.com