I don’t specifically know the types of things that you’d want to share across apps, but there’s a long history of cross process information channels being removed or restricted.
If the system is storing values for you, and isn’t keeping track of which app they came from, now you’ve got persistent storage across app deletion & re-install, as long as there isn’t a reboot in between.
I think you could easily use it to work around IDFA or IDFV resets, as a simple example.
The design is old. It probably predates facebook, so it's not been intentional, as your comment might be interpreted. But it certainly seems ripe for abuse. I'm curious if it would actually be used for that, because any app that can access internet already has a better way to share information.
Though iOS definitely predates 3rd party apps and the ad based economy. Which is a bit of a tautology.
I think the approach you describe allows roughly the same, except perhaps doing so without (or with different) permissions, and allowing to do this between vendors (that must agree upon this upfront).
DFU mode boots entirely from read-only ROM, and from there, you can just restore everything via USB cable.
Same applies to Apple Silicon Macs. You can damage the system, recovery and emergency recovery volumes, but even then, you can still boot into DFU from ROM and re-initialize everything via another Mac.
This is in contrast to some PCs, where if you damage the BIOS (e.g. by suddenly losing power during a firmware update), your device may or may not be bricked. There have even been stories of peoples' computers being bricked via rm -rf /, due to removing everything at /sys/firmware/efi/efivars/ (which is actually stored inside the motherboard), and sometimes contains things that the motherboard won't boot without
There definitely are (If you count jailbroken iPhones). I've managed to brick one by removing all thermal throttling limits and subsequently damaging the motherboard with the world's shittiest watercooling setup.
Can't use DFU to restore if you've got damaged hardware
no amount of monkeying around with the software will brick the iphone (botched updates, etc.). Once we get to hardware failures the vectors are innumerable. Lightning strikes. Device drops from height. Botched water cooling. Magnifying glass lasers. Children's vomit...
I would expect that most systems should be recoverable from this state with a CMOS clear.
> This is in contrast to some PCs, where if you damage the BIOS (e.g. by suddenly losing power during a firmware update), your device may or may not be bricked.
I accidentally destroyed the firmware on a machine that did not have any recovery features, when flashing modified UEFI images, leaving it mostly inoperable. I wound up recovering it using flashrom and a Raspberry Pi. I think this counts as a hard brick, but the modular nature of PCs (e.g. most BIOS chips are on sockets so you can pull them out easily) it's not nearly as big of an issue if you hard-bricked a device that's more integrated and locked down. It's not instant e-waste because no bricks are permanent.
(It's a little harder for laptops, but I did also flashrom a laptop in a similar fashion, in-circuit using a SOIC8 clamp. This was not a brick recovery but rather messing with coreboot.)
Definitely not as much for the faint of heart, but a repair technician could do it for you. Alternatively, for PCs with socketed BIOS, you can buy a new EEPROM that's already flashed with the right firmware--they were readily available on eBay last I looked.
That was probably a decade ago or more by now. Many modern PC motherboards from many vendors have mitigations for this; it was a common enough pain point after all. For example, my desktop PC has an embedded controller that can boot and rewrite the flash chip for you, using a copy of BIOS from a USB stick. (Works even if the CPU isn't installed. Pretty cool.)
> There have even been stories of peoples' computers being bricked via rm -rf /, due to removing everything at /sys/firmware/efi/efivars/ (which is actually stored inside the motherboard), and sometimes contains things that the motherboard won't boot without
EFI vars are stored in NVRAM, not the EEPROM. You can usually clear that a couple of ways:
- Use an integrated NVRAM reset system. Some machines have a way to do this listed in their manual. On desktop PC motherboards, it tends to be a jumper you set for a few seconds. Sometimes you will have an easier option, like a button somewhere, or even possibly a key combination at boot (Long time Macintosh fans probably have memorized the NVRAM reset key chord for Apple computers... I wonder if it still works on Apple Silicon.)
- Remove the battery for a few seconds. Usually easily accessible on a desktop. Usually a little less easy to get to on a laptop, but nothing absurd, usually just some screws.
Certainly it could be easier to recover from, I'd say it's actually not very easy to brick a typical desktop PC in a particularly permanent fashion. The only time I've ever done it was because I was modifying my UEFI image intentionally. Screwing up EFI vars doesn't make most systems unbootable. I have corrupted my EFI vars quite a few times trying to do funny things. UEFI implementations do tend to be buggy, but not all of them are that catastrophically bad.
--
Now... as for whether or not an Apple Silicon device can "physically" be bricked by software, the most obvious way to do that would be to wear the SSD down to the point where it can no longer be rewritten. I think the M4 Mac Mini finally no longer solders these and that the Mac Minis do have a way you can recover from this brick (using another Mac to restore to a new SSD) but there are many Macs where if the SSD is destroyed, it's pretty hard to fix since you need Apple tools that are hard to obtain if you want to pair a new SSD. This is unfortunate because Apple has often had dodgy hardware choices around the SSD (e.g. the notorious TPS62180 buck converter) and doesn't always use SSDs that have the best reliability (IIRC they use a lot of Kioxia in the newer Apple Silicon devices, which are not considered to be bad devices by any means, but are generally considered less durable than e.g. Samsung SSDs.)
Rather than have an Apple device become ewaste due to software issues, in recent years, it is much more likely that it will become ewaste due to hardware issues, as a result of parts pairing and having failure-prone components that are not modular even when they really can and should be (Good on them for rectifying this lately, e.g., with the Mac Mini SSD, but it's a bit sad that it took this long. And on the note of that SSD... Apple, you really could've used a standard electrical interface for that.)
This is somewhat a testament to Apple's software and system design, but it's simultaneously a condemnation of their recent track record with repair, too. Best we can hope is that they don't go backwards from this point forward, because they created a lot of devices that will become ewaste over time for almost no gain for anyone. (I strongly dislike but can understand the justification for something like parts pairing in iPhones and iPads, but much less so for similar sorts of mechanisms in computers.)
Apple not supporting their hardware after a short time is a software issue causing e-waste. I have a big box full of non-viable Apple hardware that is working perfectly well, Apple just decided to stop supporting all those devices - a bunch of tablets, a couple apple tvs, an old apple watch, several laptops, etc.
Sure, other manufacturers do this too, but none as badly as Apple does IMHO.
"Soft brick" is the correct term that already exists.
So maybe the term shouldn't be 'soft brick' but rather 'muddied'.
"That updated muddied my device, I had to clean it up with a restore"
> The result is a device that’s soft-bricked, requiring a device erase and restore from backup.
Requiring a device erase isn't a full brick, no, but it's still pretty serious.
> After restarting, as soon as SpringBoard was initialized, the extension would be woken up by the system, since it had failed to produce any widget entries before, which would then start the process all over again.
He totally murdered that guy!
What? Why would you say murdered, he only gave him a black eye?
I know, but that's still pretty serious.
Brick means entirely useless except as a doorstop, projectile, or building material.
http://www.catb.org/jargon/html/B/boat-anchor.html
1. Like doorstop but more severe; implies that the offending hardware is irreversibly dead or useless. “That was a working motherboard once. One lightning strike later, instant boat anchor!”
I contend that brick is a neologism based on this boat-anchor analogy. A brick is rather small, handheld, portable. No computer component was this way when the "boat-anchor" term was coined.
Indeed, many of my colleagues in the 90s based their trust and confidence in hardware on its volume and mass. If we could lift it, or throw it across the room, it was not worthy of respect. Those were the days of magnificent racks loaded with equipment that did comparatively very little!
https://web.archive.org/web/19981206105844/http://www.sophis...
Everything was plaintext, including “authentication”, which was (at best) just asking the “ident server” on the same machine as your client who you claimed to be, which was considered sufficient because, after all, to run identd on its “privileged” low port meant you were an “administrator” (i.e. root of a unix machine).
I was behind NAT when I first got on IRC in ‘98. I set it up with ipfwadm.
I joined IRC in the early 90s, there was no NAT then, packet filtering was uncommon, and practically nothing on the Internet was encrypted. It was a very different time.
https://en.wikipedia.org/wiki/Time_Independent_Escape_Sequen...
DCC SEND whatever 0 0 0
This caused the DCC ALG helper in ancient Linux kernels to close the connection, as they failed to parse 0 as a valid IP address. Users connecting to IRC servers over TLS were immune, as the ALG helper in the router could not observe the traffic.
This is what breaks DCC in general -- to use DCC on IRC while connecting to the server over TLS and behind a NAT, you must instruct your client to use a specific range of ports for DCC and preforward those ports to your machine in your router, as the ALG helper cannot mark the incoming connection as RELATED (and forward it through to you) as it cannot see the outgoing command that caused the incoming connection to occur. You must also instruct your client to determine the correct external IP address to advertise, as the ALG helper will be unable to rewrite it when the router does masquerading.
My memory is a bit hazy and I don't want to look up the exact sequence, but that's close enough.
Like, "hey we need a way to trigger springboard UI events.." "ok let's just use this unauthenticated bus and have springboard subscribe to it"
Something like that? Only thing I can think of is that this line of code was written so long ago and it's way at the bottom of the abstraction stack, so no one had a look
It seems like such an obvious security concern. Maybe it was pre-AppStore? And more assumed trust in other apps?
> That single line of code was enough to make the device enter “Restore in Progress”.
> as established before, any process could send the notification and trick the system into entering that mode.
In practice this is not a big problem because usually one grants very few users direct access to a PG DB.
This should probably be reworked regardless if the patch described in the article was implemented.