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:

#!/usr/bin/env python

import os
import sys

from pyew_core import CPyew
from easygui import choicebox, fileopenbox, msgbox

def main(filename=None):
    if filename is None:
        filename = fileopenbox(msg="Select PDF file", default="*.pdf", filetypes=["*.pdf"])
        if filename is None:
            return

    pyew = CPyew(batch=True)
    pyew.loadFile(filename)

    streams = pyew.plugins["pdfilter"](pyew, doprint=True)
    if len(streams) == 0:
        msgbox(title="PDF Streams",msg="No encoded streams found")

    l = []
    l.append("About PDF Streams Viewer")
    l.append("See all streams (both encoded and unencoded)")
    for x in streams:
        l.append("Stream %d encoded with %s" % (x, streams[x]))
    l.append("Quit")

    while 1:
        c = choicebox(msg="Select one stream to view it decoded", title="Stream Viewer", choices=l)
        if c is None:
            break
        elif c.lower() == "quit":
            break
        elif c.lower().startswith("about"):
            msgbox(title="About PDF Streams Viewer",
                   msg="Example usage of the Pyew APIs to see PDF streams. Written by Joxean Koret")
        elif c.lower().startswith("see all"):
            pyew.plugins["pdfview"](pyew, doprint=False, stream_id=-1)
        else:
            stream_id = int(c.split(" ")[1])
            pyew.plugins["pdfview"](pyew, stream_id=stream_id)

if __name__ == "__main__":
    if len(sys.argv) == 1:
        main()
    else:
        main(sys.argv[1])

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

some_func:
  ; Do stuff...

start:
   push offset some_func
   jmp edx

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:

000013a7 PUSH 0x74327ebc
000013ac CALL KERNEL32.dll!WriteFile
000013b2 TEST EAX, EAX
000013b4 JZ 0x000013bb      ; 1
000013b6 JMP 0x0000108e     ; 2
000013bb PUSH 0x0
000013bd CALL KERNEL32.dll!DisconnectNamedPipe

Junk code using APIs relatively commons:

00001c1f PUSH 0x0
00001c21 PUSH 0x0
00001c23 CALL SHLWAPI.dll!SHDeleteKeyA
00001c29 PUSH 0x100
00001c2e CALL msvcrt.dll!malloc
00001c34 ADD ESP, 0x4
00001c37 PUSH EAX
00001c38 CALL msvcrt.dll!free
00001c3e ADD ESP, 0x4
00001c41 PUSH 0x0
00001c43 CALL WINMM.dll!timeKillEvent
00001c49 PUSH 0x10005129
00001c4e LEA EAX, [EBP-0x20]
00001c51 PUSH EAX
00001c52 CALL USER32.dll!wsprintfA
00001c58 ADD ESP, 0x8
00001c5b PUSH 0x0
00001c5d CALL ADVAPI32.dll!RegCloseKey
00001c63 CALL ole32.dll!OleUninitialize

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

00000813 XOR ESI, ESI
00000815 PUSH ESI
00000816 MOV EAX, [0x40600c]        ; kernel32.dll!GetModuleHandleA
0000081d CALL EAX
0000081f (PUSH 0x74
00000821 MOV EAX, [0x406080]        ; msvcrt.dll!iscntrl
00000827 CALL EAX
00000829 POP ECX
0000082a TEST EAX, EAX
0000082c JNZ 0x000008ad     ; 1
00000832 PUSH 0x6d
00000834 PUSH 0x68
00000836 MOV EAX, [0x40607c]        ; msvcrt.dll!is_wctype
0000083d CALL EAX

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

f30f1f90909090. rep nop [eax+0x66909090]

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!