Slashdot Mirror


SSDs Cause Crisis For Digital Forensics

rifles only writes "Firmware built into many solid state drives (SSDs) to improve their storage efficiency could be making forensic analysis at a later date by police forces and intelligence agencies almost impossible to carry out to legally safe standards, Australian researchers have discovered. They found that SSDs start wiping themselves within minutes after a quick format (or a file delete or full format) and can even do so when disconnected from a PC and rigged up to a hardware blocker." So either SSDs are really hard to erase, or really hard to recover. I'm so confused.

399 of 491 comments (clear)

  1. Good. by Anonymous Coward · · Score: 5, Insightful

    Deleted, should mean deleted.

    1. Re:Good. by EyelessFade · · Score: 3, Informative

      I'm not to sure. Ibas says they are almost impossibly to wipe out. That even with secure delete, almost 90% is still intact. And I think I believe them.

    2. Re:Good. by graeme_ssd · · Score: 5, Informative
      Hello, I'm one of the authors of the original article.

      The drive's firmware is responsible for remapping blocks, and so the OS can't really control what happens whenever the OS tries to permanently delete things by asking the drive nicely to do so. Consequently, if the drive decides it's best to remap the logical block silently while not deleting the cell contents, then the OS doesn't realise the data is still there. That's what the other SSD study noted.

      On the other hand, in this situation, the thing doing the purging is the drive's firmware itself, not the OS, and the firmware knows for sure where the data is in the cells, and furthermore it's on a mission - to purge cells that it knows the filesystem is no longer using for data.

      The purging that is being done here, is taking place with the specific intention of getting cells freshened up and ready to be written to in future without delay. Consequently we can reasonably expect that the drive firmware really *wants* to nuke cells that contain real data that is no longer needed according to the filesystem metadata since that's the only way to boost performance, and that's the GC's job.

      If you want to check for yourself, try carrying out reads at the sector level yourself after running the experiment with the experimental setup described in the paper. You won't get much.

      I guess what I'm saying is that both studies are right despite the apparent contradiction, since they're dealing with completely different circumstances and motivations for 'purging' - OS or drive GC controlled.

      Graeme.

      p.s. Does anyone know of a postdoc position in AI, robotics, or bioinformatics in Grenoble, France? I'm currently looking for a new job.

    3. Re:Good. by Rockoon · · Score: 1

      On the other hand, in this situation, the thing doing the purging is the drive's firmware itself, not the OS, and the firmware knows for sure where the data is in the cells, and furthermore it's on a mission - to purge cells that it knows the filesystem is no longer using for data.

      Inaccurate.

      These drives are oblivious to the file-system, which is why there needs to be a TRIM command which allows the OS to say "hey, I don't care about that page (4 KB) any longer." If the SSD is pretending to be a 40 GB drive, then over time its working set grows to 40 GB of data even if the file-system is only using 10 GB of it.. and it needs to treat all 40 GB as precious unless its received some TRIM's to inform it that only 10 GB is precious.

      You are right that if its powered up and idle, the SSD will be looking for re-mapping work to do on its own behalf. But you are wrong that the SSD is doing the purging outside of OS intervention.. the OS must specifically mark pages for purging.

      --
      "His name was James Damore."
    4. Re:Good. by Anonymous Coward · · Score: 1

      Deleted, should mean deleted.

      Except to people who were trained on an OS that means "deleted should mean move to a trash folder so I can undelete it".

      IMHO encryption should be the right technology to protect data-at-rest, rather than implementation details of storage devices.

    5. Re:Good. by jbolden · · Score: 1

      Welcome to /. and that makes perfect sense now. Hopefully you get moded up.

    6. Re:Good. by Timothy+Brownawell · · Score: 3, Informative

      These drives are oblivious to the file-system, which is why there needs to be a TRIM command which allows the OS to say "hey, I don't care about that page (4 KB) any longer."

      Some SSDs actually do understand a few filesystem formats (maybe just NTFS?), and used this to GC unused blocks before TRIM was implemented.

    7. Re:Good. by tabrnaker · · Score: 1

      Except to people who were trained on an OS that means "deleted should mean move to a trash folder so I can undelete it".

      Which OS are you talking about? Ubuntu? OSX?

    8. Re:Good. by dgatwood · · Score: 2

      But you are wrong that the SSD is doing the purging outside of OS intervention.. the OS must specifically mark pages for purging.

      That's mostly correct, but incomplete. The TRIM command marks a range of logical flash pages as unused, but it's not correct to say that pages are not wiped except when a TRIM occurs. When the flash controller needs to write a new copy of a flash page, it may leave around an older copy of that page. Those older copies of the pages may later be wiped on an as-time-permits basis by the flash controller without intervention by the OS even if the flash page never sees a TRIM call.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    9. Re:Good. by GooberToo · · Score: 2

      Inaccurate.

      If the TRIM command is used, from the firmware's perspective, wouldn't the original statement be completely accurate? The device knows which cells contain data. Using the TRIM command, the device now knowns which cells contain data and which cells the filesystem is no longer using for data.

      Unless you're advocating everyone stop using the TRIM command, it appears you're being overly pedantic.

    10. Re:Good. by lgw · · Score: 3, Interesting

      SSDs do wear-leveling. If one logical block is busy, it will migrate from physical block to physical block over time to balance activity counts. The physical blocks left behind have data that the OS cannot purge by any means. The drive's firmware is certainly aware of these blocks, and will eventually wipe them for re-use (though given this is a wear-leveling scheme, reclamition isn't necessarily that urgent).

      This is all separate from file system activity: in addition to the above, the firmware purges TRIMmed blocks, and presumably does so in preference to blocks rotated out do to wear-leveling, so a block that did get TRIMmed would be agressively purged.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    11. Re:Good. by graeme_ssd · · Score: 4, Interesting
      On the other hand, in this situation, the thing doing the purging is the drive's firmware itself, not the OS, and the firmware knows for sure where the data is in the cells, and furthermore it's on a mission - to purge cells that it knows the filesystem is no longer using for data.

      Inaccurate. These drives are oblivious to the file-system

      Hey there. Unfortunately, what you've written isn't correct, and I encourage you to read into modern SSD garbage collection. These drives really do open up the filesystem by themselves, and look for deleted files and purge them, without being asked to do so by the OS. Otherwise, can you explain how file deletion using a non-TRIM OS, followed by a drive being connected to a non-TRIM OS with a write-blocker, would result in data being purged? (we proved this experimentally, and you can reproduce it in your own home using the supplied software and experimental parameters).

      But you are wrong that the SSD is doing the purging outside of OS intervention.. the OS must specifically mark pages for purging.

      The GC on the drive in question is specifically designed to provide performance improvement for *OS that do not have TRIM*. If you don't believe me, look up the drive model in the paper and google it for forum discussions of its behaviour (or buy one for yourself, and watch it happen in realtime using the probe program! It's freaky to see a drive rapidly purge it's supposedly recoverable data when connected to a non-TRIM OS)

      Graeme.

    12. Re:Good. by moonbender · · Score: 1

      Depends on what kind of a secure delete you're referring to. Simply overwriting a file -- ie. the way to securely delete it on a normal hard disk -- won't accomplish much: the meaningless data that's meant to overwrite will end up somewhere else, since there is no easy way to tell the controller where to actually put stuff. So, yeah 90% might be left.

      However, if you securely wipe an entire drive, by writing $capacity bytes to it, nearly everything on the drive will be irrevocably gone. I say nearly because all SSDs use overprovisioning to a certain degree: there is more physical flash memory available than the capacity reported by the controller. The excess space is used to increase performance and reliability. It's conceivable that a file gets written to a block that's never again written to because it's permanently replaced by a block in the overprovisioned area. AFAIK, regular HDDs also have a little bit of extra capacity to improve reliability, but it's nowhere near as much: the new 25nm OCZ drives has 128 GB "raw" capacity of which only 118 GB can be used. (Slightly more, 120 GB, can be used in the older 34nm version. Source: StorageReview.)

      Of course, none of this takes into account what I assume TFA is talking about: that the controllers on SSDs will often permanently wipe blocks without the user going to any great lengths (beyond, you know, unlinking the file), in the normal course of operations that are, in fact, required for the enduring performance of the SSD.

      --
      Switch back to Slashdot's D1 system.
    13. Re:Good. by Skapare · · Score: 1

      The OS isn't writing to the cells directly. It's writing to a presented logical drive just above the wear-leveling layer. With this layer also doing speculative cleaning of sectors (what the OS writes) and their underlying cells based NOT on what is discarded by having written over it (where the wear leveling would write the new data on different cells, making the old cells now available ... and suitable for pre-erasing when the SSD is not busy) ... but discarded by the design of the filesystem referencing structures, then the firmware needs to know something about the filesystem to know when these discards happen. So my big question is which filesystem types do these firmwares understand? Is this just filesystems invented in Redmond? Or does it also include filesystems that are readily available without royalty costs? Oh, and where can I find a utility for Linux/BSD that will execute a TRIM operation on the entire drive to effectively reset its mapping state (but without losing any important wear stats)?

      --
      now we need to go OSS in diesel cars
    14. Re:Good. by PopeRatzo · · Score: 1

      p.s. Does anyone know of a postdoc position in AI, robotics, or bioinformatics in Grenoble, France? I'm currently looking for a new job.

      Welcome to Slashdot, Graeme. Interesting article and good luck finding a gig in Grenoble.

      And if anyone hears of a high-paying part-time job playing the harmonica or applying suntan oil to swimsuit models in Carriacou or Barbados, please let me know.

      --
      You are welcome on my lawn.
    15. Re:Good. by Bengie · · Score: 1

      GC can work without the OS, but it works MUCH better with help.

      SSDs are copy-on-modify. If you change a block of data, the SSD will write the new data to a zero'd block(if available), remap the sector from the old block to the new one, and flag the old block for clean-up. This is not the same as the OS saying "This file is no longer in use, remove it". This form of GC only applies when the OS tell the drive to change a sector. The drive has no way of knowing if the sector is no-longer used.

    16. Re:Good. by mspohr · · Score: 1

      Deleted has never meant deleted. It has always been possible to retrieve files from the 'Recycle bin', Trash bin, or file system. Only by diligently deleting at a low level has it ever been possible to really delete something (and even these efforts could be ineffective).

      --
      I don't read your sig. Why are you reading mine?
    17. Re:Good. by HowIsMyDriving? · · Score: 1

      Does anyone know of a drive that has this behavior? I have an Apple Laptop that must run OS 10.5. I know that OSX does not support TRIM, so I would love to upgrade to an SSD (SATA) that does this independently of the OS.

      --
      Welcome to the Entropy Bar, may I take your order?
    18. Re:Good. by graeme_ssd · · Score: 3, Informative
      Hey there, HIMD.

      If you take a look at: http://www.jdfsl.org/subscriptions/JDFSL-V5N3-Bell.pdf , you'll see the drive model we used was the Corsair P64 (see page 16).

      There's also support for GC on the OCZ vertex 2 drives, I think. However, some bad news and good news for you:

      The bad news is, the firmware GC implementation we looked at only supported GC on NTFS partitions.

      The good news is, you can use NTFS with macos if you like (e.g. through FUSE), or you can wait for MacOS Lion, which is about to be released, and which is rumoured to support TRIM directly. Shouldn't be long!

      Graeme.

    19. Re:Good. by 42forty-two42 · · Score: 1

      To clarify - is this deletion occurring because the drive analyzed the filesystem metadata and decided it would be a good idea to zero some sectors, or is it an asynchronous response to a fast TRIM command applied to an extent covering the whole drive?

    20. Re:Good. by Rockoon · · Score: 1

      If the TRIM command is used, from the firmware's perspective, wouldn't the original statement be completely accurate?

      No, the original statement says that the SSD understands the file-system, not that its been explicitly told by the OS what pages arent in use by a special command needed because SSD's shouldn't and don't normally understand file systems. Specifically he made it sound like SSD's were constantly wiping themselves based on the data that they contain, rather than the commands that they have been issued.

      It has now been revealed (wasn't in the summary) that the submitter found an SSD firmware that does understand at least one file-system. This is not the norm, nor is it the future. Its a tragedy waiting to happen.

      --
      "His name was James Damore."
    21. Re:Good. by Bai+jie · · Score: 2

      Can you guys please stop arguing and just tell me if I can wipe the porn stash off my SSD or not?

    22. Re:Good. by graeme_ssd · · Score: 3, Informative

      "To clarify - is this deletion occurring because the drive analyzed the filesystem metadata and decided it would be a good idea to zero some sectors, or is it an asynchronous response to a fast TRIM command applied to an extent covering the whole drive?"

      It's not TRIM. We used a non-TRIM OS and a write blocker for this reason. The manufacturer has mentioned a garbage collector that works with NTFS, and the only way it could work is by zero-ing areas of the SSD using information gleaned from the metadata. Hope this clarifies the situation for you! :-)

      Graeme.

    23. Re:Good. by geminidomino · · Score: 1

      Might wanna go easy on those absolute modifiers there, sonny. Abusing them made just about everything you said there... well... wrong.

    24. Re:Good. by 42forty-two42 · · Score: 1
      Isn't that a bit dangerous? I'd be worried about a scenario like:
      • OS allocates block X and fills contents in memory.
      • Application fsyncs(). OS writes an entry for updating the metadata to the write-ahead log, as well as writing actual block contents to block X. At this point, the block is committed to disk, so the OS returns from the fsync.
      • OS crashes before updating actual metadata. User reboots.
      • SSD decides that block X is free (looking at the metadata) and trims it
      • OS reboots, applies write-back log. Block X contents have been lost

      Or perhaps even:

      • OS allocates block X and fills contents in memory. Write activity is low, so writeback is delayed for a while.
      • Memory pressure causes block X contents to be flushed to disk. Metadata remains in memory.
      • SSD decides block X is unallocated (WAL is empty, block is marked as unallocated) so it frees the block
      • OS writes back metadata. Block is now zeroed.

      Or even good old fashioned file system corruption being made worse by something like this...

    25. Re:Good. by HowIsMyDriving? · · Score: 1

      Thank you for the info. I work with biomedical devices and have a bunch that only interface with PPC Macs and really thrash my Powerbook HD and an SSD is about the last thing I can upgrade before paying 100k for a hardware upgrade for the device.

      --
      Welcome to the Entropy Bar, may I take your order?
    26. Re:Good. by Neil+Boekend · · Score: 1

      IANAEOTS (Expert On The Subject), but if the SSD doesn't know which sectors can be purged then how does it decide what sectors can be overwritten when the drive is full?
      Assume you have a 40 GB SSD. Write 60 1GB files to it, deleting each directly after it's creation. How is it going to know where to put the 41th file when it doesn't know which sectors can be purged?
      I presume the OS tells it "delete this file / unlink this file" and it can mark those sectors as "Can be purged". When it has time to spare it could start purging the sectors. Whether or not it does is an entirely different matter, but I think it has the required information.
      Assuming I am wrong: please enlighten me.

      --
      Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
    27. Re:Good. by leuk_he · · Score: 1

      According to this lecture the log is written first and the main data is written after the log. There is no problem there(But i would not bet my data on this).

      FOr the second case: OS'ses are lazy in setting the bitmap for available data. If the OS chrashed you do not want used space marked as free, thsi would result in using the same disk space twice (vary bad) as opposed to having some free space marked as used (not very bad and fixable by a disk scan)

    28. Re:Good. by 42forty-two42 · · Score: 1

      Writing the log first is an implementation detail if anything - and in fact, ext3's ordered mode is very careful to write the data first. No idea what Windows' NTFS implementation does of course. And as long as the WAL will fix up any outdated bitmaps, with traditional drives there's no problem. But if the drive decides to zero out blocks on its own initiative, then things get a bit... well, scary. I suppose you could legitimately do it if you collect the list of extents to trim at boot, after verifying the drive is clean, but filesystem corruption is still an issue (I doubt the disk runs a full fsck at startup...)

    29. Re:Good. by graeme_ssd · · Score: 1

      SSDs are a great upgrade for macs. Last year I chose a 2-year old core2duo Macbook with an SSD over a shiny new, top-end iMac i7 quad-core. After comparing them side-by-side for most of the work I was doing, 'for most practical purposes' the Macbook/SSD ran better.

    30. Re:Good. by gtvr · · Score: 1

      Yeah, if I knew about a job like that, the first thing I would do is email it to you. Just keep hitting refresh on your email ;-)

    31. Re:Good. by Agripa · · Score: 1

      Hey there. Unfortunately, what you've written isn't correct, and I encourage you to read into modern SSD garbage collection. These drives really do open up the filesystem by themselves, and look for deleted files and purge them, without being asked to do so by the OS. Otherwise, can you explain how file deletion using a non-TRIM OS, followed by a drive being connected to a non-TRIM OS with a write-blocker, would result in data being purged? (we proved this experimentally, and you can reproduce it in your own home using the supplied software and experimental parameters).

      Start with a SSD which has a rated capacity of 40GB and 10GB of extra space for garbage collection. Write 40GB of data to the drive using all of the rated capacity without overwriting. Now write 10GB of data to the drive overwriting 10GB of the data written earlier.

      At this point, without having used TRIM and without the drive being able to understand the file system since we did not use one, the drive already knows that 10GB of the first 40GB of data is no longer needed and GC can take place freeing up 10GB of space for the over provisioned area. This can take place preemptively while the drive is powered without any further commands or later when space needs to be freed for further writes.

      Without writing the last 10GB of data and overwriting some of the 40GB of data written earlier, file deletion has to modify data structures already written to the disk and those areas will be subject to garbage collection and erasure which could happen later.

    32. Re:Good. by Agripa · · Score: 1

      It's not TRIM. We used a non-TRIM OS and a write blocker for this reason. The manufacturer has mentioned a garbage collector that works with NTFS, and the only way it could work is by zero-ing areas of the SSD using information gleaned from the metadata. Hope this clarifies the situation for you! :-)

      Despite my other post, I am not surprised that some manufacturers do this because it is an easy way to improve performance. Some compact flash cards understand specific versions of the FAT file system and do the same thing. This was noticed because they behaved differently depending on which file system was used.

    33. Re:Good. by graeme_ssd · · Score: 1

      "followed by a drive being connected to a non-TRIM OS with a write-blocker"

      "Now write 10GB of data to the drive overwriting 10GB of the data written earlier."

      Write-blocker. Also, here, we did not do any writes to the drive, only reads. I wasn't asking you to suggest a way in which an OS can (generally) overwrite deleted file data, that's easy. I was asking you to explain how that could happen in the experimental setup we described, if you're suggesting it wasn't the drive-based GC that did it.

      Graeme.

    34. Re:Good. by vakuona · · Score: 1

      I think that is true of journaling filesystems true, IIRC. They never write to the same place as where the file currently is in case something bad happens whilst they are writing. This is why some secure delete tools do not work properly on journaling FS's. To securely erase an SSD, I would imagine you could just zero the entire drive.

    35. Re:Good. by Enigma23 · · Score: 1

      Deleted, should mean deleted.

      That's what the Linux command shred is for...

      --
      Ceci n'est pas une .sig
    36. Re:Good. by Agripa · · Score: 1

      Write-blocker. Also, here, we did not do any writes to the drive, only reads. I wasn't asking you to suggest a way in which an OS can (generally) overwrite deleted file data, that's easy. I was asking you to explain how that could happen in the experimental setup we described, if you're suggesting it wasn't the drive-based GC that did it.

      I am suggesting the drive based GC could be active after the drive is powered up with writes blocked because of an earlier accumulation of deallocated sectors even without TRIM support or use.

    37. Re:Good. by dgatwood · · Score: 1

      Just to be pedantic, I should probably correct that slightly. I think TRIM operates on erasure blocks rather than (read-write) pages.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    38. Re:Good. by Stupendoussteve · · Score: 1

      OS X 10.7 supports TRIM.

    39. Re:Good. by PipsqueakOnAP133 · · Score: 1

      Look at OWC for their Legacy SSDs.
      http://eshop.macsales.com/shop/SSD/OWC/Mercury_Legacy_Pro

      They're actually Sandforce SSDs with a SATA to PATA converter.
      Given Sandforce appears to be in the lead for garbage collection, I'm sure these should do you well.

  2. Why can't they make up their minds by joaeri · · Score: 1

    Lately all you have heard is the complete opposite. That they are impossible to completely erase so it's unsafe to store company/secure data on them. Because even if you erase the file its still left on the disk and just marked as empty. Now they say they erase them self.

    1. Re:Why can't they make up their minds by DrgnDancer · · Score: 4, Insightful

      It's not hard really. The drives autoclean themselves. So when you delete the inode reference to a given data file, it will be completely much more quickly that on a normal magnetic drive (which won't reclaim the space till it's needed). On the other hand it won't respond to commands that would FORCE a magnetic drive to completely wipe the file.

      So if you're in your secret lab and you hear that the evil enemy is an hour away, you just type "rm /*" and wander off to escape. By the time they get there all your data will be completely wiped. On the other hand if they are breaking down the door to your secret lab and you have only seconds left you can't type "shred /home/joeari/secretfile" and expect it to be perma-deleted like you could with a magnetic drive.

      They recover deleted sectors more quickly, but can't be forced to do so in a controlled manner.

      --
      I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
    2. Re:Why can't they make up their minds by arivanov · · Score: 4, Insightful

      The do not completely erase when you hit them with a commercial erase tool because the commercial erase tool does not give the drive a chance to "take a breath". If you hit it with a DOD wipe instead of overwriting old blocks the drive will give you new until it runs out of spares and after that will slowly overwrite some old. At the end some data will remain.

      You need to hit it with short write bursts which are alternated by rest periods so that the controller can reorganise the flash especially if you use the TRIM ATA command to mark stuff as "really deleted". As a result the data will be wiped to a standard which no hard drive can achieve.

      I can write a perl 10-liner that feeds DD to do that in about half an hour. So any geek can erase one. However the commercial and most importantly certified by banking and govt tools cannot just yet. They definitely will as there is no rocket science here. Until this happens you will hear both sides of the story depending who you talk to.

      By the way the same will apply to overlapping recording and drives with flash cache. A "dumb" wipe will not wipe them. At the same time a script any sysadmin can write in his spare time can wipe them so effectively that no forensics can get the data back.

      --
      Baker's Law: Misery no longer loves company. Nowadays it insists on it
      http://www.sigsegv.cx/
    3. Re:Why can't they make up their minds by RapmasterT · · Score: 2

      Lately all you have heard is the complete opposite. That they are impossible to completely erase so it's unsafe to store company/secure data on them. Because even if you erase the file its still left on the disk and just marked as empty. Now they say they erase them self.

      you've discovered the paradox that exists in the gulf between "in theory" and "in the real world". In the real world, a lot of shit that people get lathered up about is completely impractical and for all real-world purposes "impossible". But that doesn't stop some tech "editor" on a slow news day from hype pimping some theory as if it's the pending zombie apocalypse.

    4. Re:Why can't they make up their minds by CastrTroy · · Score: 1

      My understanding is that shred doesn't work on modern file systems because they don't overwrite a file in place. See the Shred MAN page for information on this. It worked on old file systems like ext2, but on more advanced journaling file systems, this is almost never the case.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    5. Re:Why can't they make up their minds by Tumbleweed · · Score: 1

      Ignition of the magnesium slab mounted to each SSD and memory module works 100% of the time.

      Don't forget your backups!

    6. Re:Why can't they make up their minds by graeme_ssd · · Score: 5, Interesting
      Hi, I'm one of the authors of the article (Graeme).

      You wrote: "So if you're in your secret lab and you hear that the evil enemy is an hour away, you just type "rm /*" and wander off to escape. By the time they get there all your data will be completely wiped. On the other hand if they are breaking down the door to your secret lab and you have only seconds left you can't type "shred /home/joeari/secretfile" and expect it to be perma-deleted like you could with a magnetic drive."

      Actually, we found something even more interesting when we prepared this paper.

      An evil criminal could run a quick format (about 8 seconds effort) if police were at the door, or they could set up a dead man switch to do the same. When the investigator powers up the drive, the drive's internal GC runs quickly (we couldn't get any formal documentation about why this is - presumably it begins so quickly since the filesystem metadata is nice and simple to process) and so after about 3 minutes it begins wiping itself.

      Just a few minutes later it has finished, and data and old filesystem metadata are gone (at least, gone as far as logical access to drive sectors is concerned).

      I'd encourage anyone who finds the result interesting to take a glance at the original paper, it's written to be accessible to people outside the traditional drive forensics community and there are some fun, free script tools you can use to monitor drive GC behaviour in near-realtime.

      Graeme.

    7. Re:Why can't they make up their minds by Just+Some+Guy · · Score: 3, Insightful

      On the other hand it won't respond to commands that would FORCE a magnetic drive to completely wipe the file.On the other hand it won't respond to commands that would FORCE a magnetic drive to completely wipe the file.

      So why isn't a "wipe everything, including the spares" command part of the SATA standard command set? I can think of many times I'd like to completely erase a drive. Basically, any time I run the equivalent of "fdisk, o" in whatever OS I'm using, I'm explicitly telling the drive, "I value nothing here". That would be a prime time to optionally tell a drive to totally erase itself.

      There are even non-security-related reasons for doing this. IIRC, the reiserfs recovery tools would scan a partition to look for data laid out in reiserfs-formatted chunks and undelete them. That's normally exactly what you want. However, suppose you're using reiserfs and running a VM that also uses reiserfs on its virtual disk, which lives inside a file on your main filesystem. The recovery tools would see those structures, too, and merge them back into your directory structure. This is typically disastrous.

      When programming in low-level languages, it's nice to know that the only thing in your process's heap is data you've explicitly put there. The same holds true for hard drives. While we're obviously pretty good at keeping the wheat separated from the chaff, it'd be nice if you could guarantee that there was no chaff to start with.

      --
      Dewey, what part of this looks like authorities should be involved?
    8. Re:Why can't they make up their minds by Anonymous Coward · · Score: 1

      you just type "rm /*"

      I just tried that command, it didn't work :(

    9. Re:Why can't they make up their minds by Andy+Dodd · · Score: 1

      I've seen references that this has been added to the latest standard, but I haven't found any concise details.

      The TRIM command was added, which lets the OS signal that a previously used block is free and can be erased - if you TRIM everything the drive will probably erase all blocks (mapped and unmapped).

      I haven't seen any details of the "sanitize" command I've seen a few references to.

      --
      retrorocket.o not found, launch anyway?
    10. Re:Why can't they make up their minds by bluefoxlucid · · Score: 1

      However, suppose you're using reiserfs and running a VM that also uses reiserfs on its virtual disk, which lives inside a file on your main filesystem. The recovery tools would see those structures, too, and merge them back into your directory structure. This is typically disastrous.

      No, it wouldn't, unless your VM is very horribly broken and your host OS is even more broken. Try creating an empty file, lseek(30M), write("\0"), then read in the middle to see what's in the rest of the file.

      If you want to wipe a hard disk, dd if=/dev/zero of=/dev/sda1

    11. Re:Why can't they make up their minds by icebike · · Score: 2

      Actually the man page states that on ext3 file systems running in the default manor (data=ordered) shred works fine. If you journal data as well, not so good.

      The underlying file system in use is no guarantee either. Software, such as word processors often write out a new file each time you save, and if that is successful, they then delete the old one. This defeats shred because shred requires a file to exist to delete it. (It does not shred un-allocated space).

      --
      Sig Battery depleted. Reverting to safe mode.
    12. Re:Why can't they make up their minds by maxwell+demon · · Score: 2

      But what happens if you use a different file system the drive makers didn't think of? Do you risk losing data because the SSD misinterprets your file system structures?

      --
      The Tao of math: The numbers you can count are not the real numbers.
    13. Re:Why can't they make up their minds by stubob · · Score: 1

      Just FYI, I've seen what happens to a system if you type "rm -rf /" (on a live system, no less!). It won't erase the whole drive. Most likely, you will remove some OS important file and the system will shut down. It's possible to rebuild a system that's had its root removed. Most of the files will still be there. (This was Solaris 10, IIRC).

      --
      Planning to be moderated ± 1: Bad Pun.
    14. Re:Why can't they make up their minds by vadim_t · · Score: 1

      The command does exist. It even includes security provisions for insisting on finishing the process before it allows doing anything else.

      But of course whether it actually does what it's supposed to depends on the firmware.

    15. Re:Why can't they make up their minds by Megane · · Score: 2

      However, suppose you're using reiserfs and running a VM that also uses reiserfs on its virtual disk, which lives inside a file on your main filesystem. The recovery tools would see those structures, too, and merge them back into your directory structure. This is typically disastrous.

      Sounds like it would be murder on your drive's directory structure.

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    16. Re:Why can't they make up their minds by Just+Some+Guy · · Score: 2

      I think you missed the point. Say you've installed Ubuntu on a reiserfs partition inside a VM. The VM's harddisk file is stored at /var/tmp/ubuntu.vdi. For some reason, you need to fsck /var. It reads each block in /var's partition and looks for things that look like inodes and merges them back into the directory structure tree. Guess what happens when it starts scanning blocks that are inside ubuntu.vdi? It finds a lot of things that look like inodes and merges them back into the directory structure tree. Don't believe me? Fine. Maybe Theodore Ts'o can convince you.

      If you want to wipe a hard disk, dd if=/dev/zero of=/dev/sda1

      I don't think there's a single modern SSD or HDD where that will clear every bit of storage on the device. Both drive types keep spare blocks to swap into rotation whenever old ones become damaged and it's impossible to wipe those blocks with dd. Hence the need for a native drive command to do it. Apparently the drive designers thought so, too, and made a command to do that.

      --
      Dewey, what part of this looks like authorities should be involved?
    17. Re:Why can't they make up their minds by jefe7777 · · Score: 1
      shred works just fine on ext3 (and probably ext4)

      from the link you posted:

      In the case of ext3 file systems, the above disclaimer applies only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the /etc/fstab file, as documented in the mount man page.

      I've read that ext4 works the same way, but cannot find an authoritative link at the moment.

    18. Re:Why can't they make up their minds by Just+Some+Guy · · Score: 1

      Sounds like it would be murder on your drive's directory structure.

      Your humor slays me.

      --
      Dewey, what part of this looks like authorities should be involved?
    19. Re:Why can't they make up their minds by Nikker · · Score: 1

      So if I was to build a small battery/power supply into my computer exclusively for the SSD once I initiated the wipe/delete the firmware would continue the job on it's own with out the need of the OS?

      --
      A loop, by its nature, continues. If that didn't make sense, start reading this sentence again.
    20. Re:Why can't they make up their minds by JWSmythe · · Score: 3, Interesting

          Trust me, dd can really make a mess of things, if by intention or mistake.

          I was cloning one drive (A) to a larger one (B). It needed to preserve the partition table, MBR, etc.

          dd of=/dev/sda if=/dev/sdb bs=1024

          About 10 seconds after I hit enter, I saw the mistake, and aborted it. Ya, I dd'd an empty drive over the populated one. How much harm could that possibly do, right? :)

          I've done plenty of drive recoveries, with about an 80% success rate. The only ones I can't do are drives that don't spin. I don't have the facilities to transfer the platters.

          Two weeks and several recovery attempts, I had recovered about 25% of what I wanted. The partition table, and the MFT were destroyed, and files were on four partitions with two different filesystems (NTFS and ext3). That was in 10 seconds. If you were to say" dd if=/dev/random of=/dev/sda bs=1024", it's rather unlikely even the best would find anything.

          From what I understand, the best chance at recovering data from an overwritten media is to look at sectors marked as bad. They are automatically skipped, so they don't get overwritten by anything. Who knows what will be in them though. Most likely on most users machines, it will be pieces of the browser cache, or Windows Update files.

          That's not to say if some agency named "No Such Agency", were really bent on finding out what I had on there, they couldn't recover something. Many agencies can't go beyond files that currently exist, or are in the "Recycle Bin". Some go as far as undeleting from an otherwise functional filesystem. Is it worth weeks and thousands of dollars for whatever organization to recover what you have hiding on your desktop? Probably not. If you have secrets, don't hide them on your PC at home, even if you are protected by a nice wood front door with fancy security locks. One brick through the window, and a fast getaway, will defeat any door lock and alarm system. If you kept all of your important information on some random colocated server in another country, AND you have a second person with access to clear your data, it would be untouchable by most agencies. Say I had a server colocated in China, with the normal protections (encrypted virtual filesystem, etc, etc.), and only used my desktop to manipulate them through a terminal session (VNC, SSH, etc) the most that could be found is that I connected to a server in an untouchable place, and by the time they managed to get to it, my 2nd party could have removed it.

      --
      Serious? Seriousness is well above my pay grade.
    21. Re:Why can't they make up their minds by tomuo · · Score: 1

      Search youtube, there are several vids of people who let loose a rm -rf / to see the death throes of a linux eating itself.

    22. Re:Why can't they make up their minds by CastrTroy · · Score: 1

      But there's a lot of other file systems that shred doesn't work on, some listed are JFS, ReiserFS, XFS, and possibly EXT3 depend on how they are configured. They also state that if you are using RAID it's not garaunteed to work. Point is, is that regardless of what kind of drive you are using SSD vs. Spinning platters, you shouldn't really trust shred to really shred your data.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    23. Re:Why can't they make up their minds by dgatwood · · Score: 1

      If your filesystem checker does that, it is very, very broken. No fsck tool should ever look inside an existing file for filesystem metadata. A filesystem checker should be collecting its free block list or bitmap as it reads the existing metadata so that it can check that later. Once you have that free block list you now know which blocks might potentially contain filesystem metadata legitimately. Then, you check only the blocks that are not already in use for something else.

      Now a deleted disk image, perhaps, but even then, only if you explicitly pass flags to the filesystem checker to tell it to reattach "lost" inodes that haven't been marked as deleted. Even then, the problem can be solved by adding a UUID to each inode and ignoring things that look like inodes if the UUID doesn't match.

      For that matter, even without a UUID, and even in the case where the filesystem metadata is severely damaged and you're reconstructing large parts of it from scratch by scavenging blocks, you should never have a situation where an inode appears inside the block range for another file. If you have an embedded disk image, you should be able to programmatically determine which inodes are real and which ones are inside an image by scanning for directory blocks first.

      A directory block on a disk image will mostly point to inodes that aren't actually at those physical blocks because the block numbers are logical offsets into a file instead of being relative to the start of the partition. A directory block that's real will point almost if not entirely at real inodes. Then, when you see an inode that looks like it is part of another file, you see whether it was referenced from a directory block that looks real. If not, you assume that the inode isn't real, either.

      BTW, the problem of filesystem nesting is fixed in Reiserfs V4, and is a pretty good reason to not use V3.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    24. Re:Why can't they make up their minds by networkBoy · · Score: 2

      yep, at least on my drive it does.
      (note I emulated this by removing the sata cable and not the power cable, as opposed to a nifty diode steered backup battery).

      re-connected the drive after 5 min, and re-enumerated the drive, and it was rather blank.
      -nB

      --
      whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
    25. Re:Why can't they make up their minds by julesh · · Score: 1

      But what happens if you use a different file system the drive makers didn't think of? Do you risk losing data because the SSD misinterprets your file system structures?

      I would assume they're checking FS magic numbers (e.g. "NTFS\x20\x20\x20\x20" at offsets 3-10 of the first sector) before doing anything interesting, which ought to make it safe as long as you're not doing something totally bizarre. This doesn't mean your ext3 system can't take advantage of it, of course -- just write a blank NTFS system over your fs and reboot.

    26. Re:Why can't they make up their minds by maxwell+demon · · Score: 2

      You mean, something bizarre like accidentally restoring a boot sector to the wrong partition?
      Normally this wouldn't do any harm as long as you fix the problem before you mount the partition again. However, if the drive interprets the data by itself, even immediately fixing this may be too late.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    27. Re:Why can't they make up their minds by couchslug · · Score: 1

      "That they are impossible to completely erase so it's unsafe to store company/secure data on them."

      Sure it's safe. Drives are trivially cheap, so destroy them instead of wiping them. There are plenty of ways to dispose of drives. I'd
      just clamp it in a vise then fold it over with a hammer.

      If the Illuminati are after your data or you like good destructive fun, Google "drive slagging".

      --
      "This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
    28. Re:Why can't they make up their minds by Lost+Race · · Score: 1

      If you 'dd if=/dev/zero of=/dev/sdx' and wait for "out of space on device", then thereafter any read from any logical sector will only return all zeros. There may still be some old data left in spare sectors, but there is no way to get at them through the standard controller interface. Maybe with custom firmware. Maybe.

    29. Re:Why can't they make up their minds by infolation · · Score: 1

      Although with seconds to go, an entire SSD could be destroyed more easily than the thermite-wrapped HD method.

    30. Re:Why can't they make up their minds by arivanov · · Score: 1

      Big forensic shops do not just use custom firmware. They actually disconnect the head + platter assembly from the original electronics and connect it to a set that has the firmware preloaded. If that fails, there is kit that can recover off the physical platters. Some of this costs an arm, a leg, a tail and a prosthetic.

      All of this investment however is wasted on a flash drive. You cannot access flash drives in any other way but via their normal interface at this point. There is simply not enough information out there about the new controllers to build a proper forensic rig that replicates the functionality. However, even access through the controller is enough to recover all "spare sectors" straight away via custom firmware and I bet that the people who "have to have" such firmware already have it.

      --
      Baker's Law: Misery no longer loves company. Nowadays it insists on it
      http://www.sigsegv.cx/
    31. Re:Why can't they make up their minds by wildstoo · · Score: 1

      it will be completely much more quickly that on a normal magnetic drive

      Pardon me, sir, but it would appear you accidentally a word.

    32. Re:Why can't they make up their minds by DrgnDancer · · Score: 1

      I dunno if it's changed, but it used to be possible to completely wipe a Linux system this way. Everything important: the kernel, the SATA drivers, and the rm command, are loaded into memory so even as you delete the copies on disk they continue to merrily do what you told them too. New commands quickly cease to function, and this can be a clue that you've done something wrong. As I recall the time I accidentally did this it was on a system without X, so possibly X stuff would start to fail and prevent it from completing (i.e. if your terminal committed suicide it might kill your rm command too).

      --
      I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
    33. Re:Why can't they make up their minds by RockDoctor · · Score: 1

      Trust me, dd can really make a mess of things, if by intention or mistake.

      Never! You don't say?

      I was cloning one drive (A) to a larger one (B).

      [SNIP WAR STORY]

      I dd'd an empty drive over the populated one. How much harm could that possibly do, right?

      The data content of a welding torch is near enough zero too, so running a welding torch over a platter is unlikely to cause significant harm.

      I've done plenty of drive recoveries, with about an 80% success rate.

      In the context of the rest of the war story, this isn't encouraging.

      Two weeks and several recovery attempts, I had recovered about 25% of what I wanted.

      Errr, how long did it take you to restore from the backup that you'd taken before doing your funny tricks? (OK, yes, I see that, for some reason, you'd wanted to preserve the partition table etc. Can't quite see why you were wanting that, unless you were working on a live system. But whatever ... even more so if it's a LIVE system than an offline system, you experiment and test your scripts on a sacrificial system before you approach your important system. Make your scratch monkey look more like your live monkey, not the other way around.) I'm sure that every sysadmin guide I've ever read said "Backup FIRST ; then do $FUNNY_SHIT"

      Serious? Seriousness is well above my pay grade.

      Hmmm. I didn't write that.

      I'm going to read some BOFH ; that has an air of sensible unreality.

      --
      Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
    34. Re:Why can't they make up their minds by RockDoctor · · Score: 1

      Boring ; I'd read that BOFH last week from a work's computer.

      --
      Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
    35. Re:Why can't they make up their minds by wwphx · · Score: 1

      A different file system or OS wouldn't make much of a difference for forensic analysis, the software they use to copy a drive makes a bit-by-bit image, and a bit is a bit is a bit. The higher level encoding might need add'l translation, but once they have the copy, it's not too difficult to get additional hardware and a copy of Operating System XYZ to read the write-protected image copy. It might cause reliability problems to someone trying to implement a different file system on a SSD, but if it were easy, anyone could do the stuff we do.

      --
      When you sympathize with stupidity, you start thinking like an idiot.
    36. Re:Why can't they make up their minds by maxwell+demon · · Score: 1

      I didn't have forensics in mind, but normal everyday use. If your drive misinterprets live data as abandoned data, it means you'll face a data loss. It can be assumed that they tested it well with current NTFS, and hopefully also with other widely deployed file systems to make sure it doesn't lose data there. However they probably didn't test it on less-frequently used file systems, and they definitively didn't test it on future file systems which don't even exist yet, including but not limited to future versions of NTFS. Also they probably assume that the file system structures are intact; in the real world, file systems sometimes go corrupt; you don't want to lose even more data due to the drive doing its own thing (and yes, you should have backups, but such a data loss might remain unnoticed until your last backup with valid data was deleted).

      IMHO the drive should never try to second-guess the operating system.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    37. Re:Why can't they make up their minds by wwphx · · Score: 1

      I agree that it's an issue, ignoring a forensic angle. I wrote about this on my blog last night and talked about the problem for innocent data recovery: accidental file deletion or major server crash. If you had several of these in a RAID 5 or 10 config and one failed without you noticing, then a second failed, how tough of a job would it be for a data recovery company to rebuild this? I think you'd be SOL. We had a server crash that had been built by the previous and no longer present IT group, they'd somehow done RAID at the Windows Server level plus had a RAID drive controller, and when it crashed hard, it totally bollixed the data, I don't think we got anything valuable back from the recovery company, and my boss had been lax on his tape backups. I consider backups like voting in Chicago: backup early and often.

      --
      When you sympathize with stupidity, you start thinking like an idiot.
  3. trim/discard by Tomun · · Score: 2

    At a guess this is caused by mounting with the discard option, or trim as its called in Windows. It tells the drive you don't need the data stored where a deleted file used to be.

    Maybe it's still there if you look with a microscope but who really does that?

    1. Re:trim/discard by Hatta · · Score: 3, Insightful

      Deleting a file should tell the OS that I don't need that data. That's what deleting is.

      --
      Give me Classic Slashdot or give me death!
    2. Re:trim/discard by Artraze · · Score: 4, Informative

      > Deleting a file should tell the OS that I don't need that data. That's what deleting is.

      It does, and that is, in fact, what it is. So Windows unlinks the file from the directory and removes the blocks from the in-use map.

      The drive, however, doesn't know any of this. It updates the requested sectors representing the directory and volume info, and that's about it. It has no idea that blocks somewhere else on the drive are no longer needed, so it will dutifully copy and maintain that data while rewriting blocks.

      The idea of the trim command is that it tells the drive that the data is deleted so the drive doesn't have to worry about maintaining it. This was never needed in old drives because the data was basically ignored after being written. In SSDs, the data needs to be continuously copied around to facilitate the erasing (which wipes several thousand blocks at once).

    3. Re:trim/discard by afidel · · Score: 2

      For most of modern computing it's meant unlink the inode or remove the FAT entry which makes the blocks available. This was done because it was too expensive to actually cleanse the data in 99+% of situations. Now with SSD's there is a performance gain to be had by pre-wiping the block in the background so deletes eventually mean actually cleansing the data. The flip side is with most current SSD's there's no way to force a particular physical address to be wiped because of sector to block mapping (though this is actually true to some extent on all modern HDD's due to sector re-mapping for bad areas).

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    4. Re:trim/discard by Firehed · · Score: 2

      Maybe it's still there if you look with a microscope but who really does that?

      The forensics team mentioned in TFS?

      --
      How are sites slashdotted when nobody reads TFAs?
    5. Re:trim/discard by graeme_ssd · · Score: 5, Informative

      At a guess this is caused by mounting with the discard option, or trim as its called in Windows. It tells the drive you don't need the data stored where a deleted file used to be.

      Maybe it's still there if you look with a microscope but who really does that?

      Hello there, I'm one of the authors of the paper (Graeme).

      This finding isn't related to TRIM in any way, though TRIM poses another nightmare for forensic investigators and may make the idea of examining deleted data/metadata redundant in a few years.

      What's happening here is that the drive itself has some code, a garbage collector, that reads the NTFS filesystem metadata and wipes any cells it thinks aren't needed any more, so that the next set of writes over those cells can take place more quickly.

      Normally this GC has seemed to take a while to kick in (various benchmarking sites suggest e.g. 30-60 minutes and unpredictable behaviour, e.g. not always kicking in when expected); here, we found that after a quick format has taken place, it reliably can be seen to kick in within minutes and also purges the drive within minutes. This is just one example of a case when the GC can kick in, of course.

      Current court-accepted forensics practice is to stick a write blocker between the drive and computer, under the assumption that the drive only modifies data when a PC tells it to: but that doesn't help you when the drive itself nukes all it's data cells within minutes of being powered on.

      I can imagine a situation where someone connects up the drive to power, (and possibly a write blocker), but not to the PC and makes a cup of coffee for a few minutes - by the time they connect it up for data transfer, it's too late, and they wouldn't even realise it had happened - the drive doesn't exactly make any whirrs or clicks as it wipes itself.

      Alternatively, the circumstances we found: in less than the time that would be taken to read an entire image off the disk for forensic study, the GC is racing ahead of you and purging the disk! Yikes. So you can imagine... a forensic investigator takes an image, examines it, presents it to the court, and when the court verifies the original disk that the copy was taken from, nothing is there any more, and the forensic investigator seems to be making it all up....

      So this feature has the potential to make it look like the police or forensic investigator themselves tampered with the original disk, as well as potentially destroying evidence that could help establish guilt or help establish innocence. We've put a number of 'interesting legal grey areas' at the back of the paper that we hammered out with reviewers, which are worth being aware of.

      Graeme.

    6. Re:trim/discard by sjames · · Score: 1

      That is, of course, true.

      The new part is that in ages past, the OS would just mark the blocks free and that was that. The data tended to remain there until the space was needed for another file, then it would be overwritten.

      Because flash has to be erased before it is written (directly overwriting doesn't work), erase can take some time, and the drive is not just a dumb device, it is now necessary to actually let the drive know that the data is no longer needed as well rather than just making a note somewhere. The ATA command to do that is called TRIM.

    7. Re:trim/discard by icebike · · Score: 1

      Deleting a file should tell the OS that I don't need that data.

      It does exactly that, by removing pointers to the data, and marking the blocks available (via normal means).

      Just like tossing an old shirt in the trash makes it inaccessible after the trash man picks it up, but does not shred the shirt
      to rags, file systems simply make it unavailable without heroic methods. Trash pickers can, and in some cases do, salvage all sorts of things from trash.

      Actual erasing things would slow down your computer quite a bit. There are software packages you can obtain to do this if you are paranoid that your computer is likely to be seized.

      In addition other operating systems such as Linux have a built in "Shredder" see: man (1) shred
      This is variously incorporated into Graphical file managers in some versions.

      --
      Sig Battery depleted. Reverting to safe mode.
    8. Re:trim/discard by Anonymous Coward · · Score: 2, Interesting

      The solution is simple: Don't power up SSDs. Desolder the chips, read them with your own controller, reconstruct the data. Of course the shit hits the fan when the controller applies encryption and stores the key in the controller itself where it cannot be read from the outside.

    9. Re:trim/discard by Anonymous Coward · · Score: 2

      The bigger problem with flash memory is that you can't erase just a 4K block of data. Flash memory is arranged in bigger blocks and these bigger blocks can only be erased in one piece. If you need to change just one byte in for example a 128K erase unit, then you need to read the whole erase unit into RAM, change the byte there, zap the erase unit and write the data from RAM back to flash. What SSDs do instead is write the modified 4K block to an empty erase unit and note the location of the data in a separate map. The old 4K block still exists, but the drive knows that it is no longer in use. Periodically the drive collects the remaining in-use blocks from erase units with many "abandoned" blocks and writes them to other erase units, thereby freeing the old erase unit which can then be zapped. This "write elsewhere" strategy means that SSDs can't be erased reliably, even when the operating system makes copious use of TRIM.

      The article is about a more aggressive garbage collection strategy, where the drive reads NTFS metadata to identify blocks that aren't in use. This makes many more erase units candidates for garbage collection, and without having to write data to other parts of the flash memory. The drive preemptively zaps the collected erase units. This is a very quick process if you don't need to read them first, i.e. if you know that the whole erase unit is no longer in use. A quick format in Windows thus clears almost the whole SSD in a matter of minutes. It only leaves blocks which (due to wear leveling) currently happen to be located in erase units that also have blocks which are marked in-use in the NTFS metadata structures.

    10. Re:trim/discard by graeme_ssd · · Score: 5, Informative
      Hello there,

      "The drive, however, doesn't know any of this. It updates the requested sectors representing the directory and volume info, and that's about it. It has no idea that blocks somewhere else on the drive are no longer needed, so it will dutifully copy and maintain that data while rewriting blocks."

      Actually, this is no longer correct. SSDs (such as the one in this study) are quite capable of examining the filesystem stored on the drive, independently, and the concept of 'dutifully' and ignorantly maintaining deleted data goes out of the window as a result.

      The main point of the paper is not that this 'analyse-and-purge' drive GC behaviour happens (which is well known among SSD enthusiasts), but that it fouls up long-accepted court and forensics assumptions about what computer drives are. It can result in loss of evidence (of guilt or innocence) very easily in court cases in a manner which might be incorrectly attributed to malicious human intention.

      Graeme.

    11. Re:trim/discard by Andy+Dodd · · Score: 2

      "Actual erasing things would slow down your computer quite a bit."
      True for spinning magnetic hard drives. Not true for SSDs with some idle time to erase unused blocks in the background due to how flash memory works. Hence the creation of the ATA TRIM command, which lets the OS inform the SSD that a block is no longer being used.

      --
      retrorocket.o not found, launch anyway?
    12. Re:trim/discard by graeme_ssd · · Score: 5, Informative
      Hey there -

      Yep, it's the answer that immediately springs to mind when you approach the problem as a techie, and we touched on in the paper (see point 16, page 13).

      Keep in mind though that this is extremely non-trivial - e.g. not many court officers will know how to do it - and that a court may have real trouble with a forensics guy telling them that for 'this particular case', they need to not use the standard procedure to preserve the data unmodified, but instead to rip open the disk and muck about with how it processes data.

      Courts have accepted practices that are used worldwide; what you propose is not accepted practice; therefore courts will have a problem, at least in the short term.

      Also, given the number of variations of controllers and firmware out there too, I'm sure you'll agree there's tremendous potential for a court forensics officer to get it wrong and accidentally nuke the drive data. e.g. how do you find out which firmware was in use, without powering on the drive (which activates the GC)...

      Graeme.

    13. Re:trim/discard by mlts · · Score: 2

      The problem is with desoldering chips, the defense can state that the drive was completely mangled by the prosecution that there is no proof that the data has not been fabricated.

      This is why in conventional forensics, there is a rule about using a hardware write blocker and make an image before going anywhere else. Otherwise, a good defense attorney could get the case thrown out of court.

      How this can be solved? Who knows. There is always a tug-of-war underway between one group that wants unfettered access to data for law enforcement reasons, and another group just as powerful that wants to be sure that destroyed data stays that way so secrets do not end up leaked.

      Who will win is anyone's guess. Most likely SSDs will be sold as two different models... "consumer" models which are cheap and pretend to delete data, versus "enterprise" models which ensure that bits are scrubbed pronto.

    14. Re:trim/discard by graeme_ssd · · Score: 4, Informative

      "On the SSD, the TRIM command caused the device's firmware to wipe the entire device." Close, but not exactly right. Here, the drive's firmware undertook the operation by itself using a NTFS-aware garbage collector; no ATA TRIM command from the PC was needed. We used a non-TRIM OS for just this reason. Graeme.

    15. Re:trim/discard by Kjella · · Score: 1

      Once the disk learns the blocks are unused, I would think yes. It'd be strange if the OS differentiated between blocks it knows are free through GC or is told are free through TRIM. However, the problem they talk about would not happen. With a write blocker - which I assume can be extended to a TRIM-blocker - no commands are issued so nothing is cleared after the forensics take over. Unless the suspect's OS sent a bunch of TRIM commands right before it was cease and there's already a backlog of blocks the disk is aware of should be erased but haven't gotten around to, I suppose.

      --
      Live today, because you never know what tomorrow brings
    16. Re:trim/discard by Andy+Dodd · · Score: 1

      Note: TFA is Slashdotted, so I can't access it.

      Are you sure that the flash drives are actually looking at NTFS datastructures? Due to the proprietary and complex nature of NTFS, this sounds like something drive manufacturers would avoid like the plague. It's highly dangerous, and I would personally avoid any drive that actually did such a thing. (What will it doe if a filesystem other than NTFS is present and it thinks it is NTFS? It's a recipe for epic data-loss firmware bugs on a grand scale that would instantly ruin a drive manufacturer's reputation if they made the slightest mistake in such firmware.)

      Specifically, have you done NTFS delete activities from an OS that *does not support TRIM*. It MUST NOT support TRIM, otherwise you'll have a drive that has a pile of outstanding TRIM commands when you power down the drive and then run your tests on a write-blocked machine.

      Why? Because most likely, a drive is not going to act on a TRIM command immediately if it is busy and a lot of TRIM commands are received (such as someone doing a mass-delete of files). However it will probably write to a datastructure somewhere that it had an outstanding TRIM command (takes far less time to record a list of pages to be erased than to actually erase the pages.) So if a drive receives a pile of TRIMs and is then powered down, when it wakes up it might begin acting on those TRIMs it hadn't taken care of before.

      As others have said, in the case of SSDs, anyone competent is going to bypass the SSD controller and readout the contents of the flash chips directly.

      --
      retrorocket.o not found, launch anyway?
    17. Re:trim/discard by Lorien_the_first_one · · Score: 1

      Thanks for the clarification. You've made this a lot easier for me to follow. There appears to be a lot more maintenance going on at the back end than I thought. But that still leaves the question for me open. Does this mean data recovery is harder or easier? Based on what you're saying there, it'd be harder to recover data after an erase.

      --
      The diversity and expression of human opinion is essential to human survival.
    18. Re:trim/discard by rssrss · · Score: 1

      Is this a problem for John J. Luser? I doubt it.

      --
      In the land of the blind, the one-eyed man is king.
    19. Re:trim/discard by Anonymous Coward · · Score: 1

      SSDs (such as the one in this study) are quite capable of examining the filesystem stored on the drive

      Wait, what? Why should SSDs have to parse filesystems? So now a bug in the SSD firmware's filesystem parser means it could chuck data if it mistakenly thinks the data is deleted?

    20. Re:trim/discard by Lorien_the_first_one · · Score: 4, Insightful

      Wow. Thanks for dropping by. That's one thing I really enjoy about slashdot - seeing an author come by to post a clarification. Indeed, that really helps me to understand the process better.

      --
      The diversity and expression of human opinion is essential to human survival.
    21. Re:trim/discard by afidel · · Score: 1

      Harder some period after erase IF the drive and OS support TRIM. Easier immediately after a secure erase because there is currently no such concept on an SSD currently. I expect that you will see a SCSI extension for secure block erase that enterprise class drives will obey to alleviate the fear for enterprises and governments about recoverable data existing, whether that will make it into consumer class drives using SATA is anyones guess.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    22. Re:trim/discard by BenEnglishAtHome · · Score: 2

      ...real trouble with a forensics guy telling them that for 'this particular case', they need to not use the standard procedure to preserve the data unmodified, but instead to rip open the disk and muck about...

      If such becomes accepted practice, I imagine the demand will go up for drives that are designed to frustrate exactly that sort of approach. I use Flagstone drives that are designed to resist such attacks.

    23. Re:trim/discard by marvinglenn · · Score: 1

      Are you sure that the flash drives are actually looking at NTFS datastructures? Due to the proprietary and complex nature of NTFS, this sounds like something drive manufacturers would avoid like the plague.

      Linux now has decent NTFS support. That lead me to believe that anyone who wanted to implement these GC routines would have enough (indirect) documentation of NTFS internals to do such.

      --
      The whores get mad when the sluts give it away for free.
    24. Re:trim/discard by im_thatoneguy · · Score: 1

      I would imagine they can parse filesystems so that they aren't dependent on OS support. A dumb drive will probably be nice once the OS support is complete and consistent--until then one way to ensure your drive works well with every system is to implement an extra layer of logic.

    25. Re:trim/discard by nuckfuts · · Score: 1

      It used to be fairly common for SCSI drives to have a read-only jumper. From a law enforcement perspective, it sounds like SSD's need a switch to disable writing. If this issue causes problems in enough court cases, it wouldn't surprise me if governments tried to make such a switch mandatory.

    26. Re:trim/discard by Anubis350 · · Score: 1

      Agreed with Lorien_the_first_one, I had assumed this was TRIM, thanks for the clarification - best part about /. :-D

      --
      "goodbye and hello, as always" ~Prince Corwin, from Zelazny's Amber series
    27. Re:trim/discard by Anonymous Coward · · Score: 1

      Actually, this is no longer correct. SSDs (such as the one in this study) are quite capable of examining the filesystem stored on the drive,

      This is very scary. Drives should be OS-agnostic. A drive that doesn't understand the latest variant of ext* or zfs or whatever and starts erasing your data as soon as you write it is ... wow.

      Maybe this is the next big Microsoft push. Get manufacturers of computers sold with Windows to build systems that are not just hard to run Linux on, but actively hostile to any Linux file systems.

    28. Re:trim/discard by ladoga · · Score: 1

      Have you tried this with any other filesystems (such as ext4) or is the built in GC only aware of NTFS?

    29. Re:trim/discard by Megane · · Score: 1

      Actually, this is no longer correct. SSDs (such as the one in this study) are quite capable of examining the filesystem stored on the drive, independently, and the concept of 'dutifully' and ignorantly maintaining deleted data goes out of the window as a result.

      I think that would depend on which filesystem you used. I would be surprised if these days they didn't recognize FAT and FAT32, which have relatively simple allocation mapping, and are what almost always gets used on flash drives. And it should be reasonably possible to recognize HFS+, since it uses a simple bitmap to identify free blocks. NTFS may be possible, but the lack of a proper specification wouldn't help. In any case, a flash drive can't recognize any completely new filesystem that was invented after it was manufactured. Or even the lack of a filesystem, in the case of using it as a raw device for tar-style backups.

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    30. Re:trim/discard by sjames · · Score: 1

      Snooping NTFS is only an advantage if (obviously) the device is used with NTFS and if the OS does not send TRIM commands every time it should (or at all for older OSes). Otherwise you get the same result either way. From the standpoint of evidence gathering and forensics, the NTFS snooping is only relevant in that it makes it even more likely that the device will have erasures scheduled.

      The part they have a hard time wrapping their heads around is that SSDs are active devices that will schedule block erasure and move unerased blocks around as they see fit any time they are powered. They are used to using special connections that filter all write commands out so they can make a copy for analysis while proving that the drive's state is the same as it was when seized. Those won't work anymore.

      The second problem for them is that while SSDs make it harder to be CERTAIN that data is truly erased, they make it much more likely that no longer allocated data has been erased.

      The third problem is that when that data IS erased, they can no longer even infer that it was a deliberate act by the user and so it no longer implies the user's guilty knowledge.

    31. Re:trim/discard by jbolden · · Score: 1

      -

      So you can imagine... a forensic investigator takes an image, examines it, presents it to the court, and when the court verifies the original disk that the copy was taken from, nothing is there any more, and the forensic investigator seems to be making it all up....

      Not if they submit raw data to the court. That image in raw data will show that the drive would have been garbage collecting as the image was being taken. Drives become more like biological specimens. There are multiple biological processes that occur in dead bodies, when an autopsy occurs can change what would have been found.

      Partially the problem is that there are so many levels in computer systems and end users think at very high levels of abstraction.

      I agree though your finding is very important.

    32. Re:trim/discard by jbolden · · Score: 1

      Do you think anyone is going to do that except for maybe terrorism investigations?

    33. Re:trim/discard by drsmithy · · Score: 1

      Actually, this is no longer correct. SSDs (such as the one in this study) are quite capable of examining the filesystem stored on the drive, independently, and the concept of 'dutifully' and ignorantly maintaining deleted data goes out of the window as a result.

      This would be an exceptionally stupid mis-feature for a drive vendor to implement, and hence I have a great deal of difficulty believing it is true. Do you have a source ?

    34. Re:trim/discard by drsmithy · · Score: 1

      True for spinning magnetic hard drives.

      Actually it's equally true for traditional hard disks. They have plenty of idle "cycles" that could be used to erase specific blocks.

    35. Re:trim/discard by maxwell+demon · · Score: 1

      And then someone puts another file system on it.

      A drive making assumptions about the data on it IMHO is a bad idea. Either it has a high-level interface and manages all the low level structures by itself. Or it lets the OS manage the low level structures and doesn't try to interpret it by itself. But please, nothing in between.

      What if tomorrow Microsoft makes an extension to NTFS which causes previously unused blocks to be used for a new feature, but in a way that the algorithm on the drive won't detect it? If it's not a very popular drive, it might not get noticed until the new version is out, and then users start get mysterious failures ...

      --
      The Tao of math: The numbers you can count are not the real numbers.
    36. Re:trim/discard by drsmithy · · Score: 1
      Apologies. After RTFA it looks like this drive actually is basing its behaviour off digging into the filesystem.

      Wow. Which brave soul wants to be the first to put a few of these into a RAID array and watch them slowly self-destruct ?

    37. Re:trim/discard by lgw · · Score: 1

      So now a bug in the SSD firmware's filesystem parser means it could chuck data if it mistakenly thinks the data is deleted?

      An SSD with a firmware bug could devour your data regardless of the developer's intentions. If you don't trust the firmware 100%, don't put anything important on the drive.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    38. Re:trim/discard by julesh · · Score: 1

      Maybe it's still there if you look with a microscope but who really does that?

      The forensics team mentioned in TFS?

      Most of the time, they don't bother. Disassembling your SSD and mounting it to be examined in an electron microscope is an expensive, time-consuming process. I don't know how much it would cost, but I know the equivalent operation for a hard disk is actually so expensive and unreliable that police forces effectively never use it: there are no guarantees of results, and with modern disks being so large the chance of finding enough of a (probably quite small) chunk of incriminating data to be useful is very low. AIUI no documented examples of such a technique having been performed in the real world actually exist (at least more recently than the 1980s, when disks were smaller, gaps between cylinders much larger, and the data you're looking for much more likely to be unencrypted plain text). I also believe that recovery of overwritten data in flash memory is more expensive and probably even less reliable.

    39. Re:trim/discard by cabraverde · · Score: 1

      SSDs (such as the one in this study) are quite capable of examining the filesystem stored on the drive, independently, and the concept of 'dutifully' and ignorantly maintaining deleted data goes out of the window as a result.

      Is there a list of SSDs that do this? I want to be sure I never accidentally buy one, or even get misled by marketing material based on such a terrifying 'optimisation'.

      I already got burned with a Corsair Flash Voyager USB stick whose controller would slow down to the point of timing out out if you modified the pre-formatted partition table (this bug). Annoying, but at least it's not trashing parts of the disk because it thinks it's seen an NTFS partition.

    40. Re:trim/discard by graeme_ssd · · Score: 1
      Hey,

      Thanks for your comments.

      "That image in raw data will show that the drive would have been garbage collecting as the image was being taken."

      Keep in mind the established court procedure to verify if an investigator's image (and finding) is valid, would be to e.g. run an MD5 over the original disk with a write blocker attached in front of defense and prosecution. That will show 'no match', and by precedent the investigator's copy and findings (not the original) will become devalued, practically to zero.

      Also, how could a forensic investigator show a court that his image 'really' was the original version?

      There's no authoritative copy representing the data at time of capture to refer to any more, if the original was being modified as he took the copy.

      Graeme.

    41. Re:trim/discard by graeme_ssd · · Score: 2
      Andy: Note: TFA is Slashdotted, so I can't access it.

      Mirror'd it here for you Andy.

      http://graemebell.net/downloads/JDFSL-V5N3-Bell.pdf

      Graeme.

    42. Re:trim/discard by graeme_ssd · · Score: 1
      "Thanks for dropping by."

      You're welcome, it's great to hear people's thoughts about our work and to have the opportunity to get the message out about this result to a wider audience.

      Graeme.

    43. Re:trim/discard by graeme_ssd · · Score: 1

      "Is there a list of SSDs that do this?"

      P64 Corsair and OCZ vertex 2 are known to have GC ; it's probably worth checking firmware notes for any drive you're thinking of buying.

      Graeme.

    44. Re:trim/discard by jbolden · · Score: 2

      Also, how could a forensic investigator show a court that his image 'really' was the original version?
      There's no authoritative copy representing the data at time of capture to refer to any more, if the original was being modified as he took the copy.

      There won't be, that was my point with the analogy to a biological specimen. The laws regarding hard drives will become much closer to the laws regarding biologicals which can alter themselves between collection and trial, and can be altered by the investigative process.

      There is no more "original version". There is the version that was analyzed in the lab, and maybe a stable version that gets created several hours into the lab process. Much less can be known. This is why I agree your insight is really key, computers are having more and more daemons which are engaging in activities independent of humans. Desktop forensics is slowly becoming more like server forensics where there aren't standard procedures.

      As an aside, I read your ending comments in the paper I agree with all except the issue of hybrids. I'm not so sure the hybrid presents a problem for you. The data in the SSD cache can be essentially ignored, as it will likely be a
      1) read only copy of some of the data on the drive.
      optionally: 2) some short term writes

      If it is just (1) then just look at the magnetic drive and ignore the SSD the same way you would ignore ram on the controller card. If (2) is present, do the analysis simply looks at the magnetic disk only after flushing the SSD back to magnetic.

      So in short the forensic analyst is capable of reporting what was in the filesystem at the time of capture but not what was on the physical disk.

    45. Re:trim/discard by graeme_ssd · · Score: 2

      "The laws regarding hard drives will become much closer to the laws regarding biologicals which can alter themselves between collection and trial, and can be altered by the investigative process."

      I agree, that's one way it could go; other options might include 'ignorance is bliss, except for defendants' and 'attempt to legislate ineffectively against a moving target'.

      Broadly speaking, I think a can of worms will be opened in the next few years in regard to the legal idea of volition and intention, as computers increasing come under the control of viruses, self-repairing computer systems and so on (this is arguably an example of a self-repairing system).

      Graeme.

    46. Re:trim/discard by Darinbob · · Score: 1

      How would it do this without maintaining firmware for all possible types of file systems? I can imagine that it does this for simple FAT16 or FAT32, but I doubt they deal with NTFS or EXT3 or HFS.

    47. Re:trim/discard by Darinbob · · Score: 1

      Most good SSDs will do GC, but that's not the same as proactively deciding that they know what your file system is and which blocks are free or not.

    48. Re:trim/discard by graeme_ssd · · Score: 3, Informative

      "How would it do this without maintaining firmware for all possible types of file systems?"

      It wouldn't. But, how many different filesystems are in realworld use on 95%+ of systems? HFS+, ext2/3, NTFS, FAT32?

      I can imagine that it does this for simple FAT16 or FAT32, but I doubt they deal with NTFS or EXT3 or HFS.

      It does work on NTFS, and if you set up an experimental rig similar to the one we describe at the back of the paper (page 16), hopefully you can satisfy your doubts :-)

    49. Re:trim/discard by Darinbob · · Score: 1

      Hmm, apparently some drives actually do this for NTFS... It sounds silly to me, but maybe they feel it's important enough that they can make it work for only one OS. They'd also have to have a strong partnership with Microsoft just to prevent breakage due to undocumented features or future changes.

      I presume this is done only on large SSD devices, not not just simple thumb drives or Compact Flash (even those do erasing in the background).

    50. Re:trim/discard by Darinbob · · Score: 1

      It seems odd that this happens so quickly and so thoroughly. I'm so much more used to the "lazy" approach to GC or file system management, rather than this proactive approach. Why erase as much as you possibly can as soon as you can when it's impossible to fill the SSD back up that quickly? I can see maybe aiming for a heuristic of keeping maybe 10% of the blocks freed up.

      Maybe the reason is because these have external processors so that no resources are lost by being proactive. Thus you can constantly be running the garbage collector without impacting performance. Maybe it hurts power, but I've rarely seen PC products pay any attention at all to power consumption.

      The side effect here is that this interferes with some file system operations we've taken for granted over the years. Such as being able to recover data, undelete files, etc. It could potentially interfere with future file system changes as well if they're incompatible with the SSD's logic.

    51. Re:trim/discard by geminidomino · · Score: 1

      21 years of Windows and you have trouble believing vendors will intentionally implement stupid misfeatures? :)

    52. Re:trim/discard by David+Jao · · Score: 1

      Actually, this is no longer correct. SSDs (such as the one in this study) are quite capable of examining the filesystem stored on the drive, independently, and the concept of 'dutifully' and ignorantly maintaining deleted data goes out of the window as a result.

      What you're describing is impossible. It might be possible for some of the more common filesystems, such as FAT or NTFS (although, given the difficulty of supporting NTFS in Linux, I highly doubt that embedded firmware on a drive can parse the NTFS format). It is utterly impossible in the case of new filesystems. Think about it -- if a piece of hardware predates the creation of ext4, or ext5, or whatever, then how can the hardware understand the filesystem?

    53. Re:trim/discard by sl149q · · Score: 2

      De-soldering and accessing the flash directly would allow access to flash sectors that where previously used, and are currently on the list of sectors available for erasing but that have not yet been erased. These are the sectors that a good GC in the SSD firmware will quickly erase as long as power is available.

      Also erasing is done in pages which contain multiple sectors. So a previously used sector that is free to recycle may remain unerased if the GC algorithm does not consider the page it is in a suitable candidate for recycling (e.g. if most of the other sectors are still in use.) So in this case these sectors may be available for forensic analysis if the chips are removed and mounted into a new controller.

      It would be a simple modification to the SSD firmware to fix this. Erasing sets all of the bits in a sector (e.g. all zero.) You can change those bits by writing to them (e.g. changing 0 to 1). But you cannot change back (e.g. 1 to 0) without erasing again. But you CAN effectively and quickly remove any information content in a sector that is no longer needed simply by writing to it again changing all remaining bits (e.g. so a byte might change from 0x00 to 0x10 for the initial write of data to a sector and then from 0x10 to 0xff to remove the information content while waiting to be erased.)

      This change would make any and all freed sectors immediately (as of when released) unusable and unreadable even if a well armed attacker could physically remove the chips and analyze directly through his own controller. The cost is low as a simple write to a sector is reasonably fast (unlike an erase.)

    54. Re:trim/discard by graeme_ssd · · Score: 1

      Hey,

      "What you're describing is impossible. It might be possible for some of the more common filesystems"

      You seem to have changed your mind rather quickly there?

      given the difficulty of supporting NTFS in Linux, I highly doubt that embedded firmware on a drive can parse the NTFS format)

      Well, if you think I (and the tech support staff on various SSD manufacturers forums) are wrong, you're welcome to buy an SSD and check for yourself. It's not quite as easy as typing 'it's impossible' a bunch of times, but it's a lot more likely to be correct.

      It is utterly impossible in the case of new filesystems. Think about it -- if a piece of hardware predates the creation of ext4, or ext5, or whatever, then how can the hardware understand the filesystem?"

      The same way they added GC to older models of SSD drives where it didn't already exist of course, and the same way they update features on any hardware. You flash the firmware with revised code.

    55. Re:trim/discard by toddestan · · Score: 1

      I actually can believe it. I had first generation Intel X25-M in a Vista system (no trim support in Vista, and the 1st generation Intel drives don't do trim anyway). The drive started having stuttering issues, and would actually get a lot worse when the drive was almost full (less than 1.5GB of space free). I could actually tell when it was time to empty the recycle bin based upon how slow the system was running. It was definitely like the drive was affected by how much free space was left in the filesystem, with the drive really starting to choke when free space was below 1%. The only way that made any sense (in the absence of trim) is if the drive firmware somehow knew about the file system as it went about its internal business, and a file system with a very low amount of free space hindered the ability of the drive to do this. I ended up rejecting that idea, and replaced the drive assuming it was bad (or simply not ready for primetime without trim support), but now I wonder if the drive really could understand the file system...

    56. Re:trim/discard by David+Jao · · Score: 1

      Well, if you think I (and the tech support staff on various SSD manufacturers forums) are wrong, you're welcome to buy an SSD and check for yourself. It's not quite as easy as typing 'it's impossible' a bunch of times, but it's a lot more likely to be correct.

      A SSD that performs automatic garbage collection by interpreting the filesystem in firmware is not, in my opinion, a storage device.

      Suppose I am a filesystem developer. Suppose I want to modify NTFS in such a way that deleted segments of an NTFS disk layout become (in my modified filesystem) a repository for meaningful data. This is not as absurd a concept as it appears. In my line of work (cryptography), storing actual meaningful data in deleted segments might be something that you want to do, for example in steganography.

      If the SSD goes deleting disk sectors behind my back, then it becomes impossible for me to develop said filesystem. A storage device should store what I tell it to store. If it doesn't do that, then it's not a storage device. In this sense, it is, by definition, impossible for a valid storage device to implement automatic garbage collection at the filesystem level. Any device that does such a thing, by definition, does not meet the requirements of a storage device, the primary one of which is to retain data without alteration.

      Sure, those deleted sectors are safe to erase in an NTFS volume, but how do you know that my operating system is using this NTFS volume as an NTFS volume? What if I'm doing steganography or something where those deleted sectors matter?

      The same way they added GC to older models of SSD drives where it didn't already exist of course, and the same way they update features on any hardware. You flash the firmware with revised code.

      Remind me never to upgrade the firmware on any hard drive ever again. I do want TRIM support, but I do not want automatic garbage collection, for the reasons outlined above.

      I will concede that it is possible for a write-only device to implement automatic garbage collection at the filesystem level, but I maintain that no valid storage device can do so, since to do so violates the core requirement of a storage device in a fundamental and unfixable way.

    57. Re:trim/discard by Neil+Boekend · · Score: 1

      It's harder to delete the files, but also harder to read them after "deletion".
      You can't easily remove the bits with a secure erase but since wear leveling scrambles the files into a lot of blocks you can't easily read them either. Unless you can convince the controller to hand over the data (and assuming it actually knows where the data is at) you are going to get a lot of blocks that could assemble into a file, but you don't know how they fit.
      Something like a sandcastle after a high tide. All the parts are there, but they are to small to use them to determine where they belonged and they don't give a clue of themselves. Only with an image of the castle you could recreate it, but then you wouldn't have to.
      Back to bits! The blocks are all there, but you have no clue as to in what order they should go. You could only set them back with a "map" of where they should be, but that's in the controller, or with the original file (which makes the operation kind of useless).
      Please correct me if I am wrong.

      --
      Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
    58. Re:trim/discard by Neil+Boekend · · Score: 1

      Wouldn't disassembling it and scanning it with an electron microscope set all bits to 0?

      --
      Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
    59. Re:trim/discard by Carewolf · · Score: 1

      An USB-pen might do it for only FAT systems since that is defacto standard for pen-drives, but I don't think any hardware actually does that.

    60. Re:trim/discard by HyperQuantum · · Score: 1

      That's one thing I really enjoy about slashdot - seeing an author come by to post a clarification.

      Unfortunately, that doesn't seem to happen a lot (in general).

      --
      I am not really here right now.
    61. Re:trim/discard by graeme_ssd · · Score: 1

      Hi David

      "A SSD that performs automatic garbage collection by interpreting the filesystem in firmware is not, in my opinion, a storage device."

      Well - you can hold any opinion you like, but the physical fact of reality is that this device can and is being used to store things quite safely by millions of people. To use an analogy: would you say that a library that reorganises their shelves and throws out items marked for removal from time to time - but only when there's no one using the library at 3AM in the morning - was not really a reliable repository for information? Because in reality, that's how most libraries work. You might hold the opinion that such a library was not really be an 'information storage facility' because in fact, you were arranging to have some books thrown out in such a way that a secret message was conveyed to the trashman. But 99.9999% of the population would consider the loss of such a peculiar backchannel a reasonable tradeoff, for say, a 3-fold to 10-fold improvement in how quickly they can find things on the shelf - which is of course the primary purpose of a library.

      The analogy is fair, because the disk only runs GC when the disk isn't in use for several minutes; at the OS level we can use write-through caching to ensure there's no logical data left unwritten at this point.

      "Suppose I am a filesystem developer. Suppose I want to modify NTFS in such a way that deleted segments of an NTFS disk layout become (in my modified filesystem) a repository for meaningful data. This is not as absurd a concept as it appears. In my line of work (cryptography), storing actual meaningful data in deleted segments might be something that you want to do, for example in steganography.

      This is so far into being an edge case it's not funny. The phrase 'for example in steganography' is not reasonable here - can you give me 5-10 other examples to demonstrate this isn't a one-off edge case? Steganography seems like the only example I can think of, and as a stego researcher myself (see my site) I can tell you that you won't get much capacity or reliability from rearranging deleted files - the OS will need to use that space for something. I think huge numbers of deleted files or metadata entries that are not being overwritten would stand out a bit to a forensic investigator too, given that the second thing they'll look for is deleted files.

      "In this sense, it is, by definition, impossible for a valid storage device to implement automatic garbage collection at the filesystem level."

      I'm guessing you don't consider networked computers (e.g. SMB shares, FTP sites, NFS mounts) to be storage devices either then, since the remote host will merrily overwrite deleted files with other people's data however it likes there too? Why do you think so many people are willing to use remote hosts to store data when they don't have control over how deleted files are garbage-collected/re-used/arranged below the logical layer?

      "Sure, those deleted sectors are safe to erase in an NTFS volume, but how do you know that my operating system is using this NTFS volume as an NTFS volume? What if I'm doing steganography or something where those deleted sectors matter?"

      What other somethings do you have in mind?

      Thanks for your feedback though, it's interesting to see people's gut reactions to this tech.

      I will be very interested if you can enumerate some more realistic examples of why performance-boosting GC is a bad thing, other than an edge case (NTFS file deletion stegosystem) which, I would expect, does not presently exist as an implementation.

      Graeme.

      p.s. Just thought of another example. RAM. Where you store data in memory logically, and how it is arranged physically - including zeroing of dead pages - are completely out of your control and even out of your view. Does this mean you consider RAM not to be a storage device, since you can't reliably construct a stego side-channel using dead pages of memory?

    62. Re:trim/discard by David+Jao · · Score: 1

      I'm guessing you don't consider networked computers (e.g. SMB shares, FTP sites, NFS mounts) to be storage devices either then, since the remote host will merrily overwrite deleted files with other people's data however it likes there too?

      This is of course a spurious comparison. SMB, FTP, and NFS are presented to the operating system as file trees. A drive with automatic garbage collection is presented to the operating system as a block device ... but it does not actually implement the correct semantics for a storage block device.

      What other somethings do you have in mind?

      It seems that another poster has already enumerated more ways for automatic garbage collection to break.

      p.s. Just thought of another example. RAM. Where you store data in memory logically, and how it is arranged physically - including zeroing of dead pages - are completely out of your control and even out of your view. Does this mean you consider RAM not to be a storage device, since you can't reliably construct a stego side-channel using dead pages of memory?

      Again, RAM is presented to the OS as logical addresses, and it does faithfully restore the data that was stored in those logical addresses.

      A hard drive, like RAM, presents a logical block layer to the OS which is decoupled from the underlying physical data storage. Correct data storage and retrieval is required at that logical block layer. Automatic garbage collection violates the integrity requirements of a hard drive even at the logical layer. It imposes a secondary logical layer which assumes you are using a standard filesystem in a standard way. This introduces an additional and very scary mode of failure: the possibility now exists that the firmware might actively delete certain logical block data without the knowledge of the operating system. Of course, this could happen even with older, regular firmware, but only as an accident--by default, older firmware is programmed to store everything at the logical layer, no matter what it is. Active deletion raises the stakes considerably.

      Honestly, the more I think about this, the more appalled I am that any manufacturer would actually do what you describe. I will be sure to make every possible effort to avoid such drives.

    63. Re:trim/discard by Agripa · · Score: 1

      What happens when I format the drive with a filesystem the SSD doesnâ(TM)t know about? What happens when I use database software that demands raw access to an unformatted drive? Does it just fall back to the âold daysâ(TM) behavior, where the SSD is dutiful and ignorant, or is the SSD âsmartâ(TM) enough to complain and break the system somehow?

      If the drive does not understand the file system, then it can just default to doing garbage collection based on overwritten sectors presumably with some performance loss.

    64. Re:trim/discard by Agripa · · Score: 1

      Some compact flash cards are FAT/FAT32 aware for garbage collection purposes. The Linux/BSD people discovered this when they noticed that they had significantly lower performance with other file systems.

    65. Re:trim/discard by graeme_ssd · · Score: 1

      "This is of course a spurious comparison. SMB, FTP, and NFS are presented to the operating system as file trees."

      This GC only works with NTFS filesystems. If you are operating an SSD device using an NTFS file tree to store data, then you (as a programmer) are not using the drive as a block device as you suggest; you're accessing it (or you should be accessing it) via the abstract file tree.

      "Again, RAM is presented to the OS as logical addresses, and it does faithfully restore the data that was stored in those logical addresses."

      While there is a difference in the semantics that occur when marking a reference to a memory page as free (and subsequently losing access to the data) and marking a reference to file data as deleted, they are essentially the same operation in terms of saying 'I don't need to store this data now'.

      The only difference is that people seem to take block-level access to the disk for granted; we now know with memory that block-level access isn't really a good idea at all, in the interests of protecting memory from accidental or deliberate attempts to misuse it.

      The problem, from my perspective, is that your arguments hinge on the idea that marking data as 'deleted, and the filesystem can now overwrite it at some random future point, perhaps instantly or never' (the HDD model) is in some way better than 'deleted, purge at first opportunity' (the SSD model). From my perspective, I'd prefer the latter; at least then I know what's happened to data after it's been marked for deletion.

      I'm still keen to see those realistic real-world use cases. If another poster has posted them, can you provide a link?

      Graeme.

    66. Re:trim/discard by David+Jao · · Score: 1

      This GC only works with NTFS filesystems. If you are operating an SSD device using an NTFS file tree to store data, then you (as a programmer) are not using the drive as a block device as you suggest; you're accessing it (or you should be accessing it) via the abstract file tree.

      The ATA standard (parallel or serial) does mandate that the drive appear as a logical block device. A drive with an ATA connector must honor that requirement or (IMO) it violates the standard. USB Mass Storage is another example where the standard mandates logical block storage -- what happens if I put one of these defective drives into a USB enclosure?

      The only difference is that people seem to take block-level access to the disk for granted;

      For many non-edge-case applications, like whole-disk encryption (remember, I'm a cryptographer), block-level access is exactly what you need, and anything less is unacceptable.

      I understand that the firmware is supposed to (obviously) ignore non-NTFS volumes and fall back to block storage semantics. But the mere presence of active garbage collection is unwanted to me. It adds another possible failure opportunity.

      The problem, from my perspective, is that your arguments hinge on the idea that marking data as 'deleted, and the filesystem can now overwrite it at some random future point, perhaps instantly or never' (the HDD model) is in some way better than 'deleted, purge at first opportunity' (the SSD model). From my perspective, I'd prefer the latter; at least then I know what's happened to data after it's been marked for deletion.

      The latter can (and should) be implemented with explicit TRIM support. The operating system must have control over purging.

      I'm still keen to see those realistic real-world use cases. If another poster has posted them, can you provide a link?

      Link is here. In short:

      • Lazy conversion from one filesystem to another might involve (re)using the deleted space in ways that the firmware did not anticipate.
      • Defragmenting might use the deleted space.
      • A raw filesystem image might be included as a file inside another filesystem.
      • Some filesystems (like UDF) don't clear NTFS headers upon formatting, and the drive might be confused as to what filesystem is on disk.
      • Microsoft itself might update NTFS in a way that makes use of the deleted space and conflicts with what the drive expects.
    67. Re:trim/discard by graeme_ssd · · Score: 1

      Hey again David,

      I'm not against block level access: I just think that most cases where you mix low level access to dead space with simultaneous filesystem (or page) level access are edge cases - whether it's RAM or disk you're talking about.

      Looking at the 5 suggestions: I asked for realistic, real-world use cases.

      1 - Lazy conversion of filesystems on a single medium using 'dead' space on the disk without creating a temporary filename corresponding to those blocks to cover their ass? This is a 'realistic', 'real-world' use case? Show me a program that does this.

      2 - Defragging: similarly, if you're moving data around in dead space without safely duplicating it or having a filename pointing to the blocks in use at any given time, you're not being careful. Also, which defraggers have random 3-minute gaps in operation that would even allow GC to kick in?

      3 - Raw filesystem image included as a file inside another filesystem: I don't get it - if the blocks for the image are marked as associated with a filename, where's the problem?

      4 - UDF format over NTFS old filesystem. Good point, though I would argue that any UDF formatting tool which leaves in a disk in a state where it could be interpreted ambiguously in terms of it's filesystem, is a broken formatting tool.

      5 - Interesting theoretical idea, but not 'real world'. this is not actually the case and MS are well aware of SSD tech, as seen in the latest iteration of Windows. A problem for the future though, for anyone adding new tricks to the GC.

      Graeme.

    68. Re:trim/discard by David+Jao · · Score: 3, Interesting

      2 - Defragging: similarly, if you're moving data around in dead space without safely duplicating it or having a filename pointing to the blocks in use at any given time, you're not being careful. Also, which defraggers have random 3-minute gaps in operation that would even allow GC to kick in?

      I think it is time to start bringing the discussion to a close, as it appears that we do share at least some common ground.

      I will comment only on this one question. Your implication that the 3-minute rule somehow makes the GC "safe" is missing my point entirely. Yes, in practice there are checks and balances such as you describe, that make the GC unlikely to screw up. But, in my view, "unlikely" is not good enough. I want, and need, perfect (logical) block storage and retrieval. This should and must be the design goal. Of course, this goal is impossible to achieve in practice. For example, if the firmware (such as older, pre-SSD firmware) is designed with the goal of providing logical block storage, but fails in this task because of some honest bug, then I can understand that. At least, in this case, the programming code was written unambiguously with the correct goal (and no other directly conflicting goals) in mind, even if this goal was not achieved in practice due to an unintentional bug.

      However, when a manufacturer deliberately designs firmware with the goal of deleting logical sectors, no matter how well-intentioned or well-implemented, this design goal (by definition) must come into conflict with the original, core goal of reliable (logical) data retrieval. I do not care what happens in the underlying physical layer, but I do care very greatly about data accuracy at the logical layer. The existence of certain checks and balances to prevent data loss is better than no checks and balances, but it is not better than the REAL alternative, namely, firmware that stores and retrieves logical blocks correctly, and is designed for this and only this purpose, without any other directly contradictory design goals.

      No one, not even rocket scientists, has ever succeeded in writing bug-free software. But one should make an effort to minimize the number of opportunities for data loss bugs to arise. Firmware-based logical-sector garbage collection fundamentally and irreconcilably contradicts every reliability design principle known to man. That is why I consider the idea to be so abhorrent.

    69. Re:trim/discard by Bengie · · Score: 1

      "if the original was being modified as he took the copy."

      Quantum! Only a true scientist can read SSDs :P

    70. Re:trim/discard by Bengie · · Score: 1

      Wear Leveling. Any time you modify a sector, the entire block must be read out, modified with the changed sector, and written to a *new* block.

      It's not as much of an issue of needing free blocks to "fill up" the drive, but you need free blocks to even modify data. The more free blocks, the faster the drive runs during writes.

    71. Re:trim/discard by Darinbob · · Score: 1

      True but there's a limit to the number of free blocks you need. If this is a drive that is continually writing overwriting data at full speed then maybe it needs to continually erase blocks, but that's not typical usage. You will hit a limit based on throughput where having extra erased blocks won't improve performance.

  4. Solution is simple, but not easy by Anonymous Coward · · Score: 2, Informative

    You need to disassemble the drive and read the memory chips independently of the controller. I believe I read this is how one of the major drive recovery companies is handling SSDs.

    1. Re:Solution is simple, but not easy by Zerth · · Score: 4, Insightful

      You need to disassemble the drive and read the memory chips independently of the controller.

      Bingo. Forensic tech are used to being able to just plug in a write-blocker and assume the disk will remain intact and unchanged, which is the "legally safe" part they are complaining about. Since SSDs do lots more under the hood than spinning rust drives, they can't guarantee the device is unchanged unless they disassemble it, which might be considered tampering and leaves room for the other side's lawyers to ask "and then you took a soldering iron to a delicate IC?".

      It also requires a lot more know-how than "Use this magic cable when copying drives for investigation".

    2. Re:Solution is simple, but not easy by icebike · · Score: 1

      Not to mention the fact that any method of removing something at the chip level runs a real risk of changing what was in the chip, perhaps destroying any ability to get anything off of it. There is no body of science for safe removal of SSD chips from their board. You might get away with it 9 out of ten times, or once out of a hundred. There simply isn't any data on this. There is nothing that I know of that even specifies if all bits of any given byte are written on the same chip.

      --
      Sig Battery depleted. Reverting to safe mode.
    3. Re:Solution is simple, but not easy by rwa2 · · Score: 2

      Yep, I bet this has a lot to do with money as well. With that write-blocker attached to the drive, you can just use software to clone the disk bits and reconstruct the filesystem and recent deletes.

      Sure it's possible (and more expensive) to do a complete magnetic scan of a disk platter and reconstruct that past few layers of content written (and rewritten) to the drive... the kind of thing that the secure wipe utilities are supposed to defeat with multiple layers of white noise. But I doubt law enforcement really wants or even needs to resort to the time and expense for this all that much.

      Unfortunately, that second level of forensic technology for SSD recovery isn't cheap enough yet :P

      But it's all OK, they're not going to force your SSD manufacturers to disable automatic TRIM!
      -- They'll more likely just use this as justification as to why they simply must be able to log everything going to and from your PC over the net unencrypted ;-)

    4. Re:Solution is simple, but not easy by bluefoxlucid · · Score: 1

      Sure it's possible (and more expensive) to do a complete magnetic scan of a disk platter and reconstruct that past few layers of content written (and rewritten) to the drive... the kind of thing that the secure wipe utilities are supposed to defeat with multiple layers of white noise.

      I bet you believe hard disks have a stream of "1 0 1 1 0 1 1 0 0 0 0 0 0 0 0 1 0..." on them, too...

    5. Re:Solution is simple, but not easy by graeme_ssd · · Score: 3, Informative
      Repeating a comment I made elsewhere on this board:

      -----

      Hey there

      Yep, it's the answer that immediately springs to mind when you approach the problem as a techie, and we touched on in the paper (see point 16, page 13).

      Keep in mind though that this is extremely non-trivial - e.g. not many court officers will know how to do it - and that a court may have real trouble with a forensics guy telling them that for 'this particular case', they need to not use the standard procedure to preserve the data unmodified, but instead to rip open the disk and muck about with how it processes data.

      Courts have accepted practices that are used worldwide; what you propose is not accepted practice; therefore courts will have a problem, at least in the short term.

      Also, given the number of variations of controllers and firmware out there too, I'm sure you'll agree there's tremendous potential for a court forensics officer to get it wrong and accidentally nuke the drive data. e.g. how do you find out which firmware was in use, without powering on the drive (which activates the GC)...

      Graeme.

      p.s. Also keep in mind that data is stored on the chips in a highly non-linear manner; reassembling the logical image may not be easy, since you need to work out how the flash translation layer was being represented. This is getting wildly beyond what a typical court forensics officer is usually trained to do, namely, rip an image of the drive with a write-blocker attached and scan it for jpegs/whatever.

    6. Re:Solution is simple, but not easy by maxwell+demon · · Score: 1

      No, they have a stream of areas magnetized in different directions on them. I think the idea (of which I don't know if it actually works) is that due to hysteresis, the magnetization is not completely reversed when the drive reverses it. That is, where you reversed magnetization, it is actually weaker than where you didn't. That would allow to reconstruct what the magnetization was before the latest rewrite. A bit simplified: Strong N: Is now N, was previously. Weak N: Is now N, was previously S. Weak S: Is now S, was previously N. Strong S: Is and was S. Of course reconstructing past magnetization means reconstructing past data.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    7. Re:Solution is simple, but not easy by bluefoxlucid · · Score: 1

      Hard drives have an analog magnetic waveform on them constructed such that they encode discrete 0s and 1s in the fastest way possible. This means, roughly, that what is on the disk is in some alien language that has no obvious correlation to the data stored on the disk. This is done by varying the magnetic domains on the disk, pointing north/south in some direction or another; although what's actually read from the disk is not directly what's written. It kind of depends on the data already there.

  5. Encrypt your data by rcb1974 · · Score: 4, Insightful

    Problem solved. People need control over their own privacy. Tough luck Digital Forensic folks.

    1. Re:Encrypt your data by greenreaper · · Score: 1

      Yeah, but you can still go to jail for that in the UK, unlike TRIM.

    2. Re:Encrypt your data by Kiaser+Zohsay · · Score: 1

      So either SSDs are really hard to erase, or really hard to recover. I'm so confused.

      It is really hard to prove that data from SSDs was really deleted, and it is also hard to prove that data from SSDs was really not deleted.

      --
      I am not your blowing wind, I am the lightning.
    3. Re:Encrypt your data by beelsebob · · Score: 1

      That article was bunk. The correct way to get an SSD to erase something properly is to "trim" the data – i.e. tell the SSD that the cell is no longer needed. This (a) causes the SSD to erase it so that the next write cycle is faster, and (b) lets the SSD know it can overwrite that cell without explicit instructions from the OS, which allows it to wear level better.

      What the people in that article did instead was try to write over data with crap. The SSD then did a good job of wear levelling and instead of overwriting what was previously there wrote to a totally different cell, and updated it's map of what was where.

      Basically, they decided to use a technique designed for erasing hard disks, and discovered it didn't work very well for erasing SSDs. Meanwhile, the correct technique for erasing SSDs leaves law enforcement of other people trying to recover data totally befuddled.

    4. Re:Encrypt your data by Anonymous Coward · · Score: 1

      Schrödinger's Disk.

    5. Re:Encrypt your data by tibit · · Score: 1

      IOW, if you TRIM over the whole medium, you're guaranteed that the drive will physically erase everything in short order. That's good, isn't it?

      --
      A successful API design takes a mixture of software design and pedagogy.
    6. Re:Encrypt your data by Firehed · · Score: 1

      What the people in that article did instead was try to write over data with crap. The SSD then did a good job of wear levelling and instead of overwriting what was previously there wrote to a totally different cell, and updated it's map of what was where.

      I don't see why this would be less effective on an SSD than on magnetic media - assuming, of course, you're doing a multi-pass overwrite. My hard drives contain sensitive information, so they get the DOD-spec 7-pass overwrite when that special time comes (although the info is encrypted to start, so the risk is minuscule to start). Sounds like zeroing out the drive alone isn't enough (until TRIM does its thing), but is there any reason that completely overwriting the drive wouldn't work on an SSD?

      I assume the procedure you're referring to is simply overwriting the original sectors, rather than the entire drive.

      --
      How are sites slashdotted when nobody reads TFAs?
    7. Re:Encrypt your data by Jonner · · Score: 2

      This property of modern SSDs is neither positive nor negative by itself. It's a property you'd be thankful for if you were organizing protests in Iran and stored contacts on an SSD. You'd curse it if it were exploited to destroy incriminating photos by someone who'd stalked you or a loved one.

    8. Re:Encrypt your data by larry+bagina · · Score: 1

      I don't know about the UK, but you can got to jail for underage trim in the US. "Underage" varies by state.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    9. Re:Encrypt your data by graeme_ssd · · Score: 1

      "This property of modern SSDs is neither positive nor negative by itself. It's a property you'd be thankful for if you were organizing protests in Iran and stored contacts on an SSD. You'd curse it if it were exploited to destroy incriminating photos by someone who'd stalked you or a loved one."

      Exactly right, Jonner.

      Graeme.

    10. Re:Encrypt your data by jbolden · · Score: 1

      Both. OS level command can't induce erases and erases can occur without OS level intervention. SSDs are more independent.

    11. Re:Encrypt your data by jbolden · · Score: 1

      You are missing the point. The point is that the TRIM can change the state of what is on the disk without further intervention from the computer. So a hard drive that gets removed from a computer will continue to act on a TRIM command when powered back up.

    12. Re:Encrypt your data by beelsebob · · Score: 1

      I don't see why this would be less effective on an SSD than on magnetic media - assuming, of course, you're doing a multi-pass overwrite.

      Because an SSD controller continuously remaps what address maps onto what physical cell in order to keep wear level across all cells. So by writing crap at an address you are not necessarily writing crap over the last thing you wrote at that address. By trimming the address, you do however tell the SSD that it should erase that data ready for fast writing next time.

    13. Re:Encrypt your data by beelsebob · · Score: 1

      There's no point-missing going on here – I'm saying that trim will indeed erase properly, but that "overwriting" data will not necessarily actually overwrite as the SSD controller may well decide to use a different cell for the same address.

    14. Re:Encrypt your data by jbolden · · Score: 1

      That's not a problem. The issue is (ignoring all the details)

      -- The courts currently assume drives stay in a static state once disconnected from a computer
      -- Forensic computers don't alter that static state for HDDs
      -- That static state doesn't exist for SSDs.

    15. Re:Encrypt your data by beelsebob · · Score: 1

      The courts don't need a guarantee of the data being static – they need a guarantee that no data will be added to the drive. TRIM has known semantics – it slowly turns cells to 0. It's removing data, not adding it.

    16. Re:Encrypt your data by jbolden · · Score: 1

      Actually the courts right now are concerned with added or deleted. Often the question is was evidence deliberately destroyed. There is a crime called "spoliation of evidence" for deleting stuff you think law enforcement is likely going to want. Deleting files on computers are often how this sort of things is proven. But with garbage collection it might be very hard to prove whether the deletion occurred because the evidence of that got deleted. On a typical HDD a wipe would generally be pretty powerful evidence of an intent to spoil evidence.

      Worse, the courts do need to be able to show that forensics lab didn't change the data. Taking a checksum of the disk and comparing that to the checksum if the image handed to the defense.... But now that's not possible, at least if you include any sort of "deleted" files.

    17. Re:Encrypt your data by yoshi_mon · · Score: 1
      --

      Really, I know what I'm doing...Ohhhh, look at the shiny buttons!
  6. Will be fixed by a new law. by Anonymous Coward · · Score: 1

    Next, expect law enforcement to clamor for a new law that mandates persistent data retention for all types of storage devices.

    1. Re:Will be fixed by a new law. by Anonymous Coward · · Score: 1

      What data officer?

    2. Re:Will be fixed by a new law. by treeves · · Score: 1

      Federal data officers, state data officers, county data officers, all of 'em.

      --
      ...the future crusty old bastards are already drinking the Kool-Aid.
    3. Re:Will be fixed by a new law. by RavenLrD20k · · Score: 1

      I think the AC actually meant to have a comma in there...as if to say:

      "What data, Officer?"

      implying the "play stupid, stupid" maneuver.

  7. When it absolutely, positively, has to be.. by NevarMore · · Score: 2

    ..destroyed overnight, go with the SSDs. The melting point of a surface mount IC is a lot less than that of a spinning platter.

    1. Re:When it absolutely, positively, has to be.. by joeytmann · · Score: 1

      I like hammers, no melting point required.

      --
      Insert funny smart-ass comment here.
    2. Re:When it absolutely, positively, has to be.. by Ziest · · Score: 1

      Yes but thermite is so much fun to play with.

      --
      Another day closer to redwood heaven
    3. Re:When it absolutely, positively, has to be.. by boristdog · · Score: 1

      .357 at 10 yards does it for me.

    4. Re:When it absolutely, positively, has to be.. by MonsterTrimble · · Score: 1

      And you have had reason to do this?

      --
      I call it 'The Aristocrats'
    5. Re:When it absolutely, positively, has to be.. by nolife · · Score: 2

      Only criminals are worried about protecting their personal data.
      Only criminals have guns.

      If you have both, you should go to jail without a trial just because.

      --
      Bad boys rape our young girls but Violet gives willingly.
    6. Re:When it absolutely, positively, has to be.. by St.Creed · · Score: 1

      Khadaffi, is that you?

      --
      Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
    7. Re:When it absolutely, positively, has to be.. by JWSmythe · · Score: 1

      ... and amazingly easy to make at home. It doesn't even leave a trail of unusual purchases. :)

          It could become rather messy if you had it attached to a case intrusion sensor, or it was accidentally set off. It's all fun and games 'til you burn your house down.

          Someone was describing to me what they had planned for the ultimate in intrusion proof media.

          The drive was to be encrypted with AES-256, with a few other features. It was to be mounted with shock protection inside a 1.5 cu/ft safe. The safe was to be encased in 12" of steel reinforced concrete on all sides. Around all that, would be 1" steel plate welded. The only thing that would be sticking out would be a USB cable (he forgot to mention the power cord). He was sure it was the ultimate in security. You couldn't ever get close to the drive to do forensics.

          I pondered that for a moment. Then I countered with "So, I'd torture you, until you gave me the encryption key. I'd have all the time necessary. You'd need food, water, and medical attention within 2 weeks." Torture, where the final disposition of the subject is not very important, can get really swift results. Most people have a pretty good survival instinct, and they'll tell you everything within the first few minutes.

          I didn't feel like offering up the fact that the case could be opened without damaging the contents. A torch may work on the outer skin. Saws and other assorted cutting tools would make quick work of the remainder. But who was I to ruin his perfectly good idea with facts. :)

      --
      Serious? Seriousness is well above my pay grade.
    8. Re:When it absolutely, positively, has to be.. by drinkypoo · · Score: 1

      If it's a laptop disk you can power it from USB2 with a $10 dongle, so long as it's ATA. With SATA you need a fancier adapter.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    9. Re:When it absolutely, positively, has to be.. by Fulcrum+of+Evil · · Score: 1

      Well, that's what a duress code is for. If you're feeling plucky, give out the wrong code and the drive triggers the 10mg of thermite over the SSD chips. With the right sort of engineering, the outside won't even get warm, and the chewy SSD center just stops responding. Of course, they might decide to torture you to death for pissing them off, but the data's forever beyond saving.

      --
      "We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
    10. Re:When it absolutely, positively, has to be.. by Darinbob · · Score: 1

      And you have had reason to do this?

      Because Jamie likes a big boom!

    11. Re:When it absolutely, positively, has to be.. by JWSmythe · · Score: 1

      ... Of course, they might decide to torture you to death for pissing them off, but the data's forever beyond saving.

          I think you have it just about right there. If someone wants it bad enough, and the entire purpose of keeping you alive is to give up the code, once you've rendered the device useless, you've become useless too.

          What could be so important on the disk? If you're a billionaire (or his accountant), it could be all the details of your bank account(s). If you give it to them, you may live, but you won't have most of your money. If you don't, you'll end up dead, and they've lost nothing other than a bit of time. Unless, of course, it's a Hollywood-esque kidnapping, and then they've spent a fortune on armored cars, helicopters, and exotic equipment that wouldn't work in real life. :)

      --
      Serious? Seriousness is well above my pay grade.
    12. Re:When it absolutely, positively, has to be.. by Enigma23 · · Score: 1

      ..destroyed overnight, go with the SSDs. The melting point of a surface mount IC is a lot less than that of a spinning platter.

      Surely putting either in a microwave oven and turning it on would suffice?

      --
      Ceci n'est pas une .sig
    13. Re:When it absolutely, positively, has to be.. by Fulcrum+of+Evil · · Score: 1

      I was thinking that the main thing I'd do that for would be protecting operational intelligence - if the info was something like a NOC list, then I'd take the hit. Of course, I'm in no position to be protecting anything like that, so yeah. Best strategy is for the adversary to not know I have whatever they want.

      --
      "We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
  8. Well... by Minwee · · Score: 4, Insightful

    So either SSDs are really hard to erase, or really hard to recover. I'm so confused.

    All I know is that if SSDs were really hard to erase, and I was in the business of recovering data that other people didn't want recovered, this is exactly the kind of story that I would tell them so that they would continue using SSDs.

    Not that I'm paranoid or anything.

    1. Re:Well... by EasyTarget · · Score: 3, Insightful

      What wear levelling gives with one hand (performance and life) at the expense of the OS never knowing in which memory cell the data has -actually- been stored; making targeted deletion runreliable..

      ..it takes back with the other; deleted files will begin to be overwritten very rapidly when new data arrives; whatever the OS thinks about it, data recovery, even using specialist tooling, will struggle to get complete files or metadata from the media if the drive has seen some real use after the data was deleted.

      and, most importantly:

      $ cat /dev/urandom >> /dev/ssdX

      Just needs to be run once to -really- bollox an investigation..

      --
      "Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
    2. Re:Well... by TheCyberShadow · · Score: 1

      As opposed to HDDs, which aside from being comparatively slow, supposedly allow recovering information after it's been overwritten multiple times?

    3. Re:Well... by 0123456 · · Score: 1

      As opposed to HDDs, which aside from being comparatively slow, supposedly allow recovering information after it's been overwritten multiple times?

      If you're still using a 20MB hard drive from 1993, perhaps.

      Given how hard current drives have to work to recover information that _hasn't_ been overwritten, you can be pretty sure that no-one's going to be recovering information which has.

    4. Re:Well... by The+Wild+Norseman · · Score: 4, Funny

      What wear levelling gives with one hand (performance and life) at the expense of the OS never knowing in which memory cell the data has -actually- been stored; making targeted deletion runreliable..

      Ruh-roh, Raggy! It's runreliable!

      --
      "A government is a body of people usually -- notably -- ungoverned." -Shepherd Book
    5. Re:Well... by imagoon · · Score: 1

      Issue is you will not urandom the spare space. In an example SSD that may have say 50GB of 64GB available, you still have up to 14GB of "something" out there even with the disk urandomed to full. Sure it will mess up the investigation but you really have no idea what 14GB is sitting in there.

    6. Re:Well... by graeme_ssd · · Score: 5, Interesting
      Hi, I'm one of the authors of the research (Graeme).

      It's a good joke, but with a grain of truth in it. If you're concerned, you can buy the drive we used, flash it to the firmware we used, (optionally) buy a write blocker if you like, and run the programs I placed at the back of the paper and see what happens. We carefully documented as many of the experimental setup parameters as we could so it should be possible to reproduce the results exactly.

      Skepticism is a good thing - so I hope you'll reproduce the experiment at home and tell the world afterwards if you still think we're running PsyOps for the forensics community :-)

      Graeme. p.s. I'm currently looking for a postdoctoral/research engineer/research scientist position in Grenoble.

    7. Re:Well... by EasyTarget · · Score: 1

      6 seconds of confusion followed by a minute of laughter.. rankyou!

      --
      "Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
    8. Re:Well... by mdielmann · · Score: 1

      So either SSDs are really hard to erase, or really hard to recover. I'm so confused.

      All I know is that if SSDs were really hard to erase, and I was in the business of recovering data that other people didn't want recovered, this is exactly the kind of story that I would tell them so that they would continue using SSDs.

      Not that I'm paranoid or anything.

      Here, have a sig.

      --
      Sure I'm paranoid, but am I paranoid enough?
    9. Re:Well... by s0litaire · · Score: 2

      Depends on if it's the SSD controller that is hiding the space.
      I really need to get one to test but...
      Example:
      you've got a 64Gb ssd on SDB it say's it's 50Gb partition
      If you just run a "dcfldd" command "dcfldd if=/dev/zero/ of=/dev/sdb" (the whole device not just the partition)
      Will it wipe 50Gb or 64Gb?

      --
      Laters Sol "Have you found the secrets of the universe? Asked Zebade "I'm sure I left them here somewhere"
    10. Re:Well... by EasyTarget · · Score: 1

      Nope.. that command will write a random data packet to every storage location on the device. That's why I'm writing to /dev

      $ cat /dev/urandom | dd of=/dev/ssdX

      A common misconceptions with SSD's is that their cells 'wear out'; so there is some magic 'hidden space' that only becomes available when other cells 'die'. This is nonsense.. once a cell has worn out it is dead; and the disk capacity is reduced by that amount. No secret extra storage will appear to take it's place.

      Wear levelling is just a mechanism to spread out the write cycles evenly over the cells; so that you do not get 'dead spots' where files are being constantly written. It's ultimate goal is to ensure the disk 'wears out' all in one go; rather then piece by piece.

      --
      "Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
    11. Re:Well... by marcosdumay · · Score: 1

      that cat/dev/urandom > /dev/sdX is exactly what doesn't work with SSDs. Try rm -rf *, that the current article is claiming to work quite well.

      Or, if you are really paranoid, repeatedly do cat /dev/urandom > FILE_IN_SSD after you do rm -rf *.

    12. Re:Well... by LordKronos · · Score: 1

      cat /dev/urandom >> /dev/ssdX

      Just needs to be run once to -really- bollox an investigation..

      Not entirely. Remember that most SSDs use overprovisioning to increase performance. This means that at any given time, only a portion of the drive (typically around 90-95%) is actually accessible. And I'm pretty sure that, due to wear leveling, the controller will continuously alter which portions are accessible. That means you could write to the entire drive (from the OS's point of view), but there will still be a portion you cannot touch until the controller decides to swap it back into use. On the plus side, I suspect the drives tend to keep that extra space wiped (but I'm not absolutely positive), so there probably wouldn't be any actual data in there.

    13. Re:Well... by The+Wild+Norseman · · Score: 1

      Relcome! I wasn't sure anyone at all would get it; glad you did!

      (Insightful post, though. I just spent my last mod point, otherwise +1 to you.)

      --
      "A government is a body of people usually -- notably -- ungoverned." -Shepherd Book
    14. Re:Well... by EasyTarget · · Score: 1

      Nope.. it works just fine; it will write a new value to each end every storage location in the device. Eventually this will overwrite every bit of data stored there including the coolstuff.rar file. It cannot fail, also see my previous post; there is no secret extra storage for the data to hide in and avoid overwriting.

      But the sudo rm -rf /mountpoint trick will also work quite effectively because the wear levelling stuff also responds to it and modifies the disk structure severely enough in a short timeframe that the disk becomes 'corrupted' as -evidence-. This is despite the fact that fragments of data still remain and are recoverable, it's just that a slick lawyer will ask the defence to prove the data is unmodified; which they will be unable to do.

      Piping random shit to every cell on the device will still be better if you have time.

      --
      "Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
    15. Re:Well... by grumbel · · Score: 1

      This is nonsense.. once a cell has worn out it is dead; and the disk capacity is reduced by that amount.

      Sure about that? Your average file system won't like it very much if you just "reduce the disk capacity", so having some spare blocks around to take the place of failed one would make a lot of sense if the whole drive shouldn't be unusable once the first failed block appears.

    16. Re:Well... by Onymous+Coward · · Score: 1

      Why randomish data? Why not just zeroes?

    17. Re:Well... by bluefoxlucid · · Score: 1

      A common misconceptions with SSD's is that their cells 'wear out'; so there is some magic 'hidden space' that only becomes available when other cells 'die'. This is nonsense.. once a cell has worn out it is dead; and the disk capacity is reduced by that amount.

      Having worked with flash chips that specifically do not have a controller between me and them... no. This doesn't happen. Also, no, you don't get a 64GB drive and it goes, "Oh, I'm smaller, time to lose data off the end" so when you lose a block you lose 2 blocks of data (the one in the middle of the disk and one off the end)

    18. Re:Well... by Onymous+Coward · · Score: 1

      Okay, how about this... One pass of zeroes, which on my system takes 1/300th the time urandom takes, then start in an a urandom pass.

      Better yet, since the article is suggesting that the SSDs understand NTFS and are using filesystem structure to delete unneeded SSD blocks, wipe your drive in this order:

      1. quick format
      2. complete overwrite with zeroes
      3. complete overwrite with urandom

      The quick format happens near instantly and starts the drive erasing itself, so if you're interrupted after formatting, the data is in the process of disappearing.

      The zeroes overwrite happens really fast and assures the data is munged block by block. No recovery using the drive unmolested as a device to read its own chips. An extreme gimping of the data done fast.

      The randomish overwrite, which takes a while, presumably makes the data on the chips harder to ... read with a microscope or something? Oscilloscope?

    19. Re:Well... by Andy+Dodd · · Score: 1

      Wrong. Many SSD controllers contain extra flash storage to support error checking/correction and handle bad blocks.

      Just like nearly all magnetic hard drives have slightly higher capacities than advertised/reported/usable - bad block mapping.

      --
      retrorocket.o not found, launch anyway?
    20. Re:Well... by bestalexguy · · Score: 1

      this is exactly the kind of story that I would tell them so that they would continue using SSDs.

      This is exactly the kind of comment that I would post so that they would stop using SSDs. Especially so, if I omitted any kind of reference to actual data. Not a pointless critic or trolling routine, just a request for useful info

    21. Re:Well... by _0xd0ad · · Score: 1

      Your average file system won't like it very much if you just "reduce the disk capacity"

      They didn't care back in the days of the 720K floppy (I can't say I remember any earlier than that). I don't see why they should care now.

      having some spare blocks around to take the place of failed one would make a lot of sense if the whole drive shouldn't be unusable once the first failed block appears.

      Ah, that brings back some memories... back in the day, if the first block (block 0) of a floppy failed, the entire disk was unusable. But that was also before wear-leveling ensured that "block 0" can be located anywhere at all in the flash memory.

    22. Re:Well... by jbolden · · Score: 1

      Actually that's too fast. You are better off running that to create 200 files each about a 1/2% of the disk and spacing the writes out after every 5% or so.

      Your solution is more likely if stopped 1/2 way to end up not really erasing as much.

    23. Re:Well... by EasyTarget · · Score: 1

      Why randomish data? Why not just zeroes?

      Because random data looks like real data, or mashed up real data, or encrypted data. Or whatever. All zeros on an in-use drive would make me suspicious :-)

      --
      "Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
    24. Re:Well... by moonbender · · Score: 1

      You'd be right if it weren't for the fact that there really is a 'hidden space' that's only visible to the controller itself (sadly, there is nothing magic about it). The new 25nm OCZ "120 GB" drive actually contains 128 GB worth of flash memory and stores only 118 GB. See e.g. http://en.wikipedia.org/wiki/Write_amplification#Over-provisioning. You'd need to talk to the controller to wipe those areas, writing to the "raw" block device won't do anything.

      --
      Switch back to Slashdot's D1 system.
    25. Re:Well... by Stray7Xi · · Score: 1

      Nope.. it works just fine; it will write a new value to each end every storage location in the device. Eventually this will overwrite every bit of data stored there including the coolstuff.rar file. It cannot fail, also see my previous post; there is no secret extra storage for the data to hide in and avoid overwriting.

      No, hitting all the logical blocks with random data won't hit all the physical blocks because of overprovisioning. There is a ~7% extra space the OS doesn't get access to that is used to improve performance and control bad sectors. This is not a big deal since it's not addressable and the firmware should clean it up eventually.

      Secondly you'll overwrite the MFT/Superblock with random data and then the SSD firmware won't be capable of doing garbage collection. Which is fine if you have the time to finish a long process of overwriting every sector. But if it gets interrupted your data will be left and the GC won't be able to clean it up on next power-on.

    26. Re:Well... by Stray7Xi · · Score: 1

      that cat/dev/urandom > /dev/sdX is exactly what doesn't work with SSDs. Try rm -rf *, that the current article is claiming to work quite well.

      Or, if you are really paranoid, repeatedly do cat /dev/urandom > FILE_IN_SSD after you do rm -rf *.

      Linux won't actually remove files that processes have open file descriptors to (it removes the link but doesn't deallocate the space). That means their cwd dentry (and all it's parents) will be intact (just unlinked) on disk. So your cat won't actually destroy these phantom blocks. Those dentries could have incrimating filenames of files that their space was deallocated.

      A format will however overwrite this metadata and the SSD garbage collection should still be able to clean up.

      Just to demonstrate this phantom file on linux:
      echo 123>x; sleep 9999 >> x &
      rm x
      cat /proc/${!}/fd/1
      stat /proc/${!}/fd/1

    27. Re:Well... by Stray7Xi · · Score: 1

      you've got a 64Gb ssd on SDB it say's it's 50Gb partition

      You buy a 50GB drive. Linux sees it as 50GB drive. However it's overprovisioned to 64GB (in your example) and the controller manages that extra space. On the plus side the controller is naturally going to want to zero out that overprovisioned space so it can be rewritten to.

    28. Re:Well... by Zuriel · · Score: 1

      Why randomish data? Why not just zeroes?

      Some SSD controllers use compression algorithms, and I imagine all zeroes would compress *really* well.

      It'd be a bit embarrassing to write a terabyte of zeroes to an SSD and find that the entire write fit into one 4k flash page, leaving the rest of the flash containing sensitive data.

    29. Re:Well... by marcosdumay · · Score: 1

      Yes, I ned to turn that rm -rf * into a mkfs. I didn't think about the inodes.

  9. Also the end of data recovery by assemblerex · · Score: 1

    On magnetic storage I can change controller boards, even swap out the
    platters in a clean environment into another drive with working heads.
    For a few hundred to some thousands, your poor choice of having no backup media
    can be resolved.

    On SSD I can desolder the chips, dump them and then tell you there's nothing recoverable.
    For a few hundred to some thousands, your poor choice of having no backup media
    can be resolved.

    1. Re:Also the end of data recovery by CMOS4081 · · Score: 1

      On magnetic storage I can change controller boards, even swap out the platters in a clean environment into another drive with working heads. For a few hundred to some thousands, your poor choice of having no backup media can be resolved. On SSD I can desolder the chips, dump them and then tell you there's nothing recoverable. For a few hundred to some thousands, your poor choice of having no backup media can be resolved.

      As long as they are TSOP and not BGA maybe so. If they are put in the correct order.

  10. Hard to Erase AND Hard to Recover by drenehtsral · · Score: 1

    Ultimately since the Flash Translation Layer goes and does things under-the-hood that are not externally visible, it is hard to be sure your data were erased, and it's also hard to be sure they were not erased... Essentially since there is an opaque interface at the logical-block level and the device is internally free to behave as it chooses so long as that interface is maintained, it makes it tricky to guess how the internal implementation will behave.
    Plain old magnetic disks used a fairly predictable implementation of that interface so forensics goons got used to having an easy task on their plates.

    --

    ---
    Play Six Pack Man. I
    1. Re:Hard to Erase AND Hard to Recover by Mr.Intel · · Score: 1

      The *real* problem is that flash memory has to do something inherently difficult to work: trap electrons. It's devilishly tricky to trap an electron (or group of electrons) in any meaningful way. Furthermore lash devices have to trap said electrons for a period of time that allows for reasonable storage times (years). This is why it's hard to both delete and recover data. After so many electrons leave the cell, data integrity fails. On the other hand, it's also difficult to reliably get rid of all the electrons in all the cells without destroying the ability of the cell to hold electrons in the future. Thermite and kinetic projectiles aside, SSD security is an emerging field.

      --
      ASCII tastes bad dude.
      Binary it is then.
    2. Re:Hard to Erase AND Hard to Recover by graeme_ssd · · Score: 2
      "Plain old magnetic disks used a fairly predictable implementation of that interface so forensics goons got used to having an easy task on their plates."

      You've hit the nail on the head.

      But, to be fair, consider the amount of digital evidence in the world today vs. 20 years ago. Training up court-approved forensics officers to dismantle drives and their firmware in a manner which doesn't wreck the data, is a heck of a lot harder to do than teaching them to run 'dd' with a write-blocker attached.

      Graeme.

  11. really hard to erase, or really hard to recover? by flaming+error · · Score: 5, Funny

    Why the confusion, dear editor? This should be well understood.

    If you want to recover, you can't. If you want to erase, you can't. It's Murphy's Law of Data Storage.

  12. Re:And the downside here is... by MachDelta · · Score: 4, Funny

    When Mindy the undergrad accidentally deletes her term paper and would be really REALLY grateful for a super smart and kinda cute geek to go in and recover the file with Backtrack... then you'll see the downside.

    What? I reject your reality and substitute my own!

  13. Huh? by Andrewkov · · Score: 2

    Forgive my ignorance, but how is this possible? Does this mean that the drives understand NTFS and are actually zeroing out data on the drive when the OS simply deletes the entry from the FAT table? How can the SSD second guess what the OS is doing? I thought that SSD's use the same interface as regular HD's and should behave the same.

    1. Re:Huh? by Pathwalker · · Score: 4, Informative

      There is an ATA command called "TRIM". If a device supports it, the OS can tell it that a group of sectors is no longer needed, and should be wiped.

    2. Re:Huh? by Osgeld · · Score: 2

      they use the same interface tween the computer and the device but tween that device controller and the actual raw memory is a whole different story

    3. Re:Huh? by Rich0 · · Score: 1

      I would think that the command would also be useful for wear-leveling.

      The more space that the device can understand as "free" the more opportunity it has to avoid writing to places that are wearing. if the whole drive is 100% free the best it can do is try to move data back and forth if it notices one spot getting written to more. That wastes writes and time. If it knows that a spot is now free, the drive can take the opportunity to optimize more.

    4. Re:Huh? by rwa2 · · Score: 1

      Read AnandTech's SSD Anthology, and all shall become clear (including why it's unreliable to try to securely wipe files from SSDs, as well as how they can go on deleting and rearranging stuff in the background)

      http://www.anandtech.com/show/2738

      (summary: SSD's basically have a mind of their own (of varying degrees of mediocrity) that tries to compensate for all of the shortcomings of flash storage so the OS doesn't have to worry about it)

    5. Re:Huh? by icebike · · Score: 1

      But there are reliable methods that work well on ssd drives OR spinning storage. That involves erasing the file(s) followed by filling the drive to capacity with copies of some random binary image files. This is actually practical on smaller/faster SSD drives (where this can be done quickly), not so much on large spinning drives.

      Since even a single overwrite will effectively make file recovery impossible, any method of inducing that should suffice.

      --
      Sig Battery depleted. Reverting to safe mode.
    6. Re:Huh? by Andy+Dodd · · Score: 1

      That's exactly why TRIM is there - to give wear-leveling controllers more knowledge of what is unused.

      1) Spread wear more evenly
      2) Pre-erase unused pages (You can individually write blocks, but you can only erase pages that consist of many blocks) to avoid read-erase-modify-write cycles

      --
      retrorocket.o not found, launch anyway?
    7. Re:Huh? by graeme_ssd · · Score: 1
      "Forgive my ignorance, but how is this possible? Does this mean that the drives understand NTFS and are actually zeroing out data on the drive"

      - Yes, that's pretty much what they're doing, all under their own control without the PC asking them to. But they are not so much zero-ing out the data, as resetting the cell to prepare it for being written to in future more quickly. Not all drives do it, but increasingly it's built in since the technology is already written now, and people running non-TRIM OS's can benefit from it a great deal.

      - Re: zeroing. Oddly enough, I seem to recall that cells are actually reset to all 1s at the physical level...

      Graeme.

    8. Re:Huh? by Tacvek · · Score: 1

      - Re: zeroing. Oddly enough, I seem to recall that cells are actually reset to all 1s at the physical level...

      Graeme.

      All ones or all zeros are a matter of interpretation. Physically the cells may return a high voltage when erased, But a drive could easily invert that. Inversion is the laest expensive operation possible in hardware, other than no-op (a wire). Indeed inversion is often free thanks to how CMOS logic works, and especially thanks to how things like flip-flops work, where inversion of the output is literally a matter of swapping "wires" between a pair of physical logic gates.

      --
      Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
    9. Re:Huh? by Fnord666 · · Score: 1

      Forgive my ignorance, but how is this possible? Does this mean that the drives understand NTFS and are actually zeroing out data on the drive when the OS simply deletes the entry from the FAT table? How can the SSD second guess what the OS is doing? I thought that SSD's use the same interface as regular HD's and should behave the same.

      That, my good man, is exactly what it means. The SSD understands the NTFS file system that has been placed upon it and can determine when a block is no longer referenced by any file chain. At that point it can erase the block so that it can be written to at a later point in time without incurring the penalties. If I understand the authors correctly, this "garbage collection" takes some time to kick in though. The interesting thing they found was that with some, if you did a quick format which basically just clears the file system metadata, garbage collection occurred much faster than that. Since this happens at the firmware layer in the SSD, the only requirement is power to the drive. Quite an interesting result actually.

      --
      'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
    10. Re:Huh? by geggo98 · · Score: 1

      [...]Does this mean that the drives understand NTFS and are actually zeroing out data on the drive when the OS simply deletes the entry from the FAT table? [...]

      Yes, it means exactly that. When the drive detects, that the OS running supports TRIM commands, it relies on that. If it detects that there are the OS does not support TRIM commands, it tries to interpret the filesystem to detect which blocks belong to deleted files. It then brings these blocks back to a prisine state to make them faster writable. During this process all data on the block is cleared. When you bring back the file using an undelete tool or access the according blocks directly (e.g. using a sector editor), you will only get blocks with zeroes.

      Or to phare it in another way: When you set some bits in certain blocks to zero, the drive will find it safe to wipe some other blocks on the drive, without being told so by the OS. If your file system in NTFS with the right version, this assumption is true. If you use a different file system, this might not be the case. The details are unknown because the firmware is closed source.

      You can find the details in the paper (PDF) cited in the fine article.

    11. Re:Huh? by graeme_ssd · · Score: 1

      All ones or all zeros are a matter of interpretation.

      Of course. My statement was imprecise. It would have been more accurate to say that what we (or at least, I) would intuitively expect to represent all 1s - i.e. the storage of charge - actually represents a logical zero when you read the cell. Graeme.

  14. Well, I guess.. by The+Fanta+Menace · · Score: 1

    ...we better ban them, then.

    --
    -- Even if a god did exist, why the fsck should I worship it?
  15. So what's the problem? by maxx_entropy · · Score: 2

    The whole point of the referenced article is that it is somehow a "problem" that data deleted (and intended to be deleted) by the owner of the SSD cannot be later recovered. Why should deleted data be recoverable? Will "police state" now require SSDs to stop this seemingly desirable behavior to ensure evidence be recoverable from an impounded device? I for one applaud the behavior of these new storage devices.

    1. Re:So what's the problem? by DrgnDancer · · Score: 4, Insightful

      Well to be fair, that's only part of the problem. Say you're a stupid criminal. You store all your records of your criminal acts on your computer which happens to have an SSD drive. You've never deleted your records of your criminal acts, but just before the police busted through the door you were deleting some old pictures of your cat, Fluffy. So in order to maintain evidence chain of custody, the police immediately turn off you computer and turn it over to a tech. The tech's first two actions should always be the same. He should plug your drive into a a special read only device that will first do an MD5sum or other fingerprint of the whole contents of the drive, and then do a bit for bit copy of the drive.

      The idea here is that the police can prove that nothing was done to alter the data present at the time of seizure. Power was removed from the system and the drive was immediately fingerprinted and copied. Assuming the fingerprints match, there should be no question that the copy on which the actual analysis is done is identical to the original drive. The problem is that you were deleting pictures of Fluffy when the Police came in. It's highly likely that as the drive does its self cleaning routine the fingerprint of the data will change. They fingerprint, get a value, but while they're copying the drive self cleans the bits associated with your cat pics. Bam, the copy has a different fingerprint. Now there's reasonable doubt about the usefulness of the evidence you stupidly left unencrypted in your desktop folder.

      Now I'm not saying this is a problem, and that they need to modify the design of SSDs. I didn't get the impression that article said that either. What they are saying is "Hey, we need to come up with another way to do this, becasue what we've been doing will no longer stand up in court."

      --
      I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
    2. Re:So what's the problem? by icebike · · Score: 1

      They fingerprint, get a value, but while they're copying the drive self cleans the bits associated with your cat pics. Bam, the copy has a different fingerprint. Now there's reasonable doubt about the usefulness of the evidence you stupidly left unencrypted in your desktop folder.

      Reasonable doubt in who's eyes?
      Would the tech even report that fingerprint difference knowing full well how these drives behave?
      Would the defense even raise the issue that a fingerprint difference suggests planted evidence knowing how these drives behave?

      When something is knowns to be unreliable, then neither side can rely on it.

      The tech would simply copy off all files, and hash them, and work with his hashed copy. This is a repeatable act.
      Files can be compared again and again. To impune this method you have to impune the entire lab with an assertion
      of planted data.

      Existing files aren't the problem. Its the deleted files where things get murky.

      --
      Sig Battery depleted. Reverting to safe mode.
    3. Re:So what's the problem? by DrgnDancer · · Score: 1

      I'm just saying how they do it now. It presents an extremely easy and traceable method for maintaining chain of custody. If it turns out to no longer be reliable, they'll have to come up with something else. That's all I'm saying, and as far as I can see that's all the article is saying.

      --
      I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
    4. Re:So what's the problem? by Ksevio · · Score: 1

      Assuming you have a much faster drive (or lots of memory) to write to, wouldn't it be the same amount of time to do a checksum as to copy the drive?

    5. Re:So what's the problem? by DrgnDancer · · Score: 1

      It's not a matter of speed, the checksum is done immediately so there's a baseline for comparison. You checksum the drive (The whole drive image, garbage and all), then make a complete copy of the drive image. Assuming the checksum of the copy matches the original, you store the original and never touch it again (unless there's a problem). Now you can make copies of the copy and do all the analysis you want. You've go the original sealed, the clean copy, and copies that you can hack around on. If you accidentally screw one of those copies up, you make a new one from the "clean" copy. As long as the evidence you gather comes from a copy with a checksum that matches the original you can "prove" that is was on an original unmodified piece of evidence.

      If the defendant (or litigant, I've never been involved in this for a criminal case, but I have some very limited experience working with it for a civil case) claims you changed something or planted evidence you can go step by step: Here's the record where the evidence guy bagged your drive from your computer, and here's a witness that he followed procedure. Here's where the lab tech broke the seal on the evidence bag and here's the witness that *he* followed procedure. Here's the checksum he got from your drive image, and here's the checksum taken from the image which matches. Cops and lawyers are really serious about chain of evidence, anywhere you can provide near perfect proof that you did what you said you did, they are thrilled.

      With Civil cases it's even easier, since the litigant or their lawyer can watch you remove the drive and get the checksum if they want. Removes the possibility that the cop, evidence guys and tech are in cahoots to frame you. The NCIS bit where Abby pulls the original drive out of evidence is pretty much bullshit.

      --
      I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
    6. Re:So what's the problem? by Ksevio · · Score: 1

      But if time were a factor, it would be wise to do the copy first, or at the same time as the checksum to avoid losing data.

    7. Re:So what's the problem? by geggo98 · · Score: 1
      The problem is that the firmware of the drive tries to interpret the filesystem it holds. With this interpretation it tries to guess which blocks can be delete. It does this without being told by the OS. There is a standard called TRIM command, so the OS can tell the drive which blocks don't hold valid data any more. The drive can then reset these blocks to improve future writes.

      But the drive in question does not rely on this standard but tries to interpret the file system it holds. It then tries to detect deleted files and resets all data belonging to these files. If it guesses right, you only loose data belonging to deleted files. If it guesses wron it resets blocks holdign data you still need.

      There are severaly situations where this can lead to problems: Some DRM schemes store data outside of the control of the filesystem. Microsoft might update NTFS so the interpretation of the filesystem changes and the drive deletes the wrong blocks. Some people use other filesystems than NTFS, hence confuse the drive and loose data. Some people encrypt their file system, leading the drive to try to inteprete the seemingly "random" data and randomly nuking blocks. And so on.

      It does not help that this feature is completely undocumented, so you don't know if and how your drive tries to interpret the filesystem. Good luck with fixing errors related to this.

    8. Re:So what's the problem? by DrgnDancer · · Score: 1

      From the sounds of things you're unlikely to able to get either the copy or the checksum done before it's problem. At least not on a drive with any appreciable amount of data. You have a matter of a few minutes before the drive image is altering itself.

      --
      I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
  16. Re:really hard to erase, or really hard to recover by cdpage · · Score: 1

    would mod you up one for that.

  17. SSD's are impossible to recover by teh+augmenter · · Score: 1

    Quote: "So either SSDs are really hard to erase, or really hard to recover. I'm so confused."

    I work in a professional environment where we attempted to recover data from a crashed SSD. Nothing can be recovered. Consider the way an SSD Works. They are extremely expensive because each one contains a memory bank like RAM and a processor to handle reading and writing. If an operating system has "TRIM" enabled (or implemented to work like in Windows 7) then it will delete when a user deletes a file. It writes over the blocks with blank space. This ensures that writing speed does not slow down during the use of the device. So anynill delete when a user deletes a file. It writes over the blocks with blank space. This ensures that writing speed does not slow down during the use of the device. If thing deleted on a drive like that is really DELETED and cannot be recovered. -- Little google goes a long way ;)

    1. Re:SSD's are impossible to recover by Andy+Dodd · · Score: 1

      Slight issue with your terminology:

      With flash memory, an "erase" cycle is independent of a "write". In fact, one of the reason the TRIM command was implemented is because you can write in relatively small blocks, but you can only erase fairly large pages. So if you just want to write a block of 512 bytes to a page that is in use, you need to do a read-erase-modify-write cycle.

      --
      retrorocket.o not found, launch anyway?
  18. Both hard and easy are true by RichMan · · Score: 5, Informative

    The drives have internal overprovisioning and perform internal garbage collection. This means that marked for deletion data has an unknown lifetime and may disappear at any point without interaction from a controller.

    The hard to erase bit means that you really can't be sure something is totally erased without a full specific erase command to all flash blocks. Without that a page marked unused but not erased may be nestled in with a bunch of valid pages. As all pages in a block are erased together that marked unused page can hang around for a wile.

    On the other side the firmware does garbage collection it actively looks for blocks with many erased pages and then tries to consolidate things so it can create more free blocks. This means if the drive is powered but not connected to a host machine it can still be doing data moves for consilidation and erasing marked for deletion pages.

    There are thresholds for the garbage collection so it won't overwork and try for 100% consolidation. Thus you get both the presence of some really sticky stale marked unused pages and some active erasing of others.

  19. Not necessarily a bad thing.... by macraig · · Score: 2

    I'm on the fence about this, and it's possible neither pasture is green. On the one hand, I might be the victim of a genuine crime, evidence of which happens to be hiding in an SSD drive. On the other hand, these techniques are just as routinely abused now to go after people for political noncriminal reasons that don't serve the Common Good at all, people and organizations like Julian Assange, Wikileaks, Bradley Manning, the U.S. Chamber of Commerce opponents... you name it.

    These techniques are like nuclear physics: just as easily applied for Bad Things as Good. If we can't selectively prevent the abuses, maybe we should err on the side of caution and ban the techniques altogether. They aren't being universally applied to serve justice.

    1. Re:Not necessarily a bad thing.... by dave562 · · Score: 1

      I work for a firm that is involved with digital forensics and has worked closely with the SEC and DOJ on criminal investigations. The firm also works with corporations who suspect that their employees are up to no good, and who need a neutral third party to come in and investigate. I'd name names, but that is frowned upon.

  20. Elementary my dear Watson by joeyblades · · Score: 2

    I thought that this was particularly telling. In the article it said:

    ... the state of the drive cannot be taken to indicate that its owner did or did not interact with it in ways that allow prosecutors to infer guilt or innocence. The fact that data has been purged does not mean a human knowingly did it (e.g. accidental guilt)...

    So in other words, until SSDs came along, evidence of purged data was evidence of guilt... at least in Austrailia.

    1. Re:Elementary my dear Watson by royallthefourth · · Score: 2

      Destroying evidence is a crime in the US, too.

    2. Re:Elementary my dear Watson by H0p313ss · · Score: 1

      Destroying evidence is a crime in the US, too.

      Yes, but destroying data is not. The point is that evidence that something was destroyed is not itself evidence of crime.

      --
      XML is a known as a key material required to create SMD: Software of Mass Destruction
    3. Re:Elementary my dear Watson by sjames · · Score: 1

      The question revolves around deciding if an action was innocent (deleted old files, didn't know it would be "evidence" later) vs. perhaps implying guilt (deleted files then overwrote all free space on drive to make sure evidence was really gone). With SSDs, deleting a file implies erasing the blocks it lived on in normal operation so it implies nothing.

    4. Re:Elementary my dear Watson by joeyblades · · Score: 1

      If Bob is ordered by a court to hand over his hard drive as evidence in a criminal proceeding and he wipes it, it's destruction of evidence. If Joe wipes his disk and then is ordered to hand over his hard drive as evidence in a criminal proceeding, it's NOT destruction of evidence.

    5. Re:Elementary my dear Watson by icebike · · Score: 1

      Exactly.

      Its only evidence when you are served with a warrant for it or it is seized pursuant to a warrant.
      Until then, its just data, not evidence.
      A scheduled task to purge data is evidence ONLY of a policy to do just that, which is within your rights, until ordered by a court to the contrary.
      Many companies have a policy to delete some types of files on a scheduled basis. Some companies work under laws that prevent this,
      but Joe User can pretty much do what they want on their own computer.

      --
      Sig Battery depleted. Reverting to safe mode.
    6. Re:Elementary my dear Watson by icebike · · Score: 1

      Destroying "evidence".
      Or ceasing to commit a crime.

      In both cases you were committing a crime, by possessing said prohibited item, and you have corrected it.

      And to this very DAY, Google Street View division wishes you were its lawyer.

      --
      Sig Battery depleted. Reverting to safe mode.
    7. Re:Elementary my dear Watson by betterunixthanunix · · Score: 2

      That is like saying that a paper shredder implies guilt. If I run shred to securely delete some files, that does not mean that I am guilty; it could just mean that I am concerned about possibly selling the drive to someone else (perhaps as part of a sale of an entire laptop), disposing of the drive at an electronics recycling center, or having the drive stolen. Every reason for using whole disk encryption applies equally to using secure delete programs.

      Oh, wait I forgot that I am supposed to feel sorry for the police, who need more power than they have already. Carry on with the panic, then.

      --
      Palm trees and 8
    8. Re:Elementary my dear Watson by sjames · · Score: 1

      I'm just explaining their reasoning, not necessarily agreeing with it.

      I would say that securely wiping data may suggest the possibility of guilt but shouldn't be considered probable cause. Police are upset because they would like to continue using such things to snowjob judges into giving them rubber stamp warrants.

    9. Re:Elementary my dear Watson by Enigma23 · · Score: 1

      Destroying evidence is a crime in the US, too.

      Only if you leave evidence behind that you've destroyed evidence. Absence of evidence does not equate to evidence of absence...

      --
      Ceci n'est pas une .sig
  21. The way the world works by Anonymous Coward · · Score: 1

    "So either SSDs are really hard to erase, or really hard to recover. I'm so confused"

    It's easy - if you need it back, it will be hard to recover. If you desperately depend on nobody ever seeing it, it will be hard to erase. I'm pretty sure this is a consequence of the Uncertainty Principle, but I have not yet completed my paper proving it.

  22. This is bad news by bogaboga · · Score: 1

    "Firmware built into many solid state drives (SSDs) to improve their storage efficiency could be making forensic analysis at a later date by police forces and intelligence agencies almost impossible to carry out to legally safe standards, Australian researchers have discovered..."

    So expect some government intervention on matters concerning which firmware should be built into the devices we use.

    I cannot see any government worth its credibility endorse a product which if employed in crime and confiscated (by police), it is almost impossible to use it to prosecute the perpetrators by government agencies and the FBI in the case of these United States.

    You might wonder how a government might endorse a product:

    By allowing its importation or production and subsequent collection of taxes from transactions related to the product.

    1. Re:This is bad news by edawstwin · · Score: 1

      Just because something doesn't perfectly suit a government's needs when they suspect someone of a crime doesn't mean the product should be banned. Take pre-paid cell phones. No real tracking, and if a criminal is smart, there is zero chance any government agency could ever find out what was said on the phone, and in most cases, even who used the phone. Should we ban pre-paid cell phones? What about pipes? I can smoke anything I want in a pipe, including tobacco, marijuana, crack, or torn up bits of the Constitution. The fact is the vast majority of people using any of these devices are using them legally, and benefit much more than the inconvenience to the government caused by criminals using them for nefarious purposes.

      --
      I don't want to achieve immortality through my work. I want to achieve it by not dying. - Woody Allen
    2. Re:This is bad news by graeme_ssd · · Score: 1
      "I cannot see any government worth its credibility endorse a product which if employed in crime and confiscated (by police), it is almost impossible to use it to prosecute the perpetrators by government agencies and the FBI in the case of these United States."

      Hello there, thanks for your comment. Just a couple of quick points:

      - SSD garbage collection doesn't destroy data indiscriminately, it destroys data that the user has manually chosen not to retain. In many ways, this is not substantially different to a user choosing to turn off their computer and losing all the data in RAM chips which they have manually chosen not to save permanently. Should we ban RAM as well, along with any device which loses non-archived data in a manner which can't be recovered from?

      - Keep in mind the evidence that is destroyed can be used to prove innocence as much as guilt. It's not actually a net loss as far as courts are concerned.

      Graeme.

    3. Re:This is bad news by jbolden · · Score: 1

      What do you mean by "endorse"? Government don't endorse products. And we have lots of parts on our computers that erase data: ethernet cards, RAM, keyboards.... what's changed is that diagnostics on hard drives is getting harder as we move from magnetic to SSD.

  23. Guantanamo bay for SSDs? by cultiv8 · · Score: 1

    could be making forensic analysis at a later date by police forces and intelligence agencies almost impossible to carry out to legally safe standards

    So then they're sending SSDs out of the country for hard-core, waterboarding-style data extraction?

    --
    sysadmins and parents of newborns get the same amount of sleep.
  24. Wasn't this... by MrNemesis · · Score: 5, Interesting

    ...a foregone conclusion ever since ATA Secure Erase and TRIM were introduced?

    Secure Erase basically tells the SSD that all of its cells are now blank (AFAIK implementations actually zero the drive as well but I'm happy to be corrected on that); therefore as soon as anything is written to the disc, it will be written here, there and everywhere. It took about 30s to run on my first vertex and I couldn't find any trace of

    TRIM support in the ATA spec, along with kernel/filesystem support, tells the disc that when file A is deleted, cells X, Y, and ABQ are now officially "empty" and that if the controller feels like it, it can zero them out, shunt other data in there, or have a mardi gras for all it cares. The same happens when a drive is formatted; OS tells drive controller "I've just formatted you" and for the sake of preserving performance the controller goes "Brilliant! I can chuck out all this shit I've been saddled with."

    As soon as hard drives start intelligently erasing/shuffling bits of themselves about so that cells are utilised to their utmost efficiency this was bound to happen. Unlike spinning platters where bad blocks were reallocated only if a) the hard disc knew about it and b) the data could actually be read/recovered, it becomes terribly obvious that data on SSD's is going to be read and written and deleted completely and utterly all over the place, without sequential series of sector found in slackspace like you would on a magnetic drive.

    Magnetic drives have no performance penalties for not actually erasing the data, so if you work your way around that double negative you'll see that one of the staples of digital forensics (e.g. recovering files from slack) is a by-product of people trying to make magnetic platters as fast as possible by not actually erasing stuff, because as long as the controller knows that sector is blank then it'll just be overwritten as needed. Technology has now changed sufficiently that the performance gains from new solid state tech are helped by a drive controller that erases stuff as soon as possible, since writing over an occupied cell is slower than writing over a blank one.

    I'm sure there'll be new methods to mitigate the change in tech, we're just somewhat on the cusp of a completely new tech. They'll probably come to an agreement that TRIM doesn't actually delete stuff until the amount of free space in the cells reaches a certain threshold or something like that.

    Disclaimer: I'm not a digital forensic scientist, but am friends with one and we discussed this problem over some exquisite cocktails a few months back. And I don't think TRIM instructions follow the exact specifications I laid out above (e.g. using Brilliant! as an ACK).

    --
    Moderation Total: -1 Troll, +3 Goat
    1. Re:Wasn't this... by ledow · · Score: 1

      To be honest, most data recovery from a hard drive is foiled by a simple zero anyway. All this "must wipe several times with certain patterns" thing is cobblers. Yes, if I was the military, I'd be doing it too, just to make sure, but no-one has yet provided convincing proof that "magnetic history" from drives can actually be recovered in anywhere near a cost-effective or reliable way.

      Digital forensics consists of taking an image of the drive and seeing what you can get from that. Any half-decent implementation that encrypts, zeroes and deletes things properly is going to foil any digital forensics.

      SSD's make it harder but digital forensics recovering useful data is next-to-impossible for the storage devices of anyone that actually *KNOWS* about PC's and wants to keep that info secret.

    2. Re:Wasn't this... by marcosdumay · · Score: 1

      There is plenty of evidence that hysteresis is a real phenomenum. It may not be cost-effective, but that is a function of how valuable is your data for the people trying to read it, so it varies with who you are.

      Why not play it safe and make it impossible to recover the data, instead of just not cost effective?

    3. Re:Wasn't this... by graeme_ssd · · Score: 1
      Hey there

      "...a foregone conclusion ever since ATA Secure Erase and TRIM were introduced?"

      Yes, TRIM is eventually going to change the game in the sense that data will (probably) be expunged ASAP by the drive when you delete them (as you observe though, it is a request to the drive, not an instruction, and consequences of issuing a TRIM are unknown). But it could be a decade before courts will stop seeing the problem mentioned in this paper. I think the problem will peak in coming years and decline e.g. 4-5 years out as people finally give up on XP/2003, non-TRIM linux implementations of FAT32/NTFS, older Mac OS's, etc.

      TRIM only works when you have a firmware and OS that support them. Given the number of people I know using XP (and below) and MacOS Snow Leopard (and below), there's a lot of computers out there who won't be sending ATA TRIM commands to their disk. Yet SSD GC is becoming more common and more aggressive in the meantime...

      I would say that court practice and legal precedent is slow to update as far as technology is concerned, and SSD GC has come out of the blue for them, and is a currently a fast-moving technology that works with most non-TRIM OS's out there, and wrecks court expectations and practices that have worked for about 25 years.

      Graeme.

    4. Re:Wasn't this... by icebike · · Score: 1

      Actually there is NO evidence that hysteresis is a real problem or even pertains AT ALL to data recover from overwritten magnetic media.
      There has been no demonstration of file recovery after a single overwrite. An occasional bit, and maybe an entire byte, but no complete file. Its a myth.

      --
      Sig Battery depleted. Reverting to safe mode.
    5. Re:Wasn't this... by LanMan04 · · Score: 1

      And I don't think TRIM instructions follow the exact specifications I laid out above (e.g. using Brilliant! as an ACK).

      Useless but on-topic information:

      I once wrote a protocol in C that would blast out packets containing a string to a broadcast address (over 802.11 wireless), and any other wireless unit that heard it responded with one of two ACK values and then negotiated an open-vpn tunnel over an ad-hoc connection to the originating device.

      The beacon packet contained the string "BEEF", and the 2 flavors of ACK packets contained either "PORK" or "CHICKEN".

      I have no idea how we came up with this scheme, but it's probably floating around in production software....somewhere. I should have used "Brilliant!" instead, but I'm in the USA. :)

      --
      With the first link, the chain is forged.
    6. Re:Wasn't this... by MrNemesis · · Score: 1

      Agreed, my friend has never been able to recover anything from a drive that's been zeroed/100% overwritten. They have contractors with microscopes in a clean room that they sometimes use to recover bits from the bare platters (when the drives are fucked and can't be repaired), but it's so expensive and unimaginably painfully slow that it's practically never done, and getting stuff off that's been overwritten is utterly impossible.

      Speaking of which, if anyone's ever seen the analogue data coming off a drive head, you'd be amazed that even a fully working drive can have a controller that understand that gibberish. Trying to cipher deleted data out of that mess would be... challenging.

      --
      Moderation Total: -1 Troll, +3 Goat
    7. Re:Wasn't this... by MrNemesis · · Score: 1

      Agreed that there's need to be a lot of rapid juggling done by the forensics and legal sides.

      I'm wondering if laws will be pushed through to allow SSD's to be powered on with the GC/TRIM/Secure Erase functionality of the controller disabled; essentially a god/basic mode so that drives can remain in a legally safe area like with write blockers.

      TTBOMK there's nothing like that in the pipeline at the moment, so yes, you're right in that the next few years will be crucial. You'll need to be able to take the controller out of the loop entirely to ensure forensic integrity, as well as giving you access to the spare area but... well, it's early days yet.

      I should ask my friend if any new products are popping up to deal with SSD's; bypassing the controller should be relatively simple, re-assembling the bits from the chips in a controller-specific fashion won't be.

      Thanks for the reply by the way, always nice to see the author participate with their audience.

      --
      Moderation Total: -1 Troll, +3 Goat
    8. Re:Wasn't this... by MrNemesis · · Score: 1

      I have no idea how we came up with this scheme

      If it's anything like most of the... how to put this politely? ...idiosynctratic naming schemes I've seen dotted about, it's frequently a combination of office high jinks, deadlines and higher than normal blood alcohol content :) Not to mention continuing the fine tradition of nonsensical metasysntactic variables.

      We've got an app whose logs are full of BISH, BASH and BOSH which are used as exit flags for certain DB operations and some sort of reporting app that has PUGH, PUGH2, BARNEY, MCGREW, CUTHBERT, DIBBLE and GRUBB all over it. http://en.wikipedia.org/wiki/Trumpton

      --
      Moderation Total: -1 Troll, +3 Goat
  25. Re:And the downside here is... by GameboyRMH · · Score: 1, Informative

    When Mindy the undergrad accidentally deletes her term paper and would be really REALLY grateful for a super smart and kinda cute geek to go in and recover the file with Backtrack...

    OH NOES, what will I ever do without being told "thank you" and about what a nice guy I am.

    Yeah it never goes any further than that outside of geek fantasies.

    Not even in pornos. <-- business opportunity

    --
    "When information is power, privacy is freedom" - Jah-Wren Ryel
  26. Re:And the downside here is... by mysidia · · Score: 1

    When Mindy the undergrad accidentally deletes her term paper and would be really REALLY grateful for a super smart and kinda cute geek to go in and recover the file with Backtrack... then you'll see the downside.

    That's where da recycle bin comes in.

  27. Re:And the downside here is... by cskrat · · Score: 2

    Most geeks that would try to leverage something like that to get laid will still fail at getting to the getting laid part.
    Most girls that would dangle that sort of carrot know that teasing is just as effective as giving where geeks are concerned.

    --
    My God! It's full of eval()'s.
  28. Not sure what's confusing... by malzfreund · · Score: 1

    (1.) It may be hard to securely erase an SSD. Due to things such as wear leveling, the relationship between sector addresses and physical flash cells isn't transparent to the OS. And ATA Secure Erase isn't implemented or isn't implemented correctly on all SSDs. (2.) SSDs are hard to recover. That's because they may start erasing some blocks containing data (and not just the entry in the file allocation table) shortly after you delete a file in the file system. Again, this happens due to things such as wear leveling and isn't transparent to the OS. Contrast this to a hard drive where, following a file delete, only the entry in the allocation table is deleted but no actual data. I don't see anything contradictory or confusing here

  29. Right to easily spy on you? by Ossifer · · Score: 2

    Why does the government have this expectation that technology should be built in order to make it easy to spy on citizens?

    1. Re:Right to easily spy on you? by dave562 · · Score: 2

      Why does it always come down to the "government spying on citizens". There are plenty of uses for digital forensics that do not involve tin-foil hats. The only time the government is going to doing forensics on a drive is during a criminal investigation. Those investigations are well documented.

      Look at it from the other side of the coin. "Well your honor, we know that those bastards at Enron cooked the books, and we have the data... but the MD5 fingerprint does not match, so all of that evidence is inadmissable." or "Yes your honor, we know Madoff was running this crazy Ponzi scheme. We have all of his drives and data, but the MD5 fingerprint does not match because the garbage collection on the drive ran. You're going to have to let him go because the evidence is 'tainted'."

    2. Re:Right to easily spy on you? by pushing-robot · · Score: 1

      Because the ability to destroy vast amounts of data all over the world in an instant is rather new and makes the prosecution of white-collar crime much, much harder?

      And because sending ninjas in to steal the hard drives of 300,000,000 people and attempt data recovery is hardly an efficient way to
      "spy" on citizens?

      And because in the real world, the governments you have to worry about don't give a damn about evidence or legal process?

      --
      How can I believe you when you tell me what I don't want to hear?
    3. Re:Right to easily spy on you? by cbope · · Score: 1

      Because if you are trying to hide something, you must be guilty. At least that's the line the government will use to justify mandating backdoors in everything before long. The government has proven beyond any reasonable doubt that they will abuse their power if you let them. The only question is, how long will you let them?

    4. Re:Right to easily spy on you? by jbolden · · Score: 1

      Well your honor, we know that those bastards at Enron cooked the books, and we have the data... but the MD5 fingerprint does not match, so all of that evidence is inadmissable."

      That evidence doesn't have to be inadmissible. But Enron would get to argue the police changed the data and would get to call witnesses to that effect and the jury would have to decide.... Basically in allows for the evidence to be suspect.

  30. Re:And the downside here is... by Tumbleweed · · Score: 2

    Business Tip #1: Get payment up front.

  31. Re:And the downside here is... by cayenne8 · · Score: 1

    You seem to think you're entitled to sex for helping someone with computer issues, or that a "thank you" is insufficient payment for a favor: I'm guessing you don't get told you're a nice guy very often.

    Nice guys don't get laid as much either....

    --
    Light travels faster than sound. This is why some people appear bright until you hear them speak.........
  32. Re:And the downside here is... by rogueippacket · · Score: 1

    Protip: Put up a fake "progress" bar on the screen while you are "recovering" the files. Set it for something like 20 minutes. Now you at least have a chance to talk to a girl for that time, unless you're a real sucker and you let her find an excuse to leave you alone for 20 minutes.

  33. This is not new... by bradley13 · · Score: 1

    I don't now remember what the case was, but: a few months ago a read about a guy who was charged with some crime or other. They were unable to convict him of whatever it was, but they did convict him of obstruction of justice. Why? Because the computer forensics expert stated that he had deliberately deleted some files and then run a defrag.

    --
    Enjoy life! This is not a dress rehearsal.
    1. Re:This is not new... by maxwells_deamon · · Score: 1

      I think the following is true:

      I can securely delete things that I am not required to keep just like I can shred old paper documents as long as I do not suspect they may be needed for evidence. I can have a policy that all drives being transfered from one building to another must be securely wiped. In general I can do this type of wipe everyday.

      However, if I am sued or known as being investigated I generally need to stop destroying any records that might be needed for the investigation.

      If I am sued about the XYZ accident, I will go to jail (ideally) if I then wipe all the computers/files of anyone who worked on XYZ.

      This is why companies have deletion policies.

    2. Re:This is not new... by icebike · · Score: 1

      I don't now remember what the case was, but: a few months ago a read about a guy who was charged with some crime or other. They were unable to convict him of whatever it was, but they did convict him of obstruction of justice. Why? Because the computer forensics expert stated that he had deliberately deleted some files and then run a defrag.

      Without a link, I can only assume this is a hypothetical case.

      In any event, once served with a warrant or arrested, deletions become destruction of evidence.
      Until then, you can delete to your hearts content.

      Its all a matter of timing.

      --
      Sig Battery depleted. Reverting to safe mode.
  34. Defense may get to observe ... by perpenso · · Score: 1

    I think I've read somewhere that evidence has also be reproducible by the defense. If you destroy the device in the process of recovering data, that might be hard to do; or not ... I'm just guessing really.

    I think some tests inherently destroy evidence. For such cases it may be that the defense has the right to observe the testing to ensure that it was done properly.

  35. Should not matter by fluch · · Score: 1

    In case the harddrive is full disc encrypted it all should not matter...

  36. Re:And the downside here is... by Vegeta99 · · Score: 1

    You don't get laid too often being a dick either.
    (Or by tryin to get laid for undeleting a file)

  37. Re:And the downside here is... by larry+bagina · · Score: 3, Funny

    Only a problem if the retard windows admin disabled the recycle bin because it interfered with his OCD.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  38. Re:And the downside here is... by Vegeta99 · · Score: 1

    except a lot of SSDs come in USB key form and Winderz deletes files off those immediately.

  39. Difficult to create data with soldering iron ... by perpenso · · Score: 1

    ... which might be considered tampering and leaves room for the other side's lawyers to ask "and then you took a soldering iron to a delicate IC?" ...

    Because the odds of the randomly generated bits creating an email to Bernie Madoff discussing the ponzi scheme falls within a range considered to be reasonable doubt? You would need a fairly ignorant and gullible jury to buy that ... oh wait ... OK that may work for a celebrity defendant but I wouldn't count on that saving the average guy.

  40. Re:And the downside here is... by HungryHobo · · Score: 1

    actually my girlfriend of 4 years I first started going out with her after coding a trivial little java app for her final year project.
    so it does sometimes go beyond "thank you".

  41. Re:And the downside here is... by Asic+Eng · · Score: 3, Insightful

    I think it's about impoliteness when asking favors. Friends help each other: I'm quite ok fixing my non-technical friend's WLAN, just as he's ok with giving me a hand when I'm moving houses. That's the social norm, and thus asking someone for a favor also indicates how you feel about them.

    So if you don't like someone, if you would under normal circumstances not want to spend time with them - then you don't ask them for favors. That would be plain rude.

    If you don't have an actual friend to provide tech services - just purchase said services.

  42. Re:And the downside here is... by Anonymous Coward · · Score: 2, Insightful

    It's nearly orthogonal. Confidence and power are what counts. Being nice or a jerk, while displaying weakness or impotency, won't get you anywhere. Being a jerk sometimes projects the illusion of strength, true; but it's not necessary. Being nice without being wishy-washy and fawning is best for a long-term relationship.

  43. Re:And the downside here is... by lwsimon · · Score: 3, Funny

    You often get laid for being a dick. Hell, if you're in the right place at the right time, with low enough standards, you can get laid just for *having* a dick.

    --
    Learn about Photography Basics.
  44. Re:And the downside here is... by cayenne8 · · Score: 2

    Being nice without being wishy-washy and fawning is best for a long-term relationship.

    Err...we're talking about getting laid often here...not long term relationships.

    --
    Light travels faster than sound. This is why some people appear bright until you hear them speak.........
  45. Good by Murdoch5 · · Score: 1

    My data shouldn't be easy to get off, I know a while ago there was a post about SSD's being high risk for data but now it appears there more safe? If the police want my data they can figure out how to get it off, of course if I'm doing something illegal I'd have it highly encrypted but then again why would I care. They want the data they can work to get it!

  46. Re:And the downside here is... by Opportunist · · Score: 1

    Getting told that I'm a nice guy or getting laid... decisions, decisions...

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  47. Re:And the downside here is... by Opportunist · · Score: 1

    You ... you mean ... you mean it didn't really take her 30 minutes to wash her hair?

    *sob* Why did you have to tell me?

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  48. Re:Difficult to create data with soldering iron .. by lwsimon · · Score: 5, Funny

    Plaintiff's Attorney: "Sir, what are the chances of the drive automatically generating the exact sequence of bits required to form this email?"

    Expert Witness: "Billions to one, certainly."

    Defendant's Attorney: "And how many times will that this 2KB email fit on the drive?"

    Expert Witness: "Well, it's a 2TB drive, so... about a billion, give or take."

    Defendant's Attorney: "So, assuming the data on the drive is random, then it's safe to say there are at least two billion opportunities on this drive to produce this email?"

    Expert Witness: "That's not what I meant..."

    Defendant's Attorney: "Yes or no?"

    Expert Witness: "Well, yes, but..."

    Defendant's Attorney: "No further questions"

    --
    Learn about Photography Basics.
  49. Re:And the downside here is... by ByOhTek · · Score: 1

    I miss Mindy. She was in my freshman English class- long, long ago. We worked on a project together. Unfortunately she had a fiance. She also never needed any computer assistance.

    --
    Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
  50. Re:Go figure. by natehoy · · Score: 1

    "'dd' is not recognized as an internal or external command, operable program or batch file."

    Thank goodness for the inherent security in Windows. If I had run that in Linux, who knows what could have happened? ;)

    --
    "This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
  51. TRIM by Andy+Dodd · · Score: 4, Interesting

    It used to be the drive remapping meant that if you deleted something (or even overwrote it), there was no guarantee it would be gone - SSD controllers do wear leveling to avoid having part of the drive get used excessively. Forensic analysts could go pull the raw data from the NAND flash.

    The problem was that the wear leveling algorithms need a "free block" pool to work well. Drives that have been used heavily deplete the free block pool, and the drive slows down. For a long time, SSDs would have no knowledge of whether a file had been deleted or not.

    The ATA TRIM command was added for just this purpose - with TRIM, when the OS deletes a file that references a block, it can tell the SSD controller that those blocks are free. The SSD controller will then begin erasing those blocks in its free time. (SSDs can be written one block at a time, but must be erased one page at a time. A page consists of multiple blocks. Oh, and I may have page/block swapped here.) So you get a lot of performance improvement by having a bunch of pre-erased pages - these can just have individual blocks written without a read/erase/modify/write on a whole page.

    Pre-TRIM, SSDs were probably great for forensic analysts. Post-TRIM, SSDs are not. Oh, and I think the latest ATA standard added a "sanitize" command to make life easier for information assurance types, for whom SSDs have always been a pain.

    --
    retrorocket.o not found, launch anyway?
    1. Re:TRIM by Rockoon · · Score: 2, Informative

      You have your terminology backwards. The industry standard is to refer to the erase units as Blocks and the read/write units as Pages.

      --
      "His name was James Damore."
    2. Re:TRIM by Andy+Dodd · · Score: 1

      Whoops. (I wasn't sure, hence my comment that I might have swapped the two)

      --
      retrorocket.o not found, launch anyway?
  52. Re:Go figure. by Ossifer · · Score: 1

    Especially on Linux systems with more than 23 physical drives!

  53. Finally by JackSpratts · · Score: 1

    Some good news for a change.

  54. Re:And the downside here is... by bluefoxlucid · · Score: 1

    To be fair, unless that girl is a completely worthless cunt, there's probably some pair bonding going on for generosity and helpfulness, you know. So you get a girl that is nice and grateful for the help and likes talking to you and bakes cookies. Maybe somewhere down the line you get laid, maybe not.

    Point is it's a good ice breaker and it makes you useful.

  55. This is great news by Cito · · Score: 1

    This is great news for r@ygold, hussyfan, kingpass, vicky series collectors course knowing hard drive manufacturers they will cripple the ssd's somehow so they keep ghosts of the files like older drives did

    1. Re:This is great news by graeme_ssd · · Score: 5, Informative
      "This is great news for r@ygold, hussyfan, kingpass, vicky series collectors course knowing hard drive manufacturers they will cripple the ssd's somehow so they keep ghosts of the files like older drives did" Hey there,

      Not likely in this situation - here, the GC isn't killing the data for the hell of it, it's killing it because it needs to reset the cell preemptively in order to maintain drive performance at a high level. If you preserve the data in the manner of an old HDD, you nuke performance by forcing the controller to do a reset before future writes.

      Graeme.

    2. Re:This is great news by assemblerex · · Score: 2

      YOU SHOULD REALLY WARN PEOPLE about what you posted! I googled to see what you were talking about and now I'm worried google thinks I'm a pedo thanks to you.

  56. Re:Go figure. by natehoy · · Score: 1

    Heh, good point. I suspect sda and sdb would be safe.

    Especially since it appears that the command is copying from sdx to random, and not the other way 'round.

    --
    "This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
  57. Re:And the downside here is... by GameboyRMH · · Score: 1

    You seem to think you're entitled to sex for helping someone with computer issues, or that a "thank you" is insufficient payment for a favor: I'm guessing you don't get told you're a nice guy very often.

    Uh, what?

    AC breaks it down for you:

    http://slashdot.org/comments.pl?sid=2017726&cid=35349690

    --
    "When information is power, privacy is freedom" - Jah-Wren Ryel
  58. Re:Go figure. by grumbel · · Score: 1

    That won't work. First of you want your outfile (of) to be the drive, not the infile (in), as writing your drives content to /dev/random won't do any harm. Secondly you really don't want to use /dev/random, as real randomness is extremely slow on your average system, in the order of 5bytes/second, which would take some 500 years to fill up your 80GB SSD drive. So:

    dd if=/dev/urandom of=/dev/sdx

    or just:

    dd if=/dev/zero of=/dev/sdx

  59. Re: Only criminals... by SimonTS · · Score: 1

    Only criminals are worried about protecting their personal data. Really? Doctors, lawyers, researchers, need I go on?

    Only criminals have guns. You what? Police are criminals in the US then? Soldiers are criminals?

    Grow up and get a new perspective.

  60. Re:Go figure. by nedlohs · · Score: 1

    Why would anyone regret that? Well other than if you were doing encryption at the time...

  61. An Abstract Problem by Shoten · · Score: 1

    So either SSDs are really hard to erase, or really hard to recover. I'm so confused.

    It's both. The internal optimization of SSDs includes, essentially, a degree of abstraction between what the computer says to do and what is actually done. With that kind of direct low-level control taken away, any task related to direct, granular control over what happens to what the computer sees as 'sectors' on a disk (but which don't really exist, since there is no such physical form) becomes unreliable. The reasons why it is unreliable differ between deletion and recovery, but the effect is the same and has the same basic root cause.

    --

    For your security, this post has been encrypted with ROT-13, twice.
  62. Re:And the downside here is... by CrazyDuke · · Score: 1

    All "Mindy" does is whine and pretend not to understand what happened until you fix it for her, then she will give you a courtesy thank-you and never talk to you again. You see, she's too busy trying to get knocked up by the biggest asshole she can find that still tells her what she wants to hear, natural selection and all. But, hey, at least you get to keep pretending you are a white night!

    --
    Any sufficiently advanced influence is indistinguishable from control.
  63. Re:Difficult to create data with soldering iron .. by bluefoxlucid · · Score: 1

    The expert witness is patently incorrect: Billions is 2^32, but with 2KB that's 2^2048 which is somewhere around a 1 with 616 zeroes after it.

  64. Re:Difficult to create data with soldering iron .. by tgd · · Score: 1

    Everyone involved in that exchange failed basic math.

    Assuming seven bit ANSI, that's not even five characters to get a billion combinations.

    And a 2k e-mail would be 2^2048 combinations.

  65. Re:Difficult to create data with soldering iron .. by kernelfoobar · · Score: 1

    Plaintiff's Attorney: "Sir, what are the chances of the drive automatically generating the exact sequence of bits required to form this email?"

    Expert Witness: "Billions to one, certainly."

    errmm, a quick run with numbers: 128 possible values for a single byte and lets say 1 KB messages, that would be 128^1024 possible combinations, wouldn't it? Which is WAY more than 'billions'. Not much of an expert that witness.

    --
    Here we go again!
  66. Request from one of the authors. by graeme_ssd · · Score: 2
    Hello everyone -

    I've spent the last hour writing replies for questions/comments on the thread using this throwaway account: could someone with uber-powers please mod them up a bit?

    Thanks very much in advance, and thanks also to everyone making suggestions/comments about the article. :-)

    Graeme.

    1. Re:Request from one of the authors. by ColdWetDog · · Score: 1

      Thanks for showing up.

      God, I miss floppies.....

      --
      Faster! Faster! Faster would be better!
    2. Re:Request from one of the authors. by Noughmad · · Score: 1

      For all I know, you might be a very important person, or an ubergeek, but asking for your posts replying to a Slashdot thread commenting your article to be modded up seems like a very pathetic thing to do.

      --
      PlusFive Slashdot reader for Android. Can post comments.
    3. Re:Request from one of the authors. by graeme_ssd · · Score: 1

      Hello Noughmad.

      I don't see anything unusual about being interested in having a discussion about my results with other people - in fact, I'd say that's pretty much the whole idea of scientific publication.

      Unfortunately, the way the comment moderation system is set up on this site makes it very hard to talk back and forth without help - new / temporary accounts are by default set to be almost invisible to casual readers. Given the choice between looking good from your perspective, and being able to easily engage in two-way discussion with interested slashdotters about SSDs and forensics, I'll take the latter :-)

      Graeme.

    4. Re:Request from one of the authors. by graeme_ssd · · Score: 2
      You're very welcome - it's wonderful being able to see how people are reacting to the findings...

      Graeme.

  67. Re:And the downside here is... by kyrio · · Score: 1

    +5 Truth.

  68. Re:And the downside here is... by avgjoe62 · · Score: 1

    The important thing here is not what that girl thinks of you for helping, but what she tells her friends about you. Having a woman tell other woman what a nice, helpful man you are will get you way more attention in the long run. Having a reputation as a good guy that is discreet will score way more points than a jerk that likes to brag.

    --

    How come Slashdot never gets Slashdotted?

  69. Re:And the downside here is... by kyrio · · Score: 1

    >white night

    He gets to pretend he's a snow covered winter's night?

  70. Re:And the downside here is... by similar_name · · Score: 1

    I had a boss tell me that getting laid was always a valid excuse for being late/absent to work.

  71. Melting aluminum in a flower pot by mangu · · Score: 1

    The melting point of a surface mount IC is a lot less than that of a spinning platter.

    Considering that all you need to melt a hard disk platter is a flower pot, a haird rier, and some charcoal that shouldn't be any problem.

  72. "So either SSDs are really hard to erase, or..." by graeme_ssd · · Score: 4, Informative
    "So either SSDs are really hard to erase, or really hard to recover. I'm so confused."

    Hello, I'm one of the authors of the paper. To explain the apparent paradox in rough terms:

    Drive data was traditionally purged manually, by having the computer tell the drive to write something else over the top of the old data. In the absence of such an overwrite, magnetically stored data persists. However, if you try that trick on an SSD, it may not work. The logical address you try to overwrite may be remapped on the fly, so that your 'overwrite' goes to some other physical cell rather than the one which stored the data. From a logical viewpoint, it looks like the overwrite worked - you can't access the data any more through your computer's OS. But from the drives point of view, the data is still there, lurking in some physical cell that is presently out of use as far as the logical sector list is concerned. A cunning firmware or a hacker with a soldering iron might still get at it.

    However, separately to this, modern SSD drives use tricks to try and automatically improve their performance, and one of these tricks is to pre-empetively wipe data cells that contain data no longer referenced by the filesystem. Here, the drive is actively attempting to permanently purge everything it can from the drive, all of it's own accord, in the interests of accelerating future writes by having a pool of completely unused cells available.

    Summary:

    - If you're a computer telling a drive to zero over some data, the drive may lie to you a bit, and not bother to zero it.

    - If you're a drive, you do whatever the heck you like, and you see the physical layer directly (unlike the computer). That means the drive can open up the NTFS metadata, looking for data cells which could be preemptively reset, and nuking that data out of existence (when it might traditionally have been recoverable to an expert).

    In summary. If your drive wants to nuke something, (and we've shown, they really DO want to nuke everything they can at a few minutes notice), it gets nuked. If your PC wants to nuke something, it may or may not get nuked by attempting an overwrite.

    Finally, separate to this is TRIM, which is a hybrid of the two situations - an ATA command by which the OS can signal to the drive that it would like the corresponding physical cell for a particular logical sector address to be nuked, thank you very much.

    Hope that clears things up.

    Graeme.

  73. Re: Only criminals... by Eudeyrn · · Score: 1

    Grow up and get a new perspective.

    *whoosh*

  74. Re:And the downside here is... by flaming+error · · Score: 1

    Unless it wasn't your boss that was late...

  75. Re: Only criminals... by RCGodward · · Score: 1

    Come on, even I knew that was supposed to be funny.

  76. Where to get these SSD? by F�an�ro · · Score: 1

    So, certain SSDs have a firmware "garbage collection" that analyzes the file system and marks blocks that are unused, even when the OS does not issue any trim commands.

    While perhaps a nightmare for forensics, this seems like a particularly useful thing for normal use.
    Presumably it only works for NTFS, but it would be very useful for windows xp, which I assume does not fully support TRIM.

    How can I tell which ssd supports this option?
    is there a marketing name for it?

    1. Re:Where to get these SSD? by graeme_ssd · · Score: 2
      "How can I tell which ssd supports this option? is there a marketing name for it?"

      A few drives offer it, with varying names and degrees of marketing fanfare, but there is little documentation as to the precise workings of the GC features. In the paper PDF you'll see the drive make/firmware for the drive we used in these experiments. You can buy that one if you like :-)

      Graeme.

  77. Re: Only criminals... by _0xd0ad · · Score: 1

    Whoosh.

  78. So what's the problem? by Anonymous Coward · · Score: 1

    OK, so police and intelligence agencies now have a very hard time reading the private data of other people. And yes, I can see how government worshippers who get agitated at the thought of any limit to the absolute power of governments might be upset at this.

    Myself, I don't think governments have any more right to peruse my private data on my private hardware than, say, Microsoft or AT&T do. So I don't find any problem here.

  79. Re:Difficult to create data with soldering iron .. by Megane · · Score: 1

    Actually the number of possible combinations are 2^(2048*8) bits. I'm just going to guess here that 2^16384 is more than the number of atoms in the galaxy, or even the universe.

    --
    #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
  80. Re:Difficult to create data with soldering iron .. by Megane · · Score: 1

    There's still "reasonable doubt" that the prosecution wasn't corrupt and faked the data, if you can't reproduce the recovery a second time. One time is good enough if you've lost important data, but not good enough for criminal evidence.

    --
    #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
  81. Re:And the downside here is... by Grishnakh · · Score: 1

    Exactly. Look how many women run after men who are in and out of prison. The fact is, women like assholes. No, these kind of relationships don't last long, but that doesn't matter: these men get laid all the time (frequently as soon as they're released from prison), plus they father lots of kids, so they get to pass their screwed-up genes on to the next generation.

    No, not all women are this dumb. But so many of them are, that being an asshole with a long rap sheet won't keep you from getting pussy and fathering a dozen kids. Sure, nice guys might succeed here and there in getting a wife and having a kid, but then that kid will be killed by one of the inmate's illegitimate kids during a crime. Eventually, we're going to have more criminals in the population than productive citizens.

  82. Re:Difficult to create data with soldering iron .. by jbolden · · Score: 1

    What about, not answering yes or no with a yes or no. Also the attorney can't cut the witness off, he can just say, "I wan'st finished answering". They don't have the right to edit / truncate your answers.

    Defendant's Attorney: "Yes or no?"

    Expert Witness: I was using "billions" metaphorically not as an exact figure. There is about 3240 characters in that email so it would occur randomly about 2^3240 ~ 10^1080

  83. Re:This is scary by Megane · · Score: 1

    You don't need the metadata, you just need the allocation table (an array of block IDs on some OSes, a bitmap on others), and enough superblock information to verify the filesystem type and find the allocation table. I guess this would be harder on filesystems that don't use an array or bitmap. I think ext2/ext3 uses free block lists spread sparsely around the drive. Also, partitioning the flash drive might complicate things, since most flash drives aren't partitioned.

    --
    #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
  84. Re:And the downside here is... by Grishnakh · · Score: 1

    Great, so the cute girl with computer problems tells her friends what a nice, helpful carpet mat you are, and at the least, this gets you a bunch more calls for free computer service (with nothing but a thank-you in return). At the best, they'll see you're single and fix you up with their massively-overweight girlfriend who can never get a date. Meanwhile, the cute girls whose computers you fix for free are dating the assholes on the college football team.

    You'll probably be more successful in dating one of these girls if you act like you're running your own computer repair business, use actual invoices and such, and charge her for the service. Then she'll think you're someone who's going to make lots of money as a businessman, and the thought of that always gets women wet.

  85. Re:And the downside here is... by GooberToo · · Score: 1

    When Mindy the undergrad accidentally deletes her term paper and would be really REALLY grateful for a super smart and kinda cute geek to go in and recover the file with Backtrack... then you'll see the downside.

    I still don't get it. The only difference is the phrase, "just friends", will be told to your face versus her just silently thinking it. So what is the downside?

  86. Re:And the downside here is... by mysidia · · Score: 1

    except a lot of SSDs come in USB key form and Winderz deletes files off those immediately.

    Er... Ok... what idiot would put their term paper on a USB key (except as a backup)?

    Seeing how easily USB keys are lost, accidentally dropped, or crushed, and how prone to failure the $5 electronics in them are. Putting the only copy of your termpaper on one is asking for trouble.

  87. Re:Difficult to create data with soldering iron .. by bluefoxlucid · · Score: 1

    you're right, although the relevance of the point still stands. Billions vs 1 billion is different from billions vs 10^616. But yeah.

  88. Re:Difficult to create data with soldering iron .. by maxwell+demon · · Score: 1

    This source estimates the number of atoms as 4*10^79, which is between 2^264 and 2^265, which is negligible compared to 2^16384. Even if the estimate should be a few dozen orders of magnitudes wrong, it still wouldn't come anywhere near.

    --
    The Tao of math: The numbers you can count are not the real numbers.
  89. So just disassemble the darn thing by davidwr · · Score: 1

    Sure, it makes forensic data recovery harder, but I see no reason other than $ that the feds can't disassemble the things, desolder the RAM from the controller, and attach it to their own custom-built data-extraction device.

    Sure, there may be some devices out there that are pretty much impossible to disassemble in this way, but I'm sure Congress will quietly pass a bill making any future device that isn't "forensically recoverable" in this way illegal without special government permission.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  90. It means hard to verify by spinkham · · Score: 1

    The same properties that make it hard to prove you deleted the contents make it hard to *prove* what the contents were. No surprise here really. SSDs are a b*tch no matter which side you're on.

    For hiding stuff, the best policy is to never store unencrypted data on the device. Install full-disk encryption, then data.

    For recovering stuff *to legal standards*.. Who knows. The courts are fickle at first, but standards of evidence will emerge over time.

    --
    Blessed are the pessimists, for they have made backups.
    1. Re:It means hard to verify by graeme_ssd · · Score: 1

      " but standards of evidence will emerge over time."

      Agreed! But, surely this will only happen if courts realise that new standards *need* to emerge because there is a problem with the old ones not keeping up with technology?

      Graeme.

  91. Re:And the downside here is... by tabrnaker · · Score: 1

    Certainly hope the app was just a trivial part of her project and not her actual project. Never a good idea to get into a relationship with someone who doesn't do things themselves.

  92. Re:Difficult to create data with soldering iron .. by lwsimon · · Score: 1

    You're missing the point, though. The questions isn't "are there are enough monkeys locked in the room to write the complete works of Shakespeare?" - it's about the fact that the numbers are extremely large, and difficult to comprehend for the average juror. If they don't understand the math, then there is a reasonable (in the mind of the juror) doubt.

    And yes, a lawyer can ask a yes/no question, and the judge will typically compel the witness to answer it in that fashion. There may be further discussion before or after, but a yes or a no will be the result.

    --
    Learn about Photography Basics.
  93. Sigh. I can haz ow-level interface? by davidwr · · Score: 1

    It's too bad - or perhaps good if the cops seized your PCs and you have a good lawyer - that the devices don't have both a "high-level" interface and a "low-level" interface, where the "low-level" interface gives you complete control over the device - no writes happen without your explicit say-so. Couple this with a "disable automatic background behavior" pin that's checked on power-up, and you should have a device that's not only forensically readable, but much easier to do scientific research or any other task that requires predictable repeatability.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  94. Re:And the downside here is... by An+ominous+Cow+art · · Score: 1

    I heard she shacked up with some crazed freak who called himself "Mork".

  95. Re:And the downside here is... by avgjoe62 · · Score: 1

    Don't be a carpet mat then.

    I do run my own computer business, with actual invoices and such, but I do not charge my friends for my services. Instead, we trade - a home-made dinner for getting rid of Anti Virus Studio 2010 and installing Avast, help painting my living room in exchange for setting up their wireless network, a bath and grooming for my dog after installing a new hard drive - nothing that costs me or them actual money, but we trade something of value.

    So it should be with the cute girl. Never do something for nothing and always, always schedule a time - just don't drop everything to rush over and help unless it is a genuine emergency. I always leave a couple of business cards with people so they can refer me easily. Make sure that people realize your time is valuable, but that you can help them. That's the way I've operated for fifteen years and the number of referrals I've gotten from helping friends has me happily busy.

    Word of mouth is the best advertising you can have, no matter if that is in business or in your personal life. You just have to work as hard to earn it as the dollars you would charge. And whether it is business or personal, YOU have to believe that what you offer is worth something.

    --

    How come Slashdot never gets Slashdotted?

  96. "Simple" solution by ymgve · · Score: 1

    The solution to this would be to add a new command to the ATA spec, call it FREEZE or something. If a drive receives this command, it won't do any writing/erasing, neither on its own or in response to ATA commands. Then you just create write blockers that also send this command.

    Of course, this both requires new drives and new write blocker hardware, so it probably won't be implemented.

    1. Re:"Simple" solution by graeme_ssd · · Score: 1
      "Of course, this both requires new drives and new write blocker hardware, so it probably won't be implemented."

      Who would buy it, knowing that the feature could be used against them? Also, there's the legacy problem.

      "Your honour, the defendant knowingly purchased an old SSD drive rather than one with ATA Freeze!"

      Graeme.

  97. Re:And the downside here is... by Grishnakh · · Score: 1

    Very good advice. The problem is that many geeks are tempted to give away their services for free to cute girls in school, in the hopes of a possible relationship, and it never happens. The girls just think of you as a carpet mat, a provider of free services, and certainly not as a possible romantic interest.

  98. Re:And the downside here is... by stoborrobots · · Score: 1

    Eventually, we're going to have more criminals in the population than productive citizens.

    Eventually? You mean that hasn't happened already?

  99. Re:Three words: Encrypt, encrypt, encrypt... by Skapare · · Score: 1

    If you encrypt the entire drive, the SSD firmware will have no idea which sectors are no longer referenced and can be deleted. You won't get the performance advantage of the SSD's speculative pre-erase. And if by chance your encryption gets exposed, it will not have overwritten those sensitive sectors in files you deleted that haven't yet been re-allocated to another file. But you'll probably be a little safer overall.

    --
    now we need to go OSS in diesel cars
  100. How to remove deleted data by Qatz · · Score: 1

    Want to wipe deleted data off a drive? It's really simple, there is a method I always use before making an image of a drive. dd if=/dev/zero of=/location_on_drive Wait for the file to use all the space on the drive then delete it. I use it to make drive ghosts more compressable. Though if you wanted it for privacy you could always source from urandom instead of zero.

  101. Re:Difficult to create data with soldering iron .. by blueg3 · · Score: 2

    You're off by so many orders of magnitude, it hurts.

    The chance of generating that particular e-mail, if it's 2 KiB, is 1 in 2^16384. (That's not really the number you want -- you want the chance of generating a similarly-incriminating e-mail. They're roughly equally improbable, though.)

    So that's 1 in 2^16384 compared to 2^30 copies of the e-mail that would fit on the drive.

    If the prosecution scoured every drive ever made for a random sequence of bits that looked like that e-mail, they'd never find it.

    Plus, the expert witness generally has a better and less technical answer. Defense lawyers don't ask technical questions like that: the expert witness will undoubtedly have an answer, and you'll bore the jury to tears, which they hate.

  102. Re:Who should I beleive? by graeme_ssd · · Score: 1

    "This story comes just 2 weeks after another story on slashdot saying that your data doesn't actually get deleted:"

    The two papers are similar in that they both highlight unexpected and poorly documented behaviours of real world SSDs that diverge from traditional hard disk behaviour, and raise issues for digital forensics and data recovery. The irony is that the USENIX authors have shown SSDs may not purge data even when you try your best to make them do so (i.e. a problem for information security); whereas here, we show they may purge data permanently when you don't want or expect them to (i.e. a problem for digital forensics & law).

    Graeme

  103. Re:Difficult to create data with soldering iron .. by hamster_nz · · Score: 1

    You are missing the point. "How many 2KB sets of data could be on the disk? A billion" is being played off against "What is the chance that this email appeared in random data? 128^1024" which is also true.

    So the weasel question is "So, assuming the data on the drive is random, then it's safe to say there are at least two billion opportunities on this drive to produce this email?" - (Actually it is even more - who says that the email needs to be byte aligned?).

    The answer is "Because the size of the email is relatively larfge there is about the same amount of chance as all the atoms in your underwear jumping a meter to the left in the next 5 seconds - it is very, very, very improbable".
     

  104. Re:Difficult to create data with soldering iron .. by gmhowell · · Score: 1

    Ever been to court? Whether you can answer more than "yes or no" to a "yes or no" is rather up to the whims of the bewigged asshat at the front of the room.

    --
    Jesus was all right but his disciples were thick and ordinary. -John Lennon
  105. Re:And the downside here is... by geminidomino · · Score: 1

    I guess it depends on how old you are and what you consider an "old lady." When I was in college, someone who was more years older than you than you'd been alive counted.

    IMNSHO You haven't scored until you've spent a sweaty night or three with a woman who's had a couple of decades to learn her way around a guy and to work up a good sense of adventure.

  106. Re:Difficult to create data with soldering iron .. by jbolden · · Score: 1

    Yes I have, I've testified in multiple trials. And the "bewigged asshats" have never pulled anything remotely like that.

  107. Re:Why two different (over)writing speeds? by Darinbob · · Score: 1

    Reading from Flash is fast. Writing to an erased area of Flash is slower, but not too bad. You can only write to areas that have been erased. Erasing a Flash block is sloooooooooow.

    Erasing turns all the bits to 1s in a block. Then turning a single 1 into a single 0 is relatively fast. However that 0 won't turn back into a 1 without an erase and the erase applies to a full block at once (64K or larger). Erasing involves applying some higher voltages for a certain duration of the right polarity, etc. This erase may take a few hundred milliseconds up to a second or more, depending on the type and how many times you've erased the block before.

    Flash is like an Etch-a-Sketch. Writing means you just turn the knobs. But you can't un-write anything by turning the knobs. Instead you have to pick up the Etch-a-Sketch and hold it upside down and shake vigorously. Ok, silly analogy but I couldn't think of an automobile one. Or they're a bit like the old PROMs where you could only erase them by holding a window under a UV light for a period of time.

  108. Re:Difficult to create data with soldering iron .. by exomondo · · Score: 1

    Which is WAY more than 'billions'. Not much of an expert that witness.

    lol...well it is billions, just an absolute freakin' shitload of billions ;)

  109. Mainframes/Minis/Servers by jbolden · · Score: 1

    Well what are the laws right now for servers? Mainframes/Minis/Servers for decades have had automated processes running on them. They have all sorts of custom data formats so you can't use standardized tools....

  110. Re:Difficult to create data with soldering iron .. by gmhowell · · Score: 1

    Lucky you.

    --
    Jesus was all right but his disciples were thick and ordinary. -John Lennon
  111. Re:And the downside here is... by toddestan · · Score: 1

    Lots of people sadly. Heck, it wasn't that long ago that people would unwisely carry around the only copy of their termpaper on a floppy disk. If you think USB thumbdrives have issues...

  112. Re:Difficult to create data with soldering iron .. by jbolden · · Score: 1

    Well it was never my money at stake.

    What judge would want:

    During appeal: "Mr Bolden you were cut off by the judge is that correct"
    JB: Yes
    DA: Does this answer accurately reflect your opinion at the time?
    JB: No
    DA: Could this answer have misled the jury
    JB: Yes.

    etc...

  113. Re:Difficult to create data with soldering iron .. by gmhowell · · Score: 1

    Ah, I see the trick: better attorneys than I could afford.

    --
    Jesus was all right but his disciples were thick and ordinary. -John Lennon
  114. Re:And the downside here is... by TheLink · · Score: 1

    Yeah. The nice guys won't sleep around because they know most girls don't really like it.

    The bad guys on the other hand don't care about such stuff.

    --
  115. This is news? by Pyrion · · Score: 1
    --
    "There is much pleasure to be gained from useless knowledge." - Bertrand Russell.
  116. Trim support in win7 by leuk_he · · Score: 1

    Isn't it more like that window7 support TRIM, meaning that it will issue a trim command to the SSD after a delete? The SSD firmware already has enough worries then to dive into a native file system.

  117. Re:And the downside here is... by HungryHobo · · Score: 1

    oh no.
    it was all above board.

    it was for the data collection step: she needed prompts/information to appear on the screen for a very specific amount of time then for it to prompt people for answers.

    I got an appendix.
    Her supervisor even asked me about coding up a couple more for other students.

  118. Help! by warGod3 · · Score: 1

    SSDs can do this? Call me when they can do STDs and I'll be more impressed.

    --
    "Be polite, be professional, but have a plan to kill everybody you meet." General James Mattis
  119. Re:"So either SSDs are really hard to erase, or... by Enigma23 · · Score: 1

    So does running the Linux command shred completely obliterate data stored on an SSD, or not?

    --
    Ceci n'est pas une .sig
  120. Why do people always equate SSD = HDD FTL + flash by funky_vibes · · Score: 1

    A typical SSD is hampered by it's HDD FTL that *cannot* know what you want to do, so all operations except reading are very slow.
    The only reason we use the HDD FTL is because of some operating systems don't support any good filesystems.

    Since flash memory is different than a HDD, pretending it's not, is always going to be a headache, and cause unintended problems for the user.

    It seems retarded that FTL coders are now trying to second-guess the operating systems by trying to understand what filesystem *may* be on it.
    This will obviously cause any amount of headache for users, if data written on the block device just happens to look like fat32 or ntfs...

    There's a much cooler and older technology out there, which is connecting flash directly to any of your fast buses. And using a modern filesystem that works well on flash, such as ubifs.

    Nokia n900 was a good device to test the pros and cons of using flash directly (via ubifs) or indirectly on an MMC.
    The performance on the direct flash memory totally overwhelms that of the indirect memory. in addition, you know things like bad blocks, can execute in place, append and proper compression support.

    And most likely your flash memory will last a decade longer in normal use.

    Most importantly, using flash directly makes this article pointless, since you *know* what has and hasn't been deleted.

  121. Re:Difficult to create data with soldering iron .. by Bengie · · Score: 1

    On a magnitude scale, you would have reached atoms in the known universe not too long after 2^256. 2^16384 is thousands of magnitudes more than that.