4 ms·

For comparison, note that you can't do low level recovery at all on e.g. Google Pixel phones. Lose the contents of your storage there and the phone is bricked,

For comparison, note that you can't do low level recovery at all on e.g. Google Pixel phones. Lose the contents of your storage there and the phone is bricked, as Google does not provide the low level flashing tools and signed images to do that. Apple does, with the phone home caveat. On x86 PCs, you can usually download a BIOS image, but to flash it you need hardware tools on most computers. So it's better in that you don't need to phone home, and worse in that you need specialized tools to do it. You might also lose serial numbers and other personalization information. Note: "Factory" images aren't this (and that's a misnomer, they aren't what is used at the factory). Those are OS images. To flash them your bootloader needs to be intact. We're talking about recovering from complete loss of writable storage here - that requires OEM tools to boot low level recovery images from the boot ROM alone. Some of these have leaked, but for very few devices. Apple just gives all of this to you on macOS and we have an open source reimplementation of their DFU tooling (idevicerestore) that you can run on any OS to restore any M1 Mac or iDevice to any (signable) OS version. To this day, all non-beta macOS for M1 releases are signable; I imagine they'll only revoke old ones if a major security flaw is found that impacts device backdoorability or allows SEP compromise or so, and even then you could still install an older OS in reduced security mode, just not as the first OS installed during low level recovery.

duskwuff 5y ago
> On x86 PCs, you can usually download a BIOS image, but to flash it you need hardware tools on most computers. Even then, it isn't always obvious how to write that image to flash. Sometimes you get lucky and the downloadable BIOS is a full image of the serial flash chip, but sometimes it's a delta update, or the flash chip contains other data (like configuration) which isn't part of the public image. And even then, there's a ton of other updatable firmware in a typical PC that isn't part of a BIOS update -- most video adapters and network devices will have at least a small flash chip on board, which may not be repairable at all if it's damaged.
- marcan_42 5y ago
  Yup. On M1s Apple tries to make all external chips either use runtime loaded firmware or be bootloadable, both for security and recoverability reasons. I don't know if it's possible to truly brick an M1, but if it is you have to try really hard.
- floatboth 5y ago
  GPUs are often the easiest to recover actually – boot with another GPU, keeping the screwed-up one plugged in – it will still be flashable, just run atiflash or whatever. Also, high end "gamer" hardware often includes "dual BIOS" (on both mainboards and graphics cards) and/or "BIOS flashback" (special button makes a microcontroller flash an image from a USB stick inserted into a marked port, even without a CPU present).
est31 5y ago
Google Pixel phones are phones though, and not personal computer devices like M1 Macs are. Phones have traditionally been more locked down. A fairer comparison would be to Chromebooks, which do have a screw to let you flash a different BIOS.
- floatboth 5y ago
  The screw meme just doesn't die… Modern Chromebooks use a debug USB-C cable for flashing and serial console access, and a "sit around for like 15 minutes pressing power button when told" process to prove ownership to unlock dev mode.
  - est31 5y ago
    Thanks for that information. I am not very involved in chromebook development, so I didn't know that. Do you have a link to documentation that outlines the current steps?
- marcan_42 5y ago
  Chromebooks have a different threat model; they give up once an attacker has physical access. M1s do not; their security model covers the case of preventing an attacker from installing a backdoor on a machine using physical access. That's why Chromebooks have the screw; once you have the machine in front of you, sure, go ahead and install your own firmware. They can afford that in their threat model. We in security like to throw around that "once the attacker has physical access it's game over", but that isn't true in practice, as evidenced by the success of locked platforms like iPhones. You can be secure against physical access, at least assuming your attacker can't decapsulate your CPU, rewire it with a FIB workstation, and recapsulate it. Apple's security model aims for this, while still allowing the user to install their own OS.
  - AnthonyMouse 5y ago
    > We in security like to throw around that "once the attacker has physical access it's game over", but that isn't true in practice, as evidenced by the success of locked platforms like iPhones. People find iPhone jailbreaks all the time. Apple patches them, but if you want a jailbroken iPhone, they exist. Moreover, the vulnerabilities they keep finding were there before they find them, and the ones they'll find tomorrow are there right now, if you have the resources to look. And this is distinct from the level of resources (generally considered impractical for anyone) for other forms of computer security, e.g. AES replaced 3DES in 2001 but still to my knowledge nobody -- not even the NSA or other state actors -- has ever even broken 3DES. If you ask whether a large corporation could break into an iPhone today given physical access, the answer is going to be yes. And without decapsulating your CPU. The physical vulnerabilities often end up being related to USB and things like that. Remember the whole farce where the FBI wanted to get into some iPhone and "couldn't" because Apple refused to help them? Then they just paid somebody to break into it. > You can be secure against physical access, at least assuming your attacker can't decapsulate your CPU, rewire it with a FIB workstation, and recapsulate it Or steal your phone and leave you with an identical looking one that transmits your authentication to the real one as soon as you try to unlock it. And that's really the physical access problem. If you have a device with full disk encryption and have cleared the keys from memory, the attacker might not be able to get the contents even with physical access. But if they've had physical access and then return the device to you, can you still trust it? Nope.

duskwuff 5y ago

> On x86 PCs, you can usually download a BIOS image, but to flash it you need hardware tools on most computers. Even then, it isn't always obvious how to write that image to flash. Sometimes you get lucky and the downloadable BIOS is a full image of the serial flash chip, but sometimes it's a delta update, or the flash chip contains other data (like configuration) which isn't part of the public image. And even then, there's a ton of other updatable firmware in a typical PC that isn't part of a BIOS update -- most video adapters and network devices will have at least a small flash chip on board, which may not be repairable at all if it's damaged.

marcan_42 5y ago
Yup. On M1s Apple tries to make all external chips either use runtime loaded firmware or be bootloadable, both for security and recoverability reasons. I don't know if it's possible to truly brick an M1, but if it is you have to try really hard.
floatboth 5y ago
GPUs are often the easiest to recover actually – boot with another GPU, keeping the screwed-up one plugged in – it will still be flashable, just run atiflash or whatever. Also, high end "gamer" hardware often includes "dual BIOS" (on both mainboards and graphics cards) and/or "BIOS flashback" (special button makes a microcontroller flash an image from a USB stick inserted into a marked port, even without a CPU present).

est31 5y ago

Google Pixel phones are phones though, and not personal computer devices like M1 Macs are. Phones have traditionally been more locked down. A fairer comparison would be to Chromebooks, which do have a screw to let you flash a different BIOS.

floatboth 5y ago
The screw meme just doesn't die… Modern Chromebooks use a debug USB-C cable for flashing and serial console access, and a "sit around for like 15 minutes pressing power button when told" process to prove ownership to unlock dev mode.
- est31 5y ago
  Thanks for that information. I am not very involved in chromebook development, so I didn't know that. Do you have a link to documentation that outlines the current steps?
marcan_42 5y ago
Chromebooks have a different threat model; they give up once an attacker has physical access. M1s do not; their security model covers the case of preventing an attacker from installing a backdoor on a machine using physical access. That's why Chromebooks have the screw; once you have the machine in front of you, sure, go ahead and install your own firmware. They can afford that in their threat model. We in security like to throw around that "once the attacker has physical access it's game over", but that isn't true in practice, as evidenced by the success of locked platforms like iPhones. You can be secure against physical access, at least assuming your attacker can't decapsulate your CPU, rewire it with a FIB workstation, and recapsulate it. Apple's security model aims for this, while still allowing the user to install their own OS.
- AnthonyMouse 5y ago
  > We in security like to throw around that "once the attacker has physical access it's game over", but that isn't true in practice, as evidenced by the success of locked platforms like iPhones. People find iPhone jailbreaks all the time. Apple patches them, but if you want a jailbroken iPhone, they exist. Moreover, the vulnerabilities they keep finding were there before they find them, and the ones they'll find tomorrow are there right now, if you have the resources to look. And this is distinct from the level of resources (generally considered impractical for anyone) for other forms of computer security, e.g. AES replaced 3DES in 2001 but still to my knowledge nobody -- not even the NSA or other state actors -- has ever even broken 3DES. If you ask whether a large corporation could break into an iPhone today given physical access, the answer is going to be yes. And without decapsulating your CPU. The physical vulnerabilities often end up being related to USB and things like that. Remember the whole farce where the FBI wanted to get into some iPhone and "couldn't" because Apple refused to help them? Then they just paid somebody to break into it. > You can be secure against physical access, at least assuming your attacker can't decapsulate your CPU, rewire it with a FIB workstation, and recapsulate it Or steal your phone and leave you with an identical looking one that transmits your authentication to the real one as soon as you try to unlock it. And that's really the physical access problem. If you have a device with full disk encryption and have cleared the keys from memory, the attacker might not be able to get the contents even with physical access. But if they've had physical access and then return the device to you, can you still trust it? Nope.