FPGA Password Cracker Projekt – Post-Mortem

Das Ziel

PKZIP-verschlüsselte Archive mit einem Tang Nano 4K FPGA knacken. Die Idee: Parallele Hardware-Engines sollten Millionen Passwörter pro Sekunde testen – schneller als jede CPU.

Hardware:

• Tang Nano 4K (GW1NSR-4C, 4.608 LUTs)
• ESP32 als Controller
• SPI-Kommunikation

Was funktionierte

SPI Interface: Saubere Kommunikation zwischen ESP32 und FPGA. Register-Zugriffe, Datenübertragung – alles stabil.

PKZIP Implementierung: Komplette Logik funktional:

• CRC32 Lookup Table (Block RAM)
• Key Update Engine (mit korrektem Timing)
• 12-Byte Header Decryption
• Password Generator

Python-Verifizierung: Alle Algorithmen gegen Referenz-Implementierung getestet – 100% korrekt.

Was scheiterte

Resource Overflow:

Benötigt: 25.662 LUTs (1 Engine!)
Verfügbar: 4.608 LUTs
Faktor: 5.6x zu groß

Der Killer: Password Generator (~15.000 LUTs)

• Base-N Konvertierung
• Division/Modulo Operatoren
• 7 verschiedene Charsets
• Massive Kombinatorik

Selbst mit 1 statt 4 Engines: Hoffnungslos zu groß.

Die Bugs unterwegs

1. SPI Write Bug: rx_shift[7] statt rx_shift[6] – off-by-one beim MSB
2. Timing Bug: Key Update verwendete altes key1 statt neues – falsche non-blocking assignments
3. Decrypt Logic: Erst v1/v2 confusion, dann fehlende key updates zwischen bytes
4. Synthesis: Gowin braucht default cases in allen case-statements

Jeder Bug einzeln gefixt, aber am Ende: irrelevant wegen Resources.

Warum gescheitert

Fundamentales Problem: Tang Nano 4K zu klein für komplexe kryptografische Operationen.

Alternative Ansätze geprüft:

• Cortex-M3 (onboard): Passt in 2.200 LUTs, aber 11x langsamer
• Tang Nano 20K: ~20.000 LUTs, trotzdem nur 1 Engine möglich
• Simplified Password Gen: Nur 4 chars lowercase = sinnlos

Reality Check:

• MD5 Cracking: ~50.000-100.000 LUTs pro Engine
• GPU (RTX 3060): Milliarden Hashes/Sekunde
• FPGA nur sinnvoll für spezialisierte Algorithmen

Lessons Learned

1. Resource Planning zuerst: Synthesize-Test mit 1 Engine BEVOR 4 Engines implementieren
2. Tang Nano Grenzen: Gut für LEDs/Audio/Video, zu klein für Crypto
3. Password Generators sind teuer: Division/Modulo = LUT-Monster
4. FPGA ≠ immer schneller: Für Standard-Krypto sind GPUs überlegen
5. Cortex-M3 Option: Hätte von Anfang an evaluiert werden sollen

Was ich gelernt habe

Technisch:

• SPI Slave in Verilog (bit-genaues Timing)
• PKZIP Encryption (CRC32, key chains, header decryption)
• Gowin EDA Quirks (default cases, timing constraints)
• Resource Estimation für Synthesizer

Projektmäßig:

• Proof-of-Concept mit minimaler Hardware zuerst
• Resource Budget vor Feature-Development
• GPU > FPGA für die meisten Crypto-Tasks

Nächste Schritte?

Für dieses Projekt: Tot. Tang Nano zu klein, größere Boards unwirtschaftlich vs. GPU.

Alternative:

• Cortex-M3 Demo als PoC (~5 sec für 456k Passwords)
• Oder: GPU + Hashcat für echtes Cracking

Lessons für zukünftige FPGA Projekte:

• Resource Budget ZUERST
• Synthesize early, synthesize often
• FPGAs für Streaming/Parallelverarbeitung, nicht für schwere Arithmetik

Status: Gescheitert, aber viel gelernt.

Zeit: ~90+ Stunden Entwicklung + Debugging

Ergebnis: Funktionale Implementierung, die nicht synthetisiert werden kann.

Fazit: Manchmal ist die falsche Hardware einfach die falsche Hardware.