Der Prüfling
- Projekt
- USB-RNDIS-Demo mit HTTP-Server, IAR EWARM
- Chip
- STM32F411, Cortex-M4
- Datei
- ITAT_RNDIS.out, Debug-Build, 1.072.120 Byte
- SHA-256
- 8c2b9a4dcc3b16532d8b0a0e470433436844cbd70aeab33b17d917070a852f08
Welche Dateien ein IAR-Build erzeugt
Der Linker ILINK erzeugt laut IAR „ein absolutes Objekt mit dem ausführbaren Image im ELF-Format, einschließlich DWARF für die Debug-Informationen“. Andere Formate erzeugt er nicht; HEX, S-Record oder BIN für den Flash entstehen daraus mit ielftool.
| Datei | Was darin steht |
|---|---|
.out | Das Image als ELF mit Symbolen und DWARF-Debug-Informationen. Die Datei für die Analyse. |
.map | Linker-Version, Befehlszeile, je Modul und Bibliothek der Beitrag zum Image, alle öffentlichen Symbole mit Herkunft. |
.hex .srec .bin | Mit ielftool aus dem .out erzeugt. Nur die Bytes für den Flash, ohne Symbole. |
Schritt 1: Toolchain und Ziel
Der Abschnitt .comment trägt die Linker-Version und die vollständige Befehlszeile des Linkers mit allen Objektdateien und Bibliotheken. Damit steht der Compiler als Build-Werkzeug in der SBOM.
file ITAT_RNDIS.outITAT_RNDIS.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped
strings -a ITAT_RNDIS.out | grep -m1 "IAR ELF Linker"IAR ELF Linker V9.10.1.308/W64 for ARM
strings -a ITAT_RNDIS.out | grep -c "IAR ANSI C/C++ Compiler V9.10.1.308/W64 for ARM$"713
Schritt 2: was gelinkt ist
Die Symboltabelle zeigt, welche Funktionen im Image stehen: hier der FreeRTOS-Kernel, der CMSIS-RTOS2-Aufsatz und der TCP/IP-Stack FreeRTOS+TCP.
Ein Funktionsname allein ist kein Beweis. tcpip_init klingt nach lwIP, ist in diesem Projekt aber eine eigene Funktion der Demo: kein einziges Symbol mit lwip_ steht im Image. Eine Komponente gehört erst in die SBOM, wenn mehrere Belege zusammenpassen.
nm ITAT_RNDIS.out | grep -E " T (FreeRTOS_IPInit|FreeRTOS_socket|vTaskStartScheduler|xTaskCreate|osKernelStart|tcpip_init)$"08004797 T FreeRTOS_IPInit 0800272b T FreeRTOS_socket 08007f31 T osKernelStart 0800656d T tcpip_init 08005305 T vTaskStartScheduler 08004fff T xTaskCreate
nm ITAT_RNDIS.out | grep -c -E "lwip_|mbedtls_"0
Schritt 3: die Versionen
Die FreeRTOS-Version steht hier im Image selbst, im Flash-Bereich zwischen den Texten des HTTP-Servers. Die Quellpfade im DWARF nennen bei IAR die Projektordner, etwa Middlewares\Third_Party\FreeRTOS-Plus-TCP, aber keine Version im Pfad.
Für FreeRTOS+TCP und den HAL steht keine Version im Image. Sie kommt aus den Headern des Projekts: FreeRTOS+TCP V2.3.2 LTS Patch 1 in FreeRTOS_IP.c und HAL 1.7.13 in stm32f4xx_hal.c. In der SBOM gehören diese Versionen zur Komponente, mit dem Vermerk, woher sie stammen.
strings -a -t x ITAT_RNDIS.out | grep -m1 "V10.3.1"8940 V10.3.1
strings -a ITAT_RNDIS.out | grep -m1 -i "FreeRTOS-Plus-TCP"D:\GitHub\STM32F4XX_RNDIS_DEMO\Middlewares\Third_Party\FreeRTOS-Plus-TCP\portable\BufferManagement\BufferAllocation_2.c
Was daraus für die SBOM folgt
FreeRTOS V10.3.1 liegt im Versionsbereich von CVE-2021-31571, CVE-2021-31572 und CVE-2021-32020, die NVD für FreeRTOS vor 10.4.3 führt. Ob eine davon im Gerät ausnutzbar ist, hängt von der Nutzung der betroffenen Funktionen ab.
| Komponente | Version und Beleg |
|---|---|
| FreeRTOS-Kernel | V10.3.1, im Image an Offset 0x8940, bestätigt durch task.h |
| FreeRTOS+TCP | V2.3.2 LTS Patch 1, aus FreeRTOS_IP.c; im Image nur der Name |
| STM32F4 HAL | 1.7.13, aus stm32f4xx_hal.c; im Image nur Funktionen |
| IAR-Laufzeitbibliotheken | Aus der Linker-Befehlszeile im Abschnitt .comment |
| IAR-Compiler und -Linker | V9.10.1.308, aus .comment, als Build-Werkzeug |
Was LegacyMind dabei automatisch macht
LegacyMind liest aus .out-, .elf- und .axf-Dateien die gelinkten Bibliotheken und die Toolchain mit Version, aus Keil- und GNU-Arm-Builds auch die Versionen der Bibliotheken. Dazu die Härtung (Stack-Schutz, MPU, Privilegientrennung). Belegt die Datei keine Version, bleibt das Feld leer. Die SBOM exportieren Sie als CycloneDX oder SPDX.
Die Konformitätsaussage treffen Sie. Diese Seite und unsere Berichte liefern technische Feststellungen als Grundlage dafür.
Häufige Fragen
01Welche IAR-Datei soll ich nehmen?
Das .out aus dem Ordner Exe Ihres Projekts. Ein HEX oder BIN aus ielftool enthält nur die Bytes für den Flash, ohne Symbole und Debug-Informationen.
02Steht die Version jeder Bibliothek im .out?
Nein. Manche Bibliotheken schreiben ihre Version in das Image, andere nicht. Dann liefern die Header oder Release-Notes des Projekts die Version, und die SBOM vermerkt die Herkunft.
03Hilft die Map-Datei?
Ja. Sie listet je Modul und Bibliothek, was im Image landet, und welche Symbole woher kommen. Für die Frage, ob eine Bibliothek wirklich gelinkt ist, ist sie die beste Quelle neben dem .out.
04Ist das bei Keil anders?
Keil schreibt ein .axf, ebenfalls ELF. Im öffentlichen Keil-Beispiel steht die FreeRTOS-Version zusätzlich im Quellpfad, third_party/FreeRTOSv10.1.1; im IAR-Beispiel nicht.