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.
@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. ;-)
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...
Most will not end up writing exploits but it should part of a basic training.
So please keep doing it for us!
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!