Add files via upload

Author: Denarzai

_posts/2026-06-26-bandit-level-9-10.md

@@ -0,0 +1,74 @@
+---
+title: "OverTheWire Bandit: Level 9 to Level 10"
+date: 2026-06-26 19:40:00 +0500
+categories: [CTF, Bandit]
+tags: [linux, strings, grep, binary, piping, overthewire, beginner]
+---
+
+## The Goal
+
+Find the password in `data.txt` — stored in one of the few human-readable strings, preceded by several `=` characters.
+
+## What I Did
+
+The level mentioned "human-readable strings" which immediately suggested the file wasn't plain text. I checked the `strings` man page first, then ran it on the file:
+
+```bash
+bandit9@bandit:~$ strings data.txt
+```
+
+That printed a wall of readable text extracted from what was otherwise a binary file. Too much to read through manually. Since the level said the password was preceded by `=` signs, I piped the output into `grep`:
+
+```bash
+bandit9@bandit:~$ strings data.txt | grep "="
+```
+
+That filtered the output down to only lines containing `=`, one of which had several `=` signs followed by the password.
+
+## What Was Actually Happening
+
+**`data.txt` is a binary file** — not plain text. Running `cat` on it would flood the terminal with garbage characters. The file contains mostly non-printable binary data with a few human-readable strings embedded inside it.
+
+**`strings`** scans a file and extracts sequences of printable characters above a minimum length (4 by default). It ignores everything else — all the binary noise — and outputs only the readable parts. This is how you pull text out of executables, compressed files, or any binary format.
+
+**`grep "="`** then filtered that output for lines containing `=`. Since the password was described as being preceded by multiple `=` characters, this narrowed the results immediately to the relevant line.
+
+The pipe connects both — `strings` output flows directly into `grep` without touching disk.
+
+## Other Ways I Could Have Done It
+
+**`strings` with minimum length filter:**
+```bash
+strings -n 10 data.txt | grep "="
+```
+`-n 10` only extracts strings of 10 characters or longer, cutting out short fragments that add noise.
+
+**`grep -a` directly on the binary:**
+```bash
+grep -a "===" data.txt
+```
+The `-a` flag forces `grep` to treat a binary file as text. Works but produces messier output with binary characters mixed in.
+
+**`xxd` for inspection:**
+```bash
+xxd data.txt | grep "==="
+```
+`xxd` shows a hex dump with ASCII characters on the side. Useful for low-level inspection of binary content but much harder to read than `strings`.
+
+`strings | grep` is the cleanest approach for this type of problem.
+
+## What I Learned
+
+**`strings` extracts readable text from binary files.** Any time a file isn't plain text — executables, compressed archives, unknown formats — `strings` is the first tool to reach for when you want to see what readable content is inside.
+
+**Binary files will break `cat`.** Your terminal fills with garbage characters and sometimes gets into a broken state. Always check what type of file you're dealing with using `file` before reading it.
+
+**Piping filters progressively.** `strings` does the broad extraction, `grep` does the precise filtering. Each command does one thing. The pipe connects them.
+
+## Commands Used
+
+| Command | What it did |
+|---|---|
+| `man strings` | Checked what strings does before using it |
+| `strings data.txt` | Extracted all human-readable text from the binary file |
+| `strings data.txt \| grep "="` | Filtered output to lines containing `=` signs |