| BitLocker To Go, Google Earth Forensics at DoD Cyber Crime Conference |
[Sep. 9th, 2009|10:29 am] |
I have been selected to give two presentations at 2010 DoD Cyber Crime Conference in January 2010 in St. Louis, MO. Unfortunately the St. Louis Blues will be out of town during the conference. Does anybody have some ideas on what to see and do during the off hours? The Stella Artois Anheuser-Busch tour? The gourmet burger bar? What else?
My first talk will be on BitLocker To Go, how Microsoft has extended BitLocker Disk Encryption to removable devices like USB sticks. You can learn how the technology works, how it uses passwords and smart cards, its applications for force protection, and how the protected data can be accessed during forensic examination. The second talk will cover Google Earth cache file forensics. You'll see what data is in the file, how it's stored, and how it can be viewed.
Speaking of BitLocker, we discussed the tool in the most recent CyberSpeak podcast, published on Monday. The show was recorded live at the SANS What Works in Computer Forensics conference a few months ago. You can listen as Ovie and Bret interview me, Harlan Carvey, Ken Bradley, and Rob Lee on a host of topics. |
|
|
| Last Call for Volatility Bugs Before Release |
[Jul. 30th, 2009|06:37 am] |
The Volatility Framework is looking to wrap up our month-long call for bugs before the next official release. The framework is a great way to experiment with memory forensics on Windows XP systems and I recommend it for anybody interested in this new field. You can grab the last official release, Version 1.3 Beta 1 from the web site or the latest code (patched yesterday!) directly from http://code.google.com/p/volatility/ before the final release next week.
If you find something that should be fixed, please either leave a comment here or write to the developers mailing list. We appreciate the feedback and are looking forward to big release Real Soon NowTM. |
|
|
| Introducing hashdeep and faster md5deep |
[Jul. 29th, 2008|06:27 am] |
I am pleased to announce the release of md5deep version 3.1 along with a new program, hashdeep. Along with some cosmetic bug fixes, this version of md5deep should be about 10-15% faster than version 3.0 thanks to the removal of some redundant code. The new hashdeep has two primary features, multihashing and hash set auditing. Multihashing is the ability to compute more than one hash algorithm simultaneously. Technically this feature isn't really "new", per se, it's been a part of programs like FSUM and Dan Mares' hash for years. The real magic is in the hash set auditing.
Auditing Hash SetsThe benefits of hash set auditing will be fully described in the paper Audiing Hash Sets, hopefully to be published soon. Here's the abstract:
Auditing a set of cryptographic hashes allows a forensic examiner to determine the state of a target directory as compared to those hashes. Unlike traditional hash comparison methods, an audit takes into account all of the files in the target directory and their relative paths. Not taking these data into account can impair examinations and tool certifications. An audit examines each file in the target directory, computes its hash, and compares it to a file containing the known hash values. Any file not in the set of known hashes is flagged as being inserted. When all of the files in the target directory have been examined, any known hashes that have not been matched are flagged as being missing. The result is a complete picture comparing the set of known hashes and the target directory. I'll post more details on the paper as they become available. In the meantime, here's the complete list of changes in this version of md5deep:
New Features - Added hashdeep program to support multihashing and hash set auding
- Streamlined file size computation process, which makes the programs about 15% faster.
- Added size threshold modes to only process files smaller than a given size.
- Added a timestamp mode that records the creation time time for each file on Win32, the change time on all other operating systems.
- Added support for new iLook style hashes
Bug Fixes - Corrected time estimates for large files (e.g. files which require more than one day).
- Fixed obscure bug that caused a crash (double free) when attempting to check a very small file for EnCase hashes
|
|
|
| Humor o' the Day |
[Sep. 27th, 2007|04:53 pm] |
Today I got an email from .... .... ...... ..... who is trying to put me in touch with ..... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... ....... The message ended with, "Can I make this connection?"
My response: SYN-ACK |
|
|
| The Forensics Wiki |
[Mar. 5th, 2007|09:02 am] |
Recently I've been doing a lot of work on the Forensics Wiki. Our goal is to create an open repository for information on computer forensics tools, methods, and best practices and we need your help to do so. It's been slow going so far as there is an immense amount of knowledge out there and only so many contributors. But we're starting to pick up speed now as other people are joining the fun. It's a lot easier to get content for current events, as such as the volatools and Caprica Six tools unveiled last week. But we've also assembled a list of people interviewed on the Cyberspeak Podcast and some good background on FRED and incident response.
If you've never seen a wiki before, come on over and take a look. If you've seen a wiki but thought that editing one would be hard, think again! There's a great visual interface to help you with all of the formatting. If you have any questions, don't hesitate to write to me or any of the other maintainers. |
|
|
| Buffalo Paper Accepted |
[Jan. 8th, 2007|08:29 am] |
I am pleased to announce that my paper "Using Every Part of the Buffalo in Windows Memory Analysis" has been accepted for publication in the journal Digital Investigation! I should have a preprint available soon, but here is the abstract:All Windows memory analysis techniques depend on the examiner’s ability to translate the virtual addresses used by programs and operating system components into the true locations of data in a memory image. In some memory images up to 20% of all the virtual addresses in use point to so called “invalid” pages that cannot be found using a naive method for address translation. This paper explains virtual address translation, enumerates the different states of invalid memory pages, and presents a more robust strategy for address translation. This new method incorporates invalid pages and even the paging file to greatly increase the completeness of the analysis. By using every available page, every part of the buffalo as it were, the examiner can better recreate the state of the machine as it existed at the time of imaging. |
|
|
| The Naming of Tools |
[Jan. 4th, 2007|02:00 pm] |
I watched the movie Rocky the other day and got to thinking about how the right name can make all the difference. In the movie, Apollo Creed was coming to Philadelphia for a title fight when his opponent backed out. Still wanting to put on a show, he chose to fight Rocky Balboa, aka The Italian Stallion, after only reading his name in a list. "Apollo Creed versus the Italian Stallion. Sounds like a damn monster movie," he quips. The name alone sold the goods.
These days, the first thing I do after thinking up an idea for a project, even before figuring out if it's possible, is to come up with a name. Why does the name matter so much?
To explain, let's set the wayback machine to the summer of 2000. I was working with Kris Kendall on a piece of software to recover deleted files by searching for their headers and footers. This program, which eventually became foremost, was a rewrite of the DOS-based CarvThis. Looking to distinguish our new tool, we chose a name that was a synonym of carving, namely digging, and a reference to what it was digging for, namely file headers. We chose the name "dighead" and were quite satisfied with it. That is, until the day I had to stand up and say that name as part of a presentation. I was nervous and was speaking too fast. Try saying "dighead" a little too fast and notice what it sounds like. We changed the name that afternoon.
Later that summer the FBI's Carnivore tool made headlines. Although it was only a full content monitoring tool like Snort or tcpdump, the name alone conjured up fear. News articles decried the tool and civil liberties groups had a fit even before the details of its operation were made public. I learned that the name of a thing gives people a distinct impression of what it is long before any details can be explained. That impression, for good or for ill, is what people remember. If the name doesn't look good on the front page of the New York Times, it's not a good name.
At a training course a few weeks later, we learned all about incident response procedures. During a hands-on portion of the course, I diligently executed a series of commands, recorded their output, and documented my work. The procedure worked perfectly. During the second exercise, however, I noticed that we were running the exact same commands again. With my belief that computers are supposed to be labor saving devices, I found this repitiion a little pointless. I wrote up a batch script to run those commands for me, and viola, created a new method of incident response: the automated incident response tool.
But this tool needed a name. It needed something that appeared harmless to bad guys, friendly to first responders, and effective at gathering evidence. After some playing around I came up with The First Responder's Evidence Disk, or FRED. Everybody likes Fred! He's a buddy! A pal! After publishing a paper on my innovation, the rest was history. FRED took off like wildfire and eventually became a part of other incident response tools like the HELIX project. Many other organizations developed their own FRED-like tools and even gave them similar names (e.g. WILMA, Pebbles, BAMBAM, etc.)
Was FRED the best incident response tool out there? It's debatable. But it was good and had a good name. Those two things, working together, helped to make it great. There are lots of good ideas, but good ideas with good marketing are the ones that go the distance. |
|
|
| New Curriculum Vitae |
[Nov. 18th, 2006|11:36 am] |
Having just published one paper and (hopefully) submitting another one soon, I decided it was time to give my Curriculum Vitae a new look. The old version was HTML, and although functional, a real pain to update. This new version was made with LaTeX thanks to a template from Jason Blevins. What do you think? |
|
|
| HTCIA Report, Day 1 |
[Oct. 31st, 2006|02:03 am] |
The first day of the HTCIA conference was not quite what I expected. ........ ....... ...... .... .................... .... .... .... ... .... ........... ....... ...... .... .................... .... .... .... ... .... ........ .......... ....... ...... .... .................... .... .... .... ... .... ........ .......... ....... ...... .... .................... .... .... .... ... .... ........ .......... ....... ...... .... .................... .... .... .... ... .... ........ .......... ....... ...... .... .................... .... .... .... ... .... ........ ....... ...... ....... ...........
Somehow my conference registration got lost and the organizers had no record of my existence. Thankfully the staff working the desk recognized my name as a speaker and got me a badge. It took a few minutes, but gave me a chance to have a cup of coffee and schmooze. At this point, however, things threatened to go downhill.
The first speaker I hoped to see did not check in to the conference; I hope he's ok. The second called in on Sunday to say he'd broken his leg. The lunch speaker overlapped with the first session of the afternoon so I didn't get to hear much of what he said. Finally though, I caught some good talks in the afternoon and early evening.
I'm now back in my room furiously rewriting my presentations on fuzzy hashing and Windows memory analysis. Although the talks were good, they were far too impractical for the crowd here. Right now I'm surrounded by cops from the Lower Elkswhich County Police. They have no use for which functions are O(n) versus O(n2), but care greatly about what can be taken to court and what can't. |
|
|
| Push data to the pagefile |
[Oct. 11th, 2006|11:15 am] |
One of the next steps in Windows memory analysis will be to parse the paging file (aka virtual memory). The operating system stores data here when it doesn't fit into main memory. A number of researchers have sought a way to reliably push data to the pagefile so that they can practice finding it.
I've written a simple program that attempts to allocate an infinite amount of memory and thus pushes other things out to the pagefile. The program's copyright notice is longer than the code and is available as a Windows executable or source code. Quitting the program by hitting Control-C will free up everything again. Have fun! |
|
|
| Exploiting the Rootkit Paradox |
[Sep. 27th, 2006|04:51 pm] |
My latest journal article, Exploiting the Rootkit Paradox with Windows Memory Analysis has been published in the International Journal of Digital Evidence! The abstract:Rootkits are malicious programs that silently subvert an operating system to hide an intruder's activities. Although there are a number of tools designed to detect rootkits, these programs are competing with the rootkit for system resources and allowing the rootkit to actively evade detection. By taking a memory image of the system, a forensic examiner can conduct a more thorough search for rootkits and even without discovering one directly, infer the presence of one. This paper explores how an examiner can create such a memory image and use the inherent properties of rootkits to find them in those memory images. |
|
|
| Speaking at DoD Cybercrime |
[Sep. 20th, 2006|12:58 pm] |
My presentation for the DoD Cybercrime conference, "Recovering Executables from Windows Memory Images," has been accepted. I will be speaking at 1330 on Thursday, so mark your calendars now. You don't want to miss how you can recover, from a Windows memory image, an executable essentially as it existed on the disk. See you in St. Louis!
The full agenda and the track listings have been published too. |
|
|
| Comments on Data Recovery |
[Jun. 18th, 2006|01:48 pm] |
My friend ![[info]](http://l-stat.livejournal.com/img/userinfo.gif) cipherpunk posted a great article about data destruction. While I think he's on the right track, I'm not sure his advice is entirely practical for the everyday users. Sure, large organizations can have a dedicated data destruction coordinator who can oversee that every drive is overwritten or melted down. But for the rest of us, the amount of effort needed to securely wipe a drive should be the minimum necessary to protect us against the reasonable threat.
The reasonable threat, and to his credit cipherpunk does encourage people not to paranoid, is that your old drive will be bought and connected to a new system in an ordinary manner.
As such, here is my opinion on what to do with your used hard drive to protect your data:- Smash the drive, broadside, four times with a hammer, halfway between the center and the edge of the drive at each of the compass points.
That's it! Aside from being some great stress relief, if you're lucky enough to hit the drive head it makes a really cool PING! sound. The hammer will also break the mechanism that spins the drive making it impossible to get any data out without taking the drive into a clean room. Only specialized forensic firms have such clean rooms and access to them isn't cheap. Unless you're carrying around secrets for nuclear weapons (and I hope you know you are) there's no need to go any further.
Yes, this method means that you won't be able to sell your old drive on EBay, but it will keep your credit card numbers, diary entries, and goat pr0n out of the hands of others. In my opinion, losing ten bucks on the sale of a used hard drive is worth the peace of mind. |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| [ |
go |
| |
earlier |
] |
| |
|
|
