I am not a forensics expert, nor do I play one on TV. I do, however, play one at work from time to time and I own some of the key tools: a magnifying glass and a 10baseT hub. Oh, and a Sherlock Holmes hat – that’s the key. Unfortunately, these weren’t much help when I was handed a pile of drives and was asked to find out which version of Windows they had been running. I wasn’t allowed to boot them, and I couldn’t really find the full answer of how to get the version after a lot of googling, so I figured it out the hard way. Hopefully I can save you guys some time by explaining it in detail.
And if there’s a better way, which I’m sure there is, please let me know. I don’t doubt that I did this the hard way – that’s kinda my thing.
The order of events is, basically:
- Step 1: Copy the system's registry hive to your analysis system
- Step 2: Mount the registry hive in regedit.exe
- Step 3: Navigate to the OS version in regedit.exe
- Step 4: Unmount the registry hive.
If you know how to do all that, then thanks for reading! Check back Tuesday for a brand new blog posting! I have an interesting blog that combines DNS and cross-site scripting lined up.
Otherwise, keep reading. Or just look at the pictures.
Exotic XSS: The HTML Image Tag
There are the usual XSS tests. And then there are the fun ones. This is a story about a more exotic approach to testing XSS….
I was testing a company that had passed all XSS tests from their pentester. I found that they allowed users to write HTML tags. Of course they didn’t permit <script> tags or <iframe> tags. (Well, they did allow those, but that was an oops - no server side filtering.) This company had whitelisted a variety of “safe” tags for use by clients.
Nmap script to generate custom license plates
In honour of this special day, I’m releasing an Nmap script I wrote a few months ago as a challenge: http-california-plates.nse. To install it, ensure you’re at the latest svn version of Nmap (I fixed a bug in http.lua last night that prevented this from working, so only the svn version as of today will work), download http-california-plates.nse, and install it.
Comments should work again!
So, I realized that the reCAPTCHA plugin for Wordpress
sucks was marking a lot of comments as spam, when it was actually working and not getting timeout errors (thanks to my egress filtering). I decided to toss it out and go with a math-based CAPTCHA for posts, so you should once again be able to post comments reliably! I’m hoping that by customizing the math CAPTCHA to use different field names/numbers, it should eliminate the same amount of spam that reCAPTCHA did.
Also worth noting: at the moment, registration isn’t going to work because I don’t have email set up. I’ll post an update to that when it’s going again. It shouldn’t matter, though, registration isn’t required to comment.
I also added an infobox on the side (–>) with information about the author of the post, since I’ve been taking turns with my buddy Matt Gardenghi lately. Now you can see who posted what.
If anything isn’t working, or you’d like some feature/widget/whatever that I don’t currently have, let me know!
Taking apart the Energizer trojan – Part 4: writing a probe
Now that we know what we need to send and receive, and how it’s encoded, let’s generate the actual packet. Then, once we’re sure it’s working, we’ll convert it into an Nmap probe! In most of this section, I assume you’re running Linux, Mac, or some other operating system with a built-in compiler and useful tools (gcc, hexdump, etc). If you’re on Windows, you’ll probably just have to follow along until I generate the probe.
Taking apart the Energizer trojan – Part 3: disassembling
In Part 2: runtime analysis, we discovered some important addresses in the Energizer Trojan – specifically, the addresses that make the call to recv() data. Be sure to read that section before reading this one.
Now that we have some starting addresses, we can move on to a disassembler and look at what the code’s actually doing. Fortunately, the author made no attempt to disguise the code or pack or or anything like that, so a simple disassembler is all we need to examine the code.
A word of warning: this is the longest, most complicated section. But stick with it, by the end we’ll know exactly how the Trojan ticks!
Taking apart the Energizer trojan – Part 2: runtime analysis
In Part 1: setup, we infected the system with the Trojan. It should still be running on the victim machine. If you haven’t read that section, I strongly recommend you go back and read it.
Now that we’ve infected a test machine, the goal of this step is to experiment a little with the debugger and learn a little about the Energizer Trojan. This can all be discovered with a simple disassembler, but I find it more fun to take apart a live sample. All we’re going to do is add a breakpoint at the recv() function and see where it’s called from.
This step is going to require Debugging Tools for Windows. If you haven’t installed it already, install it on the victim machine.
Taking apart the Energizer trojan – Part 1: setup
As most of you know, a Trojan was recently discovered in the software for Energizer’s USB battery charger. Following its release, I wrote an Nmap probe to detect the Trojan and HDMoore wrote a Metasploit module to exploit it.
I mentioned in my last post that it was a nice sample to study and learn from. The author made absolutely no attempt to conceal its purpose, once installed, besides a weak XOR encoding for communication. Some conspiracy theorists even think this may have been legitimate management software gone wrong – and who knows, really? In any case, I offered to write a tutorial on how I wrote the Nmap probe, and had a lot of positive feedback, so here it is!
Just be sure to take this for what it is. This is not intended to show any new methods or techniques or anything like that. It’s a reverse engineering guide targeted, as much as I could, for people who’ve never opened IDA or Windbg in their lives. I’d love to hear your comments!