$ cat writeup.md…
$ cat writeup.md…
tjctf
Task: pcap with Bluetooth audio packets (custom BTAV protocol over UDP) arriving in shuffled order, plus noise decoy packets. Solution: filter BTAV packets, reorder by 4-byte sequence number, concatenate 600-byte payloads into WAV file, read flag from spectrogram.
$ cat /etc/rate-limit
Rate limit reached (20 reads/hour per IP). Showing preview only — full content returns at the next hour roll-over.
I was transferring a file with very sensitive info over bluetooth, but someone got ahold of the packets...
Given: chall.pcap (314 KB) — a network capture containing Bluetooth audio data encapsulated in custom UDP packets. The goal is to reconstruct the original audio and extract the hidden flag.
The capture contains 509 UDP packets with no native Bluetooth/OBEX protocols — all traffic is eth:ip:udp:data:
192.168.1.100 → 192.168.1.200 (port 50000→62000), each 650 bytes total (608 bytes UDP payload)10.0.0.x → 10.0.1.x addresses with varying data sizes — decoys that don't contribute to the solutiontshark -r chall.pcap -q -z io,phs # Shows: eth:ip:udp:data (508 packets) + one ayiya packet
Each BTAV packet's 608-byte UDP payload has a fixed structure:
| Offset | Size | Field |
|---|---|---|
| 0–3 | 4 bytes | Magic: BTAV (0x42544156) |
| 4–7 | 4 bytes | Sequence number (big-endian uint32) |
| 8–607 | 600 bytes | Audio payload chunk |
Critical discovery: sequence numbers range from 0 to 458 (all 459 values present, all unique), but they arrive in shuffled order. The packets must be sorted by sequence number to reconstruct the original file.
Sorting by sequence number and concatenating the 600-byte payloads produces a valid WAV file:
The WAV header (RIFF....WAVEfmt ) appears at the start of the reassembled data (sequence number 0).
...
$ grep --similar