upvote
My favorite firmware update story is a time when I had to reflash firmware on an old IBM Fibre Channel/SCSI gateway because it had become corrupted and wouldn't boot.

Fortunately the first stage bootloader (which may have been in ROM) was intact, and had debugging commands that allowed reading and writing bytes of memory one at a time, and to jump to a specific memory address.

After using IDA to find the compressed firmware in the update blob and figure out how the update process worked, I was then able to use an expect script to use bootloader commands to slowly poke the firmware and the code that decompressed and copied the updated firmware to flash (extracted from the firmware itself after decompressing it with zlib) into RAM a byte at a time, then to jump to the uploaded code to finish the installation.

Worked like a charm, and enabled me to continue using the device for several years until I no longer had a use for it.

reply
I think my favorite is wifi access points that support tftp to load a firmware image (with some kind of hardware switch to enable this state). These can be made effective unbrickable and it's really nice for experimenting.
reply
> Let me FTP or SCP or SFTP a blob there, do a checksum or something for security reasons

Whose security are we talking about here? Mine, or the manufacturer's?

reply
I'm not sure if it was what OP meant, but it's arguably a good availability technique (as long as you can generate the checksum, that is). Like, if I want to run custom firmware and flash it, having a checksum which verifies that the firmware isn't corrupted may help prevent bricking.
reply
Right, I'm not sure either. Hence the question. :)

Checksums are great for helping to validate data integrity. And data integrity can be related to security.

But over the last 25 years or so, I've grown to become pretty averse to phrasing that parse like "for security purposes".

reply