DEV Community: rudy_candy

What people get wrong about penetration testing

rudy_candy — Mon, 08 Jun 2026 20:48:20 +0000

Before I became a vulnerability assessor I had the job slightly wrong in my head. If you only know security from films and TV, you probably do too. So here's the reality, including the parts that caught me off guard once I was actually doing it.

The reality is shockingly boring

The picture most people have is someone hammering a keyboard while text streams down the screen and they elegantly break into a system. That's not it.

Most of the work is taking nearly identical requests, changing one small thing, and comparing how the response differs. Change a parameter, send it, look at the result. Change it again, send, look. Over and over. You intercept a request in a tool like Burp Suite, edit it by hand, and check whether the behavior shifts, one at a time. There's no glamour anywhere in it.

I'll be honest, at first it felt like a letdown. But noticing those tiny differences turned out to be its own kind of fun, and I got pulled in. These days I think whether you can find that boring work interesting is the real test of fit for the job.

I didn't expect writing to be the hard part

This one I genuinely didn't see coming. Finding a vulnerability isn't the end of the job.

You have to explain where it is, what the problem is, how to reproduce it, and how dangerous it is, in words the other person can act on. That's the report. It doesn't matter how clever the bug is: if the developer reading it can't reproduce it, you get back "is this actually a vulnerability?" The job needs the hands-on skill and the ability to put it into writing. For someone who assumed it was a purely technical job, that was the biggest surprise.

You learn you can't say "it's safe"

Here's the one whose weight I only felt after starting. When an assessment turns up no vulnerabilities, you still can't say "this system is safe."

What you can say is that within the agreed time, scope, and methods, you didn't find anything. The chance you missed something is always there. "No issues within what we checked" and "definitely safe" are completely different statements. The quiet, honest part of holding that line mattered more on the job than any dramatic find.

It's still a good job

I've spent this whole piece on what surprised me, but I'm not trying to put you off. After stacking up enough of the boring checks, you hit a moment where something feels slightly off, you pull on that thread, and a real problem is sitting at the end of it. That feeling is hard to get anywhere else. Not glamorous, but genuinely interesting.

If you're drawn to this work, ask yourself less about the glamour and more about whether you could enjoy the careful, repetitive checking. Get that part right and it's a job you can do for a long time.

How I got into this work with no background, and the certs and career steps along the way, is something I've written up at length elsewhere. If this was useful, follow along.

The skills that actually transfer: what to learn for a long career in IT

rudy_candy — Mon, 08 Jun 2026 20:47:24 +0000

When you're trying to break into a specialized IT role from scratch, "what should I even study?" is a hard question. I was there myself.

I started as a network engineer and now I do vulnerability assessment. After moving across roles a few times, one thing got clear: skills split fairly cleanly into the ones that transfer and the ones that don't. Here's how I tell them apart.

The hot tool ages out faster than you think

When you're job-hunting, it's tempting to chase whatever is most in demand right now. The tool names that show up in every posting, the framework everyone's talking about. I get it.

But a thing that's popular is, by definition, a thing that gets replaced in a few years. You learn it, and by the time you have it down the next one is already taking over. Chase only that, and you're chasing forever.

What lasts is the ability to understand how things work

The opposite of that is foundation, and foundation lasts. For me it was networking.

Back as a network engineer I spent my time in Wireshark, looking at traffic one packet at a time, reading what was actually happening on the wire. It was tedious, and at the time I half-doubted it had anything to do with security. But when I moved into vulnerability assessment, that foundation was exactly what carried over. Tools change; the ability to read what's riding on a request and a response doesn't.

You can always stack tool knowledge on top of a foundation later. Going the other way is much harder. So if you're going to spend time early, spend it on the foundation.

Pick "boring but durable"

The skills that transfer are usually boring. How communication works, OS basics, how data moves. There's no flash to them, and while you study them you don't get much of a sense that they're paying off.

But you can carry that understanding across roles and across whatever new tool shows up. The only reason I could move from networking into assessment was that the foundation came with me.

If you're starting out and stuck on what to learn first, I'd pick "the thing that'll still exist in ten years" over "the hottest thing right now." It looks like the long way around. It isn't.

The full route I took from network engineering into vulnerability assessment is something I've written up at length elsewhere. If this was useful, follow along.

How I pass IT certifications in about 3 months while working full-time

rudy_candy — Mon, 08 Jun 2026 20:47:21 +0000

I've picked up a handful of IT certifications while working full-time, usually one to three months each. I'm not unusually smart. I just decide how I'm going to study before I start, and that part does most of the work. Here's the method.

Set the finish line as a number

The single thing that helped most was deciding, before I ever booked the exam, the score I had to reach before I was allowed to book it.

For networking certs I'd run through a question bank several times, then switch to exam-simulation mode and keep going until my score sat around 90 to 95 percent. Only then did I register. Not "I feel about ready," but "I hit the number, so I book it." When the trigger is a number, you stop agonizing over whether you're ready.

Cap the timeline, or it never ends

Studying for a cert expands to fill whatever time you give it. The moment I think "half a year is fine," it tends to never finish.

So I set a hard limit up front: three months. Once there's a deadline, the daily amount falls out of simple arithmetic. Work backward from the exam date and the per-day load is usually smaller than you feared, even around a full-time job.

Passive studying didn't stick for me

This one comes with some regret. Studying by watching videos didn't leave much in my head.

While the video plays you feel like you understand it. Then you sit down with a real question and your hand stops. What actually stuck was the active loop: try a problem, get it wrong, try again. Output over input. And instead of buying more and more material, finishing one standard resource cover to cover was faster.

That's the whole thing

Passing certs around a job isn't about willpower for me. It's about the setup. Decide the finish line as a number, cap the timeline, and keep your hands moving on real problems. That alone gets you forward with limited time.

If you happen to have a stretch where time comes in big blocks, like when you're still a student, that's when cramming a cert is most efficient. Use it.

I write the technical notes in long form elsewhere, but the career and "how I actually did it" pieces I keep short like this. If this was useful, follow along.

A Day in the Life of a Vulnerability Assessor in Japan

rudy_candy — Mon, 08 Jun 2026 19:13:22 +0000

People picture this job as someone hammering a keyboard and "hacking in." The reality is much quieter. I work as a vulnerability assessor (a web app pentester) in Japan, and most of my day is slow, careful, repetitive work. Here's what it actually looks like, hour by hour, plus a few things that might be specific to how the industry runs here.

Morning: I don't touch the keyboard first

The first thing I do isn't launch a tool. It's check the scope of the engagement I'm working on that day.

Which domains and screens are in scope, and where am I not allowed to go? I read through whatever the client shared in the pre-engagement hearing (in Japan there's usually a fairly formal kickoff and a signed scope document), and I confirm the test accounts work. Getting sloppy here is how you end up touching a system that wasn't in scope, which is a real incident, not a small mistake. The whole job rests on one rule: only touch what you were given permission to touch. So this check comes before anything else.

Late morning: crawl the app to build a map

Once the scope is clear, I walk through the whole target like a normal user. Log in, move between screens, fill in forms, submit them. The entire time, Burp Suite is quietly recording every request in the background.

At this stage I'm not hunting for bugs yet. I'm building a map: what features exist, and where does this app send and receive data? I also count the requests to estimate how much testing the day will actually take.

Afternoon: change one request, watch what changes

This is the core of the work. I take the recorded requests one at a time, change a parameter, and look at how the response differs. Then again. And again.

Honestly, it's tedious. You repeat almost the same action hundreds of times against different targets, and the dramatic moment almost never comes. But when a response behaves differently than you expected, that "wait, there's something here" instinct kicks in, and it gets sharper the more reps you put in. Whether you can find that tedium interesting is, I think, the real test of fit for this job.

What actually turns up

This is the question I get most: "Do you find dramatic stuff like SQL injection all the time?"

In my experience, the textbook SQL injection you learn on day one isn't that common on modern sites. Frameworks tend to handle it. What I actually run into is quieter.

Broken access control (IDOR)

This is the one I hit most. Change an ID in the URL or request from your own to someone else's, and you can see their data.

It happens because the app checks whether you're logged in, but forgets to check whether you're allowed to see that particular record. During development, people test with their own data only, so it slips through. In a test, I usually set up two accounts and drop one account's ID into the other's request.

Misconfiguration and information leakage

A directory that's exposed when it shouldn't be. An error page that spills the server's internals or a stack trace. A dev file left behind in production. These "forgot to clean up" issues come up constantly.

It's less a vulnerability than leftover mess. I find it by deliberately triggering errors and watching whether the response leaks more than it should, or by knocking on common paths to see what answers back.

Outdated, unpatched components

A library or middleware with a known vulnerability, still running an old version. "It works, so nobody updated it." If a version number shows up in a response header or an error page, you can often guess that the version has a known issue from there.

Line these up and the pattern is clear: the single flashy bug is rarer than the holes that grow out of day-to-day operations. Permission checks that are too loose, cleanup that never happened, updates that got pushed off. That gap between the textbook and the field is the part I didn't expect when I started.

Evening: find it, prove it, put it into words

Finding something isn't the end. The job runs until you've captured how to reproduce it as evidence and written it up in a form that belongs in a report.

Explaining it in language the client understands matters as much as finding it. "This is dangerous" tells them nothing. What happened, what could leak, how to fix it. Whether you can write that is what separates assessors. And in Japan the report is often the actual deliverable the client pays for, so it carries real weight.

So: quiet, but deep

A vulnerability assessor's day is far more low-key than people imagine. Check the scope, build the map, keep testing requests, put what you find into words. That loop, over and over.

But the feeling of catching a "wait, this is off" inside all that quiet checking is hard to get from other work. That's what keeps me in it.

I'm an ex-network engineer who moved into security here in Japan. I'm starting to write about real-world pentesting and what this industry looks like from the inside. If that's interesting, follow along.

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&#124;ctf&#124;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&#124;ctf&#124;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&#124;flag&#124;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&#124;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&#124;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.

DEV Community: rudy_candy

What people get wrong about penetration testing

The reality is shockingly boring

I didn't expect writing to be the hard part

You learn you can't say "it's safe"

It's still a good job

The skills that actually transfer: what to learn for a long career in IT

The hot tool ages out faster than you think

What lasts is the ability to understand how things work

Pick "boring but durable"

How I pass IT certifications in about 3 months while working full-time

Set the finish line as a number

Cap the timeline, or it never ends

Passive studying didn't stick for me

That's the whole thing

A Day in the Life of a Vulnerability Assessor in Japan

Morning: I don't touch the keyboard first

Late morning: crawl the app to build a map

Afternoon: change one request, watch what changes

What actually turns up

Broken access control (IDOR)

Misconfiguration and information leakage

Outdated, unpatched components

Evening: find it, prove it, put it into words

So: quiet, but deep

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