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

Covers electric scooter models whether shared or for consumers.
#7507
Jameskay wrote:
Fri Feb 01, 2019 8:02 pm
Am i missing something obvious or is this a new version of the lime display board with no Bluetooth antenna?
Image
I have a SZ2.5 Lime that has the same board like yours. You can see 4 points on the board, 5v GND Dat Clk, if you probe them with multimeter you will get 0 Volts, BUT, if you plug in the battery and all, and from the green connector that goes to the green gps box, you short the blue wire with the red, the controller starts, and you hear a small tick from the front wheel, and then the dashboard gets 5v,gnd,clk,data, but lights dont come up. If you probe the data line with a logic analyzer, you get partial ticks, meaning that it's trying to communicate
#7511
orac12 wrote:
Sun Apr 28, 2019 3:10 am
Interesting theory but quite far from the mark sorry.
Hello Orac12!
Ok so you said that I'm far from your solution, am I?
Let me just explain you my new theory.
Your little photo taken with your Galaxy S7 is... a FAKE !!!
Indeed, I already saw LIME scooter with switched on dashboard but locked.
Versions of VOI scooter has their dashboard switched on, on the street but when you pushed it: beep-beep-beep ! => locked !

It means that you stole a locked LIME scooter with ON dahsboard, unmount green box and connected scooter to a bt interface. Then showing to the rest of the world that you are better than anybody, even LIME/GOOGLE, XIAOMI/SEGWAY !!
Ahahah lol ! It's a good joke !

You tried to convinced us that you made injection with your HC-06 bt board and your laptop. But when I tell you about traffic protocol, you say no no it's not the solution! Dude you made the correct setup for that. Don't tell me the contrary!

There is something odd on your setup: you have 4 wires white, blue, yellow orange. But you only need 2 and the gnd. I know that both others are 31V level: is it another joke?

So unless orac12 you give us an indisputable and undeniable clue: guys, don't rely on this joke!
#7526
STM32F103:) wrote:
Fri Apr 26, 2019 4:21 pm
Hello everybody!
Nice work and very good posts!
Concerning orac12 performance on Lime: my opinion is the following.
It's possible to spy communication between the lime green box and the internal control board. It's a uart 115200 link, 3.3V level.
RX and TX wires can be monitored using saleae analyser or 2x USB FT232 3.3v level connected on Realterm software.
Doing that during a rental transaction with online bank card registered on your lime application installed in specific phone (to hide your *ss).

Then we get a traffic like this (below was taken between dashboard and esc):
(...)
5AA50521206500042B2A0000FBFE
5AA50721206400062B2A00000202F4FE
5AA5062021640004000000000050FF
5AA50020210100BDFF
5AA50D212004004E4253636F6F746572423932375AFB
5AA50721206400062B2A00000202F4FE
(...)
Explanations here: https://github.com/etransport/ninebot-d ... i/protocol

At the same time, we certainly need to spy bluetooth communication :
medium.com/@bdesnos/comment-jai-hack%C3%A9-ma-trottinette-4eae1fc1dca1

Under arduino, it can be possible to make a fake green box and send what the control board expect based on previous traffic spying.

For the moment the traffic between board is clear and not encrypted. As you know, firmware updates are nowadays encrypted to prevent hacking. One day, a Lime update will certainly hide all previous traffic between all internal boards.

Some words about online binary firmwares such as :
https://github.com/Ch4rlus/ninebot_firmware
or https://ninebot.scooterhacking.org/

The main difference between these binary and a .bin/.hex/elf from a gcc compiler is that first one is transmitted to the lime bootloader through bluetooth. The second binary is sent to the DFU bootloader inside each stm32 with an usb probe. Same thing for dashboard.
DFU stores data starting from begining of memory.
Lime bootloader stores update in a specific regions (see memory map here: https://github.com/etransport/ninebot-docs/wiki/ES2ESC) + parameters.
So binary found at Segway is not stored continuously into stm32 flash.
Lime bootloader decryts binary and then places it where they decided into the memory.
Download this kind of binary with a SWD probe will take place of the lime bootloader with nosense datas!

For me, the best way will be to ask to Chinese sellers, the binary which are loaded at factory into NRF51822 and STM32.
Then we can change firmware of ninebot lime material.

Another solution is as explained by DedX to find an old dashboard version (older than V5.0.5) to reflash control board.

Or if orac12 may help us!

This is my contribution.
Hope this can help.
That IS the way to go, but with just one detail: that Lime model (2.5) does not work with bluetooth. It is not a Ninebot nor a Xiaomi. All comms are serial/cable
#7527
Here's a little contribution by me aswell. Scooter is SZ2.5. Voltages appear on dashboard, after you short the blue wire from the green gps cable, to 36v, and led on controller starts blinking, and a momentary tick can be heard from the front wheel motor. The logic is the following: Green box receives the server signal to start the scooter after transaction is complete etc etc, it shorts the blue wire to 36V to enable the controller. After the controller is enabled, the TX2 pin which can be seen in the pictures is going from 4.3V to ~5V and down to 0V, and is trying to speak to the green box. I think the green box is only replying with an "ok" type signal like 0xFF or something similar, and not with a special "code" which is bound to the specific scooter. I think the scooter identification is solely done on the green box side, since it's the one that communicates with the servers and therefore with the user application. The STM32 on the controller has the same program on every scooter, and expects a simple talkback from the green box saying "start". Honestly, i think @orac12 has done an excellent job finding that "ok" reply that the greenbox will send to the controller and is not lying at all. Props, will try to find that ok code aswell :P
Image
Image
Image
Image
Image
Image
Image
Last edited by fieldc0llapse on Mon Apr 29, 2019 6:20 pm, edited 1 time in total.
#7528
nbr576n765iumr6n wrote:
Mon Apr 29, 2019 4:57 pm
STM32F103:) wrote:
Fri Apr 26, 2019 4:21 pm
Hello everybody!
Nice work and very good posts!
Concerning orac12 performance on Lime: my opinion is the following.
It's possible to spy communication between the lime green box and the internal control board. It's a uart 115200 link, 3.3V level.
RX and TX wires can be monitored using saleae analyser or 2x USB FT232 3.3v level connected on Realterm software.
Doing that during a rental transaction with online bank card registered on your lime application installed in specific phone (to hide your *ss).

Then we get a traffic like this (below was taken between dashboard and esc):
(...)
5AA50521206500042B2A0000FBFE
5AA50721206400062B2A00000202F4FE
5AA5062021640004000000000050FF
5AA50020210100BDFF
5AA50D212004004E4253636F6F746572423932375AFB
5AA50721206400062B2A00000202F4FE
(...)
Explanations here: https://github.com/etransport/ninebot-d ... i/protocol

At the same time, we certainly need to spy bluetooth communication :
medium.com/@bdesnos/comment-jai-hack%C3%A9-ma-trottinette-4eae1fc1dca1

Under arduino, it can be possible to make a fake green box and send what the control board expect based on previous traffic spying.

For the moment the traffic between board is clear and not encrypted. As you know, firmware updates are nowadays encrypted to prevent hacking. One day, a Lime update will certainly hide all previous traffic between all internal boards.

Some words about online binary firmwares such as :
https://github.com/Ch4rlus/ninebot_firmware
or https://ninebot.scooterhacking.org/

The main difference between these binary and a .bin/.hex/elf from a gcc compiler is that first one is transmitted to the lime bootloader through bluetooth. The second binary is sent to the DFU bootloader inside each stm32 with an usb probe. Same thing for dashboard.
DFU stores data starting from begining of memory.
Lime bootloader stores update in a specific regions (see memory map here: https://github.com/etransport/ninebot-docs/wiki/ES2ESC) + parameters.
So binary found at Segway is not stored continuously into stm32 flash.
Lime bootloader decryts binary and then places it where they decided into the memory.
Download this kind of binary with a SWD probe will take place of the lime bootloader with nosense datas!

For me, the best way will be to ask to Chinese sellers, the binary which are loaded at factory into NRF51822 and STM32.
Then we can change firmware of ninebot lime material.

Another solution is as explained by DedX to find an old dashboard version (older than V5.0.5) to reflash control board.

Or if orac12 may help us!

This is my contribution.
Hope this can help.
That IS the way to go, but with just one detail: that Lime model (2.5) does not work with bluetooth. It is not a Ninebot nor a Xiaomi. All comms are serial/cable
The console has bluetooth the scooter doesn't. If you go near a Lime 2.5 and you scan bluetooth (must be android) it shows "lime-XXXXXXXXXXXXX" connecting to this (Pair code 0000) fails to connect so it needs to accept paring or something
  • 1
  • 69
  • 70
  • 71
  • 72
  • 73
  • 136

As this was a rental version whos overstock was […]

Any one got any info on beryl bikes I seen a few[…]

LH/ TF-100 Style Display.

Hi I recently converted a Bird Zero to a personal […]

How do you operate dash without button? I have[…]