During my PDF training at 44CON I got the idea for a simple modification: now with document.write(), a third file is created. The file is write.bin.log and contains the pure UNICODE data, e.g. without 0xFFFE header.
To extract shellcode now, you no longer need to edit write.uc.log to remove the 0xFFFE header.
I also included binaries for Windows and Linux (compiled on CentOS 6.0) in the ZIP file.
I think there’s more interest for my program to calculate the SSH fingerprint for Cisco IOS since Snowden started with his revelations.
I fixed a bug with 2048 bit (and more) keys.
Some time ago, Chris John Riley reminded me of a program I had written, published … and forgotten: translate.py. Apparently, it is used in SANS classes.
Looking at this program from 2007, I though: my Python coding style has changed since then, I need to rewrite this.
So here is the new version. It’s backward compatible with the old version (same arguments), but it offers more flexibility, like input/output redirection, allowing it to be used in pipes.
And from now on, I’m going to try to add a man page to all new Python program releases. It’s embedded in the source code, and you view it like this: translate.py –man
kurt wismer pointed me to this post on pastebin after he read my Stoned Bitcoin blogpost. The author of this pastebin post works out a method to spam the Bitcoin blockchain to cause anti-virus (false) positives.
I scanned through all the Bitcoin transactions (until 24/06/2014) for the addresses listed in this pastebin post (the addresses represent antivirus signatures for 400+ malwares).
All these “malicious” Bitcoin addresses, designed to generate anti-virus false positives, have been exclusively used in the 8 Bitcoin transactions I mentioned in my previous post.
The pastebin entry was posted on 2014/04/02 19:01:08 UTC.
And here are the 8 transactions with the UTC timestamp of the block in which they appear:
Block: 2014/04/03 23:12:48
Block: 2014/04/04 01:10:45
Block: 2014/04/04 01:43:25
Block: 2014/04/04 02:58:13
Block: 2014/04/04 04:32:24
Block: 2014/04/04 04:32:24
Block: 2014/04/04 09:36:29
Block: 2014/04/04 09:36:29
So it took a bit more than 24 hours before someone spammed the Bitcoin blockchain with these transactions designed to trigger false positives.
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 0x00 is not encoded, you use option -e 0x00.
This update to my Prefetch File 010 Template adds Sections A through D.
There is extra error handling in this new version.
virustotal-search and virustotal-submit have their own page now: VirusTotal Tools.
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.
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
003a7200 00005600 (100%)
00295600 00001000 (18%)
00294a00 00000c00 (13%)
00296600 00003a00 (67%)
File msi49.tmp was found in only 2 MSI files.
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.