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.
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.
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:
This is a bugfix for my virustotal-submit.py program.
I fixed a bug in the error handling code for unreadable ZIP files.
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
Because I had to use a workaround in my js-unicode-unescape.1sc script to copy an array of bytes to the clipboard, I asked the 010 Editor developers if they could add a function that does exactly this.
They included this new function, CopyBytesToClipboard, in their new version 5.0.
Here is a new version that uses this function:
Mark Woan reported an issue with virustotal-search.py: sometimes VirusTotal returns a JSON object that the json parser can’t parse.
That’s something I didn’t expect. I’ve added error handling for this case.
This is an update for virustotal-search.py and a release of a new tool: virustotal-submit.py. I created this new tool because I needed to submit a sample stored in a password protected ZIP-file (not the ZIP-file), without extracting the sample to disk.
To submit a file to VirusTotal, you just run virustotal-submit.py sample.exe.
If you submit a ZIP file, virustotal-submit.py will extract the first file to memory and submit that to VirusTotal. The ZIP file can be password protected with password “infected”. To submit the ZIP file itself, use option -z.
To submit a batch of samples, create a textfile with the name of the files to submit and use option -f.
virustotal-submit.py supports proxies too (Python variables HTTP_PROXY and HTTPS_PROXY or environment variables http_proxy and https_proxy).
Python module poster is required for this tool.
Updates to virustotal-search.py:
- uses json or simplejson module
- proxies are supported (Python variables HTTP_PROXY and HTTPS_PROXY or environment variables http_proxy and https_proxy)
- option -g forces virustotal-search.py to use the local database in the same directory as the program