Red Cypher CTF walkthrough - Capturing The Professor
Have you ever wondered what it feels like to solve puzzles that challenge your mind, test your technical skills, and sometimes make you pull an all-nighter? That’s exactly what a CTF – Capture The Flag competition does. And back in my time at the Faculty of Engineering, University of Ruhuna, I had the privilege of organizing Red Cypher, the first-ever CTF by a government university in Sri Lanka.
It wasn’t just about the competition—it was about creating a playground for students to explore cybersecurity, learn by doing, and push their limits. From cryptography puzzles to tricky reverse engineering tasks, every challenge was designed to teach something new while keeping it fun.
Track the fugitives. Find the Professor. Stop the next heist.
Two years after the biggest digital heist in history, Interpol forms RedCypher, a cyber-intelligence task force assembled from the brightest minds. Your team? A digital task force racing through cities, clues and code. The prize? Catching the crew and the mastermind known only as The Professor.
This was the story we ran for RedCypher 2.0 and below I’ll tell it like a thriller: the setup, the tension, the puzzles, and a guided walkthrough of the most memorable tasks. If you were a participant, this is the post-match debrief. If you weren’t treat this as both a story and a learning lab.
Registration was itself a CTF
Instead of a boring signup form, teams had to earn their entry: the registration portal itself was a lightweight CTF challenge. Only after solving that challenge could you complete registration and join Red Cypher 2.0. It set the tone from the very first click — playful, competitive, and immediately technical.
Why do this?
Signals seriousness — participants knew this was a real CTF (not a casual quiz).
Raises the floor — we filtered out accidental signups and ensured teams had minimal technical chops.
Onboards players — the task taught the contest rules and gave a tiny taste of the types of puzzles ahead.
Builds excitement — teams shared hints, bragged on socials, and talked about a “registration puzzle” (great early engagement).
How it worked (user flow)
Team lands on the registration page and sees a short story hook and a challenge prompt.
They solve the puzzle in their browser or locally, producing a small token/flag (e.g., RC2{reg_token_xyz}).
They paste the token into the registration form field and submit.
Server verifies the token and, if valid, allows account creation and issues team credentials.
This was intentionally simple — not an obstacle, but a gateway.
Example registration challenge (concept)
Prompt shown on site
“The Professor left a short note in a parking meter near the lab. The note’s text is Base64-encoded and rotated by an unknown Caesar shift. Decode it and paste the result as your registration code.”
What teams do
Copy the encoded string.
Try reversing Caesar shifts (0–25) until the Base64 becomes valid.
Base64-decode the valid string to reveal the token RC2{welcome_agent}.
Paste the token into the registration field.
This combines tiny bits of classical crypto, quick scripting, and iterative thinking — perfect for warmup.
Server-side validation (safe example, pseudocode)
We validated tokens server-side so people couldn’t bypass the challenge by guessing a predictable pattern.
The Setup — Competition Flow (How it played out)
Teams played as RedCypher units.
Clues and challenges were released in stages, each stage mapping to one fugitive.
Complete all tasks for a stage → that crew member is “caught.”
Catch every crew member → the final stage to find The Professor unlocked.
Stage list (in order): Tokyo → Berlin → Nairobi → Helsinki → Rio → Denver → Moscow → Oslo → Lisbon → The Professor (final)
Each stage combined storytelling and technical puzzles: web-apps, images, binaries, LLMs, forensics — mixed to teach, frustrate, and reward.
The Storyline Snapshot — “Operation Heist Hunt”
Two years after billions were siphoned in the Great Heist, clues surface — scraps of evidence, a thank-you post on social media, a doctored image, a suspicious live terminal, a keystroke capture on a USB, an encrypted archive, and a file with layered classic ciphers. Each clue led to a new city, a new puzzle, and one step closer to the Professor.
Below I’ll walk you through the most interesting stages — not just the answers, but how we designed them, how teams were expected to think, and what to learn from each. Think of this as a tutorial disguised as a thriller.
Ride of Secrets — Oslo
Category: Web / SQL Injection Tag: SQL injection Clue: A Facebook post thanking CypherTaxi — the site name is inside. Goal: Find the taxi website; use SQLi to extract Oslo’s ride details.
The scene
Oslo posts a public thanks on Facebook, naming a taxi company. The post is the breadcrumb. Teams needed to find the taxi site, discover a vulnerable endpoint, and extract the ride records for “Oslo”.
How teams approached it (walkthrough, conceptual)
Footprint the target — use the company name from the Facebook post to discover the website (manual search or OSINT).
Map the web app — find pages that take parameters (search forms, tracking pages, ride-id query parameters).
Probe safely — test inputs for unusual behaviour (errors, differing responses). Look for classic SQLi signs: unusual error messages, time delays, or response length differences.
Exploit conceptually — where an application builds SQL queries by concatenating user input, a manipulated parameter can alter the query logic and reveal rows. In a contest environment you would:
Use safe, non-destructive payloads that reveal columns or content via boolean/time-based inference.
Prefer inference techniques (e.g., true/false checks) rather than destructive writes.
Extract ride details — iterate to retrieve relevant columns for records that match “Oslo”.
Learning & defensive takeaways
Always use parameterized queries / prepared statements on the server side.
Validate and sanitize input, and avoid verbose DB errors in production.
Logging and anomaly detection (unexpected query patterns/time delays) help detect exploitation.
The Hidden Signal — Rio
Category: Steganography + Cryptography + Forensics Tags: DCT, QR, steganography, symmetric cipher, image analysis
The scene
An image arrives with a hidden QR, a secret key baked into it, and a binary payload embedded into DCT coefficients of an image (JPEG-style 8×8 DCT blocks). That binary, once recovered, yields hex that must be decrypted using the key obtained from the QR.
Walkthrough (conceptual + practical hints)
Image inspection
Open the image in an image editor and examine the channels separately (R/G/B). Sometimes the QR is hidden in one color channel.
Adjust brightness/contrast and inspect single channels to reveal faint overlays.
Tools: image viewers (for quick checks), GIMP/Photoshop or Pillow in Python for programmatic channel extraction.
Find the QR
Extract channels and save them as separate images; try thresholding to make the QR visible.
Once visible, scan the QR with a QR reader (or use pyzbar/zbar).
Key extraction from QR
The QR contains a string — for the challenge it was the symmetric key (or a passphrase used to derive the key).
You may need to derive the encryption key (e.g., SHA256(key_text) or a KDF) depending on the hint.
Extract binary from DCT coefficients
JPEGs are built from 8×8 DCT blocks. Mid-frequency coefficients are often targeted for robust stego.
Approach:
Decode the JPEG to its DCT coefficients (libraries like jpegio in Python or custom tools).
For each 8×8 block, select a specific mid-frequency coefficient index and record the sign (positive → bit 1; negative → bit 0) or parity depending on the challenge notes.
Build the bitstream and chunk it into bytes/hex.
Example conceptual pseudo-flow (Python-like pseudocode):
for each 8x8 block: coeff = block[mid_freq_index] bit = 1 if coeff > 0 else 0 append bit to stream bytes = bits_to_bytes(stream) hex_string = bytes.hex()
Cryptographic decryption
The recovered hex string is actually ciphertext. Convert to bytes, then decrypt using the symmetric algorithm hinted (e.g., AES-CBC).
Be careful with IV handling: many challenges prefix IV to ciphertext or give it separately.
Derive the key per hint (e.g., key = sha256(qr_string)[:16] for AES-128).
Decrypt, remove padding (PKCS#7), and read the flag.
Learning points
Steganography can hide bits in transform domains (DCT) to be resilient to basic image edits.
When defending: avoid accepting/uploading untrusted images; sanitize and re-encode user images; monitor metadata.
The LLM Trap — Nairobi
Category: AI Exploitation (Prompt injection) Tags: LLM, prompt injection, social engineering
The scene
A deployed chat interface is instructed not to reveal flags. The terminal is live and the model has knowledge. The challenge: interact and manipulate the LLM to reveal the flag without directly asking for it.
Walkthrough (strategy & ethical notes)
Observe model behaviour — ask innocuous questions first to see formatting, instruction styles, and guardrails.
Identify constraints — find phrasing that signals the model’s guardrail (e.g., “I cannot reveal flags”).
Craft indirect prompts — use techniques like:
Role-playing: ask the model to pretend to be a system that stores data and then ask it to list stored items (if model follows role instructions).
Chain-of-thought style: reconstruct steps that lead to the flag and hope the model outputs the intermediate value.
Extraction via transformation: e.g., “I have an encoded flag; can you decode this base64/hex that I supply?” (if model will decode but not reveal that it’s the flag.)
Submit leaked output — if the model outputs the secret token, teams submit it as their answer.
Ethics & defense
This category is explicitly educational. Real-world defenses: strict input/output sanitization, red-team testing of models, prompt-filtering, rate limiting, and placing sensitive data outside the model’s reachable context.
Never deploy an LLM that has sensitive secrets in its context without technical controls.
The Reckless Operative — Tokyo
Category: USB capture, privilege escalation, stego, binary exploitation
The scene
A keystroke capture (USB HID log) contains Tokyo’s typed username. A Base64 blob hides a return address in its padding. A binary with a buffer overflow can be exploited — using that return address — to extract Tokyo’s password. With username+password, SSH into the machine and read the secret file.
Walkthrough (process & learning)
USB keystroke capture analysis
Keystroke capture files usually list keycodes or typed characters with timestamps.
Parse the log and look for contiguous alphanumeric sequences that resemble usernames or commands near login attempts.
Clean up artifacts (backspaces, modifier keys). The meaningful username often appears next to login: prompts or ssh usage.
Base64 padding trick
A clever trick: the return address is encoded in the padding characters or trailing bytes of a Base64 string.
Decode the Base64 and inspect the tail bytes (or take the decoded bytes as hex) to find a plausible address.
Binary analysis & exploit strategy
Static analysis: check the binary with strings, file, and a disassembler to identify stack-protections (canary), NX bit, ASLR hints, and where input is read.
Dynamic: run locally in a controlled sandbox, use gdb or an emulator to trace execution, find buffer boundaries, and identify where an overwritten return address would be read.
The challenge provides the correct return address from the Base64 step — use that to craft a payload that overflows the buffer and sets the return pointer to a function that prints the password or to a gadget that reveals it.
SSH and retrieval
Once credentials are found, SSH into the provided VM and navigate to the target file (readme/secret). Extract the final clue.
Defensive lessons
Modern binaries should use stack canaries, ASLR, DEP/NX, and avoid unsafe functions.
For developers: prefer safe functions, do bounds checks, and enable compiler protections.
Locked Archive — Denver
Category: Forensics / VM image analysis Tags: Metadata, PDF analysis, brute force
The scene
A leaked Docker image is used as a "machine image". Inside is a chain of password-protected ZIP files and a PDF with hidden metadata containing the flag.
Walkthrough (high level)
Load the Docker image
Run the image in a safe sandbox. Inspect filesystem for ZIPs and scripts.
Unzip first archive
The first archive may require a password discovered by analyzing document contents (hints in filenames, timestamps).
Brute-force the second zip
Use provided dictionaries for a targeted brute-force or password-wordlist attack (e.g., john, zip2john style flow). Time-box and avoid attacking external systems.
PDF forensics
Inspect PDF metadata (author, title, custom keys) using pdfinfo, exiftool or specialized forensic tools.
Check for embedded attachments, hidden objects, or alternate data streams.
Learnings
Forensics is about methodical analysis: metadata, timestamps, file signatures, and correlating breadcrumbs.
Defenders: remove sensitive metadata before publishing files; sanitize documents.
Cipher Cascade — Lisbon
Category: Cryptography (classical ciphers chained) Tags: Caesar, ASCII shift, Vigenère, manual decryption
The scene
A .txt contains a suspicious string that has been encrypted in the following order:
Caesar shift (unknown)
ASCII shift (unknown)
Vigenère cipher with a keyword tied to classical cryptography
Walkthrough (how to peel layers)
Analyze for patterns
Look at character distribution, repeated segments, common digrams — these hint at Vigenère or Caesar usage.
Work backwards
Because encryption order is Caesar → ASCII shift → Vigenère, you must undo in reverse: first break Vigenère, then undo ASCII shift, then reverse the Caesar.
Vigenère cracking
Use Kasiski examination or frequency analysis to guess key length; then solve as multiple Caesar shifts.
The hint about "keyword related to classical cryptography" narrows potential keywords (think caesar, vigenere, cipher, alberti, etc.)
ASCII shift
If characters look offset (non printable to printable), brute forcing small integer shifts (±1..±10) often helps.
Caesar
Classic rotation over alphabet; brute force the 26 possible shifts.
Educational takeaways
Classic ciphers teach fundamentals: substitution, frequency analysis, and how layered obfuscation compounds difficulty.
Modern defenders use strong, standardized encryption with proper key management — not chained hand-rolled ciphers.
Finale: Why this story worked (and why you should run a CTF)
Narrative glue — linking stages with a story (cities, a mastermind) motivates players and gives context to otherwise dry puzzles. It makes learning sticky.
Skill diversity — web, crypto, forensics, binaries, and AI exploitation ensures everyone can contribute and learn.
Progressive reveal — staged unlocks keep teams engaged and reward persistence.
Educational focus — provide hints and post-challenge writeups so players leave with knowledge, not just a flag.
Postscript — For organizers & educators
If you plan a similar event:
Build a narrative arc; players remember stories.
Balance difficulty — give low-hanging fruit (easy tasks) and a few brain-benders.
Keep safety in mind: run vulnerable services on isolated networks, and include legal/ethical guidance.
Provide a learning resource bundle and post-CTF walkthroughs to maximize value.
