I am a satisfied owner of an eMTB with "That Smart System" installed.
Who am I kidding? While I do like the motor assist, the ecosystem itself is a walled garden.
Unacceptable in my book, so I got to work analyzing the bus captures of a few rides.

My ultimate goal is to build a custom dash, a purely passive add-on to a pretty good system.
Therefore I will focus on making the bus data accessible but not interfere with it by sending
unauthorized messages.

Grabbing the Bits off the Bus

By using a jerry-rigged 3D-printed connector for the battery port and an Adafruit Feather M4 "CAN Express" loaded
with the latest Supercan Firmware, the jank was kept negligible.

The parameters for the bus are configured as follows

# ip link set can0 type can bitrate 500000 dbitrate 2000000 berr-reporting on fd on sample-point .8 dsample-point .8
# ip link set can0 up

 
Standard CAN-FD affair, which has been found out by the good people at pedelecforum.de.

Finding a Pattern

After some time, I think I got a grasp on how the CAN messages are composed.
Almost all data is streamed as tag-value pairs,
with a header consisting of what I assume is a message authentication code (MAC) and a freshness counter to stop replay attacks reusing a packet.
Tags I refer to as Entry IDs, and their values may or may not be structures themselves, which I further discriminate into fields by index.

By looking at individual packets, it is evident that each Entry ID starts with a zero byte, followed by a low-entropy byte and then two high-entropy ones.
To keep decoding simple for now, I disregard any meaning from this and use the whole four bytes as a unique number to assign entries.

Using that information obtained by passively snooping around, I got a decode working in Python a few days in.

Behold, usable data!

The caveat to successfully decoding messages is correctly identifying the length of entries before the one of interest.
This resulted in quite a few "sink" entries in my definitions file which are just there and contribute nothing yet.

Trouble Might Be on the Way

There are still some concerns about the validity of the definitions file:

1. The Entry and CAN IDs may be bike specific, set at manufacturing.
This would throw a wrench in the gears, but we may be able to use frequency analysis combined with known sizes to make it auto-detect Entry IDs.

2. The actually juicy IDs may be derived from an initial negotiation process at boot, even worse because that potentially delves into reversing cryptographic assets.

So my request for anyone interested who has a BES3 "Smart System" and a CAN-FD-capable interface is to send over a bus capture.
Even just one could confirm if it "works on my machine" only or if it really was that easy.

The initial Python decoder can be found on this git.

Thank you for reading.
Next time I'll go into the hardware design of my custom dashboard.