Yes I think You’re right about the serial number of scooter. I think GPS box is doing something like handshake with ESC. ESC sending some requests packet to IoT and IoT send encoded with serial number answer.
By the way
7a 12 0a 45 4f a2 da 4d ee f7 3f 8a 3d c6
“7a 12 “- in here it’s something like a header of the packet,
“0a “ - its a length of 10 bytes
“45 4f a2 da 4d ee f7 3f 8a 3d “ - is 10 bytes of data
“C6” - this is crc8 byte coded with crc8 maxim.
And this packets they look like CAN packets.
So if we’ll get both Rx and Tx data I m sure we ll find out the algorithm.
funbag wrote: ↑Sat Mar 07, 2020 4:10 am
Great to hear that the scooter still is on!
The security codes may be unique for each scooter but that's a matter of finding the algorithm which might be based on the scooter's unique serial number or so.
My theory is that ESC sends a verification request with predefined prefix (7a 12 0a as well?) but random data suffix (based on serial number and/or internal clock perhaps?) to IoT box. The IoT box then sends a verification message back based on an algorithm and the input data with the 7a 12 0a prefix we've seen. So the only way to find a solution would be to find the algorithm, but to do that we need both Tx and Rx data with timestamps so we know which reply that belongs to each request.
In a best case scenario (probably too much to hope for), the IoT replies with exactly the same code that is sent by the ESC. Why would they do like this? Just to verify that the IoT box is connected.
Keep us posted!
1215941571 wrote: ↑Fri Mar 06, 2020 11:17 pm
Yeah when I have time i'm going to look into this. The scooter is still on i've just not had the time to log the data. I hope to do it for a hour or so to collect information, and hopefully capture any duplicates.
However with this being said i think its important to mention that there is a slight chance every bird may use its own unique sequence of security codes now. I tried forwarding the information from the glitched bird scooter to a standard deactivated scooter and it did activate but shut down after a few minutes with an error code. Either that or the two way communication from the scooter and IOT box is now mandatory, im unsure of this (i only forwared IOT TX to the deactivated scooter, not the RX).
Also, a lazy fix to this that I figured out is to spam the enable pin and constantly spam the enable TX code on the arduino. This will keep the scooter activated when the failsafe for the security bytes trigger, but the scooter will still have to come to a stop every few minutes. You can also overflow the buffer on the scooter by spamming the messages really quickly, which keeps it on for longer than 2 minutes as a result. But I'm not sure if theres a way around this the lazy way, but you have to be careful with the code because if you send the deactivate code and the enable is also sent to low, the scooter will come to a instant stop even if the wheel is spinning. I feel like the scooter update can be bypassed but it might require a bit of work...