Step 89. Markdown Documentation — Your Own Personal Wiki

Level 1 — Programming and the Inside of a Computer | Difficulty ★☆☆☆☆ | Estimated time: 2 hours

Prerequisites: markdown basics from Step 47 and Git usage from Steps 86–88.

What you need: a text editor and Git Bash. No new tools today — this is the day we bind markdown, Git, and GitHub together into a "record-keeping system."
Caution: don’t aim for perfect documents. "Can I find this by searching six months from now?" is the only criterion.

Let me tell you one brutal fact. Six months from now, you won’t remember who you are today. Even that "how did I fix that error?" that’s fresh in your mind right now becomes a blank page in three months. Security study accumulates such a huge volume that this problem arrives faster than in other fields. That’s why hackers have an old saying — half of learning to hack is writing things down. From today, you’re both "a person who learns" and "a person who records."

1. Learning Objectives

By the end of this chapter, you will be able to:

Write technical documents with the seven core pieces of markdown syntax
Write concept documents in a three-slot structure: "one-line summary / hands-on commands / where I got stuck"
Record verbatim errors and their fixes in a troubleshooting document
Move around inside the wiki with a README index and links between documents
Review documents against the "searchability" criterion and set maintenance rules

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Markdown + Git Bash (version control), GitHub (optional, for publishing)
Today’s syntax	Headings (`#`), inline code (`), code blocks (```), lists (`-`), links, bold, quotes
Concepts needed	Second brain, three-slot document structure, searchability, README index
Today’s artifact	A personal wiki repository `security-wiki` managed with Git

2-1. The Second Brain — Separating What to Memorize from What to Look Up

The human brain is strong at "knowing where something is" and weak at "remembering it exactly." So the core principle of knowledge management is this — concepts and principles go in your head; commands and detailed procedures go in the wiki. This system is commonly called a "second brain."

There’s a test for whether your wiki is well built: if you can answer "what was that filter in Wireshark that picks out only scan patterns?" within 30 seconds, you pass. The trick to making searches hit is to write things in the words you actually use.

2-2. Markdown Review — Seven Pieces Are Enough

Let’s re-lay the syntax you learned in Step 47 in the order you’ll use it today.

Syntax	How to write it	Purpose
Heading	`#`, `##`, `###`	The document’s table-of-contents skeleton
Inline code	`git status`	A single command word
Code block	```python	Multi-line commands and code
List	`-`	Listing out steps
Link	`[title](address)`	Connecting references and documents
Bold	`<strong>important</strong>`	Marking warnings and key points
Quote	`>`	Quoting original text

If you attach a language name like python or bash when opening a code block, GitHub adds syntax coloring and makes it easier to read. With just these seven pieces you can write 95% of a CTF write-up. When the day comes that you need the other 5%, learn it then.

2-3. The Structure of a Good Note — Three Slots

This is not a research paper — it’s a manual your future self will use, so a simple structure wins.

# Concept name
 ## One-line summary   ← what was this again?
 ## Hands-on commands  ← so what did I type?
 ## Where I got stuck  ← where did I struggle?

The "where I got stuck" slot is the heart of this wiki. Error messages and their fixes are the highest search-value information — because the same error always comes back.

3. Follow Along

3-1. Opening the Wiki Repository

Input:

mkdir security-wiki && cd security-wiki && git init

Output (measured 2026-09-09): Initialized empty Git repository in .../security-wiki/.git/

How to read it: if Step 87’s security-study was the showroom for "what you made," this security-wiki is the warehouse for "what you know." The reason to separate the two is to narrow the search scope. If you want to put it on GitHub, connect it following Step 87’s procedure exactly.

Why: managing the wiki with Git too means the organizing itself piles up as commits and fills in your GitHub contribution graph. Your study record and the record of that record become one body.

3-2. First Document — Organizing One Concept

Input: create a file called HTTP.md.

# HTTP

 ## One-line summary
The web's conversation protocol. A stateless dialogue of request (client) → response (server).

 ## Hands-on commands
```bash
curl -v http://neverssl.com
```
`-v` lets you see all the request/response headers.

 ## Where I got stuck
- Since it's plaintext, the contents were plainly visible in Wireshark (Step 85).
- Non-standard ports like `tcp.port == 8000` aren't caught by the `http` filter.

How to read it: the three-slot structure is right there. It’s fine if the "one-line summary" looks lazy — as long as your memory revives at the first line when you search and open it, that’s enough.

Why: the first document is the specimen of the wiki. The next 100 documents will follow this format, so don’t force the format to be fancy.

3-3. Troubleshooting Collection — An Error Diary

Input: create troubleshooting.md.

# Troubleshooting Collection

 ## Git: "Password authentication is not supported"
- Cause: GitHub discontinued password authentication
- Fix: issue a PAT → enter the token in place of the password (Step 87)

 ## nmap: "Host seems down"
- Cause: host with ping blocked
- Fix: skip ping with the `-Pn` option (Step 81)

Fill this file with the errors you’ve encountered so far and their fixes. Commit after entering (measured 2026-09-09):

3af1be6 docs: HTTP, troubleshooting collection

How to read it: write error messages verbatim — because you search with exact strings. Source markers like "(Step 87)" next to fixes are your lifeline when you need context later.

Why: the difference between an expert and a beginner isn’t "do you avoid errors" but "do you avoid getting stuck on the same error twice." Someone who re-labels the moment they hit an error — not as a failure but as "a new product has arrived to be stocked in the wiki" — grows fast.

3-4. Make a Prediction — What Kind of Document Gets Found by Search?

Three months from now, you search for "token." Which document will come up?

(a) A document titled "About authentication" with only long explanations
(b) A document with the verbatim error "Password authentication is not supported"

Check for yourself: test it with a terminal search in the wiki you just made.

grep -rn "authentication" . --include="*.md"
grep -rn "token" . --include="*.md"

Output (measured 2026-09-09):

./troubleshooting.md:3:## Git: "Password authentication is not supported"

./troubleshooting.md:5:- Fix: issue a PAT → enter the token in place of the password

The answer is (b). A document with the verbatim error gets caught by both the "authentication" and "token" searches. Your editor’s Ctrl+F works on the same principle.

Why it matters: the quality of a note is decided not "when you write it" but "when you look for it." There’s one rule — plant the words your future self is likely to type into the search box inside the document.

3-5. Stacking Five Documents — Doubling as a Review of What You’ve Learned

Input: pick five things you’ve learned so far and make each one a file. Recommended list:

pointers.md (C language from Steps 49–50)
virtual-memory.md (Step 69)
socket-communication.md (Steps 77–78)
nmap.md (Step 81)
Wireshark.md (Steps 83–84)

How to read it: 10–15 minutes per document is enough. Don’t reopen the book — write from memory, then check the main text and fix only the wrong parts. The act of pulling from memory itself creates most of the review effect. Leave a commit like "docs: nmap notes" for each document.

3-6. The Wiki’s Table of Contents — Building an Index with the README

Input: the wiki’s README.md:

# security-wiki

A personal security-study wiki. A manual for me, six months from now.

 ## Concept notes
- [HTTP](HTTP.md)
- [Pointers](pointers.md)
- [nmap](nmap.md)

 ## Error diary
- [Troubleshooting collection](troubleshooting.md)

 ## Usage rules
10 minutes of documentation after each step. Searchability over perfection.

How to read it: in markdown, [name](filename) becomes a clickable link inside GitHub. The README is both the wiki’s front gate and its index.

Why: once you have more than 50 files, a wiki without a table of contents becomes an abandoned drawer. Solve it with the habit of adding one line to the README every time a document appears. Link documents to each other too — like [Wireshark filter](Wireshark.md) to confirm scan patterns inside nmap.md. Knowledge lasts as long as it’s connected.

3-7. Screenshots in Documents — Adding Images and Folder Rules

A moment comes when words aren’t enough — a single picture of "the screen looked like this" beats ten lines of explanation.

Input:

mkdir images

Save the captured screen as something like images/wireshark-filter.png, and call it up in the document like this.

![Wireshark filter screen](images/wireshark-filter.png)

How to read it: ![description](path) — with an exclamation mark it’s a picture, not a link. The description up front (alt text) is what shows in place of the image if it fails to load, so don’t leave it blank. The path is relative to where the document lives.

Caution: if a real IP or account is captured in the picture, be sure to mask it before uploading. Image files pile up in Git too, so the same warning about past-commit exposure of deleted files (Step 87) applies to images exactly as it does to documents. Use filenames in the date-content.png format — a wiki full of screenshot(27).png is one nobody can search three months later.

3-8. Setting Sustainable Rules

A wiki is harder to maintain than to make. The secret of maintenance is keeping the rules small.

Recommended rules (feel free to copy these as-is):

10 minutes of documentation after each step ends — if you put it off, you never do it
One document doesn’t exceed one screen — if it gets long, split the file
When you hit an error, add 3 lines to troubleshooting.md right after fixing it
On the first weekend of each month, tidy the README index and run a search test — pick any keyword and confirm it’s findable within 30 seconds

Why: the enemy of a record-keeping habit is "perfectionism." A hundred sloppy 10-minute documents are overwhelmingly more useful than one perfect document. And if there’s a rule you can’t keep, don’t blame yourself — split the rule smaller: if "30 minutes a day" collapsed, make it "5 minutes after each step."

4. Missions & Exercises

Mission — Completing Your Personal Wiki

Write 5 concept documents in the three-slot structure (summary/commands/stuck points) in your security-wiki repository
Fill troubleshooting.md with 10 verbatim errors and their fixes
Link every document from the README index
Pile up 5 or more commits, and run a search test with 2 keywords (grep from 3-4 or Ctrl+F)
State your "rules going forward" at the very bottom of the README

Exercises

Exercise 1. In the "second brain" principle, explain the criterion that separates what stays in your head from what goes in the wiki.

Exercise 2. Explain, together with the word "search," why error messages must be written verbatim.

Exercise 3. When you try to include ``` inside a code block to explain it, why does the document break, and what’s the fix?

Exercise 4. You clicked a link between documents on GitHub and got a 404. What’s the most common cause and fix?

5. Model Answers & Completion Criteria

Mission Model Answer

The skeleton is the HTTP.md specimen from 3-2. Five documents × the three-slot structure, and for troubleshooting.md, 10 entries of 3–4 lines each — "error title / cause / fix / source" — is enough. For README index links, match the spelling and capitalization of the filenames exactly.

How to verify: ① does git log --oneline show 5 or more commits? ② does a search like grep -rn "token" . --include="*.md" find the document you want? ③ do the link texts in the README match the actual filenames? ④ are the rules written at the bottom of the README? All "yes" means complete.

Exercise Answers

Answer 1. Concepts and principles ("why does it work this way") stay in your head; commands and detailed procedures ("exactly what did I type") go in the wiki. Since the brain is strong at remembering locations and weak at remembering things exactly, precise strings get made findable instead of memorized.

Answer 2. Because searching is done with exact strings. If you rewrite an error in your own words, it won’t be caught when your future self types the original error into the search box (in the 3-4 measurement, only the document with the verbatim error was caught by the search).

Answer 3. Because the markdown parser interprets the inner ``` as the closing fence first. Fix: wrap the outside with four backticks ( ““). The backtick count only needs to be one more than the inside.

Answer 4. The most common cause is a case mismatch (http.md vs HTTP.md) — GitHub’s servers are case-sensitive. Match the spelling and capitalization of the filename and the link exactly. If links to Korean filenames get tangled, unifying filenames to English is also an option.

Completion Criteria Checklist

[ ] I can use the seven pieces of markdown syntax freely
[ ] I can write concept documents in the three-slot structure (summary/commands/stuck points)
[ ] I’ve started the habit of recording verbatim errors and fixes in a troubleshooting document
[ ] I can move around the wiki via links from the README index
[ ] I can review documents against the "searchability" criterion
[ ] I manage screenshots with the images/ folder and alt-text rules
[ ] Mission: I completed 5 documents and 10 troubleshooting entries

6. Common Pitfalls & Fixes

Wall 1. A code block inside a code block breaks

Symptom: the document becomes a mess because of the ``` you’re trying to explain.
Cause: the markdown parser interprets the inner marker as the closing fence first.
Fix: wrap the outside with four backticks. The backtick count only needs to be one more than the inside.

Wall 2. Clicking a link on GitHub gives a 404

Symptom: a link that works locally breaks on GitHub.
Cause: mostly a case mismatch (http.md vs HTTP.md). GitHub’s servers are case-sensitive.
Fix: match the spelling and capitalization of the filename and the link exactly. If links to Korean filenames get tangled, unifying filenames to English is also an option.

Wall 3. Organizing eats the whole day

Symptom: you’re spending an hour on a single document.
Cause: you’re writing it as "a piece to show others." This wiki has exactly one reader — future you.
Fix: set a timer for 15 minutes. When the time’s up, commit even if it’s unfinished. A single line saying "beef up later" is enough.

Wall 4. I don’t know what to organize

Symptom: you freeze in front of an empty file.
Cause: you’re trying to pick "the important things."
Fix: change the question — "what did I get stuck on today?" Every stuck point is worth documenting. On days with no stuck points, just writing the three command lines you used that day is enough.

Wall 5. Personal info got captured in an uploaded screenshot

Symptom: you pushed a captured screen with a real IP, account, or token visible.
Cause: it’s easy for your inspection eye to go lax on images compared to text.
Fix: open the image and zoom in to inspect it before uploading. If it’s already up — per Step 87’s lesson, deleting isn’t enough. If what got captured is a secret, discarding and reissuing it is the right answer.

7. Summary

Today’s Concepts

Concept	One-line explanation
Second brain	Concepts in your head, commands and procedures in the wiki — separating what to memorize from what to look up
Three-slot structure	One-line summary / hands-on commands / where I got stuck — stuck points are search value #1
Searchability	The criterion for document quality. Plant the search terms your future self will type
README index	The wiki’s front gate and table of contents. Add one line whenever a document appears
Troubleshooting collection	A diary of verbatim errors + causes + fixes. Errors are new products to be stocked
Write-up	A CTF solution report — today’s wiki documents become its raw material later

Today’s Syntax

Syntax	How to write it
Heading	`#`, `##`, `###`
Inline code	`command`
Code block	```language … ``` (when nesting, four backticks outside)
List	`- item`
Link	`[name](filename-or-address)`
Image	`![alt text](images/file.png)`
Bold / quote	`<strong>important</strong>` / `> original text`

An Instinct More Important Than Commands

The real effect of record-keeping isn’t only in "finding it later." The act of writing itself organizes your thinking. As you move a concept into sentences, the sections where "I thought I knew it but it doesn’t hold up in words" reveal themselves — and those holes are exactly what to study next. One more thing: a wiki is a weapon in interviews — few candidates can answer "how did you study?" with a single repository URL. A wiki with 100 commits turns the abstract adjective "consistent" into clickable evidence. Today’s 10 minutes are one page of that evidence.

Once every box is checked, Step 89 is complete. Click the checkbox in the sidebar to save your progress.