| When I'm Sixty Four (Bits) |
[Nov. 3rd, 2009|07:26 am] |
Sixty-Four bit computing is here! What does that mean? What will the impact be on computer forensics? I've written a tech note, When I'm Sixty Four (Bits) to explain the changes. (You could also use it as justification for buying some new hardware...) The first paragraph: Forensic examiners are going to have to process computers running 64-bit operating systems in the near future. While this won't affect people doing document forensics, it will require significant changes for those who do code based forensics such as reverse engineering, malware analysis, etc. |
|
|
| 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. |
|
|
| Hibernation File Signatures |
[Aug. 18th, 2009|04:31 pm] |
There are four legal values for the magic value at the start of the Windows hibernation file. This post details the values, hibr, (null), wake, and link, and the circumstances under which they are created. They represent, in order, valid hibernation data, successfully restored hibernation data, unsuccessfully restored hibernation data, and a link to a hibernation file elsewhere. During this work I also found three noteworthy things about the hibernation process.
The file format of the Windows hibernation file begins with a PO_MEMORY_IMAGE structure. This structure begins with a four byte magic value. Matt Suiche and others have written that this magic field can take on several values, but only two have been explained. The first value, hibr or HIBR indicates the file contains valid hibernation data. (The uppercase version is found on Windows Vista and later.) The other known value, all zeros, indicates the file has been previously successfully restored. In fact, when the file has been successfully restored, the first 0x1000 bytes of the file should all be zeros.
The other values thought to be legal in a hibernation file, wake and link, indicate either a failed restore operation or a link to another partition's hiberfil.sys file. This post explains how these methods work and provides methodologies for creating them.
These experiments were conducted using a VMware Fusion virtual machine running Windows XP Service Pack 3. The system was booted and hibernated normally. The virtual disk was mounted and the hibernation file was recorded. Here's the start of the hiberfil.sys:0000000: 6869 6272 0000 0000 13f6 0000 a800 0000 hibr............
0000010: 5a5b 0000 0010 0000 0000 0000 0000 0000 Z[..............
0000020: 1aea 39fe 1320 ca01 d431 cc19 0000 0000 ..9.. ...1......
0000030: ff3f 03a0 0200 0000 1000 0000 0000 beff .?..............
0000040: 00bf 0601 0000 0000 0003 0000 5045 0000 ............PE..
0000050: c6fb 0000 3d84 0000 0300 0000 5584 0000 ....=.......U...
0000060: 8145 839d 0000 0000 58f0 ef1e 0200 0000 .E......X.......
0000070: fe01 9004 0000 0000 797f 0e3f 1900 0000 ........y..?....
0000080: 3409 0000 9304 0000 2100 0000 c70f 0000 4.......!.......
0000090: 482d 0000 3d84 0000 20d4 3908 dd08 0000 H-..=... .9.....
00000a0: 0300 0000 0000 0000 0000 0000 0000 0000 ................ The virtual machine was restarted and allowed to begin restoring. When the progress bar was just shy of completion the VM was powered off. The virtual disk was mounted again and the hibernation file recorded. The second hibernation file was identical to first except for the first four bytes. Those four bytes had changed from hibr to wake:0000000: 7761 6b65 0000 0000 13f6 0000 a800 0000 wake............
0000010: 5a5b 0000 0010 0000 0000 0000 0000 0000 Z[..............
0000020: 1aea 39fe 1320 ca01 d431 cc19 0000 0000 ..9.. ...1......
0000030: ff3f 03a0 0200 0000 1000 0000 0000 beff .?..............
0000040: 00bf 0601 0000 0000 0003 0000 5045 0000 ............PE..
0000050: c6fb 0000 3d84 0000 0300 0000 5584 0000 ....=.......U...
0000060: 8145 839d 0000 0000 58f0 ef1e 0200 0000 .E......X.......
0000070: fe01 9004 0000 0000 797f 0e3f 1900 0000 ........y..?....
0000080: 3409 0000 9304 0000 2100 0000 c70f 0000 4.......!.......
0000090: 482d 0000 3d84 0000 20d4 3908 dd08 0000 H-..=... .9.....
00000a0: 0300 0000 0000 0000 0000 0000 0000 0000 ................ The VM was again restarted and it displayed a message, "The last attempt to restart the system from its previous location failed. Attempt to restart again?" The options given were "Delete restoration data and proceed to system boot menu" and "Continue with system restart" (Screenshot).
Researchers attempting to verify this result can also hibernate a system, manually edit the hibernation file while it's powered off, and then restart the system to achieve the same effect. Although this will allow you to see how Windows handles the file, it does not allow you to verify that Windows creates this file.
The link code allows the system to boot another hibernation file found elsewhere. According to the blog post How Windows Starts Up (Part the Second) , the link signature should be followed by an ARC path similar to those found in the boot.ini file, like this:
linkmulti(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
Note there is no space between the link signature and the ARC path. The ARC path specifies another partition where the bootloader searches for a hiberfil.sys file to restore.
There are three other noteworthy facts I discovered during this research. First, I found some information on Hibernate Once Restart Many (HORM) mode. This is a feature of Windows XP embedded that allows the system to be booted multiple times using the same hibernation file. HORM mode depends on the Enhanced Write Filter (EWF) which is not included with other editions of Windows XP. There are methods to enable HORM on Windows XP, but they are cumbersome at best. The best indicator of HORM mode is the presence of a file resmany.dat in the root directory. See also Microsoft's description of HORM and the official documentation.
Second, I verified that a Windows system will attempt to parse or even restore the contents of hiberfil.sys, even if Hibernation mode is not enabled in the Control Panel.
Finally, hibernation is not supported on any Windows XP, Server 2003, Vista, or Server 2008 system with more than 4GB of RAM. See http://support.microsoft.com/kb/888575/ for details. |
|
|
| BitLocker Paper Accepted |
[Jan. 14th, 2009|10:17 am] |
My paper on Microsoft's BitLocker, Implementing BitLocker Drive Encryption for Forensic Analysis, has been accepted for publication in the journal Digital Investigation. The paper has been significantly revised since I last wrote about it. The online version bears only a passing resemblance to the final version. As such, here's the new abstract: This paper documents the BitLocker Drive Encryption system included with some versions of Microsoft's Windows Vista. In particular it describes the key management system, the algorithms and modes used, and the metadata format. Particular attention is given to methods forensic examiners can use to access protected data. There are some unanswered questions about how the cryptosystem operates, including an undocumented key management decision. This decision could allow, in a particular usage scenario, unauthorized access to a protected volume. You'll have to read the published article to get the whole story! |
|
|
| The Windows Research Kernel and Memory Analysis |
[Oct. 23rd, 2008|07:26 am] |
When doing memory analysis research it is a huge help to have access to the program's source code. While it's easy to get access to open source programs like TrueCrypt and Linux, it becomes harder with closed-source systems like Microsoft Windows. Researchers connected to academia, however, may be able to get access to the Windows source code with the Windows Research Kernel.
Most memory analysis work to date has been based on published documentation or black-box testing. The field would be greatly advanced with access to the Windows source code. Although we can see the data structures that are involved thanks to the debugging symbols, without reversing the assembly code (which is possibly against the Windows license), there's no good way to see what the operating system is really doing.
There are some projects designed to create interoperable products such as ReactOS or Wine that can offer similar functionality. But they really don't tell anybody what's happening inside Windows. Without access to the Windows source code, we really don't know.
Although access to the full Windows source code is highly restricted, a version is available to academics. Specifically, the Microsoft Corporation has made a version of the Windows kernel available under the Windows Academic Program and under the terms of a specific license agreement. This version of the source code, the The Windows Research Kernel, can be compiled for both 32 and 64 bit platforms, allowing researchers to examine, modify, and compile their own versions of the Windows kernel. Ostensibly published to encourage instruction in operating systems construction, this product could also be used to further memory analysis.
..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... |
|
|
| Volatility Plugins for TrueCrypt passphrases, suspicious processes |
[Oct. 21st, 2008|10:19 pm] |
I've written two plugins for the Volatility memory analysis framework: - cryptoscan - Scans a memory image (or really anything) for TrueCrypt passphrases using the method described in Brian Kaplan's thesis, RAM is Key, Extracting Disk Encryption Keys From Volatile Memory, pages 22-23. According to that paper, passphrases are stored in a structure containing a passphrase length and then 64 bytes of passphrase data. The data must contain exactly length ASCII characters and all remaining bytes must be zeros.
- suspicious - Displays the command line from 'suspicious' processes. A process is considered to be suspicious by this plugin if it contains the phrase 'TrueCrypt' or starts with a lowercase drive letter. You are of course welcome to expand that definition!
To use these plugins, save them to the memory_plugins file in the Volatility distribution. From the command line, type:
C:\> python volatility cryptoscan -f [FILENAME]
These plugins only work on one file at a time. Enjoy! |
|
|
| New dc3dd published |
[Oct. 8th, 2008|10:14 am] |
Andrew Medico and the Defense Cyber Crime Center have published a new version of the dc3dd imaging tool. Corresponding to Coreutils version 6.12, this new version changes some of the defaults, fixes a few issues, and in general is much splefitier than the old version. Check it out! |
|
|
| The BitLocker paper |
[Sep. 10th, 2008|08:33 am] |
In the most recent CyberSpeak podcast I was interviewed about several topics including my work with Microsoft's BitLocker Drive Encryption. It's a great interview and I highly recommend it. Here are three additional resources on BitLocker.
First, you can check out my slides from the Open Memory Forensics Workshop. These detail how to find BitLocker keys in memory images, along with my interpretation of "tool marks" in computer forensics.
Second, you can now read my paper about BitLocker's key management system. (The paper has been submitted to Digital Investigation and has not been published previously.) The paper documents how to use each kind of key to decrypt the protected data. It also covers some parts of the key management system which I don't know why Microsoft included. Even with those parts included, however, I do not think there are any backdoors in BitLocker. Here's the abstractThis paper provides details necessary, given the correct keys, to access the protected data on volumes encrypted with Microsoft's BitLocker Drive Encryption. Although Microsoft published some of the BitLocker specifications there were details left out, particularly those regarding key management. Examples are given to demonstrate the cryptographic modes claimed. The author is not aware of any backdoors in the BitLocker system, meaning forensic examiners must obtain the necessary encryption keys to access a protected volume. There are, however, some unanswered questions about how the cryptosystem was designed and operates, including an undocumented key management decision. Finally, the patient among you can wait for my presentation, "Practical Methods for Dealing with Full Disk Encryption" at the 2009 DoD Cyber Crime Conference. The conference will once again be held at the end of January in St. Louis, MO. Bring your mittens! |
|
|
| New version of ManTech dd |
[Aug. 7th, 2008|08:36 am] |
There's a new version of ManTech dd, our program for imaging RAM from a live system. The program now has a driver to support 64-bit versions of Windows 2000 and XP. It can also be run from a CDROM and has better error handling. Just in time for the Open Memory Forensics Workshop too! |
|
|
| 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
|
|
|
| md5deep and Cygwin Ports |
[Jul. 19th, 2008|01:07 pm] |
Thanks to a blog post by Mark Stam about using md5deep, I've discovered that md5deep has been added to the Cygwin Ports project. The project "provides Cygwin binary and source packages for a large variety of programs and libraries, including the GNOME and KDE desktop environments." This means that Cygwin users can download a binary package of md5deep and its associated tools.
Because I'm not a Cygwin user it's hard for me to test out the automatic installation method, but it appears that you should be able use Cygwin's Setup program to get those ports by adding ftp://sunsite.dk/projects/cygwinports to the server list.
And yes, the screenshot in Mark's post does look a little odd. I'm looking into it. |
|
|
| Let's try that one again |
[Jun. 17th, 2008|12:27 pm] |
ManTech has released a new version of mdd, our Free tool to capture the contents of physical RAM from a running Windows machine. You can download the Windows executable or the source code.
Again, although I'm not involved in the project I'd like to apologize for the confusion. The original version of the executable was linked against the debugging version of some Microsoft libraries. If you didn't have the debugging version installed, which most sane people don't, the program wouldn't run. This caused different but equally unintelligible errors on Windows XP and Windows Vista.
To clear up the confusion regarding the license, I've been authorized to say that mdd is licensed under GNU General Public License, version 3. The source code package now includes the complete source code and a copy of the license. The omission of these two was an oversight. Again, my apologies.
I hope this new version of the program will work for everybody and get them started down the road to memory analysis happiness! |
|
|
| Clarifications on mdd |
[Jun. 14th, 2008|09:08 am] |
I am amazed how fast the news about ManTech dd is spreading. This is fantastic! I've also gotten some good feedback too. Based on that feedback I'd like to make a few clarifications:- I didn't write mdd and am not involved in the project. I appreciate the kudos I've gotten, but they belong to the guys in our Texas office! My only role in mdd is marketing. [grin] Your best points of contact for development are, in order of preference, the bugs, support request, and feature request forums on SourceForge. Failing that, you can write to the maintainer directly. His email address is on the project homepage.
- The source code is in the .zip file. Yes, it appears that the source code for the driver component isn't in there. Please contact the developers as noted above.
- The project page says the license is GPL. No, there's no license file in the .zip file. Please contact the developers for clarification.
Have fun imaging memory this weekend! |
|
|
| Introducing ManTech dd |
[Jun. 13th, 2008|04:01 pm] |
I am pleased to announce that my company, ManTech, is publishing a Free tool that lets users acquire physical memory on a running Windows system. mdd is a GPL licensed driver based program that runs on Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. Other Windows platforms (e.g. Windows 9x, Windows 7, Windows 3.11 for Workgroups) are not supported. The driver has been signed by Microsoft and will work on 64-bit versions of Windows Vista. You must have Administrative privileges to run the program successfully. Some Frequently Asked Questions about mdd Q. Where I can get mdd?
A. It's available free from http://mdd.sf.net.
Q. How do I use mdd?
A. From a Windows command prompt, just type mdd. The program will write the contents of RAM to the file dump. You can change the filename of the output using the -o flag.
Q. Ok. I have a memory image, now what?
A. There are several Free tools you can use to analyze Windows memory images. The Volatility project is a great framework for getting started. There are also scripts by Harlan Carvey, Andreas Schuster, and many more!
Q. How does mdd compare to George Garner's dd?
A. Older versions of George Garner's dd were able to image physical memory. Unfortunately the technique used by that program does not work on any version of Windows after Windows 2003 Service Pack 1 (e.g. Vista, Windows XP Service Pack 3, etc.). Also, the current free version of George Garner's dd, now part of the Forensic Acquisition Utilities, does not allow the user to capture memory. Mr. Garner's company, GMG Systems Inc, sells a product called KnTDD that offers this functionality. KnTDD gathers a whole bunch of other data that might be useful during a forensic examination. On other hand, it costs money. Which is better? It depends.
Q. I've found a bug in mdd, now what?
A. Please report any bugs in the bug tracking system.
Q. What does the 'm' in 'mdd' stand for?
A. I say it's for ManTech dd, but others say Memory dd. This will probably end up like the debate over how to pronounce "Linux".
Q. Can I help update the documentation for mdd?
A. Yes! There is an entry for mdd on the Forensics Wiki. Please feel free to add your experience with the program there. |
|
|
| DFRWS Paper Accepted |
[Apr. 28th, 2008|05:38 pm] |
I am pleased to announce that my paper, Using JPEG Quantization Tables to Identify Imagery Processed by Software, has been accepted for the 8th Annual Digital Forensics Research Conference. The abstract: The quantization tables used for JPEG compression can also be used to help separate images that have been processed by software from those that have not. This loose classification is sufficient to greatly reduce the number of images an examiner must consider during an investigation. As illicit imagery prosecutions depend on the authenticity of the images involved, this capability is an advantage for forensic examiners. This paper explains how quantization tables work, how they can be used for image source identification, and the implications for computer forensics. See you in Baltimore! |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| [ |
go |
| |
earlier |
] |
| |
|
|
