Another quickie: Using scdbg to analyze shellcode
Last Updated: 2018-09-03 19:20:39 UTC
by Didier Stevens (Version: 1)
Jim's diary entry "Quickie: Using radare2 to disassemble shellcode" is a good reminder on how to use radare2. I don't often use radare2, indeed I tend to forget which commands to use exactly.
In this diary entry, I would like to showcase a tool I've used before for diary entries: scdbg. scdbg is a shellcode emulator (for Win32 32-bit shellcode). I helps you quickly analyze what shellcode does, by reporting the Win32 API functions called by the analyzed shellcode. I prefer to use the Windows version of scdbg, even on OSX and Linux (with Wine), because it supports more Win32 API functions.
To start your analysis, just run scdbg with option -f to load the shellcode stored in a file:
From this output, we know that the shellcode:
- Loads DLL wininet
- Initializes an HTTP connection with a specific User Agent String
- Connects to an IP address on port 4444
It's important to understand that this analysis is incomplete. The last line of output (Stepcount 2000001) indicates that scdbg stopped after emulating 2000000 instructions. That is the default. To have scdbg generate more analysis results, provide a higher limit using option -s. Or use -s -1, to work without a limit to the number of emulated instructions:
This produces more output, and stops the emulation when an unsupported function is called (GetDesktopWindow).
scdbg can also produce more verbose output, using option -v (or -vv, -vvv, -vvvv). With option -v, we can see each emulated instruction. I use option -s to limit the output:
This is not a disassembly of the shellcode, it's more like a trace: each emulated instruction is disassembled. You can see this after the second instruction (call), control is passed to address 0x40108F.
To produce a classic disassembly, use option -disasm:
scdbg emulates shellcode, it does not execute it. The shellcode in our example, will not establish an HTTP connection for example.
And the following shellcode, an example of a dropper, does not actually create a file when it is emulated:
Of course, with a dropper, you would like to know what the content of the dropped file is. This can be achieved using option -i:
In this interactive mode, the temporary file is still not created, but another file (with extension .drop_0) is created in the current directory, with the content written by the shellcode: