# CaringCaribou: driving CAN bus security tests from the terminal

> CaringCaribou is a Python exploration tool for automotive CAN networks that ships UDS, DoIP, XCP and fuzzing modules behind one entry point. It is built for engineers with a bench and a spare ECU, not for scanning software in a lab.

**CaringCaribou/caringcaribou** — A friendly car security exploration tool for the CAN bus

- Repository: https://github.com/CaringCaribou/caringcaribou
- Stars: 970 · Forks: 231
- Language: Python
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/caringcaribou-caringcaribou

## A zero-knowledge tool for CAN networks nobody has documented

CaringCaribou fills a specific hole: automotive security testing lacked a tool that could be dropped onto an existing CAN network without prior knowledge of what was on it. The project frames itself as a zero-knowledge tool, one that can be put on any CAN network and collect information about which services and vulnerabilities exist. That framing rules out the common assumption that you already know the ECU, the protocol and the arbitration IDs, and it is why the tool leans on discovery modules before anything else.

The audience is automotive security engineers and researchers working on controller units rather than general application security staff. The topics the project carries are can-bus, ecu, fuzzing, security-scanner, security-testing and xcp, the primary language is Python, and the classifier set labels the software as intended for science and research audiences.

The protocol coverage is the interesting part. A clean install ships modules for raw traffic dumping and sending, arbitration ID enumeration, ISO 14229-1 Unified Diagnostic Services, diagnostic communication over Internet Protocol, the XCP measurement and calibration protocol, and two fuzzing families, one for raw CAN messages and one aimed at the randomness of UDS security seeds.

## One entry point, a flat module table, and a shared protocol layer

The whole tool hangs off one entry point, caringcaribou.py, described in the README as the main entry point that runs the show. From there the design is deliberately flat: each capability is a module file inside caringcaribou/modules, and the packaging registers each one as a console entry point.

```toml
[project.entry-points."caringcaribou.modules"]
dcm = "caringcaribou.modules.dcm"
```

Sharing happens through caringcaribou/utils, a folder of higher level CAN protocol implementations and shared functions meant to be used by modules. Two files there carry most of the weight. iso14229_1.py implements the ISO 14229-1 standard for Unified Diagnostic Services, and iso15765_2.py implements ISO-15765-2, the transport protocol that enables sending messages longer than eight bytes over CAN by splitting them into multiple data frames. can_actions.py provides abstraction for access to the CAN bus and for the bruteforce engines, common.py holds common functions and type converters, and constants.py holds constant definitions. Separating transport from service logic is what lets the DoIP module reuse diagnostics behaviour over a different link instead of reinventing it.

## Install with setup.py and learn the surface from the help screen

Installation is a plain setuptools build. The build requirements are setuptools and wheel, the runtime dependency list contains a single entry, python-can, and the stated software requirements are Python 3.7 or higher, python-can and a pretty modern Linux kernel. On the hardware side the project asks for some sort of CAN bus interface.

Install the package from a checkout like this:

```bash
python setup.py install
```

The quickest way to learn the surface area is the help screen, which lists all available modules at the bottom of its output:

```bash
caringcaribou --help
```

Module help works the same way, and module help always includes some usage examples:

```bash
caringcaribou send --help
```

Subfunctions get their own screens when a module has several:

```bash
caringcaribou send message -h
caringcaribou send file -h
```

A sensible first run is a passive one. The listener module lists all distinct arbitration IDs being used on the bus, which tells you what is talking before you transmit anything. The dump module writes incoming traffic to stdout or to a file, and the send module can then replay such a dump file. That order matters, because the fuzzer and UDS modules both want a bus you have already characterised.

## UDS and DoIP run the same diagnostics against two different links

The diagnostics side holds most of the functionality. The uds module discovers and utilizes various ISO 14229-1 services through subfunctions: discovery scans for ECUs supporting diagnostics services, services scans for the diagnostics services supported by a given ECU, and subservices enumerates supported subservices of those services. Other subfunctions act on the ECU rather than on it. ecu_reset resets an ECU, testerpresent forces a raised privilege diagnostic session against an ECU to stay active, security_seed collects seeds for a specific security access level in a specific diagnostic session, dump_dids dumps values of Dynamic Data Identifiers, and read_mem reads memory from an ECU. The auto subfunction is a fully automated diagnostics scan that reuses the already existing UDS submodules.

The doip module mirrors much of this over diagnostic communication over Internet Protocol under ISO 13400-2, with its own discovery, services, ecu_reset, security_seed, testerpresent, dump_dids and seed_randomness_fuzzer entries. The overlap is deliberate, since it lets you reach an ECU over a DoIP endpoint rather than a physical bus.

One piece of history deserves a flag. The dcm module is marked deprecated and has been replaced by the UDS module, though it is still supported for legacy reasons. It still appears in the entry point table, so older command lines remain available, but new work belongs on uds.

## Two fuzzing layers, from random CAN frames to security seed randomness

The fuzzer module works on raw CAN messages and offers five strategies. random sends random CAN messages, brute brute forces all possible messages matching a given bit mask, mutate mutates selected nibbles of a given message, replay replays a log file from a previous fuzzing session, and identify replays a log file to identify the message causing a specific event.

The uds_fuzz module is narrower and aimed at UDS security seed randomness evaluation and testing. seed_randomness_fuzzer performs ECUReset method fuzzing for seed randomness evaluation, and delay_fuzzer applies delay fuzzing to targets with weak randomness, matching an acquired seed and key pair to the delay in which the seed can be requested.

The xcp module covers the calibration side of the vehicle. Its discovery subfunction scans for ECUs supporting XCP, info retrieves information about XCP abilities of an ECU, and dump performs XCP Upload, used to dump ECU memory such as SRAM, flash and bootloader to a file. A separate test module runs the automated Caring Caribou test suites, and pytest and tox are offered as an optional test dependency.

On targets, the development setup used an STM32F107 based dev board from ArcCore, the Arctic EVK-M3, and the tool is described as usable against any ECU communicating over a CAN bus.

## The gaps that matter: real hardware, no dry run, GPL-3.0

The limitations are concrete. This is a hardware tool, and without a CAN bus interface and a modern Linux kernel you have a Python package and no bus to talk to. The python-can dependency also means the abstraction layer is only as good as the interface you plug in.

There is no passive default either. Fuzzing, sending, ecu_reset and read_mem all change bus state, and the README does not document a dry run, a rollback for a reset ECU, or any sandboxing of the target. In practice that pushes fuzzing onto a bench with a spare ECU rather than onto a vehicle you depend on.

The diagnostics modules assume a responsive ECU on a reachable bus, and the seed fuzzer assumes the target exposes the specific security access path you want to evaluate. The DoIP and XCP modules assume the corresponding transports exist.

Licensing has a downstream consequence too. The project ships under GPL-3.0, and setup.py declares license GPLv3 with a classifier for the GNU General Public License v3. Anyone planning to embed or redistribute parts of it inside a product should read how that licence treats their own distribution before building on it.

## Conclusion

CaringCaribou suits automotive security engineers who have a CAN interface and a spare ECU on a bench, and it does not suit teams that need a software-only scanner or a general protocol analyser. Before adopting it, confirm that your interface works with python-can on your kernel, and check the registered entry points for the modules you expect to run, since the packaging registers ten modules and one of them, dcm, is deprecated.

## FAQ

### What hardware does CaringCaribou need before it can talk to a CAN bus?

It needs some sort of CAN bus interface, plus Python 3.7 or higher, python-can and a pretty modern Linux kernel. The project links to a Linux CAN support page as the source for interface information.

### How do I add my own module to CaringCaribou?

Create a Python file with a function module_main(args), or copy the template at caringcaribou/modules/module_template.py, and place it in the caringcaribou/modules directory. Then add an entry under caringcaribou.modules in setup.py, run python setup.py install, and check that the module appears in the output of caringcaribou -h.

### Which Python version does CaringCaribou require?

Python 3.7 or higher. The packaging metadata lists python-can as the only runtime dependency, and pytest and tox are available as an optional test extra.

### What replaced the deprecated dcm module in CaringCaribou?

The UDS module replaced it. The dcm module is still supported for legacy reasons, so it remains registered as an entry point even though new work is expected on uds.

## Sources

- [CaringCaribou/caringcaribou on GitHub](https://github.com/CaringCaribou/caringcaribou)
- [Issues](https://github.com/CaringCaribou/caringcaribou/issues)
- [License: GPL-3.0](https://github.com/CaringCaribou/caringcaribou/blob/master/LICENSE)
- [README](https://github.com/CaringCaribou/caringcaribou/blob/master/README.md)
- [Releases](https://github.com/CaringCaribou/caringcaribou/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/caringcaribou-caringcaribou