Caller- vs. Callee-saved Registers

• Callee saved:
  • %rbx, %rsp, %rbp, plus %r12-15
  • Push these at start and pop at end if you use them
  • Remember to push & pop in reverse order
• Caller saved:
  • %rax, %rcx, %rdx, %rsi, %rdi, plus %r8-11
  • Push these before a function call if you’re using them
  • Pop them afterwards

call and ret

• %rip is the Instruction Pointer register (not general)
• call does the following:
  • Computes the normal next %rip address
  • Stores that address on the stack, moving %rsp down 8 bytes
  • Jumps to the provided address, updating %rip
    (Can be “near” or “far” but we’ll let gcc worry about that)
• ret does the following:
  • Reads the value in memory at %rsp into %rip
  • Adds 8 to %rsp to finish popping that value

call and ret

• Neither call nor ret modifies registers except %rsp/%rip.
  • Neither interacts with %rax
    (using it to hold the return value is just a convention)
• Need to design functions so that anyone can call them safely
  • Hence the caller/callee save conventions and %rax
  • Also: %rsp must be a multiple of 16 when call happens
  • You can write working assembly that violates these conventions, but it won’t be working for long

Note: in 64-bit mode (which we are always in) call/callq and ret/retq makes no difference.

Using the stack

• Allocate space by subtracting from %rsp
• Optionally, use %rbp as a base while %rsp moves around
• Use push and pop to store values easily
  • push moves %rsp down + stores a value
  • pop moves %rsp up + loads a value
  • Variants like pushq store different # of bytes
• Moving %rsp and/or %rbp into registers like %rsi can be a sign that a pointer to stack-allocated memory is being sent to another function that will fill it in.

Buffers

• Any time user input happens, you need a buffer
  • Even just numbers are typed as digits first
  • Any time you have a buffer, you need to limit the size
  • But humans aren’t used to working with limited characters
• Compromises happen, and if we’re not careful, excess data gets read in, corrupting memory after the buffer
• If the buffer is on the stack, then the return address can become corrupted

Buffer Example

.data
prompt: .string "Enter a number: "
unused: .string "this will never appear\n"
.text

bad:
  sub $0x10, %rsp
  mov $prompt, %rdi
  call printf
  movq $0, (%rsp)
  mov %rsp, %rdi
  call gets
  mov (%rsp), %rax
  addq $0, %rsp // not sure why we need this
  addq $0x10, %rsp
  ret

.global main
main:
  call bad
  mov $0, %rax
  ret

never:
  sub $8, %rsp
  mov $unused, %rdi
  call printf
  add $8, %rsp
  ret

Buffer Example

• Setup with gdb:
  • Use disas to get the address of the function you want
  • Use x /8gx $rsp to see what’s on the stack
  • Use info reg rsp to see %rsp address directly
  • Look at disas for current function to see how far %rsp has moved from return address = how much padding to include

Buffer Example

• Exploit: 0123456789abcdefp^Q@
  • 0 … f = 16 bytes
  • p → 0x70 in ASCII
  • ^Q → 0x11
  • @ → 0x40

Dump of assembler code for function never:
   0x0000000000401170 <+0>: sub    $0x8,%rsp

(401170 in little-endian order)

Buffer Example

• On tempest:
  • never was now assembled at 0x4005b7
  • b7 isn’t an ASCII character!
    UTF-8 c2b7 is ·
  • 05 is ^E
• So we get: 0123456789abcde·^E@

Use hex2raw.bin instead of trying to type in your exploits!

Buffer Example

.data
prompt: .string "Enter a number: "
unused: .string "this will never appear\n"
.text

bad:
  sub $0x10, %rsp
  mov $prompt, %rdi
  call printf
  movq $0, (%rsp)
  mov %rsp, %rdi
  call gets
  mov (%rsp), %rax
  addq $0, %rsp // not sure why we need this
  addq $0x10, %rsp
  ret

.global main
main:
  call bad
  mov $0, %rax
  ret

never:
  sub $8, %rsp
  mov $unused, %rdi
  call printf
  add $8, %rsp
  ret