iPhone owners say the latest iOS update is resurfacing deleted nudes
It’s probably nothing sinister, though.
cross-posted from: https://sopuli.xyz/post/12670977
iPhone owners say the latest iOS update is resurfacing deleted nudes
You're viewing a single thread.
Computer data is never actually “deleted” until it’s overwritten with new 1s and 0s — operating systems simply cut off references to it.
That's not entirely correct, and I would expect a tech news site to know but ig not.
It's true with spinny's since they store data magnetically on the platter with 1s and 0s, but SSDs store data on the NAND as a held charge. If there's a charge in the block it's a 1 if there's no charge it's a 0.
With spinny's, when a file gets marked as "deleted" the residual magnetic 1s and 0s will remain on the platter until eventually overwritten like they say
But with SSDs, when a file gets marked "deleted" then within no more than a few minutes TRIM comes along and ensures the charge on the NAND is released (Which means that data is gone, permanently) for that data, there's no residuals to worry about like with spinny's and is in fact necessary to ensure decent lifespans.
This is dependent on the TRIM schedule. It could be size based (execute a TRIM when 50% of the blocks are used).
It could be or maybe the SSD has its own on-firmware TRIM schedule, but all major OS's execute a TRIM on a time based schedule no longer than every 10-15 minutes.
Afaik the default for windows 10 is weekly via disk defragmenter, and that assumes it recognizes the drive as an ssd. I've had drives cloned to ssds that retain the hdd flag and had to setup a 3rd party tool that actually saw it properly and would trim as expected.
11 might have reigned that in... but probably not.
Perhaps, but this is unrelated. The magnetic charges may still be there, but if the reference to the content is deleted, how is the filesystem meant to know what file is there? This seems really suspicious to me.
TRIM works outside the filesystem, it does not care about 99.9% of it, the only part it cares about is if there is a reference in filesystem to the block charges. No reference == data to be released
There's most certainly residuals, I've accidentally deleted then installed Windows on top of a bunch of my game saves. I found some random file recovery application and let it run for awhile. Guess what? Nearly everything was readable despite the fact it got wiped and then had a whole windows install.
NAND also experiences minor permanent damage on writes. Actually clearing the NAND involves a write as the charge has to be forced out (a write of 0s)
This can happen when TRIM is disabled
Here's a study published last year I read that goes through this exact thing
In consideration of results obtained from the experiments, it concluded that the behavior of Wear Leveling in different SSD manufacturers having the same storage capacities does not match. It varies based on the number of files, types of files, and sizes. The recovery of files from different SSD manufacturers showed different results. In all SSDs, not a single trace of any file found in disk format scenario(s). Whereas, some of the data recovered in the delete case and from only one drive. It clearly showed different behavior of data recoveries in format and delete cases. The obvious finding from this study is that the time interval of image acquisitions played a significant role, and the longer time interval supports few chances of data recovery because the TRIM and Garbage Collection process effects clearing residual data from the drives
Edit: corrected links
Which means that data is gone, permanently) for that data, there's no residuals to worry about like with spinny's and is in fact necessary to ensure decent lifespans.
I doubt that the firmware is doing an overwrite of TRIMmed data. Rather, I expect it's marking it as having been TRIMmed, and so can report that it's zeroed to higher layers. If a higher layer queries the firmware for its content, sure, they might get zeroes returned. But if you can modify the firmware or otherwise bypass it, you may be able to get at the underlying media.
There is also the "bad block" issue, where storage media can take blocks -- which may contain readable data -- out of use, so that higher layers cannot access them. That applies to rotational drives and it looks like SSDs do the same thing. Again, might require bypassing or modifying the firmware to get direct access. But there can be data leaked there.
I also wouldn't be terribly surprised if there is lingering information even after zeros are written to an SSD that might be recoverable if you could directly access the media, though I'm not familiar with the situation there. That is the case for rotational drives -- the drive platter itself is "analog", doesn't just store a discrete string of ones and zeroes at the physical level. I once knew a cryptographer who was working on quantifying that leakage for rotational drives.
Now, attacking some of that is a pain and probably not a concern, but there are some cases where it might be a target. I once knew a professor who used to work at the Department of Defense, and he'd talk about their disposal process for rotational drives:
I don't know what they did if Step 1 couldn't be completed due to drive failure. Maybe they were allowed to skip that step in that case.
That being said, probably most people don't have to worry about the same level of resources being aimed at them.
EDIT: Step 1 might have been a degauss rather than an overwrite. Either way, it was definitely just aiming to twiddle bits, not physically destroy the drive. I'm trying to remember a conversation from a couple decades back...
I doubt that the firmware is doing an overwrite of TRIMmed data. Rather, I expect it's marking it as having been TRIMmed, and so can report that it's zeroed to higher layers. If a higher layer queries the firmware for its content, sure, they might get zeroes returned. But if you can modify the firmware or otherwise bypass it, you may be able to get at the underlying media.
TRIM is garbage collection and is a part of the wear leveling system. The whole point of TRIM is to have the SSD only hold the charge it needs too for still in use (i.e. not deleted) data. It's the charge that damages blocks over time, so to extend lifespans it clears everything not needed. It's not overwriting data for security or anything per se, but rather just a result of its longevity processes
Now, I'm sure there are cheap no name SSD controllers out there with ineffective TRIM operations that just lie about the operation, but any controller worth its salt is gonna have proper TRIM.
There is also the "bad block" issue, where storage media can take blocks -- which may contain readable data -- out of use, so that higher layers cannot access them. That applies to rotational drives and it looks like SSDs do the same thing. Again, might require bypassing or modifying the firmware to get direct access. But there can be data leaked there.
Part of that process is to move the data to another block and release the charge to prevent further damage, it's possible the block is damaged in such a way that it won't even release the charge, but if that's the case it's incredibly unlikely to be readable.
I also wouldn't be terribly surprised if there is lingering information even after zeros are written to an SSD that might be recoverable if you could directly access the media, though I'm not familiar with the situation there. That is the case for rotational drives -- the drive platter itself is "analog", doesn't just store a discrete string of ones and zeroes at the physical level. I once knew a cryptographer who was working on quantifying that leakage for rotational drives.
Yea it's possible, but now you're in the needing x-ray machines, powerful microscopes, full clean room labs and people with extensive, specific skill sets which means $$$$$$$$$$$$$$$$$$$$ or in other words, state level budgets range. 99.99999% of people will be fine
TRIM is garbage collection and is a part of the wear leveling system. The whole point of TRIM is to have the SSD only hold the charge it needs too for still in use (i.e. not deleted) data. It's the charge that damages blocks over time,
I'm pretty sure that that is not correct.
The limiting factor is the number of writes. The reason that TRIM enhances life by facilitating wear leveling is that it lets the firmware know that the block no longer has useful data, so it can be returned to the pool used for wear-leveling. Without that, the firmware doesn't know whether or not it can switch the physical block used to represent a given logical location and safely overwrite the existing contents of that new block.
The reason that TRIM enhances life by facilitating wear leveling is that it lets the firmware know that the block no longer has useful data
Ah I see the disconnect, TRIM doesn't live in the OS outside of the firmware, TRIM is part of the controller firmware and is exposed as an ATA command for the OS to utilize
The study I have linked in my original comment goes more in-depth
Ah I see the disconnect, TRIM doesn't live in the OS outside of the firmware, TRIM is part of the controller firmware and is exposed as an ATA command for the OS to utilize
Yes, I know.
The study I have linked in my original comment goes more in-depth
I'm on a phone, and it only partly showed up.
I mean, I read the PDF, the problem was the viewer bogging down.
googles
This sounds like what I expected:
https://superuser.com/questions/1060831/triming-as-alternative-to-securely-erasing-a-ssd
If data security is your concern, it should be noted that neither a SECURE_ERASE nor a TRIM actually erase the flash cells. The SSD firmware keeps a list of which cells are allocated and which are not. A TRIM simply marks a cell as unallocated the same way deleting a file causes the filesystem to mark a cluster as unallocated. No attempt is made to actually erase the data. A read request from an unallocated cell simply causes the device to return 0x00 (or some other bit pattern) without actually checking the cell's contents.
There is no effective way of securely wiping an SSD. Forensics tools that can interface with the firmware directly can see the cells' contents. Also, there is more storage on the device than what is accessible from user-space. These extra cells are used in garbage collection. Garbage collection can reallocate cells on-the-fly and can still work even on a drive that is 100% full. A SECURE_ERASE may (probably does) TRIM those cells, but a blkdiscard or fstrim certainly wouldn't, since they use sector numbers to identify the areas to be TRIMmed.
The only way to securely erase an SSD is to destroy it. This is the policy of most companies in health care, banking, and government when surplussing equipment.
EDIT: I took a look at your PDF on a desktop. While it's pretty light on the specifics of how they tested that the data was present, nothing there talks about anything below the OS level. My expectation is that what they did for their test was try to do reads from the device at the OS level and see whether it returned zeroes. They aren't going to look below that. If they were interfacing with the drive at a firmware or below level, I'd expect them to have mentioned it, as it'd be a significant amount of additional work. And they don't list relevant information like model number, much less firmware revision on the drive.
This is a complete digression but do you know if there is a consumer hardware that can be reliably erased? I'm trying to make something behave as an affordable HSM. If I could store a key encrypted at rest and be able to actually delete it, that would work for me.
This is a complete digression but do you know if there is a consumer hardware that can be reliably erased?
behave as an affordable HSM
Like, to create a hardware keystore? No, I don't, sorry. If I wanted one myself, I'd probably just buy an existing one and hope that they did things correctly. :-)
