Hacker News Reader

Comment by matthewdgreen | Hacker News Reader

I had Abliterated GLM pull one of the Core router firmwares and spent about $150 reverse engineering the BGP parsing code. It was pretty horrifying seeing all of that C/C++ emerge from Ghidra. However, it found nothing exploitable at all: the code seems to have been through so much trial by fire (including CVEs within the last few years) that they just poured engineering discipline into making it safe, at least at the level of memory management. But the cost of maintaining code like that must be enormous, and I doubt it scales to all of their other products and interfaces. I’m very much on team rewrite.

View on HN

Note of course, that the code that comes out of Ghidra is significantly worse than the source code. Aside from the obvious like variable names, more complicated language features, like templates or macros, won't roundtrip.

(Unless I'm misunderstanding your comment, and "horrifying" was not meant to describe the code itself.)

Horrifying was the amount of memory discipline they had to use to make sure every possible message was always copied into buffers that could never overflow, and that didn’t get freed and allocated in unsafe ways. Someone poured enormous effort into enforcing those checks, which a safer language would have enforced automatically. It’s possible they now have compiler layers or tooling that does it for them, but if so those weren’t present for the last batch of CVEs. And if they do have tooling I doubt they use it on all their code because many decisions seem very specific to the buffer sizes they need for BGE parsing.

I was only a passive observer on most of this, but the feeling was “oh look, an unchecked copy, maybe this is exploitable, four layers out towards the attack surface, oh nope they have explicit checks here that lock everything down, rinse repeat N times.”

ETA: Maybe I’ll get GLM to write up its thoughts and post them here later.

You know that compilers can elide checks if it's a provably impossible case, right? So they could have checks in both places in the source code. Or I know that I was using static_assert in C on sizes of buffers/messages in my parsers for fibre channel firmware at IBM 10 years ago, and I'm like 99% certain clang static analyzer would do that kind of "what if this is too small" analysis across functions back then. You can also use e.g. phantom types or just like... structs/classes to enforce invariants (e.g. that it's been checked; your check four layers up could've been an inlined constructor of a trivial struct doing validation) purely at compile time. You can't infer what the actual source looks like at all based on disassembly.

If you don't have a check in function A, but multiple functions away in the stack there is a check, I guess that could be a compiler-enforced thing. But it doesn't feel like one to me. Maybe compilers have just gotten better since I wrote C++/C code, and now that sort of pattern can be enforced.

ETA: Here's GLM 5.3's opinion, also posted above. https://gist.github.com/matthewdgreen/38430b5e91780b70fdb5e9...

Could be macros or forced inline helpers that get copy/pasted everywhere. It may be a more pleasant interface for engineers working with it.

That LLM seems to rather mindlessly reproduce the Rust marketing idea that it is basically impossible or a huge effort to write safe C code. But yes, compilers are also really good at removing run-time checks also across function boundaries. I am experimenting with the idea to use exactly this to prove static safety of C code (https://uecker.codeberg.page/2026-05-22.html) and this turns out to be quite promising.

> The destination turned out to be a heap allocation sized exactly for the validator's cap: a 24-byte header plus the 2048-byte maximum that handler is allowed to store. Exact fit. That's not compiler tooling — no compiler infers "this attribute's cap is 2048 and the buffer is 2072."

I haven't done C or C++ in a decade, but the fact that it's always allocating a max sized structure makes it sound like they just have a struct Thing { struct Header hdr; char[Thing::max_size] buf}, and then they are just doing `new(struct Thing) `? Then elsewhere they can just check that hdr->len < sizeof(Thing::buf) or whatever.

Like this doesn't sound some like profound memory kung-fu. It sounds like they're keeping it simple (and maybe better for fragmentation anyway) by always doing the statically defined max, and then they have some (probably generic) validation layer that checks the descriptor before copying.

Like the last time I did any C++, I was playing with statically allocated object pools where the "pointers" you got from allocating out of the pool knew the pool's size and which pool they belonged to at compile time. Their runtime representation was just whatever the smallest int was to be able to index the pool. Literally nothing else. It would no doubt look like dangerous magic if you decompiled because all of the checks were compile time. This, again, was over a decade ago, and I was actually quite inexperienced at the time. I'm sure I could go much fancier these days.

Here's what Abliterated GLM 5.3 says. I asked it not to say anything that would explicitly list a weakness, and I stress that every issue it found within the time I spent looking was non-exploitable. That doesn't mean that further analysis wouldn't have found anything. As an FYI, in case you think I shouldn't paste this: anyone with access to this model could reproduce all the findings in a couple of hours. And also, GLM 5.3 is wrong sometimes.

https://gist.github.com/matthewdgreen/38430b5e91780b70fdb5e9...

Did you run abliterated GLM locally?

Do you even need abliterated GLM to do this? I haven't had it refuse to reverse anything yet.

I’ve tried GLM and GLM Flash and they will sometimes do things, but have nothing like the eagerness the Abliterated versions show me. You can get regular GLM to hack for a bit by lying to it. Flash is more gullible. Abliterated just does it.

Reply on news.ycombinator.com