dangers of stock OTA updates / whitelist proposal

[Lanchon]

hi,

first let me thank you and all the people behind these hacks for your work. i bought an S5 max a while back, mi first robotic vacuum, because i knew i could root it. i wouldn't have otherwise.

but i didn't actually root it. knowing i have the freedom to do it at any time i see fit has been enough for me. contrary to all my phones (which are de-googled and use free software OSes), i didn't feel the need to hack the S5 max before first usage.

the problem is, every couple of months i get a firmware update. and at any time, roborock could make my robot unrootable with an update. normally i wait for https://builder.dontvacuum.me/_s5e.html to add the firmware version before updating my robot and assume there wont be a problem then.

but of course, that is a totally unwarranted assumption. is there any way users can know which stock firmware versions are rootable before updating to them? it would be awesome to have a whitelist somewhere, preferably noting which root method works on each firmware.

since this project is at least somewhat involved in rooting and routinely analyzes most firmware versions, could you maybe consider maintaining such a list?

if not, at least when you add a firmware to builder.dontvacuum.me could you consider adding a note to the fw version selector if issues are rumored with a particular version? something like: (rooting issues suspected, see: [...]). i know it has nothing to do with the builder itself, but yours is the only list of fw versions i've found online.

or could we think of any other solution?

[Lanchon]

ok... because i got no reply and https://dustbuilder.dontvacuum.me/_s5e.html did not update for a while, i went ahead and flashed stock ver 1530, 09/2021. what could go wrong? all previous updates were harmless.

now dustbuilder has been updated with "S5 Max (ver 1530, 09/2021, stripped-Ubuntu) testing, might impact rooting" and i fear i may have rendered my robot unrootable... crap!!

can you point to the source of this info? thank you.

[Handy-E]

first let me thank you and all the people behind

I fully agree with that. Thank you, all! You do great work!

now dustbuilder has been updated with "S5 Max (ver 1530, 09/2021, stripped-Ubuntu) testing, might impact rooting" and i fear i may have rendered my robot unrootable.

That is absolutely not a criticism, but I also want to know, what that means?

might impact rooting

When? Only when rooting from unpatched original firmware or when 'updating' an already rooted one?
I would also like a bit more info on that one. I do not want to create and own a telegram account (for security reasons) to get info what can go wrong here.
So I please to add a little bit more details for the ones of us standing offside and just 'using' your great work.

Thanks so much!

[Lanchon]

after watching a presentation by @dgiese, it seems U-Boot was locked down for new vacuum models. OTA updating the bootloader in the field is risky: failure would brick the device. so it makes sense for Roborock not to risk it for ultimately no real gains. but that presentation is from august, a month before the update in question. so we still don't know...

[dgiese]

Good points. I am thinking of adding some more information to Robotinfo with comments why it is potentially problematic for rooting. Afaik, the latest Dustbuilder firmware for the s5max is safe if you install it on a rooted firmware. You need to assume that all firmwares released after August 2021 are likely blocking something. So far we mostly see locked U-Boot bootloaders on new devices (like the S7). However, in our manual update process, we do not touch the u-Boot, so hopefully it should be fine. Still, I would recommend to create backups of the default and misc partition (just to be safe and in case your NAND flash dies). To answer your question: it should be OK to update on 1530. We just try to be super safe when a new version comes out, thats why the warning is there.

[Lanchon]

thank you @dgiese! i don't think you understood my situation. quoting myself:

i didn't actually root it. knowing i have the freedom to do it at any time i see fit has been enough for me. contrary to all my phones (which are de-googled and use free software OSes), i didn't feel the need to hack the S5 max before first usage.

the problem is, every couple of months i get a firmware update. and at any time, roborock could make my robot unrootable with an update.

so i applied the stock 1530 update using the stock app! i would expect updates not to touch u-boot as much as possible, as it negates the A/B safety design. or is u-boot also A/B'd?

now i know that all is not lost, since the S7 hack could be adapted to the S5 max if needed.

in any case, if you get to know either way whether the stock update touches u-boot, please let me know.

thanks again!

[dgiese]

Ok, sorry for the confusion. So traditionally Robrock does not update the U-Boot on old devices... but that does not mean that they could not do it. Dreame, for example, does deliver an updated U-Boot in their latest firmwares. While that breaks the A/B concept (as there is only one copy for Roborock and Dreame), they apparently feel confident in doing so. For some devices in particular, they do not use "real" A/B. Roborock U-Boot always will write B onto A in case of a failure or factory reset. Dreame does not even have any mechanism to switch between A and B outside of the OS (which bricked lots of devices due to bad OTA).

So while I would assume that you are currently safe, I cannot guarantee that this will not change in the future. Currently we run into Problems with S7 which have all patched U-Boots. But from the past, I would assume that you should be fine with the S5 Max as lockdowns most of the time come for new devices/models.

As a sidenote: while i try to check every new firmware update before it goes into the Dustbuilder, there is still the chance that something slips thru...especially as there are so many different models out there. There is also a delay between a new firmware coming out and me taking a look at it.

[Lanchon]

in your presentation, you make it seem like roborock invested a lot of effort into securing the cam devices. actually, all those features (hardware-rooted chain of trust, signed kernel, dm-verity partitions, encrypted partitions, SELinux, etc) come standard when building AOSP android. for the SoCs used, it was probably easier to just start with CAF android than plain linux.

you seem to be in contact with the roborock people. maybe you could tell them that, although security is important for regular customers, hackeability is important for others. especially when using android, where the problem is already solved for them, they could provide a way to unlock the bootloader and a bootloader-originated user-level feedback when unlocked. this way, buyers would know if their devices are tampered.

for instance, when a device is unlocked the power button could fail to power on the device unless some button is clicked 5 times in quick succession.

the devices could be unlocked easily via fastboot or even via a specific simple H/W mod. opening the device is a significant deterrent for many, and the mod (cutting a trace, for instance) could be tamper evidence to deny warranty, in case they are worried about hardware mistreated by inferior software (not that i back the concept of denying warranty in exchange for unlocking).

they may think that they loose few customers by not unlocking, but providing unlock is cheap for them in terms of development, much cheaper than patching security to keep up with hacks.

in fact, they could make money by providing an unlock: as seen with other hardware (think PS3 history) letting hackers play with hardware greatly diminishes the attacks on that hardware, while closing it down does otherwise. as it stands, the cheaper crippled versions limited to china can be hacked and freed. but if the global version was easily unlockable, while the crippled version was not, chances of the crippled version being freed would diminish drastically. because clients interested in software freedom (mostly hackers) would buy the unlockable version and profit rather than spending countless hours hacking into it. we all like to save some money if the opportunity falls on our laps, but we don't hack to save money, we hack for freedom. providing an unlockable version would be an excellent way to increase the unhacked life expectancy of the crippled version, which results in money for them.

if you ever talk to these consumer-oriented companies, try to let them know that providing freedom is the best way to safeguard their systems and business models from hackers.

[dgiese]

In the past, I had some discussions with Roborock. I visited them in 2018 and stressed on the fact that there are many people that like to have their smart devices without a cloud. I feel, that this aspect is hard to understand for manufacturers, especially in China.

While having a "custom" mode would be great, there is also the issue that the amount of people that want to have rooted devices is very small in comparison to the whole customer base. Its kinda similar to Smartphones where most people use the stock ROM. After having rooted so many devices, I assume that the security measurements are not only there to prevent rooting, but also to protect "IP" from other Chinese manufacturers. This also leads to kinda questionable behaviour in regard to GPL and mandatory publications of open-source components.

Implementing security on a device like a vacuum robot is way harder than on a smartphone. There are big challenges due to the autonomous nature of such a device (auto-unlocking of crypto keys, booting, etc). I kinda feel sad that Dreame and Roborock are wasting so much time on trying to do that. So far, I was able to root all robots, no matter what security features were implemented. Most of the measures are kinda useless. For example, Roborock tried to protect the firmware update encryption keys inside of OP-TEE/Trustzone... still I was able to pull them out and can now decrypt firmwares by using a simple php script ;)

"if you ever talk to these consumer-oriented companies, try to let them know that providing freedom is the best way to safeguard their systems and business models from hackers."
lets be realistic: most rooting methods require some kind of physical interaction. They are not hacks in my definition. I am always amazed by people who get CVE's for getting root access via UART or some hardware probing. In the end, it appears that the vendors do not care about the niche of privacy-oriented users, as there are enough people that buy the devices anyway.

[Lanchon]

i finally had time to root, thankfully the bootloader hasn't been updated: #323

i left cables (20cm protoboard-style jumpers cut on one side) tucked below the lidar unit which is easily removed. there is plenty of space under there and space to spare to route the wires. (there is virtually no space outside the usb port under the cover in comparison.)

thanks!