Forensic Software fails on ext4

I recently got a nice image of a server intrusion to analyze only to figure out they used ext4.

Tools that failed to analyse ext4 correctly:

Encase ver. 6.18
Sleuthkit ver. 3.2.0
FTK Demo ver. 1.81.6

(FTK 3.2 does not exist as a Trial / Demo Version ready for download. )

Don’t waste your time trying for now, it does not work.

What is actually pretty surprising is that

FTK Free Imager ver.

in fact it CAN analyze ext4 and export files found within the filesystem but that’s pretty much it.

I got a trial version of Winhex 18.5 and that seems to be able to do ext4 but their demo is pretty crippled when it comes to forensics so this is where I stand right now hoping to find ext4 support in the tools I have access to ;)

I gave extundelete a try (version 0.2.0 linked against e2fsprogs 1.41.13 ) but it didn’t find anything recoverable.


Personally I think this is a major fail as ext4 was introduced within the Linux 2.6.28 kernel released on 25 December, 2008.

The next Android phones are already announced to use ext4 and Intel / Nokia are using it already for their MeeGoo.

In the end I was able to do some signature search and luckily could carve out some files I needed to go on with this case. I used our Encase for that but foremost should do the trick.


Notes on flash analysis

Recently I had the luck to get a malicious flash sample. Until further notice from the source I got the file from, I cannot offer them for download, but I compiled a quick list of tools / commands to get a glimpse on the analysis of flash files and what’s inside. Read more…

Read-only mounting on the Mac

Although it’s obvious I thought I post it here for the more gui-oriented Mac Users out there ;)

hdiutil attach -readonly -noverify -noautofsck  /path/image_file/image.dmg

This actually mounts .dmg images or dd disk images of HFS/HFS+ drives read-only.

I am not 100% certain this won’t change a bit in the image but I will verify that ;)

Lack of postings

Some might be asking themselves why there hasn’t been a posting for some time.

The reason is simply that I currently don’t do any forensic / malware research stuff but instead am very busy with other aspects of my life.

As soon as I encounter something worth showing , it will be here :)

New Radix Anti-Rootkit version released

Today a new version of the free Radix Anti-Rootkit Software was release at:

Besides some bugfixes, new Features in this release: –   FEAT:    Windows 7 support
–    FEAT:    Enumerating registered Registry Callback functions (Windows XP+)
–    FEAT:    Enumerating of PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine,
–    FEAT:    Better support for deleting files
–    FEAT:    Better support for dumping hidden files.
–    FEAT:    Support for PAE
–    FEAT:    Added checks for IRP routines additionally to exported functions when checking
for patched Modules + fixing
–    FEAT:    Added checks for Object handling Routines (ParseProcedure, …) for Kernel Objects + fixing
–    FEAT:    Added checks for modified SDT-Pointers (ServiceTable) in Threads + fixing
–    FEAT:    Added detection for hidden services and services management functions

As always, donations are welcome as are tests and reports :)

Black Energy Breakpoints / How to break on driver load in windbg

At first, you need two virtual / real machines and windbg setup properly to do the debugging as you will end up in kernel space.

If somebody stumbles across the sample of Black Energy that I have, MD5:  59CE4B4D68AC6678D51F43A8D0E84848

here are some breakpoints that will speed it up for you :)

(This works on Windows XP SP2 as this is my analysis machine)

What I did was load the dropper (dos2.exe) into some version of IDA (if you just want to test it out, freeware version is fine) or my debuggee machine and start windebug on the analysis machine, connect to the debuggee and break.

To break as soon as the driver, that the dropper will write to your disk, is loaded by the service the dropper created, set a breakpoint to:


and then

bp poi(ebp-70)+7057

where in ebp-70 is a poiner to the base_addr of the encrypted driver and 7075 is the RVA of the Entry point of the driver written to disk.

To find that entry point, the cheapest way is to go through the code of the dropper until you hit the OpenSCManager API Call. By this time the driver has been written to your windows\system32\drivers directory and you can copy it from there and open it in LordPE for the Entry Point.

(You might need to break on IopLoadDriver and find the offset for yourself, see screenshot, that’s where the base_addr is.)

base means the base addr of the current “part”, e.g. the encrypted/decrypted rootkit or the usermode component, as black energy is layered you will have diff. base addr for rootkit and user-mode payload.
bp base+657A  (there you will find some “call eax” ) ->  “OEP of decrypted rootkit driver” in memory.

begin of ntoskernel iofcompleterequest hook:

bp base+4400

decrypts usermode payload dll to allocated buffer from inside the unpacked driver:

bp base+34ff

After this call, set breakpoint to EP of decrypted payload dll.

I know this is not an extensive description but if you try it out in Winddebug, you should be able to figure it out with the screenshots posted and as a last resort, you can ask me anyway ;)

Windows Internal Blobs


During the reversing of the Black Energy V2 Rootkit, I found the following windbg commands / Tip helpful.

This will be extended as soon as I have time ;)

Dumping KeServiceDescriptorTable

dds poi(nt!KeServiceDescriptorTable) L poi(nt!KeServiceDescriptorTable+8)

Dumping Shadow KeServiceDescriptorTable

dds poi(nt!KeServiceDescriptorTableShadow+10) L poi(nt!KeServiceDescriptorTableShadow+18)

The FS:[0x124] points to ETHREAD/KTHREAD.
KTHREAD[0xe0] points to SerivceTable.