why SSD is better than HDD in terms of privacy

Antivirus, forensics, intrusion detection, cryptography, etc.
Post Reply
Message
Author
labbe5
Posts: 2159
Joined: Wed 13 Nov 2013, 14:26
Location: Canada

why SSD is better than HDD in terms of privacy

#1 Post by labbe5 »

With HDD, accidental delete of data, for example a folder of photographs, was recovered with the help of such apps as photorec, testdisk, scalpel, foremost, etc, since only a logical delete was done. The process was : no rewrite of HDD until all data lost are recovered.

On the other hand, with SSD, logical delete is immedialtely followed with a physical delete, to help with performance, so no apps can retrieve what has been accidentally deleted. Using photorec with SSD, you only will get junk.

So, if you have your precious data on SSD,, even your backups, be careful. When it is gone, it is definitely gone.

On the other hand, there is a positive side. When you willingly delete data, it is most likely definitively gone. No such apps as testdisk can be used to recover your data.

For the purpose of privacy, this is a positive side.

Further reading :
As mentioned in AJ's answer, traditionally when you "delete" a file the operating system (Windows 8 in this case) simply tells the hard drive that the file is no longer needed and the hard drive marks that file as unneeded but doesn't actually remove the data. This is a "logical delete." Actually removing the data is a "physical delete." With file-recovery software you can recover a "logically deleted" file because the data may not be gone yet.

However, SSDs have a featured called TRIM which immediately follows a logical delete with a physical delete. This improves the performance of the SSD, but comes with the cost of making file recovery impossible. I don't use Windows much, but from what I can tell this feature is enabled by default.

Because of this the "files" that were recovered are almost assuredly just filled with junk and there's no remnant of the original data left.

You can check if this feature is currently enabled on Windows 8 by opening a command line and entering the following: fsutil behavior query disabledeletenotify which will tell you the value is either 0 or 1. 0 means TRIM is enabled (the variable name is "disabled", so 0 is NOT disabled).

I've made this mistake too. It's a harsh lesson about the importance of proper backups.

https://photo.stackexchange.com/questio ... -files-can

april

#2 Post by april »

I disagree with this

I had a USB stick (a valid SSD Solid State Device) with 18 pictures on it .
I formatted that
I made a new FAT32 system

I ran Testdisk on that and it gave me no pictures recovered
I put one picture .jpg file on it
I deleted that
I ran Testdisk again

It picked up 19 pictures complete and accurately saved and displayed them .
Last edited by april on Tue 17 Jul 2018, 09:51, edited 1 time in total.

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#3 Post by nic007 »

You recovered something after doing a complete reformat of the filesystem? Impressive.

LateAdopter
Posts: 361
Joined: Fri 27 May 2011, 17:21
Location: Reading UK

#4 Post by LateAdopter »

An SSD has no knowledge of the filesystem. Deleting a file does not delete the data, it marks the space as unallocated.

If you mount the device with -o discard, then a linux filesystem driver (not NTFS) can tell the SSD to unmap the LBAs as soon as they are deallocated.
But this is not the default and can be quite tricky to get working through a USB to SATA bridge.

Alternatively if you run fstrim on the device (not VFAT) the linux filesystem driver will tell the SSD to unmap all unallocated LBAs, regardless of whether they are mapped or not.

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#5 Post by nic007 »

LateAdopter wrote:An SSD has no knowledge of the filesystem. Deleting a file does not delete the data, it marks the space as unallocated.

If you mount the device with -o discard, then a linux filesystem driver (not NTFS) can tell the SSD to unmap the LBAs as soon as they are deallocated.
But this is not the default and can be quite tricky to get working through a USB to SATA bridge.

Alternatively if you run fstrim on the device (not VFAT) the linux filesystem driver will tell the SSD to unmap all unallocated LBAs, regardless of whether they are mapped or not.
Wouldn't a complete reformat overwrite existing files?

LateAdopter
Posts: 361
Joined: Fri 27 May 2011, 17:21
Location: Reading UK

#6 Post by LateAdopter »

No.. You can tell it doesn't write the data because that would take a LONG time. A reformat just rewrites the filesystem.

With VFAT that is the FAT and the root directory. The subdirectories and the files are in the data area and are not touched.

This can rarely cause a problem if you reformat from one filesystem to another. Remnants of the previous filesystem can confuse the filesystem type detection.

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#7 Post by nic007 »

LateAdopter wrote:No.. You can tell it doesn't write the data because that would take a LONG time. A reformat just rewrites the filesystem.

With VFAT that is the FAT and the root directory. The subdirectories and the files are in the data area and are not touched.

This can rarely cause a problem if you reformat from one filesystem to another. Remnants of the previous filesystem can confuse the filesystem type detection.
Not necessarily a long time. For instance some delete programs (like CCleaner) can delete files so that it can not be recovered (for normal drives that is, not sure about SSD but I guess that would include SSD drives). But I get your point ablout reformating (although I have never been able to recover files on a non-SSD drive after a complete format not just a quick format/erase).

User avatar
Moat
Posts: 955
Joined: Tue 16 Jul 2013, 06:04
Location: Mid-mitten

#8 Post by Moat »

I recall reading Trim is part of an SSD's onboard firmware, and USB flash drives normally don't (ever?) have and/or utilize it - which could explain April's above mentioned case.

Bob

User avatar
Burn_IT
Posts: 3650
Joined: Sat 12 Aug 2006, 19:25
Location: Tamworth UK

#9 Post by Burn_IT »

Trim usually takes place during long periods of inactivity and while the drive is present. USB Flash drives tend to be transient and formatted as superfloppies so the handling is going to be different.

I always try to change the control bit on all my flash drives so that they ARE treated as hard drives.
There are upsides and downsides to this, though the downsides are easy to overcome.
The upside is that file writes can be buffered and thus free up the OS quicker.
The downside is that you should always either "safely remove" or "eject" the drive from the OS and wait for the acknowledgement before removing the drive or data will be lost. It is always better to do this anyway.
"Just think of it as leaving early to avoid the rush" - T Pratchett

april

#10 Post by april »

Burn_IT wrote:I always try to change the control bit on all my flash drives so that they ARE treated as hard drives.
So what bit do you change and how? Is it a flag?
Attachments
capture17817Smaller.png
(206.45 KiB) Downloaded 236 times

User avatar
Burn_IT
Posts: 3650
Joined: Sat 12 Aug 2006, 19:25
Location: Tamworth UK

#11 Post by Burn_IT »

I use a Windows utility called TOFIXED which I got years ago and haven't looked for since.
"Just think of it as leaving early to avoid the rush" - T Pratchett


User avatar
Burn_IT
Posts: 3650
Joined: Sat 12 Aug 2006, 19:25
Location: Tamworth UK

#13 Post by Burn_IT »

Try sticking

treat usb like fixed disk

into google
"Just think of it as leaving early to avoid the rush" - T Pratchett

april

#14 Post by april »

For those that like to get answers not cryptic "look yourself" remarks here is what I find on the "media bit" on USB drives.

I gather thisis mostly applicable to Windows users where windows insists on writing Trash and Info files Lost Directories and the like and generally wasting your space . Or if you want separate partitions for some purpose.

So for Puppy and Linux users its mostly irrelevant.
Treat USB like fixed disk
Converting your USB flash drive from removable media to HDD (fixed hard drive) is particularly useful if you want to add extra partitions to the drive or if you want to make the drive bootable. To force a computer to recognize your USB flash drive as a fixed hard drive, you must flip the USB device's removable media bit. To flip the removable bit on your USB flash drive, you must use a special USB configuration software that will alter the USB's firmware.

Step 1
Download and extract Lexar BootIt. Lexar BootIt is a USB configuration software designed to create bootable USB drives.

Step 2
Insert your USB flash drive into a free USB slot. If necessary, connect a USB hub if you need additional USB slots.

Step 3
Run Lexar BootIt. Click the "Active" button next to "Partition," then click "Flip Removable Bit" to convert your USB drive into an HDD.

Step 4
Right-click "Start," then click "Explore." Remove your USB drive from your computer once the process is complete, then reinsert it. Your USB drive will appear in the list of drives.

Step 5
Right-click your USB drive, then click "Properties." Next to "Type," the USB drive should now read "Fixed Disk" or "Local Disk," rather than "Removable Disk."

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#15 Post by rufwoof »

Not tried it, but the RMB (removable media bit) is the 7th bit of the first byte. It might be sufficient to just dd if=/dev/zero of=/dev/sdx bs=1 count=1 without consequence on a FAT based USB.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

april

#16 Post by april »

Well I tried that and can see no obvious diff

Code: Select all

root# dd if=/dev/zero of=/dev/sdc1 bs=1 count=1

Don't see a diff with lsusb so what might I be looking for?

Following on that if I do that again would the second to last bit go to 1
How can i get it back ? Can I send count=-1?

Code: Select all

root# dd if=/dev/zero of=/dev/sdc1 bs=1 count=-1
dd: invalid number: ‘-1’
root# dd if=/dev/zero of=/dev/sdc1 bs=1 count=0
0+0 records in
0+0 records out
0 bytes copied, 0.000974086 s, 0.0 kB/s
root# 
Last edited by april on Thu 19 Jul 2018, 22:47, edited 1 time in total.

User avatar
Burn_IT
Posts: 3650
Joined: Sat 12 Aug 2006, 19:25
Location: Tamworth UK

#17 Post by Burn_IT »

With some makes of USB the control bit is in a protected area and cannot be altered.
The only way that I know of telling is to try it and see.
"Just think of it as leaving early to avoid the rush" - T Pratchett

Post Reply