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 😉

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.

Friday 9 December 2011

LoadDLLViaAppInit with FORCE_INTEGRITY

Filed under: My Software,Windows 7 — Didier Stevens @ 12:46

In Windows 7 and Windows Server 2008 R2, Microsoft added a feature to the AppInit_DLLs mechanism. When the REG_DWORD RequireSignedAppInit_DLLs is set to 1, the DLLs to be loaded via AppInit_DLLs have to be signed.

You can find properly signed versions of LoadDLLViaAppInit here:
LoadDLLViaAppInit_FI.zip (https)
MD5: 2867B6AADF6C9FFA224D2D6A0153AD91
SHA256: E732451401B37087FAC619BD500E370FE3C21FB764F2E2E99C76EDBADEC86204

Nothing has changed to these DLLs, I’ve not changed the version number. I only set the FORCE_INTEGRITY flag and signed them.

Wednesday 30 November 2011

Signed TaskManager

Filed under: My Software — Didier Stevens @ 19:44

This new version 0.1.1 of my TaskManager spreadsheet is exactly the same as version 0.1.0, except that it is digitally signed.

A signature allows you to use it on systems that require VBA macros to be signed.

TaskManager_V0_1_1.zip (https)
MD5: 57D0ED69E034872DE7DF217DD491B732
SHA256: 08FD64B90E34150BD48A54904F04905D84249E7042BF31E6A5AA642B2B855D91

Wednesday 2 November 2011

Ariad 64-bit

Filed under: My Software,Windows 7 — Didier Stevens @ 19:33

You can now download a 64-bit version of my Ariad driver.

I’ve been using this driver on my x64 Windows 7 test machine only for a couple of days, so this is still beta software.

As for the installation and configuration, it’s exactly the same as the 32-bit version: you need to download the 32-bit version for the .inf files and the GUI.

Sunday 23 October 2011

HeapLocker 64-bit

Filed under: My Software,Vulnerabilities — Didier Stevens @ 19:40

I’m releasing my first 64-bit version of my HeapLocker tool.

I had to change many pointer calculations, and had to replace 32-bit shellcode with 64-bit shellcode.

This 64-bit version gets configured via the registry, exactly like the 32-bit version of HeapLocker. The only difference is when you want to protect specific addresses, you need to use a QWORD registry value in stead of a DWORD (QWORD is 64-bit wide, DWORD is 32-bit wide).

And there is a new feature: Bottom Up Randomization. To enable it, create a DWORD registry value with name BottomUpRandomization and value 1.

I will be adding this feature to HeapLocker 32-bit too, but I want to do this from the same code base. The next release of HeapLocker 32-bit will be compiled from Visual Studio 2010 and not from Borland C++ anymore.

HeapLocker64_V0_0_1_0.zip (https)
MD5: F3D43A29CE64F9418AA154C66B0B06A4
SHA256: 7EFF1D9EA20B522D76034DC4CB66E2FD7AC43E585987FC9ABF7EF8EB801FBC6C

Thursday 20 October 2011

RunInsideLimitedJob 64-bit

Filed under: My Software — Didier Stevens @ 6:00

RunInsideLimitedJob is a tool to sandbox applications by containing their process inside a limited job object. There are 2 versions of my RunInsideLimitedJob tool: a .EXE and a .DLL.

As a 32-bit executable, RunInsideLimitedJob.exe is perfectly capable of launching a 64-bit application contained in a limited job object.

But the 32-bit RunInsideLimitedJob.dll can’t be loaded inside a 64-bit process. That’s why I’m releasing a 64-bit version of RunInsideLimitedJob.dll.


RunInsideLimitedJob-DLL64_V0_0_0_1.zip (https)
MD5: A6048613CE00C9F401A8AC7943A451E3
SHA256: 279F6BE0EB124814D37A5E70F2D906B1756B27CDDC7E7AEA40B2B42B39C0CFCA

Wednesday 19 October 2011

LoadDLLViaAppInit 64-bit

Filed under: My Software — Didier Stevens @ 16:47

Many of my security tools are DLLs. If you want to use these tools inside a 64-bit process, you’re stuck, because you can’t use 32-bit DLLs inside a 64-bit process (and vice versa).

LoadDLLViaAppInit is a tool I released to load DLLs inside selected processes. If you want to use this 32-bit version of LoadDLLViaAppInit on a 64-bit Windows machine, you need to configure AppInit_DLLs in this registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows

You also need to copy LoadDLLViaAppInit.dll in this directory: C:\Windows\SysWOW64

Today I’m releasing a 64-bit version of LoadDLLViaAppInit: LoadDLLViaAppInit64.dll. This will help you to load DLLs inside 64-bit processes.

This 64-bit version has to be installed and configured just like its 32-bit version on a 32-bit OS: you copy the DLL in directory C:\Windows\System32 and you configure the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows

The configuration file is LoadDLLViaAppInit64.bl.txt.

This 64-bit version has only been tested on 64-bit Windows, not on 64-bit XP neither on 64-bit Windows Server. I expect it to work on these systems too, but you need to test first. I’ve also compiled this 64-bit version with Visual Studio 2010 and an option to include the runtime Visual C++ libraries inside the DLL, so you don’t need to install the Microsoft Visual C++ 2010 Redistributable Package. But this option has a drawback: when Microsoft releases a patch for the libraries, I (or you) will have the recompile the DLL with the new version of the libraries.

LoadDLLViaAppInit64_V0_0_0_1.zip (https)
MD5: 94C38717690CE849976883FFE4B22CA1
SHA256: 447C8F61A6398CBE6BD5E681FCE28C55D426D4E4EA49BBE367AE5B334B073A55

Tuesday 18 October 2011

HeapLocker: Preventing Heapsprays

Filed under: My Software,Vulnerabilities — Didier Stevens @ 8:34

I’ve been using my HeapLocker tool for almost a year now, and I’ve encountered no issues, except for the NOP sled detection. When used with Adobe Reader, HeapLocker will generate too many false positives when looking for NOP sleds. So I’ve disabled NOP sled detection for Adobe Reader.

The last feature I want to talk about is heap spray mitigation.

Like EMET, HeapLocker can pre-allocate memory pages so that they can’t be used by the heap. And this renders a heap spray useless, as it will not be able to inject shellcode at the addresses HeapLocker protects. But unlike EMET, HeapLocker has 2 modes of pre-allocating memory pages. The first mode is just like EMET, while the second mode will write special shellcode to the pre-allocated pages. When this shellcode is hit due to an exploit, it will callback to HeapLocker which will suspend all threads and display a warning dialog. This is what you see in the video. There are 2 advantages to this mode: the user is warned that she opened a malicious document, and you can also use this in a malware lab to find out which address the exploit is hitting.

To prevent the HeapLocker shellcode from being used for ROP exploits, I randomized the injected NOP sled and shellcode. But if you still find this too risky, just use the standard mode for pre-allocating pages.

For more details about the exact way to configure this, read the documentation found in the HeapLocker download.

FYI: I’m also working on a 64-bit version of HeapLocker.

« Previous Page — Next Page »

Blog at WordPress.com.