Didier Stevens

Monday 22 February 2010

Ping Shellcode

Filed under: My Software,Shellcode — Didier Stevens @ 10:26

I’ve added 2 new assembly source files for shellcode to execute a ping.

First one does a simple ping, second one does a ping with the computername and username in the ICMP packet data.

Tuesday 16 February 2010

MemoryLoadLibrary: From C Program to Shellcode

Filed under: Hacking,My Software,Shellcode — Didier Stevens @ 0:40

The DLL-loading shellcode I used in my cmd.xls spreadsheet was generated with a method I worked out to generate WIN32 shellcode with a C-compiler. You can find it on my new Shellcode page.

With this release, I provide you with all the tools you need to build your own version of cmd.xls:

Monday 8 February 2010

Excel with cmd.dll & regedit.dll

Filed under: Hacking,My Software — Didier Stevens @ 21:17

I modified the source code of ReactOS‘ cmd and regedit for the following trick:

Let me summarize how I did this, as this is the combined result of several techniques I blogged about before.

You can download regedit.dll here and the new version of cmd.dll with the DLL command here. The DLL command I added allows you to load a DLL with LoadLibrary or directly into memory (/m option). When loaded with LoadLibrary, the library will be unloaded with FreeLibrary unless you use option /k to keep it loaded.

The DLL command assumes that your DLLs execute via the DllMain entry-point when they get loaded.

Thursday 4 February 2010


Filed under: Hacking,My Software — Didier Stevens @ 1:16

This is something I’ve wanted to do for some time: take a command interpreter and transform it from an EXE into a DLL.

Why you ask? Well, because it’s a fun challenge ;-)

But also because a DLL is loaded into a process. In a restricted environment, it can be injected into a legitimate process and thus bypass the restriction mechanisms.

Metasploit’s Meterpreter is another example of a command interpreter in DLL form.

cmd.exe from Microsoft is closed source, but there is an open-source variant available from the ReactOS project.

Compiling cmd.exe from ReactOS is simple: download the source-code and the ReactOS build environment. Install it, start the build environment  and issue command make cmd. That’s all you need to do to compile cmd.exe (I used version 0.3.11).

Transforming the source code to generate a DLL in stead of an EXE is simple. You need to change 3 files.

Edit file cmd.rbuild and make these changes to the module element:

<module name="cmd" type="win32dll" installbase="system32" installname="cmd.dll" unicode="yes" crt="msvcrt">

Because I want to use this DLL in GUI-processes without console, I need to create a console. Edit file cmd.c and add AllocConsole(); to function cmd_main:

InputCodePage= 0;
OutputCodePage = 0;



And because a DLL has another entry-function than an EXE, edit file main.c and replace function main with function DllMain:

#include <precomp.h>

 IN PVOID hInstanceDll,
 IN ULONG dwReason,
 IN PVOID reserved)
 switch (dwReason)
 cmd_main(0, NULL);




 return TRUE;

That’s it. Recompile with make cmd to generate cmd.dll

There are still some improvements we can make, but that’s for a later version: error messages are not displayed, exiting the shell terminates the host process, …

You can download the modified source files and compiled cmd.dll here.

This is a screenshot of cmd.dll injected inside Excel with my memory module shellcode:

Tuesday 2 February 2010

Quickpost: Quasi-Tautologies & SQL-Injection

Filed under: Hacking,Quickpost — Didier Stevens @ 9:54

Last OWASP/ISSA Belgian chapter meeting was the location of an interesting discussion. For a full report of the meeting, read Xavier’s excellent blogpost.

Many SQL-injection techniques rely on tautologies: adding an expression that is always true to the where-clause of a select statement. Like OR 1=1. 1=1 is a tautology, it’s an expression that always yields true.

So if SELECT * FROM USERS WHERE USERNAME = ‘ADMIN’ and PASSWORD = ‘UNKNOWN’ doesn’t select any rows because the password is not correct, injecting ‘ OR 1=1 – gives SQL statement SELECT * FROM USERS WHERE USERNAME = ‘ADMIN’ and PASSWORD = ” OR 1=1 –’ which will return all rows, because the where-clause is always true (OR 1=1).

There are several security applications (WAFs, SQL firewalls, …) designed to monitor the stream of SQL statements and reject statements with tautologies, i.e. the result of a SQL-injection. Some are very simple and just try to match pattern 1=1. Bypassing them is easy: 1>0 is also a tautology. Others are more sophisticated and try to find constant expressions in the where-clause. Constant expressions are expressions with operators, functions and constants, but without variables. If a constant expression is detected that always evaluates to true, the firewall assumes it’s the result of a SQL-injection and blocks the query.

This is all classic SQL-injection, but now comes the interesting part.

What if I use an expression that is not a tautology in it’s mathematical sense, but is almost one… Say I use expression RAND() > 0.01 ? The RAND function is a random number generator and returns a floating point value in the range [0.0, 1.0[. Expression RAND() > 0.01 is not a tautology, it’s not always true, but it is true about 99% percent of the time. I call this a quasi-tautology.

A firewall looking for tautologies will not detect this, because it is not a tautology. But when you use it in a SQL-injection, you stand a 99% chance of being succesful (provided the application is vulnerable to SQL-injection)!

There are other functions than RAND to create quasi-tautologies. An expression comparing the seconds of the current system time with 59 is also a quasi-tautology.

The GreenSQL firewall will detect SQL statements with quasi-tautologies, not because it looks for them, but because it builds a whitelist in training mode.

Quickpost info

The Rubric Theme Blog at WordPress.com.


Get every new post delivered to your Inbox.

Join 196 other followers