I recently purchased the Unity, which has BT module built-in. While that’s certainly a nice and useful feature, there’s a big security hole. The problem is that there’s no BT pairing or any other security mechanism implemented. What that means is that anyone with a BT enabled mobile phone (= any mobile phone today) can connect to your Unity. That wouldn’t be a big deal if that merely allowed them to read the telemetry. The problem is that they can change any settings as well.
This allows doing pretty nasty things. Imagine someone remapping your PPM settings and causing that you go full throttle when you merely want to slowly accelerate. While I can’t see why anyone would do that intentionally (except maybe a very bad prank), I can imagine something similar happening accidentally on group rides when one person tries to change their riding profile and changes somebody else’s instead.
The problem is of course not isolated to the Unity. Many people use generic BT modules connected to the VESC via UART, which is basically the same setup as Unity that has the same vulnerabilities.
I personally do like the convenience of being able to read the VESC telemetry over BT/UART. However, I don’t really need to be able change my VESC settings in that way. I actually don’t even want that to be possible.
The simplest solution I can think of is to create a custom VESC FW that ignores any potentially harmful commands received over UART, namely all write commands. I have never done any VESC FW hacking before, but looking at the code it seems this could be a very small change. I believe adding a condition here would do the job.
I’m considering something like:
if (data[0] == COMM_GET_VALUES)
commands_process_packet(data, len, app_uartcomm_send_packet);
This should only process the COMM_GET_VALUES
command, which is the request for the telemetry data and silently ignore any other received commands.
Of course other safe commands can be whitelisted the same way. This is just a example, but you get the idea.
Now, could anyone with some VESC FW hacking experience confirm this would work without breaking other critical functionality?