Reverse engineering the Laotie Ti30 scooter LCD display - part 3 - Encryption Broken!

 

 

In the previous post I had the chance of discovering and documenting most of what there is to learn about the communication between the LCD unit and the master ESC (speed controller) that drives the e-Scooter rear motor.

This is interesting information for anyone willing to build something that interfaces directly with these components. For example if the user wants to write an app that captures the speed information and other status data, knowing the serial protocol is of great use in order to implement a Bluetooth module that acts as man in the middle, and sends the data to a smartphone. Alternatively one might be interested in building a hardware device that fully replaces the LCD unit, e.g. exposing a fancy TFT LCD display with more features than currently provided by these units.

Because I didn't want to leave this topic incomplete, I decided to keep on digging and try to figure out what was that mystery byte B05 sent by the LCD in every transmitted frame. Because its value would both change erratically, and because I could not find how the gear data was being sent to the ESC, I got intrigued and suspected that this information had to be contained in this byte and sent with some form of encryption.

I started by a entering a John Nash kind of groove, while looking at long sequences of numbers and obsessively searching for a pattern.

While I realized that these sequences didn't seem that random anymore, there was still something missing in order to get the complete picture.

That is when I had the idea of throwing the values into an Excel spreadsheet, and get a plot of it. What a better way to understand patterns, than to represent these visually.

I could immediately tell that there was a fixed pattern that would repeat every 128 frames. By adding the frame sequence number to the graph, I could verify that (conveniently) there was correlation between the frame number and the increment relative to the previous value. 

This meant that the mystery field was a value being encrypted with a simple substitution cipher (pretty much a form of Vigenère cipher). So in principle extracting this collection of offsets from a certain chunk of ciphertext should get us the key. Because the exact values of this pattern would simply repeat over time, I took the assumption that the plaintext was not varying. And assuming that these were indeed offsets, I took the minimum value in the collection and built a key map by subtracting the minimum from each value in the latter.

Ran the key map against a larger dataset, and voilà:

I could see what appeared to be actual data.

Thinking back about the frame sent by the ESC, where I assumed that byte B03 was just an offset for providing entropy to other bytes of the payload, I decided to run the same type of analysis on the sequence of this "entropy" field, and I realized that just like in the LCD frame, albeit different, it was a pattern that also varied according to the frame:

Taking this information into consideration, I changed the two Python scripts (one for the LCD and one for the ESC frames) to decrypt the fields based on these two key maps. And to my satisfaction, this was correct. I could now understand what was the "mystery" field. It was nothing more than (as I suspected) the encoded gear value. As I varied the gear in the LCD unit, I would obtain the following values in binary:

• Gear 1 - 0b00000101
• Gear 2 - 0b00001010
• Gear 3 - 0b00001111
  

For converting to the gear number I would simply mask the 6 most significant bits. So far I did not see other bits varying differently in this byte.

As before, the protocol details and the python scripts can be found here:

https://github.com/teixeluis/escooter-lcd-esc-decode

I also replaced the decryption of the ESC frames, by using the offset map as well, as given what I learned in this iteration, there is the possibility that what I considered as an entropy key, i.e. the byte B03, is also an encrypted field, even though so far from my observations it is always constant.

This information is valid for the LCD and Speed Controller manufactured by the company named Jipin (often also labeled as J&P). As I have mentioned in a previous post, this frame follows the same overall structure as the QS-S4 display, even though the meaning of the fields is not entirely the same in the latter.