I was searching for something completely different on Google’s video search and ran across this video of Tom Liston and Sherri Davidoff demonstrating cold-boot memory attacks at CanSecWest. As I have covered before, they used my msramdmp tool to make an image of RAM:
Aug 132008
Today, Jacob Applebaum is giving a talk at The Last HOPE conference on the tools they have for dumping and retrieving keys from memory after a cold boot. These are the tools that were demonstrated some months ago, and got everyone interested in the security of whole-disk encryption products. There was a lot of interest in the memory dumping tool, so since the Princeton tool had not been released, I wrote msramdmp.
The Princeton tools are now available here.
The key-finding code is definitely of interest, and ought to work with msramdmp images as well (although I haven’t tested the code at all, yet). From what I’m reading of the memory dumping code and docs, if msramdmp is currently suiting your needs, you may not need to change over, especially if you’re taking advantage of the fact that msramdmp will let you dump a few computers before having to pull the images off and reset the partitions. If, however, you’re wanting to dump more than 4 gigs on a 64-bit machine, dump over a network, or dump an EFI-based machine, the Princeton tools are definitely what you’ll want to start playing with now.
Very cool work, Jacob! Hope the talk goes well!
It’s a weekend, so I’m all for a fun post.
The sexyhacking.com videos are not safe for work, however they’re probably even less arousing than you’d think. They are hosted on YouTube, after all. You might want to have a look, though, since they’re funny (intentionally and unintentionally), and who knows how long they’ll actually be around.
In the second video, described as Episode 1 in a series called “Naughty Script K1dd13″, basic compilation and usage of nmap is covered by a somewhat disinterested teacher. It must be hot in the classroom, since she’s unbuttoned her shirt about halfway down. Strangely enough, while nmap is displaying its scan, they censor the IP addresses involved with COPS-style pixelization:
If you’re paying more attention to the terminal than the girl, you’ll notice that they’re not very thorough. At 3:49, we catch the video editor asleep at the wheel as the traceroute pops up :
…and at 3:50, the censor wakes up 
:
I’m not even sure why they’re attempting to hide the IP address. It’s stated in the narration that sexyhacking.com will be used as the target, and the IP address revealed above is simply what you’d get doing a DNS lookup of sexyhacking.com…
(so long as Dan Kaminsky isn’t angry at you)
So, to sum it up: If you’re redacting information out of a video you’re publishing, you not only have to worry about people being able to reverse engineer your pixelation (just black it out!), you’ll also have to make sure you blot it out of every frame .
Jun 032008
Last night, I received a phishing email wanting my university email account information. Whenever I’m picking through email headers, or any other kind of network forensics, I find it useful to punch the IP addresses I find into Google. You can often build a good image of what that particular system or network is used for, by reading abuse reports, exposed log files, logs of Wiki edits, and all sorts of other situations where an IP address might be indexed by a search engine.
This particular bad-guy IP is a great example of an IP address that has really made its mark on Google, so I’ll link the results here:
* Google search results for “196.3.61.4″
Off the eastern coast of Madagascar, there’s an island called Mauritius. On this island there’s the city of Ebene. In this city, there’s this building, the “Cyber Tower”. According to Whois, on the third floor of this building, there’s a computer being used for all sorts of phishing and fraud.
It would be “just another scammer”, but this one has a great sense of humor. Check out this diff on an edit made from that IP address on the Wikipedia entry for Advance fee fraud:
Very nice.
May 282008
I just received these two pictures via email from my major professor, and thought I’d share. They’re from a series of mock trials that were held for this past fall semester’s computer forensics class. The students had the opportunity to take the stand and present expert witness testimony regarding the evidence that they had examined as part of a class project. We had a real courtroom, a real judge, real attorneys, and another university’s students sitting as a jury. I sat as the accused for a few cases, and also helped guide the defense attorneys through some of the more technical aspects of the forensics.
Thankfully, with the inexperience of the expert witnesses, and coaching my attorney a bit (he had an engineering background, which helped), I was found to be not guilty .
A lot of older computers have issues with booting from USB. I have computers that I can’t boot from USB, and so do some people that have wanted to experiment with msramdmp. I have had a few people ask about booting msramdmp from a CD (and an email from one person who did it themselves!), so I’ve decided to make an ISO available of it.
Be warned however: There are some problems with doing things this way. You still must write the data somewhere! If your BIOS doesn’t allow you to boot from a USB drive, there’s a good chance that it won’t map them in a way that msramdmp can see or write to (although some BIOS might). You may wind up having to put msramdmp partitions on an internally connected drive, which would make this less of a desirable tool for pentests, but still allow you to experiment with imaging RAM. Experiment with this, your drives, and your BIOS to figure out exactly how you need to have everything set up.
You can download a bootable ISO of msramdmp here:
Note that this hasn’t been tested very heavily (I threw it together just now). If you run into problems with it, feel free to get in touch with me and I’ll try to help you out.
Yesterday I did an email interview with SCMagazineUS.com reporter Sue Marquette Poremba, and the article was published later in the day here:
It’s not a bad article by any stretch of my imagination, but there were some points that I felt were important, and brought up in the interview, that didn’t make it through the writing and editing process. I can definitely understand this, as SC Magazine isn’t my soapbox to stand on (that’s what this site is for). I posted these points as a comment to the article, but they appear to have been deleted or “lost”. While I think that’s strange, I’ll let it be, and just post my points here (these might make more sense if you’ve read the article):
- What I have written is not an “encryption scanner”. It simply dumps the contents of memory, in order to allow someone to data carve it for whatever they’re looking for, which could include images, passwords, text, or even encryption keys. My tool doesn’t “scan” for anything. It’s also kind of strange to call it “home-grown” in the title, and then refer to McGrew Security as a “research firm”. I suppose you could argue that both are true, though
- The problem that I mentioned that the Princeton researchers “got around” was the large footprint in memory of other techniques of imaging RAM, such as using Linux Live CDs, not whatever the article is implying was the problem (recovering data from RAM, I think?)
- One reason I wrote the tool was simply because the Princeton tool has not, as of right now, been released. I felt like it was important for security and forensic researchers and practitioners to be able to experiment and base further research off of a tool like this.
- I should have placed more emphasis on this in my response, but I think one of the most positive uses for this could be for forensic examiners/investigators. The ability to capture the contents of RAM with a minimal impact, when seizing evidence, can be very helpful.
- I have a lot of respect for the work that the Princeton researchers have done, and I think they have done an amazing job of raising awareness of an issue that’s been around for a long time.
These are things from the interview that didn’t make the cut, but I felt that people should know. It would have been nice if they would have kept my comment underneath the story, but this’ll just have to do. Everyone that I care about reads this blog anyways, don’t they 
!
Mar 052008
Matthew Geiger was kind enough to point out to me a very silly typo I had made when writing msramdmp. Rather than grabbing 8192 bytes every time I went through the loop in the first section of memory it dumps, it was only going through 8182. Ugh. This means that it was writing 0×00′s for the last 10 bytes of every 8k (but thankfully, only for the smaller first section).
It’s fixed now, so if you downloaded it before, you should go and download it again. Sorry about that .
…Firewire.
Kind of like the RAM remanence phenomenon that I wrote msramdmp to utilize, this is also something that I thought people already knew about. Firewire devices have direct access to the main memory of hosts that they are connected to, and you can use this access to dump sections of memory from computers you have temporary physical access to.
Metistorm has written up a nice post and script describing this technique, and is very modest about it. He’s been sitting on the script for 2 years, and also thought this was something everyone else already knew
It’s something else to add to your forensic/incident-response bag of tricks
I’ve been in email contact with a gentleman that’s wanting to get msramdmp integrated into his incident response USB toolkit. Here’s some of my thoughts on how one might could accomplish that, straight from my response to him:
To keep this thing very-low-footprint, it runs straight from the bootloader and accesses the disk directly through INT 13h bios calls. To reduce complexity and footprint, it doesn’t know anything about filesystems, and simply dumps memory to a partition, marked with a specific type (0×40).
You could probably get this working on your drive with this kind of partition layout:
- Primary 1: Very small FAT-16 partition, marked bootable – Install syslinux to this and put msramdmp on it like I discuss on my howto.
- Primary 2: The partition you keep all of your tools in, whatever filesystem, however you want it.
- Primary 3: A 2 to 4 gig msramdmp (type 0×40) partition, large enough to hold an image of RAM of any machine you plan to dump.
Between using it on different machines, you’ll want to mark the partition type back to 0×40 (msramdmp marks used partitions as 0×41), and zero it out with dd.
I haven’t tested this out, but there’s no reason this shouldn’t work, assuming you have a large enough drive to comfortably do it
Recent Comments