Hacking the Boosted Accessory Port

In late 2019, Boosted, an electric skateboard company based in Mountain View, California, developed smart skateboard lights called Boosted Beams that can attach to their boards. The Beams came with white headlights and red taillights, similar to the lights of a car. The lights were dimmable from the Boosted app, and the taillights blinked when the board was braking. This new product for the board also required the company to activate the accessory ports on the board, which were two hidden cables on every board that Boosted manufactured starting from 2016. Before the lights were developed, those ports were useless. Now, the ports supply power and data from and to the board.

​Shortly after, the company went out of business after negotiations with investors collapsed and they could not secure enough capital. Because the Beams were only in production for a short period of time, they became extremely scarce as some are selling on third party websites like Ebay for triple their retail price. It is almost impossible to secure your own Beams now unless you are willing to spend almost a grand on a pair of lights.

I tried to reverse engineer the accessory port that Boosted unlocked to effectively communicate with the board and utilize the power from the board’s battery. The end goal is to develop third party accessories for the board, just like the Beams, without having to carry an extra power supply to support the accessories. The first step is to create a product that mimics the original Beams’ functionality, and then to create further products that can improve the safety and enjoyability of the Boosted Board.

​The accessory port, located under the trucks of the board, comes with 4 pins: GND, +15V, CAN-H, and CAN-L. The correct signal must be sent through the two CAN pins, operating at 250k baud, within five seconds of the board turning on for the power pins to continue delivering power. Before the handshaking occurs, the behavior of the ESC depends on the configuration of the accessory, for the rest of this page, it will be assumed that the accessory is directly powered from the board as opposed to anther power source, as the latter results in a different ESC CAN frames in the beginning. Before any handshake is sent to the ESC, the ESC sends what I’ll call beginning sequences. Each beginning sequence contains over a hundred identical can frames. Each frame is separated by about 0.1 milliseconds, and there is about half a second between each sequence. The frames in the first sequence have a DLC of 8, and the ones that follow have a DLC of 6. Using a Saleae Logic 8 and its associated Logic 2 software, all the CAN frames could be interpreted. Using the software can be very useful in visualizing when each frame occurs and to identify patterns that correspond with certain actions, but it is difficult to filter out certain frames with specific parameters. In every figure, D0 is the digital TX and D1 is the digital RX.

Robert Scullin discovered that the handshaking to register the headlights is to transmit [FE 00 00 00 00 00 37 13] to [10 33 92 00]. To register the taillights, send [FE 00 00 00 00 01 37 13] to [10 33 92 00]. The transmission of the two lights are shown below. It is possible to only register one of the lights, which will still activate the power pins on both accessory ports, but the CAN messages that the ESC delivers will vary.

The lights can then be triggered on and off, either by double tapping the main button on the Boosted remote or toggling the Beams button on the Boosted app. When this happens, the ESC sends out four “command frames” followed by an “on frame”. The command frames are separated by about 280 microseconds, and the on frame is sent around 6.5 milliseconds later. The on frame has the exact same data as the last (4th) command frame, and both frames have a standard ID, making them slightly different. After that, the on frame is periodically sent every 50 milliseconds. Every on frame has the same data and a standard frame. When the lights are turned off, four different command frames are sent, and the only frames that continue to be sent on the bus after are the constant frames. Figure 6 shows the four command frames and the first on frame that follows. Figure 7 shows the command frames that come from turning the lights off.

The two CAN bus cables coming out of the accessory port are connected to a MCP2515 based CAN Bus module with the exact same wiring as the one in this repository, excluding the voltage regulator on the right side. Also, rather than wiring the Vcc of the module to +5V, I wired it to +3.3V. The Saleae is probing the Tx and Rx pins of the MCP2515. The LEDs on the breadboard are Adafruit NeoPixel Ring with addressable LEds. The input of the LEDs go to 6, and it is powered by the +5V of the Arduino. The power cables coming from the accessory port feed into the adjustable buck regulator, which drives the Arduino with +10V.

You can see a video of the functionality of the prototype here: https://www.youtube.com/watch?v=JPjtq_15DJU&feature=youtu.be.

** Warning: I demonstrate the braking functionality around the 10 second mark, so the video is very loud there **


4 Likes

Cool stuff! I have to admit, using a Logic would not normally be the way I’d go about doing CAN reverse engineering. But, it shows how versatile a tool like the Logic can be. And, let’s say you didn’t know it was CAN. Then you would need some means of determining what is going on. A tool like Logic is perfect for that! So, I think your post is very beneficial to Saleae as a good example of what their product is good for. Excellent write up and work.

1 Like

@rc68 Awesome work! I’ve just bought an Arduino CAN shield so I can try talking to an EV speed controller myself.

Is there any chance you have any saved CAN captures leftover? Here at Saleae we’re starting to add python high-level analyzer support for more of our existing protocol decoders, including the CAN analyzer. It would be awesome to try writing a high-level analyzer to decode the CAN traffic you recorded into detailed messages in the software, using python.

I agree, it definitely would have been very useful if I didn’t know what protocol the system was using. Even then, my Arduino module was able to give me the frames to analyze manually, and the Saleae gave me a visual representation of when the frames were occurring, which was useful. Thanks for the response!

** I tried to upload the captures to this reply but they wouldn’t complete uploading. Is there another way I can send this?

I still have most of the captures that I used!

To preface the captures, there were different frames in the beginning depending on whether the Arduino and CAN Module were powered via USB or through my skateboard battery. Not too sure why this happens, but since I figured the end product will be powered by the battery, those are the frames I should focus on. The first two captures are when the transceiver are powered by USB, and battery.sal is when it is powered via battery.

‘tx after 5.sal’ is the capture of when I transmitted the handshake after 5 seconds of the battery being on.

‘tx after 10.sal’ is the capture of when I transmitted the handshake after 10 seconds of the battery being on.

‘battery.sal’ is the capture of when the power source is solely the battery, and the handshakes are sent almost right after the skateboard and transceiver are turned on.

The forum should support uploading .sal files, but in case that it still doesn’t work for you, I’ll send you a private message with a link to a Google Drive folder.

Thanks!

If I try to upload all the files, the forum says they are updating with the percentage uploaded at the bottom, but then one or more of the uploads suddenly disappear. I tried to upload them one at a time but I can’t get some of the files to upload.

1 Like

Oh, we’re not hosting the forum, so I can’t fix that :frowning_face:
Have you seen my private message?