I suspect the reason why most exploit code is so messy to read is that while writing the exploit you're still figuring out the "architecture and language" of the thing you are attacking.

There are so many false starts, and so many false assumptions when you start.

A simple false assumption can start you down a wrong path for weeks... but often you can't easily verify that it is false before starting.

Follow

@HalvarFlake Plus a lot of the time it's: calc popped, done! Next vuln, please. (Unless it's going into "production" and you have to clean it up and make it reliable)

Sometimes just by reading the exploit code you can clearly see the thought process the author went through at the time and the rabbit holes they went down etc (especially when code based on old/wrong assumptions is merely commented out not deleted) I often found that insight immensely helpful.

@kwanre I am thinking it would be extremely interesting to publish full git history of a convoluted exploit, with measures how much code was deleted and how long everything took.

@HalvarFlake @kwanre in the past few years I decided to go back and re-write my exploits once they are "good enough" because I want them to be more clean/accurate/readable, not just for others, but for myself.

I'll never forget the emails from a leaked email spool around ~2002 when the US Army said one of jduck's exploits was "the cleanest we had ever seen". And it was. ;-)

@donb @kwanre @HalvarFlake Maybe also some of the exploit developers are just not good software developers. Like literary critic who never really staged his own play.

@saper @HalvarFlake @kwanre I think that absolutely used to be true. It used to blow people's minds to put more than system() shellcode in a payload. Today, I think the best exploit developers are also engineers because they have to be.

@saper @kwanre @donb I kinda disagree. I have done good software dev, and I have done exploit engineering.

When I do software engineering, I have a vague idea about where I am going. With exploits, you have 180-degree turns & rollbacks all the time.

@HalvarFlake @kwanre @saper did you read my recent blog post on the RISC-V MCM flaws?

A point I made in that piece is that exploit engineering (in the context of complex exploit dev) requires a thousand-foot view of an entire technology to succeed, while engineers are often cordoned off to specific subsets of technologies.

Complementary skills, but very different perspectives.

@donb @saper @kwanre @HalvarFlake I disagree that an exploit dev has to understand the whole technology. Finding vulns is basically: this thing takes input in this way and it probably goes to something that looks like a similar thing I've seen before so I'll try this kind of attack.

Then exploiting it is a deep dive, not broad learning. Recent example: I wrote the Struts OGNL injection module and I still don't know fuckall about what Struts does or how it works from an engineering perspective

@egypt @HalvarFlake @kwanre @saper yes in that context I fully agree with you. I've written a lot of Linux kernel bugs before I understood anything about the Linux kernel.

I'm talking here about systemic issues that are harder to find unless you understand the relationships between technologies and their security models.

@donb @saper @HalvarFlake @egypt it really depends on the target imo. Back When Flash exploits were still interesting, in order to exploit a vuln you had to be intimately familiar with AVM and various quirks of the system, the same is true in general of browser exploitation, I really have to know Chakra if I'm targeting Edge.
Then again in most of those cases you are basically manipulating the higher abstraction layers to achieve a nicely exploitable heap layout.

Thank you @HalvarFlake : this is good to know!

Actually I wish more devs had exploit experience to kind of feel various attack vectors.

@donb @kwanre

@saper @kwanre @donb In a way, exploit dev is often a bit like a brainfuck programming competition, except with a new BF dialect for each attack...

@saper @kwanre @donb But to be honest: I am not sure I wish exploit dev experience on most devs. It's a strange thing to do with one's time.

The best dev I ever worked with, when I explained to him how I earned my living, was like: "Wow, this sounds like the most horrible computer job imaginable." :-)

I have to admit I really enjoy switching between dev and vulndev, even at the cost of making me both a worse dev and worse vulndev...

@HalvarFlake @donb @kwanre nobody says it is easy or pleasant, nor should be. But it is like learning a new foreign language, it may open your mind to a whole different world.

Most will not end up writing exploits but it should part of a basic training.

But maybe I demand too much in the times where it is enough to know JavaScript only:)

So please keep doing it for us!

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!