Lab 5: Shellcode testing

Lesson:

Where are we?

We now have:

• Control over EIP

• An area where we can write our code (at least 144 bytes large. If you do some more tests with longer patterns, you will see that you have even more space… plenty of space in fact)

• A register that directly points at our code, at address 0x000FFD08

What’s next?

Now we need to:

• Build real shellcode

• Tell EIP to jump to the address of the start of the shellcode

  • We can do this by overwriting EIP with 0x000FFD08

• We’ll build a small test case:

  • First 26064 A’s

  • Then overwrite EIP with 000FFD08, then put 25 NOP’s, then a break, and then more NOP’s

• If all goes well, EIP should jump 000FFD08, which contains NOPs

• The code should slide until the break

Weird…

• The application died, but we expected a break instead of an access violation

• When we look at EIP, it points to 000FFD08, and so does ESP

• When we dump ESP, we don’t see what we had expected

Now what?

• So jumping directly to a memory address may not be a good solution after all

• 000FFD08 contains a null byte, which is a string terminator

  • The A’s you are seeing are coming from the first part of the buffer

• We never reached the point where we started writing our data after overwrite EIP

• Besides, using a memory address to jump to in an exploit would make the exploit very unreliable. After all, this memory address could be different in other OS versions, languages, etc…

• We have to use another technique to achieve the same goal: make the application jump to our own provided code

• Ideally, we should be able to reference a register (or an offset to a register), ESP in our case, and find a function that will jump to that register

• Then we will try to overwrite EIP

Moving forward…

• We have managed to put our shellcode exactly where ESP points at (or, if you look at it from a different angle, ESP points directly at the beginning of our shellcode)

  • If that would not have been the case, we would have looked to the contents of other register addresses and hoped to find our buffer

• Anyways, in this particular example, we can use ESP

• The reasoning behind overwriting EIP with the address of ESP was that we want the application to jump to ESP and run the shellcode.

  • Jumping to ESP is a very common thing in Windows applications

  • In fact, Windows applications use one or more DLLs, and these DLLs contain lots of code instructions

  • Furthermore, the addresses used by these DLLs are pretty static

  • So, if we could find a DLL that contains the instruction to jump to ESP, and if we could overwrite EIP with the address of that instruction in that DLL, then it should work, right?

Yep, get ready for it!

Assignment:

• Step 1 – Modify code to place new EIP and to test whether shellcode will work

• Step 2 – Run executable, transfer crash_[sid].m3u to target, and run it in the debugger

  • If the program stops running and you receive an “INT3 command at [memory address]” than we have executed the “\xcc” in our program

• Step 3 – Discover what went wrong

Answers:

• View associated .txt file