Didier Stevens

Monday 27 February 2012

Teensy PDF Dropper Part 2

Filed under: Hacking,My Software,PDF — Didier Stevens @ 0:00

Last year I showed how to use a Teensy micro-controller to drop a PDF file with embedded executable. But I was limited to a file of a few kilobytes, because of the Arduino programming language I used for the Teensy.

In this post, I’m using WinAVR and I’m only limited by the amount of flash memory on my Teensy++.

First we use a new version of my PDF tools to create a PDF file with embedded file:

Filter i is exactly like filter h (ASCIIHexDecode), except that the lines of hex code are wrapped at 512 hex digits, making them digestible to our C compiler.

Another new feature of my make PDF tools is Python 3 support.

Here is a sample of our C code showing how to embed each line of the pure-ASCII PDF document as strings:

Macro PSTR makes that the string is stored in flash memory. The embedded executable is 57KB large, but still only takes half of the flash memory of my Teensy++.

After programming my Teensy++, I can fire up Notepad and let my Teensy++ type out the PDF document:

You can download my example for the WinAVR compiler here:

avr-teensy-pdf-dropper_V0_0_0_1.zip (https)
MD5: EA14100A1BEDA4614D1AE9DE0F71B747
SHA256: 2C9A5DF1831B564D82548C72F1050737BCF17E5A25DCDC41D7FA4EA446A8FDED

Monday 20 February 2012

Peeking at NAFT

Filed under: My Software,Networking — Didier Stevens @ 20:02

Here are DNS queries issued by a Windows XP machine:

And here is a command history of a Cisco router:

What do these results have in common?

Both were produced by analyzing RAM dumps with a new forensic toolkit I’m developing, the Network Appliance Forensic Toolkit, or NAFT.

More to be published soon.

But if you want a beta version now, provide me a Cisco core dump in exchange 😉

Friday 17 February 2012

Article: White Hat Shellcode

Filed under: Announcement,Shellcode — Didier Stevens @ 17:57

The latest (IN)SECURE Magazine issue includes my article on White Hat Shellcode.

Thursday 9 February 2012

Quickpost: Disassociating the Key From a TrueCrypt System Disk

Filed under: Encryption,Quickpost — Didier Stevens @ 21:05

TrueCrypt allows for full disk encryption of a system disk. I use it on my Windows machines.

You probably know that the TrueCrypt password you type is not the key. But it is, simply put, used to decrypt the master key that is in the volume header.

On a system drive, the volume header is stored in the last sector of the first track of the encrypted system drive (TrueCrypt 7.0 or later). Usually, a track is 63 sectors long and a sector is 512 bytes long. So the volume header is in sector 62.

When this header is corrupted or modified, you can no longer decrypt the disk, even with the correct password. You need to use the TrueCrypt Rescue Disk to restore the volume header. This rescue disk was created when you encrypted the disk.

I’m using Tiny Hexer on the Universal Boot CD For Windows to erase the volume header (you can’t modify the volume header easily when you booted from the TrueCrypt system disk; using a live CD like UBCD4WIN is one possible workaround).

First I’m checking the geometry of the system drive with MBRWizard:

Take a look at the CHS (Cylinders Heads Sectors) value: S = 63 confirms that a track is 63 sectors long.

Then I open the system drive with Tiny Hexer (notice that the sector size is 512 bytes or 0x200 bytes):

I go to sector 62, the last sector of the first track:

It contains the volume header (an encrypted volume header has no recognizable patterns, it looks like random bytes):

Then I erase the volume header by filling the sector with zeroes and writing it back to disk:

And if you absolutely want to prevent recovery of this erased sector, write several times to it with random data.

Booting is no longer possible, even with the correct password. The TrueCrypt bootloader will tell you the password is incorrect:

One can say that I’ve created a TrueCrypt disk that requires 2-factor authentication. To decrypt this disk, you need 2 factors: the password and the corresponding TrueCrypt Rescue Disk.

First you need to boot from the TrueCrypt Rescue Disk, and select Repair Options (F8):

And then you write the volume header back to the system disk. Remark that the TrueCrypt Rescue Disk requires you to enter the password before it writes the volume header to the disk:

And now you can boot from the system disk with your password.

Use this method if you need to travel with or mail an encrypted system disk and want to be 100% sure there is no way to decrypt the drive while in transit. But don’t travel with the 2 factors on you, send the TrueCrypt Rescue Disk via another channel.

Remark: MBRWizard allows you to wipe sectors, but for whatever reason, it couldn’t successfully wipe sector 62 on my test machine.

Oh yeah, don’t forget to make a full backup before you attempt this technique 😉

Quickpost info

Thursday 2 February 2012

x64 Windows Shellcode

Filed under: My Software,Shellcode — Didier Stevens @ 20:00

Last year I found great x64 shellcode for Windows on McDermott’s site. Not only is it dynamic (lookup API addresses), but it even handles forwarded functions.

But it’s written for MASM, and I prefer to use NASM. Hence I translated it, but also normalized it to adhere to the x64 calling convention and fixed a bug in the error handling.

And I modularized it so you can use it like my 32-bit shellcode.

Here’s the classic MessageBox example:

; x64 shellcode to display a "Hello from injected shell code!" MessageBox, then return to caller
; Written for NASM assembler (http://www.nasm.us) by Didier Stevens
; Source code put in public domain by Didier Stevens, no Copyright
; https://DidierStevens.com
; Use at your own risk
;
; History:
;   2011/12/27: Refactored functions to include file sc-x64-api-functions.asm

%include "sc-x64-macros.asm"

INDEX_KERNEL32_LOADLIBRARYA        equ 0 * POINTERSIZE + STACKSPACE
INDEX_MESSAGEBOXA                            equ 1 * POINTERSIZE + STACKSPACE
APIFUNCTIONCOUNT                            equ 2

segment .text

; Setup environment
sub rsp, STACKSPACE + ROUND_EVEN(APIFUNCTIONCOUNT) * POINTERSIZE        ;reserve stack space for called functions and for API addresses

LOOKUP_API KERNEL32DLL, KERNEL32_LOADLIBRARYA, INDEX_KERNEL32_LOADLIBRARYA

lea rcx, [rel USER32DLL]
call [rsp + INDEX_KERNEL32_LOADLIBRARYA]

LOOKUP_API USER32DLL, USER32_MESSAGEBOXA, INDEX_MESSAGEBOXA, INDEX_KERNEL32_LOADLIBRARYA

; Display MessageBox
xor r9, r9
lea r8, [rel TITLE]
lea rdx, [rel HELLO]
xor rcx, rcx
call [rsp + INDEX_MESSAGEBOXA]

add rsp, STACKSPACE + ROUND_EVEN(APIFUNCTIONCOUNT) * POINTERSIZE
ret

%include "sc-x64-api-functions.asm"

KERNEL32DLL                            db    "KERNEL32.DLL", 0
KERNEL32_LOADLIBRARYA        db    "LoadLibraryA", 0

USER32DLL                                db    "USER32.DLL", 0
USER32_MESSAGEBOXA            db    "MessageBoxA", 0

HELLO                                        db    "Hello from injected shell code!", 0
TITLE                                        db    "Message", 0

Here’s what I changed exactly from the original MASM code:
1) non-volatile registers are preserved (by storing them on the stack)
2) building the DLL name for forwarded functions is done with a variable on the stack frame of lookup_api, and not of the caller
3) the address of LoadLibraryA is passed via r9, and no longer r15
4) lookup_api not only returns the function address in rax, but also stores it in memory at an address provided in r8
5) fixed the error handling bug (stack restoration)
6) added some EQUs to make it easier to use this code as a “library” (include)

You can get the code from my shellcode page. Look for filenames starting with sc-x64 in the zip file.

Blog at WordPress.com.