Let me try & put your mind at rest a bit.

(a) everyone @ msft takes the confidentiality of data uploaded to Watson (the crash reporting system) extremely seriously - you can't just 'look for useful stuff' in it without a good reason, and you'd be fired immediately if you were found to be reverse-engineering or copying bits of code out of it

b) on a technical level, trawling through dumps looking for 'useful stuff' would be an absurdly inefficient way to do anything. For one thing, it just crashed, which in my book is not usually a sign that you'd want to copy it.

c) your crash dump is a drop in the ocean. There are millions coming in. Nobody will ever look at it unless the system picks up that there a multiple millions of crashes occurring at the same point in the same widely-used app, in which case it's possible msft might contact the vendor (if identifiable) to offer to help fix it.

See http://oca.microsoft.com/en/dcp20.asp

Yet surely the virus authors themselves aren't experiencing "millions of crashes" during the early development stages that Heckman is describing. So how does he find their code, given what you've said?

Clearly, there must be some red flags which cause even small numbers -- perhaps single -- crash reports to get human attention at MSFT.

The crash database can be trawled after the hostile code is found in the wild.

Exactly. Many exploits rely on crashing components of the system. Depending on configuration settings a system may automatically be sending in watson reports for certain kinds of crashes. This makes it possible to track down the origin of a virus / worm after the fact. Step 1: take notice of the exploit in the wild. Step 2: determine it's method of operation. Step 3: correlate watson reports with exploit (likely there will be many of these). Step 4: backtrack to the oldest reports which might be from when the exploit was being developed, then dig out as much information from those reports as you can.

Certainly this doesn't work all the time, but even if it worked only very rarely it'd still be a pretty substantial payoff.

Yes, that must be it, thanks.

But then the same thing could apply to non-malicious/competitive code, too. Once it proves interesting to Microsoft, they could mine the past crash history for background info.

I can believe internal controls and culture mitigate this risk -- but sheer volume doesn't provide confidence of confidentiality for non-malware coders any more than it does for malware coders.

Look at it this way -- the Watson system is pretty important in improving the quality of Windows (let's assume that more quality -> more sales). If coders (most of whom work in a corporate environment) ever found out that Microsoft was looking through their code for a non-emergency reason, they'd immediately turn off error reporting on all of their systems (not to mention, file a few lawsuits), removing sources of crash errors from a sector that is vital to Microsoft (and leading to a decrease in the quality of Windows, and thus, fewer sales).

So it's in their best interests to keep those internal controls as strict as possible in order to avoid such a thing.

Much more likely, something along the lines of - Microsoft security people searched through their database of crash logs for (however fragmentary) evidence of people attempting to develop exploits. This probably works particularly well in the case of vulnerabilities known to Microsoft but not yet publicly disclosed.

That sounds about right

Actually, they check to see WHAT caused the crashed. In the case of a virus writer, that would be the virus' code. How could they not look at it? It IS directly related to the crash.

The problem I have with that story is that there are a lot more people writing software for the MS platform than just the virus writers and I figure that if you add that all up the virus writers are a drop in the bucket.

So this applies to all developers, not just to the ones writing viruses.

True, but most developers aren't writing code that attempts to bypass Kernel Patch Protection[0]

[0]http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.m...

If you are starting a club of skeptics on this matter, I am hereby applying for membership...