Device Bricking Recovery
Comments focus on software drivers and firmware updates bricking devices, particularly counterfeit hardware, debating the intentionality, reversibility via reflashing or hardware methods, and designs for unbrickability like write protection or recovery partitions.
Activity Over Time
Top Contributors
Keywords
Sample Comments
No equipment was destroyed by the old driver: the old driver set a word in the firmware of counterfeit devices to zero. All that needs to happen to reverse what some comment-writers are calling "bricking" is to set the word back to its original value. The new version of the driver could probably do that.
it's used for stuff like trusted firmware, and easily leads to devices being bricked
The fuses aren't being protected from modifications by the firmware, but they are physically burnt - no way to reverse that.
and that seems to be kindof a problem? in so far as possible, hardware should attempt to be unbrickable
Why can't they just pull the flash memory and work on it directly?
A physical jumper or switch to enable/disable writing to the firmware flash could end a lot of these kinds of problems.
Doesn't the protection usually work such that it prevents reading the firmware but still allows you to erase and reflash it?
The bricking was absolutely intentional. The new driver overwrote the fake chip' PID. You can undo it, but it's a pain to do on Windows.
perhaps that's how vulnerable devices were bricked?
People are usually careless when it comes about the real deal.Hardware companies like Asus could also provide a hard switch to reset efi and drivers to default in similar scenarios, they can simply hardcode a read-only small memory with high compression.Hence there are projects like libreboot and coreboot.