Thanks to perfect blue for these nice challenges! The Binary Tree and Switching it up reversing challenges were probably also doable but I didn’t really have the required skill to complete them within the given CTF duration 👍
🎵 Sander van Doorn x Lucas Steve - The World is actually so good.

Misc

BTLE

I stored my flag inside a remote database, but when I tried to read it back it had been redacted! Can you recover what I wrote?

Author: UnblvR

Attached: btle.pcap

Opening up the capture file in Wireshark, we notice that a large percentage of the packets are just Empty PDUs from the Bluetooth Low Energy Link Layer (LE LL).

If we filter by btatt and scroll to the bottom, we can spot a Read Response packet containing the redacted flag in the Value attribute.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

import pyshark
import binascii
import io
cap = pyshark.FileCapture("btle.pcap", display_filter="btatt.opcode == 0x16")

flag = io.BytesIO()
for packet in cap:
	offset = int(packet.btatt.offset)
	flag.seek(offset)

	data = packet.btatt.value.replace(":", "")
	data = binascii.unhexlify(data)

	flag.write(data)

flag.seek(0)
flag.write(b"pb")

print(flag.getvalue())

cap.close()

I also added an additional write of b"pb" to the beginning of the BytesIO object (lines 16-17) because among the sea of Prepare Write Requests, there was a sneaky standard Write for just these 2 letters. But of course, even if you missed this out, it wouldn’t matter because the flag format is known and you would know the correct first 2 letters.

1
2

C:\Downloads\PB\btle_solve.py
b'pbctf{b1Ue_te3Th_is_ba4d_4_y0u_jUs7_4sk_HAr0lD_b1U3tO07h}\n'

Flag: pbctf{b1Ue_te3Th_is_ba4d_4_y0u_jUs7_4sk_HAr0lD_b1U3tO07h}

Reverse

Cosmo

To make it fair for everyone, this binary is fully portable. Run it anywhere! This definitely makes it easier, right?

Author: UnblvR

Attached: hello.com

Googling “cosmo portable binary” led me to discover that the binary is built with Cosmopolitan and is in what is known as the αcτµαlly pδrταblε εxεcµταblε (Actually Portable Executable) format. In short, the binary can run natively on multiple different operating systems without requiring a virtual machine or interpreter.

What are the implications of this? Static analysis will be more difficult, because there will be many distracting unused code paths present in the binary that are only meant to be taken when run on other operating systems. Thus, we will be doing mostly dynamic analysis.

First, basic black-box testing tells us that hello.com accepts a command-line argument that will be checked for the flag.

1
2
3
4
5

C:\Downloads\PB>hello.com
Give flag

C:\Downloads\PB>hello.com asd
No

Next, I opened up the binary in IDA Pro and did a binary string search (Alt-B) for the UTF-8 string “Give flag”.

• rdi (v0) is the number of command-line arguments including the executing binary’s filename (argc)
• rsi is the vector of command-line arguments (argv), so [rsi+8] is the 2nd command-line argument which is our input
• length of input is checked to be 38 characters
• enc_flag is an array of 19 QWORDs
• 2 characters from the input are taken at a time, encoded, and checked against a QWORD from enc_flag

You might notice there are variables in red (v0, v1, v2) in the pseudocode view on the right, and also subroutine calls like len(), print(), and exit() contain no arguments though the arguments can be clearly seen in the disassembly view on the left.
We can fix this by specifying proper custom function type declarations so that IDA knows where function arguments and return values are stored. IDA has helpful documentation for this.

As an example, right click on print(), click Set Item Type, and enter in the definition __int64 __userpurge print@<rax>(char *y@<rdi>). This essentially means that the argument y is passed in rdi, and the __int64 return value will be in rax. _userpurge means that the callee will clean up the stack. I’ll leave the rest of the function prototype redefinitions as an exercise for the reader, but once you’re done the pseudocode will make more sense:

• 1st argument will always be 2 which is the number of characters to take from our string input
• 2nd argument is our input
• 3rd argument is 1 for the first time encode is called but will be the encoded output for future runs

• $ low_{new} = [low_{old} + c_1 + c_2] \ \% \ \mathrm{0xfff1} $
• $ high_{new} = [high_{old} + (low_{old} + c_1) + (low_{old} + c_1 + c_2)] \ \% \ \mathrm{0xfff1} $

$ low_{new} $ and $ high_{new} $ will then form the encoded QWORD result that is checked with enc_flag, and passed in as the 3rd argument to encode the next time is called to become the next $ low_{old} $ and $ high_{old} $.
Armed with this knowledge, we can extract out the 19 QWORDs stored at enc_flag and basically do the reverse of the operations to get the flag:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

flag = ""

enc_flag = [
	0x14400D3, 0x42401AA, 0x8BF028B, 0x0EFA034F, 0x16A1040D, 0x200004EA, 0x2AE20597,
	0x3721065C, 0x4507072B, 0x542F07CD, 0x651208A2, 0x77860970, 0x8B8F0A34, 0x0A0D50ADF,
	0x0B75C0B75, 0x0CFA40C5E, 0x0E9440D01, 0x4520DB2, 0x20B10E6E
]

high_old = 0
low_old = 1

for qword in encoded_flag:
	high = (qword & 0xffff0000) >> 16
	low = (qword & 0x0000ffff)

	c1 = (high - high_old - low_old - low) % 0xfff1
	flag += chr(c1)
	c2 = (low - low_old - c1) % 0xfff1
	flag += chr(c2)
	
	high_old = high
	low_old = low

print(flag)

1
2

C:\Downloads\PB>cosmo_solve.py
pbctf{acKshuaLLy_p0rtable_3x3cutAbLe?}

Flag: pbctf{acKshuaLLy_p0rtable_3x3cutAbLe?}

Thanks for reading!