• You need to create an .exe file on the system, which will very likely draw unwanted attention.
• You cannot use an API that downloads your file to a temporary location, because that will likely not retain the .exe extention.
• You need to make an assumption about where a safe place is to write your .exe file, which means you can guess wrong and the code fails.
• You need to store the string ‘.exe’ in the download & execute shellcode, which means this is 4 bytes larger.
• You need to spawn an extra process, which will very likely draw attention.
• You leave cleaning up the exploited process to the download & execute shellcode, which means this needs to be larger.

To get around these problems, I created download and LoadLibrary shellcode: a shellcode that will download a DLL file to a temporary file and load it into the exploited process using LoadLibrary. The benefits of this approach are:

• Smaller code.
• You can use the URLDownloadToCacheFileA API function in urlmon that downloads and saves your DLL to a temporary file, meaning you do not need to provide a location.
• No need to create an .exe file on the system: the extention of a DLL is irrelevant.
• No need to spawn an extra process.
• You can clean up the exploited process from the code in the DLL instead of the shellcode.

The size of the final shellcode depends on the length of the URL for your DLL. For most recent version of the code it is 138 bytes + the length of the URL. This is a pretty decent reduction from the average download and execute shellcodes of 200+ bytes (excluding the URL) that I found around the interwebs.

Project homepage:
http://code.google.com/p/w32-dl-loadlib-shellcode/

The Testival project aims to do all those things and more: it also allows you to test ret-into-libc attacks, set the type of memory allocation you want (RWE flags, etc…), report exceptions in your code to stdout as well as load DLLs to test shellcode in DllMain.

Testival is used by ALPHA3 for automatically testing if all the en-/decoders work.

Testival requires SkyBuild to automatically build all files.

Countslide GetPC is a new technique that I developed to allow the use of nopslides and determine exactly where your shellcode is if you can roughly predict where it will be located in memory.

Given a range of addresses A_min – A_max in which you can predict your shellcode to start, we will calculate the average address A_avg and the maximum absolute deviation D_max like so:
Aavg == (Amin + Amax) / 2
Dmax == (Amax – Amin) / 2
 

Using a nopslide of length D_max * 2 starting at an address in this range and a return address of A_avg + D_max will always cause the nopslide to get hit and thus the code at the end of the nopslide to get executed:

Aavg

Aavg – Dmax

Aavg + Dmax

D = -Dmax

Nopslide

code

O = 2 * Dmax

D = X

Nopslide

code

O = Dmax – X

D = +Dmax

Nopslide

code

O = 0

Return address

In this example, the actual deviation D from A_avg indicates where the exploit actually ends up jumping to. The base address of the nopslide A_nop plus the offset in the nopslide where execution starts O are equal to the return address A_avg + D_max:

Anop + O == Aavg + Dmax
 

Because A_avg and D_max are values we predict, we can calculate the base address A_nop of the nopslide if we can calculate O. And because we know the length of the nopslide is D_max * 2, we can calculate the base address of the code that follows the nopslide A_patcher as well:

Anop == Aavg + Dmax – O
Apatcher == Aavg + Dmax * 3 – O
 

So, any address A_avg + D_max * 3 + X will be in the code that follows the nopslide at offset O + X (if that code is large enough). We can choose to overwrite a byte at that address to modify the code following the nopslide. Which byte of the code gets modified depends entirely on the value of O. This means that the value of O can directly influence what our code does and this is what we use to calculate the value of O.

A small piece of code which I will call the patcher of length P is put after the nopslide followed by a second nopslide of length D_max * 2 which I will call the countslide. When executed, the patcher overwrites a byte in the countslide at address A_avg + D_max * 3 + P (the modification address), which is always inside the countslide. Here’s an example:

Anop + Dmax * 2 + P

Anop

Anop + Dmax * 2

Anop + Dmax * 4 + P

Nopslide

patcher

countslide

Anop + O

Anop + O + P + Dmax * 2

Aavg + Dmax

Aavg + Dmax * 3 + P

Return address

Modification address

The countslide will consist entirely of one byte INC ECX instructions. The patcher will overwrite one byte at the predictable address A_avg + D_max * 3 + P with a one byte POP ECX instruction. It then stores the predictable value A_avg + D_max * 3 + P + 1 on the stack after which the countslide is executed.

Here is what will happen after the exploit makes code jump to address A_avg + D_max in the nopslide:

• the nopslide executes until it reaches the patcher,
• the patcher modifies the countslide at A_avg + D_max * 3 + P,
• the patcher saves the value A_avg + D_max * 3 + P + 1 on the stack, after which the countslide is executed,
• the countslide increments ECX over and over, acting like a normal nopslide, until it runs into the patched POP ECX,
• the POP ECX instruction pops the value A_avg + D_max * 3 + P + 1, saved there by the patcher, off the stack into ECX.
• the countslide then continues to increment ECX for every one byte instruction it executes, until it reaches its end.

The number of INC ECX instructions executed in the countslide after the POP ECX N_inc depends on D_max and O as follows:

Ninc == Dmax * 2 – O – 1
 

So, taking into account that the POP ECX sets ECX to A_avg + D_max * 3 + P + 1, after the countslide has completely been executed, the value in ECX will be:

ECX == Aavg + Dmax * 3 + P + 1 + Ninc
ECX == Aavg + Dmax * 5 + P – O
 

And because A_nop + O == A_avg + D_max, this means the value in ECX is:

ECX == Anop + Dmax * 4 + P
 

Which, as you can see in the second diagram above, is exactly where our countslide ends, so at this point ECX == EIP. The countslide is followed by the shellcode, which can use ECX as the source of its base address.

*UPDATE*: ALPHA3 comes with a working version of Countslide mixedcase alphanumeric ascii GetPC for x86.

w32-bind-ngs-shellcode is hosted on Google code here.

I’ve create a solution to this problem that should be able to find kernel32.dll on all versions of Windows with minimal code size increase. It works by walking the “InInitializationOrder” list mentioned above and checking the length of the name of the module: the Unicode string “kernel32.dll” has a terminating 0 as the 12th character. From my (limited) testing, it seems that scanning for a 0 as the 24th byte in the name allows the code to find kernel32.dll correctly.

More details can be found here.

The code:

    XOR     ECX, ECX                    ; ECX = 0
    MOV     ESI, [FS:ECX + 0x30]        ; ESI = &(PEB) ([FS:0x30])
    MOV     ESI, [ESI + 0x0C]           ; ESI = PEB->Ldr
    MOV     ESI, [ESI + 0x1C]           ; ESI = PEB->Ldr.InInitOrder
next_module:
    MOV     EBP, [ESI + 0x08]           ; EBP = InInitOrder[X].base_address
    MOV     EDI, [ESI + 0x20]           ; EBP = InInitOrder[X].module_name (unicode)
    MOV     ESI, [ESI]                  ; ESI = InInitOrder[X].flink (next module)
    CMP     [EDI + 12*2], CL            ; modulename[12] == 0 ?
    JNE     next_module                 ; No: try next module.
 


NB. See the comments for a problem (and solution) on Win2K targets courtesy of aniway.