# CAN Commander, a Flipper Zero front end for a CAN bus

> CAN Commander is a Flipper Zero application that drives a small ESP32 board over UART, and the board does the CAN work while the Flipper renders dashboards, holds profiles and streams events back. The documentation is unusually good for a hardware project, with a workflow-oriented tool reference, a status glossary and a section of safe-use notes, and the design decisions that stand out are the version handshake at boot and the in-frame swap that makes injection selective.

**MatthewKuKanich/CAN_Commander** — CAN Commander is a comprehensive tool designed for the reverse engineering of CAN (Controller Area Network) bus systems. This project aims to provide a robust platform for automotive enthusiasts, engineers, and security researchers to interact with and analyze CAN networks, facilitating a deeper understanding and manipulation of communication.

- Repository: https://github.com/MatthewKuKanich/CAN_Commander
- Stars: 1,077 · Forks: 91
- Language: C
- License: not declared
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/matthewkukanich-can-commander

## The Flipper renders, the ESP32 drives the bus

The architecture is the first thing to understand, and the documentation states it plainly. CAN Commander on Flipper is a UART-driven user interface and controller for the CAN Commander ESP32 firmware. The core behaviour is a division of labour: Flipper sends tool and configuration actions over UART, the ESP32 executes the CAN operations and streams events back, Flipper renders structured dashboards and status and monitor output, and Flipper also handles profiles, save data and configuration.

That split is forced by the hardware. The Flipper Zero has GPIO pins, not a CAN controller, and the ESP32 board has both the CAN transceiver and the firmware to drive it. Rather than pushing raw CAN handling onto a microcontroller with a small display and a constrained CPU, the design gives the Flipper the part it is good at, which is a screen, a keypad and storage.

The startup sequence shows how carefully that boundary is managed. The app enables 5V OTG to power the CAN Commander board if it is not already on, settles for 400 milliseconds while the ESP32 finishes booting, then performs a clean UART connect with a Ping and runs the firmware version check with GetInfo. If the firmware is below v2.2, a status screen with the warning and an update URL is pushed on top of the main menu, and pressing Back returns to the main menu with the warning not showing again for the rest of the session.

The connection handling is equally deliberate. The UART ping is retried up to three times with a 50 millisecond gap before the board is declared offline, and the documentation explains why: it eliminates the rare false Not connected pop-up that previously fired on a single transport glitch. A tool that shows a false disconnection during a capture is worse than one that is slow to report a real one, and the retry is three lines of policy that encode that judgement.

There is one more navigation rule worth knowing before you press anything. Pressing Back from an active tool stops that tool automatically, as designed.

## The tool menu is organised by what you are trying to do

The documentation presents the tools as workflows rather than as a list of functions, and the menu structure follows that. The tools are grouped into Monitor and Discovery, Vehicle Diagnostics, and Control and Injection.

The first workflow is reading. Read All Frames is a quick sanity check that traffic is present, and the documentation is explicit that you use it when you do not yet know which identifiers matter, and it suggests switching to a filtered read if the traffic is too heavy. Filter and Read Frames is the second step, where you set bus, mask, filter, ext_match and ext, and it is the tool for tracking a specific ECU or message.

The second group is diagnostics. OBD2 Live Data with a PID list polls live vehicle data such as speed, RPM and fuel level. Fetch VIN grabs the vehicle identification number. Fetch DTCs pulls diagnostic trouble codes, and the display has separate pages for summary, stored, pending and permanent codes. Clear DTCs clears the codes and resets the check engine light. The documentation says to use this group when you are using CAN Commander primarily as a diagnostic and scan workflow, and that framing is honest, because those are the operations a mechanic performs and the reason a lot of people buy a CAN tool at all.

The third group is where the project earns its name as a reverse engineering tool. Write Frames sets bus, id, ext, dlc, data, count and interval_ms, and while the write dashboard is open, pressing OK resends the current payload using the same count and interval configuration, which is the fast iteration loop for someone working out what a particular byte does.

The documentation marks Smart Injection as the primary way to inject data onto the bus, and the distinction is not cosmetic. A plain write replaces the whole frame, which overwrites every signal in it. The replay tool reproduces a captured sequence with its original inter-frame timing, and it records up to 384 frames for one CAN identifier, with playback speed fixed at 100 percent, in other words real time, and a loop count from 1 to 99.

## Smart Injection swaps bits inside a live frame

The mechanism that makes injection selective is worth describing on its own, because it is the most interesting engineering idea in the documentation.

Smart Injection stores live data as it comes in for the selected identifiers, tracks that data, and then performs in-frame bit or data swaps while keeping all unwanted signal changes untouched. The stated consequence is that it is safe to inject specific signals and commands without causing unwanted signals to be affected or modified.

That is a significant difference from writing a frame. A vehicle CAN frame is a container of many signals packed into a handful of bytes, and a naive write of the right bytes will set every signal in those bytes, including the ones the sender is actively updating. On a real vehicle, that means a counter or a checksum or a liveness signal in the same frame gets frozen at whatever value you wrote, and the receiving ECU may reject the frame or may behave unpredictably. It also means that a replayed frame is stale by definition, since the live sender would have produced something different a millisecond later.

The approach in the documentation avoids that. The tool watches the real frame, keeps the parts it does not care about exactly as they arrive, and replaces only the bits or fields the user selected. The configuration for a slot includes a name, bus, ID, the bytes or bit or field to change, a mux setting, a count and an interval, and the workflow is to open a slot, configure it, save it, then use Start to sync the slots and enter a live view, where selecting a slot and pressing OK triggers the injection.

The same slots can be saved as a profile with Save Profile and restored with Load Profile or through the Profiles view, which is what makes the tool usable for a repeatable test rather than a one-off poke. The mux setting in the slot configuration is the detail that signals the designer's familiarity with real vehicle traffic, where several signals share the same identifier and are distinguished by a multiplexing nibble.

## Replay: 384 frames at original timing

The Replay tool is the most conventional of the three injection tools, and the documentation is explicit about when it is the right choice.

The workflow is to set bus, id and ext for the frame you want to capture, then Start. On the replay dashboard, pressing OK begins recording, and the screen shows a live elapsed timer and a frame counter. You then trigger the action on the vehicle that produces the target frames, and press OK again to stop recording, or wait until the buffer fills.

Once frames are captured, Left and Right set the loop count from 1 to 99, OK plays them back at the original timing, and Up clears the buffer if you want to record again. Pressing OK or Down while replaying stops the playback.

The documented use is capturing a sequence such as a button press or a CAN handshake and reproducing it exactly with the original inter-frame timing; a single Write Frames burst is not enough when you need timing fidelity. That is a real distinction. A burst of frames with a fixed interval does not reproduce a handshake, because a handshake is a sequence whose correctness depends on the gaps between messages rather than on the messages themselves.

The limits are stated in the same breath. The tool records up to 384 frames for one CAN identifier, and the playback speed is fixed at 100 percent, which is real time. So the capture is short, the replay is honest about timing rather than allowing acceleration, and the loop count is what lets a sequence repeat for as long as you need to observe a response.

## Diagnostics that a general-purpose analyser will not have

The Vehicle Diagnostics group is the part of the tool that a buyer who is not doing security research will actually use, and it is worth describing on its own terms.

OBD2 Live Data with a PID list is a polling interface for the standard vehicle parameters, speed, RPM and fuel level among them. Fetch VIN retrieves the vehicle identification number, which is the first thing you need when you want to know which car is on the other end of the bus or when you are pairing a capture with a specific vehicle. Fetch DTCs retrieves the diagnostic trouble codes, and the display is organised into four pages: summary, stored, pending and permanent. Clear DTCs clears the codes and resets the check engine light.

The four DTC pages are the part that shows the author has used the tools. A single list of codes is not much use, because a stored code is a historical record of a fault that has already happened, a pending code is one that has been seen once and not confirmed, a permanent code cannot be cleared by the scan tool at all, and a summary is the count across all of them. Presenting them as one flat list hides exactly the distinctions a technician needs.

The documentation's framing is worth repeating because it is a good description of the tool's scope: use this when you are using CAN Commander primarily as a diagnostic and scan workflow. It is an admission that the tool does more than read frames, and a reminder that the injection features are the specialised part rather than the everyday one.

The Auto Reverse Engineer tool sits on the other side of the menu, in Monitor and Discovery, and begins with a Calibration phase in which the documentation tells you to hold still, which is a first indication of what it does: it watches the bus while you move a control, and works out which bits respond to which movement.

## Profiles, the firmware handshake and who owns the versioning

The documentation covers two file formats for saved work, .injprof and .dbcprof, in its profile and storage appendix, and the tool list refers to Save Profile and Load Profile for the reusable injection setups. Saving a working setup matters more in a vehicle context than in most software, because a setup that took an afternoon of bit-level experimentation to find is not something you want to rediscover at the roadside.

The versioning story is more interesting, and it is the part a new user will hit first. The current app version in the source is v2.3.1, held in a constant called PROGRAM_VERSION in can_commander.h. The minimum supported ESP32 firmware is v2.2. The app handshakes the firmware version at boot and surfaces a warning if the board is running older firmware.

So there are two version lines, an application and a firmware, and the application refuses to pretend they match. A user who flashes old firmware gets a warning screen with an update URL pointing at cancommander.com, rather than a mysterious failure later. That is a well-judged design for hardware, where the app and the board are two separate things that can be out of step, and where the failure mode of not checking is a tool that appears to work and silently does the wrong thing.

The documentation also notes that community development may move faster than the written documentation, which is why the guide points at the release notes attached to the version you installed, at the community, and at experimenting. For a project distributed as an app and a firmware image to a device, that is the correct set of references to trust over a wiki page that is edited on a different schedule.

## Where CAN Commander is the wrong tool

The first limit is the hardware dependency, and it is total. The tool is a Flipper Zero application that expects a specific CAN Commander ESP32 board on the GPIO pins, with CAN wires on the screw terminals and the primary bus on the right port. A lab with a professional CAN interface, a USB adapter and a laptop has none of the pieces this needs, and the project offers nothing for that case. There is no standalone desktop mode and no generic serial protocol documented for use with other hardware.

The second is the safety question, and the documentation has a whole section for it, known limits and safe-use notes. The tool can transmit on a live vehicle bus, and the Clear DTCs function resets the check engine light, which is a change to the vehicle's state. A technician who does not know which mode the bus is in can write to an ECU that is actively controlling something. The documentation's framing is that Smart Injection is the safe way to inject vehicle controls and commands, and that is true, but it is a mitigation rather than a guarantee, and the tool is a research platform rather than a diagnostic analyser with a safety interlock.

The third is what the repository actually contains. The top level holds a README, a CAN_Commander_FlipperZero/ directory with the application and a Legacy/ directory, which suggests the repository is mostly documentation and the Flipper application, with the ESP32 firmware and the hardware design living elsewhere. A reader looking for the firmware source or the schematic will not find them here.

The fourth is the licensing and release hygiene. The repository records no licence, publishes no releases, and the last push was on 2026-04-25. For a project whose users install an app onto a device and flash firmware onto a board, the absence of a stated licence and of versioned releases makes it hard to build a process around.

The fifth is the audience. The project describes itself as a tool for automotive enthusiasts, engineers and security researchers, and the workflows assume some familiarity with CAN, with identifiers and masks and multiplexing and diagnostic codes. It is not a learning tool, and the documentation does not explain the protocol.

## Conclusion

CAN Commander fits a vehicle security researcher or a mechanic who already owns a Flipper Zero and a CAN Commander board and wants a laptop-free way to read, filter, diagnose and replay traffic, and the diagnostic workflows are the part a general-purpose analyser will not have. It does not fit a lab without that hardware, since the whole design is a Flipper application driving a specific ESP32 firmware, and it does not fit anyone who needs to transmit on a live vehicle bus without reading the safe-use notes first. Before you use it, confirm the firmware is v2.2 or later, because the app refuses to work properly with anything older and says so at startup, and remember that the documentation in the repository is the product here, since the top level holds a README, a Flipper application directory and a Legacy directory. The licence is not recorded, the repository has no releases, and the last push was on 2026-04-25.

## FAQ

### What hardware does CAN Commander need?

A Flipper Zero with the CAN Commander ESP32 board connected over GPIO, with CAN wires attached to the board's screw terminals, where the primary bus is the right port. The minimum supported ESP32 firmware is v2.2, and the app warns at startup if the board is older.

### How does CAN Commander check the firmware version?

At startup the app powers the board over 5V OTG, waits 400 milliseconds for the ESP32 to boot, then performs a clean UART connect with a Ping and a GetInfo version check. The ping is retried up to three times with a 50 millisecond gap before the board is declared offline.

### How many frames can the CAN Commander Replay tool record?

Up to 384 frames for a single CAN identifier. Playback speed is fixed at 100 percent, in other words real time, and the loop count can be set from 1 to 99 so a captured sequence repeats as many times as you need.

### Can CAN Commander read diagnostic trouble codes?

Yes. The Vehicle Diagnostics group offers OBD2 Live Data with a PID list for polling parameters such as speed, RPM and fuel level, Fetch VIN, Fetch DTCs with separate summary, stored, pending and permanent pages, and Clear DTCs to clear the codes and reset the check engine light.

### What is the difference between Smart Injection and Write Frames?

Smart Injection stores live data for the selected identifiers and performs in-frame bit or data swaps, leaving unwanted signal changes untouched, which is the documented primary way to inject data onto the bus. Write Frames sets the whole payload with bus, id, ext, dlc, data, count and interval, and pressing OK resends that same payload with the same settings.

## Sources

- [Issues](https://github.com/MatthewKuKanich/CAN_Commander/issues)
- [MatthewKuKanich/CAN_Commander on GitHub](https://github.com/MatthewKuKanich/CAN_Commander)
- [README](https://github.com/MatthewKuKanich/CAN_Commander/blob/main/README.md)

---

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