Meditation, The Art of Exploitation

Thinking? At last I have discovered it--thought; this alone is inseparable from me. I am, I exist--that is certain. But for how long? For as long as I am thinking. For it could be, that were I totally to cease from thinking, I should totally cease to exist....I am, then, in the strict sense only a thing that thinks.

Thursday, June 22, 2006

char * ptr = "hello" and char carray[] = "hello"

I was intrigued by this interview question where the reviewer asked if a char * ptr will take more space than a char carray[]. I found the following with gcc 2.96 on ia32:

#include < stdio.h>

static char * ptr = "hello";
int x = 0x41414141;
static char ptr8[] = "hello888";
int y = 0x42424242;
char ptr5[] = "hello";
int z = 0x43434343;
static char ptr8a[8] = "hello888"; // I got confused here between
ptr8 and ptr8a
int u = 0x42424242;

int main(void){

int i;
for(i = 0; i < 9; i ++)
printf("%d %c\n", i, ptr8[i]);
if((unsigned char)ptr8a[8] == 0x42)
printf("not null terminated\n");
if((unsigned char)ptr5[5] != 0x43)
printf("null terminated, aligned on 8 byte boundary\n");

printf("ptr[0] = %c\n", ptr[0]);

Executing this (after compiled with gcc 2.96 with -O3)
0 h
1 e
2 l
3 l
4 o
5 8
6 8
7 8
not null terminated
null terminated, aligned on 8 byte boundary
ptr[0] = h

Now I did a binary dump of the ELF binary file, here is the
interesting sections:
Contents of section .rodata:
80485e0 03000000 01000200 00000000 00000000 ................
80485f0 00000000 00000000 00000000 00000000 ................
8048600 68656c6c 6f002564 2025630a 006e6f74 hello.%d %c..not
8048610 206e756c 6c207465 726d696e 61746564 null terminated
8048620 0a000000 00000000 00000000 00000000 ................
8048630 00000000 00000000 00000000 00000000 ................
8048640 6e756c6c 20746572 6d696e61 7465642c null terminated,
8048650 20616c69 676e6564 206f6e20 38206279 aligned on 8 by
8048660 74652062 6f756e64 6172790a 00707472 te boundary..ptr
8048670 5b305d20 3d202563 0a00 [0] = %c..
Contents of section .data:
804967c 00000000 00000000 cc960408 00000000 ................
804968c 00860408 41414141 68656c6c 6f383838 ....AAAAhello888
804969c 00000000 42424242 68656c6c 6f000000 ....BBBBhello...
80496ac 43434343 68656c6c 6f383838 42424242 CCCChello888BBBB

RVA 804968c -> 00860408 (08048600) ->"hello"

Tuesday, June 06, 2006

Part 3 Patch binary file directly to bypass strongname security

The following tools will make this job very easy, lordPE, winhex, Lutz's .net reflector and ildasm. The easy part first, to bypass strong name security with lordPE is as simple as changing one byte in the PE header->CLR header->strongname key check. lordPE has support to directly modify PE header, go ahead and change the key length to 0, usually from 0x80. This change completely disables strong name check on patched binary.

To reroute/patch binary code flow. Combine the strength of ildasm and .net reflector. .net reflector can generate source code level listing, making code reverse engineering so much easier; also dump a copy of target binary with ildasm with opcode turned on. This creates a dump file with each IL command's binary opcode value available. Find the target opcode sequence in winhex and patch it to whatever result you desire.

Saturday, June 03, 2006

Part 2 Approaching .net protection by decompile/modify/compile

There are several tools availble to decompile .net assembly. I recommend two tools, one is the microsoft tool ildasm included in .net SDK distribution. The next one is Lutz Roeder's .net reflector, best free .net decompiler available.

Run 'ildasm' and open a .net assembly, you will see how the file is broken down to variables, methods, resources, etc. You can dump the assembly to a text file containing CLR intermediate language. Once you have the text file, you can start making changes to the IL. Afterwards, run 'ilasm' on the dumped/modified assembly text file and resource files to generate a modified binary, either a DLL file (use '/DLL' flag with ilasm) or a EXE file. Resources can be included with /RESOURCE= flag.

Simply modify IL will generate CLR load file exception. This is due to .net strong name security check. Inside the .net IL text file, usually at the begining, you can see that it has a public key and a hash code used by the strong name security scheme. To bypass strong name check, remove these key related text and recompile. This will do the trick.

Security model of the .net framework and how to defeat it. Part 1 Basics

In this mini series, I will discuss the microsoft .net framework security model. I recommend the following readings as introduction material to understand .net security model.

.net IL using ildasm and ilasm
Part 1 - Learn to break a .NET Assembly:

Part 2 - Learn to protect your .NET assemblies from being tampered:

Part 3 - Learn to break Strong Name .NET Assemblies:

Understanding, programming and debugging IL .net application:
Part 1 Introduction

Part 2 A short description and .NET application

Part 3 Debugging

Tools (It can be said, a hacker is as good as his tools)
New tool:
.NET decompiler
ildasm and ilasm (decompiler and compiler of intermediate language)

Old friends:
LORD PE (examine and modify PE header)
WINHEX (examine and modify binary file in hex mode)
REGEDIT (studying protection scheme used by certain softwares)

Now, there are 2 ways to actually patch a .net binary file, the first way is to directly patch the binary file with a hex editor; the second way is to decompile/modify/compile .net intermediate language (IL). Both approaches works equally well and the details of both methods are discussed in the URL links I provided.*security*%26hl%3Den%26lr%3D%26selm%3D%2523UDXSOX0EHA.3820%2540TK2MSFTNGP11.phx.gbl%26rnum%3D2#bf09582265c8f154
Discusses the method used in this article
Has a section of .NET header in figure 10.
Details on how to crack .net protection.
For the old schools.