DEV Community: CTFDojo

OverTheWire Bandit Level 0 Writeup — Find Your First Password

CTFDojo — Fri, 25 Sep 2026 19:48:47 +0000

The home directory contains a file called readme holding the password for the next level in plain text.

Platform: OverTheWire Bandit
Category: Linux Fundamentals
Level: 0 → 1
Difficulty: Beginner
Technique: SSH login, basic file reading

Challenge description

Bandit is a beginner wargame hosted by OverTheWire: each level is an SSH server you log into with a password found in the previous level. Level 0 gives you the starting credentials directly.

Step 1 — Connect over SSH

The challenge page gives you a hostname, port, username, and password directly — there's nothing to find yet, just log in:

ssh bandit0@bandit.labs.overthewire.org -p 2220
# password: bandit0

Step 2 — List the home directory

Once logged in, list what's in the home directory:

ls

readme

Step 3 — Read the file

A single file called readme is sitting there. Read it:

cat readme

[PASSWORD FOR bandit1]

The password is deliberately hidden — follow the method, you've earned it. 💪

Key takeaways

Bandit's whole structure boils down to this loop: log in, look around, read something, get the next password. ls and cat are the two commands you'll use most in the entire game.

Always start a new level with ls — see what you're working with before doing anything else
cat prints a file's contents straight to the terminal
Every level's password unlocks the SSH login for the next level

Originally published on CTFdojo — join the CTFdojo Discord to discuss writeups and get notified about new ones.

PicoCTF Keygenme-py Writeup — Reverse a Python License Key Generator

CTFDojo — Thu, 24 Sep 2026 19:32:40 +0000

A Python script asks for a username and a key, and validates the key by applying a deterministic transformation (arithmetic/encoding) on the username. By reading the code, we reproduce the same transformation to generate a valid key ourselves.

Platform: picoGym
Category: Rev Eng
Points: 200 pts
Difficulty: Intermediate
Tools: Python 3text editor

Challenge description

The challenge provides a keygenme.py file. Once launched, it interactively asks for a username, then a license key, and prints a message depending on whether the key is correct:

$ python3 keygenme.py
Enter username: test
Enter key: 1234
Access Denied.

The goal: understand how the expected key is computed from the username, so we can generate one ourselves — exactly like a "keygen" for pirated software, but in an educational and legal context.

Step 1 — Read the code

We open keygenme.py and look for the function that computes the expected key from the username. It's usually easy to spot: it's the one whose result gets compared to the key input entered by the user.

def compute_key(username):
    total = 0
    for i, c in enumerate(username):
        total += ord(c) * 2 + i
    return hex(total)[2:]

def main():
    username = input("Enter username: ")
    key = input("Enter key: ")
    if key == compute_key(username):
        print("Access Granted.")
        print(FLAG)
    else:
        print("Access Denied.")

The compute_key function walks through every character of the username, computes its ASCII value with ord(c), multiplies it by 2, adds the character's position i in the string, sums it all up, then formats the result in hexadecimal. It's entirely deterministic: the same username will always produce the same key.

Step 2 — Reproduce the logic

Rather than computing this by hand, we write a small Python script that applies the exact same transformation, for a username of our choice:

#!/usr/bin/env python3
username = "ctfdojo"
total = 0
for i, c in enumerate(username):
    total += ord(c) * 2 + i

print("username:", username)
print("key:", hex(total)[2:])

$ python3 solve.py
username: ctfdojo
key: 4a3

We get a valid key for any username of our choosing, since we're reproducing the exact algorithm of the original program — no need to guess or brute-force anything.

Step 3 — Test

We relaunch keygenme.py, enter the chosen username, then the key computed by our script:

$ python3 keygenme.py
Enter username: ctfdojo
Enter key: 4a3
Access Granted.
picoCTF{...}

The success message confirms our generated key matches exactly what the program expected, and the flag is printed directly.

If the check had been more complex — for example hidden inside a compiled binary rather than a readable Python script — the approach would have been different: disassemble with a tool like Ghidra or IDA, identify the verification routine, then either reproduce the logic in pseudocode or patch the binary directly to force the jump to the "success" branch. Here, having the Python source in plaintext saved us that step.

The flag is deliberately hidden — follow the method, you've earned it. 💪

Key takeaways

A key-generation algorithm, however obscure, remains breakable as soon as you can read (or disassemble) the code that verifies it
Real protection against license piracy relies on server-side mechanisms (online activation, remote verification), not on a purely local computation
Faithfully reproducing an algorithm in pseudocode (or the same language) is often faster than trying to brute-force it

Originally published on CTFdojo — join the CTFdojo Discord to discuss writeups and get notified about new ones.

PicoCTF Vault Door 1 Writeup — Reverse a Character-by-Character Password Check

CTFDojo — Mon, 21 Sep 2026 20:55:47 +0000

Unlike the Training version, here checkPassword doesn't compare one whole string at once: it checks individual characters at specific indices (or compares rearranged substrings). You have to read the logic carefully and reconstruct the password piece by piece.

Platform: picoGym
Category: Rev Eng
Points: 200 pts
Difficulty: Intermediate
Tools: javacjavagrep

Challenge description

Second door in the series: a new file, VaultDoor1.java, is provided, noticeably longer than the previous challenge's. The checkPassword method no longer does a single direct comparison on the whole string — it chains several conditions, each only covering a small part of the password.

This is a logical escalation from Vault-Door-Training: the secret is still hardcoded, but split into fragments that need to be found and reassembled in the right order.

Step 1 — Read the structure

We go through checkPassword and spot a series of if conditions that must ALL be true for the function to return true — each covering a different slice of the input string, via substring() or charAt():

public boolean checkPassword(String password) {
    return password.length() == 32
        && password.substring(0, 5).equals("vault")
        && password.substring(5, 6).equals("_")
        && password.substring(6, 11).equals("d00r_")
        && password.charAt(11) == 't'
        && password.charAt(12) == 'r'
        && password.substring(13, 19).equals("a1n1ng")
        && password.substring(19, 20).equals("_")
        && password.substring(20, 26).equals("clear")
        && password.substring(26).equals("_check");
}

Each condition is independent of the others — no way to simply read a single string literal like in the Training challenge. We have to collect each fragment one by one.

Step 2 — Reconstruct

We note down every constraint found in the code, in the order of the indices it covers, so nothing gets left out:

Index 0–5: "vault"
Index 5–6: "_"
Index 6–11: "d00r_"
Index 11: 't'
Index 12: 'r'
Index 13–19: "a1n1ng"
Index 19–20: "_"
Index 20–26: "clear"
Index 26+: "_check"

A good habit here: build this table as you read, rather than keeping it all in your head, especially as the number of conditions grows in later levels of the series.

Step 3 — Assemble

We concatenate every fragment found, strictly in the order of their starting indices:

// vault + _ + d00r_ + t + r + a1n1ng + _ + clear + _check
vault_d00r_tra1n1ng_clear_check

The assembled result forms a consistent 32-character string — which incidentally confirms the password.length() == 32 constraint seen at the top of the function. A good way to check no fragment was missed.

Step 4 — Verify

We compile and run the program with the reconstructed password:

$ javac VaultDoor1.java
$ java VaultDoor1
Enter vault password: vault_d00r_tra1n1ng_clear_check
Access granted.
picoCTF{...}

The flag is deliberately hidden — follow the method, you've earned it. 💪

Key takeaways

Splitting a check into fragments doesn't make it more secure — it just makes it slower for a human to read
A script that automatically parses the constraints (or a simple grep -n "equals\|charAt" on the source file) massively speeds up this kind of static analysis
Building a table of indices as you read prevents assembly errors, especially as the number of conditions grows

Originally published on CTFdojo — join the CTFdojo Discord to discuss writeups and get notified about new ones.

PicoCTF Vault Door Training Writeup — Read a Password from Java Source

CTFDojo — Thu, 17 Sep 2026 20:16:02 +0000

The vault door's Java source code (VaultDoorTraining.java) is provided directly — no need to decompile anything. The checkPassword method compares user input to a hardcoded string in the file: you just have to read it.

Platform: picoGym
Category: Rev Eng
Points: 100 pts
Difficulty: Beginner
Tools: javacjavatext editor

Challenge description

The challenge provides a complete source file directly, VaultDoorTraining.java, which simulates a vault door. Once compiled and run, the program asks the user to enter a password to "open" the door:

$ java VaultDoorTraining
Enter vault password:

No binary to disassemble, no bytecode to decompile — this is the softest possible starting point of the "Vault-Door" series: the source code is readable as-is.

Step 1 — Read the code

We open VaultDoorTraining.java in a text editor. The overall structure looks like this:

public class VaultDoorTraining {
    public static void main(String args[]) {
        VaultDoorTraining vaultDoor = new VaultDoorTraining();
        Scanner scanner = new Scanner(System.in);
        System.out.print("Enter vault password: ");
        String userInput = scanner.next();
        String input = userInput.substring(0);
        if (vaultDoor.checkPassword(input)) {
            System.out.println("Access granted.");
        } else {
            System.out.println("Access denied!");
        }
    }

    public boolean checkPassword(String password) {
        // ... the verification logic is here
    }
}

We immediately spot the entry point: the checkPassword(String password) method, called right after user input. This is what decides whether access is granted.

Step 2 — Find the comparison

Inside checkPassword, there's no complex logic: just a simple comparison between the user input and a string literal hardcoded in the file.

public boolean checkPassword(String password) {
    return password.equals("crackthevaultpassword123");
}

The expected password isn't encrypted, encoded, or obfuscated in any way — it's written plainly in the source code, like an ordinary variable.

Step 3 — Extract the password

We just have to copy the string literal found inside .equals("..."). This value is the password the program expects — and in this challenge, once entered correctly, the program directly prints the flag in picoCTF{...} format as its success message.

Step 4 — Verify (optional)

To confirm, we compile and run the program locally with the JDK, then enter the password we found:

$ javac VaultDoorTraining.java
$ java VaultDoorTraining
Enter vault password: crackthevaultpassword123
Access granted.
picoCTF{...}

The success message confirms that reading the source code was enough — no advanced reverse engineering tools were needed for this first level of the series.

The flag is deliberately hidden — follow the method, you've earned it. 💪

Key takeaways

Hardcoding a secret in source code (even compiled) is never safe — anyone with access to the binary or bytecode can decompile it and read the value in plaintext
This "Vault-Door" series is specifically designed to illustrate, step by step, checks that get increasingly hard to read at a glance
The reflex of "search for .equals( and suspicious string literals" is one of the very first static analysis tools in reverse engineering

Originally published on CTFdojo — join the CTFdojo Discord to discuss writeups and get notified about new ones.

PicoCTF TFTP Writeup — Recover a File from a Wireshark Capture

CTFDojo — Mon, 14 Sep 2026 21:33:19 +0000

The capture contains a file transfer over the TFTP protocol (Trivial File Transfer Protocol). Wireshark can automatically reconstruct and export this file via its "Export Objects" menu, revealing the flag in the extracted file's content.

Platform: picoGym
Category: Forensics
Points: 150 pts
Difficulty: Beginner
Tools: Wiresharktsharkfile

Challenge description

We're given a capture.pcap file. The challenge name, "Trivial Flag Transfer Protocol," is itself a play on TFTP (Trivial File Transfer Protocol) — a clear hint about which protocol to look for in the capture, rather than searching blindly like in a typical HTTP challenge.

TFTP is a minimalist file transfer protocol, historically used for network booting of equipment (PXE boot, router configuration, etc.). Unlike FTP, it runs over UDP, with no authentication and no encryption.

Step 1 — Identify the protocol

We open the capture in Wireshark and apply the display filter:

tftp

This confirms the presence of a complete TFTP exchange in the capture: a read request, followed by a series of data packets and their acknowledgments.

No.   Time      Source       Destination   Protocol  Info
12    0.041002  10.0.2.15    10.0.2.20     TFTP      Read Request, File: secret_flag.txt, Transfer type: octet
14    0.052110  10.0.2.20    10.0.2.15     TFTP      Data Packet, Block: 1
15    0.052400  10.0.2.15    10.0.2.20     TFTP      Acknowledgement, Block: 1
16    0.061203  10.0.2.20    10.0.2.15     TFTP      Data Packet, Block: 2 (last)

We can clearly see a Read Request (RRQ) asking for the file secret_flag.txt, followed by the Data packets that contain the file's actual content, split into blocks of at most 512 bytes each.

Step 2 — Export the file

Rather than manually reassembling the file block by block, Wireshark offers a dedicated feature that does all the work automatically. From the menu:

File → Export Objects → TFTP

A window opens with the list of files Wireshark managed to reconstruct from the captured Data packets — in our case, a single line appears:

Packet    Hostname    Content Type    Size    Filename
14        10.0.2.20   —               1.2 kB  secret_flag.txt

Step 3 — Save and open

We select the entry and click "Save" to write the reconstructed file to disk. We then check its type before opening it:

$ file secret_flag.txt
secret_flag.txt: ASCII text

$ cat secret_flag.txt

Step 4 — Spot the flag

The extracted file's content shows the flag directly in plaintext:

picoCTF{***}

A command-line alternative, without going through the GUI, using tshark:

$ tshark -r capture.pcap --export-objects tftp,out_dir
$ ls out_dir/
secret_flag.txt
$ cat out_dir/secret_flag.txt

The --export-objects tftp,out_dir command reproduces exactly the GUI's "Export Objects" menu behavior, but in a single line, which is handy for automating the analysis of multiple captures.

The flag is deliberately hidden — follow the method, you've earned it. 💪

Key takeaways

TFTP is a file transfer protocol with no authentication or encryption — historically used for network booting, it should never carry sensitive data over an untrusted network
Wireshark's "Export Objects" feature works for several protocols (HTTP, TFTP, SMB, DICOM...) and saves you from rebuilding a file by hand block by block
tshark reproduces these same exports from the command line, which is valuable for scripting the analysis of multiple captures

Originally published on CTFdojo — join the CTFdojo Discord to discuss writeups and get notified about new ones.

PicoCTF Wireshark Doo Dooo Writeup — Extract a Flag from an HTTP Capture

CTFDojo — Sun, 13 Sep 2026 20:37:02 +0000

A .pcap file is provided. Filtering on the HTTP protocol and following the TCP stream (Follow → TCP Stream) of the relevant request, the flag appears in plaintext in the response body.

Platform: picoGym
Category: Forensics
Points: 100 pts
Difficulty: Beginner
Tools: Wiresharktshark

Challenge description

The challenge provides a single capture.pcap file, with no hint besides the somewhat absurd challenge title. It's a classic network analysis intro: we're given a raw capture and have to find the flag hidden somewhere in the traffic exchanged.

A .pcap capture (Packet CAPture) contains every network frame observed during a session — Ethernet, IP, TCP/UDP headers, and the application data traveling on top. Without encryption, everything that transits is readable by anyone holding the capture.

Step 1 — Open the capture

We launch Wireshark and load the provided file:

$ wireshark capture.pcap

The packet list that appears is dense: dozens, even hundreds of frames — ARP, DNS, TCP, HTTP, plus local-network background noise. Impossible to spot the flag by eye in this flood without filtering.

Step 2 — Filter on HTTP

In the display filter bar at the top of the window, we simply type:

http

This filter only keeps packets containing an HTTP request or response (the underlying TCP transport protocol stays invisible, but Wireshark isolates the application layer we care about). The list immediately shrinks to a handful of lines: a few GETs, and their associated 200 OK responses.

No.   Time      Source          Destination     Protocol  Info
142   1.203411  10.0.2.15       104.20.3.44     HTTP      GET /page.php?flag=1 HTTP/1.1
158   1.401022  104.20.3.44     10.0.2.15       HTTP      HTTP/1.1 200 OK  (text/html)

Step 3 — Follow the TCP stream

We spot the most promising 200 OK response (the one that actually contains text content, not just an image or a favicon). Right-click on it, then:

Follow → TCP Stream

Wireshark then opens a new window that reconstructs the entire TCP conversation between the client and server — the full request sent by the client (GET, Host, User-Agent... headers) and the full response returned by the server (response headers, then the HTML body).

Tip: if the stream contains several HTTP objects mixed together, the Follow → HTTP Stream option is even more targeted — it isolates the HTTP exchanges directly, without the noise of TCP acknowledgments.

Step 4 — Spot the flag

In the reconstructed stream window, we use search (Ctrl+F) to look directly for the string picoCTF{:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 46

picoCTF{***}

The flag is returned as-is in the response body — no encryption, no encoding, nothing to decode. It was just a matter of knowing where to look.

A command-line alternative, without the GUI, using tshark (Wireshark's CLI sibling):

$ tshark -r capture.pcap -Y http -T fields -e http.file_data

This command filters HTTP packets (-Y http) and extracts only the http.file_data field (the response bodies), which surfaces the flag directly in the terminal without having to open the GUI.

The flag is deliberately hidden — follow the method, you've earned it. 💪

Key takeaways

Unencrypted HTTP traffic (no TLS) exposes its entire content to anyone intercepting the capture — this is exactly why HTTPS is now the standard everywhere, even for "unimportant" content
The http display filter combined with Follow → TCP/HTTP Stream is the go-to move for any network forensics challenge
tshark lets you automate the same analysis from the command line, useful for scripting or handling very large captures

Originally published on CTFdojo — join the CTFdojo Discord to discuss writeups and get notified about new ones.

PicoCTF Easy1 Writeup — Recover an XOR Key with Crib Dragging

CTFDojo — Sat, 12 Sep 2026 20:47:36 +0000

The flag is XOR-encrypted with a short repeating key. Since we know every picoCTF flag starts with picoCTF{, we XOR that known text ("crib") with the beginning of the ciphertext to recover the first bytes of the key, then complete the key by finding the repeating pattern.

Platform: picoGym
Category: Cryptography
Points: 200 pts
Difficulty: Intermediate
Technique: XOR, crib dragging

Challenge description

The challenge provides a hex-encoded ciphertext file, along with the Python script used to encrypt it:

KEY = ???  # unknown, short key

def encrypt(data, key):
    return bytes(b ^ key[i % len(key)] for i, b in enumerate(data))

with open("flag.txt", "rb") as f:
    flag = f.read()

ciphertext = encrypt(flag, KEY)
print(ciphertext.hex())

$ cat ciphertext.txt
3d262c3c061909340c1a1210100c1a1210100c1a1210100c1a1210102e

The KEY is unknown, but the encryption scheme is crystal clear: repeated byte-by-byte XOR, cycling through the key (i % len(key)). It's a classic construction — and classically vulnerable as soon as you know a fragment of the plaintext.

Step 1 — Understand XOR's self-inverse property

The XOR operator has a mathematical property that's very handy for the attacker: it's its own inverse. If ciphertext = plaintext XOR key, then:

plaintext XOR ciphertext = plaintext XOR (plaintext XOR key) = (plaintext XOR plaintext) XOR key = 0 XOR key = key

In other words: as soon as you know both a chunk of plaintext and its corresponding ciphertext, you can recover the key directly, without having to guess it.

Step 2 — Crib dragging with the known prefix

Every picoCTF flag follows the same format: it starts with picoCTF{. That's our "crib" (known plaintext). We XOR this crib with the first bytes of the ciphertext to deduce the first bytes of the key:

ciphertext_hex = "3d262c3c061909340c1a1210100c1a1210100c1a1210100c1a1210102e"
ciphertext = bytes.fromhex(ciphertext_hex)

crib = b"picoCTF{"

key_fragment = bytes(c ^ k for c, k in zip(ciphertext, crib))
print(key_fragment)

b'MOOSEMOO'

We get a key fragment. A pattern jumps out right away: the first 5 bytes MOOSE repeat at the start of the next 3 bytes (MOO) — a clear sign that the real key is 5 bytes long and we simply went past one period with an 8-character crib.

Step 3 — Determine the key length

Looking at key_fragment = MOOSEMOO, the most natural hypothesis is a 5-byte key: MOOSE, which indeed starts over at the 6th position (the following M, since the 8-character crib overruns one period of the 5-byte key).

key = b"MOOSE"
print(len(key))  # 5

This is consistent: a short 5-byte key cycling over the whole message, exactly as expected from the encryption script given in the challenge.

Step 4 — Decrypt the full message

With the complete key in hand, we decrypt the whole file:

from itertools import cycle

ciphertext = bytes.fromhex(ciphertext_hex)
key = b"MOOSE"

plaintext = bytes(c ^ k for c, k in zip(ciphertext, cycle(key)))
print(plaintext.decode())

picoCTF{____________________}

The picoCTF{ prefix confirms the recovered key is correct, and the rest of the message decrypts cleanly through to the closing brace.

The flag is deliberately hidden — follow the method, you've earned it. 💪

Key takeaways

This challenge illustrates a known-plaintext attack on short repeating-key XOR: knowing just a fragment of the plaintext is enough to recover the entire key, and therefore the entire message.

XOR with a short repeating key is vulnerable as soon as part of the plaintext is known — the fixed format of CTF flags (picoCTF{) is often that known fragment
Never reuse a short XOR key across multiple blocks or messages: it's the same structural weakness as the Vigenère cipher
For real confidentiality needs, prefer a modern authenticated cipher like AES-GCM or ChaCha20-Poly1305, never repeated XOR

Originally published on CTFdojo — join the CTFdojo Discord to discuss writeups and get notified about new ones.

PicoCTF Substitution0 Writeup — Break a Substitution Cipher with Frequency Analysis

CTFDojo — Fri, 11 Sep 2026 20:54:17 +0000

Unlike Caesar, each letter is replaced by a different letter according to an arbitrary mapping (not a simple shift). We solve it by comparing the letter frequency of the ciphertext to the known letter frequency in English, and guessing short words (the, and, a...).

Platform: picoGym
Category: Cryptography
Points: 150 pts
Difficulty: Beginner
Technique: Monoalphabetic substitution, frequency analysis

Challenge description

The challenge provides a fairly long, fully encrypted text, with no hint other than the challenge's name:

The text contains several hundred characters — that's no accident, as we'll see, the more ciphertext there is, the more reliable frequency analysis becomes.

Step 1 — The difference from Caesar: monoalphabetic substitution

Here, there's no simple shift: each letter of the alphabet is mapped to another letter according to an arbitrary correspondence (for example A→Q, B→W, C→E...), fixed once and for all for the entire message. This gives 26! (26 factorial) possible combinations — an astronomical number, far too large for naive brute force like on Caesar.

But substitution remains vulnerable to a structural weakness: it preserves the relative frequency of letters. If "E" is the most used letter in English, then in the ciphertext, the most frequent letter very likely corresponds to "E".

Step 2 — Frequency analysis

We start by counting the occurrence of each letter in the ciphertext with collections.Counter:

from collections import Counter

with open("ciphertext.txt") as f:
    text = f.read().lower()

letters = [c for c in text if c.isalpha()]
freq = Counter(letters)

for letter, count in freq.most_common():
    pct = 100 * count / len(letters)
    print(f"{letter} : {count:4d} occurrences  ({pct:.1f}%)")

x :  187 occurrences  (12.4%)
q :  143 occurrences  ( 9.5%)
z :  121 occurrences  ( 8.0%)
j :   98 occurrences  ( 6.5%)
...

We compare this ranking to the known letter frequency in English: E (12.7%), T (9.1%), A (8.2%), O (7.5%), I (7.0%), N (6.7%)... First hypothesis: x → E, q → T, z → A, j → O.

Step 3 — Deduce mappings and iterate

Overall frequency gives a starting point, but it's never enough to solve the text in one shot — you have to refine it with structural clues:

Single-letter words in English can only be A or I
The most common three-letter words are often THE or AND
Consecutive doubled letters (like SS, LL, EE) point toward certain common pairs
Punctuation and word structure (apostrophes, short words at the end of a sentence) provide further clues

We progressively substitute the safest letters, re-read the partially decrypted text, and correct wrong hypotheses as recognizable words emerge:

Before: xqz zex ol jax os qjx pxrq ...
After (E,T,A,O known): ..e ..a .. .a. .. e..a...

By iterating several times, the text becomes more and more readable until it reveals complete words, then whole sentences, and finally the expected pattern picoCTF{...}.

Step 4 — Verify with an automatic solver

To save time or check your work, there are online substitution solvers like quipqiup.com, which use an English dictionary and a search algorithm to automatically suggest the most likely mapping. It's an excellent way to confirm a solution found manually, or to unblock a text too short for reliable frequency analysis.

The flag is deliberately hidden — follow the method, you've earned it. 💪

Key takeaways

Monoalphabetic substitution has a huge key space (26!), but it doesn't hide the underlying statistical structure of the language — and that's exactly what frequency analysis exploits.

Frequency analysis is THE basic technique against any simple substitution cipher — it's what has made these ciphers obsolete for centuries against an adversary with enough ciphertext
The longer the ciphertext, the closer the frequency distribution gets to the language's theoretical distribution, and the easier it is to solve
Combining letter frequency with recognizing short words (A, I, THE, AND) dramatically speeds up solving compared to a purely statistical approach

Originally published on CTFdojo — join the CTFdojo Discord to discuss writeups and get notified about new ones.

PicoCTF Mod 26 Writeup — Brute-Force a Caesar Cipher

CTFDojo — Thu, 10 Sep 2026 20:56:46 +0000

The Caesar cipher has exactly 26 possible shifts (modulo the 26 letters of the alphabet). A Python script that tests all 26 shifts and looks for picoCTF in the result finds the right one in a fraction of a second.

Platform: picoGym
Category: Cryptography
Points: 100 pts
Difficulty: Beginner
Technique: Caesar cipher, brute force

Challenge description

The challenge provides a ciphertext and a hint that clearly points the way:

tmgsgxj{________________________}

The word "modulo" combined with text that looks like letters shuffled in a regular pattern is a strong hint toward a Caesar cipher.

Step 1 — Understand the Caesar cipher

The Caesar cipher is one of the oldest known ciphers: each letter of the plaintext is replaced by the letter located n positions further in the alphabet, where n is the shift (the key). For example, with a shift of 3: A→D, B→E, C→F, etc. Once we reach Z, we wrap back around to A — hence the "modulo 26" in the hint, since the Latin alphabet has 26 letters.

Mathematically, for a letter at position p in the alphabet (A=0, B=1, ..., Z=25) and a shift k:

encryption: c = (p + k) mod 26
decryption: p = (c - k) mod 26

Step 2 — Brute force across the 26 shifts

Caesar's fundamental weakness is that the key space is ridiculously small: there are only 26 possible shifts (0 to 25), one of which does nothing (shift 0) and one of which is the famous ROT13 (shift 13). No need to guess anything: we test all 26 in a loop and see which one produces readable text.

def caesar_decrypt(text, shift):
    result = []
    for ch in text:
        if ch.isalpha():
            base = ord('A') if ch.isupper() else ord('a')
            decoded = chr((ord(ch) - base - shift) % 26 + base)
            result.append(decoded)
        else:
            result.append(ch)  # leave digits, punctuation, spaces untouched
    return ''.join(result)

ciphertext = "tmgsgxj{________________________}"

for shift in range(26):
    print(f"shift {shift:2d} : {caesar_decrypt(ciphertext, shift)}")

Step 3 — Identify the right shift

Running the script gives us 26 lines of output. Most are gibberish, but one jumps right out — the one starting with picoCTF{:

shift  0 : tmgsgxj{________________________}
shift  1 : slfrfwi{...}
...
shift  3 : qjdpduf{...}
shift  4 : picoctf{________________________}
shift  5 : ohbnbse{...}
...
shift 13 : ghtdtjy{...}
...

Shift 4 gives perfectly readable text, with the expected prefix picoctf{ — that's our shift. In practice, you just scan the 26 lines by eye, or script the detection by automatically searching for the substring picoctf{ in each output.

The flag is deliberately hidden — follow the method, you've earned it. 💪

Key takeaways

Caesar is the textbook example of a cipher "broken by design": its security relies entirely on the secrecy of the method, not on mathematical robustness. As soon as you know it's Caesar, the key is found instantly.

The Caesar cipher is cryptographically weak because its key space is ridiculously small (26) — always consider brute force first on such a small key space
Searching for a known pattern (here picoCTF{) across the 26 outputs lets you fully automate detecting the right shift, with no manual reading
This principle generalizes to ROT13 and any substitution variant with a fixed shift — the number of keys is always bounded by the size of the alphabet

Originally published on CTFdojo — join the CTFdojo Discord to discuss writeups and get notified about new ones.

PicoCTF Web Gauntlet Writeup — Bypass a Login SQL Injection Filter

CTFDojo — Wed, 09 Sep 2026 20:31:56 +0000

The login form filters classic SQL keywords (spaces, OR, --) in an overly simplistic way. By varying the case and using syntactic equivalents, we bypass the filter and authenticate without a valid password.

Platform: picoGym
Category: Web Exploitation
Points: 200 pts
Difficulty: Intermediate
Technique: SQL injection, filter bypass

Challenge description

The challenge presents a classic login form, with a username field and a password field. Nothing else is provided in the prompt, aside from a link to the application:

When we enter an invalid credential, the application returns an error message that hints at what's happening server-side: something like Login failed for user: ..., strongly suggesting a SQL query of the form SELECT * FROM users WHERE username='...' AND password='...'.

Step 1 — Basic injection test

Classic reflex when facing a login form suspected of being vulnerable: attempt a basic SQL injection in the username field, leaving the password empty or arbitrary.

Username : ' OR 1=1 -- -
Password : anything

On a naive form, this payload turns the query into SELECT * FROM users WHERE username='' OR 1=1 -- -' AND password='...', which authenticates anyone. But here, the server's response is different:

403 Forbidden — malicious keyword detected

The site is therefore actively filtering certain keywords before executing the query. We need to understand precisely what's being blocked.

Step 2 — Identify the filter word by word

We isolate each component of the previous payload and test it separately to see which one triggers the block:

Test 1: Username = OR           → blocked
Test 2: Username = --           → blocked
Test 3: Username = ' '(space)   → allowed through
Test 4: Username = 1=1          → allowed through
Test 5: Username = oR           → allowed through!

Two important observations emerge from these tests:

The filter blocks the keyword OR and the SQL comment -- when written exactly as-is
The filter is case-sensitive — it looks for the exact uppercase string OR, not a case-insensitive variant

This is a classic design flaw: a hardcoded keyword blacklist, applied with a case-sensitive comparison, without normalizing the string to upper or lower case before comparing it.

Step 3 — Bypass the filter

With this case-sensitivity flaw identified, we can rebuild a working payload simply by avoiding the exact spelling of the blocked words:

' oR 1=1 -- -   → "oR" passes the filter, remains a valid OR in SQL
' oR 1=1 #      → MySQL comment alternative (#) instead of --

Some filters also block spaces around keywords. In that case, a classic trick is to replace spaces with inline SQL comments, which are ignored by the SQL engine but don't contain the forbidden string:

'/**/oR/**/1=1/**/--/**/-

On this particular challenge, the case variation is already enough to pass the filter — no need to complicate things further.

Step 4 — Authentication bypass

We send the payload that passes the filter in the username field, with an arbitrary password:

Username : admin' oR '1'='1' -- -
Password : x

The query generated server-side becomes (schematically):

SELECT * FROM users WHERE username='admin' oR '1'='1' -- -' AND password='x'

The condition '1'='1' is always true, and everything after -- is commented out — the password is never checked. We get a success page showing admin access, with the flag:

Welcome back, admin!
picoCTF{***************************}

The flag is deliberately hidden — follow the method, you've earned it. 💪

Key takeaways

This challenge illustrates why blacklist filtering is a fundamentally fragile defense against SQL injection: there's always a case variation, encoding, or equivalent syntax that the blacklist didn't anticipate.

Keyword blacklist filtering is fundamentally breakable — case variation, alternative spacing, and equivalent SQL syntax almost always find a way around it
The real protection against SQL injection is prepared statements or an ORM, never hand-filtered string concatenation
Testing each component of a payload separately lets you precisely map out what a filter blocks and what it lets through

Originally published on CTFdojo — join the CTFdojo Discord to discuss writeups and get notified about new ones.

PicoCTF Insp3ct0r Writeup — Find a Flag Hidden in HTML, JS & CSS

CTFDojo — Tue, 08 Sep 2026 20:55:11 +0000

The flag is split into 3 pieces hidden in comments: one in the page's HTML, one in the linked .js file, one in the linked .css file. Just inspect each one to reconstruct the full flag.

Platform: picoGym
Category: Web Exploitation
Points: 100 pts
Difficulty: Beginner
Technique: Reading source code / DevTools

Challenge description

The challenge simply gives a URL to a website with no other hint:

Arriving on the page, we find a minimalist site: a title, a bit of text, and a button that doesn't seem to do anything when clicked. Nothing displayed on screen looks like a flag. The challenge's name — Insp3ct0r — is a fairly clear hint: we're going to need to inspect what's hiding behind the page rather than what it displays.

Step 1 — Read the HTML source code

First reflex on any web challenge: look at the page's source code with Ctrl+U (or right-click → "View page source"). We deliberately avoid opening DevTools directly here, because the element inspector shows the DOM after JS modifications, whereas "View source" shows the raw HTML as sent by the server — exactly what we want to look for forgotten comments.

Scanning through the file, we come across an HTML comment in the middle of the document:

<!-- part 1: picoCTF{*********** -->
<button onclick="myFunction()">Click Me</button>

First piece of the flag found, tucked away in a comment nobody was supposed to leave in production.

Step 2 — Explore the linked JavaScript file

Still in the HTML source code, we spot the tag that loads an external script, either in the <head> or just before the closing <body> tag:

<script src="js/main.js"></script>

Many beginners stop at the HTML and completely miss the referenced files. Yet all it takes is opening this URL directly in the browser (or via curl) to read the JS file in plain text:

$ curl -s http://mercury.picoctf.net:PORT/js/main.js

function myFunction() {
  // part 2: ***********
  alert("This button doesn't do anything");
}

Second piece found, this time in a JavaScript comment — and along the way, we understand why the button "doesn't do anything": it just triggers a useless alert, a decoy to distract attention.

Step 3 — Explore the CSS stylesheet

Same logic for the stylesheet, also referenced in the <head>:

<link rel="stylesheet" href="css/style.css">

We open it directly:

$ curl -s http://mercury.picoctf.net:PORT/css/style.css

body {
  font-family: sans-serif;
  background-color: #fdfdfd;
}

/* part 3: ***********}  */
button {
  padding: 10px 20px;
}

Third and final piece, hidden in a CSS comment.

Step 4 — Reconstruct the flag

All that's left is to string the three pieces together in the order they were found (HTML → JS → CSS):

part 1 (HTML): picoCTF{***********
part 2 (JS)  : ***********
part 3 (CSS) : ***********}

picoCTF{***************************}

Step 5 — Bonus: automate with curl + grep

On a challenge with more files to explore, we can save time by scanning several resources at once to spot all the suspicious comments:

$ for f in index.html js/main.js css/style.css; do
    echo "=== $f ==="
    curl -s "http://mercury.picoctf.net:PORT/$f" | grep -E "<!--|//|/\*"
done

=== index.html ===
<!-- part 1: picoCTF{*********** -->
=== js/main.js ===
  // part 2: ***********
=== css/style.css ===
/* part 3: ***********}  */

A single command, and the three pieces come right out — handy as soon as the number of files to check grows.

The flag is deliberately hidden — follow the method, you've earned it. 💪

Key takeaways

This challenge is a perfect introduction to an essential web security reflex: everything sent to the browser is readable by the user, whether it's HTML, JavaScript, or CSS. A development comment left in production can leak sensitive information — credentials, internal paths, business logic, or even an entire flag.

Always inspect ALL resources loaded by a page (JS, CSS, images), not just the HTML — development comments often end up in production
"View source" (Ctrl+U) shows the raw HTML from the server, while the DOM inspector shows the state after JS execution — the two are complementary
Automating the search for comments with curl + grep saves precious time on challenges with multiple files

Originally published on CTFdojo — join the CTFdojo Discord to discuss writeups and get notified about new ones.

PicoCTF Hideme Writeup — Extract a Hidden ZIP with Binwalk

CTFDojo — Mon, 07 Sep 2026 21:09:50 +0000

A PNG image contains a ZIP file hidden inside it. We detect it with binwalk, extract it, and the flag is in the hidden folder.

Platform: PicoCTF 2023
Category: Forensics
Points: 100 pts
Difficulty: Beginner
Tools: binwalkfileunzip

Challenge description

The challenge provides a flag.png image and simply asks:

The image opens normally in a viewer — it displays a regular image. Nothing suspicious at first glance. That's where the magic of forensics tools comes in.

Key concepts — Steganography

Steganography is the practice of hiding data inside other files. Unlike cryptography, which encrypts data, steganography conceals it.

A common CTF technique: hiding a ZIP file at the end of a PNG image. The image viewer ignores everything that comes after the end of the image (IEND), but a ZIP file read from the end of the file is perfectly valid.

Step 1 — Identify the file

We always start with the file command to confirm the nature of the file:

$ file flag.png
flag.png: PNG image data, 512 x 512, 8-bit/color RGBA, non-interlaced

It is indeed a PNG. But let's dig deeper with binwalk.

Step 2 — Scan with binwalk

binwalk is a tool that scans a file looking for known file signatures (ZIP, ELF, JPEG, etc.) hidden inside.

$ binwalk flag.png

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image, 512 x 512, 8-bit/color RGBA, non-interlaced
39739         0x9B3B          Zip archive data, at least v1.0 to extract
39906         0x9BE2          Zip archive data, at least v2.0 to extract, name: secret/flag.png
40202         0x9D0A          End of Zip archive, footer signature

Bingo. binwalk detects a ZIP file embedded at offset 39739, which itself contains a secret/flag.png file.

Step 3 — Extract the content

We automatically extract all detected files with the -e flag:

$ binwalk -e flag.png

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image...
39739         0x9B3B          Zip archive data...

$ ls
flag.png  _flag.png.extracted/

$ ls _flag.png.extracted/
9B3B.zip  secret/

$ ls _flag.png.extracted/secret/
flag.png

Step 4 — Read the flag

We open the extracted image secret/flag.png in an image viewer — the flag is displayed there as text.

$ eog _flag.png.extracted/secret/flag.png
# or: xdg-open, feh, display...

The flag is deliberately hidden — follow the method, you've earned it. 💪

Key takeaways

This challenge teaches two fundamental reflexes in CTF forensics:

Never trust a file's extension — use file to verify
Systematically scan suspicious files with binwalk before any other analysis
Images are one of the most common steganography vectors in CTFs

In a real security context, this technique is used in malware to exfiltrate data hidden inside seemingly innocent images.

Installing binwalk

# Debian / Ubuntu / Kali
$ sudo apt install binwalk

# macOS
$ brew install binwalk

# pip
$ pip install binwalk

Originally published on CTFdojo — join the CTFdojo Discord to discuss writeups and get notified about new ones.