I really appreciate the work of the Broadcom exploit by P0 (cool that Halvar gets a shoutout)!

Constructive observation:

I wish people writing exploit-reports would start with the reveal or outcome and *then* show how they got there.

Too often the author takes the reader on the full journey from the the start. The problem is that the author already has end-result context but the reader does not.

The reader, at the end, is forced to re-parse earlier elements when they get the final context.

@Mudge it is a bit like reading academic papers, read the abstract, introduction and the conclusions before the rest of the paper

@Mudge Back when I was in the MSRC I always appreciated the vuln reports we got from ZDI. They'd start with the end result 'double free in IE 7 results in privilege escalation', then give more detail around the 'why', then you'd get the dump at the end that my V&M team could use to repro. Should be an industry standard format

@Mudge that is an interesting observation. I often call it the "marketing" vs. "engineering" approach. Former has more immediate impact, shows results first and leaves details about how to derive them for later. The latter is how engineers & exploit developers work, bottom up. Both are needed in my opinion: TL;DR exec summary & detailed blow-by-blow account

@Mudge the same applies (perhaps even more) to conference presentations. I am always hoping to find the TL;DR of the presentation in the 1st 5 minutes

@Mudge I agree, and same thing holds with other forms of writing too. Working toward a big reveal can put people to sleep before you get there.

@Mudge This is a common failing in tech writing I find… it's hard to write as if you have no context when you know the punchline.

Sign in to participate in the conversation

The original server operated by the Mastodon gGmbH non-profit