EH-Net

I've resumed working with assembly language, having "played" around with it many years ago.  I've generated shellcode that I've put into a C Code frame and then compiled using gcc in mingw.  I loaded the executable into OllyDbg and, as expected, it starts at the entry point which is nowhere near the code that I wrote.  I need to be able to find that code so I can step through it.

I've tried setting a register to a specific value (maybe 1357ABCD) at the beginning of my code and then set that as a condition via Ctrl-T (Condition to pause run trace), but it doesn't stop at my code.  I've also tried inserting a few Int 3 instructions at the beginning of my code (or \xcc\xcc\xcc at the beginning of the shellcode).  When I load the executable in OllyDbg and run it, it stops at the Int 3 but, when I step through the code past the Int 3, using F7 or F8, I frequently get an Access Violation which I never saw without the Int 3 instructions.  The code stops dead and I can't go any further.

I've also tried using Immunity Debugger but it does exactly the same.  If I can't find a way of seeing my code in a debugger and stepping through it to make sure it's doing what it's supposed to, I might just as well give up.  I'm so frustrated!

Does anyone have any suggestions?

Hey Ignatus,

Don't give up! I suggest you go through these free and excellent video tutorials from vivek: http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,6450.msg34580/#msg34580 (http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,6450.msg34580/#msg34580)

I went through all assembly tutorials (both Linux and Windows) and I learned quite a lot.

Good luck and let me know if it helped!

Thank you.

I've seen Vivek's videos and my problem isn't so much writing the code.  I'm far from an expert and have accessed several sites for code examples.  The problem that I have is being able to load it into OllyDbg (or Immunity) and step through the code, watching what happens in the registers, memory etc. to make sure it does what I want.

I've also seen MaXe's excellent paper which deals with writing shellcode by hand and have worked my way through much of it ... but I still don't know how to stop reliably at MY shellcode within the compiled C Code, which is preceded by a whole load of code inserted by my compiler.

The tricks that I've tried result in an Access Violation when I have been successful in finding the start of my code and have stepped through it.

Are you using a 32 or 64 bit OS?

Also, I have an hard time understading what you are doing.

So you want to launch your exploit using an existing C program, isnt? But against which target? You're using OllyDbg on the target application or on the exploit C code?

May I ask you to explain step by step what you have done?

Maybe if you share the source code and the exe we could help you to match the assembly code to the C code, or at least try to spot where the problem is.

write what you did, hope we can help?!

Thank you for the comments.  Here's a detailed step-through, along with the code that I used.  It's not an exploit, but simply a message box.

I have a laptop with 32-bit XP Pro SP3 (not a VM).  The software is OllyDbg v2.00.01, nasm and mingw.

1)  Put the following code through nasm with <nasm msgbox.asm -o msgbox.bin>.


2)  Extract the 105 bytes of NULL-free shellcode from msgbox.bin and put it into a C frame:


3)  Compile the C code with <gcc msgbox.c -o msgbox.exe>.

4)  Run msgbox.exe from the command line and it pops up the message box, so everything's working as it should.

5)  Open OllyDbg and load msgbox.exe.  It show the Entry Point of the executable (PUSH EBP; MOV EBP, ESP; SUB ESP, 18 etc.).

AIM

Find my code in OllyDbg (XOR EAX, EAX; XOR EBX, EBX; XOR ECX, ECX; XOR EDX, EDX etc.) then step through it whilst watching the registers, stack and memory.

I've tried some ideas:

a)  put several int 3 immediately before the initial XOR EAX, EAX instruction
b)  put "\xcc\xcc\xcc\xcc" at the top of my shellcode before compiling
c)  put an instruction such as MOV EAX, 0ABAABA0 before the initial XOR EAX, EAX in the hope that I could search for that particular command (via ctrl-T in OllyDbg)

unfortunately, none of these has allowed me to find my code in OllyDbg.  I'm starting to think that it's not possible so, if it's not, how do I access code that I want to debug?  If it's very complicated, I'll NEED to be able to see exactly what's happening to the registers, stack and memory so I can correct any errors.

I hope that I've provided sufficient information and I apologise for such a lengthy post!

Ignatius,

I have compiled your c code, ran it on WinXp SP3 and the executable works.

Then I opened OllyDbg and from the File | Open menu, I have attached msgbox.exe. I was able to see your assembly code easily. Here is what I did:

1) At the very begining of the program execution, when OllyDbg paused the execution, I put a break point (F2) on the following line:

2) I pressed F9 and the execution stopped at the breakpoint.

3) Now you won't see your assembly code the main window. You have to look at the bottom of your screen. Make sure you look at Hex/ASCII (see attachment).

Do you see your code? (31 C0 31 DB etc)

Thank you for your assistance.  I can see what you mean, but how do I get OllyDbg to step through my code in the CPU (top left) window?  I see that the memory locations in that window are 00401000 to 00401FFF but my code starts at 00402000.

I stepped into (F7) CALL msgbox.00401020 and continued F7 repeatedly but nothing showed my code in the CPU window and I got bored pressing F7 repeatedly!  Eventually, I pressed F9 and, sure enough, the execution worked perfectly.

Surely there's way of stepping through my code in OllyDbg?  The msgbox code is simple enough but, if it was very complicated and didn't work as planned, I wouldn't be able to just "eyeball" it and see exactly why and where it was failing.

EDIT:

I just set a memory breakpoint at 00402000 by hilighting the first of my instructions in the Memory window then right click -> Breakpoint -> Memory and ran it via F9.  It stopped at my code and displayed it in the CPU window so I thought that I'd cracked it.  However, I pressed F8 repeatedly and, after 4 or 5 (memory location 0040203F - CALL 0040200A), I got an Access Violation.

Can you try it on your system and see if you get the same error?  Do you (or anyone else) have any suggestions?

That's ASLR (Address space layout randomization). Basically, Windows makes it harder (but not impossible!!) to develop exploits by constantly changing the "starting address" of an application. So everytime you reboot, you will see your program using a different address. You will also notice that not all the address change, only half of it. There lies the trick of bypassing ASLR while writing exploits. But that's a more advance topic...

You can set breakpoints by selecting a line an hitting F2 or like you did, through the menu.

F8 resumes execution until the next breakpoint or the end of the program, so I am not sure about the access violation...

In the image I posted, you see where I placed my break point (in red). So when I launch the program (F9), Ollydbg stopped at this line. You don't need to press F7 or F8 at this point to see your code, it's in the lower pane.

One last thing I forgot to mention, make sure your see the column name "Hex dump" at the bottom. I think Ollydbg comes with Ascii or something like that display by default. You have to right-click in the lower pane and select "Hex | Hex/ASCII (16 bytes) " to see your asm code.

I may not be able to post again this weekend (no access to Win XP at home...), but I will try to continue help you Monday, if you haven't figured it out by then.

Don't give up!
 

I'm starting to think that there's a bug in OllyDbg.  If I put a breakpoint (F2) on 0040200B, 0040210B and 0040202C and run it to the first breakpoint (F9), it runs without any Access Violation and I can step through/over (F7/F8) as I want.  If I remove the breakpoints and step through/over, the Access Violation recurs.

I'd be grateful if you (or someone else) can try it to see if the behaviour is specific to my system.

If it is a bug, its disappointing because if I had seen the Access Violation, I would have assumed that my code was at fault so would have been chasing my tail to correct it!

Hi Ignatius,

At this point, I think you have everything you need to achieve your goal. I proved to you it works and I tried the best I could to guide you on reproducing it.

I have been a developer for 11 years now and one thing I learn is that every time I think the tool is bad and I can't prove why it's bad, I have always been wrong.

Reboot, reinstall Ollydbg, do what ever you need to do, but it can be done and you are close to doing it.

Banging your head is not always a bad thing. But in order to view your code, I doubt the Access Violation is important.

Good luck and post your results!!

Hey,
there is a few things you can do, for example use the "search for sequence of commands" feature of olly and look for the first 3 instructions of ur shellcode, also look here http://www.ethicalhacker.net/content/view/165/2/ and read this part "Finding Main() - Compiler Code vs Developer Code", hope that helps :)

@H1t M0nk3y:  It's gratifying to have guidance from someone who has such a lot of experience under their belt.  We've both shown that the executable works as planned, both within and outside OllyDbg.  I didn't know if the Access Violation when stepping though/over was due to something that I was doing wrong or if it was, indeed, a bug within OllyDbg.  I turn my computer off each night and the executable is standalone, rather than an installation.  I've tried both v1.10 and v2.00.01 with identical results.  I've also tried Immunity Debugger with the same result.  I think I'll hilight this problem to the OllyDbg developer but I didn't want to make a fool of myself in case the behaviour was due to something that I was. or wasn't, doing!

@matugm:  Thank you for the link.  I tried searching for the initial four xor commands but they didn't show up in the main (CPU) window until I hit the memory breakpoint that I mentioned in an ealier post in this thread.