UDS fuzzing
Random payloads on standard or non-standard service IDs, with session re-entry, configurable timeouts and an exclusion list.
Engine · Fuzzing
Break it on the bench, not in the field.
AutoST throws malformed and unexpected traffic at an ECU and watches for the moment it stops responding, resets or throws a fault. Every run is reproducible, so a crash can be replayed and handed to developers.
In short
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.
Two modes
UDS and CAN, your choice
CAN fuzzing
Random classic and FD frames on arbitration IDs from your DBC, with a reproduce count to confirm a finding before it is logged.
Crash detection
How AutoST knows something broke
Liveness
A TesterPresent check after every iteration catches an ECU that has stopped responding. Always on.
DTC monitor
Optionally watches the diagnostic trouble code count and flags any change during the run.
Timeouts
Timeouts and transport errors on a fuzzed request are recorded as findings, with the exact payload.
Reproducible by design
A crash you can replay
Every fuzzing run is driven by a seed that AutoST stores and shows. Re-run with the same seed and you get the same sequence, so a crash is not a one-off you can never find again.
Each finding is recorded with its iteration, timestamp, the monitor that caught it and the payload, plus a short history of the last payloads leading up to it.
- Seeded, reproducible runs
- Payload and monitor recorded per finding
- Live iterations, crashes and requests per second
- Exclusion lists for IDs and service IDs
Safety
For the bench only
Fuzzing can put an ECU into a fault state, reset it or brick it. AutoST is a bench tool: never fuzz a vehicle in traffic or a system whose failure could hurt someone.
- Run on an isolated bench
- Never on public roads
- Keep a recovery path for the ECU
FAQ
Frequently asked questions
Is the fuzzing reproducible?
Yes. Each run uses a stored seed, so you can replay the exact sequence that triggered a crash and hand it to developers.
How does it detect a crash?
With a TesterPresent liveness check after every iteration, an optional DTC-count monitor, and timeout or transport-error detection on the fuzzed requests.
Can I fuzz a car on the road?
No. Fuzzing is a bench activity. It can put an ECU into a fault state, so it must never run on a vehicle in traffic.
See it on your ECU
See AutoST run against your kind of ECU
Book a one-hour live demo. We scan a real target, walk through the findings and the Fix Plan, and answer whatever you throw at us.
- A security engineer runs it, not a sales rep
- Bring your own protocol and hardware questions
- Free, and a clear next step afterwards
Your demo is withTom ZaubermannFounder of Zyberum, ex-lead of the VW InCar Security Testing Lab
Already trusted by Tier 1, Tier 2 suppliers and OEMs. References on request.
Or send us a message
We reply within one business day.