Brauche ich den Quellcode?

Nein. Das AXF trägt genug Information, um Bibliotheken und viele Versionen zu bestimmen. Die Projektdatei (.uvprojx) hilft zusätzlich, weil dort die Packs mit Version stehen.

Funktioniert das auch mit IAR oder GCC?

Ja. IAR Embedded Workbench schreibt ein .out, der GNU-Arm-Compiler ein .elf. Beides sind ELF-Dateien und werden genauso gelesen.

Was ist mit einer Intel-HEX-Datei?

HEX ist eine Textkodierung derselben Bytes wie das BIN. Für die Prüfung ist das AXF besser, weil das HEX keine Symbole enthält.

Wissen · Bare-Metal

Keil-Firmware auf bekannte Schwachstellen prüfen

Ben Plannet, Co-Founder und CTO der LegacyMind GmbH · Stand 5. Oktober 2026

Kurz beantwortet

Eine mit Keil MDK gebaute Firmware prüfen Sie auf CVEs in zwei Schritten: erst feststellen, welche Bibliotheken in welcher Version im Build stecken, dann diese Liste gegen Schwachstellendatenbanken wie die NVD abgleichen. Die beste Datei dafür ist das AXF, nicht das BIN. Das AXF ist ein ELF mit Symbolen und Abschnitten, aus denen sich CMSIS-Packs, RTOS und TLS-Bibliotheken samt Version lesen lassen.

Warum das AXF und nicht das BIN

Der Linker von Keil (armlink) schreibt das AXF als ELF-Datei. Darin stehen die Symboltabelle mit den Funktionsnamen, die Abschnitte des Programms und, je nach Projekteinstellung, Debug-Informationen mit Quellpfaden. Ein Funktionsname wie mbedtls_ssl_handshake oder xTaskCreate zeigt, dass mbedTLS oder FreeRTOS gelinkt ist. Ein Quellpfad wie FreeRTOS/v10.4.6 nennt oft schon die Version.

Das BIN entsteht daraus mit fromelf und enthält nur noch die Bytes, die in den Flash geschrieben werden. Symbole und Pfade sind weg. Was bleibt, sind Texte, die eine Bibliothek selbst einkompiliert, etwa eine Versionskennung. Nicht jede Bibliothek tut das.

So geht es von Hand

Packs aus dem Projekt lesen: In der Projektdatei (.uvprojx) stehen unter RTE die eingebundenen Software-Packs mit Hersteller und Version.
Gelinkte Bibliotheken finden: fromelf --text -s firmware.axf (Arm) oder arm-none-eabi-nm firmware.axf listet die Symbole. Präfixe wie mbedtls_, lwip_, wolfSSL_ oder osKernel zeigen die Bibliothek.
Compiler und Toolchain lesen: arm-none-eabi-readelf -p .comment firmware.axf zeigt, mit welchem Compiler gebaut wurde.
Versionen suchen: strings -a firmware.axf | grep -iE "version|v[0-9]+\.[0-9]+" findet Versionskennungen, wo eine Bibliothek sie einkompiliert. Quellpfade in den Debug-Informationen nennen Versionen oft im Ordnernamen.
Abgleichen: Name und Version als CPE im NVD-Verzeichnis suchen und die zugehörigen CVEs prüfen. Für aktiv ausgenutzte Lücken den CISA-KEV-Katalog und die EUVD der ENISA dazunehmen.
Mit dem Hersteller abgleichen: Die Release Notes des Pack-Herstellers sagen, ab welcher Version eine Lücke behoben ist.

Was LegacyMind dabei automatisch macht

Builds für Mikrocontroller aus Keil MDK, IAR oder GNU Arm. Gelesen werden CMSIS-Packs mit Version aus der Paketbeschreibung des Pack-Herstellers, Versionsdatensätze im Binary (etwa RTX5) und Versionen aus Quellpfaden (FreeRTOS, lwIP, mbedTLS, STM32Cube). Dazu Härtung (Stack-Canary, MPU, Privilegientrennung) und eingebettete Schlüssel.

Komponenten mit belegter Version werden gegen die Schwachstellenquellen abgeglichen, und jede Version nennt, wo sie gelesen wurde: Versionsdatensatz, Quellpfad oder Paketbeschreibung. Eine Version, die das Binary nicht belegt, bleibt leer statt geraten.

Werden angenommen und erkannt. Bis die Umwandlung in Bytes fertig ist, laden Sie bitte das BIN oder das AXF desselben Builds hoch.

Was sich aus dem Build lesen lässt

Quelle im AXF	Was sie verrät
Symboltabelle	Welche Bibliotheken gelinkt sind (Funktionsnamen)
Debug-Informationen	Quellpfade, oft mit Version im Ordnernamen
Abschnitt .comment	Compiler und Version, etwa Arm Compiler 5.06 oder 6.x
Versionsdatensätze	Versionen, die eine Bibliothek selbst ablegt, etwa RTX5
Texte im Binary	Versionskennungen, wo die Bibliothek eine einkompiliert

Häufige Fragen

Reicht das BIN für eine Schwachstellenprüfung?: Teilweise. Im BIN fehlen Symbole und Pfade, es bleiben nur Texte, die eine Bibliothek selbst einkompiliert. Wenn Sie das AXF desselben Builds haben, nehmen Sie das AXF.
Brauche ich den Quellcode?: Nein. Das AXF trägt genug Information, um Bibliotheken und viele Versionen zu bestimmen. Die Projektdatei (.uvprojx) hilft zusätzlich, weil dort die Packs mit Version stehen.
Funktioniert das auch mit IAR oder GCC?: Ja. IAR Embedded Workbench schreibt ein .out, der GNU-Arm-Compiler ein .elf. Beides sind ELF-Dateien und werden genauso gelesen.
Was ist mit einer Intel-HEX-Datei?: HEX ist eine Textkodierung derselben Bytes wie das BIN. Für die Prüfung ist das AXF besser, weil das HEX keine Symbole enthält.

Quellen

Weiterlesen

Prüfen Sie Ihr eigenes Image

Der CRA-Readiness-Check ist kostenlos: ein Firmware-Image oder eine Lieferanten-SBOM, ein Befundbericht.

Zum CRA-Readiness-Check Unterstützte Formate