4 ms·
So when you're writing code on windows and it crashes and you, accidentally or not, hit the "send report to Microsoft" not only does it send them your code (pre
by almost 16y ago
So when you're writing code on windows and it crashes and you, accidentally or not, hit the "send report to Microsoft" not only does it send them your code (presumably they mean the compiled bytes here) but Microsoft then checks over it to see if there's anything useful there, even stuff not directly related to the crash...
- umibozu 16y agoIf you are starting a club of skeptics on this matter, I am hereby applying for membership...
- pvg 16y agoMuch 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.
- almost 16y agoThat sounds about right
- wccrawford 16y agoActually, 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.
- jacquesm 16y agoThe 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.
- JBiserkov 16y agoTrue, 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.mspx http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.m...
- edyoung 16y agoLet 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 http://oca.microsoft.com/en/dcp20.asp
- gojomo 16y agoYet 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.
- Daniel_Newby 16y agoThe crash database can be trawled after the hostile code is found in the wild.
- InclinedPlane 16y agoExactly. 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.