Author: M15tak3(skyman.soul@gmail.com)

A Detailed Guide to CTF Tracks

1. What Is CTF

CTF (Capture The Flag) is a cybersecurity competition format. Players solve challenges through analysis, exploitation, cryptanalysis, reverse engineering, and forensics, then submit a flag (usually a specially formatted string) for points.

The core of CTF is not memorizing tool commands. It is understanding system fundamentals, security mechanisms, and attacker/defender thinking under concrete challenge scenarios.

1.1 Common Competition Formats

• Jeopardy: categorized challenges (Web, Pwn, Reverse, Crypto, Misc, etc.), submit flags one by one.
• Attack-Defense: attack other teams’ services while defending your own.
• King of the Hill: continuously hold target points to gain score.

1.2 Why CTF Matters

• Practical ability: turns fragmented knowledge into complete attack/defense chains.
• Engineering ability: automation, debugging, log analysis, and postmortem habits.
• Collaboration ability: team split, parallel progress, time management, and strategy decisions.

1.3 Typical Challenge Characteristics

• Most problems are built around one exploitable flaw and are not identical to production systems.
• Deliberate noise is common; you must separate useful clues from distractions.
• High-value challenges often require multi-step chaining across domains.

2. Web Track

2.1 Core Focus

Understand how Web applications work, then use design/implementation flaws to extract sensitive data (for example, flags).

2.2 Common Problem Types

• SQL injection (union, error-based, blind, stacked)
• XSS (reflected, stored, DOM-based)
• File upload vulnerabilities (extension bypass, MIME bypass, parser bugs)
• Deserialization issues (PHP/Python/Java)
• SSRF (internal network probing, cloud metadata endpoints)
• Command injection (RCE)
• Auth/session weaknesses (weak passwords, JWT forgery, session fixation)
• Access control bugs (horizontal/vertical privilege bypass)
• SSTI
• Path traversal / local file include (LFI/RFI)

2.3 Knowledge You Need

• HTTP/HTTPS basics (methods, status codes, cookies, headers)
• Backend framework behavior (Flask, Django, PHP, Node, etc.)
• SQL basics (MySQL/PostgreSQL)
• Secure data flow model (input -> processing -> output)
• Encoding/decoding (URL, Base64, Unicode, HTML entities)

2.4 Common Tools

• Burp Suite
• Browser DevTools
• sqlmap
• ffuf / dirsearch
• Postman / curl

2.5 Generic Solving Workflow

1. Inventory pages, endpoints, parameters, and auth flow.
2. Find controllable input points.
3. Test boundary behavior (special chars, long input, type mismatch).
4. Use errors and responses to classify vulnerability type and craft payloads.
5. After initial foothold, expand laterally (file read, privilege escalation, internal probing).

3. Misc Track

3.1 Core Focus

Misc emphasizes information processing, automation, and cross-domain reasoning. It is often about connecting multiple small clues rather than exploiting one single bug.

3.2 Common Problem Types

• Encoding/decoding puzzles
• Steganography (image/audio/text/file tail)
• Traffic analysis (pcap, HTTP/TCP extraction)
• Forensics artifacts (logs, archives, metadata)
• Protocol interaction or small automation games
• QR/barcode/keyboard traffic/Morse-style tasks

3.3 Knowledge You Need

• File format structures (PNG/JPG/ZIP/PDF)
• Network basics (TCP/HTTP/DNS)
• Linux CLI and batch operations
• Python scripting (regex, bytes, batch processing)

3.4 Common Tools

• CyberChef
• Wireshark / tshark
• binwalk / foremost
• stegsolve / zsteg / exiftool
• Python

3.5 Generic Solving Workflow

1. Identify artifact type.
2. Inspect metadata and structure (headers, tails, magic bytes).
3. Try reversible transformations.
4. Script repetitive operations early.

4. Crypto Track

4.1 Core Focus

In CTF, Crypto is usually not about brute-forcing modern algorithms, but about exploiting weak parameters, flawed implementations, or insecure usage.

4.2 Common Problem Types

• Classical ciphers (Caesar, Vigenere, rail fence)
• RSA issues (small exponent, common modulus, weak prime entropy, partial leakage)
• Symmetric misuse (ECB, IV reuse, padding oracle)
• Hash-related issues (length extension, weak collision setups)
• Predictable randomness (weak seeds)

4.3 Knowledge You Need

• Modular arithmetic, Euclid, inverses
• Prime math, Euler phi, fast exponentiation
• Cipher modes (ECB/CBC/CTR/GCM)
• Signature/auth concepts (HMAC, RSA/ECDSA basics)

4.4 Common Tools

• Python + pycryptodome
• SageMath
• factordb / yafu
• RsaCtfTool

4.5 Generic Solving Workflow

1. Decide whether this is algorithmic or implementation-driven.
2. List knowns/unknowns (key, ciphertext, params, oracle behavior).
3. Build mathematical relationships and solvability conditions.
4. Prioritize weak/reused parameters.

5. Pwn Track

5.1 Core Focus

Exploit binary memory-safety flaws to control execution flow and finally read flag or get shell.

5.2 Common Problem Types

• Stack overflow (ret2win, ret2libc, ROP)
• Heap exploitation (UAF, double free, tcache poisoning)
• Format string bugs
• Integer overflow leading to OOB read/write
• Sandbox escape (advanced)

5.3 Knowledge You Need

• C memory model (stack, heap, globals)
• x86/x64 calling conventions
• ELF and dynamic linking
• Linux/syscall fundamentals
• Protections: NX, Canary, PIE, RELRO, ASLR

5.4 Common Tools

• gdb + pwndbg/gef
• pwntools
• checksec
• IDA / Ghidra
• one_gadget / ropper

5.5 Generic Solving Workflow

1. Run checksec.
2. Reverse for controllable input and dangerous code paths.
3. Confirm crash point and offset control.
4. Choose exploit chain based on active mitigations.
5. Port local exploit to remote; handle libc and timing differences.

6. Reverse Track

6.1 Core Focus

Reconstruct program logic through static and dynamic analysis to recover key data, validation rules, or keys.

6.2 Common Problem Types

• String checks and simple obfuscation
• Control-flow flattening/fake branches
• Anti-debug/anti-sandbox
• Custom crypto routine recovery
• APK/so/script mixed reversing

6.3 Knowledge You Need

• Assembly basics
• Compiler optimization side effects
• PE/ELF/APK structures
• Dynamic breakpoint-tracing workflow

6.4 Common Tools

• IDA Pro / Ghidra
• x64dbg / OllyDbg
• gdb
• JADX / apktool
• Frida

6.5 Generic Solving Workflow

1. Execute first and observe IO behavior.
2. Locate critical functions statically.
3. Validate hypotheses with breakpoints.
4. Rebuild algorithm or patch around key verification.

7. AI Security Track

7.1 Core Focus

Focus on attacks/defenses around model, data, inference pipeline, and integration layer.

7.2 Common Problem Types

• Prompt injection
• Jailbreak
• Data leakage (system prompts/private data)
• Tool abuse / privilege overreach
• RAG poisoning/retrieval manipulation
• Model extraction / membership inference
• Adversarial examples

7.3 Knowledge You Need

• LLM role hierarchy (system/user/assistant)
• RAG pipeline (retrieve/rerank/context build)
• Agent tool invocation and permission boundaries
• Input filtering, output policy checks, and safety strategy engines

7.4 Common Methods

• Manual payload crafting across turns and role tricks
• Log auditing for model/tool call traces
• Red-team benchmark sets
• Automated injection test scripts

7.5 Generic Solving Workflow

1. Identify system boundaries.
2. Start with low-risk probing.
3. Escalate by layer (instruction conflicts -> context poisoning -> tool abuse).
4. Confirm reproducibility.
5. Provide mitigations (least privilege, context isolation, policy guardrails).

7.6 Defensive Checklist

• System instructions must not be overridden by user input.
• Separate retrieved context from user text with trust labels.
• Add permission gateways for tool calls (allowlists + auditing).
• Require policy checks / human review for high-risk output.
• Keep full logs for replay and incident tracing.

8. Team Role Suggestions

• Web: endpoint and business-logic vulnerabilities
• Pwn: binary exploitation chain
• Reverse: algorithm reconstruction and helper scripts
• Crypto: math/crypto tasks + validation scripts
• Misc: traffic/steg/mixed fast cleanup
• AI security: model and agent attack surface

Mature teams usually need both ownership and backup for each domain.

9. Conclusion

CTF is not just tool usage. It is the combination of knowledge structure, analysis method, automation ability, and team coordination.

A practical learning path is to deeply specialize in 1-2 tracks first, build stable scoring strength, then gradually expand to other tracks.

Published on 2026-05-14 at M15tak3のBlog, last modified on 2026-05-14

All articles on this blog are licensed under the BY-NC-SA license agreement unless otherwise stated. Please indicate the source when reprinting!

Author: M15tak3(skyman.soul@gmail.com)

When AI Starts Bringing Us Closer to Ithaca…

At some point, I realized my first reaction to a problem had become: ask AI.

At first, that felt exciting. AI was like a lamp you can switch on at any moment, lighting up corners that once took a long time to explore alone. If I did not understand code, I asked it. If I could not explain an error, I asked it. If I had no idea how to start a CTF challenge, I asked it. Web, Reverse, Pwn, Crypto: things that used to require endless searching and trial-and-error suddenly felt much closer.

This is real progress, and I do not want to deny that. AI lowers barriers and removes a lot of meaningless friction. People who were blocked by environment setup, unfamiliar terms, and fragmented documentation can now enter the field more smoothly. For security learners, that help is real. It gives difficult knowledge a softer entry point, and in lonely study hours, it can feel like a tireless companion.

But at the same time, something else is quietly becoming lighter.

In the past, getting stuck in CTF was normal. You could stare at a code fragment and see nothing. You could build payload after payload and get silence. You could get lost in decompiled output, search through traffic captures for one anomaly, and guess the next move of a program from registers and stack frames. Learning was slow. Many nights ended with no beautiful result, only a pile of failed attempts.

Yet when I look back, what stayed with me was exactly that slowness. The moments without immediate answers taught me how to observe. Wrong guesses taught me where the boundaries were. Problems I could not solve for a long time taught me that security is not remembering vulnerability names, but holding on to doubt inside uncertainty.

Now answers arrive too quickly. Sometimes before we have even sat with the question, we rush to submit something. A fluent explanation can replace half an hour of silent reasoning. A complete-looking solution path can make us believe we already understand.

That makes me a little sad. Not because AI is too powerful, but because we are becoming less able to tolerate the state of “not knowing.” Not knowing used to be the most natural entry to learning. It forced us to pause, to admit blank space, to move step by step toward the unknown. Now that blank space gets filled almost instantly. A confident answer appears on screen, well-structured, patient, polished. Anxiety fades for a while.

But understanding may fade with it.

In CTF, the most important thing was never only the flag. The flag can be an endpoint, or just a signal. What truly changes us is the path we walk toward it. Why did you suspect this point? Why does this route work? Why did the other direction fail? Why does the same payload break in a different environment? If we skip that journey and only see the final string, what remains inside is often empty.

AI is excellent at giving answers, but not always at helping people own answers. In cybersecurity, this is especially risky. Security is judgment. It is sensitivity to boundaries. It is distrust of things that “look normal.” AI can explain vulnerabilities, generate scripts, and speak with technical fluency. But it can also be wrong, and often wrong in ways that look right. Smoothness can make errors look respectable, and guesses look like conclusions. Without verification ability, it is easy to mistake that polish for truth.

Sometimes AI feels like a faster road that helps us avoid muddy paths. But some of our strength is built in that mud. We avoid detours, but we also lose time wrestling with real questions. We reach results faster, but not always the essence.

This is not an anti-AI argument. I will keep using it, and I know I depend on it. It helps me see blind spots, save time, and find a starting point in chaos. I just hope I do not forget this: tools can light the road, but they cannot grow eyes for me.

In CTF, maybe the best way to use AI is not to let it replace problem-solving, but to let it accompany us while we stay in front of the problem. It can suggest a direction, but we still need to decide whether there is really a path. It can help write a script, but we still need to know why every line exists. It can produce an answer, but we still need to ask: is this an answer I truly understand?

We are entering an age where answers are cheaper than ever. Precisely because of that, slowing down becomes more precious. Slow is not backward, and it is not incompetence. Slow is respect for the problem. Slow is a way to keep understanding for ourselves.

When everything is compressed into progress bars, outcomes, screenshots, and summaries, slowing down takes courage.

In cybersecurity, rushing is dangerous. Security is not a speed quiz; it is verification. Saying a vulnerability name first does not mean being closer to truth. Producing a payload first does not mean truly understanding the system. Security needs patience, skepticism, and the willingness to pause where things seem reasonable. Many vulnerabilities are not discovered by speed, but by repeated observation, repeated verification, and repeated questioning.

So I hope we can still learn to slow down.

Not to reject AI. Not to return to the past. But to keep a healthy distance while using it. Look at the challenge first. Think about boundaries first. Let the question stay in your head for a while.

Do not rush to cover all blank space with answers, and do not rush to use generated content to silence your insecurity.

Some blank space is worth keeping.

Because that is where thinking begins.

AI can bring us to Ithaca faster.

But before arrival, I still want to know whether we truly saw the sea.

Published on 2026-05-07 at M15tak3のBlog, last modified on 2026-05-07

All articles on this blog are licensed under the BY-NC-SA license agreement unless otherwise stated. Please indicate the source when reprinting!

Author: M15tak3(skyman.soul@gmail.com)

Linux Python Management (Installing and Using pyenv)

On newer Linux versions (for example, Ubuntu 24.04), using pip for system-level package management may trigger the externally-managed-environment error. In other words, the system does not allow direct global package installation with pip.

To avoid breaking the system Python environment and to manage Python versions more cleanly, I recommend using pyenv (plus virtual environments).

Install Build Dependencies

For Ubuntu/Debian:

sudo apt-get update; sudo apt-get install -y make build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncursesw5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev

For CentOS and similar systems:

sudo yum install -y gcc zlib-devel bzip2 bzip2-devel readline-devel sqlite sqlite-devel openssl-devel xz xz-devel libffi-devel findutils

Install pyenv

Install via the official script:

curl https://pyenv.run | bash

Configure Your Shell and Apply

echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc
 
# If you use Zsh, replace .bashrc with .zshrc

source ~/.bashrc
# If you use Zsh, replace .bashrc with .zshrc

# Verify
pyenv --version

Basic pyenv Usage

# pyenv install python-version, e.g. install 3.13.3
pyenv install 3.13.3

# pyenv global python-version, e.g. set global version to 3.13.3
pyenv global 3.13.3

# pyenv local python-version, e.g. set local project version to 3.13.3
cd my-project/
pyenv local 3.13.3

# pyenv shell python-version, e.g. set shell session version to 3.13.3
pyenv shell python-version

# pyenv virtualenv python-version myproject-env, e.g. create ctf env with 3.13.3
pyenv virtualenv 3.13.3 ctf

# pyenv activate myproject-env, e.g. activate ctf env
pyenv activate ctf

# pyenv deactivate, exit virtual environment
pyenv deactivate

Published on 2026-05-06 at M15tak3のBlog, last modified on 2026-05-06

All articles on this blog are licensed under the BY-NC-SA license agreement unless otherwise stated. Please indicate the source when reprinting!

Author: M15tak3(skyman.soul@gmail.com)

Installing WSL2 + Ubuntu from Scratch

Before You Start

You can think of WSL as a lightweight VM that gives much better local file interaction than VMware under Windows.

Note: after installing a Linux subsystem, if you later upgrade Windows from Home to Pro, subsystem file corruption can happen. Please keep backups.

Installing WSL

Enable Required Features

Open: Windows Settings -> System -> Optional features -> More Windows features

Enable Windows Subsystem for Linux and Virtual Machine Platform, then click OK. Windows will install these features and ask for a reboot.

Install WSL Ubuntu

Open a terminal and run:

wsl --install -d Ubuntu-22.04

The system will automatically pull Ubuntu 24.04 in this setup, so just wait for the progress to finish.

After installation, the subsystem starts automatically and asks you to create a username. Username rules vary slightly by distro; if your name is rejected, adjust it accordingly.

Move the Subsystem to Another Drive

By default, WSL installs distributions under drive C. If you want to move it, first run exit in the Linux shell.

Then shut down all WSL VMs and export the installed Ubuntu 22.04 for backup:

wsl --shutdown
wsl --export Ubuntu-22.04 E:\WSL\ubuntu2204.tar

You can choose your own path, but the exported file must end with .tar.

Now unregister the current distro and import it to your target location:

wsl --unregister Ubuntu-22.04
wsl --import Ubuntu-22.04 E:\WSL\Ubuntu2204 E:\WSL\ubuntu2204.tar
wsl -d Ubuntu-22.04

After that, the subsystem location is changed, and your files stay intact.

Published on 2026-05-06 at M15tak3のBlog, last modified on 2026-05-06

All articles on this blog are licensed under the BY-NC-SA license agreement unless otherwise stated. Please indicate the source when reprinting!