Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Simple ret2win. It calls gets on rbp-0xd0, and there's a function called flag that grabs the flag from flag.txt
0xd0 + 8 bytes of padding + address of ret + flag function. Address of ret is needed on remote because stack alignment is a bitch
Lets look into this. Let's first of all disassemble main. We'll notice lots of logic going on, and lots of functions - eat, zzz, etc. We also see some variables - once, sleepy, hungry, etc. These have to do with making your pwnagotchi happy. Is this important? No, not at all.
The main thing is that there is a gets call on rbp-0xc. This means that we instantaneously have a buffer overflow vulnerability. 0xc is 12, and 12 + 8 = 20, so we will have 20 bytes until the return address. This is confirmed by pattern.py.
No PIE, NX. My first instinct was ROP, but there wasn't enough gadgets. So I used ret2libc instead.
There's no PIE in the binary, so the GOT and the PLT stay constant. This allows us to execute a simple ret2plt attack, calling puts@plt on puts@GOT, and leaking the puts libc address. This libc address can be used to find the libc version of the remote instance, which is libc6_2.27-3ubuntu1_amd64. From there, we can call main again, and execute a simple ret2libc attack.
There's two things stopping us here, which I'll review.
First of all: main has some weird logic at the beginning. What actually happens is not important, what you need to know is that it can detect whether you've done weird stuff and called it again. When it detects this, it says "um, this is awkward" and quits. How do we bypass this? Simple. We jump to the specific instruction in main which starts our input, and continue from there.
Second thing: quite subtle. When we execute this attack remotely, everything goes smoothly. However, once we hit the final payload, things stop working. we get an EOF.
It's important to review what's happening. When our remote exploit does not work, the "pwnagotchi name is not happy!" message does NOT show up. What does this mean? It means we likely a hit a problem with the stack. You guessed it, stack alignment.
We can add a simple ret gadget in the middle of our payloads(0x400285) and our exploit succeeds! Script below
My fakestack pointer was a pointer to a random page mapped read-write in memory, so that the program could resume and make local variables like normal.
Let's look at the source code. It gets an input, and checks if it's length is 23 first of all. If not, it automatically tells you your input is wrong.
Then, it goes in a for loop. This loop will iterate 3 times. Each time, it sets inp(variable containing the input) to transpose(inp), and then to xor(inp)
Essentially, 3 times, it transposes then xors the input.
the xor is self explanatory, it xors the input with a key.
The transposing is a little different. It has a list of numbers, then does the equivalent of this in java(if the list of numbers was called nums)
return ''.join(inp[i] for i in nums)
We can reverse this relatively simply with a python script, and get the flag.
There's a text file IceCreamManual.txt. It's actual contents aren't important, more what happens to it. The program reads all bytes from this file, then calls fillMachine on it. fillMachine basically grabs specific indexes of the file and puts them together into a byte string. I recreated this function in python and ran it to get the string lollookatthistextigotfromthemanual. The code calls 4 functions on our input, then compares the final result to that string. So we must reverse from that string back to the flag.
The 4 functions it calls, in order, are strawberry shuffle -> vanilla shuffle -> chocolate shuffle -> toppings
We'll work in reverse, going back one step each time to get the original input.
First things first: toppings. Toppings basically takes an array of bytes(bytes can be negative in java! It's weird, but largely unimportant) and every byte of the output is the respective byte of the input + the respective byte of the toppings byte array. We can simply subtract the values.
Next: chocolate shuffle
This code is a bit more complicated. For every index in the output: if an even index, AND index is > 0, set output[i] = input[i - 2] if an even index, and index IS 0, set output[i] = input[33]
if an odd index, AND index is < 32, output[i] = input[i + 2] if an odd index, and index >= 32, output[i] = input[1]
We can basically recreate the loop in python and swap around the indexes, e.g
input[i + 2] = output[i]
to reverse this step.
Next: vanilla shuffle.
This is simple. For every index in the input - if the index is even, add 1 to the byte value. If the index is odd, subtract 1. Again, easily reversible with a simple loop.
Finally, strawberry shuffle. The final thing to reverse to get the flag. The code looks a bit weird at first, but in reality all it does is reverse the string.
If we string all these things together, we get the flag. Script below.
Download -> read file -> We've been provided with a java file
Upon some basic looking, we can see that the input has to be 18 chars - if (inp.length() != 18) { System.out.println("Input is incorrect") }
.
We can also see - if (inp.equals("inagzgkpm)Wl&Tg&io")) { System.out.println("Input if the flag") }
. So we know our input, and that string is 18 chars. Perfect.
We also see that - inp = shift( shift(inp) )
, so now time for the reversing.
All shift()
does is gets a character in a string and then minuses i from that, and then stores it in a ret variable. So doing a bit of changing a minus to a plus, we manage to get a new string from that - "iocj~lqwu2aw2au5y\x80"
(\x80 isn't an ascii char) - We can remove that \x80, as we know that it's going to be }.
I couldn't code this in python, so I turned to a online java compiler, and performed shift2()
on that string, but again, taking a plus as a minus for reversing it.
That should return the flag, and you just pad it with the } that we took out earlier (\x80)
Python rev for shift
Java rev for shift2