Didier Stevens

Thursday 20 March 2014

XORSearch: Finding Embedded Executables

Filed under: My Software,Update — Didier Stevens @ 10:58

Someone mentioned on a forum that he found a picture with an embedded, XORed executable. You can easily identify such embedded executables by xorsearching for the string “This program must be run under Win32″. But if the author or compiler modifies this DOS-stub string, you will not find it.

That’s how I got the idea to add an option to search for PE-files: search for string MZ, read the offset to the IMAGE_NT_HEADER structure (e_lfanew), and check if it starts with string PE.

Example: XORSearch.exe -p test.jpg

Found XOR A2 position 00005D1D: 000000E8 ........!..L.!This program cannot be r
Found XOR A2 position 0001221D: 00000108 ........!..L.!This program cannot be r

We found 2 embedded executables in test.jpg (XOR key A2). Remark we didn’t provide a search string, only option -p.

XORSearch also reports the value of e_lfanew and the string found in the DOS-stub. This allows you to inspect the results for false positives.

This can also be used on unencoded files, like this installation file:

XORSearch.exe -p c8400.msi
Found XOR 00 position 00236400: 000000E8 ........!..L.!This program cannot be r
Found XOR 00 position 00286000: 00000100 ........!..L.!This program cannot be r
Found XOR 00 position 00346800: 000000F8 ........!..L.!This program cannot be r
Found XOR 00 position 003A7200: 00000080 ........!..L.!This program cannot be r
Found XOR 00 position 003AD200: 00000080 ........!..L.!This program cannot be r
Found XOR 00 position 004B4800: 00000108 ........!..L.!This program cannot be r
Found XOR 00 position 004DE600: 000000F8 ........!..L.!This program cannot be r
Found XOR 00 position 004FE200: 000000E0 ........!..L.!This program cannot be r
Found XOR 00 position 00520C00: 000000E0 ........!..L.!This program cannot be r
Found XOR 00 position 00542000: 000000E0 ........!..L.!This program cannot be r
Found XOR 00 position 00562400: 00000100 ........!..L.!This program cannot be r
Found XOR 00 position 0058F800: 000000E0 ........!..L.!This program cannot be r

Finally, I added option -e (exclude). This excludes a particular byte-value from encoding. If you suspect a file is XOR encoded, but that byte 0×00 is not encoded, you use option -e 0×00.

XORSearch_V1_10_0.zip (https)
MD5: 23809A03C63914B0742B7F75B73E1597
SHA256: 97BFBC5E8C59F60E10ABDA2D65DF4200B10BE14662D4A447797B341C9AAE17D8

Monday 23 December 2013

Update: Prefetch File 010 Template

Filed under: Forensics,My Software,Update — Didier Stevens @ 22:01

This update to my Prefetch File 010 Template adds Sections A through D.

PFTemplate_V0_0_2.zip (https)
MD5: 56A98A78BD4E8D1AED88385AF1DD8446
SHA256: E15D721E46FFB8158C6D14C9A38DE4E3DD5DCD0972896441DF17590C540DBCC3

Saturday 14 December 2013

Update: virustotal-submit.py V0.0.3

Filed under: Malware,My Software,Update — Didier Stevens @ 0:21

There is extra error handling in this new version.

virustotal-search and virustotal-submit have their own page now: VirusTotal Tools.

virustotal-submit_V0_0_3.zip (https)
MD5: 3F9F5421F711E2930AB6F80D87DF9E2B
SHA256: 37CCE3E8469DE097912CB23BAC6B909C9C7F5A5CEE09C9279D32BDB9D6E23BCC

Monday 2 December 2013

4 Times Faster virustotal-search.py

Filed under: Malware,My Software,Update — Didier Stevens @ 0:26

This is an important update to virustotal-search.py.

Rereading the VT API, I noticed I missed the fact that the search query accepts up to 4 search terms.

This new version submits 4 hashes at a time, making it up to 4 times faster than previous versions.

virustotal-search_V0_1_0.zip (https)
MD5: 0141D3677F759317034C416EBF9FF30D
SHA256: FE07859C3FA09DA120D3104FF982AF0D78ADFCF099A10E46E254823502DF4EE4

Friday 15 November 2013

Update: find-file-in-file.py Version 0.0.3

Filed under: Forensics,My Software,Update — Didier Stevens @ 12:55

shinnai made an interesting comment when I released my tool to find contained files: he wanted to know if I could add a batch mode.

I guess this batch mode is interesting when you want to check if a large set of files contains a particular file. So I added this features and release it here.

Now you can provide more than one containing-file to find-file-in-file.py: you can just type several files, use wildcards and/or use at-files (@file). When you specify @filename, find-file-in-file.py will search in all the files listed in textfile filename (each file on a separate line).

When you provide only one file to search, then this new version will just work like the previous version.

But if you provide more than one file, then batch mode is enabled. In batch mode, the contained file is searched for in each containing file. If a (partial) match is found, it will be included in the report. If no match is found, no output is produced. If you want output even when no match is found, then use option verbose (-v).

Example for a bunch of MSI files:

find-file-in-file.py msi49.tmp *.msi

File: c8400.msi
003a7200 00005600 (100%)
File: Cisco_Jabber.msi
00295600 00001000 (18%)
00294a00 00000c00 (13%)
00296600 00003a00 (67%)

File msi49.tmp was found in only 2 MSI files.
find-file-in-file_v0_0_3.zip (https)
MD5: 8691158700079C786F6905F0CA0F32BC
SHA256: 84506CED140F309503E723831A9EFB99A8CC213532BEB56E00BC4BA5FE235797

Monday 4 November 2013

Update: naft-gfe.py

Filed under: Forensics,My Software,Networking,Update — Didier Stevens @ 20:49

This new version of the generic frame extraction tool (naft-gfe) can handle files (RAM dumps) that are too large to fit into memory.


Use option -b for buffered reads. By default, the file will be read and analyzed in blocks of 101MB (100MB buffer + 1MB overlap buffer).

Since the file is not read completely in memory, there is a possibility that some frames/packets are not completely read in memory. For example, a frame starts in the first block of 100MB, and ends in the second block of 100MB. The analysis routines would miss this frame.

To avoid this, the program reads the first block of 100MB (block A) plus an extra block of 1MB (block B). This block of 101MB (A + B) is analyzed. Then, the second block of 100MB (block C) is read, and the extra block B is prepended to block C for analysis (B + C). Hence the overlap buffer is analyzed twice, but packets are only extracted once from this buffer. This procedure is repeated for the complete file.

It is important that the overlap buffer is large enough to accommodate the largest possible frame or packet. That’s why by default, it is 1MB.

Use options -S and -O to choose your own size for buffer and overlap buffer.

Monday 21 October 2013

Update: Suspender V0.0.0.4

Filed under: Forensics,Malware,My Software,Update — Didier Stevens @ 10:19

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.


Suspender_V0_0_0_4.zip (https)
MD5: 629255337FE0CA9F631B1A7177D158F0
SHA256: 8E63152620541314926878D01469E2E922298C147740BDEAF7FC6B70EB9305EF

Monday 14 October 2013

Update: XORSearch Version 1.9.2

Filed under: Forensics,My Software,Update — Didier Stevens @ 5:00

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 0×00000000 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 0×00 bytes (4 consecutive 0×00 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:


XORSearch_V1_9_2.zip (https)
MD5: BF1AC6CAA325B6D1AF339B45782B8623
SHA256: 90793BEB9D429EF40458AE224117A90E6C4282DD1C9B0456E7E7148165B8EF32

Monday 30 September 2013

Bugfix virustotal-submit.py Version 0.0.2

Filed under: My Software,Update — Didier Stevens @ 13:12

This is a bugfix for my virustotal-submit.py program.

I fixed a bug in the error handling code for unreadable ZIP files.

virustotal-submit_V0_0_2.zip (https)
MD5: 1152A8507FE7A668DCDF5C44DEAD11DF
SHA256: D5A4E5C3E80F98D4A82A128D8C9DBA395C2B9CDFE9F37E2B0882904D47673CE5

Thursday 25 July 2013

Update: Lookup Tools

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

It looks like I didn’t release this update to my lookup tools.

lookup-hosts.py has a new argument: -R. This does a reverse lookup of the IP addresses (thus after it resolved the hostname).


And now you can also use letters as a counter: test-[a-z].com

lookup-tools_V0_0_2.zip (https)
MD5: 310904722F900FA34C567FC38634124E
SHA256: 85626574A99BF4D2AB786D8C2FF5B8F6649F1FC7410F1786A24EF0201AAF64AA

Next Page »

The Rubric Theme. Create a free website or blog at WordPress.com.


Get every new post delivered to your Inbox.

Join 198 other followers