AV vendors track various malware .dll's by their md5 hash. if we have that info in crash reports related to malware like in bug 633445 and other bugs hanging off the malware tracking bug. what we would need to participate in this system of identification would be to compute the hash at the time the crash report is being generated, then send it along in the crash report. other info that is useful to surface is the path to the suspicious .dll's but that info might also already be in the the report. size of each .dll in the module list might also be helpful.

also, we probably don't want to surface path to the suspicious .dll's in socorro's public reports.

Full paths are present in the minidump already, we just don't expose them. The problem with calculating an MD5 sum is that it's one more thing we'd have to do in the already-crashed process, which is tricky. Might be more feasible once I fix bug 587729.

No, we don't want to calculate the MD5 sum of anything in the process. It needs to be the MD5 sum of the file on disk. That's what AV vendors use, and that is much more stable than the sum of anything that is in memory.

Uh, well, we still need to do that at some point. When do you recommend we do it?

We definitely shouldn't do it until after the crash as it's a pretty expensive operation. But I thought that the crash reporter ran in a separate process than the one that crashed?

Well, the crash reporter client does, but the minidump generation is all done in the crashed process, and the crash reporter client doesn't actually know how to read the minidump files, so it has no idea what modules were in the crashed process. bug 587729 will change it so that we actually do the minidump generation in the crash reporter client, and then this will be much more feasible.

It would be better to use a stronger hash than MD5 if possible, but if MD5 all the AV vendors use then MD5 is better than nothing.