shellcode

Question 1

initialize data with

Answer 1

db, dw,dq

Question 2

$

Answer 2

evaluates to current line

Question 3

$$

Answer 3

evaluates to current section

Question 4

times

Answer 4

used to execute one expression multiple times, eg. times 100 movsb runs it 100 times

Question 5

CALL

Answer 5

FF Dx. This could be anything from D0 to D7 based on the register that it’s referencing. Again you’re just trying to recall what a command does when you see it, so you don’t have to memorize the number for each register.

Question 6

JMP

Answer 6

EB. You’re going to be seeing this one alot!

Question 7

INC

Answer 7

4x. Again this goes from 40 to 47 depending on the register. When you fuzz a program you’re going to be using a lot of A’s, B’s and C’s which translate to 41, 42, 43 respectively. That means that sending A (or 41 in hex) to a program, will be interpreted as a INC ECX command. This is useful to know not just for quickly identifying where your offset lands, but also as a reminder that they can be interpreted as commands.

Question 8

DEC

Answer 8

4x. This carries on where INC stopped and goes from 48 to 4F depending on the register.

Question 9

XOR

Answer 9

33

Question 10

jump (or call)

Answer 10

a register that points to the shellcode. With this technique, you basically use a register that contains the address where the shellcode resides and put that address in EIP. You try to find the opcode of a “jump” or “call” to that register in one of the dll’s that is loaded when the application runs. When crafting your payload, instead of overwriting EIP with an address in memory, you need to overwrite EIP with the address of the “jump to the register”.� Of course, this only works if one of the available registers contains an address that points to the shellcode. This is how we managed to get our exploit to work in part 1, so I’m not going to discuss this technique in this post anymore.

Question 11

pop return

Answer 11

If none of the registers point directly to the shellcode, but you can see an address on the stack (first, second, … address on the stack) that points to the shellcode, then you can load that value into EIP by first putting a pointer to pop ret, or pop pop ret, or pop pop pop ret (all depending on the location of where the address is found on the stack) into EIP.

Question 12

push return

Answer 12

this method is only slightly different than the “call register” technique.� If you cannot find a or opcode anywhere, you could simply put the address on the stack and then do a ret.� So you basically try to find a push , followed by a ret.� Find the opcode for this sequence, find an address that performs this sequence, and overwrite EIP with this address.

Question 13

jmp [reg + offset]

Answer 13

If there is a� register that points to the buffer containing the shellcode, but it does not point at the beginning of the shellcode, you can also try to find an instruction in one of the OS or application dll’s, which will add the required bytes to the register and then jumps to the register. I’ll refer to this method as jmp [reg]+[offset]

Question 14

blind return

Answer 14

in my previous post I have explained that ESP points to the current stack position (by definition).� A RET instruction will ‘pop’ the last value (4bytes) from the stack and will put that address in ESP. So if you overwrite EIP with the address that will perform a RET instruction, you will load the value stored at ESP into EIP.

Question 15

limited space

Answer 15

If you are faced with the fact that the available space in the buffer (after the EIP overwrite) is limited, but you have plenty of space before overwriting EIP, then you could use jump code in the smaller buffer to jump to the main shellcode in the first part of the buffer.

Question 16

SEH

Answer 16

Every application has a default exception handler which is provided for by the OS. So even if the application itself does not use exception handling, you can try to overwrite the SEH handler with your own address and make it jump to your shellcode. Using SEH can make an exploit more reliable on various windows platforms, but it requires some more explanation before you can start abusing the SEH to write exploits.� The idea behind this is that if you build an exploit that does not work on a given OS, then the payload might just crash the application (and trigger an exception). So if you can combine a “regular” exploit with a seh based exploit, then you have build a more reliable exploit. Anyways, the next part of the exploit writing tutorial series (part 3) will deal with SEH.�� Just remember that a typical stack based overflow, where you overwrite EIP, could potentionally be subject to a SEH based exploit technique as well, giving you more stability, a larger buffer size (and overwriting EIP would trigger SEH… so it’s a win win)