?

Log in

A Geek Raised by Wolves [entries|archive|friends|userinfo]
jessekornblum

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| Browse by Tag LiveJournal Portal Update Journal Logout ]

Beta version of ssdeep 2.10 [Jul. 10th, 2013|12:09 am]
jessekornblum
[Tags|, , ]

I have published a new (beta) version of the ssdeep tool for fuzzy hashing. Although reserved for testing purposes only at this point, this is an exciting development for several reasons.

First, this version contains a complete re-write of the hashing engine itself. The code, written by Helmut Grohne, is now thread-safe. Please note the ssdeep program is not multi-threaded—yet. But the library on which its based can now easily be used in multi-threaded applications.

Second, this version fixes a long-standing bug regarding long file paths on Windows. By default, paths are limited to 255 characters. There is a way to extend that limit, however, which I have finally gotten around to implementing.

Third and finally, this version contains a few miscellaneous bug fixes.

That being said, of course, this is a beta version and I'm sure there are a few new bugs I've introduced. The first person who reports each new, reproducable bug gets a free beer from me. Please post those bug reports to the SourceForge site.

Thanks, and happy fuzzy hashing!
LinkLeave a comment

Standard 64-bit Windows Memory Image [May. 23rd, 2013|11:13 pm]
jessekornblum
[Tags|]

My recent posting showed me there are no standard, public 64-bit Windows memory images. There are several public Windows memory images, but none of them are from a 64-bit Windows system. In order for us to replicate each other's work, it's important to have a standard memory image to reference.

I've taken the liberty of creating such an image and publishing it. In a few weeks this image will be transferred to the Computer Forensic Reference Data Sets project at the National Institute of Standards and Technology. In the meantime, however, you can download the image, joshua1, from https://dl.dropboxusercontent.com/u/55819714/joshua1.zip (209 MB). The system was a 64-bit Windows 7 Home Premium running Service Pack 1.

(This link will be deprecated on or about 1 July 2013.)
LinkLeave a comment

Modified Buffalo [May. 21st, 2013|07:52 pm]
jessekornblum
[Tags|, ]

Some recent changes to the Volatility™ code (r3414 and r3420) altered how my Buffalo patch fits into the source code. As a result, I had to update the patch. You can get the new version from both the official enhancement request and on my web site. The instructions from my last post should now work again. Thank you M‐ to pointing this out to me!


Volatility is a trademark of Verizon. Jesse Kornblum is not sponsored or approved by, or affiliated with Verizon.
LinkLeave a comment

I got a fever! And the only prescription... is more buffalo! [May. 16th, 2013|12:51 am]
jessekornblum
[Tags|, , ]

Six years after publishing the "Buffalo" paper about using invalid memory pages in forensics [3], I have implemented a method for using prototype page table entries. I apologize for the delay.

As demonstrated below, you can use this technique to pull more data out of your Microsoft Windows memory images. As an example, the existing Volatility™[5] code can recover ten out of 58 modules from a particular process. Using the code I am publishing today, you can recover 32 of them. Please note that this code is still experimental and should be used for testing purposes ONLY.

The code is currently under review by the Volatility™ development team and will hopefully be included in their next release. The rest of this post contains some background on prototypes, a demonstration of this implementation, and instructions on how you can test it yourself.

Background


The Buffalo paper described the invalid states of memory on the x86 architecture. In computer science terms, "invalid" doesn't mean "bad", just "not immediately available." Attempting to access invalid memory generates a page fault. The operating system and architecture must handle the page fault and make the memory valid. They may need to read data from the paging file, from some other file on the disk, or return a page to the working set of the process which requested it.

There are many references for page fault handling. My personal favorite is the 6th edition of "Windows Internals" [4], pages 267-279. But when it comes to prototype page table entries, the writeup from the Code Machine, http://www.codemachine.com/article_protopte.html, is outstanding. I won't even attempt to explain these structures, but will just ask you to read that article instead.

Certainly an argument can be made that any data which can be recovered using prototype page table entries isn't that special. In order for this method to work, the data has to be available in some process' working set, perhaps just not the one you're considering. That's absolutely true. You could look at this code as merely a convenience. But I argue that it can be a huge convenience, especially when the examiner doesn't know that the data in question is available anywhere.

Here's a real-world example. Let's say we wanted to recover all of the modules from a process. We'll use the firefox.exe process from the xp-laptop memory image [6], pid 3276. Here's what happens with the current Volatility™ trunk code:

$ svn up
Updating '.':
At revision 3419.

$ python vol.py -f xp-laptop-2005-07-04-1430.vmem --profile=WinXPSP2x86 dlldump --dump-dir=output --pid=3276
Volatile Systems Volatility Framework 2.3_beta
Process(V) Name                 Module Base Module Name          Result
---------- -------------------- ----------- -------------------- ------
0x8133d810 firefox.exe          0x000400000 firefox.exe          OK: module.3276.133d810.400000.dll
0x8133d810 firefox.exe          0x07c900000 ntdll.dll            OK: module.3276.133d810.7c900000.dll
0x8133d810 firefox.exe          0x060130000 nspr4.dll            Error: DllBase is paged
0x8133d810 firefox.exe          0x060230000 smime3.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x077f60000 SHLWAPI.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x077c00000 VERSION.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x05ad70000 uxtheme.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x076380000 msimg32.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x010000000 LgWndHk.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x0017a0000 LgMsgHk.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x06d5b0000 NPOJI610.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x006330000 SSSensor.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x076d60000 iphlpapi.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x077dd0000 ADVAPI32.dll         OK: module.3276.133d810.77dd0000.dll
0x8133d810 firefox.exe          0x077fe0000 Secur32.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x020000000 xpsp2res.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x07c800000 kernel32.dll         OK: module.3276.133d810.7c800000.dll
0x8133d810 firefox.exe          0x060210000 plds4.dll            Error: DllBase is paged
0x8133d810 firefox.exe          0x060160000 nss3.dll             Error: DllBase is paged
0x8133d810 firefox.exe          0x06d420000 jpinscp.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x060020000 jar50.dll            Error: DllBase is paged
0x8133d810 firefox.exe          0x06d440000 jpioji.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x060250000 softokn3.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x071ad0000 WSOCK32.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x077e70000 RPCRT4.dll           OK: module.3276.133d810.77e70000.dll
0x8133d810 firefox.exe          0x076080000 MSVCP60.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x071a90000 wshtcpip.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x06d450000 jpishare.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x071ab0000 WS2_32.dll           OK: module.3276.133d810.71ab0000.dll
0x8133d810 firefox.exe          0x076f60000 WLDAP32.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x0602d0000 xpcom.dll            OK: module.3276.133d810.602d0000.dll
0x8133d810 firefox.exe          0x0774e0000 ole32.dll            Error: DllBase is paged
0x8133d810 firefox.exe          0x077920000 SETUPAPI.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x073000000 WINSPOOL.DRV         Error: DllBase is paged
0x8133d810 firefox.exe          0x077120000 OLEAUT32.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x060330000 xpcom_compat.dll     Error: DllBase is paged
0x8133d810 firefox.exe          0x077d40000 USER32.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x074720000 MSCTF.dll            Error: DllBase is paged
0x8133d810 firefox.exe          0x076fd0000 CLBCATQ.DLL          Error: DllBase is paged
0x8133d810 firefox.exe          0x066580000 pnrpnsp.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x0763b0000 comdlg32.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x043000000 GoogleDes...ork1.dll Error: DllBase is paged
0x8133d810 firefox.exe          0x07c9c0000 SHELL32.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x0773d0000 COMCTL32.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x071a50000 mswsock.dll          OK: module.3276.133d810.71a50000.dll
0x8133d810 firefox.exe          0x060200000 plc4.dll             Error: DllBase is paged
0x8133d810 firefox.exe          0x0662b0000 hnetcfg.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x077c10000 msvcrt.dll           OK: module.3276.133d810.77c10000.dll
0x8133d810 firefox.exe          0x077f10000 GDI32.dll            Error: DllBase is paged
0x8133d810 firefox.exe          0x076fc0000 rasadhlp.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x077050000 COMRes.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x0746f0000 msimtf.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x060070000 js3250.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x076f20000 DNSAPI.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x076fb0000 winrnr.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x071aa0000 WS2HELP.dll          OK: module.3276.133d810.71aa0000.dll
0x8133d810 firefox.exe          0x05edd0000 OLEPRO32.DLL         Error: DllBase is paged
0x8133d810 firefox.exe          0x0602b0000 ssl3.dll             Error: DllBase is paged



For many of these DLLs, the base address is paged out, which means we can't dump out the DLL. We only recovered ten of them. Now as it turns out, some of these DLLs are still in the working set of other processes. For example, the OLEPRO32.DLL file is in the working set of another process. If we ask Volatility™ to recover any DLL with that filename, from any process, we can get a copy of it:

$ python vol.py -f xp-laptop-2005-07-04-1430.vmem --profile=WinXPSP2x86 dlldump --dump-dir=output -r OLEPRO32
Volatile Systems Volatility Framework 2.3_beta
Process(V) Name                 Module Base Module Name          Result
---------- -------------------- ----------- -------------------- ------
0x8216c9b0 Smc.exe              0x05edd0000 OLEPRO32.DLL         Error: DllBase is paged
0x820d1b00 Directcd.exe         0x05edd0000 OLEPRO32.DLL         OK: module.2456.20d1b00.5edd0000.dll
0x8133d810 firefox.exe          0x05edd0000 OLEPRO32.DLL         Error: DllBase is paged



The OLEPRO32 file is still part of the working set of Directcd.exe. Nice! It turns out there are prototype PTEs which will point from the other process' working sets to this copy. The code I've written will follow the pointers, which results in the following. In the example below I am changing directories to my branch and running the exact same command as before:

$ cd ../branches/buffalo/
$ python vol.py -f xp-laptop-2005-07-04-1430.vmem --profile=WinXPSP2x86 dlldump --dump-dir=output -r OLEPRO32
Volatile Systems Volatility Framework 2.3_beta
Process(V) Name                 Module Base Module Name          Result
---------- -------------------- ----------- -------------------- ------
0x8216c9b0 Smc.exe              0x05edd0000 OLEPRO32.DLL         OK: module.840.216c9b0.5edd0000.dll
0x820d1b00 Directcd.exe         0x05edd0000 OLEPRO32.DLL         OK: module.2456.20d1b00.5edd0000.dll
0x8133d810 firefox.exe          0x05edd0000 OLEPRO32.DLL         OK: module.3276.133d810.5edd0000.dll


Success! How does following prototype PTEs affect our ability to recover DLLs from the original firefox.exe executable? Let's try our original command again to recover its DLLs:

$ rm -f output/*
$ python vol.py -f xp-laptop-2005-07-04-1430.vmem --profile=WinXPSP2x86 dlldump --dump-dir=output --pid=3276
Volatile Systems Volatility Framework 2.3_beta
Process(V) Name                 Module Base Module Name          Result
---------- -------------------- ----------- -------------------- ------
0x8133d810 firefox.exe          0x000400000 firefox.exe          OK: module.3276.133d810.400000.dll
0x8133d810 firefox.exe          0x07c900000 ntdll.dll            OK: module.3276.133d810.7c900000.dll
0x8133d810 firefox.exe          0x060130000 nspr4.dll            Error: DllBase is paged
0x8133d810 firefox.exe          0x060230000 smime3.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x077f60000 SHLWAPI.dll          OK: module.3276.133d810.77f60000.dll
0x8133d810 firefox.exe          0x077c00000 VERSION.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x05ad70000 uxtheme.dll          OK: module.3276.133d810.5ad70000.dll
0x8133d810 firefox.exe          0x076380000 msimg32.dll          OK: module.3276.133d810.76380000.dll
0x8133d810 firefox.exe          0x010000000 LgWndHk.dll          OK: module.3276.133d810.10000000.dll
0x8133d810 firefox.exe          0x0017a0000 LgMsgHk.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x06d5b0000 NPOJI610.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x006330000 SSSensor.dll         OK: module.3276.133d810.6330000.dll
0x8133d810 firefox.exe          0x076d60000 iphlpapi.dll         OK: module.3276.133d810.76d60000.dll
0x8133d810 firefox.exe          0x077dd0000 ADVAPI32.dll         OK: module.3276.133d810.77dd0000.dll
0x8133d810 firefox.exe          0x077fe0000 Secur32.dll          OK: module.3276.133d810.77fe0000.dll
0x8133d810 firefox.exe          0x020000000 xpsp2res.dll         OK: module.3276.133d810.20000000.dll
0x8133d810 firefox.exe          0x07c800000 kernel32.dll         OK: module.3276.133d810.7c800000.dll
0x8133d810 firefox.exe          0x060210000 plds4.dll            Error: DllBase is paged
0x8133d810 firefox.exe          0x060160000 nss3.dll             Error: DllBase is paged
0x8133d810 firefox.exe          0x06d420000 jpinscp.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x060020000 jar50.dll            Error: DllBase is paged
0x8133d810 firefox.exe          0x06d440000 jpioji.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x060250000 softokn3.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x071ad0000 WSOCK32.dll          OK: module.3276.133d810.71ad0000.dll
0x8133d810 firefox.exe          0x077e70000 RPCRT4.dll           OK: module.3276.133d810.77e70000.dll
0x8133d810 firefox.exe          0x076080000 MSVCP60.dll          OK: module.3276.133d810.76080000.dll
0x8133d810 firefox.exe          0x071a90000 wshtcpip.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x06d450000 jpishare.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x071ab0000 WS2_32.dll           OK: module.3276.133d810.71ab0000.dll
0x8133d810 firefox.exe          0x076f60000 WLDAP32.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x0602d0000 xpcom.dll            OK: module.3276.133d810.602d0000.dll
0x8133d810 firefox.exe          0x0774e0000 ole32.dll            Error: DllBase is paged
0x8133d810 firefox.exe          0x077920000 SETUPAPI.dll         OK: module.3276.133d810.77920000.dll
0x8133d810 firefox.exe          0x073000000 WINSPOOL.DRV         Error: DllBase is paged
0x8133d810 firefox.exe          0x077120000 OLEAUT32.dll         OK: module.3276.133d810.77120000.dll
0x8133d810 firefox.exe          0x060330000 xpcom_compat.dll     Error: DllBase is paged
0x8133d810 firefox.exe          0x077d40000 USER32.dll           OK: module.3276.133d810.77d40000.dll
0x8133d810 firefox.exe          0x074720000 MSCTF.dll            Error: DllBase is paged
0x8133d810 firefox.exe          0x076fd0000 CLBCATQ.DLL          Error: DllBase is paged
0x8133d810 firefox.exe          0x066580000 pnrpnsp.dll          Error: DllBase is paged
0x8133d810 firefox.exe          0x0763b0000 comdlg32.dll         OK: module.3276.133d810.763b0000.dll
0x8133d810 firefox.exe          0x043000000 GoogleDes...ork1.dll OK: module.3276.133d810.43000000.dll
0x8133d810 firefox.exe          0x07c9c0000 SHELL32.dll          OK: module.3276.133d810.7c9c0000.dll
0x8133d810 firefox.exe          0x0773d0000 COMCTL32.dll         Error: DllBase is paged
0x8133d810 firefox.exe          0x071a50000 mswsock.dll          OK: module.3276.133d810.71a50000.dll
0x8133d810 firefox.exe          0x060200000 plc4.dll             Error: DllBase is paged
0x8133d810 firefox.exe          0x0662b0000 hnetcfg.dll          OK: module.3276.133d810.662b0000.dll
0x8133d810 firefox.exe          0x077c10000 msvcrt.dll           OK: module.3276.133d810.77c10000.dll
0x8133d810 firefox.exe          0x077f10000 GDI32.dll            OK: module.3276.133d810.77f10000.dll
0x8133d810 firefox.exe          0x076fc0000 rasadhlp.dll         OK: module.3276.133d810.76fc0000.dll
0x8133d810 firefox.exe          0x077050000 COMRes.dll           OK: module.3276.133d810.77050000.dll
0x8133d810 firefox.exe          0x0746f0000 msimtf.dll           OK: module.3276.133d810.746f0000.dll
0x8133d810 firefox.exe          0x060070000 js3250.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x076f20000 DNSAPI.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x076fb0000 winrnr.dll           Error: DllBase is paged
0x8133d810 firefox.exe          0x071aa0000 WS2HELP.dll          OK: module.3276.133d810.71aa0000.dll
0x8133d810 firefox.exe          0x05edd0000 OLEPRO32.DLL         OK: module.3276.133d810.5edd0000.dll
0x8133d810 firefox.exe          0x0602b0000 ssl3.dll             Error: e_magic 0876 is not a valid DOS signature.



Much better. With the trunk code we were able to recover ten out of 58 modules. Using prototype PTEs we were able to recover 32 of them. This is a great improvement, and saves the user from having to type an extra 22 separate command lines to recover the other DLLs. (Actually, without any knowledge of which 22 DLLs to recover, the user would be doing a lot more typing than 22 lines.)

This method works on x86, x86 with PAE enabled, and x64 systems. The former is demonstrated above. For PAE systems, try recovering the csrss.exe process, pid 596, from Brendan Dolan-Gavitt's ds_fuzz_hidden_proc memory image [2].

$ python vol.py -f ds_fuzz_hidden_proc.img --profile=WinXPSP3x86 procexedump -D output --pid=596

The Buffalo and Volatility™


The Volatility™ framework already uses some kinds of invalid memory. Support for reading PTEs marked as "in transition" was added in August 2012 with version 2.1. As of the date of this post, however, neither the latest release nor the trunk code (version 2.2 and revision 3419, respectively), supported prototypes PTEs.

I have created a patch against revision 3419 of the trunk code which adds support for prototype PTEs. This patch covers the three Volatility™ supported architectures used by Microsoft Windows--x86, x86-PAE, and x64.

This patch was submitted to the Volatility™ development team on 16 May 2013, https://code.google.com/p/volatility/issues/detail?id=419. While they are reviewing it, you can try it out using the method and examples below. Please let me know if you have any problems or your results don't match mine.

These directions assume you don't have a copy of the current trunk code. If you do, and know what you're doing with svn, just make a new branch from the trunk ($ svn copy trunk branches/buffalo) and skip to step three.

Testing out More Buffalo with Volatility™


1. Check out a copy of the Volatility™ trunk source code.

$ svn checkout http://volatility.googlecode.com/svn/trunk volatility

2. Make a copy of the trunk code. This is where we're going to apply the patch. But we'll need the original trunk code too for comparison.

$ cp -R volatility buffalo

3. Change into the new buffalo directory, download and apply the patch

$ cd buffalo
$ wget http://jessekornblum.com/tools/volatility/buffalo-patch.txt
$ patch -p0 < buffalo-patch.txt


That's it! Running the Volatility™ code from the Buffalo directory will let you test out prototype PTEs. Remember: This code is still experimental and should be used for testing purposes ONLY!



References

[1] Code Machine, "Prototype PTEs", December 2010, http://www.codemachine.com/article_protopte.html.

[2] Brendan Dolan-Gavitt, "Plugin Post: Robust Process Scanner", Push the Red Button blog, http://moyix.blogspot.com/2010/07/plugin-post-robust-process-scanner.html, July 2010, accessed 16 Mar 2013.

[3] Jesse Kornblum. "Using Every Part of the Buffalo in Windows Memory Analysis", Digital Investigation 4(1) pp 24-29, March 2007, http://dx.doi.org/10.1016/j.diin.2006.12.002 or http://jessekornblum.com/publications/di07.pdf.

[4] Mark Russinovich, David Solomon, and Alex Ionescu. "Windows Internals", 6th Edition, Microsoft Press, April 2012.

[5] Volatility Development Team, "Volatility™", https://code.google.com/p/volatility/.

[6] NIST Computer Forensic Reference Data Sets (CFReDS), Windows Memory Images, 2006, http://www.cfreds.nist.gov/.

Legal

Volatility™ is a trademark of Verizon. Jesse Kornblum is not sponsored or approved by, or affiliated with Verizon.
LinkLeave a comment

Memory Forensics is not a Nail [Apr. 5th, 2013|09:56 am]
jessekornblum
[Tags|, , ]

"If all you have is a hammer, everything looks like a nail" —Abraham Maslow, The Law of the Instrument.

I wrote a course on memory forensics which is not tied to any particular tool. Tools are great, and I've written several. But to understand a topic you have to know why you should use any particular tool. Sometimes you need a hammer, and a hammer can be used in a lot of ways. But a hammer isn't going to do you much good when you need a screwdriver or a saw.

Windows memory images are sometimes best viewed as a highly structured set of data. Sometimes it's best to see them as a jumble of ones and zeros. The view you choose, and tools you use from that vantage point, should be determined by your original motivation. Are you trying to find a runaway child or a runaway process? The best tool for the former is going to be worthless for the latter.

I don't have tunnel vision for any particular tool because I don't have tunnel vision to any particular task. In my work I have to do a lot of things. Chances are you do too. It would be nice to live in a simple world, where you only have one job to do. But the world is messy and complex and you have to use your best judgement on how to deal with it.

By all means, know your tools. Know what your hammer can do and how to use it effectively. But don't assume that every problem can be solved by hammering away at it.

If you're curious about Windows memory forensics and want to learn about all of the available tools, come take my course, Windows Memory Forensics In-Depth. There will be sessions in May in San Diego, CA; June in Washington DC; July in Austin, TX; September in Las Vegas, NV; and October in Prague.
LinkLeave a comment

TrueCrypt Has Been Wiping BIOS Memory Since at least May 2009 [Apr. 2nd, 2013|02:12 pm]
jessekornblum
[Tags|, , ]

Here are two follow ups to my recent post on TrueCrypt and the BIOS keyboard buffer. First, thanks to @jduck, I've been able to verify that TrueCrypt was wiping the BIOS keyboard buffer as far back as version 6.2, released in May 2009.

Second, an anonymous reader asked:
if [TrueCrypt] is wiping the buffer with zeros, why is it filled with 0x20 0x00?
Sorry, but I don't know. Does anybody out there have an idea?
LinkLeave a comment

No More TrueCrypt Boot Passphrases [Mar. 31st, 2013|07:56 pm]
jessekornblum
[Tags|, , , ]

Bad news for the memory forensics community. There will be no more (partial) TrueCrypt passphrases found in the BIOS keyboard buffer. I'm not sure when this changed, but the TrueCrypt bootloader now wipes the keyboard buffer.

The BIOS keyboard buffer holds the keystrokes entered when the BIOS is running. Found at offset 0x41e in memory, the buffer cannot be read or written by the operating system. The data left in the buffer by the boot loader will stay there indefinitely.

Somewhere along the line, however, the TrueCrypt developers removed this artifact. This may have happened in the summer of 2008 based on the data in the Open Source Vulnerability Database [1] and a vulnerability report from iViZ [2, 3, 4]. Of course, just because the problem was reported then doesn't mean that it was fixed then. I'm not sure exactly when the code was changed as it's difficult to find old versions of the TrueCrypt source. If you have a copy of the source code prior to the current version, please send me a link. Regardless, I am sorry it's taken me so long to notice this change and report it to you.

The practical impact of this change is that when you look at the BIOS keyboard buffer of a system with TrueCrypt full disk encryption, you will see no meaningful data. Instead you'll only find the repeating pattern 0x20 0x00 starting at offset 0x41e. To test this, I made a virtual machine, installed TrueCrypt, and encrypted the system drive. I then rebooted the system, entered my passphrase, allowed the system to boot, and took a snapshot. Looking at the snapshot data, however, does not reveal the passphrase. In the first line of this output, look at the last column of the hex dump for offset 0x41e:

$ xxd test-truecrypt-Snapshot-1.vmem
[...]
0000410: 2744 007e 0228 0000 0000 3400 3400 2000  'D.~.(....4.4. .
0000420: 2000 2000 2000 2000 2000 2000 2000 2000   . . . . . . . .
0000430: 2000 2000 2000 2000 2000 2000 2000 0080   . . . . . . ...
[...]

If you look through the current source code of TrueCrypt for Windows, version 7.1a, you'll find the following in the file BootMain.cpp. Here's the specific code executed when the user hits the return key while entering their passphrase:
case TC_BIOS_KEY_ENTER:
   ClearBiosKeystrokeBuffer();
   PrintEndl();

   password.Length = pos;
   return scanCode;

The function ClearBiosKeystrokeBuffer does exactly what the name says. From BootConsoleIo.cpp:
void ClearBiosKeystrokeBuffer ()
{
        __asm
        {
                push es
                xor ax, ax
                mov es, ax
                mov di, 0x41e
                mov cx, 32
                cld
                rep stosb
                pop es
        }
}

The value in the ES register is saved by pushing it onto the stack. The AX register is XOR'ed against itself—a common compiler trick for setting a register to zero. The DI value is set to the start of the BIOS keyboard buffer, 0x41e, and the CX register is set to 32. The instruction rep stosb then stores the value in AX (0) into the address starting at ES:DI (0:0x41e), for CX (32) bytes. Finally the saved value for ES is restored by popping it off the stack. (The cld instruction clear the direction flag.)


References


[1] Open Source Vulnerability Database, http://osvdb.org/47904

[2] Jonathan Brossard, "Bypassing pre-boot authentication passwords by instrumenting the BIOS keyboard buffer (practical low level attacks against x86 pre-boot authentication softwares)", http://www.ivizsecurity.com/research/preboot/preboot_whitepaper.pdf

[3] iViZ, http://www.ivizsecurity.com/security-advisory-iviz-sr-0803.html.

[4] CVE-2008-3899, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3899
LinkLeave a comment

First Issue of 4:mag Published [Mar. 26th, 2013|09:47 am]
jessekornblum
[Tags|]

Lee Whitfield has updated the forensic4cast.com web site and published the first issue of 4:mag: http://forensic4cast.com/2013/03/4mag-issue-1/. Enjoy!
Link1 comment|Leave a comment

Dumping Raw Kernel Memory [Mar. 21st, 2013|09:22 pm]
jessekornblum
[Tags|, , ]

"A good plan violently executed now is better than a perfect plan executed next week." — General George S. Patton

"DONE IS BETTER THAN PERFECT." — Ben Barry, via Facebook

A recent post on the Volatility™ users mailing list [1] asked for help dumping out a kernel driver from a Microsoft Windows system.

It turns out the standard plugin for dumping kernel modules, moddump, is based on the procexedump plugin. That plugin, in turn, does a number of sanity checks on the PE executable it is attempting to extract. Although good in theory, it was preventing the poster from getting any data at all.

To help him out, I wrote two plugins. The first is modmemdump. It's the same code as moddump, but based on procmemdump instead of procexedump. (English translation: this plugin attempts to dump out the raw memory of the module without attempting to modify it--or perform sanity checks.) The usage/command line flags are the same as moddump.

$ python vol.py -f xp-laptop-2005-07-04-1430.vmem --profile=WinXPSP2x86 modmemdump --dump-dir=output
Volatile Systems Volatility Framework 2.3_alpha
Module Base Module Name          Result
----------- -------------------- ------
0x0804d7000 ntoskrnl.exe         OK: driver.804d7000.sys
0x0806ec000 hal.dll              OK: driver.806ec000.sys
0x0f87d9000 PartMgr.sys          OK: driver.f87d9000.sys
0x0f849c000 atapi.sys            OK: driver.f849c000.sys
0x0f5e22000 NAVENG.sys           OK: driver.f5e22000.sys
0x0f8931000 watchdog.sys         OK: driver.f8931000.sys
0x0f8551000 isapnp.sys           OK: driver.f8551000.sys
...


The second plugin is rawmoddump. This plugin allows you to dump out a section of kernel memory. There are no safety checks of any kind. You simply specify a base virtual address, number of bytes to dump, and an output directory. The plugin performs the read, padding with zeros where data is unavailable, and writes it out.

$ python vol.py -f xp-laptop-2005-07-04-1430.vmem --profile=WinXPSP2x86 rawmoddump --dump-dir=output --base=0x804d7000 --size=0x214100
Volatile Systems Volatility Framework 2.3_alpha
Wrote 0x214100 bytes to output/module-804d7000-00214100.sys
$ xxd -a output/module-804d7000-00214100.sys | head -n 10
0000000: 4d5a 9000 0300 0000 0400 0000 ffff 0000  MZ..............
0000010: b800 0000 0000 0000 4000 0000 0000 0000  ........@.......
0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0000 0000 e800 0000  ................
0000040: 0e1f ba0e 00b4 09cd 21b8 014c cd21 5468  ........!..L.!Th
0000050: 6973 2070 726f 6772 616d 2063 616e 6e6f  is program canno
0000060: 7420 6265 2072 756e 2069 6e20 444f 5320  t be run in DOS 
0000070: 6d6f 6465 2e0d 0d0a 2400 0000 0000 0000  mode....$.......
0000080: ce0d 2de1 8a6c 43b2 8a6c 43b2 8a6c 43b2  ..-..lC..lC..lC.
0000090: 4963 1eb2 8d6c 43b2 8a6c 42b2 de6c 43b2  Ic...lC..lB..lC.


Here's the code for these plugins:

http://jessekornblum.com/tools/volatility/modmemdump.py
http://jessekornblum.com/tools/volatility/rawmoddump.py

To use them, save these files to the volatility/plugins directory in your Volatility™ source code tree. Let me know if you have any problems or questions.

Happy memory forensics!


[1] http://lists.volatilesystems.com/pipermail/vol-users/2013-March/000828.html.

Volatility™ is a trademark of Verizon. Jesse Kornblum is not sponsored or approved by, or affiliated with Verizon.
LinkLeave a comment

Updating ssdeep SourceForge site [Mar. 21st, 2013|11:05 am]
jessekornblum
[Tags|, ]

In accordance with SourceForge's move a new codebase, I am upgrading the ssdeep SourceForge site. Aside from having a splefty new look, this shouldn't affect much of the site except the Subversion repository. If you're working with the Subversion tree, check out https://sourceforge.net/p/ssdeep/code/ to get more details.

If the above makes no sense to you, don't worry about it. You can still get ssdeep, as always, from http://ssdeep.sf.net/.
LinkLeave a comment

navigation
[ viewing | 10 entries back ]
[ go | earlier/later ]