DEV Community: CTFDojo

OverTheWire Bandit Level 9 Writeup — Extract Readable Text from a Mostly-Binary File

CTFDojo — Sun, 01 Nov 2026 22:41:40 +0000

data.txt is mostly binary data, but the password is one of the few human-readable strings inside it, preceded by several = characters — strings pulls out the readable text, and grep narrows to the marked line.

Platform: OverTheWire Bandit
Category: Linux Fundamentals
Level: 9 → 10
Difficulty: Beginner
Technique: strings + grep for a marker pattern

Challenge description

This file looks like garbage when opened directly — mostly non-printable binary bytes. Somewhere inside it, a handful of human-readable strings survive, and the level says the password is one of them, marked by leading equals signs.

"Level Goal: The password for the next level is stored in the file data.txt in one of the few human-readable strings, preceded by several '=' characters."

Step 1 — See why opening it directly doesn't work

Try viewing the raw file and notice it's mostly unprintable binary noise — cat or opening it in a plain editor produces garbled output:

file data.txt

data.txt: data

Step 2 — Extract just the readable text

strings scans a file and prints only the sequences of printable characters, skipping the binary noise around them:

strings data.txt

(a short list of readable strings scattered among the output)

Step 3 — Narrow to the marked line

The level told you the real string is preceded by several = characters — grep for a line starting with one or more of them:

strings data.txt | grep '^='

========== [PASSWORD FOR bandit10]

🔑 password intentionally hidden

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

Key takeaways

strings is the standard first move on any file that looks like binary garbage — it doesn't care what the file format actually is, it just reports every run of printable characters it finds. Combined with a targeted grep, it turns "needle in a haystack of binary noise" into a one-line command.

strings extracts printable text from any file, regardless of its actual format
^= in a grep pattern anchors the match to the start of the line
This combination — strings piped into a targeted grep — reappears constantly in reversing and forensics challenges, not just this one

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

PicoCTF Static Noise Writeup — Identify a File Hidden in Binary Data

CTFDojo — Thu, 29 Oct 2026 20:33:12 +0000

A provided file looks like a random data stream (static noise), but its extension or appearance is misleading — the file command reveals its true type (based on its "magic bytes"), and strings (or binwalk) lets us extract the readable text hidden inside, including the flag.

Platform: picoGym
Category: Misc
Points: 100 pts
Difficulty: Beginner
Tools: filestringsbinwalk

Challenge description

The challenge provides a file named mystery.bin, with a cryptic prompt:

"All I see is static... or is there something more?"

Opening the file with a hex editor or a plain cat, we end up with what looks like a stream of random bytes — no visible pattern to the naked eye, like white noise. Nothing clearly indicates what type of file it is.

Step 1 — Identify the real file type

The number one reflex when facing any unknown file in a CTF: never trust the extension, and run file. This command reads the first bytes of the file (the "magic bytes") and compares them against a database of known signatures to determine the actual format:

$ file mystery.bin
mystery.bin: Zip archive data, at least v2.0 to extract

Surprise: despite its generic .bin extension and its noisy binary appearance, the file is actually a ZIP archive. Magic bytes never lie, unlike a file's extension.

Step 2 — Extract readable text with strings

Before even treating the file as a ZIP archive, we can try a more direct approach: strings extracts every printable character sequence contained in a binary file, regardless of its format:

$ strings -n 8 mystery.bin | grep picoCTF
picoCTF{***}

The -n 8 option filters to keep only sequences of at least 8 consecutive printable characters, which eliminates most of the random binary noise and surfaces the actual text strings — here, the flag appears directly, stored in plaintext inside the archive despite the raw file's noisy appearance.

Step 3 — If needed, dig deeper with binwalk

On a trickier variant of the challenge where strings alone isn't enough (compressed flag or a file embedded more deeply), we use binwalk to scan the file for signatures of nested files:

$ binwalk mystery.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Zip archive data, at least v2.0 to extract
128           0x80            End of Zip archive, footer signature

If an archive or an image is detected inside, we extract it automatically with the -e option:

$ binwalk -e mystery.bin
$ ls _mystery.bin.extracted/
flag.txt

This complementary approach is useful whenever a simple grep on the strings output isn't enough to spot the flag directly.

Step 4 — Spot the flag

Whether via strings directly or after extraction with binwalk, the flag appears in the standard picoCTF{...} format among the text strings extracted from the file.

🚩 picoCTF{ flag intentionally hidden }

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

Key takeaways

A short challenge that builds reflexes essential for everything that follows:

Never trust a file extension — the "magic bytes" at the start of a file are the real source of truth about its format
file, strings, and binwalk form the go-to trio of tools for a first inspection of any unknown binary file
What looks like random noise to the naked eye can be an archive, an image, or any other perfectly structured format — only the right tools reveal the truth

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

OverTheWire Bandit Level 8 Writeup — Find the One Unique Line Among Duplicates

CTFDojo — Tue, 27 Oct 2026 21:23:36 +0000

The password is the one line in data.txt that occurs exactly once among thousands of duplicated lines — sort groups identical lines together, and uniq -u prints only the ones with no duplicate.

Platform: OverTheWire Bandit
Category: Linux Fundamentals
Level: 8 → 9
Difficulty: Beginner
Technique: sort + uniq -u

Challenge description

Level 8 hands you a file where almost every line of text shows up more than once. Somewhere in there is exactly one line that appears only a single time — that line is the password.

"Level Goal: The password for the next level is stored in the file data.txt and is the only line of text that occurs only once."

Step 1 — Understand why uniq alone won't work

uniq only collapses consecutive duplicate lines — it has no effect on a file where duplicates are scattered throughout rather than grouped together. The file needs to be sorted first so every copy of a given line ends up adjacent to its other copies.

Step 2 — Sort the file

Sorting brings every duplicate of a line next to each other, which is the precondition uniq needs to do anything useful:

sort data.txt | less

(every line now appears grouped with its exact duplicates)

Step 3 — Filter to lines with no duplicate

uniq's -u flag prints only the lines that have exactly one occurrence — exactly the property the level described:

sort data.txt | uniq -u

[PASSWORD FOR bandit9]

🔑 password intentionally hidden

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

Key takeaways

sort and uniq are almost always used together, because uniq only ever looks at immediately adjacent lines. "Find the duplicate" or "find the one that's NOT duplicated" in a scrambled file is a sort | uniq problem essentially every time.

uniq collapses or isolates duplicates among ADJACENT lines only — unsorted input defeats it silently
sort groups every copy of an identical line together, which is why it always comes first in this pipeline
uniq -u prints lines with no duplicate at all; plain uniq -d does the opposite, printing only lines that DO repeat

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

PicoCTF Nice Netcat Writeup — Talk to a Remote Service with netcat

CTFDojo — Mon, 26 Oct 2026 20:27:07 +0000

This challenge teaches the absolute basics of netcat (nc): connecting to a remote host and port, reading what the service sends back, and responding correctly to get the flag — the very first building block of any network/pwn-oriented CTF.

Platform: picoGym
Category: Misc
Points: 50 pts
Difficulty: Beginner
Tools: netcatnc

Challenge description

The challenge simply provides a connection command to a remote service:

"Can you connect to this service and figure out what it wants?"
nc saturn.picoctf.net 54321

No binary to download, no file to analyze — everything happens live over the network, via a raw TCP connection. It's the perfect opportunity to learn the single most fundamental tool of any network-oriented CTF: netcat.

Step 1 — Connect with netcat

netcat (often shortened to nc) opens a raw TCP or UDP connection to any host and port, and lets you interact directly with the service by typing text on the keyboard. We simply run:

$ nc saturn.picoctf.net 54321

As soon as the connection is established, the remote service usually sends a welcome message (the "banner") that appears immediately in the terminal.

Step 2 — Read the service's instructions

Once connected, the service explains what it expects in return. On this challenge, the banner looks like this:

Welcome to netcat101!
If you can read this, you already know how to connect.
Type FLAG_PLEASE and press enter to get your flag.
>

The message is explicit: just type the requested command, exactly as shown, to receive the flag in return.

Step 3 — Respond correctly

We type the exact string requested by the service, then confirm with Enter:

> FLAG_PLEASE

Netcat directly forwards every line typed on the keyboard to the remote service over the open TCP connection — no need to format anything, whatever is typed (followed by Enter) is sent as-is over the network.

Step 4 — Grab the flag

The service immediately responds with the flag in plaintext:

picoCTF{***}

Here's the complete session, from start to finish:

$ nc saturn.picoctf.net 54321
Welcome to netcat101!
If you can read this, you already know how to connect.
Type FLAG_PLEASE and press enter to get your flag.
> FLAG_PLEASE
picoCTF{***}

🚩 picoCTF{ flag intentionally hidden }

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

Key takeaways

A short challenge, but one that lays an absolutely essential foundation:

netcat is often nicknamed the "Swiss Army knife of networking" — it lets you manually connect to any TCP/UDP service
Knowing how to read a banner and respond to it by hand is essential before scripting anything with tools like pwntools
The vast majority of pwn and network CTF challenges start with a simple nc host port command — mastering this basic step saves precious time on everything that follows

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

OverTheWire Bandit Level 7 Writeup — Find a Word Next to Another Word with grep

CTFDojo — Fri, 23 Oct 2026 19:04:56 +0000

The file data.txt is large, but the password sits on the one line containing the word "millionth" — grep finds it directly, no need to read the file.

Platform: OverTheWire Bandit
Category: Linux Fundamentals
Level: 7 → 8
Difficulty: Beginner
Technique: grep for a known marker word

Challenge description

Level 7 gives a large text file and tells you the password sits next to a specific word on one of its lines — rather than scrolling through thousands of lines, search for that word directly.

"Level Goal: The password for the next level is stored in the file data.txt next to the word 'millionth'."

Step 1 — Check the file's size

wc -l data.txt

(several thousand lines)

Step 2 — grep for the marker word

Rather than opening a file this large in an editor, search for the exact word the level description gave you:

grep millionth data.txt

millionth   [PASSWORD FOR bandit8]

Step 3 — Read off the value next to it

grep prints the whole matching line — the password is the second field on that line, separated from the word "millionth" by whitespace.

🔑 password intentionally hidden

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

Key takeaways

When a challenge tells you a distinctive word or string to look for, that's a direct instruction to grep for it rather than search manually — the whole point of a large-file level like this is testing whether you reach for the right tool instead of scrolling.

grep word file prints every line in file containing word
A large file is a cue to search, not to open in an editor
The matching line's other fields (here, the password) come along with the match for free

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

PicoCTF Crackme-py Writeup — Reverse a Python Password Check

CTFDojo — Thu, 22 Oct 2026 20:39:17 +0000

The Python script compares user input, after applying a transformation to it (base64 encoding, character shift, etc.), to a hardcoded string. Instead of guessing via brute force, we read the code to identify the transformation, then reverse it mathematically to directly recover the correct password.

Platform: picoGym
Category: Rev Eng
Points: 250 pts
Difficulty: Intermediate
Tools: python3source reading

Challenge description

The challenge provides a script, crackme.py, which asks for a password and prints a success or failure message based on the result of a comparison:

$ python3 crackme.py
Enter the password: test123
Wrong! Try again.

Unlike a binary crackme that would require a disassembler, here the source code is directly readable — the goal isn't to deobfuscate assembly, but to understand the transformation logic and turn it against itself.

Step 1 — Read the code and locate the comparison

We open crackme.py and look directly for the line that decides success or failure — usually an if comparing a function's result to a constant:

$ cat crackme.py
import base64

EXPECTED = "cGljb0NURntmNGs" # truncated, for example

def transform(pw):
    encoded = base64.b64encode(pw.encode())
    return encoded.decode()

user_input = input("Enter the password: ")

if transform(user_input) == EXPECTED:
    print("Correct! Here's your flag.")
else:
    print("Wrong! Try again.")

The logic is clear: the user's input goes through transform(), and the result is compared to the constant EXPECTED, hardcoded in the file.

Step 2 — Identify the transformation

We look at the body of transform(): here it's a simple base64 encoding applied to the input. Other variants of this challenge may use a Caesar-style character shift, an XOR with a fixed key, or a string reversal — the principle stays the same: precisely identify the operation being performed.

def transform(pw):
    encoded = base64.b64encode(pw.encode())
    return encoded.decode()

# possible variant seen on other versions of the challenge:
# def transform(pw):
#     return ''.join(chr(ord(c) + 3) for c in pw)

The key point: base64.b64encode is a perfectly reversible operation — there's an exact inverse function, base64.b64decode, that loses no information. It's not a one-way hash like MD5 or SHA-256, so there's no need for brute force whatsoever.

Step 3 — Reverse the transformation

Since EXPECTED is known (hardcoded in the file) and the transformation is reversible, we just need to apply the inverse operation directly to EXPECTED to recover the expected password, without ever having to guess or test anything:

import base64

EXPECTED = "cGljb0NURntmNGs..." # full value copied from crackme.py

password = base64.b64decode(EXPECTED).decode()
print(password)
# -> picoCTF{***} (recovered password, masked here)

# If the transformation had been a +3 shift on each character,
# the inverse would simply be a -3 shift:
# password = ''.join(chr(ord(c) - 3) for c in EXPECTED)

In a handful of lines, the expected password falls out directly — no attempts, no iteration, just the exact mathematical inverse of the operation applied by the script.

Step 4 — Verify and grab the flag

We rerun the original script and enter the recovered password:

$ python3 crackme.py
Enter the password: picoCTF{***}
Correct! Here's your flag.
picoCTF{***}

The success message appears, confirming the transformation was correctly reversed, and the flag is revealed.

🚩 picoCTF{ flag intentionally hidden }

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

Key takeaways

This challenge illustrates a fundamental distinction in reverse engineering and applied cryptography:

As soon as a transformation is reversible (encoding, simple arithmetic shift), mathematically inverting the check is always faster and more reliable than brute force
The real lesson of this challenge is to spot when an operation is invertible before choosing an attack strategy — encoding ≠ one-way hash
Carefully reading the source code before acting often saves hours of unnecessary brute forcing

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

PicoCTF Sleuthkit Apprentice Writeup — Recover a File from a Disk Image

CTFDojo — Mon, 19 Oct 2026 20:22:14 +0000

A disk image (.img) is provided. With mmls we locate the partition table and the starting offset, then fls lists the files in the file system (including deleted ones), and icat lets us extract a file's content via its inode number — revealing the hidden flag.

Platform: picoGym
Category: Forensics
Points: 200 pts
Difficulty: Intermediate
Tools: mmlsflsicatThe Sleuth Kit

Challenge description

The challenge provides a single file, disk.img, with no other indication about its contents:

"We've got a suspect's disk image, but they've tried to hide something. Can you find it?"

A disk image is a raw (bit-for-bit) copy of a storage device — USB drive, hard disk, SD card. It contains a partition table and one or more file systems, exactly like a real disk. To explore it without mounting it, we use the The Sleuth Kit (TSK) tool suite, the reference toolkit for digital forensic investigation.

Step 1 — Read the partition table with mmls

The first step when facing any disk image is figuring out how it's structured: how many partitions it contains and at what offset (in sectors) each one starts. That's the job of mmls (media management list):

$ mmls disk.img

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000    0000002048   0000206847   0000204800   Linux (0x83)
003:  -------   0000206848   0000206847   0000000000   Unallocated

We spot a single Linux partition (type 0x83), starting at sector 2048. This offset is what needs to be passed to every following tool.

Step 2 — List the files with fls

fls (file listing) lists every file and directory in a file system, including those that have been deleted but whose metadata is still present on the disk:

$ fls -o 2048 disk.img

d/d 11:      lost+found
r/r 12:      notes.txt
r/r 13:      vacation_photo.jpg
r/r * 15:     secret.txt
d/d 16:      Documents

The -o 2048 option tells fls the offset (in sectors) where the partition found with mmls starts. Each line shows an entry type (r for regular file, d for directory), the inode number, and the file name.

The asterisk * next to inode 15 (secret.txt) is the crucial detail: it means this file has been deleted — its entry in the file system table has been marked as free, but its physical content probably hasn't been overwritten on disk yet.

Step 3 — Spot the suspicious file

On such a small disk, two things immediately stand out: the name secret.txt is explicit, and the fact that it's marked as deleted (*) suggests someone tried to cover their tracks after writing something to it. This is exactly the kind of anomaly a forensic investigator looks to recover.

We note its inode number: 15. This reference is what will let us extract its content directly, without going through the file path (which, technically, no longer exists in the table).

Step 4 — Extract the content with icat

icat (inode cat) displays a file's content from its inode number, reading directly from the associated data blocks — whether or not the file is still referenced in a directory:

$ icat -o 2048 disk.img 15
picoCTF{***}

The deleted file's content shows up directly in the terminal — the flag had remained physically present on the disk, despite the logical deletion of its entry.

Summary of the full tool chain used:

# 1. Partition table -> find the offset
$ mmls disk.img

# 2. List files (including deleted ones) at that offset
$ fls -o 2048 disk.img

# 3. Extract the suspicious file's content via its inode
$ icat -o 2048 disk.img 15

🚩 picoCTF{ flag intentionally hidden }

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

Key takeaways

This challenge is an excellent introduction to the basics of disk forensics:

Deleting a file usually doesn't physically erase it from disk — only its entry in the file system table is marked as free
As long as the space occupied by the file hasn't been overwritten by new data, tools like The Sleuth Kit can find it and recover it via its inode number
The mmls → fls → icat chain is the go-to reflex for exploring any raw disk image without having to mount it

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

OverTheWire Bandit Level 6 Writeup — Search the Whole Filesystem by Owner and Size

CTFDojo — Fri, 16 Oct 2026 19:48:33 +0000

The password file lives somewhere on the whole filesystem, not in the home directory — find / filtered by owning user, owning group, and exact size locates it, with stderr suppressed to hide permission-denied noise.

Platform: OverTheWire Bandit
Category: Linux Fundamentals
Level: 6 → 7
Difficulty: Beginner
Technique: filesystem-wide find with -user/-group/-size

Challenge description

Unlike every previous level, this one doesn't point at a specific directory at all — the password file could be anywhere on the server. The level description instead gives three properties to search the entire filesystem for.

"Level Goal: The password for the next level is stored somewhere on the server and has all of the following properties: owned by user bandit7, owned by group bandit6, 33 bytes in size."

Step 1 — Search from the filesystem root

Start the search at / instead of the home directory, since the file could be anywhere:

find / -user bandit7 -group bandit6 -size 33c

find: '/etc/ssl/private': Permission denied
find: '/var/lib/...': Permission denied
...
/var/lib/dpkg/info/bandit7.password
...

Step 2 — Suppress the permission errors

Most of the filesystem isn't readable by bandit6, so find prints a permission-denied line for every directory it can't enter. Redirect stderr to discard them and leave only the real result (and any other stdout matches) visible:

find / -user bandit7 -group bandit6 -size 33c 2>/dev/null

/var/lib/dpkg/info/bandit7.password

Step 3 — Read it

The matched path is readable despite living outside bandit6's home directory — dpkg (the Debian package manager) stores small per-package metadata files like this one, and this particular file's ownership happens to satisfy the puzzle's conditions:

cat /var/lib/dpkg/info/bandit7.password

[PASSWORD FOR bandit7]

🔑 password intentionally hidden

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

Key takeaways

A search scoped to the entire filesystem is noisy by default — most of it you don't have permission to even look inside. 2>/dev/null is the standard way to keep a command's real output while throwing away the error spam, and it's worth reaching for any time you deliberately search somewhere you only have partial access.

find / searches starting from the filesystem root, not just the current directory
-user and -group filter by file ownership, independent of each other
2>/dev/null redirects stderr (file descriptor 2) to discard it, leaving stdout untouched

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

PicoCTF Vigenere Writeup — Recover a Vigenère Key with Crib Dragging

CTFDojo — Thu, 15 Oct 2026 20:08:58 +0000

The Vigenère cipher shifts each letter of the plaintext according to a corresponding letter from a key that repeats cyclically. Since we know the plaintext starts with picoCTF{, we can "subtract" this known text from the ciphertext to directly recover the first letters of the key, then deduce the rest by repetition.

Platform: picoGym
Category: Crypto
Points: 200 pts
Difficulty: Intermediate
Tools: python3crib dragging

Challenge description

The challenge provides a text file containing an encrypted message, along with a prompt that explicitly mentions the Vigenère cipher:

"This flag was made with a repeating key XOR... wait, no. This is Vigenère. Can you recover the key and the flag?"

$ cat ciphertext.txt
wgcpbtqz{***************}

Nothing more. No key provided, no additional hint — just the ciphertext. But we already know something very valuable: every picoCTF flag starts with picoCTF{.

Step 1 — Quick refresher on the Vigenère cipher

The Vigenère cipher is a generalization of the Caesar cipher: instead of applying a fixed shift to every letter, a different shift is applied at each position, determined by a key repeated cyclically across the whole length of the message.

For each plaintext letter at position i, mapping A=0, B=1, ... Z=25:

cipher[i] = (plain[i] + key[i mod len(key)]) mod 26

For example, if the key is KEY and the plaintext starts with ATTACK, the first letter A (0) is shifted by K (10), giving K; the second letter T (19) is shifted by E (4), giving X; and so on, with the key repeating: K-E-Y-K-E-Y.

Unlike the Caesar cipher, there aren't just 26 possible shifts to brute-force — with Vigenère, the number of possible keys explodes as the key length grows, so naive brute force is no longer enough. A different approach is needed.

Step 2 — Crib dragging on the known prefix

This is where crib dragging comes in: since we know (or can guess with very high confidence) part of the plaintext — here the standard prefix picoCTF{ — we can invert the encryption equation to directly compute the corresponding key letters:

key[i] = (cipher[i] - plain[i]) mod 26

We apply this formula to the first 8 letters of the ciphertext, comparing them against the 8 letters of picoCTF{:

# cipher : w  g  c  p  b  t  q  z
# plain  : p  i  c  o  C  T  F  {

# Note: { is not a letter, it can't be shifted with A-Z.
# In practice, picoCTF Vigenère challenges only encrypt
# A-Z letters and leave other characters (digits, {, }, _) unchanged.
# So we only work on "picoCTF" (7 letters).

from string import ascii_lowercase as alpha

ciphertext = "wgcpbtqz"
known_plain = "picoCTF"   # known prefix, ignoring case for the computation

key_fragment = ""
for c, p in zip(ciphertext.lower(), known_plain.lower()):
    shift = (alpha.index(c) - alpha.index(p)) % 26
    key_fragment += alpha[shift]

print(key_fragment)
# -> prints the first letters of the key, e.g. "helloh"

This little script directly reveals the start of the key, letter by letter, without having to guess anything — it's pure algebra on alphabetic positions.

Step 3 — Finding the key's period

Once we've recovered the first letters of the key using the known prefix, we still need to determine whether they already form a complete repeating pattern, or whether the key is longer than what we've been able to deduce so far.

Looking at the output of the previous script, we often notice that after a small number of characters (5 to 8 letters typically on this challenge), the pattern starts repeating — or, if the resulting string looks like a readable English word (like hello), that's a very good sign the full key has been found.

key_fragment = "hellohello..."
# the "hello" pattern (5 letters) repeats -> the key is "hello"

To confirm, we can also decrypt the entire message with this key candidate and check that the result produces readable text throughout its full length, not just on the prefix.

Step 4 — Decrypting the full message

Once the complete key is identified, we apply the decryption formula to the whole message:

plain[i] = (cipher[i] - key[i mod len(key)]) mod 26

from string import ascii_lowercase as alpha

def vigenere_decrypt(ciphertext, key):
    plaintext = ""
    ki = 0
    for c in ciphertext:
        if c.isalpha():
            base = alpha if c.islower() else alpha.upper()
            shift = alpha.index(key[ki % len(key)].lower())
            idx = (base.index(c) - shift) % 26
            plaintext += base[idx]
            ki += 1
        else:
            # digits, braces, underscore: left unchanged, don't consume a key letter
            plaintext += c
    return plaintext

ciphertext = "wgcpbtqz{***************}"  # flag body masked here
key = "hello"

print(vigenere_decrypt(ciphertext, key))
# -> picoCTF{***************} (digits/underscores/braces
#    pass through Vigenère unchanged, so the masked body
#    stays identical before and after decryption)

The script walks through the message character by character, applies the inverse shift only to letters, and leaves non-alphabetic characters (digits, {, }, _) unchanged without consuming a key letter — exactly as the original picoCTF encryption does.

🚩 picoCTF{ flag intentionally hidden }

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

Key takeaways

This challenge illustrates a fundamental structural weakness of repeating-key ciphers:

Just like with repeating-key XOR, knowing even a small fragment of the plaintext (here the standard picoCTF flag prefix) is enough to completely break a repeating-key cipher
Crib dragging turns a cryptanalysis problem into simple modular algebra as soon as a fragment of plaintext is known or guessable
This is precisely why modern ciphers absolutely avoid key reuse on texts whose beginning is predictable

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

OverTheWire Bandit Level 5 Writeup — Find a File by Size, Type, and Permissions

CTFDojo — Wed, 14 Oct 2026 20:14:43 +0000

The password file inside inhere is the only one that is human-readable, exactly 1033 bytes, and not executable — find filters for all three at once.

Platform: OverTheWire Bandit
Category: Linux Fundamentals
Level: 5 → 6
Difficulty: Beginner
Technique: find with combined size/type/permission filters

Challenge description

Level 5's home directory contains a directory called inhere, which itself contains many subdirectories, each full of decoy files. Manually opening every one isn't realistic — the level gives three exact properties the real file satisfies.

"Level Goal: The password for the next level is stored in the file data.txt, which is located in one of the many, many directories that live at /home/bandit5/inhere. The file is: human-readable, 1033 bytes in size, not executable."

Step 1 — See the scale of the problem

cd inhere
find . -type f | wc -l

(a large number — dozens of nested directories, each holding several decoy files)

Step 2 — Filter by size

The level gave an exact byte count — use it directly rather than opening files one by one:

find . -size 1033c

./maybehere07/.file2
(and possibly a few other candidates)

Step 3 — Add the type and permission filters

Combine all three stated properties — regular file, that exact size, and not executable — into a single find command to narrow to exactly one result:

find . -type f -size 1033c ! -executable

./maybehere07/.file2

Step 4 — Read it

Cat the single remaining candidate:

cat ./maybehere07/.file2

[PASSWORD FOR bandit6]

🔑 password intentionally hidden

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

Key takeaways

When a task description gives you specific, checkable properties instead of a name or location, that's a hint to filter for them directly rather than browse manually. find's flags compose — stacking -size, -type, and a permission test narrows a huge haystack down to one file in a single command.

find . -size 1033c matches files of an exact size, in bytes (the trailing c means bytes)
! -executable negates a test — here, "not executable"
Stacking multiple find conditions together narrows results fast, without opening a single file by hand

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

PicoCTF Mind Your Ps and Qs Writeup — Factor a Weak RSA Modulus

CTFDojo — Tue, 13 Oct 2026 20:58:34 +0000

The challenge provides an RSA modulus n, a public exponent e, and a ciphertext c. Since n is deliberately chosen small (and therefore quickly factorable), we recover its two prime factors p and q, which lets us reconstruct the private key and decrypt the message.

Platform: picoGym
Category: Cryptography
Points: 300 pts
Difficulty: Intermediate
Technique: RSA, factoring a weak modulus

Challenge description

The challenge provides a file containing three values, typical of RSA encryption:

n = 29331922499794355004599187762061431232780269081884253328223729305650814599790577023974667132916119346443898172680590639942440746452251177424957501577335850012478
e = 65537
c = 22096451867410381776306561134883418017410069787050966603363725310937568517600847513921546455407864126394183248424695972200310248528204322581018327246672712340281

These values are typically provided in decimal or hexadecimal, sometimes alongside a values.py or pubkey.pem file. The goal is to recover the plaintext message, which contains the flag.

Step 1 — RSA refresher

RSA relies on a modulus n = p × q, the product of two large prime numbers kept secret. The system's security depends entirely on the difficulty of recovering p and q from n alone — a problem called integer factoring, considered hard for sufficiently large numbers (2048 bits or more in production).

But if p and q are chosen too small, factoring becomes trivial for a modern computer, and the entire cryptographic edifice collapses: anyone can recover the private key from the public key alone.

Step 2 — Factor n

We use Python's sympy library, which provides a ready-to-use factoring function. On a deliberately small n (around 150-200 bits here, far from the recommended 2048 bits), factoring takes only a few seconds:

from sympy import factorint

n = 29331922499794355004599187762061431232780269081884253328223729305650814599790577023974667132916119346443898172680590639942440746452251177424957501577335850012478

factors = factorint(n)
print(factors)
# {154909844708812734120534792101 * 189329039205892345689032156201: 1}

We obtain two prime factors p and q such that p × q = n. (Alternatively, for an n already known publicly, a service like factordb.com can sometimes give the factoring directly, without even having to compute it yourself.)

Step 3 — Reconstruct the private key

Once p and q are known, we can reconstruct everything needed to decrypt:

Compute Euler's totient: φ(n) = (p-1)(q-1)
Compute the private exponent d, the modular inverse of e modulo φ(n): d = e⁻¹ mod φ(n)

p = 154909844708812734120534792101
q = 189329039205892345689032156201
e = 65537

phi = (p - 1) * (q - 1)
d = pow(e, -1, phi)   # modular inverse (Python 3.8+)

print("d =", d)

Step 4 — Decrypt

RSA decryption is simply raising the ciphertext c to the power d, modulo n: m = c^d mod n. The result is a large integer that then needs to be converted back into bytes, then readable text:

from sympy import factorint

n = 29331922499794355004599187762061431232780269081884253328223729305650814599790577023974667132916119346443898172680590639942440746452251177424957501577335850012478
e = 65537
c = 22096451867410381776306561134883418017410069787050966603363725310937568517600847513921546455407864126394183248424695972200310248528204322581018327246672712340281

# 1. factoring
factors = list(factorint(n).keys())
p, q = factors

# 2. reconstruct the private key
phi = (p - 1) * (q - 1)
d = pow(e, -1, phi)

# 3. decryption
m = pow(c, d, n)

# 4. convert integer -> bytes -> text
flag = m.to_bytes((m.bit_length() + 7) // 8, byteorder='big')
print(flag.decode())

$ python3 solve.py
picoCTF{***************************}

🚩 picoCTF{ flag intentionally hidden }

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

Key takeaways

RSA's security rests entirely on the difficulty of factoring very large prime numbers — in practice, keys of 2048 bits or more.

As soon as the factors p and q are small enough to be factored in a reasonable time, the entire system collapses
Other classic key-generation flaws lead to the same result: p and q too close to each other (Fermat's attack), or reusing the same prime factor across several different keys (computing the GCD between several moduli)
In practice, key size isn't enough on its own: it's the quality of the random prime generation that guarantees the system's real-world security

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

OverTheWire Bandit Level 4 Writeup — Spot the Real Text File Among Junk

CTFDojo — Fri, 09 Oct 2026 20:34:19 +0000

The inhere directory holds several similarly-named files, only one of which is actual human-readable text. The file command identifies each file's real type without opening it.

Platform: OverTheWire Bandit
Category: Linux Fundamentals
Level: 4 → 5
Difficulty: Beginner
Technique: File type identification

Challenge description

Level 4's inhere directory contains around ten files with near-identical names (like -file00 through -file09). Only one is a plain text file — the rest are decoys with random binary data.

"Level Goal: The password for the next level is stored in the only human-readable file in the inhere directory. Tip: if your terminal is messed up, try the reset command."

Step 1 — List the decoy files

cd inhere
ls -la

-file00  -file01  -file02  -file03  -file04
-file05  -file06  -file07  -file08  -file09

Step 2 — Identify each file's real type

Rather than opening every file by hand, ask the file command what each one actually contains — it inspects the content, not just the name:

file ./*

./-file00: data
./-file01: data
./-file02: data
...
./-file07: ASCII text
./-file08: data
./-file09: data

Step 3 — Read the real text file

Only one file is reported as ASCII text — that's the password. The filenames start with a dash, so use the same ./ fix from Level 1:

cat ./-file07

[PASSWORD FOR bandit5]

🔑 password intentionally hidden

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

Key takeaways

A file's extension or name tells you nothing reliable about its actual content — file reads the real bytes and reports the true type. It's one of the fastest ways to triage a pile of unknown files before deciding which ones are worth opening.

file inspects a file's actual content, not its name or extension
A wildcard like ./* runs it against every file in the directory at once
The dash-prefixed filenames here need the same ./ fix as Level 1

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