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

> Open-Source-UDS-Tools (CaringCaribou, python-udsoncan, die Automotive-Layer von Scapy, can-utils) sind kostenlos, gut gepflegt und die richtige Wahl, um ein Steuergerät zu erkunden, ein einmaliges Skript zu schreiben oder das Protokoll zu lernen. Die freien Tools hören dort auf, wo ein Team bei jedem Release dasselbe Ergebnis braucht: Session-bewusste Enumeration mit ODX- oder CDD-Namen, reproduzierbares Fuzzing mit Crash-Erkennung, Berichte, SARIF und CI-Anbindung. Das ergänzt AutoST. Wenn ein Engineer ein Steuergerät einmal testet, reichen die freien Tools.

CaringCaribou, python-udsoncan, Scapy und can-utils sind kostenlos und stark beim Erkunden eines Steuergeräts. Was AutoST ergänzt und wann die freien Tools reichen.

Source: https://auto-st.com/de/vergleich/autost-vs-open-source-uds-tools · Updated: 2026-10-07

## 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.

## FAQ

**Nutzt AutoST diese Open-Source-Tools intern?**

Der Test-Agent hat eine eigene Implementierung von UDS, ISO-TP, DoIP und SOME/IP, damit er Session-bewusst und reproduzierbar über CAN und Ethernet laufen kann. Manche Testfälle folgen veröffentlichter Forschung, zum Beispiel CaringCaribou bei der Seed-Zufälligkeit, und das steht so auf der SecurityAccess-Seite. Die Tools sind gut; wir haben für eine andere Aufgabe gebaut.

**Kann ich meine eigenen Skripte neben AutoST weiter nutzen?**

Ja, und das solltest du. AutoST hat eine REST-API, also kann ein Scapy- oder udsoncan-Skript einen Scan starten, die Findings als JSON oder SARIF abholen und mit den eigenen Ergebnissen vergleichen. Teams behalten meist Skripte für den explorativen Teil und lassen AutoST den wiederholbaren Teil machen.

**Wann sind die freien Tools die bessere Wahl?**

Wenn du UDS lernst, ein unbekanntes Steuergerät zum ersten Mal erkundest, einen Proof of Concept schreibst oder ein Steuergerät einmal ohne Berichtspflicht testest. Auch, wenn du noch keine Prüfstandshardware hast: can-utils und ein SocketCAN-Adapter für 30 Euro bringen dich an einem Nachmittag ins Gespräch mit einem Steuergerät.

## Sources

- [CaringCaribou: a friendly car security exploration tool (GitHub)](https://github.com/CaringCaribou/caringcaribou)
- [python-udsoncan: UDS (ISO 14229) in Python (GitHub)](https://github.com/pylessard/python-udsoncan)
- [Scapy-Dokumentation: Automotive-Layer (CAN, ISO-TP, UDS, DoIP, SOME/IP)](https://scapy.readthedocs.io/en/latest/layers/automotive.html)
- [can-utils: Linux-SocketCAN-Userspace-Werkzeuge (GitHub)](https://github.com/linux-can/can-utils)
- [ISO 14229-1:2020 Unified diagnostic services (UDS), Teil 1: Anwendungsschicht](https://www.iso.org/standard/72439.html)
- [OASIS SARIF 2.1.0 (Static Analysis Results Interchange Format)](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html)

## Related

- [UDS (Unified Diagnostic Services)](https://auto-st.com/de/glossar/uds)
- [ODX (Open Diagnostic Data Exchange)](https://auto-st.com/de/glossar/odx)
- [UDS-Fuzzing vs. CAN-Fuzzing: Welche Schicht du angreifst und was bricht](https://auto-st.com/de/vergleich/uds-fuzzing-vs-can-fuzzing)
- [UDS Enumeration erklärt: wie man ein ECU sicher abbildet](https://auto-st.com/de/insights/uds-enumeration-explained)
- [Kenne jede Tür ins ECU.](https://auto-st.com/de/uds-enumeration)
- [Sicherheitstests bei jedem Build, nicht einmal im Jahr.](https://auto-st.com/de/ci-cd-integration)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/vergleich/autost-vs-open-source-uds-tools