$ cat writeup.md…
$ cat writeup.md…
tjctf
Task: a 6480-byte file identified as 'data' — each byte was shifted by +0x1d (ROT-29), hiding a UPX-packed ELF with an obfuscated bash script containing a multi-layer encoded flag. Solution: byte frequency analysis to find the rotation offset, UPX unpacking, bash deobfuscation, then base64+gzip+base64 decoding to recover the flag.
$ cat /etc/rate-limit
Rate limit reached (20 reads/hour per IP). Showing preview only — full content returns at the next hour roll-over.
this file isn't making any sense to me. can you discover what it means?
Hint 1: "look at the title" Hint 2: "consider each byte separately"
English summary: a single binary file chall (6480 bytes) is provided. The file command identifies it only as "data" — not a recognized format. The goal is to reverse the obfuscation and find the flag.
$ file chall chall: data $ wc -c chall 6480 chall
The file is not recognized as any known format. A hex dump of the first bytes shows no recognizable magic number.
The most common byte in the file is 0x1d, appearing 644 times out of 6480 bytes. In a typical ELF binary, the most common byte is 0x00 (null). This suggests each byte was shifted by adding 0x1d (decimal 29) modulo 256.
Verification against the expected ELF magic header \x7fELF:
| File byte | - 0x1d | Expected |
|---|---|---|
0x9c | 0x7f | \x7f ✓ |
0x62 | 0x45 | E ✓ |
0x69 | 0x4c | L ✓ |
0x63 | 0x46 | F ✓ |
The "rotation" in the title refers to a Caesar/ROT cipher applied to raw bytes: each byte had 0x1d (29) added to it modulo 256.
After subtracting 0x1d from every byte, the result is a valid ELF binary — but UPX-packed:
$ file chall_decoded
chall_decoded: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), statically linked, no section header
...
$ grep --similar