Why Document a CTF Task Solution
Write-up is not a report for the report. It is a tool that works in three directions. More details – in our review, creating ctf tasks.
Memory and speed. CTF categories are built on repeating patterns. Web-tasks often follow the scheme "source code inspection → parameters test → vulnerability confirmation". Forensics – “determine file type → extract data → analyze metadata.” Crypto – recognize the encoding and apply the correct decoding method. If you do not fix the pattern after the decision, in a month you will have to re-understand. Documenting a CTF solution turns a one-off insight into a reproducible recipe. I checked on myself: the task, which decided two hours, six months later on his own write-up restored in ten minutes.
Contribution to the community. The official decision from the organizers is one way to the flag, usually the most direct. Your path, let the winding, demonstrate alternative techniques and non-standard thinking. For a beginner stuck on a task, someone else’s CTF-taska can be the moment when everything falls into place. It is the write-up culture that transforms the CTF from a closed club into an educational environment.
What to fix during the decision of the task
The main mistake is to hope for memory and bash_history. After 48 hours without sleep, the history of the commands in the terminal turns into a porridge, and the sequence of reasoning disappears completely. Start the note file before the first command - then it will be too late.
Minimum set of notes during CTF
Format – Markdown, because it will become the basis of writing-up without reformatting. Tool – Obsidian, CherryTree or regular .md file in any editor. The main thing is not the tool, but the habit of writing.
What to record in real time:
The Task Condition. Copy the text of the task, take a screenshot. After the end of the CTF, the platform may become unavailable, and the condition is part of the context, without which write-up loses its meaning.
The first observations. What saw that it seemed strange, what hypotheses arose. One or two sentences, no more.
Effective teams. Not the full log of the terminal, but those teams after which something changed. Copy with the conclusion.
Deadlocks. Where they went and why it didn't work. Paradoxically, this is the most valuable part for future readers – and for yourself.
Practical Tip: Create a template folder with subfolders screenshots/, files/, scripts/ and file notes.md. In the competition, just copy the template and rename it - you do not spend time on organizing in the midst of a solution.
The time for the final write-up after the CTF is 10-15 minutes on the tack, if the notes were kept in the process. Without notes - from an hour and above, and with holes in logic that can no longer be restored.
Write-up Structure: A 7-block Template
A good write-up answers a small set of questions in predictable order. The predictability here is not minus, but plus: the reader knows in advance where to look for the right. Below is a template that can be copied to Obsidian or any Markdown editor.
Block 1. Metadata. Name CTF, job title, category (Web / Crypto / Forensics / Pwn / Reverse / OSINT), number of points or difficulty level, date of conduct. The P=NP command in its write-up checklist correctly notes: the category is needed for the reader to immediately understand the task area, and the glasses to assess the complexity. No metadata write-up hangs in the air.
Unit 2. Condition of assignment. Full text of the task, description of attached files. URL, interface screenshot, hints from organizers - everything here. The goal: to give the reader the same starting point that you had.
Unit 3. Intelligence and first observations. What did you see when you first opened the mission. Don’t start with the finale – start with what you noticed. “Opened a page – login form, but in URL the parameter debug=false." The block allows the reader to follow your CTF methodology from a zero-point.
Unit 4. Progress of the decision. Step-by-step chain: action → result → output → next action. It's the core of write-up. Do not list the commands without explanation - explain why you have moved from one step to another. “I saw the parameter debug → tried debug=true → received a stack trace → noticed the way to the config of the database. " Every transition must be understood by a person who sees the tuck for the first time.
Block 5. Code and key teams. If you wrote a script, show it with comments on the key lines. If you used a standard tool, bring a specific command with flags and explain the choice of these flags. Showing code – give the reader a tool. Explain the key lines – teach them to use.
Unit 6. Flag and outcome. The flag itself (if the CTF rules allow publication) and a brief summary: what was the vulnerability or trick. Two sentences maximum.
Block 7. Lessons learned. What new learned, what a pattern to remember, what to try first in a similar task. On the recommendation of Elite Era Security, it is the lessons lessons block that makes the write-up overuse: in six months, open and in 30 seconds, remember the essence without re-reading the entire analysis.
The optional block is alternative solutions. If you know that the task was decided otherwise, mention. Indicating alternatives shows a deep understanding of the task. For the Github portfolio of CTF, this highlights the author among those who settled on the first working option.
Example of writing-up: analysis of Web-task
The difference between a bad and a good write-up is most obvious on the same tack. Take a simple Web: “Find the flag on the page.”
What does writing-up look like without context
Opened the site, looked at the source, found a comment from base64, decoded, received flag{s0urc3_c0d3_r3v13w}.
Four problems: no metadata (which CTF, category, glasses), no condition, no explanation of logic (why the author flew into the source code, not in cookies or titles), there are no lessons. The reader can neither repeat the decision nor learn anything.
How to make a CTF solution competently - the same task
Metadata: ExampleCTF 2025 / Hidden Comment / Web / 100 pts / Easy.
Condition: “Find the flag on the page. URL: http://chall.example.com:8080."
Intelligence: page is a standard landing page without forms and interactive. Nothing suspicious in the visible part. Task for 100 points in the Web category - at this level of complexity, the first action: view the source code of the page (Ctrl+U).
Solution:
Opened the source code. In the end <body> Discovered an HTML comment: <!-- ZmxhZ3tzMHVyYzNfYzBkM19yM3YxM3d9 -->.
The line is similar to Base64: Latin, numbers, multiple length 4, no special characters except +, /, =.
Decoded via CyberChef (Operation From Base64). Result: flag{s0urc3_c0d3_r3v13w}.
Flag: flag{s0urc3_c0d3_r3v13w}.
Lessons: in easy Web-tasks always start by viewing the source code of the page. HTML comments are a typical place for hidden data. Lines of symbols [A-Za-z0-9+/=] First candidate for Base64.
The same tack, the same complexity - but the second option can be reused in six months, show at an interview and find a text search in the archive. That’s the whole difference between “I decided to pull” and “I have a write-up CTF that works as a directory.”
Checkout write-up in Markdown
Key Formatting Rules for Readability:
Titles through ## and ### create navigation. Do not use more than three levels of nesting: the write-up structure is not so deep.
Code blocks – triple reverse quotes with language indication (```python, ```bash). This includes syntax illumination on all platforms.
Inline code — single reverse quotes for file names, parameters, short commands: nmap -sV target. Do not create a separate block for one line.
Numbered lists for step-by-step actions. Marked – for transfers without order.
Fat text for key terms at the first mention, but without abuse. If everything is allocated, nothing is allocated.
Code in write-up: how not to turn the parsing into a terminal log
A frequent problem is inserting a full output nmap -sV -sC -A -p- target, occupying two screens. The reader is drowning and does not understand what is important.
Rule: Show only the lines that have influenced the decision. Reduce the rest to [...] or describe the text. Instead of 50 lines of output, there will be enough of a single sentence: “Namap discovered open ports 22 (SSH), 80 (HTTP) and 8080 (Apache Tomcat 9.0.31).” All the information is in place, and the attention is focused on what moves the solution forward.
Insert the code only when meaning is lost without it. Two or three blocks for the whole analysis is the optimum. Each is not longer than ten lines. If the exploit script is longer, put the file in the repository, and in write-up show a key fragment with comments to important lines.
To convert Markdown to PDF with table of contents and backlighting code is convenient Pandoc with Eisvogel Template: pandoc writeup.md -o writeup.pdf --from markdown --template eisvogel --listings. The result is a neat document for the portfolio. Ryan Kozak describes this bundle in its workflow: Markdown is written once, generated by PDF, the same file with minimal header edits becomes a post for a blog on Jekyll. One write-up - two formats, a minimum of manual work.
Write-up is not a report for the report. It is a tool that works in three directions. More details – in our review, creating ctf tasks.
Memory and speed. CTF categories are built on repeating patterns. Web-tasks often follow the scheme "source code inspection → parameters test → vulnerability confirmation". Forensics – “determine file type → extract data → analyze metadata.” Crypto – recognize the encoding and apply the correct decoding method. If you do not fix the pattern after the decision, in a month you will have to re-understand. Documenting a CTF solution turns a one-off insight into a reproducible recipe. I checked on myself: the task, which decided two hours, six months later on his own write-up restored in ten minutes.
Contribution to the community. The official decision from the organizers is one way to the flag, usually the most direct. Your path, let the winding, demonstrate alternative techniques and non-standard thinking. For a beginner stuck on a task, someone else’s CTF-taska can be the moment when everything falls into place. It is the write-up culture that transforms the CTF from a closed club into an educational environment.
What to fix during the decision of the task
The main mistake is to hope for memory and bash_history. After 48 hours without sleep, the history of the commands in the terminal turns into a porridge, and the sequence of reasoning disappears completely. Start the note file before the first command - then it will be too late.
Minimum set of notes during CTF
Format – Markdown, because it will become the basis of writing-up without reformatting. Tool – Obsidian, CherryTree or regular .md file in any editor. The main thing is not the tool, but the habit of writing.
What to record in real time:
The Task Condition. Copy the text of the task, take a screenshot. After the end of the CTF, the platform may become unavailable, and the condition is part of the context, without which write-up loses its meaning.
The first observations. What saw that it seemed strange, what hypotheses arose. One or two sentences, no more.
Effective teams. Not the full log of the terminal, but those teams after which something changed. Copy with the conclusion.
Deadlocks. Where they went and why it didn't work. Paradoxically, this is the most valuable part for future readers – and for yourself.
Practical Tip: Create a template folder with subfolders screenshots/, files/, scripts/ and file notes.md. In the competition, just copy the template and rename it - you do not spend time on organizing in the midst of a solution.
The time for the final write-up after the CTF is 10-15 minutes on the tack, if the notes were kept in the process. Without notes - from an hour and above, and with holes in logic that can no longer be restored.
Write-up Structure: A 7-block Template
A good write-up answers a small set of questions in predictable order. The predictability here is not minus, but plus: the reader knows in advance where to look for the right. Below is a template that can be copied to Obsidian or any Markdown editor.
Block 1. Metadata. Name CTF, job title, category (Web / Crypto / Forensics / Pwn / Reverse / OSINT), number of points or difficulty level, date of conduct. The P=NP command in its write-up checklist correctly notes: the category is needed for the reader to immediately understand the task area, and the glasses to assess the complexity. No metadata write-up hangs in the air.
Unit 2. Condition of assignment. Full text of the task, description of attached files. URL, interface screenshot, hints from organizers - everything here. The goal: to give the reader the same starting point that you had.
Unit 3. Intelligence and first observations. What did you see when you first opened the mission. Don’t start with the finale – start with what you noticed. “Opened a page – login form, but in URL the parameter debug=false." The block allows the reader to follow your CTF methodology from a zero-point.
Unit 4. Progress of the decision. Step-by-step chain: action → result → output → next action. It's the core of write-up. Do not list the commands without explanation - explain why you have moved from one step to another. “I saw the parameter debug → tried debug=true → received a stack trace → noticed the way to the config of the database. " Every transition must be understood by a person who sees the tuck for the first time.
Block 5. Code and key teams. If you wrote a script, show it with comments on the key lines. If you used a standard tool, bring a specific command with flags and explain the choice of these flags. Showing code – give the reader a tool. Explain the key lines – teach them to use.
Unit 6. Flag and outcome. The flag itself (if the CTF rules allow publication) and a brief summary: what was the vulnerability or trick. Two sentences maximum.
Block 7. Lessons learned. What new learned, what a pattern to remember, what to try first in a similar task. On the recommendation of Elite Era Security, it is the lessons lessons block that makes the write-up overuse: in six months, open and in 30 seconds, remember the essence without re-reading the entire analysis.
The optional block is alternative solutions. If you know that the task was decided otherwise, mention. Indicating alternatives shows a deep understanding of the task. For the Github portfolio of CTF, this highlights the author among those who settled on the first working option.
Example of writing-up: analysis of Web-task
The difference between a bad and a good write-up is most obvious on the same tack. Take a simple Web: “Find the flag on the page.”
What does writing-up look like without context
Opened the site, looked at the source, found a comment from base64, decoded, received flag{s0urc3_c0d3_r3v13w}.
Four problems: no metadata (which CTF, category, glasses), no condition, no explanation of logic (why the author flew into the source code, not in cookies or titles), there are no lessons. The reader can neither repeat the decision nor learn anything.
How to make a CTF solution competently - the same task
Metadata: ExampleCTF 2025 / Hidden Comment / Web / 100 pts / Easy.
Condition: “Find the flag on the page. URL: http://chall.example.com:8080."
Intelligence: page is a standard landing page without forms and interactive. Nothing suspicious in the visible part. Task for 100 points in the Web category - at this level of complexity, the first action: view the source code of the page (Ctrl+U).
Solution:
Opened the source code. In the end <body> Discovered an HTML comment: <!-- ZmxhZ3tzMHVyYzNfYzBkM19yM3YxM3d9 -->.
The line is similar to Base64: Latin, numbers, multiple length 4, no special characters except +, /, =.
Decoded via CyberChef (Operation From Base64). Result: flag{s0urc3_c0d3_r3v13w}.
Flag: flag{s0urc3_c0d3_r3v13w}.
Lessons: in easy Web-tasks always start by viewing the source code of the page. HTML comments are a typical place for hidden data. Lines of symbols [A-Za-z0-9+/=] First candidate for Base64.
The same tack, the same complexity - but the second option can be reused in six months, show at an interview and find a text search in the archive. That’s the whole difference between “I decided to pull” and “I have a write-up CTF that works as a directory.”
Checkout write-up in Markdown
Key Formatting Rules for Readability:
Titles through ## and ### create navigation. Do not use more than three levels of nesting: the write-up structure is not so deep.
Code blocks – triple reverse quotes with language indication (```python, ```bash). This includes syntax illumination on all platforms.
Inline code — single reverse quotes for file names, parameters, short commands: nmap -sV target. Do not create a separate block for one line.
Numbered lists for step-by-step actions. Marked – for transfers without order.
Fat text for key terms at the first mention, but without abuse. If everything is allocated, nothing is allocated.
Code in write-up: how not to turn the parsing into a terminal log
A frequent problem is inserting a full output nmap -sV -sC -A -p- target, occupying two screens. The reader is drowning and does not understand what is important.
Rule: Show only the lines that have influenced the decision. Reduce the rest to [...] or describe the text. Instead of 50 lines of output, there will be enough of a single sentence: “Namap discovered open ports 22 (SSH), 80 (HTTP) and 8080 (Apache Tomcat 9.0.31).” All the information is in place, and the attention is focused on what moves the solution forward.
Insert the code only when meaning is lost without it. Two or three blocks for the whole analysis is the optimum. Each is not longer than ten lines. If the exploit script is longer, put the file in the repository, and in write-up show a key fragment with comments to important lines.
To convert Markdown to PDF with table of contents and backlighting code is convenient Pandoc with Eisvogel Template: pandoc writeup.md -o writeup.pdf --from markdown --template eisvogel --listings. The result is a neat document for the portfolio. Ryan Kozak describes this bundle in its workflow: Markdown is written once, generated by PDF, the same file with minimal header edits becomes a post for a blog on Jekyll. One write-up - two formats, a minimum of manual work.
