Ask HN: Is there any defense against LLM-based reverse engineering? | Hacker News Reader

Ask HN: Is there any defense against LLM-based reverse engineering?

3 pointssemidror11 comments

Recent news headlines [1] about LLM-based reverse engineering make it seem that anyone with a monthly subscription is capable of translating any executable into an equivalent source code representation.

If this is true, then how can one guard against having their source code essentially unveiled with the correct semantic meaning of the underlying algorithms by someone with an extremely low amount of effort? I bet that using obfuscators would still not be enough.

I'm distinguishing between recreating the source code of your software vs vibe coding an inexact clone without knowing your source code (which is not exactly reverse engineering).

Example: Imagine it would be possible to faithfully recreate the source code of the firmware running on a foreign military device, even with correct semantic meaning of variables, functions and of the whole algorithm. On the other hand, vibe coding a clone would require that you know the underlying algorithm (or at least that you have a high-level idea of how does it work), which you don't have for such device.

Does it mean that companies like Denuvo are now out of business (assuming anything can be reverse engineered with the correct semantic meaning)?

[1] https://news.ycombinator.com/item?id=50028275

For the firmware case specifically, some embedded processors support encrypted, signed firmware and encrypted memory. The physical defenses of the processor would need to be defeated to recover the unencrypted binary. That's not impossible (defeat of protections on game consoles being an example) but it would take physical access to the hardware and specialized tooling to even attempt.

Maybe that's a possible future? Chips are not that expensive compared to the price of an app so each app can come on its own SOM in a cartridge to run its core logic. The computer just serves as a terminal and auxiliary compute server to the app cartridge.

Interested and following as someone wanting to maximize reverse engineering capabilities.

IMO it's a double-edged sword. What if, as a direct consequence of the new RE capabilities, there eventually won't be any new "juicy" binaries to decompile because every important piece of software will run on a company's server while you will have just a thin client (as someone pointed in [1])?

Even remotely.

At a certain point, an AI looks at what the software does and figures out what functions would produce the observed results.

If it turns out to be different to the original, but stil gets the job done, how often will the distinction matter?

This is the way.

“Computah, replicate target system. Use whatever resources are required to build requirements and specs, ship to software factory when necessary.” Whenever models and harnesses improve, improve reverse engineering accordingly.

Reverse engineer anything with agents, from app behavior down to native binaries - https://news.ycombinator.com/item?id=50058850 - October 2026

https://github.com/morluto/rea

https://rea.tools

AI is mass decompiling games. That's both awesome and scary - https://news.ycombinator.com/item?id=50088534 - October 2026

Patents and copyright.

Turning a binary into source code that would compile into an identical-to-the-bit binary seems like it would be a copyright violation (caveat: IANAL).

Even an imperfect copy would (again, IANAL) sound to me like a patent law question.

Copyright laws didn't even pause the Big AI companies from hoovering up all material to train their systems. With their financial and thus legal resources they would be very expensive to sue for patent infringement.

Possible crux: I see this discussion as being about the users of LLMs using them to develop software, not about the developers of the LLMs themselves.

Sounds like you're arguing about the developers of the LLMs?

> Copyright laws didn't even pause the Big AI companies from hoovering up all material to train their systems.

Sure they did. That even came up in some of the court cases which they lost, and then settled out of court.

I don't think anything new here is actually all that novel: the only thing that's changed is there used to be more of a skills and time gap than there is now.

IANAL, but I've worked with a lot of lawyers in my life on software licenses on technical products and am also currently building a platform (ZeroQuarry) which uses some decompilation/disassembly tools (not for rebuilding source software, but rather to find underlying vulnerabilities).

Tools for reverse engineering have existed for a long time (Ghidra, IDA Pro, cavaj, and a bunch of other language-specific tools), which is why most commercial companies producing non-OSS executables have put in caveats that you can't "reverse engineer or decompile, decrypt, disassemble or otherwise reduce the Software to human-readable form".

Some of these tools and underlying source code/compilation mechanisms required more skill/time than others, and now with AI, just like in software development, multimedia creation and editing, etc, the barrier to entry and the skills needed to produce something have collapsed to the point that many novices can at least "get started" at virtually no cost. A lot of people on the "builder" side have reached for obfuscation to make it more difficult (a suite of tools has been available there for a long time as well), but all that does is raises the cost of decompilation, and that cost is on an exponentially decreasing cost curve: it was never really a viable defense against "advanced" actors: the only defense against them was legal guards.

To me, I think the more interesting legal conundrum we're entering isn't pure decompilation/deobfuscation/disassembly, but rather the "clean room" carve out. Several big tech companies (Compaq vs IBM, NEC vs Intel, etc) have gotten away with using 1 team to decompile a piece of code and then have that team write a spec for a clean-room team to re-implement without looking at the decompiled software. That was deemed legal over several court cases, and now it's effectively trivial as well. Or just have an AI with vision capabilities click every button in a UI, see how they work, build the spec from there, and you don't even need decompilation tools, as we're now seeing with the Adobe suite of products: https://getartcraft.com/apps and many others

I honestly can't think of a real protection for these companies/products except signed/encrypted software at the lowest level, but that only protects companies against non-interactive software (or the non-interactive components). Some people might be old enough to remember that some software used to ship with physical devices that were the physical keys used to allow encrypted software to run. Maybe some of that makes a return?

Reply on news.ycombinator.com