A common source of confusion for entry-level Reverse Engineers and Forensic Analysts is the difference between virtual and physical memory. When following the execution flow and data usage of a piece of malware through a physical memory snapshot, a lack of understanding can mean the difference between a wild goose chase and a successful reversing session leading to the discovery of an advanced persistent threat.

Physical memory, as the name implies, is the hardware that provides volatile storage for a computer. Virtual memory, on the other hand, is a conceptual memory space, often much larger than the physical memory provided by hardware. This conceptual memory space is managed by the operating system. The 32-bit versions of Microsoft Windows®, for example, organize memory by providing every running process with 4GB of virtual memory, which is used to store both executable code and data (it is worth noting that only 2GB of this virtual memory is available to user-mode code, while the rest is reserved for kernel-mode code). Obviously, if every process has that much memory to work with, it can’t all fit into physical memory at one time, so Windows® uses a process called paging to persist lesser-used memory to disk, and maintains a series of maps (most notably the Paging Directory and the Virtual Address Descriptor) to correlate virtual addresses to physical addresses and swap memory on and off disk as necessary.

When working with a physical memory snapshot as part of your computer forensics investigation, you will frequently come across addresses being used in a push or jmp instruction. These addresses are virtual, and if you try to simply browse to that offset in the physical memory snapshot , you will find that you’re looking in the wrong place, or that the address is outside the bounds of the physical memory entirely. To find the correct physical memory location, you have to walk the Paging Directory and VAD Tree for the process in question, and translate the address manually. If the instruction in question exists within a defined module, then a shortcut can be used by finding the offset in the section header and use that to jump to the correct location in physical memory. These techniques require a very detailed understanding of how memory is managed in Windows® as well as a level of patience that most entry-level analysts simply don’t have.

HBGary Responder™ Automatically Translates Virtual-To-Physical and Physical-to-Virtual Memory

HBGary’s Responder™ provides these shortcuts and translates virtual addresses to physical and vice-versa automatically, dramatically shortening the amount of time spent on analysis by both entry-level and experienced analysts. In the following two screenshots, you can see the same area of memory, but you’ll notice that the addresses displayed on the left are different.

Responder Disassembly View with Physical Addresses

Responder Disassembly View with Virtual Addresses

In the first screenshot, physical addresses are being displayed offset from the start of the module. In the second screenshot, virtual addresses are being displayed. Notice in the first screenshot the final instruction jmp dword ptr references a virtual memory address. It’s impossible to tell exactly where that jmp instruction is going to from the first image, but becomes extremely clear in the second image, where you can see that the jmp takes us back to the first line of the code segment.

Automatic Address Navigation

Even without virtual addresses being displayed, Responder™ simplifies the process of tracking addresses down by automatically translating addresses that you double-click on and taking you to the correct offset in the physical memory view. For example, if you double-click on the address (note the darker aqua bar indicating the selected line)

Responder Disassembly View with Virtual Address Selected

Responder™ will automatically select the correct line for the destination address even when not displaying virtual addresses:

Responder Disassembly View with Correct Physical Address Selected

Reverse Engineers and Forensic Analysts are always looking for better and faster ways to triage unknown code and come to conclusions. Jumping back and forth between Physical and Virtual memory spaces can be one of the more significant time-sinks and can be prone to error. Having a tool like Responder in your pocket can both lower the barrier to entry and shorten the path to success.

Web developers face many challenges in this newly-forged cyber-world. Where once your site had to have something people wanted before it got hacked, now your site is being attacked simply because it can be. Lists of sites with known vulnerabilities float around the internet like an à la carte menu for the under-skilled, impatient hacker. Hacking has become a game show of sorts, with each new participant vying for their 5 minutes of fame on Twitter. In this world, you must assume that you are under attack at all times.

Standing naked in public is always an uncomfortable experience; even more so when people are throwing rocks at you and trying to pull your hair out. That, however, is exactly what a web site does every day. The only way to survive is to keep things neatly trimmed and move fast.

Common web site vulnerabilities like SQL injection and cross-site scripting are easily overcome through proper coding practices. Nice and neat, nothing to grab hold of there, and rocks are bouncing harmlessly off of you. Then, out of nowhere, a walnut-sized rock hits you square between the eyes. Once the stars clear from your vision, you look down at the rock and notice the unmistakable contours of password re-use. You just made the fatal mistake of forgetting that your web site is, by and large, used by human beings, and not ones you can count on to help you keep your site secure. This problem, unlike the others, can't be solved with techniques that are invisible to the user.

Passwords represent a uniquely human challenge in the world of computing. To be effective a password must be complex and difficult to guess, with a mixture of various character types to thwart rainbow table lookups, but at the same time easy to remember for the individual using the password. For a human being, this is a self-contradicting set of requirements. Most people have a hard enough time remembering all of their relatives' birthdays, much less remembering that Ph3n0m!n@l is their password on one site while B1gD@ddy657 is their password on another. Yes, they can have a little cheat sheet with their passwords on it or some electronic equivalent, but from their point of view, it's so much easier to just have the same password on every site. And so guess what? That's what they do most of the time.

You should know that passwords are going to be re-used, and it simply does not matter how small or obscure your site is, and it simply does not matter if you believe that you have a controlled user base that would never, ever re-use passwords. They will. I assure you. If you allow authentication on your site, someone just authenticated with the same password they use on Facebook. Knowing that you can't stop your users from committing this sin, what can you do to keep it from impacting your site? The answer, in almost all cases, is Multi-Factor Authentication.

Multi-Factor Authentication comes in many forms, and has been around for many, many years. When working as a Systems Administrator for MCI twenty years ago, one of my responsibilities was to maintain the "code blocks", little more than an LCD display hooked to a chip and a quartz crystal. Embedded into the chip was a time-based algorithm to generate a pseudo-random but predictable number every ten seconds. When logging in to the MCI sales system, you had to enter the code currently displayed. The matching algorithm on the server would validate the entry, and you would be authenticated. Similar technology is still in use today by companies like Blizzard Entertainment to protect their online gaming assets. Google Mail offers several options for a second factor of authentication, all of which involve generating a random number for each authentication request, and then transmitting it to the user on an alternate channel, such as by SMS message or voice telephone call.

The key to successful Multi-Factor Authentication is to have a piece of secret data that the user does not have access to prior to the authentication attempt, and to deliver that secret data to a specific physical device that is under the user's control. In the case of MCI and Blizzard, that device is a portable LCD display. In the case of Google Mail, it is your mobile or landline phone. Now the hacker not only has to guess, reverse, or find your password, but they have to have physical access to your mobile phone or other device as well.

Nothing will stop hackers from trying to throw rocks and pull hair, but there are things you can do to thwart their attempts. Multi-Factor Authentication is easy and cheap, and raises the hacking requirements from a simple rainbow table attack that any script kiddie can pull off to something worthy of a Hollywood blockbuster. As someone who stands naked in public a lot, multi-factor authentication provides that extra dose of assurance, knowing as I do that most hackers are not Tom Cruise, and probably very few of them have zero-gravity repelling gear or flying motorcycles.

- Michael Snyder