AutoST vs. Open-Source-UDS-Tools: CaringCaribou, udsoncan, Scapy, can-utils

Was ist der Unterschied?

Die Open-Source-Tools sind Bausteine für einen Engineer am Terminal. cansend und candump aus can-utils legen Frames auf den Bus und zeigen, was zurückkommt. python-udsoncan gibt dir einen korrekten UDS-Client mit typisierten Services und Exceptions, ideal für ein Skript, das DIDs liest oder eine Session durchgeht. Die Automotive-Layer von Scapy zerlegen und bauen CAN-, ISO-TP-, UDS-, DoIP- und SOME/IP-Pakete und bringen Scanner für Services, DIDs und Sessions mit. CaringCaribou bündelt Discovery, Service- und DID-Enumeration, einen Fuzzer und eine Prüfung der SecurityAccess-Seed-Zufälligkeit in einem Kommandozeilen-Tool. Alle sind kostenlos, dokumentiert und werden von Leuten gepflegt, die die Protokolle kennen.

AutoST ist ein Produkt für ein Team, das dasselbe Ergebnis wiederholt erzeugen und jemand anderem zeigen muss. Der Test-Agent am Prüfstand enumeriert über Sessions hinweg, benennt die Funde aus deiner ODX oder CDD, prüft SecurityAccess mit begrenzten Versuchen, fuzzt UDS und CAN mit gespeichertem Seed und laufender Crash-Erkennung und liefert das Ergebnis als PDF, SARIF und priorisierten Fix Plan, gestartet aus dem Dashboard, über die REST-API oder aus einem Bamboo-Build. Der Unterschied ist nicht, dass AutoST einen Service kennt, den die freien Tools nicht kennen. Es ist das, was um den Request herum passiert: Zustandsbehandlung, Benennung, Reproduzierbarkeit, Nachweis und Integration.

Nebeneinander

	Open-Source-UDS-Tools	AutoST
Findet	Endpunkte, Sessions, Services und DIDs eines CAN-Steuergeräts; Seed-Zufälligkeit (CaringCaribou); alles, was du mit udsoncan oder Scapy skriptest, inklusive DoIP- und SOME/IP-Paketen	Dieselbe Oberfläche plus Session-bewusste Klassifikation, ODX/CDD-benannte DIDs und Routinen, Schreibtests, SecurityAccess-Zähler und -Verzögerungen, reproduzierbares UDS- und CAN-Fuzzing mit Crash-Erkennung, DoIP-Routing, SOME/IP-Service-Mapping, Android-IVI-Checks
Übersieht	Im Prinzip nichts, in der Praxis alles, was niemand skriptet: Zustand über Sessions, Reproduzierbarkeit, Hänger-Erkennung, Benennung, Historie, Berichte	Logik und verkettete Angriffe (Sache des Pentesters), FlexRay, LIN, HSFZ, Firmware-Interna
Wer macht es	Ein Engineer, der Python, SocketCAN und das Protokoll kennt; das Skript lebt bei diesem Engineer	Test- und QA-Engineers über ein Dashboard; kein Skripten nötig
Prüfstandszeit	Minuten pro Probe, Stunden, um einen vollen Lauf zusammenzubauen und zu debuggen; bei jedem Release von Hand wiederholen	Minuten für die Enumeration, Stunden für Fuzzing, unbeaufsichtigt; Wiederholung per Klick oder Build-Schritt
Kosten	Kostenlos; die Zeit deines Engineers und ein CAN-Interface	Lizenz pro getesteter Komponente, Preis auf Anfrage nach einer Demo
Passt in den Release-Zyklus	Nur, wenn jemand die Skripte pflegt und Ergebnisse von Hand vergleicht	Ja, über API-Tokens, das Bamboo-Plugin und SARIF-Export in deinen Tracker
Verlangt von	Niemandem; ein anerkannter Teil jedes Tester-Werkzeugkastens	Auch niemandem; Normen verlangen Tests mit Nachweis, und das liefern beide Wege
Ergebnis	Konsolenausgabe, candump-Logs, was dein Skript eben schreibt	PDF-Bericht pro Lauf, SARIF 2.1.0, CSV und JSON, datierte Scan-Historie, Fix Plan mit Status

Nimm die Open-Source-Tools, wenn

• du erkundest. Die erste Stunde mit einem unbekannten Steuergerät ist candump, ein paar cansend-Frames und uds discovery aus CaringCaribou. Nichts schlägt das, um zu verstehen, was auf dem Bus liegt.
• du etwas brauchst, was das Produkt nicht tut: ein eigenes Protokoll über CAN, einen herstellerspezifischen Service mit eigenem Framing, ein schnelles DoIP-Paket mit Scapy, um eine Hypothese zu prüfen.
• ein Engineer ein Steuergerät einmal testet und niemand einen Bericht braucht. Ein Skript und ein Notizbuch sind dafür die richtige Größe.
• du lernst. Der Quelltext von udsoncan erklärt ISO 14229 besser als die Norm selbst.
• das Budget null ist. Diese Tools sind der Grund, warum ein Security-Test nicht mit einer Bestellung anfangen muss.

Nimm AutoST, wenn

• dasselbe Steuergerät jeden Sprint oder in einem Dutzend Varianten zurückkommt und die Frage “Ist etwas zurückgefallen” lautet, nicht “Was ist das”.
• Ergebnisse verteidigt werden müssen: Ein Auditor, ein OEM oder ein Kunde will wissen, was wann getestet wurde und was aus jedem Finding geworden ist. Datierte Historie, PDF und SARIF beantworten das; ein Ordner voller candump-Logs nicht.
• das Team am Prüfstand aus Test-Engineers besteht, nicht aus Security-Spezialisten. Ein Dashboard mit DID-Namen aus der CDD und ein Fix Plan in klarer Sprache sind das, was sie einen Security-Test fahren und lesen lässt.
• Fuzzing reproduzierbar sein muss. Ein Crash, den ein Zufallsskript um drei Uhr nachts findet, nützt nur, wenn dieselbe Sequenz am Prüfstand des Entwicklers wiederholt werden kann, mit Payload-Historie und dem Monitor, der ihn gefangen hat.
• der Test in der Pipeline laufen und den Build oberhalb einer Schwelle brechen soll, mit JUnit-XML in den Build-Ergebnissen.

Beides zusammen

Die meisten Teams, mit denen wir arbeiten, behalten beides. Skripte und CaringCaribou für die explorative halbe Stunde an einem neuen Steuergerät und für das gelegentliche Sonderprotokoll; AutoST für die wiederholbare Suite, die bei jedem Release läuft und den Nachweis schreibt. Die REST-API macht die Übergabe leicht: Ein Skript kann einen Scan starten und das JSON abholen. Wenn du immer nur die erste Hälfte machst, reichen dir die freien Tools, und das sagen wir dir auch in der Demo.