I made a video of the Network Appliance Forensic Toolkit demo I gave at my local ISSA chapter.
Monday 28 October 2013
Monday 21 October 2013
Suspender is a DLL that suspends all threads of a process.
This new version adds an option to suspend a process when it exits. Rename the dll to suspenderx.dll to activate this option (x stands for eXit).
When DllMain is called with DLL_PROCESS_DETACH and the reserved argument is not NULL, the process is exiting. So that’s the trigger to suspend it.
Monday 14 October 2013
I’ve been asked many times to support 32-bit keys with my XORSearch tool. But the problem is that a 32-bit bruteforce attack would take too much time.
Now I found a solution that doesn’t take months or years: a 32-bit dictionary attack.
I assume that the 32-bit XOR key is inside the file as a sequence of 4 consecutive bytes (MSB or LSB).
If you use the new option -k, XORSearch will perform a 32-bit dictionary attack to find the XOR key. The standard bruteforce attacks are disabled when you choose option -k.
XORSearch will extract a list of keys from the file: all unique sequences of 4 consecutive bytes (MSB and LSB order). Key 0x00000000 is excluded. Then it will use this list of keys to perform an XOR dictionary attack on the file, searching for the string you provided. Each key will be tested with an offset of 0, 1, 2 and 3.
It is not unusual to find the 32-bit XOR key inside the file itself. If it is a self-decoding executable, it can contain an XOR x86 instruction with the 32-bit key as operand. Or if the original file contains a sequence of 0x00 bytes (4 consecutive 0x00 bytes at least), then the encoded file will also contain the 32-bit XOR key.
Here is a test where XORSearch.exe searches a 0xDEADBEEF XOR encoded copy of itself. With only 74KB, there are still 100000+ keys to test, taking almost 10 minutes on my machine:
Monday 7 October 2013
Some time ago I had to figure out if a file was embedded inside another file.
It’s not a file carving problem. I had both files. I just needed to be sure that file A was contained inside file B.
With a hex editor I could find parts of file A inside file B, but it looked like file A was split up and scattered at different locations in file B.
I Googled a bit for a tool, but nothing came up, so I wrote my own Python program.
With my new tool I was able to get assured that file msi49.tmp was inside file c8400.msi:
You can see that file msi49.tmp is one contiguous sequence inside file c8400.msi starting at position 0x3A7200.
But I was more interested to know if file msi49.tmp was also inside file Cisco_Jabber.msi:
And you can see it is, but not as one contiguous sequence. It’s split in 3 sequences.
This tool can also be used to find a downloaded file inside a pcap/pcapng file. I downloaded AnalyzePESig_V0_0_0_2.zip while taking a Wireshark capture.
Or to find a file opened by an application. Here I look into the process dump:
The only limitation is that both files need to be read into memory. But when I’ve time, I’ll turn this into a plugin for the Volatility framework.
The program looks for sequences of at least 10 bytes long (this is an option). If your file is divided in sequences smaller than 10 bytes, then my program will not find the embedded file. Unless you lower the minimum length, but don’t go as low as 1 byte, because then you’re likely to be finding random data.
I’m not 100% sure that my program will find all possible cases of embedded files. No problem if it’s one contiguous sequence, or several sequences in logical order. But I’ve to review my algorithm to be sure it will also find all possible cases of embedded files with sequences in random order. I think it will, but I need to prove it.