Ad

Tuesday, December 14, 2021

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.

7 comments:

Alex said...

So you are saying that the QS-S4 display can be a replacement display for the Ti30?
Would you loose anything when switching the two?

What would be the best P-settings for speed?

Thank you.

Creation Factory said...

Hello @Alex,

"So you are saying that the QS-S4 display can be a replacement display for the Ti30?"

No. The two use very similar messages, but there are some differences such as the byte used for encoding the gear. Eventually some functions may work, but there is no way of telling without testing with an actual QS-S4. At least the gear change would not work correctly, but other important things such as the P-settings don't entirely correspond between the two. Also, the encrypted fields can also be different or encoded with a different key (don't have enough data samples from the QS-S4 in order to determine if the encryption key is the same or not).

You may compare the differences, by looking at the info shared by the user @raxrip regarding the QS-S4:

https://endless-sphere.com/forums/viewtopic.php?t=111236

Cheers

Creation Factory said...

@Alex, regarding you second question:

"What would be the best P-settings for speed?"

For the Laotie, in order to maximize top speed, you need to set this P-setting to 100%:

P08 - Performance (0-100%): 100

Even though in some scooters people play with the parameter:

P00 - Wheel diameter: 11

In this particular scooter I don't think that this makes any difference in manipulating the top speed, because it does not look like this value is sent to the speed controller, only used for calculating the speed presented in the display I believe.

Unknown said...

@Alex, thanks a lot for your job.

More people have Problem with cut off level. the scooter cut with battery 55V.

the P01 46V and the rear controler cut the battery. you know hgow we can solve this trouble with physical adjustment in controler or flash programmation ?

Thanks.

Creation Factory said...

@Unknown,

There are usually two different devices in the scooter which will do a voltage based power cutoff: one is the speed controller, and the threshold is defined by that P-setting. The other one is the BMS (Battery Management System) which is mounted within the battery itself. Now matter how low you set the cutoff voltage at the controller, if that threshold is lower than the BMS own threshold, the latter will kick in first.

Regarding the BMS, even if you are able to hack into it and change that value, it is a dangerous idea, as you increase the risk of battery dendrites and potentially a fire, or at least a damaged battery pack due to the deep discharge.

I personally prefer to stick to the controller default setting, and even then I don't let the battery discharge to the level where it shuts down the scooter.

Having the controller setting be so low that the BMS threshold is triggered also has the inconvenience that it might take some time until the BMS unlocks the battery protection.

Cheers

Mr.Anonymus said...

Hello CF!
First of, thank you for sharing all of this with us!
I recently bought a Ti30 and it is scary fast. Have you come up with a way of having "ECO" mode while no speed limit? It sure would be interesting!

Thanks in advance!

Creation Factory said...

Hello @Mr.Anonymus, no unfortunately I haven't yet found a way of removing speed limit from ECO mode. That would be great though, because the throttle curve is much smoother in that mode.

Cheers