Preparing Macbook for Trade-In
August 22, 2020 12:29 PM Subscribe
My Macbook Pro (2017) has been one disaster after another, first a wonky keyboard (thank you Apple for the butterfly keyboard from hell), and then the display zonked out. And I am just so totally done and ready to send it back. But today, when I went to erase the hard drive, after a ton of troubleshooting, it just won't boot into recovery mode (using an external monitor to do that).
I know technically speaking it is not necessary to wipe the drive before trading in, but I am not super thrilled about sending it in without doing that.
What can I do, short of erasing the drive, to remove my personal data?
Usually what I do in a similar situation is create a second kinda-blank admin account. Log in to that account, delete the second account, make sure I am securely erasing or overwriting the free space. Then from the kinda-blank account (which I don't use to do ANYTHING) I delete apps and figure that's really most of everything.
posted by jessamyn at 1:05 PM on August 22, 2020 [1 favorite]
posted by jessamyn at 1:05 PM on August 22, 2020 [1 favorite]
Response by poster: When you say it won't boot into recovery mode, what is happening when you try? And you're holding down command-R until you see the apple logo?
I end up with a blank screen (no apple logo). I've also tried booting into Internet Recovery mode, and same thing, a blank screen.
posted by nanook at 1:26 PM on August 22, 2020
I end up with a blank screen (no apple logo). I've also tried booting into Internet Recovery mode, and same thing, a blank screen.
posted by nanook at 1:26 PM on August 22, 2020
Have you tried zapping the PRAM (hold down command, option, P, R during restart until the home sounds a second time) and then trying to go into recovery mode?
posted by jonathanhughes at 1:37 PM on August 22, 2020 [2 favorites]
posted by jonathanhughes at 1:37 PM on August 22, 2020 [2 favorites]
Response by poster: Yes, tried zapping the PRAM, still a gray screen.
posted by nanook at 1:56 PM on August 22, 2020 [1 favorite]
posted by nanook at 1:56 PM on August 22, 2020 [1 favorite]
Also, are you able to start in target disk mode and then mount the drive on another mac?
posted by nothing.especially.clever at 1:59 PM on August 22, 2020 [2 favorites]
posted by nothing.especially.clever at 1:59 PM on August 22, 2020 [2 favorites]
Are you sure the machine is turning on? My MBA had something annoying like that and turns out it was the logic board which had spontaneously decided to fry itself. You might not be able to trade it in in that condition.
posted by Alensin at 1:59 PM on August 22, 2020
posted by Alensin at 1:59 PM on August 22, 2020
Response by poster: It turns on just fine, I am able to work on it with an external monitor. All the software seems just fine, too.
posted by nanook at 2:03 PM on August 22, 2020
posted by nanook at 2:03 PM on August 22, 2020
Response by poster: Also, are you able to start in target disk mode and then mount the drive on another mac?
That could be an option, I don't have a thunderbolt to thunderbolt cable on hand at the moment, though.
posted by nanook at 2:10 PM on August 22, 2020
That could be an option, I don't have a thunderbolt to thunderbolt cable on hand at the moment, though.
posted by nanook at 2:10 PM on August 22, 2020
And SMC?
https://support.apple.com/en-us/HT201295
posted by nothing.especially.clever at 2:16 PM on August 22, 2020
https://support.apple.com/en-us/HT201295
posted by nothing.especially.clever at 2:16 PM on August 22, 2020
Do you have a spare thumb drive? Is it 8GB or larger?
Re-download the installer and use the createinstallmedia command to create another recovery system which runs from the thumb drive and can wipe your device entirely.
posted by k3ninho at 2:28 PM on August 22, 2020 [1 favorite]
Re-download the installer and use the createinstallmedia command to create another recovery system which runs from the thumb drive and can wipe your device entirely.
posted by k3ninho at 2:28 PM on August 22, 2020 [1 favorite]
If I'm understanding you correctly, you can use the system normally but can't boot into Recovery mode.
If that's the case, you could just turn on FileVault with a long randomly generated password, let the system run for long enough to finish encrypting the disk, then remove the machine from your Apple account and forget the FileVault password.
posted by flabdablet at 2:45 PM on August 22, 2020 [5 favorites]
If that's the case, you could just turn on FileVault with a long randomly generated password, let the system run for long enough to finish encrypting the disk, then remove the machine from your Apple account and forget the FileVault password.
posted by flabdablet at 2:45 PM on August 22, 2020 [5 favorites]
I am able to work on it with an external monitor
Can you start in recovery mode, connected to an external monitor? If you still get a blank screen, you might try these suggestions from Apple.
Short of that, you might get a Thunderbolt cable and try target disk mode to another Mac, in order to use Disk Utility on another Mac, with security settings to do a secure wipe.
The aforementioned FileVault approach is clever, which encrypts your hard drive. No one but you would be able to access the data, so long as you do not enable access via your Apple/iCloud account, i.e. set up a recovery key. If you were to give the computer to someone else, they would need your key to get to the data.
posted by They sucked his brains out! at 2:56 PM on August 22, 2020
Can you start in recovery mode, connected to an external monitor? If you still get a blank screen, you might try these suggestions from Apple.
Short of that, you might get a Thunderbolt cable and try target disk mode to another Mac, in order to use Disk Utility on another Mac, with security settings to do a secure wipe.
The aforementioned FileVault approach is clever, which encrypts your hard drive. No one but you would be able to access the data, so long as you do not enable access via your Apple/iCloud account, i.e. set up a recovery key. If you were to give the computer to someone else, they would need your key to get to the data.
posted by They sucked his brains out! at 2:56 PM on August 22, 2020
Quite so. Without its decryption key, a disk that's been subjected to full-disk encryption is absolutely indistinguishable from one whose every block has been overwritten with randomly generated noise.
On a solid-state drive you can't rely on the drive to remove the contents of any data block from flash storage immediately when you overwrite it, especially if what you're overwriting it with is zeroes, which is what software-based "secure erase" routines originally designed for use with spinning hard drives will frequently choose to use.
That design choice is made because zeroes are what gets written to all the blocks on a spinning a hard disk during the initial factory formatting process, so that's what the drive will give you if you read a data block that's never been written since the drive was first manufactured.
SSDs are designed to emulate this behaviour. But the design of the flash memory chips in an SSD means that they can't write arbitrary data to an arbitrary block address at any time like a disk drive can. Writing to flash memory is a two-step process: first, a large chunk of flash memory (thousands of blocks) has to be erased, and only then can some part of that chunk have new data written in. Which means that in order for a SSD to behave as if it were a disk drive, it has to do some fiddly internal bookkeeping to keep track of where it's actually put the block of data that the computer asked it to store at block address X.
If you tell a SSD to write a block of zeroes, all it might in fact do is make an internal note that the block number you just wrote those zeroes to is henceforth to be treated as empty; whichever chunk of flash storage formerly held that block's contents will then become internally available for scavenging when the drive starts to get low on free erase blocks to write new data into, but there's no guarantee at all that it will actually be erased immediately.
The drive doesn't actually need to consume a whole block's worth of flash storage to store a block of zeroes. It can simply return a block of constructed zeroes to the user when asked for any of the blocks it knows it's supposed to treat as empty. So writing zeroes to a SSD - even in whole-drive quantities - is actually fairly likely to leave large amounts of the underlying flash storage completely intact. Same goes for SSD-specific explicit block-discard operations like Trim.
So if you try to use a erase procedure designed for hard disk drives to write zeroes to every user-accessible block on a SSD, there's a fair chance that somebody capable of physically taking the thing apart and getting direct access to the contents of the flash chips might still be able to reconstruct at least some of what used to be there. And if you're unlucky, that might include some amount of personally sensitive material.
But if you overwrite every user-accessible block on your drive with randomness rather than zeroes, which from the SSD's point of view is exactly what happens while FileVault is being initially set up, then there is no way for the SSD to recognize that it doesn't actually need to store any given block of that stuff. And since there's only a relatively small amount of non-user-accessible space in an SSD, overwriting every user-accessible block on a drive with random data has a very high chance of causing the erasure of everything that used to be inside it before the overwrite started. And the longer you keep on using a system with whole-disk encryption in place, the greater becomes the likelihood that all of the internal flash storage has been erased and/or now holds nothing but randomness.
This is in part why iPhones and iPads have their well-deserved reputation for refusing to leak sensitive information after being trashed; whole-disk encryption is turned on from day 1 for those devices, and once the decryption keys are lost there is simply nothing useful to be discerned in the contents of their flash memory chips.
posted by flabdablet at 6:19 AM on August 23, 2020 [1 favorite]
On a solid-state drive you can't rely on the drive to remove the contents of any data block from flash storage immediately when you overwrite it, especially if what you're overwriting it with is zeroes, which is what software-based "secure erase" routines originally designed for use with spinning hard drives will frequently choose to use.
That design choice is made because zeroes are what gets written to all the blocks on a spinning a hard disk during the initial factory formatting process, so that's what the drive will give you if you read a data block that's never been written since the drive was first manufactured.
SSDs are designed to emulate this behaviour. But the design of the flash memory chips in an SSD means that they can't write arbitrary data to an arbitrary block address at any time like a disk drive can. Writing to flash memory is a two-step process: first, a large chunk of flash memory (thousands of blocks) has to be erased, and only then can some part of that chunk have new data written in. Which means that in order for a SSD to behave as if it were a disk drive, it has to do some fiddly internal bookkeeping to keep track of where it's actually put the block of data that the computer asked it to store at block address X.
If you tell a SSD to write a block of zeroes, all it might in fact do is make an internal note that the block number you just wrote those zeroes to is henceforth to be treated as empty; whichever chunk of flash storage formerly held that block's contents will then become internally available for scavenging when the drive starts to get low on free erase blocks to write new data into, but there's no guarantee at all that it will actually be erased immediately.
The drive doesn't actually need to consume a whole block's worth of flash storage to store a block of zeroes. It can simply return a block of constructed zeroes to the user when asked for any of the blocks it knows it's supposed to treat as empty. So writing zeroes to a SSD - even in whole-drive quantities - is actually fairly likely to leave large amounts of the underlying flash storage completely intact. Same goes for SSD-specific explicit block-discard operations like Trim.
So if you try to use a erase procedure designed for hard disk drives to write zeroes to every user-accessible block on a SSD, there's a fair chance that somebody capable of physically taking the thing apart and getting direct access to the contents of the flash chips might still be able to reconstruct at least some of what used to be there. And if you're unlucky, that might include some amount of personally sensitive material.
But if you overwrite every user-accessible block on your drive with randomness rather than zeroes, which from the SSD's point of view is exactly what happens while FileVault is being initially set up, then there is no way for the SSD to recognize that it doesn't actually need to store any given block of that stuff. And since there's only a relatively small amount of non-user-accessible space in an SSD, overwriting every user-accessible block on a drive with random data has a very high chance of causing the erasure of everything that used to be inside it before the overwrite started. And the longer you keep on using a system with whole-disk encryption in place, the greater becomes the likelihood that all of the internal flash storage has been erased and/or now holds nothing but randomness.
This is in part why iPhones and iPads have their well-deserved reputation for refusing to leak sensitive information after being trashed; whole-disk encryption is turned on from day 1 for those devices, and once the decryption keys are lost there is simply nothing useful to be discerned in the contents of their flash memory chips.
posted by flabdablet at 6:19 AM on August 23, 2020 [1 favorite]
When getting rid of a Mac, I've done what Jessamyn suggests: create a convenience account, delete my old account.
posted by adamrice at 6:22 AM on August 23, 2020
posted by adamrice at 6:22 AM on August 23, 2020
Response by poster: Thanks everyone, all good answers. I tried everything from the list, to no avail. And in the end, did as Jessamyn suggested. So happy to finally have that piece of junk on its way to some kind of well-deserved rebirth in the lower realms.
posted by nanook at 11:25 AM on August 23, 2020 [1 favorite]
posted by nanook at 11:25 AM on August 23, 2020 [1 favorite]
This thread is closed to new comments.
posted by jonathanhughes at 12:44 PM on August 22, 2020