# AutoST by Zyberum

> AutoST is an automated security testing platform for automotive ECUs, made by Zyberum GmbH in Germany. A test agent (Carbyne) connects to an ECU on the bench over CAN, CAN FD, DoIP or SOME/IP, while a web dashboard orchestrates the scans. It enumerates diagnostic sessions, services and data identifiers, imports ODX and CDD files to name DIDs and run routines, probes UDS SecurityAccess (0x27), fuzzes UDS and CAN, checks Android infotainment units over ADB, scores the risk and produces a ranked fix plan with PDF, SARIF, CSV and JSON output. It runs on your own servers or hosted by Zyberum and fits into CI/CD pipelines.

## Product facts
- Product: AutoST, automated security testing for automotive ECUs
- Maker: Zyberum GmbH, Jägerstieg 12, 30657 Hannover, Germany (https://zyberum.com)
- Founder and managing director: Tom Zaubermann (former lead of the InCar Security Testing Lab at Volkswagen AG)
- Contact: automotive@zyberum.com, +49 176 439 17074
- Book a live demo: https://auto-st.com/contact
- Pricing: on request (licence per tested component; hosted by Zyberum or installed on your own servers)
- Languages: English, German, French, Italian, Spanish

## Capabilities
- [UDS Enumeration: Map Every ECU Diagnostic Surface](https://auto-st.com/uds-enumeration): The enumeration engine is a non-destructive discovery scan over UDS (ISO 14229). It finds ISO-TP endpoints across the 11-bit and 29-bit ranges, discovers diagnostic sessions (0x10) including extended and programming, sweeps every service ID from 0x00 to 0xFE in each session and classifies the response, reads data identifiers (0x22, the 0xF180-0xF19F range by default or the full 0x0000-0xFFFF space), and discovers XCP and CCP calibration interfaces. Each risky service is scored against a configurable weighting.
- [DID & Routine Scanning with ODX and CDD Files](https://auto-st.com/did-routine-scanning): AutoST imports ODX, ODX-D, PDX and Vector CDD files per ECU and normalises them into data identifiers and routines. The DID names enrich the enumeration results, so a discovered identifier shows its real name instead of a raw number. Routines (UDS service 0x31) are never brute-forced: AutoST calls only the routines defined in your file, with the request payload you can override, and stores the request and response. Optional write-probing (0x2E) is destructive, off by default and clearly warned.
- [UDS SecurityAccess (0x27) Testing: Seed, Key and Lockout](https://auto-st.com/security-access-testing): The SecurityAccess engine actively tests UDS service 0x27. It measures seed randomness (constant, zero, low-entropy or incrementing seeds), attempts to recover the seed-to-key algorithm and tries a catalogue of default keys, checks whether a brute-force lockout triggers after wrong keys, and verifies that the ECU enforces the request-seed-then-send-key sequence. An opt-in ECU-reset probe checks whether the seed is predictable across reboots. Every probe is bounded and non-destructive by default; the reset probe is gated behind a confirmation.
- [ECU Fuzzing: Reproducible UDS and CAN Fuzzing](https://auto-st.com/ecu-fuzzing): The fuzzing engine sends randomised, reproducible traffic to an ECU in two modes. UDS fuzzing sends random payloads (up to 128 bytes) on selected or non-standard service IDs over ISO-TP, re-entering the diagnostic session periodically. CAN fuzzing sends random CAN and CAN FD frames on arbitration IDs taken from a DBC. Runs are seeded, so a finding can be reproduced exactly. Crash detection runs after every iteration: a TesterPresent liveness check (always on), an optional DTC-count monitor, and timeout or transport-error detection. Progress streams live and results export to PDF.
- [DoIP and SOME/IP Security Testing](https://auto-st.com/doip-someip-testing): AutoST tests automotive Ethernet in two engines. DoIP (ISO 13400) carries UDS over IP: AutoST performs vehicle discovery over UDP, handles routing activation and then runs the transport-generic UDS enumeration over the link, so sessions, services, DIDs and SecurityAccess are all reachable. SOME/IP support does passive service discovery and active FindService, mapping services, methods and eventgroups and their endpoints, and scoring the exposure.
- [Android IVI Security Testing over ADB](https://auto-st.com/ivi-security-testing): The IVI engine assesses Android infotainment units over ADB. It performs recon of packages, permissions, exposed components, pullable files and SELinux posture, runs static analysis of APKs (manifest flags and secret scanning), and can run functional tests with screenshots and live logcat streaming. Findings are grouped by severity with per-finding remediation and flow into the shared fix plan.
- [The AutoST Fix Plan: Findings Turned into Ranked Tasks](https://auto-st.com/fix-plan): The Fix Plan is a shared remediation view across all AutoST engines (UDS enumeration, SecurityAccess, DoIP, SOME/IP and Android IVI). Each finding becomes one workable task, ranked by severity, with a plain description of what was found, why it matters and how to fix it. Tasks have a workflow state (open, in progress, done), assignees and an ALM/PLM reference field, can be viewed as a list or a Kanban board, and export to CSV, SARIF 2.1.0 and JSON.
- [Risk Scoring and Test Reports in AutoST](https://auto-st.com/risk-scoring-reports): AutoST scores the risk of an ECU from its enumeration results. A configurable catalogue of 26 ISO 14229 services carries a risky flag and a weight (0 to 5); the active, non-accepted risky services are summed and normalised to a 0-10 score, and an exposed XCP or CCP interface raises it. Each scan produces a PDF report with an overview, the findings and a non-repudiation footer. The fix plan exports as SARIF, CSV and JSON, and the CI plugin emits JSON and JUnit XML.

## Using AutoST
- [How AutoST Works: Dashboard, Backend and Bench Agent](https://auto-st.com/how-it-works): AutoST has three parts. The web dashboard is where you define ECUs (components), configure scans and read results. The backend orchestrates jobs, stores findings and issues API tokens. Carbyne is a bench agent that runs on Windows or Linux, connects to the ECU over CAN, CAN FD, DoIP or SOME/IP, and executes the scans, reporting progress and results back over HTTPS. Several agents can test several ECUs in parallel.
- [AutoST as Verification Evidence for ISO/SAE 21434](https://auto-st.com/iso-21434-testing): AutoST supports an ISO/SAE 21434 and UN R155 programme on the testing side. ISO/SAE 21434:2021 asks for security testing in three places: Clause 10.4.2 Integration and verification ([RQ-10-09], and [RC-10-12] which recommends component testing with fuzzing and vulnerability scanning to minimise unidentified weaknesses), Clause 11 Cybersecurity validation ([RQ-11-01], which names penetration testing), and Clause 8.5 Vulnerability analysis as a continuous activity. AutoST performs that testing (enumeration, SecurityAccess probing, fuzzing, DoIP/SOME/IP and IVI) and produces the evidence (PDF and SARIF reports, scan history, risk acceptance) behind it. It does not run your CSMS or write your TARA: for those, Zyberum offers ISO/SAE 21434 consulting.
- [Run ECU Security Tests in CI/CD](https://auto-st.com/ci-cd-integration): AutoST automates ECU security testing through long-lived API tokens (JWTs) and a REST API. A CI plugin triggers an enumeration scan, polls for the result, fails the build when findings exceed your threshold, and emits JSON, JUnit XML and a PDF report. Any CI system (Jenkins, GitLab CI, GitHub Actions) can drive AutoST through the same API; a ready-made plugin is provided for Bamboo.
- [Supported Protocols, Buses and Hardware Adapters](https://auto-st.com/protocols-hardware): AutoST supports CAN and CAN FD with ISO-TP (ISO 15765), UDS (ISO 14229), XCP and CCP calibration discovery, DoIP (ISO 13400) and SOME/IP including service discovery. The Carbyne bench agent runs on Windows and Linux and works with SocketCAN (Linux), Vector XL (Windows) and comma.ai Panda interfaces, with configurable bitrate, CAN FD data bitrate and sample point.
- [Deploy AutoST: On Your Servers or Hosted by Zyberum](https://auto-st.com/deployment): AutoST deploys as a container on your own infrastructure, or as an instance hosted by Zyberum. The backend serves the API, the dashboard and the docs; the Carbyne agent runs on your bench. AutoST is multi-tenant with six roles and groups that own components, licensed per component count plus feature flags. Test results and reports stay with your organisation.
- [AutoST Pricing: Licensed per Component, Quote on Request](https://auto-st.com/pricing): AutoST is licensed per tested component (ECU), with feature flags for the engines you need, and runs either hosted by Zyberum or on your own servers. There is no per-seat charge; your whole team can use it. Pricing is on request: book a demo or send an enquiry with your number of ECUs and your test setup, and we will prepare a quote.
- [About AutoST: Built by Zyberum, an ECU Security Team](https://auto-st.com/about): AutoST is built by Zyberum GmbH, an automotive and embedded security team in Hannover, Germany, founded in 2019 by Tom Zaubermann, who previously led the InCar Security Testing Lab at Volkswagen AG. The team does hands-on ECU penetration testing and automated what it learned into AutoST. Its certifications include OSCP and the SAE and TÜV SÜD Automotive Cybersecurity certification for ISO/SAE 21434.

## Articles
- [Too few security engineers: automation, AI and reaching SOP clean](https://auto-st.com/insights/security-talent-gap-ai-automation): There are not enough automotive security specialists to test every ECU on every release. AI-driven automation is how a small team still reaches SOP clean.
- [Traceability in an ISO 21434 audit: making fuzzing count](https://auto-st.com/insights/traceability-iso-21434-audit): Security testing is required by ISO/SAE 21434, but tests only pass an assessment when they are traceable. Here is what an assessor looks for and how to get there.
- [UDS enumeration explained: how to map an ECU safely](https://auto-st.com/insights/uds-enumeration-explained): What UDS enumeration finds on an automotive ECU, why sessions and services matter, and how a non-destructive scan maps the diagnostic surface without breaking anything.

## German version
- https://auto-st.com/de