Heute ging es nicht darum, sofort den nächsten Bug zu finden. Heute ging es darum, ein Setup zu bauen, mit dem ich langfristig sauber arbeiten kann: als Android Security Researcher, Bug-Bounty-Hunter, Lernender und Content-Creator.
Warum ich das Setup gebraucht habe
Bug Bounty wirkt von außen oft wie: App herunterladen, decompilen, Endpoint finden, Report schreiben. In der Realität ist es viel unordentlicher. Es gibt Programmregeln, Scope-Grenzen, unterschiedliche APK-Versionen, halbfertige Decompiled-Ordner, Notizen, Screenshots, Proxy-Logs, Lernziele und irgendwann auch Content-Ideen für YouTube oder den Blog.
Wenn das alles einfach irgendwo auf dem Desktop liegt, verliert man schnell den Überblick. Genau deshalb habe ich heute meinen Workspace neu strukturiert.
Die Grundidee: Nicht ein Ordner, sondern Projekte
Ich wollte keine lose Sammlung aus Dateien, sondern Arbeitsbereiche. Deshalb gibt es jetzt getrennte Projekte für Bug Bounty, YouTube, Homepage, Lernen, Business und gemeinsame Vorlagen. Der wichtigste Bereich ist aktuell das Bug-Bounty-Projekt, weil dort meine Android-Ziele vorbereitet und analysiert werden.
Mein Ziel: Jedes Target bekommt dieselbe Struktur. Dadurch muss ich nicht jedes Mal neu überlegen, wo APK, JADX-Ausgabe, apktool-Ausgabe, Notizen, Evidence und Reports liegen.
Für jedes Ziel gibt es jetzt einen eigenen Target-Ordner. Dort liegt die APK direkt im
apk-Ordner. Die decompilierte Ausgabe von JADX kommt in apk/jadx,
die Ausgabe von apktool in apk/apktool. Daneben gibt es feste Orte für Notizen,
Evidence, Findings und Report-Entwürfe.
Manifest zuerst
Eine der wichtigsten Entscheidungen heute: Bei jedem Android-Ziel wird das Manifest
verpflichtend analysiert. Das klingt banal, ist aber in echten Apps entscheidend.
Die AndroidManifest.xml zeigt, welche Komponenten exported sind, welche Deep Links
existieren, welche Permissions genutzt werden, ob Backup erlaubt ist, ob Cleartext Traffic
möglich ist und welche OAuth- oder Payment-Callbacks in der App landen.
Ich habe in den letzten Wochen gemerkt: Wer das Manifest überspringt, überspringt oft genau die Stellen, an denen Mobile Bugs sichtbar werden. Nicht jede exported Activity ist ein Bug. Aber jede exported Activity ist eine Frage: Warum ist sie exported, welche Daten nimmt sie an und kann daraus ein echter Impact entstehen?
Ein Scanner, aber kein Autopilot
Zusätzlich haben wir einen eigenen kleinen Scanner verbessert, der decompilierte Android-Projekte nach meinen priorisierten Bugklassen durchsucht. Er sucht unter anderem nach API-Hosts, Auth- und Session-Flows, IDs, Rollen, Deep Links, exported Components und hardcoded Secrets.
Wichtig ist dabei: Der Scanner entscheidet nichts. Er liefert Leads. Ein Treffer ist kein Finding.
Ein API-Key ist nicht automatisch ein Sicherheitsproblem. Ein Deep Link ist nicht automatisch
ausnutzbar. Ein userId im Code ist erst dann spannend, wenn ich damit eine
Autorisierungsgrenze testen kann.
Der Scanner soll mir nicht die Arbeit abnehmen. Er soll mir zeigen, wo ich meine echte manuelle Arbeit beginnen sollte.
Meine Prioritäten sind klarer geworden
Aus dem Setup ist auch eine klare Spezialisierung entstanden. Ich fokussiere mich auf Android Apps, aber nicht auf jede theoretische Mobile-Best-Practice. Mein Fokus liegt auf Bugs mit realem Impact: IDOR, Broken Access Control, Auth- und Session-Probleme, API-Datenlecks, Business Logic und hardcoded Secrets nur dann, wenn sie tatsächlich Zugriff oder Aktionen ermöglichen.
Dinge wie fehlendes Certificate Pinning, fehlende Obfuscation oder harmlose SDK-Keys sind oft ausgeschlossen oder niedrig bewertet. Das heißt nicht, dass sie technisch uninteressant sind. Es heißt nur: Für Bug Bounty muss der Impact stimmen.
KI als Hauptmitarbeiter, nicht als magischer Knopf
Der spannendste Teil heute war nicht der Ordnerbaum. Der spannendste Teil war die Arbeitsweise mit KI. Ich will KI nicht nur als Chat benutzen, der mir gelegentlich einen Befehl erklärt. Ich will sie als festen Mitarbeiter in meinem Research-Prozess einsetzen.
Dafür haben wir eigene Codex-Skills gebaut. Das sind kleine Arbeitsanweisungen, die festlegen, wie bestimmte Aufgaben erledigt werden sollen. Zum Beispiel:
- Android Bug Bounty Triage: APK, apktool, JADX, Manifest, Scanner und Priorisierung zusammenführen.
- Program Scope Parser: Programmtexte in Scope, Regeln, Ausschlüsse und Prioritäten übersetzen.
- Mobile API Recon: API-Hosts, Auth-Flows, IDs und Zwei-Account-Testpfade strukturieren.
- Finding Report Writer: Aus validierten Findings saubere Bug-Bounty-Reports bauen.
- Homepage Blog Writer: Neue Blogartikel in meinem bestehenden Webseitenstil erstellen.
Das verändert die Arbeit. Ich muss nicht jedes Mal erklären, dass Manifest-Analyse dazugehört. Ich muss nicht jedes Mal neu sagen, dass Secrets ohne Impact keine guten Reports sind. Diese Regeln sind jetzt Teil meines Workflows.
Auch Lernen und Content gehören dazu
Neben Bug Bounty habe ich auch meinen Lernbereich strukturiert. Besonders wichtig ist mein Lernplan für API-Endpunkt-Angriffe: Auth, Objekt-IDs, Rollen, Sessions, Rate Limits, Business Logic und saubere Reproduktion. Genau dort will ich stärker werden.
Gleichzeitig ist mein YouTube- und Blog-Projekt Teil des Setups. Ich will später zeigen, wie man mit KI CTF-Challenges und autorisierte Pentests strukturierter angeht. Dafür brauche ich einen Workflow, der sauber dokumentiert, ohne private Bug-Bounty-Details zu veröffentlichen.
Die wichtigste Grenze: Öffentlich dokumentiert wird nur, was ich veröffentlichen darf. Private Scope-Details, Reports, Tokens, Kunden- oder Nutzerdaten gehören nicht in Blogposts oder Videos.
Was ich daraus mitnehme
Heute war kein spektakulärer Hunting-Tag. Es gab keinen großen Report, kein Bounty, keinen "Critical". Aber es war trotzdem ein wichtiger Tag, weil ich mein Fundament gebaut habe.
Ich habe jetzt:
- eine feste Projektstruktur für meine Selbstständigkeit
- ein wiederholbares Target-Layout für Android Bug Bounty
- einen Scanner, der auf meine priorisierten Bugtypen ausgerichtet ist
- einen Lernplan für API-Angriffe
- einen gepflegten Homepage- und Blog-Workflow
- eigene KI-Skills, die meine Arbeitsweise speichern
Das klingt vielleicht weniger aufregend als ein einzelner Fund. Für mich ist es aber genau der Punkt, an dem aus losem Lernen langsam ein professioneller Prozess wird.
Mein nächster Schritt ist nicht mehr "irgendwo anfangen". Mein nächster Schritt ist: ein Target öffnen, Scope prüfen, Manifest analysieren, API-Flows mappen und dann gezielt testen.
— KenSySec