1. bitek's Avatar
    I hope it is secure. I just sold my 16GB and bought 64GB. I did secure wipe and did not bother to make sure it is properly done !
    01-11-12 06:09 PM
  2. FourOhFour's Avatar
    My idea involved writing and rewriting the flash drive with random stuff
    The funny thing about flash filesystems is that the controllers which drive them use wear-leveling algorithms and shuffle flash sectors around underneath the user (eg. the OS) for performance reasons -- it takes too much time to cache/erase/rewrite a flash sector to be usable in practice.
    Overwriting a file with 0's or 1's or random data does not guarantee that the physical sector on the flash chip has been erased.
    That being said, I asked around a bit and like peter9477, I was satisfied with the responses I got. Enough so that I would be comfortable with someone desoldering a flash chip and attempting to recover data off it using anythng less than a scanning electron microscope.
    01-11-12 07:41 PM
  3. BuzzStarField's Avatar
    The funny thing about flash filesystems is that the controllers which drive them use wear-leveling algorithms and shuffle flash sectors around underneath the user (eg. the OS) for performance reasons -- it takes too much time to cache/erase/rewrite a flash sector to be usable in practice.
    Overwriting a file with 0's or 1's or random data does not guarantee that the physical sector on the flash chip has been erased.
    That being said, I asked around a bit and like peter9477, I was satisfied with the responses I got. Enough so that I would be comfortable with someone desoldering a flash chip and attempting to recover data off it using anythng less than a scanning electron microscope.
    In a sentence or two can you tell me about defragging a flash chip. Or is concept n/A since there a no moving heads to wear out and slow things down? Is the wear you are talking about related to maximum number of times you can switch a bit's state before it stops responding?
    01-11-12 08:33 PM
  4. peter9477's Avatar
    Defragging is largely a moot concept if it takes the same time (roughly zero) to get to all parts of the storage space.

    The thing with wear-levelling, which as you guessed is because there's a fuzzy upper limit on how many times you can burn a bit (change from a 1 to a 0), is that you basically try not to write to any given page in flash (lets call that a 1K block, for kicks) more often than you write to any other page.

    You also can't unburn (erase, change from 0 back to 1) individual bits, but have to do an entire page (or more) at a time.

    If you need to modify some data, you (roughly speaking) read the data for the entire page into RAM, modify it there, then write the entire page back out to a fresh (erased) location elsewhere in flash.

    If possible, you probably "rotate" your writes across the entire address space over time, to ensure you're covering the whole area about equally.

    If your filesystem is particular sophisticated, you probably even do some behind-the-scenes juggling from time to time to move data from rarely modified pages to areas that have seen too much action, again to keep the "wear" roughly equal all around.

    I'm speaking somewhat from theory, as I've only built the most simplistic flash filesystems myself, but the basic principles above should translate to the PlayBook's flash memory (made by Samsung, I believe) and qnx flash filesystems pretty well.

    You'll perhaps see in the above why just trying to "write zeros on top of the data" may not work out so well: the lower levels of the filesystem and the flash memory device may just be writing your zeros into a fresh page somewhere, burning all those bits but leaving the other ones untouched. (More likely they'll get erased and become available for reuse around the same time, but I doubt there are many guarantees about that, except through the secure wipe.)

    (And yes, I can count... for me that is a "sentence or two"! :-) )
    BuzzStarField and tangyboy like this.
    01-11-12 08:45 PM
  5. BuzzStarField's Avatar
    @peter9477
    Because of your rather lengthy second sentence, you got me thinking about something else that has bothered me about flash drives - that is, some are cheap and others identical in capacity cost an arm and a leg. I had always assumed that this was because of brand recognition but is also due the the sophistication of the controller and also the quality/longevity of the media itself? If I get a cheap one do I risk an early failure? In addition, one last question, which is likely to fail first on my PB, the flash chip or the battery?

    Please don't spend a lot of time on this- one sentence would do nicely.
    01-11-12 09:13 PM
  6. peter9477's Avatar
    ... I had always assumed that this was because of brand recognition but is also due the the sophistication of the controller and also the quality/longevity of the media itself? If I get a cheap one do I risk an early failure? In addition, one last question, which is likely to fail first on my PB, the flash chip or the battery?

    Please don't spend a lot of time on this- one sentence would do nicely.
    1. No idea.

    2. Battery.
    Hgouck and BuzzStarField like this.
    01-11-12 09:21 PM
  7. Hgouck's Avatar
    Y'all are definitely more knowledgeable than I on the workings of a flash drive and how it operates. I have a friend (I know, we all have friends) who works within the police departments computer data retrieval department. I was curious about how secure a BB smartphone was that had been "security wiped" before I gave it away. I ran the security wipe twice on my old 9650 BB and gave it to him. He was unable to retrieve anything off it.
    Not to say it can't be retrieved but I was happy with that. Personally, if the information was in need of absolute security that no one was able to retrieve it I would never give it to someone else. And I would break it into small pieces and throw them away in different locations.
    BuzzStarField likes this.
    01-11-12 10:08 PM
  8. FourOhFour's Avatar
    In addition, one last question, which is likely to fail first on my PB, the flash chip or the battery?
    The typical lifespan on these things is on the order of hundreds-of-thousands into the millions of write/erase cycles per sector before bits start sticking. Even so, the controllers can detect failures and either retry or stop using those pages entirely. As the chips age, they may start to take longer to perform erase operations (usually on the order of a few hundred ms or so). After a certain threshold (say 10x beginning-of-life erase-time), the sectors may be marked unusable.

    As for wear-leveling, peter described it well. Imagine a database that was accessed constantly. If you didn't read-copy-rewrite those sectors elsewhere on the flash chip, you would quickly approach the erase/rewrite cycle limit on the chip for the busiest blocks in the database (usually erase first). Also, the time to rewrite the data in those blocks would be horrible as you would have to wait for them to be erased first.
    The flash controller maintains a list of unused pages that are quietly erased in the background during periods of low activity so that there is always a fresh supply ready to go.
    A very clever system may be even able to detect that 25% of the data on the flash has never changed, and when the performance on the rest of the device has degraded, maybe it's time to start migrating those static files into the low-performing sectors in order to free up the younger, fresher sectors that they've been occupying all this time for r/w use by others.
    01-11-12 10:26 PM
  9. space_traveler's Avatar
    I do apologize if I offended you with my remarks. My clumsy attempt at humour was more directed at myself and the strange thoughts that crossed my mind when I considered the poster's question about paranoia.
    No problem. I probably flew off the handle a bit myself. All is forgotten. Peace.
    01-11-12 10:52 PM
34 12
LINK TO POST COPIED TO CLIPBOARD