DEV Community: rudy_candy

strings Command in CTF: Hidden Data Guide

rudy_candy — Mon, 20 Apr 2026 18:01:46 +0000

picoCTF Ph4nt0m 1ntrud3r — Network Forensics Writeup

Category: Forensics | Difficulty: Easy | Competition: picoCTF

Challenge Overview

The picoCTF Ph4nt0m 1ntrud3r challenge drops you into a classic network forensics scenario: you receive a PCAP file and need to figure out what a mystery attacker was smuggling across the wire. No binary exploitation, no cryptographic math — just you, Wireshark, and a packet capture that hides a fragmented flag across multiple packets. I'll be honest: I thought this would take me ten minutes. It took closer to ninety, mostly because I spent the first half-hour confidently doing the wrong thing.

This writeup covers the full investigation: my initial wrong approach, the rabbit hole I fell into, the exact Wireshark filters I used, the Python decoder I wrote, and what I'd do differently if I had to solve this again from scratch.

My First (Wrong) Approach — And Why I Chose It

When I opened evidence.pcap in Wireshark, my gut reaction was to look at DNS traffic. In a lot of CTF forensics problems, exfiltration happens over DNS because defenders often under-monitor it. Long, weirdly-encoded subdomains are a classic data-hiding technique. I filtered on dns immediately and started staring at query names, convinced I was about to find something like cGljb0NURg==.attacker.evil.

There was nothing. Some boring A-record lookups, nothing that looked hand-crafted. I switched to HTTP, thinking maybe the flag was in a User-Agent header or a URL parameter. Still nothing suspicious. I then tried tcp contains "picoCTF" as a raw string search — also empty. At this point I had burned roughly 35 minutes and had zero leads.

The reason I kept chasing these paths is that they work in a lot of other CTF challenges, and pattern-matching from past experience can be a trap. I was looking for the shape of a problem I'd solved before instead of reading the actual data in front of me.

The Rabbit Hole: Manual Packet Inspection

After the DNS and HTTP dead ends, I started scrolling through packets manually, reading payloads one by one. This is exactly the kind of approach that sounds thorough but is actually just slow. I found a few packets with short string payloads and tried to read them as ASCII flags. One of them had what looked like a partial "picoC" — I got excited, copied it out wrong because I was working from a hex dump, and spent another fifteen minutes trying to figure out why my "flag" was garbled nonsense.

That manual copy failure was the moment I finally stopped and thought about the problem differently. If the data is fragmented and Base64-encoded, manual copying from hex dumps is going to produce errors every single time. I needed to sort by something structural and then automate the extraction.

Setting Up the Investigation Environment

Tools used for this challenge:

Wireshark 4.x (packet capture analysis)
Python 3.11 (Base64 decoding script)
tshark (command-line Wireshark for batch extraction)
A Linux terminal with base64 utility for quick spot checks

Nothing exotic. The point of forensics challenges at this level is usually that the tools are simple and the insight is the hard part.

Digging Into the PCAP with Wireshark

Initial Triage: What Does This Traffic Even Look Like?

After abandoning the manual scroll approach, I went back to basics. In Wireshark, I opened the Statistics menu and ran Protocol Hierarchy first. This gives you an instant breakdown of what protocols are present in the capture without requiring you to guess. The capture was mostly TCP with a small cluster of short application-layer payloads that didn't map cleanly to any known protocol — that asymmetry was the first real signal.

Next I sorted packets by Length (ascending). This is a move I wish I'd made at the start. The attacker's fragments were short — consistently around 12–16 bytes of payload — while the rest of the traffic had normal-sized packets. That uniform small size is unusual and stands out immediately once you sort by length.

Applying Wireshark Filters

Once I had a hypothesis — short payloads, possibly Base64 — I used the following display filter to isolate TCP segments with small application data:

tcp.len > 0 and tcp.len < 20

This filtered down to a manageable set of packets. Looking at the Follow TCP Stream output on one of them:

Wireshark > Right-click packet > Follow > TCP Stream

Stream content (ASCII view):
cGljb0NURg==
ezF0X3c0cw==
bnRfdGg0dA==
XzM0c3lfdA==
YmhfNHJfOQ==
NjZkMGJmYg==
fQ==

Seven short strings. Every single one ends in = or ==. That trailing equals sign is the unmistakable fingerprint of Base64 padding — it appears when the input length isn't a multiple of three bytes. Seeing it once might be coincidence. Seeing it seven times in a row is a pattern that can only mean one thing.

I also used tshark from the command line to extract these payloads more cleanly, which avoids the copy-paste errors I'd been making earlier:

tshark -r evidence.pcap -Y "tcp.len > 0 and tcp.len < 20" -T fields -e data.text

Output:

cGljb0NURg==
ezF0X3c0cw==
bnRfdGg0dA==
XzM0c3lfdA==
YmhfNHJfOQ==
NjZkMGJmYg==
fQ==

Clean extraction, no manual copying. This is what I should have done from the beginning instead of scrolling through hex dumps by hand.

The Importance of Timestamp Order

One subtlety worth noting: network packets don't necessarily arrive in the order they were sent. TCP handles reordering at the transport layer, but if you're extracting application-layer fragments manually, you need to sort by the original timestamp — not by the order Wireshark received them. In this challenge the packets happened to arrive in sequence, but in a real incident response scenario, out-of-order fragments are a deliberate anti-forensics technique. Always sort by time first, then extract.

Recognizing the Base64 Pattern

Before writing the decoder, I did a quick sanity check on the first fragment using the command line:

$ echo "cGljb0NURg==" | base64 --decode
picoCTF

That was the moment everything clicked. picoCTF — the first fragment is literally the competition name and flag prefix. The attacker (or in this case, the challenge author) split the flag at a seven-character boundary and encoded each chunk separately. The decode confirms: I have the right data, I have the right encoding, and I just need to concatenate all seven decoded strings.

Let me be specific about that feeling: it's genuinely satisfying after 35 minutes of wrong guesses to see a word you recognize come out of a decoder. Not triumphant — more like the relief when you finally find your keys after tearing the house apart. The work isn't done yet but now at least you know what you're doing.

Writing the Decoder Script

With all seven fragments confirmed, the decoder is straightforward:

import base64

# Fragments extracted from PCAP via tshark, sorted by timestamp
cipher = [
    "cGljb0NURg==",   # fragment 1
    "ezF0X3c0cw==",   # fragment 2
    "bnRfdGg0dA==",   # fragment 3
    "XzM0c3lfdA==",   # fragment 4
    "YmhfNHJfOQ==",   # fragment 5
    "NjZkMGJmYg==",   # fragment 6
    "fQ=="            # fragment 7
]

plain = ""
for i, c in enumerate(cipher):
    decoded = base64.b64decode(c).decode("utf-8")
    print(f"Fragment {i+1}: {c!r:20s} => {decoded!r}")
    plain += decoded

print()
print("Assembled flag:", plain)

Execution output:

$ python3 decode_flag.py
Fragment 1: 'cGljb0NURg=='      => 'picoCTF'
Fragment 2: 'ezF0X3c0cw=='      => '{1t_w4s'
Fragment 3: 'bnRfdGg0dA=='      => 'nt_th4t'
Fragment 4: 'XzM0c3lfdA=='      => '_34sy_t'
Fragment 5: 'YmhfNHJfOQ=='      => 'bh_4r_9'
Fragment 6: 'NjZkMGJmYg=='      => '66d0bfb'
Fragment 7: 'fQ=='              => '}'

Assembled flag: picoCTF{1t_w4snt_th4t_34sy_tbh_4r_966d0bfb}

Flag: picoCTF{1t_w4snt_th4t_34sy_tbh_4r_966d0bfb}

The flag text itself is a small joke by the challenge author — "it wasn't that easy, tbh" — which I found funnier after spending 90 minutes on what is technically an "Easy" challenge.

Full Trial Process Table

Here is every approach I tried during this challenge, in order:

Step	Action	Command / Filter	Result	Why it failed / succeeded
1	Filter DNS traffic	`dns`	Only standard A-record lookups, nothing encoded	Wrong assumption — exfiltration wasn't DNS-based
2	Filter HTTP traffic	`http`	No suspicious headers or URL params	Wrong protocol assumption from past CTF patterns
3	Raw string search for flag prefix	`tcp contains "picoCTF"`	No matches	Flag was Base64-encoded, not plaintext — search missed it
4	Manual hex dump scroll	(manual, no filter)	Found short payloads but copied incorrectly	Human error in transcribing hex; garbled output
5	Protocol hierarchy check	Statistics > Protocol Hierarchy	Identified anomalous short TCP payloads	Right direction — structural anomaly visible
6	Sort by packet length	Column sort in Wireshark UI	Small cluster of 12–16 byte payloads visible	Attacker's fragments isolated from normal traffic
7	Filter short TCP payloads	`tcp.len > 0 and tcp.len < 20`	Seven packets isolated	Correct filter; exact fragments found
8	Follow TCP stream	Right-click > Follow > TCP Stream	All seven Base64 strings visible in sequence	Confirmed data and order; saw "=" padding pattern
9	tshark command-line extraction	`tshark -r evidence.pcap -Y "tcp.len > 0 and tcp.len < 20" -T fields -e data.text`	Clean list of seven Base64 fragments	No manual copy error; clean input for Python script
10	Quick spot decode	`echo "cGljb0NURg=="	base64 --decode`	`picoCTF`
11	Python decoder script	`python3 decode_flag.py`	Full flag assembled: `picoCTF{1t_w4snt_th4t_34sy_tbh_4r_966d0bfb}`	All fragments decoded and concatenated correctly

Technical Deep Dive — Why Attackers Fragment Data This Way

Data Fragmentation as an Evasion Technique

This challenge models a real attacker behavior: splitting exfiltrated data into small chunks to evade detection. Signature-based intrusion detection systems (IDS) look for known patterns — if a full flag string or a recognizable file header appears in a single packet, an alert fires. But if that same data is split into seven fragments of 8–12 bytes each, each encoded in Base64 (which looks like random alphanumeric noise to a pattern matcher), the same IDS might let every packet through individually.

Base64 encoding adds another layer of deniability. It transforms binary or text data into a character set that looks like ordinary web traffic — Base64 appears constantly in legitimate email attachments, image data URIs, and API tokens. A network defender scanning for "weird-looking traffic" might not flag short Base64 strings without specific tuning.

Real-World Network Forensics Parallels

In professional incident response and digital forensics, Wireshark and tshark are standard tools that security operations center (SOC) analysts and DFIR (Digital Forensics and Incident Response) specialists use daily. The workflow in this challenge — capture traffic, identify anomalous patterns, extract and decode payloads — mirrors what a real analyst does when investigating suspected data exfiltration.

Some concrete real-world parallels:

APT exfiltration campaigns often use DNS tunneling or HTTP with Base64-encoded payloads in headers — the same encoding technique used here, just over a different protocol
Malware command-and-control (C2) traffic frequently uses short, regular beacons with encoded payloads; identifying the "attacker's packets" by their unusual size and periodicity is a standard detection heuristic
Network traffic analysis (NTA) tools like Zeek/Bro and Suricata implement exactly the kind of length-based filtering we did manually here — they flag short TCP streams with encoded payloads as potential exfiltration candidates
DFIR tools like NetworkMiner automate the extraction of payloads from PCAP files, doing at scale what we did by hand in this challenge

The skills this challenge teaches — statistical anomaly detection in traffic, protocol filter construction, payload extraction, encoding recognition — are directly transferable to entry-level SOC analyst work. This isn't just a CTF puzzle; it's a stripped-down version of a real investigation workflow.

Why Base64 Specifically?

Base64 is not encryption — it provides no confidentiality. Anyone who sees the encoded string can decode it trivially. The reason it shows up in CTF challenges and in real attacks is that it solves a different problem: binary data compatibility. Network protocols, email systems, and web applications are often designed to handle text. Base64 encodes arbitrary binary data as printable ASCII characters, making it safe to embed in text-only contexts. Attackers use it not to hide data from sophisticated defenders, but to get it through infrastructure that would otherwise mangle or block binary payloads.

Reflection — How I Would Solve This Faster Next Time

Looking back at this challenge with the benefit of knowing the answer, my 90-minute solve breaks down roughly as:

35 minutes: chasing DNS and HTTP false leads
20 minutes: manual hex dump scrolling and failed copy attempts
15 minutes: realizing I should check protocol hierarchy and sort by length
10 minutes: applying the right filter and extracting fragments
10 minutes: writing and running the decoder

The first 55 minutes were waste. Here's the checklist I'd follow if I had to do this again from the start:

Protocol Hierarchy first, always. Before applying any filters, run Statistics > Protocol Hierarchy. This takes 10 seconds and tells you exactly what you're dealing with.
Sort by packet length before scrolling. Attackers' fragments usually stand out by size. Sort ascending, look for clusters of unusually short or unusually long packets.
Use tshark for extraction, not manual copy. The moment you're copy-pasting hex or ASCII from Wireshark by hand, you're introducing errors. Automate extraction from the start.
Spot-test the encoding before writing a full script. A one-liner (echo "..." | base64 --decode) confirms your hypothesis before you invest time scripting.
Don't assume past patterns apply. DNS exfiltration, HTTP header hiding — these work in many challenges. But the first thing to do is read the actual data, not apply heuristics from previous problems.

If I applied this checklist, I think I could solve this challenge in under 15 minutes. The solution is genuinely straightforward — the difficulty is resisting the urge to jump to conclusions and doing the unglamorous structural analysis first.

Key Takeaways

Wireshark filter to isolate short TCP payloads: tcp.len > 0 and tcp.len < 20
tshark command to extract payload text: tshark -r evidence.pcap -Y "tcp.len > 0 and tcp.len < 20" -T fields -e data.text
Base64 tell: trailing = or == padding in all fragments
Lesson: Start with protocol-level statistics, not protocol assumptions
Real-world connection: This workflow (size anomaly detection → payload extraction → encoding analysis) is standard network forensics practice in SOC and DFIR environments

picoCTF Ph4nt0m 1ntrud3r is a well-constructed introductory forensics challenge because it teaches a real investigative pattern, not just a trick. The "easy" rating is accurate once you know what to look for — but getting to that moment of knowing takes most of the work.

pngcheck in CTF: How to Analyze and Repair PNG Files

rudy_candy — Mon, 20 Apr 2026 18:01:43 +0000

🔍 pngcheck CTF Tutorial: How to Analyze Corrupted PNG Files and Find Hidden Chunks

Searching for "pngcheck CTF" or "how to fix corrupted PNG forensics" usually returns tool documentation or terse Writeups that skip the thinking. This article is different: it's a walkthrough of how I actually use pngcheck in CTF PNG forensics challenges — including the 30 minutes I wasted on steganography tools before I learned to validate structure first. If you're stuck on a corrupted PNG challenge and wondering what pngcheck is showing you, this guide will get you unstuck.

This Article at a Glance

pngcheck is a command-line PNG validation tool that reads a PNG file's internal chunk structure and reports exactly what's wrong — or what's hidden — at the byte level. In CTF forensics, it's the fastest way to diagnose a corrupted PNG, find non-standard chunks, and decide whether you're dealing with a structural fix challenge or a steganography challenge. By the end of this article, you'll know when to run it, what its output means, and — just as importantly — when to put it down and switch tools.

Introduction: The PNG Challenge Where I Used Every Tool Except the Right One

CTF forensics challenges love PNG files. They're binary, they have a well-documented structure, and there are a dozen ways to hide data inside them without visually changing the image. The problem for beginners is that a corrupted or manipulated PNG doesn't announce itself — it just fails to open, or opens fine while hiding something in the chunk data you never look at.

pngcheck is the tool that makes the invisible visible. It reads the raw PNG chunk stream and validates every piece of the structure: the magic header bytes, the IHDR dimensions, each IDAT chunk's CRC, the IEND terminator, and anything else lurking in between. It won't decrypt anything or extract hidden images — but it will tell you precisely where the file is broken, where extra data is hiding, and what every chunk in the file actually contains.

The challenge that taught me this was picoCTF's Corrupted File — a PNG that wouldn't open, a description that said "I tried to open this image but something seems off," and me spending 30 minutes going down the wrong path completely. My first instinct was steganography. I ran zsteg challenge.png, got output I didn't understand, tried every channel combination. Nothing. I tried stegsolve and clicked through every filter. Still nothing. I even tried strings and grepped for picoCTF{. The flag wasn't there because the image wasn't a steganography challenge. It was a broken CRC challenge. One pngcheck -v would have shown me the answer in 2 seconds. The reason I didn't run it first: I associated PNG challenges with hidden pixel data and never considered that the file structure itself was the puzzle.

What is pngcheck? (And What It Isn't)

What pngcheck actually does

A PNG file is a sequence of chunks. Each chunk has a type (4-byte name like IHDR, IDAT, tEXt), a length, data, and a CRC checksum. pngcheck reads every chunk in order, validates the CRC, checks that required chunks are present in the right order, and reports anything unexpected.

The basic output looks like this:

$ pngcheck challenge.png
OK: challenge.png (800x600, 24-bit RGB, non-interlaced, 92.3%).

And verbose output — which is what you actually want in CTF — looks like this:

$ pngcheck -v challenge.png
File: challenge.png (153847 bytes)
  chunk IHDR at offset 0x0000c, length 13
    800 x 600 image, 24-bit RGB, non-interlaced
  chunk tEXt at offset 0x00025, length 36, keyword: Comment
  chunk IDAT at offset 0x00057, length 8192 (OK)
  chunk IDAT at offset 0x02065, length 8192 (OK)
  chunk IEND at offset 0x25819, length 0
No errors detected in challenge.png (5 chunks, 92.3% compression).

What pngcheck cannot do

This is the part beginners miss. pngcheck is a validator and inspector — it is not an extractor or a decoder. It will tell you that a tEXt chunk exists with keyword "Comment," but it won't show you the content of that comment in basic mode. It will tell you there's data after the IEND chunk, but it won't extract it. It validates structure; everything else needs another tool.

Task	pngcheck can do it?	Use this instead
Find broken CRC	✅ Yes	—
List all chunks and offsets	✅ Yes	—
Detect extra data after IEND	✅ Yes	—
Extract hidden text from tEXt chunks	⚠️ Partial (shows keyword only)	`strings`, `exiftool`
Detect LSB steganography	❌ No	`zsteg`
Extract embedded files	❌ No	`binwalk -e`
Fix broken CRC	❌ No	hex editor + manual CRC calculation
Repair corrupted IHDR dimensions	❌ No	hex editor + `pngcheck` to verify fix

When to Use pngcheck in CTF

Problem description keywords that should trigger pngcheck

I've developed a reflex: if a PNG challenge mentions any of these, pngcheck runs first before anything else:

"The image is corrupted" or "won't open"
"Something is wrong with the file"
"Check the structure" or "check the chunks"
"The file passes validation but something is off"
Any hint involving CRC, chunk, header, or IHDR

pngcheck vs zsteg vs binwalk — When to Use Which

The trap I fell into on Corrupted File — and then again on two other challenges before I finally learned — was running steganography tools on a PNG that had a structural problem. My reasoning at the time: "It's a PNG challenge, so it's probably steganography." That assumption is wrong about half the time. Here's the decision logic I've built since then:

Use pngcheck when: the file won't open, the challenge mentions "corruption," "chunks," or "structure," or you want to enumerate what chunks exist before doing anything else. pngcheck answers the question: is this file structurally valid?

Use zsteg when: pngcheck reports no errors and the image opens normally. zsteg checks for LSB-encoded data hidden in pixel channels — it operates entirely at the pixel level and doesn't care about chunk structure. If pngcheck says the file is clean, zsteg is your next move.

Use binwalk when: you suspect an entirely different file is embedded somewhere inside the PNG, or when pngcheck reports extra data after IEND and you want to extract it cleanly. binwalk signature-scans the raw bytes regardless of format.

The decision order that works for me: pngcheck -fvp first, always. If it passes → zsteg. If it fails with extra data → binwalk -e. If it fails with CRC → hex editor to patch. This sequence alone has saved me from countless Rabbit Holes. (For a deeper look at binwalk, see CTF Forensics: How to Use binwalk to Extract Hidden Files.)

Basic Usage With Thinking

Step 1 — Basic validation: is it broken at all?

$ pngcheck challenge.png
CRC error in chunk IHDR (computed 4a3f2c1b, expected 00000000)
ERRORS DETECTED in challenge.png

If this returns an error, you have a structural problem. The chunk name tells you where to look. IHDR error = broken header. IDAT error = broken image data. CRC mismatch = someone modified a byte somewhere. The next question is whether it was intentional (challenge design) or accidental (corrupted file).

Step 2 — Verbose output: read every chunk

$ pngcheck -v challenge.png

This is the command I run on every PNG challenge now, even before checking if it opens. The verbose output shows chunk names, offsets, lengths, and CRC status. I'm looking for:

Any chunk with a CRC error
Non-standard chunk names (anything that isn't IHDR/IDAT/IEND/tEXt/zTXt/gAMA/etc.)
Chunks in wrong order (IDAT before IHDR is invalid)
Content after IEND

Step 3 — Maximum detail: zlib and compression info

$ pngcheck -fvp challenge.png

The -f flag forces pngcheck to continue checking even after errors (useful when multiple chunks are broken). The -p flag prints the contents of non-critical chunks including text. This is how I found a base64-encoded flag sitting in a tEXt chunk with keyword "Author" — the image opened perfectly, the flag was in plain sight in the chunk data, and I'd wasted 20 minutes on pixel-level steg before checking this.

The Three Most Common CTF Scenarios

Scenario 1: Broken CRC — The Most Common Trap

A challenge author modifies a chunk's data without recalculating the CRC. pngcheck catches it immediately:

$ pngcheck -v challenge.png
  chunk IHDR at offset 0x0000c, length 13
    800 x 600 image, 24-bit RGB, non-interlaced
CRC error in chunk IHDR (computed 4a3f2c1b, expected 1a2b3c4d)
ERRORS DETECTED in challenge.png

The CRC mismatch means the IHDR data was modified after the CRC was set. In CTF, this almost always means the image dimensions were changed — the real dimensions were replaced with smaller values to crop out the hidden content. The flag is in the part of the image that was "hidden" by reducing the reported height or width.

To fix it: find the correct CRC value for the real IHDR data, then patch the file. Here's the Python approach I use:

import struct, zlib

with open("challenge.png", "rb") as f:
    data = f.read()

# IHDR chunk data is at bytes 12-28 (after 8-byte signature + 4-byte length + 4-byte type)
ihdr_data = data[12:29]  # 4 (length) + 4 (IHDR) + 13 (data) = offset 12 to 28
chunk_type_and_data = data[16:29]  # just "IHDR" + 13 bytes of data

correct_crc = zlib.crc32(chunk_type_and_data) & 0xFFFFFFFF
print(f"Correct CRC: {correct_crc:#010x}")

# Patch: replace bytes 29-33 with correct CRC
patched = data[:29] + struct.pack(">I", correct_crc) + data[33:]
with open("fixed.png", "wb") as f:
    f.write(patched)

After patching, run pngcheck fixed.png to confirm it passes, then open the image. If the dimensions were manipulated, the fixed file will render at the real size and reveal the hidden area. This pattern is so common in picoCTF and beginner CTFs that I now check for dimension mismatches as the first instinct whenever I see an IHDR CRC error.

Scenario 2: Hidden Custom Chunks

PNG allows custom (ancillary) chunks. They're valid PNG — most image viewers ignore unknown chunks silently. pngcheck lists them:

$ pngcheck -v challenge.png
  chunk IHDR at offset 0x0000c, length 13
  chunk IDAT at offset 0x00025, length 8192 (OK)
  chunk IEND at offset 0x25801, length 0
  chunk flAg at offset 0x25815, length 42
    (unknown ancillary chunk)
No errors detected in challenge.png (4 chunks).

That flAg chunk after IEND is not standard. The data inside it is the flag. pngcheck found it in one command. Without it, I'd be running steganography tools on an image that wasn't hiding anything in its pixels at all.

Scenario 3: Data Appended After IEND

The IEND chunk is supposed to be the last chunk in a PNG. Data after it is technically invalid, but most image viewers load the image anyway and ignore the trailing bytes. pngcheck flags it:

$ pngcheck challenge.png
invalid chunk name "" (00 00 00 00)
ERRORS DETECTED in challenge.png

Or with verbose:

  chunk IEND at offset 0x25801, length 0
additional data after IEND chunk

From the offset of IEND, you can calculate exactly where the appended data starts and extract it with dd or binwalk.

Common Mistakes and Rabbit Holes

The Corrupted File mistake was the first one. The second was a different challenge where pngcheck reported "No errors detected" — so I assumed I'd checked everything and moved to pixel-level steganography. I spent another 20 minutes on zsteg before going back and running pngcheck -fvp. The -p flag I'd skipped revealed a tEXt chunk with keyword "flag" containing a base64 string. It was sitting there in plain text the whole time. The file was clean structurally — the data was just hidden in a chunk I hadn't looked at.

The third mistake: I saw an IHDR CRC error, correctly identified that dimensions had been manipulated, patched the CRC — and then stopped. The image rendered at the new larger size, but I didn't look at what was in the newly revealed area carefully enough. The flag was written in white text on a white background in the bottom 50 pixels that had been hidden. I would have seen it immediately if I'd opened the image in a tool that let me invert colors. Lesson: when you fix a CRC and the image changes size, the newly revealed area is where to look first.

Mistake	What happens	How to avoid it
Running steganography tools on a structurally broken PNG	Tools either fail or give garbage output	Always run `pngcheck -v` first; fix structure before any steg analysis
Stopping at "No errors detected" without `-p`	Miss flag stored in tEXt chunk content	Always use `-fvp` — "no errors" doesn't mean "nothing hidden"
Fixing CRC without examining what changed	Fix the structure but miss the actual clue in the revealed area	After patching, look at the newly visible area of the image first
Ignoring ancillary chunk names	Miss flag stored in custom chunk like `flAg`	Read every chunk name in verbose output; unusual names are the challenge

Full Trial Process Table

Step	Action	Command	Result	Decision
1	Open in image viewer	—	❌ Won't open / blank	Structural problem suspected
2	Basic pngcheck	`pngcheck challenge.png`	❌ CRC error in IHDR	IHDR was modified
3	Verbose pngcheck	`pngcheck -v challenge.png`	✅ Offset + expected CRC shown	Dimensions likely manipulated
4	Check IHDR bytes in hex editor	hex editor at offset 0x10	✅ Width/height values confirmed wrong	Restore real dimensions
5	Recalculate CRC and patch	Python CRC32 + hex editor	✅ pngcheck now passes	Image opens at correct dimensions
6	Full verbose check on fixed file	`pngcheck -fvp fixed.png`	✅ Flag visible in tEXt chunk	Challenge solved

Command Reference

Command	Purpose	When to Use	Notes
`pngcheck file.png`	Basic validation	Quick first check	Shows pass/fail only
`pngcheck -v file.png`	Verbose chunk listing	Always, after basic check	Shows all chunk names, offsets, CRC status
`pngcheck -fvp file.png`	Full detail including text chunk contents	When looking for hidden data in chunks	-f forces continuation past errors
`pngcheck -c file.png`	Show chunk names only	Quick structural scan	Less detail than -v
`pngcheck -t file.png`	Print tEXt/zTXt chunk content	When verbose output shows text chunks	Useful for reading hidden comments

Beginner Tips

My personal pngcheck workflow for every PNG challenge

Run pngcheck -fvp challenge.png immediately — even before trying to open the file
Read every line of output. Non-standard chunk names are red flags
If there's a CRC error in IHDR, check the dimensions with a hex editor before doing anything else
If it passes cleanly, note any tEXt, zTXt, or iTXt chunks — extract their content
Check for data after IEND
Only switch to steganography tools (zsteg, stegsolve) after structural analysis is complete

Installing pngcheck

# Debian/Ubuntu/Kali

sudo apt install pngcheck

  
  
  macOS


brew install pngcheck

What You Learn From Using pngcheck

If you want to go further with the pattern this article teaches — validate structure before running analysis tools — the same mindset applies to disk images with mount and mmls, to ZIP archives with zip2john, and to PDFs with pdfdumper. Every binary format has a structure validator. Find it before running extraction tools.

Using pngcheck teaches you to read binary file structure before running tools. The PNG chunk format is one of the clearest examples of how a file format works internally — fixed headers, typed chunks, CRC integrity checks, a defined terminator. Once you understand why pngcheck exists and what it's validating, you start applying the same thinking to every binary challenge: what does the spec say this file should contain, and what does this specific file actually contain?

That gap between spec and reality is where CTF flags live. pngcheck is the tool that measures that gap for PNG files.

In real-world forensics, the same principle applies. Investigators validate file format integrity to detect tampering — a modified PNG with a recalculated CRC might look valid to an image viewer but will show the modification timestamp inconsistency at the chunk level. CTF PNG challenges are teaching you actual forensic thinking, not just CTF tricks.

Scan Surprise picoCTF Writeup

rudy_candy — Mon, 20 Apr 2026 17:50:26 +0000

picoCTF forensics challenges come in all shapes, but Scan Surprise from the General Skills category is one where the difficulty isn't the technique — it's knowing which tool exists. I solved this in under two minutes once I figured that out, but getting there took longer than I'd like to admit.

The Challenge

The challenge gives you a ZIP file. Unzip it and you get a flag.png. Open it and you're looking at a QR code.

$ unzip challenge.zip
Archive:  challenge.zip
   creating: home/ctf-player/drop-in/
 extracting: home/ctf-player/drop-in/flag.png

Okay, it's a QR code. First instinct: pull out my phone and scan it. That works — phone cameras read QR codes fine. But in a CTF environment where you're working in a terminal, there's a cleaner way, and figuring that out is the whole point of this challenge.

The Part Where I Wasted Time

I knew QR codes existed as a challenge type in CTF forensics, but I didn't know there was a dedicated command-line decoder for them. My first thought was to write a Python script using opencv or pyzbar. I started down that path:

# What I tried first (unnecessary)
pip install pyzbar
pip install Pillow

# Then started writing:
from pyzbar.pyzbar import decode
from PIL import Image
...

A few minutes in, I stopped and searched for "qr code cli linux" — and immediately found zbarimg. It's a standalone command-line tool that reads QR codes and barcodes from image files directly. No Python, no script, no library imports needed.

That's the actual "surprise" in this challenge: there's already a tool for this. Once you know zbarimg exists, the challenge collapses into a single command.

Installing zbarimg

If you don't have it already:

# Debian/Ubuntu (including picoCTF's webshell environment)
sudo apt install zbar-tools

# Verify it's working
zbarimg --version

The package is zbar-tools, not zbarimg — that's the command name, not the package. This tripped me up the first time I tried to install it.

The Solution

$ cd home/ctf-player/drop-in/
$ zbarimg flag.png
QR-Code:picoCTF{p33k_@\_b00\_3f7cf1ae}
scanned 1 barcode symbols from 1 images in 0 seconds

Flag: picoCTF{p33k_@_b00_3f7cf1ae}

The flag text — p33k_@_b00 — is leet speak for "peek-a-boo." The challenge name "Scan Surprise" is a nod to that. Small detail, but it made me smile when I noticed it.

What This Challenge Is Actually Testing

Scan Surprise isn't testing your knowledge of QR code internals or image processing. It's testing tool awareness — specifically, whether you know that zbarimg exists.

This comes up more than you'd think in CTF forensics. A lot of time gets lost not because the technique is hard, but because competitors don't know a purpose-built tool exists and end up writing scripts from scratch. Knowing the toolbox matters as much as knowing the theory.

Why not just use a phone camera? In a competition, you want reproducible, copy-pasteable output in your terminal — not a screenshot of your phone screen. zbarimg gives you that. It also becomes essential when challenges deliberately break QR codes in ways that confuse phone cameras but can be fixed with preprocessing.

What Harder Versions of This Challenge Look Like

Scan Surprise is the baseline — a clean QR code that zbarimg reads without any preprocessing. Once you've seen this pattern, you'll encounter versions where it's deliberately harder:

Inverted colors — the QR code has white modules on a black background. zbarimg returns "0 barcodes" because the ISO standard assumes dark-on-light. Fix: convert -negate before scanning.
Low resolution — the image is too small for the decoder to reliably parse. Fix: upscale with convert -resize using -filter point to keep edges sharp.
QR code inside a video — a QR code appears in a frame of a video file. Fix: extract frames with ffmpeg, then run zbarimg on the frames.

In all of those cases, the tool is still zbarimg — you just have to preprocess the image first. Scan Surprise establishes the foundation; the harder variants are the same workflow with an extra step in front.

CTF Audio Challenges: A Practical SoX Combat Guide

rudy_candy — Mon, 20 Apr 2026 17:50:23 +0000

― Decision Log: Turning an Inaudible WAV into a Flag ―

Facing the Problem: Why I Judged This Audio "Meaningless to Play"

First Impression of the Distributed Audio File (CTF Context)

It was a Saturday evening CTF. The problem title was "Silent Message" and a single file was attached: message.wav.

I downloaded it, double-clicked. Windows Media Player opened. Hit play.

Static. Pure white noise for about 5 seconds, then silence.

My first thought: "Corrupted file?" But this is CTF. Nothing is ever corrupted by accident. I closed the player and stared at the filename for a moment.

In that instant, I made a decision: " Playing this normally won't get me anywhere."

Why could I make that judgment so quickly? Because I'd wasted 40 minutes on a similar problem two months earlier, listening to static on repeat with headphones, convinced I was "missing something subtle." I wasn't. The information was just stored in a completely different dimension.

The Basis for Immediately Discarding the "Just Listen" Approach

Here's what I knew from the problem context:

Problem category : Listed under "Forensics" not "Audio Analysis"
File size : 441KB for 5 seconds—that's suspiciously standard (44100Hz × 2 bytes × 1 channel × 5 sec)
Problem description : "The message is there, you just need to hear it differently"

That last line was the tell. Not "listen carefully" but "hear it differently." In CTF language, that's code for: "The playback parameters are wrong."

I've learned to read these hints. When a problem says:

"Listen carefully" → Likely steganography or obscured speech
"Hear it differently" → Parameter manipulation needed
"Something's off" → Structural problem with the file

This was clearly the second type.

Initial Hypotheses I Formed at This Point

Standing at the starting line, I had three hypotheses:

Hypothesis 1: Sampling rate mismatch The file header claims one rate, but the data was recorded at another. Classic CTF trick. If recorded at 22050Hz but labeled as 44100Hz, it would play at double speed—unintelligible squeaks.

Hypothesis 2: Channel-based hiding Maybe it's stereo and one channel is empty noise while the other has data. Or left/right channels need to be XORed together.

Hypothesis 3: Frequency domain information The "sound" might be meaningless, but a spectrogram could reveal text or images.

I needed to test these fast. But which tool?

First Approach and Failure: Why I Didn't Use SoX

Why I Considered Other Tools (Audacity / ffmpeg) First

My initial instinct was Audacity. I'd used it before, knew where the menus were, and most importantly: I could see what I was doing.

For Hypothesis 3 (spectrogram), Audacity was the obvious choice. I opened the file.

The waveform appeared—flat line with occasional noise spikes. I switched to spectrogram view (Ctrl+Shift+Y in my muscle memory).

Nothing. Just uniform noise across all frequencies. No hidden text, no patterns, no images.

Okay, Hypothesis 3 out. But this took 2 minutes including load time.

For Hypotheses 1 and 2, I could use Audacity's effect menus:

Effect → Change Speed
Tracks → Stereo Track to Mono
Effect → Equalize

But here's where I hesitated. To test Hypothesis 1 properly, I'd need to try multiple sampling rates: 22050, 16000, 11025, maybe 8000. In Audacity, that's:

Effect → Change Speed → Calculate ratio → Apply
Listen
Undo
Repeat with different ratio

Each cycle: 20-30 seconds.

I sat there, cursor hovering over the Effect menu, and thought: "There has to be a faster way."

The Point Where I Judged "This Isn't It"

I tried one speed change in Audacity: 0.5x (simulating if the file was actually 22050Hz).

Result: Slow static. Still meaningless.

The problem wasn't that Audacity couldn't do it. The problem was the feedback loop was too slow. Each test required:

Menu navigation
Parameter input via dialog box
Processing time (even if short)
Manual playback
Mental note-taking of what I tried

I needed to test maybe 10 different configurations. At 30 seconds per test, that's 5 minutes minimum—and that's if I don't get lost or forget what I already tried.

I closed Audacity.

What Would Have Happened If I Hadn't Chosen SoX Here

Looking back, if I'd stuck with Audacity, one of two things would have happened:

Scenario A: I 'd have solved it, but slowly Eventually, I'd have hit the right combination and heard the flag. But it might have taken 15-20 minutes instead of the 3 minutes it actually took with SoX.

Scenario B: I 'd have given up More likely, after trying 3-4 combinations manually, I'd have convinced myself "it's not a sampling rate problem" and moved to a different hypothesis. Wrong direction, wasted time.

The danger with GUI tools in CTF isn't that they can't solve problems—it's that they make you give up on correct hypotheses too early because the iteration cost is too high.

The Turning Point: The Decisive Condition That Made Me Deploy SoX

The CTF-Specific Checklist: "When These Conditions Align, Use SoX"

I've developed a mental checklist over time. When I can tick 3+ boxes, I reach for SoX:

✅ Problem hints at parameter manipulation (sampling rate, speed, channels) ✅ Need to test multiple values systematically ✅ GUI tool feedback loop feels too slow ✅ File format is standard (WAV, not some obscure codec) ✅ Time pressure (other problems to solve, limited CTF duration)

This problem hit all five.

The moment I realized "I need to try 5+ sampling rates quickly" was the moment I decided: SoX.

Why I Abandoned GUI and Chose CLI

Here's the honest truth: I don't love command-line tools. GUIs are comfortable. You can see your options, click around, explore.

But in CTF, comfort is the enemy of speed.

With SoX, I could write:

bash

for rate in 8000 11025 16000 22050 32000 44100; do
  sox message.wav -r $rate "test_${rate}.wav"
done

Six files generated in under 3 seconds. Then I could just play them all:

bash

for f in test_*.wav; do
  echo "Playing $f"
  play "$f"
done

Linear playback, no menu navigation, no remembering what I tried. The command history is my lab notebook.

This is why I chose CLI: not because it 's better at audio processing, but because it's better at rapid experimentation.

Misconceptions and Anxiety at First Deployment

That said, I wasn't confident.

The first time I used SoX in a CTF (different problem, months earlier), I spent 10 minutes fighting with it because I didn't understand the option syntax. I kept trying:

bash

sox input.wav output.wav -r 22050

Nothing changed. No error messages, just… no effect. I thought SoX was broken or I had the wrong version installed.

Turns out, the -r option has to come before the output filename:

bash

sox input.wav -r 22050 output.wav

This kind of thing—option ordering, global vs. effect syntax—was completely non-obvious to me as a beginner. The man page didn't help; it's comprehensive but overwhelming.

So even as I decided "SoX is the right tool," part of me was thinking: "Am I going to waste 15 minutes debugging syntax again?"

Where I Actually Got Stuck: Traps Every SoX Beginner Steps On

The "Cognitive Mismatch" That Happened on First Operation

I created my test files with the for-loop above. Played test_22050.wav.

Clear human voice. Success on the second try.

But here's the thing—I almost dismissed it.

The voice said: "The password is echo charlie tango…"

I thought: "Wait, that's not a flag. Flags are flag{...} format."

I started to move on to the next test file, then stopped. Re-read the problem description: "The message is there."

Not "the flag." The message.

This was a two-stage problem. The audio gives you a password, you use that password to decrypt something else (there was a .enc file I'd ignored).

The trap : I was so focused on "find the flag" that I almost missed "find the message." SoX did exactly what it was supposed to—I almost threw away the correct answer because my mental model was wrong.

This happens more than I'd like to admit. The tool works; my assumptions don't.

Why Changing Options Didn't Change Results

Earlier in my SoX learning curve (different problem), I tried:

bash

sox input.wav output.wav rate 16000

Played output.wav. No change.

Tried again:

bash

sox input.wav output.wav rate 8000

Still no change. I checked file sizes—they were different, so something happened. But when I played them, identical to the original.

I was mystified for 20 minutes.

The problem: I was using rate as an effect, which does sample rate conversion (resampling the existing data). What I actually wanted was to reinterpret the existing samples at a different rate, which requires the -r option:

bash

sox input.wav -r 16000 output.wav

The lesson : SoX has two philosophies:

Global options (-r, -c): "Interpret the data this way"
Effects (rate, channels): "Transform the data"

For CTF sampling rate tricks, you almost always want global options, not effects. But if you don't know this distinction, you'll burn time on operations that do nothing useful.

Operations I Should Have Abandoned at This Point

In that earlier problem where rate wasn't working, I tried:

Different rate values (8000, 11025, 16000…)
Adding quality options (rate -h, rate -m)
Checking if dither affected it
Reading forums about sample rate conversion algorithms

None of this mattered because I was using the wrong approach entirely.

The abandonment rule I developed : If 3 attempts with parameter variations don't change the perceptible output, it's not a parameter problem—it's a conceptual problem. Stop tweaking, start reading.

In this case, 5 minutes with the man page (searching for "sample rate") would have saved me 15 minutes of flailing.

What Worked / What Disappointed (Combat Comparison)

Settings That Worked: Why This Parameter Hit Hard

For the "Silent Message" problem, the winning command was:

bash

sox message.wav -r 22050 output.wav

Why did this work?

The file header claimed 44100Hz, but the actual recording was done at 22050Hz. When played as 44100Hz, it ran at 2x speed—too fast to understand, sounded like noise.

Re-interpreting as 22050Hz slowed it to the correct speed.

But here's the critical part: I didn 't just get lucky. The file size was the tell:

bash

ls -lh message.wav
# 441000 bytes

441000 bytes = 220500 samples × 2 bytes/sample (16-bit) 220500 samples at 44100Hz = 5 seconds 220500 samples at 22050Hz = 10 seconds

The problem description said nothing about file length, but I timed the audio: 5 seconds of noise. If the hidden message was "normal speech speed," it probably needed more than 5 seconds to say anything meaningful.

So 22050Hz (doubling the duration to 10 seconds) was a strong hypothesis.

Differences in "Appearance and Sound" When Changing Values

I made a systematic test:

bash

for rate in 11025 16000 22050 32000 44100 88200; do
  sox message.wav -r $rate "test_${rate}.wav"
  echo "Testing ${rate}Hz..."
  play "test_${rate}.wav" 2>/dev/null
  sleep 1
done

Results:

11025Hz : Very slow, deep voice, but comprehensible words
16000Hz : Slow, slightly lower pitch, also comprehensible
22050Hz : Normal speech speed—clear winner
32000Hz : Too fast, words blur
44100Hz : Original—unintelligible
88200Hz : Extremely fast squeaks

The pattern was obvious. Below 22050Hz, I could understand the words but the speech was unnaturally slow. Above 22050Hz, too fast. At 22050Hz exactly, natural cadence.

This is why systematic testing matters. If I'd only tried 16000Hz, I might have thought "close enough" and missed subtle details in the message.

Settings I Expected to Work but Did Nothing

In an earlier problem, I was convinced the trick was channel manipulation. The file was stereo, so I tried:

bash

# Extract left channel
sox stereo.wav left.wav remix 1

# Extract right channel  
sox stereo.wav right.wav remix 2

# Mix both channels
sox stereo.wav -c 1 mono.wav

```

Played all three. All sounded identical—just noise.

I wasted 10 minutes trying different channel operations: swapping left/right, inverting one channel, isolating frequency bands per channel.

Nothing.

Eventually checked the file with `soxi`:
```

Channels: 1

It was mono the whole time. The file extension was .wav and I assumed stereo because many WAV files are. I never verified.

The lesson : soxi first, assumptions later. One command (soxi input.wav) would have saved me those 10 minutes.

Rabbit Hole Chronicle: Dangerous Forks in This Audio Problem

The Trap of Drowning Time in Spectrograms

Even after solving "Silent Message" with sampling rate changes, I felt uneasy. "That was too easy," I thought. "Maybe there's a second flag hidden in the spectrogram?"

I generated one:

bash

sox message.wav -n spectrogram -o spec.png

Opened the image. Stared at it for 5 minutes, looking for patterns.

Nothing obvious, but I zoomed in. Enhanced contrast in GIMP. Adjusted gamma. Rotated 90 degrees (I've seen upside-down text before).

15 minutes gone.

Then I snapped out of it. The problem was marked as 100 points—easy tier. If there were two flags, it would be marked higher. I was inventing complexity that wasn't there.

The psychology : After solving a problem "too easily," your brain invents reasons to doubt the solution. Especially in CTF, where you're trained to expect tricks within tricks.

The fix : Check the problem's point value. Check if anyone else has solved it (if scoreboards are visible). If 20 people solved it in 5 minutes, you're probably done. Move on.

The Psychology of Continuing Noise Reduction

In a different problem (not "Silent Message"), I had an audio file with voice buried under noise. I tried:

bash

sox noisy.wav clean.wav noisered profile.prof 0.21

It helped. The voice became slightly clearer.

So I thought: "What if I do it again?"

bash

sox clean.wav cleaner.wav noisered profile.prof 0.21

And again:

bash

sox cleaner.wav cleanest.wav noisered profile.prof 0.21

By the third iteration, the "voice" was unrecognizable. I'd removed so much signal along with the noise that the message was destroyed.

But I kept going. "Maybe one more time…"

Why? Because each iteration showed some change. The file sounded different. My brain interpreted "different" as "progress."

It wasn't progress. It was destruction.

The escape : Set a rule before starting: "I'll try this effect twice at most. If it doesn't clearly help by attempt two, abandon it." Write the rule down. Stick to it.

The Moment When Continuing to Use SoX Becomes the Failure

"Silent Message" was perfect for SoX. But I've had problems where SoX was the wrong tool and I didn't realize until I'd wasted 30 minutes.

Example: A problem with an MP3 file that had metadata steganography—flag hidden in ID3 tags, not in the audio data itself.

I spent ages trying:

bash

sox hidden.mp3 -r 22050 test.wav
sox hidden.mp3 output.wav reverse
sox hidden.mp3 output.wav speed 0.5

Nothing worked because I was operating on the wrong layer. SoX processes audio data. Metadata isn't audio data.

The solution was:

bash

ffmpeg -i hidden.mp3
# (Shows metadata in output)

bash

exiftool hidden.mp3

The recognition point : If you've tried 5+ different SoX operations across different categories (sampling rate, channels, speed, effects) and nothing changes the perceptible output, the problem isn't in the audio domain. It's structural, metadata-based, or you're completely off-track.

That's when you stop using SoX and reassess.

Thought Progression to Flag Identification (Reproducible Search Order)

Hypothesis → Operation → Result → Next Hypothesis

Here's the mental flowchart I followed for "Silent Message":

Initial state : WAV file, plays as static

Hypothesis 1 : "Static = high-frequency noise, maybe lowpass filter helps"

bash

sox message.wav filtered.wav lowpass 4000
play filtered.wav

Result : Still static, just quieter Judgment : Wrong direction, abandon lowpass approach

Hypothesis 2 : "File metadata lies about sampling rate"

bash

soxi message.wav
# Sample Rate: 44100
# Duration: 5 seconds

File size: 441KB ≈ 220500 samples Reasoning : 5 seconds feels short for a message. Try reinterpreting as 22050Hz → 10 seconds

bash

sox message.wav -r 22050 output.wav
play output.wav

Result : Clear voice! Judgment : Hypothesis confirmed, proceed to decode message

Hypothesis 3 : (Not needed—already solved)

Total time: Under 3 minutes.

Key principle : Each hypothesis is falsifiable. "Lowpass might help" → test → no → discard. Don't dwell. Move to next hypothesis.

Confirmation Judgment Derived from Flag Format

The voice said: "The password is echo charlie tango foxtrot bravo alpha two zero two four"

I transcribed: ectfba2024

But the problem said "submit the flag." Flags have format flag{...} or similar.

Checked problem description again: "The flag is obtained by using the password to decrypt the file."

There was an attached secret.enc. I tried:

bash

openssl enc -d -aes-256-cbc -in secret.enc -out secret.txt -k ectfba2024

Output: flag{sampling_rate_lies}

That 's the flag.

The confirmation process :

Audio gives "password" → Not directly the flag
Problem gives encrypted file → Flag is inside
Decrypt with password → Obtain actual flag
Flag matches expected format → Confirmed

If I'd submitted ectfba2024 directly, I'd have gotten "Wrong answer." Understanding the flag submission format and multi-stage problem structure was as critical as solving the audio part.

Why Deviating from This Order Leads to Getting Lost

I've seen people (including past-me) mess up by:

Mistake 1 : Trying everything simultaneously

Open Audacity, look at spectrogram
Run SoX sampling rate changes
Try steganography tools
Check metadata

Result: Information overload, can't track what worked

Mistake 2 : Not recording what you tried

"Wait, did I already try 16000Hz?"
"Was this the file before or after I applied the effect?"

Result: Repeated work, confusion

Mistake 3 : Ignoring problem context

Solve the audio to get ectfba2024
Submit it directly without reading "use it to decrypt"

Result: Correct step, wrong conclusion

The fix : Linear progression with documentation.

My actual terminal history for "Silent Message":

bash

# 1. Initial recon
file message.wav
soxi message.wav
play message.wav

# 2. First hypothesis - lowpass
sox message.wav filtered.wav lowpass 4000
play filtered.wav
# (nope)

# 3. Second hypothesis - sampling rate
sox message.wav -r 22050 output.wav
play output.wav
# (yes!)

# 4. Decrypt
openssl enc -d -aes-256-cbc -in secret.enc -out secret.txt -k ectfba2024
cat secret.txt
# flag{sampling_rate_lies}

```

Clean, linear, reproducible. That's how you avoid getting lost.

## Next Time I See Similar Conditions: Action Guidelines

### Decision Criteria Summary for Using SoX

I reach for SoX when:

1. **Problem hints suggest parameter tricks**
   - Keywords: "sounds wrong," "too fast," "can't hear," "hidden message"
   - File format: Standard WAV/FLAC, not exotic codecs

2. **Need systematic parameter exploration**
   - Test multiple sampling rates: 8k, 11k, 16k, 22k, 32k, 44k, 48k
   - Test channel operations: L/R split, mono conversion
   - Test time operations: reverse, speed changes

3. **Time is constrained**
   - Other unsolved problems waiting
   - GUI iteration feels too slow
   - Need to automate multiple tests

4. **Command-line environment available**
   - Can pipe outputs, use loops
   - Terminal history = automatic documentation

### Decision Line for Not Using / Abandoning Midway

I abandon SoX and switch tools when:

1. **5 different operations produce identical output**
   - Likely wrong problem domain
   - Switch to metadata tools (`exiftool`, `ffmpeg -i`)

2. **Visual inspection needed**
   - Need to see spectrogram clearly
   - Need to manually select waveform regions
   - Switch to Audacity

3. **Complex signal processing required**
   - FFT analysis, correlation, custom algorithms
   - Switch to Python (librosa, scipy)

4. **File format unsupported**
   - Exotic codecs, video with audio
   - Switch to ffmpeg for conversion first

### Timing for Switching to Other Tools

My typical workflow:
```

Start: SoX (3-5 minutes)
  ↓
Sampling rate, channels, speed, reverse → Any change?
  ↓ Yes                    ↓ No
Keep using SoX         Switch to Audacity
(refine parameters)    (visual inspection)
  ↓                        ↓
Flag found?            See patterns?
  ↓ Yes                   ↓ Yes              ↓ No
Submit              Process with       Switch to metadata
                    Python/SoX         or steganography tools

Time limits :

SoX phase: Max 5 minutes. If no progress, switch.
Audacity phase: Max 10 minutes for visual inspection.
If nothing after 15 minutes total on audio: Problem might not be audio-focused. Re-read problem description.

Example decision points :

Minute 2 : "Tried 6 sampling rates with SoX, heard voice at 22050Hz" → Stay with SoX, refine Minute 5 : "Tried sampling rates, channels, speed, reverse—all sound identical" → Switch to Audacity, check spectrogram Minute 15 : "Spectrogram shows nothing, SoX operations did nothing" → This isn't an audio problem. Check file metadata, steganography, encryption.

The key is having predetermined time boxes. Without them, you'll sink 45 minutes into one tool because "just one more thing to try…"

Conclusion

When I started doing CTF audio challenges, I thought success meant "finding the right tool." I'd see writeups that said "use SoX" or "use Audacity" and think: "Oh, I need to learn that tool better."

Wrong mindset.

Success isn't about tools—it's about decision timing. Knowing when to use SoX, when to abandon it, when to switch. The tool is just an instrument for testing hypotheses.

"Silent Message" taught me:

Decide fast : 30 seconds to judge if normal playback is viable
Test systematically : Loop through parameters, don't guess randomly
Recognize dead ends : 3-5 attempts with no change = wrong direction
Document as you go : Command history is your lab notebook
Know the win condition : Flag format, submission requirements

SoX isn't magic. It's just really good at one specific thing: rapidly converting audio files with different parameter interpretations. When that's what you need, nothing beats it. When it's not, you're just wasting time.

The real skill is knowing which situation you're in.

Now when I see an audio problem, I don't think "which tool should I use?" I think: "What's my hypothesis, and what's the fastest way to test it?"

Usually, that answer is SoX. But only if I'm asking the right question.

There's a specific kind of CTF frustration that comes from staring at a disk image and knowing the flag is in there, but having no idea where to even start looking. I hit that wall hard on a picoCTF forensics challenge — one of the "Disk, disk, sleuth!" variants — where I spent close to an hour trying every file-level tool I knew before someone in Discord mentioned fdisk and completely changed how I was thinking about the problem.

I had been approaching it all wrong. I was reaching for binwalk, strings, foremost — tools that look at content embedded inside files. But this challenge had a partition table , and the flag was sitting in a partition that no filesystem tool would touch because it was never mounted anywhere. The moment I ran fdisk -l disk.img and actually read the output — three partitions, one with a suspicious type ID I'd never seen before — I realized I'd been scanning the surface of the image while the answer was structured one layer deeper.

That's what this article is about. Not just the fdisk -l syntax — that takes thirty seconds to learn — but the mindset shift that makes fdisk genuinely useful in CTF forensics. Understanding partition boundaries, sector math, and why tools like Autopsy miss things that live in unallocated space is the difference between solving this class of challenges quickly and wandering through them for hours.

fdisk Syntax: The One Command That Actually Matters

Unlike dd, which has a handful of critical parameters to memorize, fdisk in CTF basically comes down to one command:

fdisk -l disk.img

The -l flag lists partition information: partition numbers, start and end sectors, total sector count, sector size, and filesystem type identifiers. Everything else you need for CTF work — the sector-to-byte math, the gap calculations, the dd extraction commands — flows from reading this output correctly.

Here's what typical output looks like on a CTF disk image:

$ fdisk -l disk.img
Disk disk.img: 100 MiB, 104857600 bytes, 204800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

Device      Boot  Start    End  Sectors  Size  Id  Type
disk.img1         2048   43007   40960   20M  83  Linux
disk.img2        43008  122879   79872   39M   7  HPFS/NTFS/exFAT
disk.img3       124928  204799   79872   39M  8e  Linux LVM

The fields that matter for CTF: Start (first sector of the partition), Sectors (total sector count), and Id (partition type code). Notice the gap between disk.img2 ending at 122879 and disk.img3 starting at 124928 — those 2048 unallocated sectors are 1MB of space that no filesystem tool will touch unless you're explicitly looking for it. Challenge authors love that gap.

The Sector-to-Byte Calculation (Do This Once, Do It Right)

Everything in fdisk output is in sectors. Everything in dd (the extraction tool you'll pair with fdisk) is configurable in whatever unit you choose. The simplest approach: set bs=512 in dd, and the sector values from fdisk map directly to skip and count without any multiplication.

# Extract partition 2 — sector values from fdisk map directly to dd parameters
$ dd if=disk.img of=partition2.img bs=512 skip=43008 count=79872

If you ever need raw byte offsets — for a hex editor or a tool that takes byte positions — the math is: byte offset = sector × 512. disk.img2 starts at sector 43008, which is byte 22,020,096. But in practice, I almost always use bs=512 and let the sector numbers do the work directly.

One Detail That Trips Up Beginners Every Time

When extracting with dd, the count parameter is the Sectors column from fdisk output — not End minus Start, and not the End value itself. fdisk gives you the total sector count directly in that column; use it. Using the End sector as count will extract from the wrong position entirely, and dd won't warn you — it'll just silently produce an incorrect image. Always double-check: count = Sectors column value.

Rabbit Hole: The Hour I Wasted Before Running fdisk

Here's exactly what I tried before reaching for fdisk — I want to be honest about this because I think it maps to what most beginners attempt:

$ file disk.img
disk.img: DOS/MBR boot record; partition 1 : ID=0x83, start-CHS (0x0,32,33),
end-CHS (0x14,223,19), startsector 2048, 40960 sectors; partition 2 : ID=0x07...
# Okay, partitions exist. Let me just mount it...

$ sudo mount -o loop disk.img /mnt/disk
mount: /mnt/disk: wrong fs type, bad option, bad superblock on /dev/loop0
# Mounting the raw image without an offset doesn't work on partitioned images.
# I spent 15 minutes trying different mount flags here.

$ strings disk.img | grep -i "flag\|ctf\|pico"
(no output)
# Flag was inside an unmounted filesystem, not raw ASCII in the image

$ binwalk disk.img

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             DOS/MBR boot record
1048576       0x100000        Linux EXT2 filesystem data
# Saw the EXT2 hit and tried extracting it with dd — got a partial image that
# mounted but only contained the first partition's content. Missed partition 3.

$ foremost -i disk.img -o output/
# 12 minutes later: recovered some JPEG files, none relevant
# foremost carved by signature without partition context — wrong tool here

$ sudo autopsy &
# Waited 8 minutes for the browser GUI
# Autopsy found files in partition 1 and 2 — nothing in partition 3
# It had silently skipped partition 3 due to the unrecognized type ID (0x8e)
# I didn't know that's what happened until much later

That Autopsy session was the specific failure point. Partition 3 had type ID 8e (Linux LVM), which in this challenge was a deliberate mislabel — the author set an unusual partition type to make standard tools skip over it while still keeping the actual content as a mountable ext2 filesystem. Autopsy didn't parse it as a recognized filesystem, reported it as empty, and I had no reason to dig further because Autopsy had "scanned everything."

The fix took about ninety seconds once I ran fdisk properly. Saw three partitions, noticed 8e was suspicious, extracted it with dd, ran file on the result — it came back as ext2. Mounted it. Flag was in /home/user/flag.txt. The entire challenge hinged on knowing that partition type IDs are just labels and can't be trusted.

Five CTF Patterns Where fdisk Is the Right Starting Point

After working through multiple forensics disk image challenges, the scenarios where fdisk matters fall into recognizable patterns. Here's what each looks like and where beginners typically get stuck:

Pattern 1: Partition Extraction with dd

The most common pattern. fdisk shows a partition with content; you extract it with dd and analyze the result. The calculation is straightforward but error-prone if you're rushing.

$ fdisk -l disk.img
...
Device      Boot  Start    End  Sectors  Size  Id  Type
disk.img1         2048   43007   40960   20M  83  Linux
disk.img2        43008  204799  161792   79M  83  Linux

# Extract partition 2: skip=Start, count=Sectors (not End)
$ dd if=disk.img of=part2.img bs=512 skip=43008 count=161792

$ file part2.img
part2.img: Linux rev 1.0 ext2 filesystem data

$ mkdir /tmp/mnt && sudo mount part2.img /tmp/mnt
$ ls /tmp/mnt
flag.txt  home/  lost+found/

The mistake I made early: confusing the End column with the count. End is the last sector number, not the total sector count. fdisk gives you the total directly in the Sectors column — that's your count value.

Pattern 2: Hidden or Mislabeled Partitions

CTF authors add partitions with misleading type IDs, or use unusual IDs that standard tools don't recognize and quietly skip. The tell is an unfamiliar type in the Type column — things like "Unknown", "W95 FAT32 (LBA)", or "Linux LVM" on an image that's clearly not a production server.

$ fdisk -l tricky.img
...
Device       Boot  Start    End  Sectors  Size  Id  Type
tricky.img1        2048   20479   18432    9M  83  Linux
tricky.img2       20480   40959   20480   10M  7f  Unknown

# Type 0x7f is unusual — extract and verify what's actually there
$ dd if=tricky.img of=hidden_part.img bs=512 skip=20480 count=20480

$ file hidden_part.img
hidden_part.img: Linux rev 1.0 ext2 filesystem data
# Despite the "Unknown" label — it's actually ext2

$ sudo mount hidden_part.img /tmp/hidden
$ find /tmp/hidden -name "flag*"
/tmp/hidden/secret/flag.txt

The rule I follow now: never trust the Type label. A partition's type ID is a single byte that anyone can set to anything. Always extract and run file on unknown or suspicious types before writing them off.

Pattern 3: Unallocated Space Between Partitions

Gaps between partition boundaries are invisible to filesystem tools — they don't belong to any partition — but they can contain deleted files, embedded data, or raw flag strings. Spot them by checking whether each partition's End+1 equals the next partition's Start.

$ fdisk -l gappy.img
...
Device       Boot  Start    End  Sectors  Size  Id  Type
gappy.img1         2048   20479   18432    9M  83  Linux
gappy.img2        24576  204799  180224   88M  83  Linux

# Gap: sectors 20480 to 24575 = 4096 sectors = 2MB of unallocated space
# That's not alignment padding — 2MB is a deliberate gap in CTF context

$ dd if=gappy.img of=gap.bin bs=512 skip=20480 count=4096

$ strings gap.bin | grep -i "flag\|ctf\|pico"
picoCTF{h1dd3n_1n_th3_g4p_a7b2c3}

Normal partition alignment padding is typically 2048 sectors (1MB) between sector 0 and the first partition. Gaps larger than that — especially gaps in the middle of the image — are almost always intentional in CTF challenges. Also check the tail: if the last partition ends well before the disk's total sector count, that trailing space is another standard hiding spot.

Pattern 4: Filesystem Identification for Targeted Analysis

Different partition types contain different kinds of artifacts. Knowing what you're dealing with before you start digging saves significant time. NTFS partitions have Windows event logs, USN journals, and alternate data streams. Linux ext2/3/4 partitions have .bash_history, shadow files, and syslog. Swap partitions sometimes contain memory fragments — including plaintext credentials or flag strings that were briefly loaded into RAM.

$ fdisk -l multi.img
...
Device      Boot  Start    End  Sectors  Size  Id  Type
multi.img1         2048   43007   40960   20M  83  Linux       # ext2/3/4
multi.img2        43008  122879   79872   39M   7  NTFS        # Windows filesystem
multi.img3       122880  143359   20480   10M  82  Linux swap  # memory fragments

# Swap partition: strings can find in-memory artifacts
$ dd if=multi.img of=swap.img bs=512 skip=122880 count=20480
$ strings swap.img | grep -i "password\|flag\|secret" | head -20

Swap partitions are an underrated source in CTF disk imaging challenges. I've found plaintext flags in swap regions on two separate challenges where the filesystem partitions had nothing — the flag had been used in a process that paged memory to swap before the image was captured.

Pattern 5: Corrupted or Malformed Partition Tables

Sometimes fdisk can't read the partition table cleanly — overlapping sectors, impossible values, a corrupted MBR signature. This is itself a clue: the challenge is about table forensics, not just extracting a known partition. When fdisk fails, switch to mmls from Sleuth Kit.

$ fdisk -l corrupted.img
GPT: not present
MBR: not present
# fdisk can't find a valid partition structure

# mmls is more tolerant of malformed tables
$ mmls corrupted.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   0000043007   0000040960   Linux (0x83)
003:  -------   0000043008   0000045055   0000002048   Unallocated
004:  000:001   0000045056   0000204799   0000159744   Unknown Type (0xcc)

mmls explicitly labels unallocated regions and parses tables that fdisk gives up on. The key difference: fdisk relies on the MBR/GPT signature being intact to even begin reading. mmls reads the raw sector data more defensively and will reconstruct partial partition entries even from a damaged table. The partition with type 0xcc was the payload in the challenge above — fdisk returned nothing, but mmls found it and gave me exact Start and Length values I could feed directly to dd. When fdisk says "no partition table found" on a file that file identifies as a boot record, switch to mmls immediately.

fdisk vs Other Tools: How I Actually Decide

fdisk reads partition tables. It doesn't carve files, parse filesystems, or recover deleted data — and reaching for it when those are your actual needs wastes time. Here's how I make the call in practice:

Situation	My First Choice	Why Not fdisk?
Disk image with unknown structure	fdisk -l	—
Corrupted or unreadable partition table	mmls (Sleuth Kit)	fdisk gives up on malformed tables; mmls keeps going and shows unallocated regions
Browse filesystem contents visually	Autopsy / sudo mount	fdisk doesn't open or navigate filesystems
Carve files without a filesystem	foremost or binwalk	fdisk only reads partition boundaries, not file signatures
Extract a specific partition	fdisk → then dd	fdisk identifies the boundaries; dd extracts — they're a matched pair
Detect unallocated gaps	fdisk -l (manual gap math)	mmls labels gaps explicitly if you want them surfaced automatically
NTFS-specific artifacts (ADS, USN journal)	Autopsy or ntfsinfo	fdisk identifies the partition type but can't read NTFS structures

The failure mode I keep seeing in beginners: running Autopsy directly on the raw disk image and trusting that it finds everything. Autopsy works at the filesystem level — it will find files in recognized partitions, but it silently skips partitions with unusual type IDs and won't surface anything in unallocated gaps. Run fdisk first, identify which partitions are worth investigating, then point Autopsy at the specific extracted images rather than the raw disk.

Full Trial Process Table

Step	Action	Command	Result	Why it failed / succeeded
1	File identification	file disk.img	DOS/MBR boot record	Confirmed it's a partitioned disk — useful, but told me nothing about what was inside each partition
2	Direct mount	sudo mount -o loop disk.img /mnt	mount: wrong fs type	Mounting the raw image without an offset doesn't work on partitioned images — wasted 15 minutes trying different flags
3	String search	strings disk.img	grep flag	No output
4	Auto-carve	foremost -i disk.img -o out/	JPEGs recovered, no flag	foremost uses file signatures without partition context — carved false positives from the wrong region
5	Autopsy full scan	autopsy (GUI)	Files in partitions 1–2, nothing in partition 3	Autopsy silently skipped partition 3 due to unrecognized type ID — I didn't know it had done this
6	fdisk scan	fdisk -l disk.img	Three partitions visible; type 0x8e on partition 3 looks suspicious	Turning point — saw the full partition layout for the first time
7	Extract partition 3	dd if=disk.img of=p3.img bs=512 skip=124928 count=79872	Clean image extracted	fdisk sector values mapped directly to dd skip/count — no calculation needed
8	Verify filesystem type	file p3.img	Linux rev 1.0 ext2 filesystem data	Despite the "Linux LVM" label from fdisk, it's actually ext2 — the partition ID was a deliberate mislabel
9	Mount and explore	sudo mount p3.img /tmp/p3 && ls /tmp/p3	flag.txt present in root	—
10	Read flag	cat /tmp/p3/flag.txt	picoCTF{…}	Should have run fdisk at step 1 — everything before step 6 was wasted time

Why Partition-Level Thinking Matters Beyond CTF

Partition tables exist below the filesystem layer — they're the first structure on any block storage device, before any filesystem driver gets involved. This is why forensic investigators care about them: data in unallocated sectors, between partitions, or in partitions that were never mounted still shows up in a raw partition table scan, even if every filesystem tool reports nothing found.

In real incident response, deleted partitions are a common evidence source. An attacker can delete a partition containing exfiltrated data or tooling, but the bytes remain on disk until overwritten. fdisk and mmls often detect the ghost of a former partition entry — the data may be recoverable even after the partition record is gone. CTF challenge authors use the same principle: they create data structures at the partition layer specifically because most beginners only look at the filesystem layer.

The insight that shifts how you think about disk forensics: a disk image is not a folder. It's a byte sequence with structure at multiple layers — the partition table at the outermost level, filesystems within each partition, individual file structures within those filesystems. Each layer can hide data from the others. fdisk gives you visibility into the outermost layer, which is precisely the one beginners tend to skip.

How I'd Solve It Faster Next Time

My first-three-minutes workflow for any disk image challenge now — hard-won from running the wrong tools in the wrong order too many times:

# Step 1: What kind of image is this?
file target.img

# Step 2: What partitions exist, and are any suspicious?
fdisk -l target.img
# Look for: unusual type IDs, gaps between partitions, trailing unallocated space

# Step 3: Note any gaps
# gap = next_Start - current_End - 1 (in sectors)
# If gap > 2048 sectors, extract it:
dd if=target.img of=gap.bin bs=512 skip=<end_of_prev_part+1> count=<gap_size>
strings gap.bin | grep -i "flag\|ctf"

# Step 4: Extract each partition that looks interesting
dd if=target.img of=partN.img bs=512 skip=<Start> count=<Sectors>

# Step 5: Verify what's actually in each extracted partition
file partN.img
# Don't trust the fdisk type label — verify with file every time

# Step 6: Mount or analyze
sudo mount partN.img /tmp/mnt
ls -la /tmp/mnt

I run fdisk -l before anything else now — before binwalk, before strings, before Autopsy. It takes two seconds and immediately tells me whether I'm dealing with a partitioned image (where the partition structure is the puzzle) or a raw binary (where I should switch to binwalk and dd). That decision used to cost me twenty minutes of trying the wrong tools. Now it costs two seconds.

One specific thing to watch: compare the total sector count at the top of fdisk output against the End sector of the last partition. If the last partition ends significantly before the total, that trailing space is another common hiding spot — extract it the same way you'd extract a gap.

binwalk in CTF: Spot False Positives Fast

rudy_candy — Mon, 20 Apr 2026 17:44:42 +0000

binwalk is a binary analysis tool that scans files for embedded signatures — ZIPs inside PNGs, compressed firmware blobs, appended archives. In CTF forensics it's usually one of the first tools you reach for. But the real skill isn't running it; it's reading the output correctly. While working on the "Digging for Treasure" challenge at BurnerCTF 2025, I ran binwalk and watched more than ten detections scroll across the screen. My first thought was "this is a goldmine." Thirty minutes later, when I realized every single one of them was a false positive, I learned firsthand just how dangerous it is to blindly trust tool output.

Rather than listing binwalk commands one by one, this article focuses on the noise problem you actually face in CTF scenarios and the decision-making process for finding the signal that matters.

Real Output from BurnerCTF 2025: Separating Noise from Signal

Here is the actual output from running binwalk on the "Digging for Treasure" challenge.

$ binwalk treasure.png

DECIMAL       HEXADECIMAL     DESCRIPTION
------------------------------------------------------------------------
0             0x0             PNG image, 1536 x 1024, 8-bit/color RGB, non-interlaced
3860          0xF14           Certificate in DER format (x509 v3), header length: 4, sequence length: 1573
5440          0x1540          Certificate in DER format (x509 v3), header length: 4, sequence length: 1746
7193          0x1C19          Certificate in DER format (x509 v3), header length: 4, sequence length: 1455
8688          0x21F0          Object signature in DER format (PKCS header length: 4, sequence length: 5983
8857          0x2299          Certificate in DER format (x509 v3), header length: 4, sequence length: 1573
10634         0x298A          Certificate in DER format (x509 v3), header length: 4, sequence length: 1716
12354         0x3042          Certificate in DER format (x509 v3), header length: 4, sequence length: 1421
15075         0x3AE3          Zlib compressed data, default compression
2706518       0x294C56        TIFF image data, big-endian, offset of first image directory: 8

At first glance, it looks like the PNG contains six DER certificates, zlib data, and an embedded TIFF. In reality, every detection from offset 3860 through 15075 was a false positive.

Why So Many DER Certificates Get Detected

PNG files store image data compressed with zlib inside IDAT chunks. Within that compressed binary data, patterns can appear that happen to match the magic bytes of a DER certificate (sequences starting with 30 82). Since binwalk determines file types through binary signature matching without considering context, it reports every byte sequence that looks certificate-like.

The two bytes of the DER sequence tag (0x30) and the length field (0x82) appear frequently in compressed data. This is the root cause of the false positive flood inside IDAT chunks.

Criteria for Finding Real Signals

In the output above, the only detection actually worth investigating was the last line: the TIFF at offset 0x294C56 (2,706,518 bytes). Here is the reasoning behind that call.

First, check the context of each offset. Detections clustered near the beginning of the file (within the range where IDAT chunks exist) are likely false positives inside compressed data. On the other hand, an isolated detection of a different format near the end of the file — close to the total file size — is likely data appended after the file's end.

Next, compare against the file size. Run ls -la treasure.png to check the file size and see whether 2,706,518 bytes corresponds to near the end of the file. If data exists beyond the PNG's native IEND chunk, it was clearly appended.

Also check the consistency of detected formats. If six DER certificates are detected in a row and they are densely packed within small offset intervals, you should assume binwalk is scanning through a single compressed data block.

The -e Option Trap: Avoiding Extraction Chaos

Using binwalk's extraction option -e dumps everything detected into an _extracted/ folder. But running it against output riddled with false positives generates a flood of useless files and turns the folder into a mess.

# A common mistake

$ binwalk -e treasure.png

  
  
  Result: _extracted/ gets filled with unwanted files


$ ls _extracted/treasure.png.extracted/

F14         F14.der

1540        1540.der

1C19        1C19.der

21F0        21F0.der

2299        2299.der

298A        298A.der

3042        3042.der

3AE3        3AE3.zlib

294C56.tiff

294C56

  
  
  Manual extraction from a specific offset using dd


  
  
  Extract the TIFF from offset 0x294C56 (2706518 bytes)


$ dd if=treasure.png bs=1 skip=2706518 of=extracted.tiff

  
  
  Or use binwalk's --dd option to extract only a specific type


$ binwalk --dd='tiff image:tiff' treasure.png

Core binwalk Commands and When to Use Them

# Scan a file for signatures

$ binwalk file.bin

  
  
  Detailed entropy analysis (-B)


$ binwalk -B file.bin

  
  
  Output an entropy graph (high-entropy regions = likely encrypted or compressed data)


$ binwalk -E file.bin

  
  
  Extract detected files (watch out for false positives)


$ binwalk -e file.bin

  
  
  Recursive extraction (re-scan extracted files)


$ binwalk -Me file.bin

  
  
  Search for a specific signature only


$ binwalk -R "\x50\x4b\x03\x04" file.bin   # Search for ZIP signature

  
  
  Scan a firmware image (common in CTF hardware/misc challenges)


$ binwalk firmware.bin

  
  
  Recursive extraction when the image contains filesystems like squashfs or cpio


$ binwalk -Me firmware.bin

How Magic Numbers and Binary Signatures Work

Understanding how binwalk identifies file types is key to spotting false positives. Most file formats have a fixed signature (magic number) at the start of the file. PNG, for example, uses 89 50 4E 47 0D 0A 1A 0A (\x89PNG\r\n\x1a\n), and ZIP uses 50 4B 03 04 (PK\x03\x04).

binwalk matches signature patterns from its internal database against every offset in a file using a sliding window. This approach is powerful, but in regions with byte sequences that look random — like compressed or encrypted data — coincidental matches happen all the time. In the case of DER format, the sequence tag 0x30 0x82 appears frequently in binary data that has nothing to do with certificates, and binwalk reports every single one of those matches.

When Not to Use binwalk: Choosing the Right Tool

If LSB steganography is suspected, use zsteg. The technique of hiding data in the least significant bits of PNG pixels cannot be detected by binwalk's signature scanning — binwalk found nothing on the "RED" picoCTF challenge where zsteg recovered the flag immediately. For metadata inspection, use exiftool; GPS coordinates, comment fields, and custom XMP tags are invisible to binwalk because they don't appear as binary signatures. To diagnose file corruption, reach for pngcheck or the file command first — running binwalk on a deliberately corrupted PNG often produces misleading output.

binwalk's full signature database and source are maintained at the ReFirmLabs/binwalk GitHub repository. The src/binwalk/magic/ directory lists every pattern binwalk scans for, which is useful when you need to understand why a specific false positive is being triggered.

binwalk vs foremost vs strings: Comparison Table

Situation	Recommended Tool	Reason
Suspected embedded file in a different format	binwalk -e	Signature scanning with automatic extraction
Appended data at the end of a file	binwalk (check offset) + dd	Identify the exact extraction point, then extract manually
Recovering files from a disk image	foremost	File carving that ignores filesystem structure
Searching for printable strings in a binary	strings	Fast search for flag strings or config values
Analyzing filesystem structure in firmware	binwalk -Me	Recursive extraction unpacks squashfs/cramfs
LSB steganography suspected	zsteg	binwalk does not detect bit-level manipulation of pixel data
Flag hidden in EXIF metadata	exiftool	Metadata fields do not appear as binary signatures

Practical binwalk Workflow for CTF

# Step 1: Start with the file command to get basic info

$ file challenge.png

  
  
  Step 2: Check the file size (you'll compare this against offsets later)


$ ls -la challenge.png

  
  
  Step 3: Scan with binwalk


$ binwalk challenge.png

  
  
  Step 4: Interpret the output


  
  
  - Focus on detections at offsets close to the file size


  
  
  - Be skeptical of DER/certificate detections clustered near the beginning


  
  
  - Prioritize isolated detections of a different format at a unique offset


  
  
  Step 5: Manually extract only from promising offsets


$ dd if=challenge.png bs=1 skip=2706518 of=candidate.tiff

  
  
  Step 6: Use strings to search for text if needed


$ strings candidate.tiff | grep -i "ctf|flag"

Tips for Reducing binwalk False Positives

Using entropy analysis (the -E option) lets you visually map high-entropy regions (compressed or encrypted data) within a file. Combining it with the strings command is also effective — if you spot file header strings like "JFIF", "Exif", or "PK", use those offsets as a starting point.

# Inspect bytes around offset 0x294C56

$ xxd challenge.png | grep -A 3 "00294c"

  
  
  Or use dd to check the bytes around that area


$ dd if=challenge.png bs=1 skip=2706510 count=32 | xxd

CTF Forensics Tools: The Ultimate Guide for Beginners

rudy_candy — Mon, 20 Apr 2026 17:39:36 +0000

When I first started picoCTF forensics challenges, I had a folder full of installed tools and no idea which one to open first. Every challenge felt like staring at a locked box with twenty keys on the table. The problem wasn't a lack of tools — it was not knowing the decision process behind picking the right one.

This page is what I wish had existed when I started. Not a list of tools with feature descriptions, but a map of when to reach for each one and — just as importantly — when to put it down and try something else.

Step Zero: Identify What You're Dealing With

Before touching any specialized tool, run these two commands on every unknown file:

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

$ xxd challenge.bin | head -5
00000000: 504b 0304 1400 0000 0800 ...  PK..........

file reads magic bytes and tells you the actual format regardless of the extension. xxd shows the raw hex so you can spot a corrupted header immediately. I've lost count of how many times a file named data.png turned out to be a ZIP or a disk image — the magic bytes 50 4B 03 04 (PK) are a dead giveaway for ZIP regardless of what the filename says.

If file says "data" or gives something unexpected, that's your first clue. See the Corrupted File writeup for a real example of this — the challenge handed me a PNG with a broken magic byte, and file was what made that obvious.

By File Type: Which Tool to Reach For

Disk Images (.img, .dd, raw)

Disk image challenges are a category where picking the wrong tool first wastes a lot of time. Here's the order I follow now:

fdisk — read the partition table first. Tells you how many partitions exist and their offsets.
dd — carve out individual partitions by byte offset for closer inspection.
mount — only after you know the partition layout. Mounting blindly often fails; fdisk tells you the offset you need for the -o flag.

The Rabbit Hole I fell into early on: jumping straight to mount without checking the partition table. If the image has multiple partitions, mount defaults to the first one and you might miss the flag entirely.

Audio Files (.wav, .mp3, .flac)

Audio forensics challenges almost always hide data in one of three places: the spectrogram, the waveform LSBs, or metadata. Your first move should always be the spectrogram.

Audacity — open the file and switch to spectrogram view immediately. If there's a visual message hidden in the frequency domain, you'll see it in seconds. This is the tool I open first for any audio challenge.
SoX — when I need to script audio analysis or batch-process files. Also useful for speed/pitch manipulation when a challenge hints that audio has been distorted.
FFmpeg — for video files or when a challenge mixes audio and video. Also my go-to when a file won't open in Audacity due to codec issues — FFmpeg can transcode it first.

Image Files (.png, .jpg, .bmp)

Image steganography is one of the most common forensics categories. The approach depends on whether the file is structurally intact or corrupted.

pngcheck — run this first on any PNG. It validates chunk integrity and will immediately flag if something is wrong with the file structure. A challenge with a "broken" PNG almost always has an intentionally modified chunk.
steghide — for JPEG/BMP files that might have data embedded with a passphrase. If the challenge gives you a password hint, steghide is usually involved.
binwalk — when the image looks clean but is suspiciously large. Scans for embedded files and compressed data appended after the image end.

One pattern I've noticed: if a PNG passes pngcheck cleanly but still feels suspicious, look at the IDAT chunk data and palette entries. Some challenges inject data there that doesn't break the structure.

Documents and Archives

pdfdumper — PDFs are containers. pdfdumper extracts embedded objects, JavaScript, and hidden streams that you'd never see just opening the file normally.
zip2john — for password-protected ZIPs. The key thing here is identifying the encryption type first: ZipCrypto is crackable with zip2john + hashcat/john, but AES-256 encryption requires the actual password. I wrote about this distinction in detail in the zip2john article.

QR Codes and Barcodes

zbarimg — the fastest way to decode QR/barcodes from the command line. The Scan Surprise challenge in picoCTF is a straightforward example — see the writeup for how it plays out in practice.

My First-Pass Workflow

When I get a new forensics challenge, this is the sequence I actually follow:

# 1. What is this file?
file challenge.*
xxd challenge.* | head -30

# 2. Anything embedded?
binwalk challenge.*
strings challenge.* | grep -i flag

# Example output that changes my approach:
$ strings mystery.dat | grep -i flag
picoCTF{hidden_in_plain_sight_3a9f2}
# Done in 10 seconds. Sometimes it's that simple.

# 3. Branch based on file type
# → disk image: fdisk → dd → mount
# → audio: Audacity spectrogram → sox/ffmpeg
# → image: pngcheck → steghide
# → archive: zip2john (check encryption type first)
# → PDF: pdfdumper
# → QR/barcode: zbarimg

The strings pass in step 2 sounds too simple to mention, but I've found flags in plaintext embedded in binary files more than once. Never skip it before reaching for a specialized tool.

Common Rabbit Holes in Forensics CTF

Things I've learned to check before going deep on a tool:

Wrong file type assumption — the extension lies. Always check magic bytes with file and xxd.
Multiple layers — extracting one file from a ZIP and stopping. There's often another layer inside.
Mounting without reading partition offsets — mount fails or mounts the wrong partition when you skip fdisk.
AES-256 ZIP + zip2john — zip2john cannot crack AES-256 encrypted ZIPs. If you're seeing $zip2$* in john output, you need the actual password, not a dictionary attack.
Spectrogram at wrong scale — if Audacity's spectrogram looks like noise, zoom in on the frequency range 1–4kHz. Flags are sometimes hidden in a narrow band that's invisible at default zoom.

Tool Reference Index

Tool	File Type	When to Use
fdisk	Disk image	Read partition table before anything else
dd	Disk image	Carve partitions by byte offset
mount	Disk image	Browse filesystem after fdisk gives you the offset
Audacity	Audio	Spectrogram analysis — open first for any audio file
SoX	Audio	Scripted analysis, speed/pitch manipulation
FFmpeg	Audio/Video	Video files, codec issues, format conversion
pngcheck	PNG	Validate chunk integrity on any PNG challenge
steghide	JPEG/BMP	Extract passphrase-protected embedded data
binwalk	Any binary	Detect and extract embedded files; watch for false positives in PNG IDAT chunks
zbarimg	QR/Barcode	Fastest CLI decoder for QR and barcode images
pdfdumper	PDF	Extract hidden streams, embedded objects, JavaScript
zip2john	ZIP archive	Password hash extraction (ZipCrypto only — check encryption type first)

RED picoCTF Writeup

rudy_candy — Mon, 20 Apr 2026 17:34:27 +0000

Introduction

This is my writeup for the picoCTF challenge RED — a forensics puzzle centered on LSB steganography hidden inside a PNG image. I used exiftool to find a suspicious poem in the metadata, decoded an acrostic clue pointing to zsteg , and extracted a Base64-encoded flag from the LSB layer. Fair warning: I hit a wall installing zsteg before I even got started.

Challenge Overview

CTF: picoCTF

Challenge: RED

Category: Forensics

Difficulty: Easy

The challenge description was minimal — almost taunting:

RED, RED, RED, RED

Download the image: red.png

A single PNG. No hints. Just red. I had no idea what I was walking into.

Step-by-Step Walkthrough

Step 1: Start with `file` — Because Assumptions Kill

My first instinct with any unknown file is to run file. Not because I expect fireworks, but because I've been burned before. Once I tried to open a "PNG" that was actually a ZIP in disguise — and I wasted 20 minutes confused why my image viewer crashed. Never again.

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

Legitimate PNG, 128×128 pixels, RGBA color space. Nothing suspicious here — which somehow made it more suspicious. A 128×128 image isn't exactly a high-resolution photo. Something was packed inside.

Step 2: `exiftool` — Where Things Got Weird

When the file itself looks clean, I dig into metadata. exiftool reads EXIF and other embedded data that the image itself doesn't display visually. Most of the time it's boring — camera model, GPS coordinates, timestamps. This time it was not boring at all.

$ exiftool red.png
ExifTool Version Number         : 13.25
File Name                       : red.png
Directory                       : .
File Size                       : 796 bytes
File Type                       : PNG
Image Width                     : 128
Image Height                    : 128
Bit Depth                       : 8
Color Type                      : RGB with Alpha
Poem                            : Crimson heart, vibrant and bold,
Hearts flutter at your sight.
Evenings glow softly red,
Cherries burst with sweet life.
Kisses linger with your warmth.
Love deep as merlot.
Scarlet leaves falling softly,
Bold in every stroke.
Image Size                      : 128x128

A Poem field. I had never seen that metadata field before. My first reaction was genuine confusion — who puts a poem in a PNG? But then I read it again. Something about the structure felt deliberate. Too deliberate.

Step 3: The CHECKLSB Acrostic — I Almost Missed It

I copied the poem into a text editor and read it a few times looking for something — a URL, a hex string, anything obviously encoded. Nothing. I almost moved on to running strings on the raw file when something made me slow down. The poem felt constructed rather than natural. Every line started clean and capitalized. That's not how poems flow when they're written to be felt — that's how they flow when they're written to hide something.

I read the first letters vertically.

C rimson heart, vibrant and bold,

H earts flutter at your sight.

E venings glow softly red,

C herries burst with sweet life.

K isses linger with your warmth.

L ove deep as merlot.

S carlet leaves falling softly,

B old in every stroke.

C-H-E-C-K-L-S-B. CHECKLSB.

I genuinely laughed. Not because it was funny, but because I almost didn't see it. I had been looking for something technical — encoded characters, unusual Unicode, anything that looked like data — when the answer was a first-grade word puzzle hiding in plain sight. An acrostic: a message formed by the first letters of each line. And "CHECKLSB" is not a cryptic phrase. It's an instruction. Check the LSB — the Least Significant Bit layer of the image. The poem was telling me exactly what to do next.

Step 4: Installing `zsteg` — The Part That Tripped Me Up

LSB steganography in PNG images — my tool of choice is zsteg. So I typed sudo apt install zsteg and got nothing. Package not found. I tried apt search zsteg. Still nothing. Checked Snap. No luck there either.

Turns out zsteg is not in the standard APT repositories at all. It's a Ruby gem, and you need to install it through RubyGems after setting up the Ruby development environment and ImageMagick bindings. I didn't know this going in and lost probably 10 minutes trying different apt variants before looking it up.

$ sudo apt update
$ sudo apt install ruby ruby-dev imagemagick libmagickwand-dev
$ sudo gem install zsteg

The libmagickwand-dev dependency is the one that catches people. The gem won't compile without it. Once that's in place, gem install zsteg works cleanly.

Step 5: Running `zsteg` — The Payload Surfaces

With zsteg installed, I ran it on the image:

$ zsteg red.png
meta Poem           .. text: "Crimson heart, vibrant and bold,\nHearts flutter at your sight.\nEvenings glow softly red,\nCherries burst with sweet life.\nKisses linger with your warmth.\nLove deep as merlot.\nScarlet leaves falling softly,\nBold in every stroke."
b1,rgba,lsb,xy      .. text: "cGljb0NURntyM2RfMXNfdGgzX3VsdDFtNHQzX2N1cjNfZjByXzU0ZG4zNTVffQ==cGljb0NURntyM2RfMXNfdGgzX3VsdDFtNHQzX2N1cjNfZjByXzU0ZG4zNTVffQ=="
b1,rgba,msb,xy      .. file: OpenPGP Public Key

There it is. The b1,rgba,lsb,xy channel contains a Base64-encoded string — twice concatenated, but that's just the decoder reading past the end of the actual data. The real payload is the first copy.

Capture the Flag

The Base64 string cGljb0NURntyM2RfMXNfdGgzX3VsdDFtNHQzX2N1cjNfZjByXzU0ZG4zNTVffQ== needed one more step. I wrote a quick Python snippet:

import base64
cipher = "cGljb0NURntyM2RfMXNfdGgzX3VsdDFtNHQzX2N1cjNfZjByXzU0ZG4zNTVffQ=="
plain = base64.b64decode(cipher).decode()
print(plain)


$ python3 a.py
picoCTF{r3d_1s_th3_ult1m4t3_cur3_f0r_54dn355_}

That moment when the flag prints cleanly to stdout — it never gets old. After the frustration of the zsteg installation, seeing a clean picoCTF{...} string felt disproportionately satisfying.

Flag: picoCTF{r3d_1s_th3_ult1m4t3_cur3_f0r_54dn355_}

Full Trial Process Table

Step	Action	Command	Result	Why it failed or succeeded
1	Identify file type	`file red.png`	Valid PNG, 128×128, RGBA	Succeeded — confirmed the file is a genuine PNG, not disguised as something else
2	Read metadata	`exiftool red.png`	Found embedded Poem field	Succeeded — unusual Poem field stood out immediately as non-standard metadata
3	Decode acrostic	Manual reading of first letters	CHECKLSB	Succeeded — once you look for it, the pattern is obvious; easy to miss on first glance
4a	Install zsteg via apt	`sudo apt install zsteg`	Package not found	Failed — zsteg is not in the standard APT repositories; requires RubyGems
4b	Install Ruby dependencies	`sudo apt install ruby ruby-dev imagemagick libmagickwand-dev`	All packages installed	Succeeded — `libmagickwand-dev` is required for the gem to compile
4c	Install zsteg via gem	`sudo gem install zsteg`	zsteg installed	Succeeded — once dependencies are in place, gem install works cleanly
5	Run LSB steganography scan	`zsteg red.png`	Base64 string in b1,rgba,lsb,xy	Succeeded — CHECKLSB hint pointed directly to the right channel
6	Decode Base64	`python3 a.py`	`picoCTF{r3d_1s_th3_ult1m4t3_cur3_f0r_54dn355_}`	Succeeded — standard Base64 decoding, no further obfuscation

Command Explanations

exiftool

exiftool reads metadata embedded in image files — things like camera settings, GPS data, copyright information, and (in this case) custom fields that challenge authors have planted. It reads dozens of metadata formats across hundreds of file types. Running it with no flags on a file gives you a full dump of everything embedded. It's usually one of the first things I run on a forensics challenge image because metadata is cheap to hide things in and often overlooked.

zsteg

zsteg is a Ruby-based tool specifically designed to detect hidden data in PNG and BMP files using steganographic techniques. It checks multiple bit-plane combinations (b1 through b8), color channel orderings (rgb, rgba, bgr, etc.), bit orders (lsb, msb), and scan directions (xy, yx). The output line b1,rgba,lsb,xy means: bit depth 1, RGBA channels in that order, least significant bit first, scanning left-to-right then top-to-bottom. That specific combination is one of the most common LSB hiding methods, which is why it showed up first.

base64 (Python)

Base64 is an encoding scheme — not encryption. It converts binary data into ASCII text using a 64-character alphabet (A-Z, a-z, 0-9, +, /). The = padding at the end is a giveaway. Python's base64.b64decode() reverses this. Because it's encoding rather than encryption, no key is needed — if you recognize the format, you can decode it immediately. In CTF challenges, Base64 often appears as a final layer after the actual hiding mechanism has been defeated.

Beginner Tips

Always runfile first. A file extension can lie. The file command reads magic bytes at the start of the file — that's the truth.
exiftool before anything else on image challenges. Custom metadata fields like "Poem" won't show up in normal image viewers. You need to ask for them explicitly.
Read slowly. The acrostic in this challenge is easy to miss if you skim. Treat every piece of embedded text as potentially meaningful.
zsteg is not in apt. Save yourself 10 minutes of confusion: it requires ruby-dev and libmagickwand-dev before gem install zsteg will work.
Double-check Base64 strings before decoding. zsteg sometimes reads past the end of the actual data and duplicates it. Compare the two halves — if they're identical, use just one copy.
Keep a tool checklist. For PNG forensics: file → exiftool → strings → binwalk → zsteg → pngcheck. Working through a checklist beats staring blankly at a file.

What You Learned / Takeaways

This challenge is a clean three-layer puzzle: metadata hiding (the poem in exiftool), linguistic encoding (the acrostic spelling CHECKLSB), and steganographic hiding (LSB data in the RGBA channel). Each layer points to the next. It's a well-designed beginner challenge because no layer requires specialized knowledge — just methodical thinking and knowing which tools to reach for.

The zsteg installation issue is worth dwelling on. "Not in apt" is a common pattern for niche security tools. When a standard package manager comes up empty, the usual next steps are: check if it's a Python package (pip install), a Ruby gem (gem install), a Go tool (go install), or a manual build from GitHub. Knowing the tool's ecosystem tells you where to look.

On the LSB technique itself: each color channel in an RGBA pixel is stored as an 8-bit number. The least significant bit — the rightmost 1 in the binary representation — contributes almost nothing to the visible color. A red value of 254 (11111110) and 255 (11111111) are visually indistinguishable. Flip those last bits across every pixel in a 128×128 RGBA image and you have 128 × 128 × 4 = 65,536 bits of hidden storage — enough to hold meaningful text. The image looks completely normal. No tools would flag it in transit. That's the point.

This is not just a CTF puzzle technique. I've read incident reports where malware communicated with command-and-control servers by exfiltrating data hidden in PNG images uploaded to public file-sharing sites — traffic that looked like ordinary image uploads to any network monitor not specifically checking for steganographic content. Media companies use the same underlying math for digital watermarking: embedding traceable identifiers in image files to identify the source of a leak. Both sides of the security industry use this. Knowing how to detect it matters.

If I solved this again: I'd go straight from exiftool to zsteg. The CHECKLSB acrostic is a strong enough hint that I wouldn't spend time on binwalk or strings first. I'd also pre-verify the zsteg installation before the challenge clock starts — tool installation under time pressure is avoidable friction.

Includes picoCTF Writeup

rudy_candy — Mon, 20 Apr 2026 17:34:24 +0000

HTML source code review is one of those skills that sounds obvious in hindsight, yet I spent a full 30+ minutes chasing the wrong rabbit before I figured that out. This is my writeup for the picoCTF "Includes" challenge — a Web Exploitation Easy problem that taught me more about my own assumptions than it did about hacking. If you landed here hoping to find how a hidden flag lives inside CSS and JavaScript comments, you're in the right place.

Challenge Overview: picoCTF "Includes"

Competition: picoCTF

Challenge Name: Includes

Category: Web Exploitation

Difficulty: Easy

Points: 100

The challenge drops you at a single-page website with a button and some decorative text. The objective: find the flag. No hints. No file downloads. Just a URL.

My First Instinct — And Why It Was Wrong

I'll be honest: the moment I saw a web challenge labeled "Easy," my brain jumped straight to SQL injection. I don't know why — probably because SQL injection is the first thing I learned and it feels like a reliable default. I opened the page, saw a text input area, and started typing.

' OR 1=1 --
" OR "1"="1
admin'--
' UNION SELECT null--

Nothing. The button didn't even submit anything to a visible endpoint. I checked the Network tab in DevTools — no POST request firing at all. The form was cosmetic, or at least it wasn't wired to a backend I could see.

Then I pivoted to XSS, reasoning maybe there was a reflection point somewhere.

<script>alert(1)</script>
<img src=x onerror=alert(1)>
javascript:alert(document.cookie)

Also nothing. The page just sat there looking smug. No reflected output, no pop-ups. I started to feel the slow creep of frustration — you know the feeling when you're trying three things at once and none of them are landing.

I wasted about 20 minutes here before stepping back and asking myself: why am I jumping to SQL injection on a page that probably doesn 't even have a database? I had pattern-matched to "web challenge = injection" without actually reading what was in front of me.

Rabbit Hole Log — 30+ Minutes of Going Nowhere

Here's the honest accounting of what I tried before getting to the actual solution:

Step	What I Tried	Time Spent	Result	Why It Failed
1	SQL injection via text input	~10 min	No response change	No database backend; form is static
2	XSS payloads in input fields	~10 min	No reflection	Input not rendered back to DOM
3	Brute-forcing hidden paths (/admin, /flag, /secret)	~8 min	404 on everything	This is a static challenge page, no hidden routes
4	Checking cookies and local storage for encoded values	~5 min	Empty / session cookie only	Flag isn't stored client-side in that way
5	HTML source view — finally	2 min	Found CSS and JS references	Should have been step 1

Thirty-three minutes. That's how long it took me to do what should have been the first thing. If you're laughing right now, that's fair. I was laughing too — eventually.

The Actual Solution: Reading the Source

Step 1: View HTML Source

I hit Ctrl+U to open the raw HTML source. Right away I could see two external file references: style.css and script.js. Nothing unusual about that structure — every web page has CSS and JS. But in a CTF context, "included files" is practically a signpost.

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

The challenge name is literally "Includes." I cannot stress enough how much I should have caught that earlier.

Step 2: Open style.css

I navigated directly to /style.css by appending it to the base URL. The file loaded. I scrolled through the usual CSS declarations — nothing unusual — until I hit a comment at the bottom of the file:

/* You need to include picoCTF{1nclu51v17y_1of2_ */

There it was. Half a flag, wrapped in a developer comment. My first reaction was a small, embarrassed laugh — this was right here the whole time, in the CSS file, which I hadn't thought to open for over half an hour.

Step 3: Open script.js

With the first fragment in hand, I opened /script.js. Same approach — append to base URL, scroll through the file. Near the bottom:

// f7w_2of2_6edef411}

The second fragment. A JavaScript single-line comment hiding in plain sight.

Step 4: Combine the Fragments

Concatenate the two parts:

picoCTF{1nclu51v17y_1of2_f7w_2of2_6edef411}

That's the flag. The moment I pasted both strings together I had that very specific CTF feeling — not triumph exactly, more like relief mixed with "oh come on, really?" It's humbling when a 100-point Easy challenge makes you feel genuinely foolish for 30 minutes.

Why I Tried SQL Injection and XSS First (And Why That Was a Mistake)

I want to be specific about the reasoning failure here, because it's a pattern worth breaking.

SQL injection made sense in my head because I saw an input field and assumed there was a database behind it. That's an assumption without evidence. I should have checked whether the form even submitted a request before crafting payloads for a backend that didn't exist.

XSS followed from the same mistake: I was looking for a reflection point in a page that wasn't reflecting user input anywhere. I was testing a hypothesis I'd constructed without reading the actual page behavior first.

The correct mental model for an Easy web challenge should be: start with what the browser already has access to, then escalate. HTML source → linked resources → cookies/storage → requests → server behavior. I started in the middle and paid for it with half an hour of my time.

Why This Matters in the Real World: Comment Leakage

This challenge isn't contrived. Leaving sensitive information in code comments is a genuine, documented vulnerability class. A few real cases worth knowing:

API keys in JavaScript files: Developers frequently embed API keys in client-side JS for quick prototyping, then ship to production without stripping them. Google Maps API keys, Firebase credentials, and Stripe publishable keys have all been leaked this way. Some of these allow read access to entire databases.
AWS credentials in HTML comments: AWS Access Key IDs and Secret Access Keys have been found in HTML comments of public-facing pages. Once extracted, these credentials can be used to access S3 buckets, spin up EC2 instances, or exfiltrate data.
Internal path disclosure: Comments like /* TODO: move /admin/config.php before launch */ reveal server directory structures that help attackers map the application.
Debug notes left in production: Comments such as // password is "admin123" for now or /* hardcoded until OAuth is ready */ have appeared in real production codebases during security audits.

The picoCTF "Includes" challenge distills this exact pattern: split sensitive data across multiple files, leave it in comments, and wait to see who checks. In a real engagement, an attacker running a passive reconnaissance pass over your JS and CSS files would find this in seconds. Automated tools like LinkFinder and subjs scrape JS files specifically looking for exposed secrets.

OWASP Top 10: Security Misconfiguration

This vulnerability maps directly to OWASP Top 10 A05:2021 — Security Misconfiguration. The OWASP category covers scenarios where systems are deployed with unnecessary features enabled, default credentials unchanged, or — as here — error-prone development artifacts left in production code.

Leaving debug comments, internal notes, or fragment data in unminified CSS/JS files qualifies as misconfiguration because it exposes internal implementation details that serve no function for end users but provide genuine value to an attacker. The fix is straightforward: minify and strip comments from all production assets. A build pipeline using tools like Webpack, Rollup, or esbuild handles this automatically — there's no excuse in 2026 for shipping commented development notes to a production server.

Beginner Web Challenge Checklist

Based on this challenge (and the 33 minutes I wasted), here's the checklist I now follow before trying anything fancy:

View HTML source (Ctrl+U or right-click → View Page Source)
Check all externally linked files: CSS, JS, images, fonts
Read every comment in every file — CSS /* */, JS // and /* */, HTML 
Open browser DevTools → Network tab, reload the page, inspect every request
Check cookies, localStorage, and sessionStorage for encoded or suspicious values
Look at the page title, meta tags, and hidden form fields
Check robots.txt and sitemap.xml for path hints
Only after all of the above: start testing for injection, XSS, or authentication bypass

If you follow this order, you'll solve "Includes"-style challenges in under two minutes every time. I know this now. You know this now. Let's not lose 33 minutes again.

Retrospective: How I'd Solve This Next Time

If I encountered a challenge like this again, my first move would be to look at the challenge name. "Includes" is not a subtle hint — it's telling you exactly what the mechanic is. Always read the problem title as a potential clue about what technique is being tested.

Second, I'd open the HTML source before even interacting with the page. No clicking buttons, no typing in forms — just Ctrl+U, read the markup, note every external resource, and visit each one immediately.

Third, I'd use a tool like Burp Suite to passively collect all resources the page loads, so I don't miss anything that isn't in an obvious <link> or <script> tag. Dynamic imports, fetch calls, and lazy-loaded resources can hide interesting content that raw source viewing won't catch.

The core lesson: don't let your instinct for "cool" techniques — injection, XSS, SSRF — blind you to what's already sitting in the DOM.

steghide in CTF: Extract Flags

rudy_candy — Mon, 20 Apr 2026 17:29:18 +0000

I stared at the steghide extract prompt for a full minute before I realized the passphrase was sitting right there — encoded twice in the image's own metadata. That was picoCTF Hidden in Plainsight , and it changed how I think about steganography challenges entirely.

Before that problem, my steghide workflow was: download image, run steghide extract, type "password," fail, give up. After it, I understood that the real skill isn't knowing steghide's flags — it's knowing where the passphrase is hiding before you even open the tool.

The Solve That Taught Me Everything: picoCTF Hidden in Plainsight

The challenge gave me a single file: img.jpg. No hints, no description beyond "can you find it?" I ran file first, which is always my starting point — not because I expect much, but because sometimes the output surprises you.

$ file img.jpg
img.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, comment: "c3RlZ2hpZGU6Y0VGNmVuZHZjbVE9", baseline, precision 8, 640x640, components 3

That comment field stopped me cold. A JPEG comment containing what's clearly a base64 string — that's not normal. I decoded it immediately:

import base64
cipher = "c3RlZ2hpZGU6Y0VGNmVuZHZjbVE9"
plain = base64.b64decode(cipher).decode()
print(plain)


$ python3 decode.py
steghide:cEF6endvcmQ=

The output itself was split at a colon: steghide on the left, another base64 string on the right. The challenge was literally telling me which tool to use and handing me an encoded passphrase. I decoded the right side:

import base64
cipher = "cEF6endvcmQ="
plain = base64.b64decode(cipher).decode()
print(plain)


$ python3 decode.py
pAzzword

Before extracting, I ran steghide info to confirm data was actually embedded — a habit I've developed after chasing too many false positives:

$ steghide info img.jpg
"img.jpg":
  format: jpeg
  capacity: 4.0 KB
Try to get information about embedded data ? (y/n) y
Enter passphrase:
  embedded file "flag.txt":
    size: 34.0 Byte
    encrypted: rijndael-128, cbc
    compressed: yes

There it was — flag.txt, 34 bytes, AES-128 encrypted. The passphrase pAzzword unlocked it:

$ steghide extract -sf img.jpg
Enter passphrase:
wrote extracted data to "flag.txt".


picoCTF{h1dd3n_1m4g3_67479645}

The lesson wasn't about steghide — it was about metadata. The passphrase was never "hidden." It was in file img.jpg output the whole time, double base64-encoded in the comment field. I almost missed it because I was looking for the payload, not the key.

What steghide Actually Does — and Why It Matters for CTF

Most tutorials say steghide "hides data using LSB." That's close, but not precise — and the difference matters when you're trying to figure out why binwalk found nothing but steghide still has data.

For JPEGs, steghide operates on DCT (Discrete Cosine Transform) coefficients — the numeric values produced during JPEG compression. It swaps pairs of coefficients using a graph-theoretic algorithm so the statistical distribution of the image stays nearly identical to an unmodified JPEG. This is why binwalk shows nothing: there's no appended data, no file signature to detect. The payload is woven into the image's compression artifacts.

For WAV files, it modifies the least significant bits of audio samples. The human ear can't detect it, and spectrum analysis in Audacity usually won't show anything either.

Understanding this tells you when steghide is the right tool: when the file is JPEG or WAV, when binwalk comes up empty, and when the challenge hints at a password or passphrase being required.

My Pre-steghide Checklist

I don't open steghide until I've done three things. This checklist has saved me from multiple dead ends:

1. Run file — read every field

The Hidden in Plainsight comment field is a perfect example of why. The file command output is dense and easy to skim past. Force yourself to read the comment field, the OEM-ID, the segment length — anything that looks non-standard.

2. Check file size vs. resolution

A 640×640 JPEG shouldn't be 2MB. If the file size is disproportionately large for its resolution, steghide (or a similar tool) is almost certainly involved. steghide's capacity field in steghide info will confirm it.

3. Try a blank passphrase first

A non-trivial number of Easy-rated steganography challenges embed data with no passphrase at all. Run steghide info and just press Enter when prompted. If it returns embedded file information, you're done searching for the password.

When steghide Fails: My Decision Tree

Wrong passphrase vs. no data — how to tell

This is the most common point of confusion for beginners. The error messages look different:

# Wrong passphrase — data IS embedded, key is wrong
steghide: could not extract any data with that passphrase!

# No data — steghide info returns nothing
steghide: could not extract any data with that passphrase!

The messages are identical. The only way to confirm data is embedded is to run steghide info first with the correct passphrase — which is circular. In practice: if the challenge involves a JPEG or WAV and you suspect steganography, assume steghide and look harder for the passphrase rather than assuming there's no data.

When to switch to Stegseek

If you've exhausted the obvious passphrase sources (metadata, challenge description, filenames, visible strings in the binary) and nothing works, switch to Stegseek for brute force — not Stegcracker.

The difference is significant: Stegcracker restarts the full steghide process for every attempt. Stegseek interfaces directly with the steghide library, skipping redundant hash recalculation. Against rockyou.txt, Stegcracker takes hours; Stegseek takes seconds.

$ stegseek suspicious.jpg /usr/share/wordlists/rockyou.txt

When to abandon steghide entirely

steghide only supports JPEG and WAV. If the file is PNG, BMP, or MP3 — stop. You're looking at a different tool. For PNGs, zsteg is the equivalent. For formats steghide can't read, steghide info will error immediately, which is at least a fast negative signal.

Tool Selection: When to Use What

Tool	File types	Use when	Skip when
steghide	JPEG, WAV	Password/passphrase is available or suspected; binwalk empty	File is PNG or any non-JPEG/WAV format
Stegseek	JPEG	steghide fails and passphrase is unknown; need brute force	You have the passphrase already
zsteg	PNG, BMP	File is PNG; LSB analysis needed	File is JPEG or WAV
binwalk	Any	First pass; looking for appended files or embedded signatures	Stego technique is DCT-based (steghide)

My steghide Workflow

# 1. Static analysis first — read every field
file target.jpg

# 2. Check for embedded data with blank passphrase
steghide info target.jpg
# (press Enter at the prompt)

# 3. If data confirmed, extract
steghide extract -sf target.jpg
# (enter passphrase when prompted)

# 4. If passphrase unknown, check metadata, strings, challenge text
strings target.jpg | grep -v "^.\{1\}$"
exiftool target.jpg

# 5. Last resort: brute force with Stegseek
stegseek target.jpg /usr/share/wordlists/rockyou.txt

One install note: steghide is occasionally missing from modern repositories due to aging dependencies. If apt install steghide fails, download the .deb package directly or use a pre-built CTF environment like pwntools Docker images.

Corrupted File picoCTF Writeup

rudy_candy — Mon, 20 Apr 2026 17:24:10 +0000

Magic bytes corruption, hex editing, and a JPEG hiding in plain sight — this is my full walkthrough of the picoCTF 2019 "Corrupted File" forensics challenge. The file command returned just "data." No extension, no hint about the format. I spent roughly 25 minutes confused, trying the wrong tools, before two bytes of hexdump finally made everything click. Here's the complete process, including every dead end.

Challenge Overview: picoCTF 2019 "Corrupted File"

This challenge is from picoCTF 2019 , Forensics category, rated Easy. The setup: you receive a single file with no extension. The challenge description says it's "corrupted." Your job is to figure out what it actually is and recover the hidden flag inside it.

There are no other hints. No suggested tools. Just a broken file and your terminal.

Field	Details
CTF Name	picoCTF 2019
Challenge Name	Corrupted File
Category	Forensics
Difficulty	Easy
Flag	picoCTF{r3st0r1ng_th3_by73s_b67c1558}

First Look: The File Command Returns Nothing Useful

My first instinct with any unknown file is file. It checks the actual byte content — not the extension — and matches known magic byte patterns. I ran it expecting at least a partial identification:

$ file corrupted_file
corrupted_file: data

"data." That's the file command's way of saying it matched absolutely nothing in its signature database. Not truncated, not partially identified — just completely unknown. My first thought was that maybe the file was totally destroyed and nothing was recoverable. I sat with that for a moment.

Then I looked at the challenge name again: Corrupted File. Of course it was corrupted. That was the point. Something had been deliberately broken, and that something was almost certainly the header — the magic bytes that tell every tool on your system what type of file it's looking at.

Running strings — and finding more than I expected

Before touching any hex editor, I ran strings to see if any readable content survived the corruption:

$ strings corrupted_file | head -20
JFIF
Exif
...
picoCTF{r3st0r1ng_th3_by73s_b67c1558}

Two things jumped out immediately. First: JFIF. That's the JPEG File Interchange Format marker — it's specific to JPEG files and always appears just after the SOI header. Second, the flag was right there, readable as plain text near the end of the output. I could have submitted it and moved on.

But I didn't, because I wanted to understand what was actually broken. Submitting the flag without understanding the fix felt like cheating myself out of the lesson.

Why JPEG? How I Ruled Out Every Other Format

When you see an unidentified file, the first question is: what format is it supposed to be? I didn't guess JPEG randomly — I reasoned through it by eliminating alternatives.

JFIF = JPEG, full stop. The string "JFIF" doesn't appear in PNG, GIF, PDF, or ZIP files. It's specific to JPEG. Once I saw it in strings output, there was no ambiguity.
PNG ruled out immediately. PNG files contain the ASCII string "PNG" in bytes 1–3 of their magic number (89 50 4E 47). Even if the first byte were corrupted, "PNG" would still show up in strings. It didn't.
GIF ruled out. GIF headers start with ASCII "GIF87a" or "GIF89a." Completely readable in strings. Absent here.
PDF ruled out. PDFs begin with %PDF, also readable ASCII. Not present.
ZIP ruled out. ZIP files start with "PK" in ASCII. Not present either.

The only format consistent with seeing "JFIF" in the strings output was JPEG. The body of the file was fine — it was just the two-byte SOI marker at the very beginning that had been tampered with.

Rabbit Hole: 20 Minutes of Wrong Approaches

I didn't go straight to hexdump. I'm being honest here: I fumbled around for a while trying things that seemed reasonable but weren't actually going to fix anything.

Attempt 1: Renaming and opening directly (~5 minutes)

My immediate reaction was to rename it to corrupted_file.jpg and try to open it in an image viewer. I figured maybe it just needed the extension. The image viewer opened, showed a loading spinner for a fraction of a second, then gave me an error: "Invalid or unsupported image format." Of course. File extensions are just labels — they don't affect how the actual bytes are interpreted. A JPEG viewer checks the magic bytes first, and FF D8 was not there.

Attempt 2: exiftool (~5 minutes)

$ exiftool corrupted_file
ExifTool Version Number         : 12.76
File Name                       : corrupted_file
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Image Width                     : 400
Image Height                    : 300
Color Components                : 3
...

This was surprising. Exiftool identified it as JPEG — dimensions and everything — even without the correct magic bytes. That's because exiftool doesn't rely solely on the first two bytes; it looks for JFIF/Exif markers deeper in the file structure. Useful confirmation that the file was JPEG, but it didn't repair anything. I still couldn't view it.

Attempt 3: binwalk (~10 minutes)

$ binwalk corrupted_file

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Unknown data

Binwalk relies on magic byte signatures at known offsets. With the first two bytes wrong, it couldn't match anything. I tried binwalk -e (extract), binwalk --dd, different flags — nothing. Eventually I accepted that no automated tool was going to save me here. I needed to look at the raw bytes.

hexdump: Finding the Two Wrong Bytes

I finally did what I should have done ten minutes earlier:

$ hexdump -C corrupted_file | head -3
00000000  5c 78 ff e0 00 10 4a 46  49 46 00 01 01 00 00 01  |\.....JFIF......|
00000010  00 01 00 00 ff db 00 43  00 08 06 06 07 06 05 08  |.......C........|
00000020  07 07 07 09 09 08 0a 0c  14 0d 0c 0b 0b 0c 19 12  |................|

The first two bytes: 5C 78. Everything from byte 2 onward looked like legitimate JPEG data — FF E0 is the APP0 marker, and there's "JFIF" right in the ASCII column at bytes 6–9.

So what is 5C 78? In ASCII, 5C is a backslash (\) and 78 is the letter x. Together: \x. That's the hex escape prefix used in Python, C, and most scripting languages. When you write \xff\xd8 in code, the \x parts are supposed to be interpreted by the language and produce the binary bytes FF D8. But here, the \x prefix had been written out as literal ASCII characters instead of being processed. So instead of the binary JPEG SOI marker, the file had the text "\x" followed by the rest of the original sequence.

A correct JPEG SOI (Start of Image) header looks like this:

FF D8 FF E0 00 10 4A 46 49 46 ...
^^^^^
SOI marker — the two bytes that identify this as JPEG

The fix: replace bytes 0 and 1 with FF D8.

The "Aha" Moment: \x as a Fingerprint of the Corruption

When I saw 5C 78 in the hexdump, I stared at it for a moment. Then it hit me. Backslash-x. That 's escape notation. The person who wrote the challenge (or the script that generated it) had likely worked with the bytes as a Python string like b'\xff\xd8\xff\xe0...', and something went wrong in the encoding — the escape sequences got written as ASCII text rather than as binary.

It's such a specific kind of corruption that it immediately told me this was intentional challenge design. It's not random bit-flipping or file truncation — it's a precise two-byte substitution that takes the exact magic number and replaces it with its own escape-notation representation. Elegant, in a devious sort of way.

Once I understood what had happened, the fix was obvious and I felt slightly embarrassed it took me 20 minutes to get there.

The Fix: Surgical Repair with hexedit

First, copy the file. This is non-negotiable — never edit the original:

$ cp corrupted_file fixed_file
$ hexedit fixed_file

In hexedit, the display shows hex values on the left and their ASCII equivalents on the right. The cursor starts at position 0x00. I typed FF — the display updated immediately, showing the changed byte. Then D8 for the second byte. Then Ctrl+X to save and exit.

The hexdump before and after, for direct comparison:

Before — corrupted header:

00000000  5c 78 ff e0 00 10 4a 46  49 46 00 01 01 00 00 01  |\.....JFIF......|

After — repaired header:

00000000  ff d8 ff e0 00 10 4a 46  49 46 00 01 01 00 00 01  |......JFIF......|

Two bytes changed. The rest of the file: completely untouched. The JFIF marker at bytes 6–9 had been there all along, waiting for the SOI marker to precede it correctly.

Confirmation with file:

$ file fixed_file
fixed_file: JPEG image data, JFIF standard 1.01, resolution (DPI), density 1x1, segment length 16, baseline, precision 8, 400x300, components 3

From "data" to a fully described JPEG image with dimensions, resolution, and encoding details. That output felt disproportionately satisfying for what was, mechanically, a two-byte fix.

The Flag

Opening the repaired image revealed the flag printed on it:

picoCTF{r3st0r1ng_th3_by73s_b67c1558}

Full Trial Process: Every Step, Honest Results

Step	Command	Result	Why it failed / What I learned
1	`file corrupted_file`	"data" — unidentified	Magic bytes at offset 0 don't match any known signature
2	Renamed to .jpg, opened in image viewer	Error: invalid image format	File extensions are labels only; viewers check actual header bytes
3	`strings corrupted_file	head -20`	Found "JFIF" and the flag as plaintext
4	`exiftool corrupted_file`	Identified as JPEG (400×300)	Exiftool uses deeper format parsing; useful confirmation
5	`binwalk corrupted_file` (multiple flags)	"Unknown data" — nothing extracted	Binwalk also uses magic bytes at offset 0; dead end
6	`hexdump -C corrupted_file	head -3`	Bytes 0–1 are `5C 78` (ASCII "`\x`")
7	`cp corrupted_file fixed_file && hexedit fixed_file`	Changed `5C 78` → `FF D8` at offset 0	Two-byte repair of the JPEG SOI marker
8	`file fixed_file`	Valid JPEG, 400×300, 3 components	Repair successful; format fully identified
9	Opened fixed_file in image viewer	Flag visible in image	Challenge complete

Real-World Relevance: Magic Byte Attacks Beyond CTF

Magic byte manipulation isn't just a CTF trick. It's a real attack technique with documented abuse cases — and understanding how it works makes you a better analyst on both sides of a security investigation.

File upload bypass attacks

Many web applications validate uploaded files by checking only the magic bytes — the assumption being that if the first few bytes say "JPEG," the file is a JPEG. Attackers exploit this by prepending valid JPEG magic bytes to a PHP shell, a Python script, or any other executable payload. The server's validator sees FF D8 and passes the check. The file is stored. A direct HTTP request to the upload URL executes the code.

This attack class has appeared in CVEs against WordPress plugins, PHP image processing libraries (particularly when getimagesize() is misused as a security check), and custom file upload handlers that never perform server-side content inspection beyond the header.

Email gateway evasion

Some email security gateways block attachments based on their detected file type. Malware authors have swapped the magic bytes of Windows executables (which start with 4D 5A, "MZ") to make them resemble PDFs or Office documents. The gateway scans the header, sees a "document," and passes the attachment. The recipient's system — which may do additional verification — then handles it correctly as an executable.

Polyglot files

A polyglot file is simultaneously valid in two different formats. The most well-known CTF example is a file that is both a valid JPEG (because it starts with FF D8) and a valid ZIP archive (because the ZIP end-of-central-directory record appears at the end and doesn't interfere with JPEG parsing). Different tools interpret the same file completely differently. This has been used in real attacks to bypass content filters that only check one format's markers.

Anti-forensic header corruption

Malware samples sometimes deliberately corrupt their own PE headers or remove their magic bytes to confuse automated sandboxes. If a sandbox can't identify the file type, it may skip format-specific behavioral analysis. This buys the malware time in environments where human review only happens for samples that automated systems flag clearly.

MIME sniffing and the nosniff header

Browsers can disagree with servers about file types. A server might declare Content-Type: image/jpeg, but if the bytes look like HTML, some browsers will sniff the content and render it as HTML — potentially executing embedded JavaScript. This is why X-Content-Type-Options: nosniff is a security best practice in HTTP headers. Understanding magic bytes is fundamental to understanding why that header exists.

Magic Bytes Cheat Sheet for CTF Forensics

Having these memorized saves significant time in forensics challenges:

File Type	Magic Bytes (Hex)	ASCII / Notes
JPEG	`FF D8 FF`	Non-printable; followed by APP0 `FF E0` or APP1 `FF E1`
PNG	`89 50 4E 47 0D 0A 1A 0A`	`.PNG....` — "PNG" is readable in strings
GIF	`47 49 46 38`	`GIF8` — followed by "7a" or "9a"
PDF	`25 50 44 46`	`%PDF` — fully readable ASCII
ZIP / JAR / DOCX	`50 4B 03 04`	`PK..` — many formats are ZIP-based
ELF (Linux binary)	`7F 45 4C 46`	`.ELF`
Windows PE (.exe/.dll)	`4D 5A`	`MZ` — from Mark Zbikowski, original DOS designer
SQLite database	`53 51 4C 69 74 65 20 66`	`SQLite f` — starts "SQLite format 3"

Beginner Tips for Magic Byte Challenges

Start withfile, always. If it returns "data," the header is broken. That's your diagnostic.
Runstrings before reaching for a hex editor. Format-specific strings like "JFIF," "PNG," "%PDF," or "GIF8" appear in even heavily corrupted files and tell you the intended type in seconds.
Check only the first 8–16 bytes. Magic bytes live at the very beginning. hexdump -C file | head -2 is almost always sufficient to find header corruption.
Copy before editing. Always: cp original working_copy. Run all your edits on the copy. You may need the original as a reference.
hexedit navigation: Arrow keys to move, just type hex digits to overwrite. Ctrl+X saves and exits. Ctrl+C cancels without saving.
Python one-liner if hexedit feels uncomfortable:

data = open('corrupted_file', 'rb').read()
fixed = b'\xff\xd8' + data[2:]
open('fixed_file', 'wb').write(fixed)

This replaces the first two bytes with the correct JPEG SOI marker and writes the result to a new file. Three lines. No hex editor needed.

What I'd Do Differently Next Time

The biggest mistake I made was spending time on tools before looking at the raw bytes. The pattern for magic byte corruption challenges is straightforward once you've done it once:

Run file — does it identify the format? If it returns "data," the header is wrong.
Run strings — what format-specific strings appear? This tells you the intended file type without opening a hex editor.
Run hexdump -C file | head -3 — find the exact bytes at the start and compare to the known magic number for that format.
Make a copy, open in hexedit (or write a Python one-liner), and fix the bytes.
Verify with file again.

That's a five-step process I could now execute in under two minutes. At the time it took me about 25. The difference is just pattern recognition — and that comes from working through enough of these challenges to stop second-guessing the most obvious approach.

I'd also spend five minutes before any forensics CTF round memorizing the common magic bytes: JPEG, PNG, GIF, ZIP, PDF. Having that table in your head means you recognize a corrupted header instantly from the hexdump, rather than having to stop and look things up mid-solve.

Crack the Power picoCTF Writeup

rudy_candy — Mon, 20 Apr 2026 17:24:07 +0000

picoCTF Crack the Power is an RSA cryptography challenge where the key insight isn't just knowing the attack — it's reading the numbers closely enough to know which version of the attack you're dealing with before you write a single line of code. I didn't do that at first, and it cost me about 40 minutes.

The Challenge

The challenge provides a message.txt file with three values:

n = 557838419289674163475248835907844438905982230212026010035453573...
e = 20
c = 640637430810406857500566702096274079797813783756285040245597839...369140625

RSA with e = 20. The hint says the primes are large, and factorization is not the intended approach.

What I Tried First (and Why It Was Wrong)

Seeing e = 20 and "large primes," I immediately thought: low-exponent RSA attack. I knew two variants exist — the direct root case and the k-iteration case — but instead of figuring out which one applied here, I just reached for the general solution that handles both:

# olddecript.py — my first attempt, works but misses the point
from Crypto.Util.number import *
import gmpy2

i = 1
while True:
    m, ok = gmpy2.iroot(c + i * N, e)
    if ok:
        break
    i += 1
print(long_to_bytes(m))

This ran and produced the flag at i = 1, meaning the loop exited on the first iteration. Which meant… i = 1 wasn't even needed. The loop was unnecessary. I had written the mini-rsa solution for a problem that didn't require it.

That bothered me enough to go back and figure out why i = 0 would have worked just as well — and that's where the actual learning happened.

Reading the Numbers Before Writing Code

The two cases of RSA low-exponent attack differ by one condition:

No wrapping (m^e < N): the modular reduction never fires, so c = m^e exactly. Direct iroot works.
Wrapping (m^e ≥ N): c = m^e mod N, meaning m^e = c + k·N for some small k. You need to iterate.

Looking at the ciphertext again:

c = ...369140625

The last 9 digits are 369140625. Now check what happens when you compute 5^20:

>>> 5**20
95367431640625

The last 9 digits of 5^20 are 431640625. And 369140625 ends with the same suffix pattern — multiples of powers of 5 propagate their trailing digit structure predictably. This is a hint that c is a raw integer power of a plaintext that ends in 5, not a reduced modular value. If the modular reduction had fired, those trailing digits would look arbitrary.

The cleaner check: if m^e < N, then c < N should hold. Comparing the number of digits in c versus n in this challenge confirms c is smaller — no wrapping occurred.

The Actual Solution

import gmpy2
from Crypto.Util.number import long_to_bytes

e = 20
c = 640637430810406857500566702096274079797813783756285040245597839...369140625

m, exact = gmpy2.iroot(c, e)

print("Exact:", exact)
print(long_to_bytes(m))


$ python3 decript.py
Exact: True
b'picoCTF{t1ny_e_2fe2da79}'

exact = True confirms it: c was a perfect 20th power, no wrapping, no iteration needed.

Flag: picoCTF{t1ny_e_2fe2da79}

How to Distinguish the Two Cases Quickly

Check	No wrapping (this challenge)	Wrapping (mini-rsa pattern)
Compare digit count of c vs n	c has fewer digits than n	c has similar digit count as n
gmpy2.iroot(c, e) exact flag	True	False
Required technique	Direct iroot	k-iteration: iroot(c + k·N, e)
Loop exits at	k=0 (no loop needed)	k=1 or small value

The fastest approach in practice: try gmpy2.iroot(c, e) first and check the exact flag. If it's True, you're done. If it's False, you need the k-iteration loop. No need to analyze trailing digits beforehand.

Why This Matters Beyond CTF

The "no wrapping" case happens in practice when RSA is implemented without proper padding and the message is short relative to the modulus. A 20-byte flag encrypted with e = 20 and a 2048-bit modulus will almost always satisfy m^e < N, making the encryption trivially reversible. This is why modern RSA uses OAEP or PKCS#1 v1.5 padding — padding inflates the effective message size to make m^e > N guaranteed, forcing modular reduction and making direct root extraction impossible.

DEV Community: rudy_candy

strings Command in CTF: Hidden Data Guide

picoCTF Ph4nt0m 1ntrud3r — Network Forensics Writeup

Challenge Overview

My First (Wrong) Approach — And Why I Chose It

The Rabbit Hole: Manual Packet Inspection

Setting Up the Investigation Environment

Digging Into the PCAP with Wireshark

Initial Triage: What Does This Traffic Even Look Like?

Applying Wireshark Filters

The Importance of Timestamp Order

Recognizing the Base64 Pattern

Writing the Decoder Script

Full Trial Process Table

Technical Deep Dive — Why Attackers Fragment Data This Way

Data Fragmentation as an Evasion Technique

Real-World Network Forensics Parallels

Why Base64 Specifically?

Reflection — How I Would Solve This Faster Next Time

Key Takeaways

pngcheck in CTF: How to Analyze and Repair PNG Files

🔍 pngcheck CTF Tutorial: How to Analyze Corrupted PNG Files and Find Hidden Chunks

This Article at a Glance

Introduction: The PNG Challenge Where I Used Every Tool Except the Right One

What is pngcheck? (And What It Isn't)

What pngcheck actually does

What pngcheck cannot do

When to Use pngcheck in CTF

Problem description keywords that should trigger pngcheck

pngcheck vs zsteg vs binwalk — When to Use Which

Basic Usage With Thinking

Step 1 — Basic validation: is it broken at all?

Step 2 — Verbose output: read every chunk

Step 3 — Maximum detail: zlib and compression info

The Three Most Common CTF Scenarios

Scenario 1: Broken CRC — The Most Common Trap

Scenario 2: Hidden Custom Chunks

Scenario 3: Data Appended After IEND

Common Mistakes and Rabbit Holes

Full Trial Process Table

Command Reference

Beginner Tips

My personal pngcheck workflow for every PNG challenge

Installing pngcheck

macOS

What You Learn From Using pngcheck

Further Reading

Scan Surprise picoCTF Writeup

The Challenge

The Part Where I Wasted Time

Installing zbarimg

The Solution

What This Challenge Is Actually Testing

What Harder Versions of This Challenge Look Like

Further Reading

CTF Audio Challenges: A Practical SoX Combat Guide

Facing the Problem: Why I Judged This Audio "Meaningless to Play"

First Impression of the Distributed Audio File (CTF Context)

The Basis for Immediately Discarding the "Just Listen" Approach

Initial Hypotheses I Formed at This Point

First Approach and Failure: Why I Didn't Use SoX

Why I Considered Other Tools (Audacity / ffmpeg) First

The Point Where I Judged "This Isn't It"

What Would Have Happened If I Hadn't Chosen SoX Here

The Turning Point: The Decisive Condition That Made Me Deploy SoX

The CTF-Specific Checklist: "When These Conditions Align, Use SoX"

Why I Abandoned GUI and Chose CLI

Misconceptions and Anxiety at First Deployment

Where I Actually Got Stuck: Traps Every SoX Beginner Steps On

The "Cognitive Mismatch" That Happened on First Operation

Why Changing Options Didn't Change Results

Operations I Should Have Abandoned at This Point

What Worked / What Disappointed (Combat Comparison)

Settings That Worked: Why This Parameter Hit Hard

Differences in "Appearance and Sound" When Changing Values

Settings I Expected to Work but Did Nothing

Rabbit Hole Chronicle: Dangerous Forks in This Audio Problem

The Trap of Drowning Time in Spectrograms

The Psychology of Continuing Noise Reduction

The Moment When Continuing to Use SoX Becomes the Failure