Friday, April 30, 2010
When we talk about cyber threats, we need to conceptualize the relationship between the person and the software entity. Cyber threats are not just about malware, nor just about a human actor. You can't separate the two. It doesn't make sense to talk about human threats that don't manifest in cyberspace. And, malware that isn't backed by human intent would cease to be a threat. Our job is to explore this relationship between a human and his manifestation in cyberspace. The very word 'cyber threat' implies this relationship. It's direct and basic.
Monday, April 5, 2010
I first presented active reversing in 2007 at the Blackhat show in Vegas. At that time, the concepts were mostly theory, backed by a few prototypes I demo'd during the talk. It's taken us three years but I am very proud to say we have stayed the course and delivered something that is a true game changer for reverse engineers. It works so well that it's cheating.
Active reversing is when you obtain program understanding via runtime instrumentation, data collection, and statistics. Active reversing puts the focus on volatile runtime behavior as opposed to static disassembly. This transforms the tradecraft of reversing in many ways. For one thing, it promotes reversing to a larger professional audience. People who are already comfortable reading packet sniffer logs can now reverse engineer software. The data collected from a point in memory resembles the kind of data collected by a packet sniffer, the only difference being the data structure of the packet is actually an internal structure within a software program. Observing just a string can reveal what a function is responsible for.
Active reversing empowers you to reverse engineer by exercising a software program's capabilities and features. Consider that runtime code coverage reveals which functions are executing and when. This allows you to simply observe which functions execute in response to an action you have taken with the software. For example, if you want to find the password handling function, just review which functions executed after you typed in the login information. Filtering can be used to remove code that has executed more than once, or code that has already executed in response to another action. This so-called background noise may represent utility functions and general purpose packet handling. Once filtered, you are left with only the newly executed password handler functions. This approach can identify functions when searching for data might be difficult - for example if the data is numeric and not easily predicted. More than anything, this approach is fast. In just a few minutes you can have most of the major features of a program mapped to code.
HBGary just published a very technical whitepaper on software exploitation using REcon, with lots of screenshots and step-by-step how-to. Check it out: Software Exploitation with HBGary's REcon.