It’s frustrating that this isn’t completely typical. As the writeup pointed out, this “exploit” can only be performed by the device owner anyway, so nobody is harmed by the unlockability. But 95% of devices that are sold, besides non-Mac PCs, and SBCs, are locked down completely, prohibiting anyone from using the device as they like.
I can't help imagining someone trying to debug this rigging their laptop to their bicycle handlebars, connecting to the ride computer and then going for a ride to get live data for the debug session.
It would be very hard not to die in a traffic accident while debugging in this way.
I mainly object to AI writing when it’s excessively verbose. This was pretty information dense, a few AI-isms didn’t make it a waste of my time to read.
There seems to be a debugging pattern that arises when problems are in proximity to a poorly understood, highly complex part of the system: We tend to think that's where the problem probably is. And we can lose an inordinate amount of time looking for it there. It's like an inverse streetlight effect.
I've seen coding LLMs do it too. I have a well-tested, but complex, subsystem that constantly draws their attention when something non-obvious elsewhere goes wrong.
It’s frustrating that this isn’t completely typical. As the writeup pointed out, this “exploit” can only be performed by the device owner anyway, so nobody is harmed by the unlockability. But 95% of devices that are sold, besides non-Mac PCs, and SBCs, are locked down completely, prohibiting anyone from using the device as they like.
I can't help imagining someone trying to debug this rigging their laptop to their bicycle handlebars, connecting to the ride computer and then going for a ride to get live data for the debug session.
It would be very hard not to die in a traffic accident while debugging in this way.
Welcome to hell, developer!
I found this really hard to read due to the Claude-isms. "Classic" chicken and egg problem? 39 em-dashes, random numbered lists, etc.
If you're not going to even bother to take the time to write an article, why should I waste my time reading it?
I mainly object to AI writing when it’s excessively verbose. This was pretty information dense, a few AI-isms didn’t make it a waste of my time to read.
I read it and found it useful
\_(^ ^)_/
There seems to be a debugging pattern that arises when problems are in proximity to a poorly understood, highly complex part of the system: We tend to think that's where the problem probably is. And we can lose an inordinate amount of time looking for it there. It's like an inverse streetlight effect.
I've seen coding LLMs do it too. I have a well-tested, but complex, subsystem that constantly draws their attention when something non-obvious elsewhere goes wrong.
I love reading these kinds of stories!
Title is: How a Broken Bike Sync Led Me to Reverse Engineering My Wahoo's Hidden Debug Mode
Yes, less fun, sorry for the lack of 1:1 match
That's pretty interesting; I've always wondered about the internals of those things, as I stared at mine while pedaling up some steep grade.
I'm also curious about what the electronic derailleurs and shifters run.
Love the punchline