Hacker News Reader

Comment by flyinglizard | Hacker News Reader

Why on earth didn’t Bird lock down the STM32 through builtin hardware fuses, thus disabling the debug interface? Is that a consequence of moving fast and breaking things?

View on HN

Because you must really be confident in your firmware before you start disabling debug interfaces. Most people aren't. They see more value in being able to fix their bugs after the fact than locking out potential hackers.

Imagine just receiving a batch of 1000 scooters with a botched firmware, which you must write off now because you can't reprogram them due to the disabled SWD. This happens more often than you might imagine.

I dunno, how expensive are these units? And how does that compare to the labor and time expense of hooking them up to be reprogrammed, vs the risk of theft / hacking?

I'm genuinely curious btw, Bird and co have a huge scale challenge on their hands, thousands of units all over the place.

They could at least have locked down the flash and RAM, triggering a flash mass erase when attempting to dump the firmware/RAM contents. Not that this would be 100% secure either, but with these STM32 HW features in place this is already significantly more difficult.

I don’t see how making it harder to dump the firmware makes the platform any more secure. Determined attackers will get in anyways and you’ll lose out on people who are interested in poking around.

It's usually done to prevent cheap chinese clones of your boards, not so much for security.

You can still provide a write-only bootloader interface (over UART or whatever) to allow for firmware updates.

Probably because the business risk is minimal, it's not likely to impact their bottom line so it doesn't have to be Fort Knox

I think they just buy a conversion kit from a Chinese OEM

Reply on news.ycombinator.com