64 bit systems are more than 10 years old, but only until recently did they emerge in the market. In the past, 64 bit was found doing the “hard stuff” - complex fluid mechanics, computational modeling, and ultra large databases. Today they are mass market - it’s hard to find a 32 bit machine, and you pretty much have to custom order to get XP. More complex applications are going to demand upgrade - virtual environment collaboration for example - but even more important is just the fact we are dealing with large data - think > 4GB files. If you need an example, think of a DVD movie. Multimedia alone is driving upgrades in the consumer market.
64 bit architecture is just plain faster - it's not so much about the CPU speed - it's more about how much data can be moved. Data movement is more important, IMHO, than Data calculation for most users. With the possible exception of codec's and compression, people just don't USE their CPU's (Video cards with cooling manifolds, GPU's, and "Left 4 Dead" addicts aside :-).
This means “big” things for memory forensics – and also malware analysis in terms of the 64 bit operating system. While I think malware will continue to be coded in 32 bit (for maximum compatibility if nothing else) the stations they infect are migrating to 64 bit windows.
Simply stated, workstations are the point of penetration into the Enterprise. It’s the place we care most about analyzing. To understand malware from our (that is, HBGary’s) point of view, we need to understand the operating system – and by this I mean Windows Vista 64bit, Windows XP 64bit, Windows 2003 64bit, and Windows 2008 64bit. We follow the OS, we find the malware. Pretty much any pre-2008 rootkit technology just raises its hand “here I AM” in an offline memory analysis. From a rootkit developer’s point of view, things are happening live-action, hooking a function pointer makes sense because the HIDS is going to be totally subverted. Offline, everything changes. Said hook is a big red flag waving “over here – find me over here!” But, of course, this means being able to analyze the OS data structures in the first place. Hence, the importance of 64 bit.
HBGary released the 1.3 version of Responder a few days ago. This is the 64 bit platform upgrade. It includes analysis of 64 bit Windows platforms, and the FDPro dumping utility that can dump physical memory images from 64 bit systems (including those that require signed drivers). This was the longest development iteration for our team so far this year. The 64 bit upgrade was a lot harder and more work that I originally expected – there were upgrades and point-fixes in every part of the product from the GUI controls down to the memory-acquisition routines. Over 1,000 points of code had to be fixed just for 64 bit address and offset support. Yeah, big job. And the testing, wow… So here it is. I think HBGary might be the first to market with 64 bit support (that means analysis AND acquisition, and full shipping non-alpha). The new version of FDPro is pretty nice too, supporting compression and probing, speed upgrades, and nearly 100% reliable memory-page queries even for systems with more than 4GB of RAM.
I am glad this release went out the door and hopefully I won’t spend the rest of the year in a troll-cave. I’m going to be in New York City next week and also a few days in D.C. showing off the new bits. If you’re a current customer you should click the upgrade button in the about box :-) Contact sales@hbgary.com for an eval and the website is www.hbgary.com.
p.s. Thanks to everyone who uploaded me 64 bit memory dumps for QA – you’re the best!
