As someone who does it for a living the challenge can be in both. However this article is asking its agents to do CTF like challenges which I am sure the respective LLMs have seen millions of so it can essentially regurgitate a large part of the exploit code. This is especially true for the OOB/RW primitive API.

Yea, this entire repo/article seems super misleading to me. Not to mention asking it to generate API for OOB R/W primitives is essentially asking it to regurgitate what exists on thousands of github repos and CTF toolkits.

Most modern kill chains involve chaining together that many bugs... I know because it's my job and its become demoralizing.

Vulnerability Researcher/Reverse Eng here... Aspects about it generating an API for read/write primitives are simply it regurgitating tons of APIs that exist already. Its still cool, but its not like it invented the primitives or any novel technique. Also, this toy JS is similar to binaries you'd find in a CTF. Of course it will be able to solve majority of those. I am curious though.. Latest OpenAI models don't seem to want to generate any real exploit code. Is there a prompt jail break or something being used here?

I had similar questions when reading the original article. I’m also interested in how the agent is constructed. From my experience, it can be very difficult to implement exploits without access to debugging tools, so I’m curious whether pwndbg or similar tools are included in the agent’s toolset and, if so, how they are integrated. Existing open-source GDB MCPs don’t work very well unless further optimized, at least the last time I checked.

It is pretty and it can do pretty much exactly what Rust enums do if they learned basic idiomatic Go.. Rust is a cult at this point honestly.

No its because 99% of the time people use enums to give names to magic constants... That is it. Go went for simplicity and const+iota achieves it just fine. People act like enums make or break software itself or something.

That seems unlikely to me to be the actual explanation. It could very well be what you prefer or how you would do it, but I can definitely assure you that the Go/other infrastructure teams think about these problems and hear plenty of complaints about lack of union type support.

Yea but with a tiny bit more effort they could have ensured that an invalid value is never assigned to an enum, iterate over the values, ensure switch statements handle every case, etc.

What is with people and their need for enums? Functionally using go const with iota gives you the same damn thing and people use enums that way 99% of the time. I find Rusts reliance on enums annoying as hell. At this point I consider Rust a bandwagon language. The syntax is abysmal and we have had memory safe languages far before Rust. That I wont get into because as a Vulnerability Researcher I find the Rust push super misguided and it sets me off.

To be more clear, I want sum types with exhaustive matching - which Go does not support.

I get by without it Go enums are an inferior representation of the same logical concepts. Sure, I can have (kind, value) and cast things for a hacky sum type for some kind enum. But Go lacks closed enums/exhaustive matching.

You can at least validate the match arms with things like type switches and marker interfaces, but they're still not exhaustive and they're terribly verbose.

And, again, I can get by without them! But I miss them because Rust-style enum representation comes up _so often_, even if you don't like the rest of Rust.

> What is with people and their need for enums?

I mean, you have atomic and compound data types. Atomic ones represent single values, like "a string" or "an integer", and compound ones represent multiple atomic types combined in some way, like a struct or an enum. Enums are useful for the same reason structs are useful, they do the same core thing, just model it in a different way. It's the difference between "and" and "or", which are both useful tools.

They don't seem to understand Go much at all. Comparisons to Rust are somewhat misplaced but that's a different topic... Back to errors. Errors are interface values. They are simple yet powerful. You can create sentinel errors that can be wrapped or just passed to be checked then discarded. Go has all the functionality it needs to provide what ever it is Rust cult members believe makes Rust error handling so great. You can use the primitive constructs Go provides to do nearly the same damn things Rust can do and it won't look like a pile of hieroglyphs your local crackhead would draw. Best of all... Its simple and the syntax of Go (veering off topic) doesn't make me want to jump off a bridge. Stop gaslighting yourselves into thinking Rust syntax is reasonable and that its some perfectly proven language with all edge cases put to rest..

Isn't this just fractal page mappings? Am I missing something?

I hold a R&D Position at an MIT lab. I also hold gov clearances for DoD work. They are pretty accepting of the fact that a lot of folks in the field are neurodivergent. No one cares because if you deliver results you deliver results. No one cares about shit under the Trump administration because its an absolute joke that has thus far only stood to get in the way of the way we carry out research. The party of "minimal government" sure as hell loves to tell public established institutions how to carry out their own damn business.