tl;dr
- Decoding the strings found in TCP stream 0.
- Analysing and extracting data sent via different ports of TCP.
- Using character-wise caesar from the extracted data.
- Zip cracking
tl;dr
Intended solution of PRetty stroNG challenge from InCTF Internationals 2019
tl;dr
Intended solution of Wannavmbe challenge from InCTF Internationals 2019
tl;dr
Intended solution of waRSAw challenge from InCTF Internationals 2019
tl;dr variant of LSB Oracle Attack on unpadded RSA
tl;dr
tl;dr
tl;dr
Solved by: stuxn3t
tl;dr
Array.pop. Uint32Array and a Uint8Array to get a overflow in an ArrayBuffer and proceed to convert this to arbitrary read-write and execute shellcode.tl;dr
This post will describe how I exploited CVE-2019-14378, which is a pointer miscalculation in network backend of QEMU. The bug is triggered when large IPv4 fragmented packets are reassembled for processing. It was found by code auditing.
tl;dr
Challenge Points: 769
Challenge Solves: 7
Solved by: R3x
Initial analysis shows us that there are minor changes between this binary and the signal_vm binary - in the way the VM works. Please refer to the writeup of signal_vm for learning about the VM structure.
In the first stage of the challenge - we had access to all of the VM registers since they were all in the parent itself. Now in signal_vm_de1ta they are all in the memory space of the child - This makes it hard for us to track what is happening in the VM since we aren’t able to directly view its memory or registers.
The VM uses the same four signals (SIGTRAP, SIGILL, SIGSEGV and SIGFPE) to serve as instruction classes. However there are a few significant differences from the first stage.
The VM(parent) uses PTRACE_PEEKDATA and PTRACE_POKEDATA to read and write data into the child memory which contains the memory and the registers.
We tweaked the script for the old challenge to work for this one. Since we don’t have the register and memory states this time as that happens in the child, we decided to go ahead and write our own code to parse the instructions. So we were able to predict the contents of the VM registers accurately which helped us in figuring out what the child did.
1 | import gdb |
This was probably the most complicated VM algorithm I have seen in CTFs. I have written the python version of the code below - you can take a look at it.
1 |
|
Looking a bit deeper into the algorithm we see that it is actually taking the numbers in a very specific order.
| x | z = ((x * (x + 1)) >> 1) | range of y + z |
|---|---|---|
| 0 | 0 | 0 |
| 1 | 1 | 1..2 |
| 2 | 3 | 3..5 |
| 3 | 6 | 6..9 |
| 4 | 10 | 10..14 |
| … | … | … |
| 100 | 5050 | 5050..5150 |
From this order we figured out that this was basically dividing the array in form of a triangle and then trying to find the path which has the maximum sum.
Now we know what the VM is trying to do and it is taking a long time since the VM is trying to bruteforce the path. Now all we need to do is to find a more efficient way to solve this.
Since it is copying the path that has the maximum sum. I printed out the entire array in the form of a triangle and then I searched for the flag format manually - that is de1ctf{ and then I followed it until I reached the end.
You can probably trace - ~triangle~is from the above screen shot. That was like a wrapper around the flag.
flag was
de1ctf{no~n33d~70-c4lcul473~3v3ry~p47h}
After talking to the admin at the end of the CTF I learned that this was a DP problem and the solution was pretty simple.
You can take a look at the problem statement and the solution techniques here.