It sounds like the re-flashing was an important step in fixing it, and that just unblocking the IP would not have fixed it if the bricking command had been sent. After all, this was happening sufficiently early in startup that the device appeared to not turn on (rather than boot loop, or turn off after connecting).
I think, charitably, what might have happened here is:
1. Author left out the diagnostic step that restoring the connectivity didn't fix the robot, because it didn't work.
2. Author did the technical analysis mentioned (there is a repository attached. I haven't verified that it actually has the level of technical analysis indicated).
3. Author took some creative liberties (possibly involving some AI-assisted punching-up) when writing the blog post story to make it more compelling in a way that made it feel a bit off and left me and others questioning its veracity.
Yeah I agree this seems most likely. I get the impression the author is not a frequent writer, so "hey LLM turn this draft into a blog post" seems the most likely scenario.
Skimming the post and skipping past the fluff, I thought it was an interesting situation and bit of debugging.
Well, the device _did_ turn on, at least enough that author could adb into, SSH into it, examine files, read the logs.
The post really makes it unclear how permanent the disablement was, or how exactly "one script had been modified to prevent the main application from launching". Would really love to see some details here. Could author undo that change? Did they try to?
