UnforgottenBits picoCTF 2023 Solution

Description

1. Step 1

   Read the IRC logs

   Observation

   I noticed the disk image contained a home directory for user 'yone' with an irclogs folder, which suggested that IRC chat logs stored in plain text would be the first place to look for leaked credentials or cryptographic parameters.

   Open /vol4/home/yone/irclogs/01/04/#avidreader13.log in Autopsy. It reveals the steghide password akalibardzyratrundle and the AES-256-CBC parameters: salt=0f3fa17eeacd53a9, key=58593a...d508, iv=7a12fd...91.

   Learn more

   Autopsy is an open-source digital forensics platform built on top of The Sleuth Kit (TSK). It provides a graphical interface for analyzing disk images - browsing the file system, recovering deleted files, viewing file metadata, searching for keywords, and examining timeline data. It's widely used by law enforcement and security researchers for forensic investigations.

   IRC (Internet Relay Chat) logs are plain-text records of chat conversations stored on the user's machine. IRC was the dominant real-time text communication protocol before Slack, Discord, and similar platforms. IRC clients like WeeChat and irssi store logs in structured directory trees organized by server, channel, and date - exactly the path structure seen here (irclogs/01/04/).

   Finding credentials in communication logs is a classic forensic technique. People often share passwords, keys, or other sensitive data in private chats, assuming the conversation is ephemeral. In reality, IRC clients log everything by default, and those logs persist on disk - even after the user thinks they've "deleted" the conversation.

2. Step 2

   Extract from 1.bmp, 2.bmp, 3.bmp (steghide)

   Observation

   I noticed the IRC log revealed the passphrase 'akalibardzyratrundle' alongside BMP gallery files, which suggested using steghide to extract hidden payloads from those images since steghide is the canonical tool for BMP/JPEG steganography with a known passphrase.

   Export the four BMPs from /vol4/home/yone/gallery/ and run steghide on each. 1.bmp, 2.bmp, and 3.bmp yield frankenstein.txt.enc, dracula.txt.enc, and les-mis.txt.enc. Decrypt each with the IRC-provided AES params - these are red herrings; they contain classic literature, not the flag.

   bash

   steghide extract -sf 1.bmp -p akalibardzyratrundle

   Copied!

   bash

   steghide extract -sf 2.bmp -p akalibardzyratrundle

   Copied!

   bash

   steghide extract -sf 3.bmp -p akalibardzyratrundle

   Copied!

   bash

   openssl enc -aes-256-cbc -d -S 0f3fa17eeacd53a9 -K 58593a7522257f2a95cce9a68886ff78546784ad7db4473dbd91aecd9eefd508 -iv 7a12fd4dc1898efcd997a1b9496e7591 -in frankenstein.txt.enc -out frankenstein.txt

   Copied!

   Expected output

   wrote extracted data to "frankenstein.txt.enc".
   wrote extracted data to "dracula.txt.enc".
   wrote extracted data to "les-mis.txt.enc".

   What didn't work first

   Tried: Run stegcracker on 1.bmp, 2.bmp, and 3.bmp without first checking the IRC logs for the known passphrase

   stegcracker with a generic wordlist like rockyou.txt will churn through millions of attempts without finding 'akalibardzyratrundle' because it is a concatenation of champion names, not a dictionary word. The IRC log hands you the passphrase directly; using steghide extract -p akalibardzyratrundle extracts the payload in one shot and skips the brute-force entirely.

   Tried: Assume the decrypted .enc files contain the flag and spend time examining frankenstein.txt, dracula.txt, and les-mis.txt for hidden content

   Decryption succeeds and produces readable classic novel text, which looks like progress. These files are deliberate red herrings - the real path forward is 7.bmp, which still requires a separate passphrase not yet discovered at this stage. Recognizing the red herring requires noting that the challenge says to find a flag, not classic literature.

   Learn more

   steghide is a steganography tool that hides data inside image and audio files. It embeds secret data in the least significant bits of pixel values (for BMP/JPEG) or audio samples (for WAV/AU), optionally encrypting the hidden data with a passphrase. The host image's visual appearance is imperceptibly altered. steghide uses AES-128 encryption internally to protect the embedded data, in addition to the image-level hiding.

   Red herrings are deliberate distractions in CTF challenges - they look like progress but don't lead to the flag. The encrypted classic literature files here are designed to consume time and make you question whether you have the right password or decryption parameters. Recognizing red herrings requires methodically tracking what you've tried and what the challenge description actually says to find.

   AES-256-CBC (Advanced Encryption Standard, 256-bit key, Cipher Block Chaining mode) is one of the most common symmetric encryption configurations. The openssl enc command performs both encryption and decryption using standard algorithms. The parameters here - salt, key, and IV - fully specify the decryption; all three must be correct for decryption to succeed.

3. Step 3

   Find the partial password in notes

   Observation

   I noticed the gallery contained a 7.bmp file that steghide had not yet been applied to, and the disk's notes directory was an unexplored artifact, which suggested checking it for a password hint that would unlock 7.bmp.

   Browse /vol4/home/yone/notes/. 3.txt reads: "I keep forgetting this, but it starts like: yasuoaatrox...". This is the beginning of the steghide password for 7.bmp - yasuo and aatrox are two League of Legends champions.

   Learn more

   Notes files on a user's machine are goldmines for forensic investigators. People frequently write down passwords, reminder hints, or partial credentials in plain-text notes, to-do files, or sticky note applications. Even a partial password like "it starts like: yasuoaatrox..." dramatically reduces the search space for a brute-force attack.

   This clue reveals that the password follows the XKCD #936 "correct horse battery staple" philosophy - using multiple common words concatenated together. The words are League of Legends champion names, which the user apparently knows by heart and uses as a memorable but complex password. The challenge design cleverly ties the user's hobby (gaming) to their password strategy, which is realistic forensic behavior.

4. Step 4

   Email forensics - recover the password strategy

   Observation

   I noticed the note said the password 'starts like: yasuoaatrox' but gave no further champions, and Autopsy's deleted-file recovery could surface email conversations, which suggested searching for yone786@ to find deleted emails explaining how many champion names to concatenate.

   Use Autopsy's Keyword Search for yone786@ to surface deleted emails. An email chain between yone786@gmail.com and azerite17@gmail.com references the XKCD #936 password philosophy (four strong words from a favorite game). Since the IRC logs show Yone loves League of Legends, the full password is yasuoaatrox + two more LoL champion names.

   Learn more

   Deleted file recovery is a cornerstone of digital forensics. When a file is "deleted," the operating system typically just marks the space as available - the actual data remains on disk until overwritten. Forensic tools like Autopsy, FTK, and Recuva can recover these "deleted" files by scanning for intact file system metadata or known file headers.

   Email forensics on a disk image involves searching for email client database files (Thunderbird's .mbox and .sqlite files, Outlook's .pst/.ost, Evolution's local mail store). Email metadata - sender, recipient, timestamp, subject - often survives even when the body is partially overwritten. Keyword searching for email addresses like yone786@ can surface relevant messages quickly.

   XKCD #936("Password Strength") is the famous comic arguing that four random common words concatenated (like "correct horse battery staple") provide more entropy and memorability than complex passwords with symbols substituting letters. The math checks out - but as this challenge shows, the strategy fails if the word universe is small (only ~160 LoL champions) and the attacker knows your interests.

5. Step 5

   Generate a wordlist and stegcrack 7.bmp

   Observation

   I noticed the recovered email described an XKCD #936 four-champion concatenation strategy and the note confirmed the prefix 'yasuoaatrox', which suggested generating all pairwise combinations of League of Legends champion names appended to that prefix and feeding the list to stegcracker.

   Build a Python script that prepends yasuoaatrox to every pair of lowercase champion names and writes the combos to output.txt. Feed that list into stegcracker. After ~1259 attempts it finds the password yasuoaatroxashecassiopeia and extracts 7.bmp.out.

   python

   python3 - <<'PY'
   arr = open('leagueOfLegendsChampions.txt').readlines()
   with open('output.txt', 'w') as f:
       for i in arr:
           for j in arr:
               f.write('yasuoaatrox' + i.strip() + j.strip() + '\n')
   PY

   Copied!

   bash

   stegcracker 7.bmp output.txt

   Copied!

   What didn't work first

   Tried: Feed stegcracker a generic wordlist like rockyou.txt instead of generating the custom champion-combo list

   rockyou.txt contains over 14 million passwords but does not include champion-name concatenations like 'yasuoaatroxashecassiopeia'. The tool will exhaust the entire list and report no match. The email forensics and notes clues exist precisely to tell you the word universe and prefix, making a custom generated wordlist the only practical approach.

   Tried: Generate the wordlist with only one champion appended (prefix + one name) instead of two

   The note says 'it starts like: yasuoaatrox...' with a trailing ellipsis, and the IRC logs show passwords formed from four LoL champion names. A single-suffix list (160 entries) will not contain 'yasuoaatroxashecassiopeia', and stegcracker will return no match. The nested double-loop generating all 160x160 pairs is required to cover the correct password.

   Learn more

   stegcracker is a brute-force tool for steghide that tries passwords from a wordlist. It automates what would otherwise be a tedious manual process of running steghide extract repeatedly. The key insight here is that the password space - while large in theory - is severely constrained by the known prefix (yasuoaatrox) and the known word universe (LoL champion names), reducing it to approximately 160 × 160 = 25,600 combinations.

   Custom wordlist generation is often more effective than generic wordlists like rockyou.txt when the attacker has information about the target's interests or habits. The nested loop approach here generates all pairwise combinations of champion names - a form of combinatorial generation. Real-world tools like CeWL (Custom Word List generator) scrape websites related to a target to build tailored wordlists for password attacks.

   The fact that only ~1259 attempts are needed (out of 25,600) suggests the password was found early alphabetically - ashe and cassiopeia are both early in the champion list. This illustrates why password cracking with a targeted wordlist is far more efficient than brute-force: domain knowledge dramatically reduces the search space.

6. Step 6

   Locate the second key in slack space

   Observation

   I noticed that stegcracker extracted 7.bmp.out but the first IRC-derived AES parameters only decrypted the red-herring files, and browser history on the disk referenced golden-ratio-base encoding, which suggested checking file slack space in Autopsy for a second AES key encoded in that unusual format.

   Open the disk in the Windows version of Autopsy (or any tool that exposes slack space). Under Settings → Hide slack files, uncheck both boxes. Inspect 1.txt-slack - it contains encoded data. The browser history in the disk shows research into Golden Ratio Base (φ-base) encoding. Decode the slack data using a golden-ratio-base decoder to obtain a new salt, key, and iv.

   Learn more

   Slack space (also called file slack) is unused space within the last cluster allocated to a file. File systems allocate disk space in fixed-size clusters (e.g., 4096 bytes). If a file is 100 bytes, the entire 4096-byte cluster is still allocated, but 3996 bytes go unused - this gap is the slack space. Data previously written to those sectors may remain there even after the file is overwritten, making slack space a rich source of forensic evidence.

   Golden Ratio Base (Phinary / φ-base) is a non-integer positional numeral system using the golden ratio φ ≈ 1.618 as its base. Every positive integer can be represented in this base using only 0s and 1s (the Zeckendorf representation). It's a highly unusual encoding with no practical cryptographic purpose, but its obscurity makes it a clever CTF clue - the browser history pointing to research on "golden ratio base" is the key hint that tells you which decoder to use.

   The challenge design here exemplifies multi-layer forensic investigation: you must find data hidden in slack space, recognize an unusual encoding from a contextual clue (browser history), decode it to recover crypto parameters, and then use those parameters in another decryption step. Each layer builds on the previous one, requiring both technical skills and careful attention to the narrative clues embedded throughout the disk.

7. Step 7

   Final AES decryption

   Observation

   I noticed the slack space of 1.txt contained golden-ratio-base encoded data that decoded to a distinct salt, key, and IV, which suggested using those new AES-256-CBC parameters with openssl to decrypt 7.bmp.out and finally recover the flag.

   Decrypt 7.bmp.out with the second set of AES parameters recovered from the slack space. Run cat finallyReleased.txt to read the flag.

   bash

   openssl enc -aes-256-cbc -d -S 2350e88cbeaf16c9 -K a9f86b874bd927057a05408d274ee3a88a83ad972217b81fdc2bb8e8ca8736da -iv 908458e48fc8db1c5a46f18f0feb119f -in 7.bmp.out -out finallyReleased.txt

   Copied!

   bash

   grep picoCTF finallyReleased.txt

   Copied!

   What didn't work first

   Tried: Reuse the first set of AES parameters from the IRC logs (salt=0f3fa17eeacd53a9, key=58593a..., iv=7a12fd...) to decrypt 7.bmp.out

   openssl will complete without an error because CBC decryption cannot detect a wrong key - it just produces garbage output. The resulting file will contain unreadable binary data instead of a text flag. The second key and IV come from the slack space of 1.txt decoded via golden-ratio-base; those parameters are distinct from the first set and are the only ones that produce readable output.

   Tried: Omit the -S flag and supply only -K and -iv, assuming the salt is not needed when providing a raw key

   When -K and -iv are provided directly, OpenSSL bypasses key derivation entirely and the -S value is indeed not used for computing the key. However, omitting -S when it is present in the original encryption command may cause a header mismatch on some OpenSSL versions, resulting in a 'bad magic number' error. Including -S exactly as recovered from the slack space ensures compatibility across OpenSSL versions.

   Learn more

   AES-256-CBC with an explicit key and IV (as used here with -K and -iv) bypasses the password-based key derivation step that -pass would use. This means the key material must match exactly - not just the password, but the raw hex key bytes. The -S flag specifies the salt used during key derivation, but when -K and -iv are supplied directly, the salt is ignored in some OpenSSL versions. Supplying all three gives you full control over the cipher state.

   CBC (Cipher Block Chaining) mode processes data in fixed-size blocks (16 bytes for AES). Each plaintext block is XORed with the previous ciphertext block before encryption, chaining them together. The IV (Initialization Vector) is used as the "previous block" for the first block, ensuring that identical plaintexts with the same key but different IVs produce different ciphertexts. Without a random IV, AES-CBC leaks information about repeated message prefixes.

   The grep picoCTF at the end accounts for the possibility that finallyReleased.txt contains a lot of text (the decrypted content might be a long document). Piping to grep quickly isolates the flag line. This "needle in a haystack" pattern - decrypting a large file and then searching it - is a common forensics pattern when the flag is embedded in a larger document.

Flag

Every clue lives on the disk: IRC logs expose the first AES key, deleted emails reveal the LoL-champion password strategy, and slack space hides the second AES key in golden-ratio-base encoding.