Return-Oriented Programming: Why literal number used in ROP chain?

Question

Following an article introducing ROP on Windows, I found that the author put some literal numbers in the ROP chain.

The code snippet generating the shellcode:

rop += struct.pack('<L',0x10013b1c) # POP EBX # RETN
rop += struct.pack('<L',0xffffffff) # will be 0x1
rop += struct.pack('<L',0x100319d3) # INC EBX # FPATAN # RETN
rop += struct.pack('<L',0x100319d3) # INC EBX # FPATAN # RETN
                                    #------------------------------------[dwSize (0x1) -> EBX]-#
rop += struct.pack('<L',0x10030361) # POP EAX # RETN
rop += struct.pack('<L',0x90909090) # NOP
                                    #---------------------------------------------[NOP -> EAX]-#

From my understanding, the ROP chain should consist of memory addresses that pointing to the gadget, so CPU will execute the instructions at the corresponding memory address sequentially. Yet, the author put 0xffffffff and 0x90909090 in the gadget chain.

Can somebody explain the use of these literal numbers in the ROP chain? Thank you.

Answer 1

• In this ROP chain, the author needs ebx to be 0x1. However, an entry on the stack in this binary is 4 bytes as this is a 32-bit binary. To fulfill this entry, the number is supposed to be 0x00000001, but writing of null bytes is known to be bad in exploitation since functions like strcpy will stop processing the input when it hits null bytes. Therefore, the author pop the value of 0xffffffff for ebx (using the first 2 lines) and then increase the value on ebx by 1. This wraps around the maximum value on 32-bit system and the value becomes 0x00000001.
• For the second literal number 0x90909090, this is a NOP-sled. 0x90 is the NO-oPeration and it does nothing. This maybe a nop-sled to fulfill the buffer that the author is trying to overflow.
• You can also see other literal numbers in bypassing ASLR that includes overwriting the Global Offset Table of a dynamically linked binary. In this exploitation technique, particular functions in libc will be at a particular offset from the libc base address. You will need to find this libc base address and from the offset obtained from the libc, you can calculate the address of those functions and use them in your exploit. Read more here.