[HN Gopher] How to get a heart attack while using JEB decompiler...
___________________________________________________________________
How to get a heart attack while using JEB decompiler (2022)
Author : todsacerdoti
Score : 119 points
Date : 2023-02-13 09:52 UTC (13 hours ago)
(HTM) web link (blog.stmcyber.com)
(TXT) w3m dump (blog.stmcyber.com)
| Dwedit wrote:
| Please clap.
| bbayer wrote:
| Why would a decompiler execute code that has decompiled?
| fps_doug wrote:
| For further deobfuscation you might want to record runtime
| stats and code flow.
| nneonneo wrote:
| 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...
| Karliss wrote:
| 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).
| JosephRedfern wrote:
| Seems pretty wild that JEB would _default_ to just turning the
| sandbox off when `SecurityManager` is missing.
| tetha wrote:
| 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.
| flykespice wrote:
| .
| saurik wrote:
| None of this information is required for the article to be
| written and would be a distraction from the point of the
| article.
| [deleted]
| gg-plz wrote:
| From the headline, I worried that the author may have been live-
| debugging their own pacemaker. But this is still pretty bad.
| [deleted]
| blinkingled wrote:
| > 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.
| vips7L wrote:
| 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.
| [deleted]
| nneonneo wrote:
| 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.
| ActorNightly wrote:
| >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.
| Joker_vD wrote:
| 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.
| flangola7 wrote:
| 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.
___________________________________________________________________
(page generated 2023-02-13 23:01 UTC)