An Electric Scooter Community on a Mission to Stamp out Transportation Mediocrity.

Changing mobility one trip at a time.
#19848
Hi Rick, thanks for the hint with the battery but unfortunately it did not work. I disconnected both cables from the battery and reconnected them after about 10 seconds. But the same problem still appears: no front-light, just the red back light. And in the display the symbol for the light also appears. Any idea if there might be a cable broken and/or something else? I thought about to wire the back light with the front light as a workaround but that sounds a bit stupid to me if it is just a "software"-bug or something else i could fix. Thanks for more ideas!
Rick Sanchez wrote:
Sun Feb 23, 2020 8:04 am
@Biingobom yes I had this problem once, It was fixed after a battery disconnect and reconnect.





#19970
Hello, if it s possible, can u get Tx and Rx data or just rx data from IoT GPS box
1215941571 wrote:
Sun Feb 16, 2020 11:43 pm


I've attached a dump of some new scooter data. This is the data that the scooter receives from the IOT box for activation. You can see that the same old 6a 12 02... activation command is still the same, but the new expected command starts with 7a 12 0a... and then has a series of 11 bytes that are calculated through the algorithm. The dump was a random 3 minute capture from a scooter that was activated (glitched) for a few days.
https://gyazo.com/b637361f75a1f96671e1a1966ddd1566
This view in notepad visualizes the data a bit better. I have a bird that is running the new software with the new security bytes, but is in a glitch state and has been activated for about 5 days now running at full speed. If theirs any sort of debugging tips I can do to maybe help track down how the algorithm is calculated, definitely let me know. In theory the scooter will be on until it loses power, so as long as I keep it charged I should have enough time to crack the code, as long as I know what im looking for.

#19991
Jvon wrote:
Tue Mar 03, 2020 8:35 pm
Hello, if it s possible, can u get Tx and Rx data or just rx data from IoT GPS box

Agree, there is probably a two way communication between IoT box and ESC so it would be really interesting to see the Rx data from IoT box as well. Simultaneous logging of Tx and Rx is most preferable, hopefully not a must, since we then can identify exact messages that the ESC/IoT reply to.

#20011
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...
Jvon wrote:
Tue Mar 03, 2020 8:35 pm
Hello, if it s possible, can u get Tx and Rx data or just rx data from IoT GPS box
1215941571 wrote:
Sun Feb 16, 2020 11:43 pm


I've attached a dump of some new scooter data. This is the data that the scooter receives from the IOT box for activation. You can see that the same old 6a 12 02... activation command is still the same, but the new expected command starts with 7a 12 0a... and then has a series of 11 bytes that are calculated through the algorithm. The dump was a random 3 minute capture from a scooter that was activated (glitched) for a few days.
https://gyazo.com/b637361f75a1f96671e1a1966ddd1566
This view in notepad visualizes the data a bit better. I have a bird that is running the new software with the new security bytes, but is in a glitch state and has been activated for about 5 days now running at full speed. If theirs any sort of debugging tips I can do to maybe help track down how the algorithm is calculated, definitely let me know. In theory the scooter will be on until it loses power, so as long as I keep it charged I should have enough time to crack the code, as long as I know what im looking for.

#20012
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! To view images REGISTER or LOGIN for full access.

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...

#20026
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! To view images REGISTER or LOGIN for full access.

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...

  • 1
  • 64
  • 65
  • 66
  • 67
  • 68
  • 71
Flash / Circ Scooter Model?

The brand is Manke The model is mk088

first off when my battery finally dies, i don't wa[…]

I’m not sure I’m still trying to figur[…]

Hallo. Kein Plan was hier los ist wegen den Nachri[…]