Learning

Was ist ein Computer — kurz und klar

Ein PC speichert Daten und führt Programme aus. Für CTFs reicht dieses Bild:

• CPU rechnet und steuert den Ablauf
• RAM ist der schnelle Arbeitsspeicher (leer nach dem Ausschalten)
• Festplatte/SSD speichert dauerhaft Dateien und Programme
• Betriebssystem (Windows, Linux) verwaltet Hardware und startet Programme

Warum das zählt

Challenges sind oft Programme (EXE, ELF) oder Webseiten. Du musst wissen: Was läuft wo, und wo liegen Dateien?

Prozesse

Jedes laufende Programm ist ein Prozess. Er hat eigenen Speicherbereich und Rechte. Im Task-Manager (Windows) oder mit ps/top (Linux) siehst du sie.

Tipp: Stell dir den PC wie eine Werkstatt vor — Tools (Programme), Werkbank (RAM), Schrank (Festplatte).

Dateiformate & Erweiterungen

Die Endung (z. B. .exe, .elf, .js, .html) ist ein Hinweis, was die Datei sein soll — aber kein Garant. Angreifer (und CTFs) benennen Dateien manchmal irreführend.

Typ	Typisch für	Hinweis
.exe	Windows-Programm	Läuft unter Windows (oder Wine)
.elf / ohne Endung	Linux-Programm	Läuft unter Linux
.js / .html	Web	Browser / DevTools
.zip / .7z / .tar.gz	Archiv	erst entpacken
.dll / .so	Bibliothek	wird von Programmen geladen
.pcap	Netzwerk-Mitschnitt	Forensik / Wireshark

Magic Bytes

Viele Dateien starten mit festen Bytes:

• Windows PE: MZ (Hex 4D 5A)
• Linux ELF: ELF (Hex 7F 45 4C 46)
• PNG: 89 50 4E 47

Mit file datei (Linux) oder einem Hex-Editor erkennst du den echten Typ.

Lade Challenge-Dateien nur vom Hub und idealerweise in einer VM, wenn du unsicher bist.

Windows-Grundlagen für CTF

Viele Binaries hier sind Windows PE (.exe).

Was du brauchst

• Programm im Explorer oder in cmd/PowerShell starten
• Ausgabe im Terminal lesen (manche Challenges „reden“ nur so)
• Ordnerpfade verstehen: C:\\Users\\Name\\Downloads\\

PowerShell-Basics

cd ~\Downloads
.\\SlapSalve.exe
Get-FileHash .\\file.exe

Besonderheiten

• Pfade mit \\ statt /
• Rechte: Admin oft nicht nötig für CTFs
• Antivirus kann CTF-Binaries melden (False Positive) — siehe /note

Wichtige Ordner

• Downloads, Desktop
• Temp (%TEMP%) — manchmal landen dort Drops/Logs

Starte unbekannte EXEs am besten in einer isolierten Windows-VM.

Linux-Grundlagen für CTF

Linux ist in der Security-Welt Standard (Server, Tools, viele Binaries).

Wichtige Ideen

• Terminal statt nur Klicks
• Dateien und Programme haben Rechte (lesen/schreiben/ausführen)
• Pfade mit / (z. B. /home/user/)
• Alles ist (fast) eine Datei — auch Geräte unter /dev

Nützliche Kommandos (Einstieg)

ls -la      # Ordnerinhalt inkl. Rechte
cd          # Ordner wechseln
pwd         # aktueller Pfad
file x      # Dateityp raten
strings x   # lesbare Texte in Binaries
chmod +x x  # ausführbar machen
./x         # Programm starten
cat / grep  # lesen / suchen

Rechte kurz

rwx = read / write / execute. Ohne x startet ein Binary nicht mit ./.

Du musst kein Admin-Guru sein — diese Handvoll Befehle deckt viele Easy-Challenges ab.

Netzwerk-Basics: IP, Ports, HTTP

IP-Adresse

Identifiziert einen Rechner im Netz (z. B. 192.168.1.10 im Heimnetz).

Port

Wie eine Türnummer auf dem Rechner. Beispiele:

• 80 / 443 — Web (HTTP / HTTPS)
• 22 — SSH (Linux-Fernzugriff)
• 53 — DNS

HTTP (vereinfacht)

Browser fragt: „Gib mir /login“. Server antwortet mit HTML/JSON und Statuscode (200 ok, 404 nicht gefunden, 302 Redirect).

Für CTFs

Web-Challenges = du sprichst mit einem Server. Manchmal lokal im Browser-Modul, manchmal über APIs.

Merke: Client (Browser/Script) ↔ Server (antwortet). Beide Seiten können interessant sein.

Terminal-Denken & Pfade

Viele CTF-Lösungen leben im Terminal: Programme starten, Ausgaben lesen, Tools verketten.

Absolute vs. relative Pfade

• Absolut: /home/user/chal/flag.txt oder C:\\CTF\\flag.txt
• Relativ: ./flag.txt (im aktuellen Ordner)

Ein-/Ausgabe

• Tastatur → Programm (stdin)
• Programm → Bildschirm (stdout)
• Fehler → oft stderr

Weiterleiten (Linux-Idee)

./prog < input.txt
./prog > out.txt

Wer Pfade und Terminal beherrscht, spart in jeder Kategorie Zeit.

Encoding: Base64, URL, Hex

Encoding ist kein Verschlüsseln — es ist eine andere Schreibweise derselben Daten.

Format	Beispiel	Nutzen
Hex	46 4c 41 47 = FLAG	Speicher-Dumps, Strings
Base64	RkxBR3…	Web, Tokens, Blobs
URL-Encoding	%20 = Leerzeichen	Query-Strings

Tools

• CyberChef (Browser)
• base64 / xxd unter Linux
• Online-Decoder nur mit unkritischen CTF-Daten

Wenn etwas „komisch“ aussieht: erst decoden, dann weiterdenken.

Text, Bytes und Hex — ohne Angst

Computer speichern alles als Bytes (0–255). Menschen lesen oft Hex (41 = A).

Beispiel

Text:  FLAG
Hex:   46 4c 41 47

Little-Endian

Auf x86/x64 liegen mehrbyte-Werte oft „rückwärts“ im Speicher. Bei Stack-Leaks Hex-Blöcke byteweise umdrehen.

ASCII vs. Unicode

CTF-Flags sind meist reines ASCII. Sonderzeichen in Logs können UTF-8 sein.

Du musst Hex nicht auswendig können — das Prinzip reicht für den Einstieg.

VM & sicheres Labor

CTF-Binaries sind Lernmaterial — trotzdem gut isolieren.

Empfehlung

• VirtualBox / VMware / Hyper-V mit Snapshot
• Getrenntes Netz oder Host-Only, wenn du experimentierst
• Snapshots vor riskanten Schritten

Warum?

Fehler, Endlosschleifen, absichtliche Crashes, AV-Quarantäne — in der VM ist das egal.

Hub-Hinweis /note erklärt False-Positives von Antivirus.

Was ist ein CTF?

Capture the Flag = spielerische Security-Rätsel. Du findest eine Flag (geheimen String) und reichst sie im Hub ein.

Typische Kategorien

• Web — Webseiten, JavaScript, Requests
• Reverse — Programm verstehen, ohne Quellcode
• Pwn — Schwachstellen in Programmen ausnutzen (kontrolliert!)
• Crypto / Forensik / Misc — je nach Modul

Schwierigkeitsfarben auf AlienZone

• Einfach (grün) — Einstieg
• Mittel (orange)
• Schwer (rot)
• Extrem (kräftig rot, pulsierend)

Fair Play

Nur die Challenges auf AlienZone angreifen — nicht fremde Systeme.

Punkte und Ranking belohnen erfolgreiche Flags — einmal pro Challenge.

So nutzt du den AlienZone Hub

1. Registrieren / Login mit E-Mail
2. Modul im Hub wählen (Farben = Schwierigkeit)
3. Datei laden oder Web-Modul öffnen
4. Analysieren, knacken, Flag einreichen
5. Im Ranking vergleichen

Flag-Format

Oft FLAG{…} oder challenge-spezifisch. Leerzeichen am Rand stören manchmal — der Hub normalisiert in der Regel.

Profil

Bio, Banner, Links (z. B. Discord) — für Seasons relevant, wenn Teilnahme an Community-Preisen.

Bei „falsch“: Tippfehler, falsche Challenge, oder Flag noch nicht komplett.

Security-Hygiene für Spieler

• Starke, eigene Passwörter (Hub ≠ andere Dienste)
• Keine Flags in öffentlichen Discord-Channels spoilern
• Writeups erst teilen, wenn erlaubt / nach Solve
• Unbekannte Links aus Challenges mit Vorsicht öffnen
• Backups / Snapshots deiner Lab-VM

CTF trainiert Angreifer-Denken — bleib ethisch und im erlaubten Rahmen.

Browser & DevTools — Einstieg

Für Web-Challenges ist der Browser dein Labor. DevTools (meist F12 oder Rechtsklick → Untersuchen) zeigen, was die Seite wirklich tut.

Wichtige Tabs

Tab	Wozu
Elements / Elemente	HTML & CSS der Seite
Console	JavaScript-Fehler, console.log, kleine Tests
Network / Netzwerk	Jeder Request (URL, Status, Body)
Application / Speicher	Cookies, LocalStorage, SessionStorage
Sources	JS-Dateien lesen, Breakpoints

Erste Schritte

1. Challenge öffnen
2. Network-Tab leeren, Aktion klicken (Login, Submit, …)
3. Request anschauen: Methode, Header, Response

Konsolen-Skills

document.cookie
localStorage
location.href

Keine Angst vor roten Fehlern — sie sind oft der Hinweis, was schiefgeht.

Hashes & Prüfsummen

Ein Hash mappt Daten auf einen festen Fingerabdruck. Gleicher Input → gleicher Hash; kleine Änderung → völlig anderer Wert.

Typische Algorithmen

Name	Länge (Hex, grob)	CTF-Nutzung
MD5	32 Zeichen	oft „erraten“ / Rainbow
SHA-1	40	ähnlich
SHA-256	64	Integrität, manchmal Flag-Format

Wozu im CTF?

• Datei verifizieren (Get-FileHash, sha256sum)
• Passwort-Hashes knacken (Hashcat/John — ethisch nur im Lab)
• Integrität von Dumps

Nicht verwechseln

Hash ≠ Verschlüsselung. Aus dem Hash bekommst du die Originaldaten nicht „rückwärts“ (außer Brute-Force bei kurzen Inputs).

Steht in der Challenge „MD5 der Flag“: oft ist der Hash die Prüfung, nicht die Flag selbst.

Ports, Dienste & netcat

Dienste lauschen auf Ports (Nummern). Web oft 80/443, SSH 22, viele CTF-Remote-Tasks z. B. 1337.

Typische Ports merken

Port	Dienst (klassisch)
22	SSH
80 / 443	HTTP / HTTPS
21	FTP (selten)
3306	MySQL
1337 / 9999	oft CTF-Challenges

netcat (nc)

nc host port
# oder
ncat host port

Windows: nmap/ncat oder WSL. Manche Challenges brauchen nur: connecten und Text tippen.

Firewall & Lab

Lokal erreichbar ≠ im Internet offen. In deiner VM darfst du scannen — nicht fremde Netze ohne Erlaubnis.

Remote-Challenge = oft: Host + Port aus der Beschreibung, dann nc oder Browser.

Notizen & Writeup-Gewohnheiten

Gute Spieler verlieren weniger Zeit, weil sie schreiben, was sie schon wissen.

Was notieren?

• Challenge-Name, Kategorie, Punkte
• Erste Beobachtungen (file, Strings, URL)
• Was nicht funktioniert hat (wichtig!)
• Offsets, Hashes, merkwürdige Ausgaben
• Die finale Flag (lokal), bis sie im Hub ist

Writeup-Struktur (später teilen)

1. Ziel der Challenge
2. Recon
3. Kernidee
4. Exploit / Schritte
5. Flag / Learning

Tools

Markdown-Datei, Obsidian, Notion, einfaches Notepad — egal, Hauptsache durchsuchbar.

Spoiler: im Discord erst freigeben, wenn erlaubt. Lernen > spoilern.

Git-Grundlagen (für CTF-Repos)

Git versioniert Dateien. Im CTF brauchst du selten Branches — aber oft: Repo klonen, Historie lesen, gelöschte Secrets finden.

Mini-Vokabeln

• Commit — Snapshot
• Clone — Repo herunterladen
• Log — Geschichte
• .git — Metadaten-Ordner (manchmal öffentlich auf Webservern 👀)

Nützliche Befehle

git clone <url>
git log --oneline
git show <commit>
git checkout <datei-aus-alter-version>

CTF-Klassiker

• .git exposed → mit Tools/Clone rekonstruieren
• Commit-Messages mit Flags oder Passwörtern
• Alte Configs in der History

Nie eigene Secrets committen — auch nicht „nur lokal“, wenn du pushst.

Base64, URL-Encoding & Sonderzeichen

Daten werden oft umkodiert, damit sie sicher in URLs, Cookies oder JSON passen — das ist keine starke Verschlüsselung.

Base64

• Alphabet: A–Z, a–z, 0–9, +, /, Padding =
• Sieht aus wie: RkxBR3suLi59
• Decodieren: Online-Tools, base64 -d, CyberChef, PowerShell

URL-Encoding

Zeichen	Encoding
Leerzeichen	%20 oder +
<	%3C
>	%3E
&	%26

CTF-Tipp

Wenn die Flag „komisch“ aussieht: erst dekodieren, dann raten. Mehrfach-Encoding kommt vor (Base64 in Base64).

CyberChef („From Base64“, „URL decode“) spart Stunden.

Lab, Snapshots & Isolation

CTF-Binaries und unbekannte Dateien gehören nicht auf den Alltagspfad deines Haupt-PCs.

Gute Defaults

1. VM (VirtualBox, VMware, Hyper-V) mit Snapshot
2. Optional: zweiter User / getrennte Downloads
3. Kein automatisches Mounten von USB aus Challenges
4. Host-Firewall und getrennte Browser-Profile fürs Lab

Snapshot-Workflow

1. Saubere Basis-VM
2. Snapshot „clean“
3. Challenge lösen
4. Bei Chaos: zurückrollen

Docker (optional)

Manche Labs laufen in Containern — praktisch, aber Isolation ist nicht magisch. Verstehe, was du startest.

AlienZone: Challenges vom Hub laden; unbekannte Fremdlinks trotzdem mit Vorsicht.

Web-Challenges: Browser & Requests

Web-Module laufen im Browser. Client (JavaScript) und Server tauschen HTTP-Requests aus.

Praktisch

• DevTools (F12): Network, Console, Sources, Application (Cookies/Storage)
• Welche URLs werden aufgerufen? Was kommt als JSON zurück?
• Request-Methode: GET vs POST, Header, Body

Typische Ideen

• Client prüft Passwort nur im JS → Algorithmus nachbauen
• Versteckte API-Endpunkte
• Mehrere „Layer“, die nacheinander freigeschaltet werden

UI allein reicht oft nicht — beobachte den Netzwerk-Traffic.

XSS — Cross-Site Scripting

XSS heißt: Es gelingt, fremden JavaScript-Code in einer Seite auszuführen, die andere Nutzer (oder du selbst im CTF) sehen.

Drei grobe Arten

1. Reflected — Payload steckt in der URL/Request und kommt sofort in der Antwort zurück
2. Stored — Payload wird gespeichert (Kommentar, Profil) und später ausgeliefert
3. DOM-based — unsicheres JS im Browser bastelt HTML aus unzuverlässigen Daten

Warum gefährlich (real)

Session-Klau, Aktionen im Namen des Opfers, Phishing im echten Look der Seite.

CTF-Blick

• Suche Stellen, an denen User-Input im HTML landet
• Teste harmlose Marker: <b>test</b>, dann Script-Kontexte
• Schau, ob Filter nur <script> blocken (Umgehungen lernen — nur im CTF!)

Gegenmittel (Konzept)

Escaping/Encoding von Ausgaben, Content-Security-Policy, sichere Templates.

Auf AlienZone: XSS nur in dafür vorgesehenen Challenges üben — nie „wild“ gegen fremde Sites.

SQL-Injection — die Idee

Wenn eine App SQL-Strings aus User-Input zusammenklebt, kann man die Abfrage verbiegen.

Klassisches Bild

Login-Check in der Datenbank — Input wird Teil der Query statt nur Daten.

Symptome im CTF

• Fehlermeldungen mit SQL-Syntax
• Verhalten ändert sich bei ' oder OR 1=1
• Unterschiedliche Antworten bei wahren/falschen Bedingungen (blind)

Modernes Gegenmittel

Prepared Statements / parametrisierte Queries — Input ist nur Wert, nie Code.

Ziel im CTF: verstehen und Flag holen, nicht echte DBs zerstören.

Cookies, Sessions & Auth im Web

Cookie

Kleines Datum, das der Browser mitschickt. Kann Session-ID, Sprache, Tracking … sein.

Session

Server merkt sich: „Cookie X = User Y ist eingeloggt.“

CTF-Ideen

• Session ohne Login erraten/vorhersagen (selten, aber lehrreich)
• Cookie-Flags: HttpOnly, Secure (Konzept)
• Eigenes Login im Web-Modul ≠ AlienZone-Account

DevTools → Application → Cookies ist dein Freund.

JavaScript lesen für CTFs

Viel Web-Logik steckt in .js-Dateien.

Vorgehen

1. Sources in DevTools öffnen
2. Nach password, flag, fetch, token suchen
3. Schön formatieren (Prettier / DevTools pretty-print)
4. Minifiziertes JS nicht fürchten — suchen statt alles lesen

Typische Muster

• Client-seitige Checks (leicht zu umgehen)
• API-Calls mit festen Pfaden
• Obfuscation (Variablen _0x…) — schrittweise entwirren

Du musst kein Frontend-Profi sein — Suchen und Nachvollziehen reicht oft.

Reverse Engineering — Einstieg

Ziel: Verstehen, was ein Programm tut, ohne (viel) Quellcode.

Reihenfolge für Einsteiger

1. strings / lesbare Texte
2. Programm normal starten, Verhalten notieren
3. Disassembler (Ghidra, IDA Free, Cutter)
4. Wichtige Funktionen finden (Check, Decrypt, Main)

Begriffe

• Disassembly — Maschinenbefehle lesbar
• Decompiler — näher an C
• Import — genutzte Systemfunktionen (z. B. printf)

Nicht alles lesen — suche die Flag-Prüfung oder auffällige Strings.

Format-String — die Idee

Unsicher:

printf(user_input);

Sicher:

printf("%s", user_input);

Mit %x, %p, %s liest man oft Stack-Inhalte (Flag!).

Einstieg

1. Normale Eingabe → Echo?
2. %p.%p.%p… ausprobieren
3. Hex → ASCII (Endianness!)

AlienZone-Beispiel-Mindset: „Slap Salve“-Stil — wiederholen, bis die Flag plappert.

Statische vs. dynamische Analyse

Art	Was	Beispiele
Statisch	Programm ohne Laufen lesen	strings, Ghidra, Code-Review
Dynamisch	Programm laufen lassen und beobachten	Debugger, Logs, Network, Input testen

Gute Mischung

Erst grob statisch orientieren, dann dynamisch Hypothesen prüfen — und umgekehrt.

Wer nur eines von beiden kann, bleibt stecken.

Werkzeugkasten Mittel

Ziel	Tool-Ideen
Web	Browser DevTools, curl, Burp Community
Strings / Data	strings, HxD, CyberChef
Reverse	Ghidra, IDA Free, Cutter
Windows	x64dbg (später), Procmon
Linux	gdb, ltrace/strace (einfach)
Skripte	Python 3

Tipp

Ein Tool tief lernen schlägt zehn halb installierte.

Notiere dir deine persönliche „Standard-Reihenfolge“ pro Kategorie.

HTTP-Methoden & einfache APIs

• GET — etwas holen (oft sichtbar in der URL)
• POST — Daten schicken (Body)
• PUT/PATCH/DELETE — ändern/löschen (REST-APIs)

JSON

Viele CTF-APIs sprechen JSON:

{ "ok": true, "layer": 2, "token": "…" }

Vorgehen

Network-Tab → Request kopieren → mit curl/Python nachbauen → Parameter systematisch ändern.

Layer-Challenges lieben State: Token aus Antwort 1 in Request 2 stecken.

Path Traversal — die Idee

Wenn eine App Dateinamen aus User-Input baut, kann ../ aus dem erlaubten Ordner hinaus führen.

Typische Tests (nur CTF/Lab)

• ../../etc/passwd (Linux-Lab)
• encoded Varianten: %2e%2e%

Gegenmittel (Konzept)

Pfad normalisieren, Allowlist, chroot/jail, nie rohe User-Pfade.

Ziel im CTF oft: Flag-Datei lesen, die „neben“ dem Webroot liegt.

Command Injection — die Idee

User-Input wird unsicher an eine Shell übergeben (system, popen, …). Metazeichen wie ; | && können Befehle anhängen.

CTF-Blick

• Wo baut die App einen Shell-String?
• Blind vs. mit Output
• Filter umgehen nur im erlaubten Scope

Nie gegen fremde Systeme — nur Challenge/Lab.

CSRF — Cross-Site Request Forgery (Idee)

CSRF nutzt, dass der Browser bei Requests an eine Site automatisch Cookies mitschickt. Eine fremde Seite kann so Aktionen im Namen des eingeloggten Users auslösen.

Beispiel-Idee

Du bist bei bank.example eingeloggt. Bösartige Seite triggert POST /transfer — Cookie fliegt mit.

Abwehr (kurz)

• CSRF-Token in Formularen
• SameSite-Cookies
• Re-Auth für kritische Aktionen

CTF

Suche nach State-ändernden Requests ohne Token. Manchmal reicht ein simpler HTML-Form-Auto-Submit.

XSS stiehlt oft Sessions; CSRF reitet auf bestehenden Sessions.

JWT — JSON Web Tokens (Einstieg)

Ein JWT hat typisch drei Base64-Teile: header.payload.signature.

Inhalt

• Header — Algorithmus (HS256, none, …)
• Payload — Claims (sub, role, exp)
• Signature — schützt vor unbemerkter Änderung (wenn korrekt geprüft)

CTF-Klassiker

Trick	Idee
alg: none	Signatur weglassen, Server akzeptiert
weak secret	HS256 mit ratebarem Secret knacken
Key confusion	RS256 vs HS256 verwechseln
Claims ändern	role: admin nach Decode/Encode

Praxis

jwt.io oder jq + Base64 — Payload lesen ist ok; Signatur fälschen nur, wenn der Server schwach ist.

JWT ≠ magisch sicher. Immer Server-Validierung prüfen.

SSTI — Server-Side Template Injection (Idee)

Wenn User-Input in Server-Templates (Jinja2, Twig, Freemarker, …) landet und als Template ausgewertet wird, kann Code auf dem Server laufen.

Erkennen

Probiere harmlose Template-Syntax in Eingabefeldern:

{{7*7}}
${7*7}
<%= 7*7 %>

Wenn 49 zurückkommt: heiße Spur.

Folgen

RCE, Dateilesen, Config-Leaks — je nach Engine und Sandbox.

CTF

Engine identifizieren (Fehlertexte, Payload-Cheatsheets), dann gezielte Payloads. Nicht blind 50 Payloads spammen.

PortSwigger hat exzellente SSTI-Labs — ideal nach dem Einstieg hier.

Web-Recon: Karte der Angriffsfläche

Bevor du exploitest: was gibt es überhaupt?

Checkliste

1. Alle sichtbaren Links und Formulare
2. Network-Tab: XHR/API-Endpunkte
3. robots.txt, sitemap.xml, .git (manchmal)
4. Kommentare im HTML/JS
5. Alte Parameter in JS-Bundles (admin, debug, token)
6. HTTP-Header (Server, X-Powered-By)

Tools (lab)

• Browser DevTools
• curl -i
• optional: ffuf/gobuster (nur erlaubte Targets)

Notiz

Liste der URLs + Methoden + Auth-Bedarf spart Doppelarbeit.

Recon ist langweilig und gewinnt Challenges.

Ghidra — die erste Stunde

Ghidra (NSA, kostenlos) disassembliert und decompiliert Binaries. Für Reverse-Challenges Gold wert.

Start

1. Project anlegen, Binary importieren
2. Analyze (Defaults oft ok)
3. Symbol Tree / Functions
4. Decompiler-Fenster neben Listing

Suchen

• Strings-Fenster → interessante Texte doppelklicken
• XRefs (wer ruft diese Funktion auf?)
• main / entry / WinMain

Tipps

• Funktion umbenennen, wenn du sie verstehst
• Kommentare setzen
• Nicht alles auf einmal lesen — dem Datenfluss der Flag folgen

Alternative

IDA Free, Binary Ninja, radare2/Cutter — Konzept ist ähnlich.

Ein String „FLAG{" ist oft der Einstieg, nicht das Ende der Analyse.

Klassische Crypto: XOR, Caesar & Co.

CTF-Crypto startet oft nicht bei AES-GCM, sondern bei spielerischen Chiffren.

Caesar / ROT

Buchstaben verschieben. ROT13 ist Spezialfall. Brute-Force: 25 Möglichkeiten.

XOR

c = p ⊕ k. Eigenschaften:

• p ⊕ k ⊕ k = p
• Single-Byte-Key: Häufigkeitsanalyse / Brute
• Wiederholter Key: crib dragging

Encoding ≠ Crypto

Base64, Hex, Morse — erst dekodieren, dann knacken.

Werkzeuge

CyberChef, Python, quipqiup (Substitution), dcode.fr

Lies die Challenge: oft steckt der Algorithmus im Namen oder Sample.

HTTP-Proxy: Requests manipulieren

Ein Intercepting Proxy (Burp Community, OWASP ZAP, mitmproxy) sitzt zwischen Browser und Server. Du siehst und änderst Requests live.

Wozu im CTF?

• Parameter ändern (role=user → admin)
• Versteckte Felder freischalten
• Cookies/Header testen
• Repeater: denselben Request feilen

Setup (grobe Idee)

1. Proxy auf 127.0.0.1:8080
2. Browser-Proxy setzen
3. CA-Zertifikat für HTTPS (Lab!)
4. Intercept an, Request anhalten, editieren, forwarden

Alternative ohne GUI

curl mit kopierten Headern aus DevTools — reicht oft.

Nur gegen Lab/Challenge-Hosts. Fremde Systeme = illegal.

Speicher: Stack, Heap, Pointer

Stack

Lokale Variablen, Rückadressen, kurze Lebensdauer. Wächst/schrumpft mit Aufrufen.

Heap

Dynamischer Speicher (malloc / new). Länger lebend — und oft fehleranfällig.

Pointer

Adresse: „Hier liegt etwas.“ Falsche Pointer → Crash oder (in CTFs) Kontrolle.

Adressräume

Jedes Prozess hat (vereinfacht) eigenen Speicher. ASLR verschiebt Basen.

Merke: wo Daten liegen, entscheidet viele Exploits.

Buffer Overflow — die Idee

Mehr Daten als Puffer-Platz → Nachbarn überschreiben (klassisch: Rückadresse).

Schutzmechanismen (kurz)

Schutz	Idee
ASLR	Adressen random
DEP/NX	Daten nicht ausführbar
Canary/Cookie	Overflow erkennen
PIE	Binary selbst verschiebbar

CTF-Realität

Oft absichtlich schwache Builds oder Leak + Bypass als Lernpfad.

Verstehen vor Copy-Paste-Exploits.

Binary-Schutz erkennen

Unter Linux oft:

checksec --file=./chal

Oder in Ghidra/IDA: Imports, Compiler-Flags grob ableiten.

Windows

DEP, ASLR, CFG … — für CTFs reicht: „Läuft mit modernen Defaults?“ und ob es Leaks gibt.

Strategie

1. Schutz notieren
2. Was brauche ich? (Leak? Partial overwrite?)
3. Dann erst Payload bauen

Ohne Inventur der Protections baust du ins Leere.

Windows PE & Linux ELF

PE (.exe)

• Magic MZ
• Sektionen: Code, Daten, Imports
• WinAPI über DLLs (kernel32, …)

ELF

• Magic ELF
• Dynamisch/statisch gelinkt
• ldd, readelf -h (Linux)

Praxis

file, Header ansehen, Imports listen — bevor der Debugger stundenlang läuft.

Endung lügt manchmal — Magic Bytes nicht.

Aufrufe & Calling Conventions (Überblick)

Wenn eine Funktion aufgerufen wird, liegen Argumente und Rückadresse an festen Orten (Register/Stack) — je nach Architektur und OS.

x64 (grobe Faustregel)

• Linux: Argumente u. a. in rdi, rsi, rdx, …
• Windows: u. a. rcx, rdx, r8, r9, …

Wozu?

Debugger und Exploits brauchen das, um Parameter und Rückwege zu verstehen.

Details lernst du on-demand — merke zuerst: Register + Stack = Aufrufzustand.

Debug-Mindset ohne Frust

1. Reproduzieren
2. Verkleinern (eine Variable, ein Schritt)
3. Messen (Log, Breakpoint, Dump)
4. Hypothese → Test → anpassen

Anti-Patterns

• 20 Tools parallel
• Nur raten
• Writeup copy-pasten ohne Verständnis

Notizen

Eingaben, Adressen, was schon widerlegt ist — alles aufschreiben.

Langsam ist schnell.

Logikfehler & Race Conditions (Idee)

Nicht jeder Bug ist ein Overflow.

Logikfehler

„Darf User A das überhaupt?“ — fehlende Checks, TOCTOU im Business-Sinn, falsche Reihenfolge.

Race

Zwei Abläufe gleichzeitig — Zustand wird inkonsistent (Klassiker in Datei-/Kauf-Szenarien).

CTF

Manchmal reicht, Requests parallel zu feuern oder Schritte umzusortieren.

Lies die Challenge-Story: oft steckt der Hinweis in der erlaubten Aktion.

ASLR & PIE — Adressen rutschen

ASLR (Address Space Layout Randomization) verschiebt Module im Speicher bei jedem Start. PIE (Position Independent Executable) macht das Binary selbst relativ.

Folge für Exploits

Harte Adressen aus einem Run funktionieren im nächsten oft nicht.

Was brauchst du?

• Leak (Pointer ausgeben)
• relative Offsets (aus dem Binary/Libc)
• manchmal partial overwrite (nur untere Bytes)

Ohne ASLR üben

Lokal setarch -R / Disable ASLR (nur Lab!) — verstehen, dann mit ASLR.

checksec: PIE/ASLR-Status notieren, bevor du Offsets hardcodest.

Stack Canaries (Stack Cookies)

Ein Canary ist ein geheimer Wert vor der gespeicherten Rückadresse. Overflow zerstört ihn → Programm bricht ab (Stack Smashing Detected).

Erkennen

• __stack_chk_fail in Imports
• checksec: Canary vorhanden

Bypass-Ideen (Überblick)

1. Canary leaken (Format-String, Info-Leak)
2. Byte-für-Byte raten (nur wenn Fork/Worker denselben Canary teilt — klassisch remote)
3. Overflow ohne Canary zu treffen (andere Primitive)

CTF

Viele Lern-Binaries haben Canary aus — lies checksec. Mit Canary: erst Leak-Plan, dann Overflow.

Canary zerstören und hoffen ist selten die Lösung.

Integer-Overflows & Größenfallen

Ganzzahlen haben begrenzte Breite. 255 + 1 in 8 Bit → 0. Negative Werte als Größe → riesige Allocations oder Unterläufe.

Typische Bugs

• Länge prüfen, dann mit anderer Breite allokieren
• signed/unsigned Mischung
• Multiplikation vor Check (n * size wrap)

CTF-Signale

• „Länge“-Felder im Protokoll
• Allokationen mit User-kontrollierter Size
• Vergleiche die „komisch“ wirken (if (len < 0) vs unsigned)

Debug

Werte an der Compare-Instruktion ansehen — oft ist der Wrap schon passiert.

Größenangaben immer misstrauen, besonders wenn sie vom Client kommen.

x64-Assembly — die ersten Befehle

Du musst kein Compiler-Nerd sein — aber ein paar Mnemonics lesen zu können, spart Stunden in Ghidra/Debugger.

Register (Linux x64, grob)

Register	Rolle (Faustregel)
rax	Rückgabewert / allgemein
rdi, rsi, rdx	1.–3. Argument
rsp	Stack-Pointer
rip	nächste Instruktion

Häufige Ops

• mov dest, src — kopieren
• call / ret — Funktionen
• jmp / je / jne — Sprünge
• push / pop — Stack
• cmp + bedingter Sprung — if

Praxis

In Ghidra: Decompiler + Listing parallel. Wenn Decompiler lügt, hilft das Listing.

Lerne Mnemonics on demand an echten Challenges, nicht aus 200-Seiten-Handbuch.

Linux Privilege Escalation (Idee)

Manche Challenges (oder Boot2Root) geben dir eine Shell als User — Ziel: root oder Flag-Datei mit anderen Rechten.

Klassische Checks

id
sudo -l
find / -perm -4000 2>/dev/null   # SUID
getcap -r / 2>/dev/null
cat /etc/crontab

Ideen

• SUID-Binary mit Known Exploit / GTFOBins
• Schreibbare Cron-Jobs / Scripts
• Kernel (selten in kurzen CTFs)
• Falsche Dateirechte auf Flag

AlienZone-Hub

Die meisten Challenges sind kein volles OS-Privesc — aber das Denken hilft bei Dateirechten und SUID-Tasks.

GTFOBins + linPEAS sind Werkzeuge, kein Ersatz für Lesen.

PCAP & Netzwerk-Forensik (Einstieg)

Ein PCAP ist ein Mitschnitt von Paketen. In Wireshark filterst und rekonstruierst du Streams.

Einstieg

1. Datei in Wireshark öffnen
2. Statistik → Conversations / Protocol Hierarchy
3. Follow → TCP Stream
4. Export Objects (HTTP) wenn Web-Traffic

Nützliche Filter

http
tcp.port == 80
dns
frame contains "FLAG"

Typische Funde

• Klartext-Passwörter
• Flags in HTTP-Bodies
• DNS-Tunnel / Base64 in Queries
• Datei-Transfers (FTP, SMB)

strings capture.pcap hilft manchmal — Wireshark ist der Profi-Weg.

Deserialisierung — die Idee

Objekte werden zu Bytes/Text serialisiert und später wieder geladen. Wenn die Daten user-kontrolliert sind, kann das Laden gefährlichen Code auslösen (je nach Sprache/Framework).

Ökosysteme (Beispiele)

Stack	Stichwort
PHP	unserialize, Phar
Java	ObjectInputStream, ysoserial
Python	pickle
.NET	BinaryFormatter (historisch)

CTF-Blick

• Cookie/Parameter sieht aus wie serialisiertes Objekt
• Magic Bytes / Base64-Blobs
• Library-Versionen mit bekannten Gadgets

Defense (kurz)

Niemals untrusted Input deserialisieren; JSON + Schema statt nativer Objects.

Wenn du „gadget chain“ liest: Ketten bekannter Klassen, die zu RCE führen.

Shellcode — nur das Konzept

Shellcode = kleine Maschinenbefehl-Sequenz, die z. B. eine Shell startet. In modernen CTFs oft durch Protections erschwert; manchmal reicht eine vorhandene Funktion (ret2win).

Für den Einstieg wichtiger

• Kontrollfluss übernehmen (EIP/RIP)
• Existierende Gadgets/Funktionen nutzen
• Nicht blind „irgendeinen Shellcode“ pasten

AlienZone: lies die Challenge — oft gibt es einen gewollten Gewinn-Pfad.

ret2win, PLT/GOT (Überblick)

ret2win

Statt komplexem Shellcode: RIP auf eine bereits existierende Gewinn-Funktion lenken (z. B. win() druckt die Flag).

PLT / GOT (Linux, grob)

• PLT — Stub zum Aufruf dynamischer Funktionen
• GOT — Tabelle mit echten Adressen nach Resolve

CTF-Nutzen

Mit Overflow oft: Rückadresse = win oder sinnvoller Libc-Pfad nach Leak.

Suche im Binary nach offensichtlichen win/flag-Funktionen, bevor du ROP baust.

Fuzzing — systematisch Inputs testen

Fuzzing = viele (halb-)automatische Eingaben, um Crashes und Edge-Cases zu finden.

Einfach starten

• Längen: 1, 8, 64, 200, 1000, 4000 Bytes
• Sonderzeichen: %x, ', ../, Nullbytes
• Wiederholen mit Script statt Hand

Fortgeschritten

AFL++, libFuzzer — lohnt bei größeren Binaries, nicht bei jeder Easy-Challenge.

Ein kleines Python-for schlägt planloses Tippen.

Sockets & Remote-Interaktion

Viele Pwn-Challenges laufen remote: du connectest per TCP statt ./local.

Werkzeuge

• nc host port
• pwntools remote()
• Eigenes Python socket

Tipps

• Timeouts und Buffering beachten
• recvuntil / klare Marker
• Lokal mit denselben Offsets verifizieren, wenn Binary da ist

Remote = gleiche Logik, mehr Flakiness — Scripts statt Handklick.

Heap-Exploitation — Landkarte

Auf dem Heap liegen dynamische Objekte. Fehler wie Use-After-Free (free, Pointer behalten) erlauben, „alte“ Strukturen mit neuen Daten zu füllen.

Begriffe

• Chunk — Block
• Alloc / Free — anfordern / freigeben
• Reuse / Reclaim — freier Block wird wiederverwendet
• Metadata — Verwaltungsdaten neben Nutzdaten (allocator-abhängig)

Typischer CTF-Flow (abstrakt)

1. Struktur allokieren
2. free (hängender Pointer)
3. gleich große Allokation → überschreibt Felder (z. B. Funktionszeiger)
4. „alte“ Operation auslösen

Erst Stack/Format-String und Reverse sitzen — dann Heap.

Use-After-Free Muster

Symptom

Objekt freigegeben, Code nutzt es weiter.

Exploit-Idee (CTF)

Nach free Speicher mit kontrollierten Bytes füllen (gleiche Größe), dann Virtual Function / Callback / encrypted pointer missbrauchen.

Analyse

• Welche Menüpunkte alloc/free/use?
• Objektgröße?
• Welche Felder sind kritisch?

Extreme Challenges (z. B. Kernel-/Xeno-Style) bauen genau solche Menü-Spielereien.

Anti-Debug & Evasion

Challenges können Debugger erkennen und Verhalten ändern (kaputter Key, andere Zweige).

Windows-Beispiele (Konzept)

• IsDebuggerPresent
• TLS-Callbacks vor main
• Timing-Checks

Deine Optionen

• Ohne Debugger arbeiten
• Anti-Debug patchen (nur Challenge!)
• Logging/Emulation

Antivirus

Solche Muster triggern Heuristiken — siehe /note.

Wenn’s mit Debugger „komisch“ wird: vielleicht soll es das.

Mehrschichtige Protokolle & State

Module erwarten oft Reihenfolge: Layer 1 → 2 → 3. Zustand steckt in Cookie/Token/Session.

Vorgehen

• Jede Antwort vollständig lesen
• State speichern und mitschicken
• Kleines Script statt Klick-Chaos

Fehlerbilder

• SEQUENCE_VIOLATION / falsche Layer
• Abgelaufene Tokens
• Client unvollständig absichtlich

Das ist näher an echter Arbeit als an einem einzelnen Button.

Pointer-Verschlüsselung (Idee)

Manchmal speichert Code Funktionszeiger vercodet (z. B. XOR mit Adresse). Einfach überschreiben reicht nicht — du musst die Kodierung treffen.

Analyse

1. Wie wird der Pointer gelesen/decodiert?
2. Welche Werte brauchst du zur Laufzeit (Leak)?
3. Payload = encode(ziel)

Leaks (ASLR-Base, Heap-Adresse) + Formel = klassisches Extrem-Puzzle.

ROP — Skizze

Wenn du den Stack kontrollierst, aber keinen eigenen Code ausführen darfst (NX), reihst du existierende Codeschnipsel (Gadgets) aneinander — jeweils endend mit ret.

Braucht

• Leak / bekannte Adressen
• Gadget-Suche (ROPgadget, …)
• Saubere Stack-Pivots manchmal

Für AlienZone

Nur relevant, wenn die Challenge wirklich dahin führt — nicht jeder Extrem-Task ist ROP.

Konzept kennen > blind Tool spammen.

Mehrstufige Exploits planen

Phasen denken

1. Info — Leaks, Layout, Protections
2. Write primitive — was kann ich überschreiben?
3. Control — RIP/Code-Pfad
4. Payload / Flag

Checkliste

• [ ] Repro stabil?
• [ ] Offsets dokumentiert?
• [ ] ASLR an/aus getestet?
• [ ] Script statt manueller Wiederholung?

Extrem = Organisation so wichtig wie Technik.

BROP — Blind Return Oriented Programming

BROP (Blind ROP) ist eine Technik, um ROP zu fahren, wenn du das Binary nicht (vollständig) analysieren kannst — z. B. kein Download, Remote-Service, oder stark blinde Umgebung. Populär geworden u. a. durch die Arbeit von Bittau et al. (Stanford).

Welches Problem löst BROP?

Klassisches ROP braucht:

• bekannte Gadgets (pop rdi; ret, …)
• oft Leaks / feste Adressen

Blind heißt: du siehst kaum Code, hast aber vielleicht:

• einen Crash/Neustart des Dienstes (Worker-Prozess)
• eine Write-What-Where- oder Overflow-Primitive remote
• wiederholbare Verbindungen

Kernidee (vereinfacht)

1. Stack-Control erlangen (Overflow o. Ä.)
2. Durch geschickte Payloads Gadgets und Längen „ertasten“ (oft über Stoppen/Hängen vs. Crash)
3. Genug Gadgets finden, um z. B. write/send für einen Leak zu bauen
4. Danach wie normales ROP weiter (Libc/Base, Shell, Flag lesen)

Typische Bausteine

Baustein	Wozu
Stop gadget	Ausführung „einfrieren“ / Timeout → Signal „hier ging’s noch“
Probe	Adressen systematisch testen
Leak gadget	Speicher nach draußen schicken
Restart	Server startet Worker neu → viele Versuche möglich

Wann lohnt sich BROP?

• Remote, kein Binary (oder stark stripped + kein Dump)
• Dienst crasht und respawnt (klassisch: prefork/worker)
• Du hast zuverlässige Kontrolle über den Instruction-Pointer-Pfad

Abgrenzung

| | ROP | BROP |
|--|-----|------|
| Binary | meist vorhanden | oft nicht |
| Gadgets | aus Datei suchen | remote finden |
| Aufwand | mittel–hoch | sehr hoch, spezielles Setup |

CTF-Hinweis

Auf AlienZone brauchst du BROP nur, wenn die Challenge wirklich blind/remote denkt. Viele Extrem-Module geben dir das Binary — dann ist klassisches Reverse + ROP/Heap oft der kürzere Weg.

BROP ist ein Notfall-Werkzeugkasten, kein Default für jede Pwn-Challenge. Verstehe ROP und Debugging zuerst.

Info-Leaks strategisch nutzen

Ohne Leak oft kein ASLR-Bypass. Leaks können sein:

• Format-String (%p)
• uninitialisierter Speicher
• partial overwrites + Beobachtung
• absichtliche „Debug“-Ausgaben im Menü

Was leaken?

1. Binary/PIE base
2. Libc / module base
3. Heap / Stack pointer

Ein guter Leak spart drei Raten — dokumentiere Adressen und Offsets.

Sandboxes & seccomp (Idee)

Manche Challenges erlauben nach dem Exploit nur noch wenige Syscalls (seccomp). Dann reicht „shell“ nicht — du brauchst open/read/write der Flag-Datei oder einen erlaubten Pfad.

CTF-Blick

• Welche Syscalls sind noch erlaubt?
• Gibt es schon einen offenen FD?
• ORW (open-read-write) statt execve

Lies Challenge-Text und Fehlercodes — Sandbox-Hinweise stehen oft zwischen den Zeilen.

Heap-Techniken: House-of-… Landkarte

In der glibc-Welt haben viele Exploit-Muster Spitznamen (House of …). Du musst sie nicht alle auswendig können — aber die Landkarte kennen.

Beispiele (nur Orientierung)

Name (Idee)	Grob
House of Force	top chunk size → riesige Allocation steuern
House of Spirit	fake chunk freigeben / umleiten
House of Orange	fsop / unsorted bin → IOFILE (historisch)
Tcache poisoning	freelist-Pointer überschreiben (modern)

Wichtiger als Namen

1. Welche Allocator-Version?
2. Welche Bins (tcache, fast, unsorted)?
3. Welche Primitive (UAF, overflow, double free)?

CTF

Oft reicht eine klare Primitive + ein Leak. Nicht 20 Papers lesen, bevor das Binary da ist.

How2Heap (shellphish) ist die Referenz — nach dem ersten UAF-Erfolg.

C++ VTables & virtuelle Calls (Idee)

C++-Objekte mit virtuellen Methoden haben oft einen VTable-Pointer am Objektanfang. Ruft man eine virtuelle Methode auf, springt der Code über diese Tabelle.

Exploit-Idee

Wenn du Objekt-Speicher überschreibst:

1. VTable-Pointer auf kontrollierte Fake-Tabelle
2. Eintrag zeigt auf system / One-Gadget / stack pivot
3. Virtueller Call → Kontrolle

Erkennen

• C++ Binary (mangled symbols, _ZTV…)
• Ghidra: this-Pointer, vftable-XRefs

Abgrenzung

Nicht jedes C++-Programm ist VTable-Pwn — erst Objekt-Layout und Overflow/UAF finden.

Fake VTable + RIP-Kontrolle ist ein Extrem-Klassiker in C++-Challenges.

Kernel-Pwn — Landkarte (sehr grob)

Userland-Exploits laufen im Prozess. Kernel-Bugs betreffen den privilegierten Kern — oft schwieriger, mächtiger, und in CTFs als eigene Kategorie.

Typische Einstiege

• vulnerable Kernel-Module (.ko)
• IOCTL-Handler mit Overflow/UAF
• Race im Kernel

Zielbilder

• Privilege Escalation (uid 0)
• Arbitrary R/W auf Kernel-Memory
• Bypass von SMEP/SMAP/KASLR (je nach Setup)

Praxis-Hinweis

QEMU + busybox-Rootfs ist Standard-Lab. AlienZone-Hub ist primär Userland — dieses Thema ist Orientierung für später.

Ohne stabiles Userland-Pwn (Stack, Heap, ROP) lohnt Kernel selten.

Timing- & Side-Channel-Ideen

Manchmal leakt die Zeit oder das Fehlerverhalten mehr als die Ausgabe.

Timing

• Vergleich bricht bei erstem falschen Byte ab → Byte-für-Byte raten
• Netzwerk-Jitter: viele Samples mitteln

Andere Kanäle

• Fehlermeldungen unterschiedlich lang
• CPU-Cache (forschungsnah, selten pure CTF-Easy)
• Strom/EM — nicht CTF-Alltag

CTF-Pattern

Login/Oracle: „wrong user“ vs „wrong password“ in unterschiedlicher Zeit/Response.

Script

# Pseudocode: median over N tries per guess

Side-Channels brauchen Statistik und Geduld — und ein Orakel.

Browser-Exploits — Landkarte

Jenseits von klassischem XSS gibt es die Welt der Engine-Exploits (V8, SpiderMonkey, WebKit): Type Confusion, OOB in JIT, WASM-Bugs.

Stufen

1. Web-App-Bugs (XSS, CSRF, SQLi) — CTF-Alltag
2. Browser-Logic (SOP-Bypasses, UXSS) — selten
3. Memory corruption in Engine — Pwn2Own-Niveau

CTF

Meist: absichtlich gebaute JS-Engines oder vereinfachte Interpreter-Challenges. Lies, welche Engine und welche Version.

Skills-Brücke

Heap/Type Confusion aus Userland-Pwn hilft; reines „alert(1)“ reicht hier nicht.

Für AlienZone: XSS (Mittel) zuerst. Browser-Pwn ist Marathon, kein Sprint.

Eigene Binärprotokolle reverse-engineeren

Viele Extrem-Web/Network-Module sprechen kein reines HTTP, sondern ein Custom-Protokoll (Länge + Opcode + Payload).

Vorgehen

1. Traffic mitschneiden oder Client-Binary analysieren
2. Feste Header finden (Magic, Version)
3. Längenfelder & Endianness klären
4. Zustände (Handshake → Auth → Command)
5. Parser im Server suchen (Overflow an Länge?)

Werkzeuge

• Wireshark (Custom Dissector optional)
• ImHex / Hex-Editor
• pwntools für strukturierte Packets
• Ghidra am Client/Server

Exploit-Ideen

• Integer an Längenfeld
• Type Confusion im Opcode-Switch
• State machine skip (Command vor Auth)

Protokoll verstehen = halbe Challenge. Dann erst Payload.

Mitigations-Matrix: was blockiert was?

Am Extrem-Ende gewinnt, wer Schutzmechanismen kombiniert denkt.

Mitigation	Blockiert primär	Braucht oft
NX/DEP	Shellcode auf Stack/Heap	ROP / vorhandene Funktionen
ASLR/PIE	feste Adressen	Leak
Canary	naive Stack-Overflows	Leak / partielle Überschreibung
RELRO	GOT-Overwrite	andere Write-Primitiven
Fortify / CFI	manche overflow patterns	andere Bugs
seccomp	execve-Shell	ORW / erlaubte Syscalls

Strategie

1. Inventur (checksec, seccomp-bpf dump)
2. Welche Primitive habe ich wirklich?
3. Kürzester Pfad zur Flag — nicht der beeindruckendste

Extrem-CTF ist oft Mitigation-Puzzle, nicht nur „Overflow finden“.

Empfohlener Lernpfad auf AlienZone

1. Einfach hier auf /learning + Easy-Module im Hub
2. Mittel — Web/XSS/SQL-Idee, Reverse-Tools, Format-String
3. Schwer — Speicher-Modell, PE/ELF, sauberes Debugging
4. Extrem — Heap, Anti-Debug, BROP-Idee, Protokolle — mit fester Basis

Teilen & Deep-Links

Stufen und Themen sind verlinkbar, z. B.:

• /learning#level-medium
• /learning#topic-xss
• /learning#topic-brop
• /learning#level-resources

Community

Discord im Footer — spoilerarm fragen.

Wissen ist Macht — Üben im Hub macht den Unterschied.

AetherSec Blog (DE)

https://aethersec.de — deutschsprachiger Security-/CTF-Blog rund um Analyse, Exploitation und Praxis.

Inhalt / Hinweis

Writeups, Technik-Erklärungen und Einblicke aus dem AlienZone-/AetherSec-Umfeld. Gut als Begleitung zu den Hub-Modulen und diesem Learning-Bereich.

Starte dort, wenn du DE-sprachige Vertiefung und aktuelle Posts willst.

Deutschsprachige Einstiege & Nachschlagewerke

Quelle	Inhalt / Hinweis
https://aethersec.de	DE-Blog: CTF, Analyse, Praxis — empfohlen
BSI — Bürger-CERT / Grundschutz-Themen	Solide DE-Grundlagen zu IT-Sicherheit (nicht CTF-spezifisch, aber sauber)
OWASP (DE-Inhalte / Cheat Sheets EN)	Web-Sicherheit: XSS, Injection, Top-Risiken — Standard
HackTricks (EN, sehr praxisnah)	Riesiges Nachschlagewerk zu Web/PrivEsc/… — zum Nachschlagen, nicht auswendig
PayloadsAllTheThings	Payloads & Cheats zu vielen Vuln-Klassen — nur im erlaubten Labor/CTF

Kombiniere eine gute DE-Erklärung mit einer EN-Referenz, statt 20 Tabs offen zu haben.

Web-Security Quellen (DE + EN)

Quelle	Sprache	Inhalt / Hinweis
PortSwigger Web Security Academy	EN	Kostenlose Labs: XSS, SQLi, SSRF, … — goldener Einstieg
OWASP Cheat Sheet Series	EN	Kompakte Gegenmaßnahmen & Konzepte
MDN Web Docs	DE/EN	HTML/JS/HTTP nachschlagen — Pflicht für Web-CTFs
Can I use	EN	Browser-Features (selten CTF, oft nützlich)
JWT.io	EN	Tokens dekodieren (nur CTF/eigene Tokens)

XSS / Injection vertiefen

• PortSwigger XSS / SQL Injection Labs
• OWASP „Cross Site Scripting“ / „SQL Injection“ Prevention Cheat Sheets

Zuerst Konzept (dieses Learning), dann ein Lab-Pfad auf PortSwigger.

Reverse & Pwn Quellen (DE + EN)

Quelle	Sprache	Inhalt / Hinweis
https://aethersec.de	DE	Praxisnahe Posts zu Analyse/Exploitation
LiveOverflow (YouTube)	EN	Sehr gute Video-Erklärungen zu Binary/CTF
pwn.college	EN	Strukturierter Binary-Pfad (akademisch, top)
how2heap	EN	Heap-Allocator-Demos — fortgeschritten
ROPgadget	EN	Gadget-Suche
pwntools docs	EN	Python-Exploit-Helper
Ghidra	EN	Kostenloser Disassembler/Decompiler
x64dbg	EN	Windows-Debugger
checksec	EN	Binary-Protections anzeigen

Format-String / ROP / BROP

• LiveOverflow-Playlists zu Binary Exploitation
• Paper/Talks zu BROP (Blind ROP) — Suche: „Bittau BROP“
• man 3 printf — Format-Spezifizierer verstehen

Pwn ohne Reverse ist Blindflug — Tools und Lesen trainieren.

Linux, Windows & Systeme

Quelle	Sprache	Inhalt / Hinweis
Linux man-pages	EN	open, read, Syscalls — die Wahrheit
Microsoft Learn / Docs	DE/EN	Windows-APIs, PE-Konzepte
Windows Internals (Buch, EN)	EN	Sysinternals-Tools + Hintergrund
explainshell.com	EN	Shell-Befehle zerlegen
tldr pages	EN	Kurze Kommando-Beispiele

Ein Terminal-Cheat und die Manpage schlagen zehn zufällige Blogposts.

Crypto-Basics & Forensik (Auszug)

Quelle	Sprache	Inhalt / Hinweis
CryptoHack	EN	Interaktive Crypto-Rätsel
CyberChef	EN	Encode/Decode/Analyse im Browser
Wireshark docs	EN	PCAP-Analyse
Volatility	EN	Memory-Forensik (fortgeschritten)

Crypto in CTFs oft „knackbare“ Schwächen — erst Encoding, dann echte Crypto.

Englische Blogs & Writeup-Kulturen

Quelle	Inhalt / Hinweis
https://aethersec.de	DE — nicht EN, aber hier verlinkt als Heimblog
CTFtime writeups	Event-Writeups indexieren — nach Event suchen
HackTricks	Enzyklopädisch, gut zum Nachschlagen
0x00sec	Forum/Artikel (Qualität variiert — kritisch lesen)
Team-Blogs (z. B. führende CTF-Teams)	Suche: „CTF writeup <challenge name>“

Hinweis zum Lesen von Writeups

1. Selbst versuchen (Timer setzen)
2. Writeup als Vergleich, nicht als erste Quelle
3. Technik in eigenen Worten notieren

Writeups sind Nachschlagewerk — kein Ersatz für Denken.

Tool-Cheatsheets & Referenzen

Quelle	Inhalt / Hinweis
GTFOBins	Linux-Binaries missbrauchen (PrivEsc-Labor)
LOLBAS	Windows Living-off-the-Land
ss64.com	CMD/PowerShell/Bash-Referenz
Regex101	Regex bauen und testen
Canarytokens / eigene Lab-Notes	Eher Awareness — im CTF selten

Baue dir eine eigene Notizdatei pro Tool (10 Befehle, die du wirklich brauchst).

Ethik, Legalität & gutes Benehmen

Quelle	Inhalt / Hinweis
AlienZone /note	Plattform, AV-False-Positives, CTF-Kontext
BSI	DE-Grundlagen sicherer IT
OWASP	Verantwortungsvolle Web-Security-Kultur

Merksätze

• Nur erlaubte Ziele (CTF, eigenes Lab, schriftliche Erlaubnis)
• Keine echten Credentials/Flags öffentlich leaken
• Writeups spoilerarm, wenn Events noch laufen

Skill ohne Ethik ist nur Risiko — auf AlienZone trainieren wir ethisch.

Kuratierte Link-Sammlung (Quick Index)

Schnelle Übersicht — Details in den anderen Ressourcen-Kacheln.

Pflicht-Start

1. AetherSec — DE-Blog
2. PortSwigger Academy — Web-Labs
3. pwn.college / LiveOverflow — Binary
4. Ghidra + x64dbg
5. Dieses Learning: #level-easy → … → #level-extreme

Nach Kategorie

• Web: PortSwigger, OWASP, MDN
• Pwn/RE: pwn.college, how2heap, pwntools, ROPgadget
• Systeme: man7.org, Microsoft Learn
• Decode: CyberChef

Ein großes Nachschlagewerk lebt von Links + eigener Übung — nicht von 100 offenen Tabs.