4 ms·
> system identity information and calibration data that only Apple can put back properly Ha. This reminds me of a Motorola Linux phone I bricked as a kid by tr
by floatboth 5y ago
> system identity information and calibration data that only Apple can put back properly
Ha. This reminds me of a Motorola Linux phone I bricked as a kid by trying to write a package manager in C shell (lol) which inevitably led to rm -rf / being executed which wiped a unique per-device security partition required for the boot process.
Why did Apple make the same choice of putting critical data onto an OS-writable flash chip? Chromebooks do it right – everything critical lives in the Security Chip's own on-chip flash, and the list of commands it would take from the host system is very limited by default (most things are only available to the debug cable).
- my123 5y agoIt's an SPI flash that isn't mapped to /dev. As far as I know, fully wiping it is recoverable, but involves putting the Mac into device firmware update mode, and then recovering from another machine.
- marcan_42 5y agoAIUI if you actually wipe NOR flash entirely, DFU mode won't save you, because the Mac won't even know who it is (MAC addresses, serial number, etc.). However, I can't claim to have tried it, so there may well be additional safeguards. I'm just not particularly interested in risking it for our users either way :)
- spacedcowboy 5y agoYou might be able to restore the NOR with 'Apple Configurator 2', which seems to be a public version of an internal tool, though it's limited to taking an otherwise unbootable machine to a fully-installed-OS machine. Plug the bricked machine into another Mac using a TB3 cable in a particular slot (they tell you which) and follow the instructions. Worked for me.