new posts

This commit is contained in:
casual 2024-12-03 05:11:02 +03:00
parent 924200ca57
commit 7e3f51fc47
2 changed files with 224 additions and 0 deletions

View File

@ -0,0 +1,29 @@
+++
title = 'HDD wipe 101'
date = 2024-12-12
image = 'https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fwww.easeus.com%2Fimages%2Fen%2Fscreenshot%2Fpartition-manager%2Fphysical-damage.png&f=1&nofb=1&ipt=52e03fc20edc108b7cee49cacbc26b1810547f9641f1b29f0de79ebcc2ada00a&ipo=images'
+++
## Secure wipe individual file
```sh
shred -v -n 3 ./file
```
> Thou might not be secure if your filesystem use COW (copy-on-write) (like btrfs,zfs)
## Secure wipe entire drive
```sh
shred -v -n 3 /dev/HDD
# Or if you are paranoid - slower
shred -v -n 7 /dev/HDD
```
> Long. Expect waiting a day or two.
Or...
![](https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fwww.easeus.com%2Fimages%2Fen%2Fscreenshot%2Fpartition-manager%2Fphysical-damage.png&f=1&nofb=1&ipt=52e03fc20edc108b7cee49cacbc26b1810547f9641f1b29f0de79ebcc2ada00a&ipo=images)

View File

@ -0,0 +1,195 @@
+++
title = 'HowTo wipe SSD'
date = 2024-12-11
image = 'https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fi.imgflip.com%2F5fold8.jpg&f=1&nofb=1&ipt=57d5a7bd95d2cf08d7a126d00926f244038b58c47a130479233bd079c024a6f9&ipo=images'
+++
![](https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fi.imgflip.com%2F5fold8.jpg&f=1&nofb=1&ipt=57d5a7bd95d2cf08d7a126d00926f244038b58c47a130479233bd079c024a6f9&ipo=images)
If you are using SSD and want to securely wipe it (so no one can recover data), then you are in a trouble since it isn't as easy as with [HDD](/tech/hdd_wipe_101) thou faster. <!--more-->
> Warning: Be *really* sure that you are wiping correct drive. If you are doing it in script, then find your drive in `/dev/disk/by-id` since linux can change `/dev/sdX` after reboot
> By the way. You can't just wipe individual file on SSD, it won't be removed securely.
## Level 1 - blkdiscard
```sh
blkdiscard -v /dev/SSD
```
### Verify
```sh
echo 3 > /proc/sys/vm/drop_caches
cmp /dev/zero /dev/SSD
# expected result: EOF on /dev/SSD
```
pros:
- Just works on any SSD
- Done in a blink of an eye
- Scriptable (just add `-f`)
cons:
- Not secure, data still can be recovered.
`blkdiscard` will tell SSD to wipe blocks, SSD should put them to TRIM queue and wipe them *later*. It can't be secure and we don't trust SSDs manufacturer with that.
## Level 2 - SATA Secure Erase / NVMe SES
### SATA
```sh
hdparm -I /dev/SSD
```
In a buttom part, 'Security' section
![](https://grok.lsu.edu/image/32974.png)
```sh
# IF ' frozen' - we need to unfreeze it by putting PC in sleep for a few seconds
echo -n mem > /sys/power/state
# or - systemctl sleep
# check if it frozen
hdparm -I /dev/SSD
# if it still frozen - repeate sleeping/waking until it's not. #TODO is there any other better way???
```
![](https://grok.lsu.edu/image/32979.png)
```sh
# IF 'not frozen' - we will set up temporary password 'p' (don't change) for a drive to issue secure erase command
hdparm --user-master u --security-set-pass p /dev/SSD
# Check to see if the password is set correctly and that security is now enabled
hdparm -I /dev/SSD
# In 'Security' section now should be ' enabled' and 'Security level high'
```
![](https://grok.lsu.edu/image/32986.png)
```sh
# Finaly erase drive
# If the drive DOES support Enhanced Security Erase:
hdparm --user-master u --security-erase-enhanced p /dev/SSD
# If NOT:
hdparm --user-master u --security-erase p /dev/SSD
# After reset password should be disabled automatically
hdparm -I /dev/SSD
```
In case if you get error when tried to wipe and want to disable password:
```sh
sudo hdparm --user-master m --security-erase NULL /dev/SSD
# if didn't worked try --security-disable
# also try with --user-master u
```
pros:
- Should work on most SATA SSDs
cons:
- You can't be sure that it is secure wipe if you paranoid enough or against NSA.
When you issue Secure Erase, SSD controller should instantly wipe all memory banks by just giving power on them. If you don't trust your SSD's manufacturer, then it isn't sufficient.
If your drive is SED (self-encrypting drive), then it should remove cryptographic key instead of wiping memory banks making proccess faster
- Complicated. Hard to add in a script
- Drive must be directly attached to SATA (no USB, RAID controller or NVME SSD...)
- Long, expect it to take up to a hour
### NVMe
```sh
sudo nvme format /dev/nvmeSSD --ses=1
# Or if you have SED (self-encrypting drive)
sudo nvme format /dev/nvmeSSD --ses=2
```
pros:
- Should work on most recent NVMe SSDs
- Scriptable
cons:
- Same as in SATA - You can't be sure that it is secure wipe if you paranoid enough or against NSA.
Drive's firmware decide how exactly it should be erased (e.g., zeroing, random data overwrite)
In case of `--ses=2` and SED drive - it will remove crypto keys what is going to be fast
- Long, expect it to take up to a hour
## Level 3 - dd/shred + blkdiscard
```sh
dd bs=1M status=progress if=/dev/urandom of=/dev/SSD
# or - shred -v -n 1 /dev/SSD
blkdiscard -v /dev/SSD
```
### Verify
```sh
echo 3 > /proc/sys/vm/drop_caches
cmp /dev/zero /dev/SSD
# expected result: EOF on /dev/SSD
```
pros:
- Just works on any SSD
- Scriptable
cons:
- Long, expect it to take up to a hour
- Security - complicated. `dd/shred` aren't a guaranteed to securely wipe entire SSD. The issue is a complexity of a SSDs:
wear leveling, garbage collection, logical/physical data mapping, TRIM during proccess... They all make `dd/shred` arent reliable to securely wipe entire SSD, some parts of a drive still can be recovered.
If you trust enough your drive manufacturer and drive didn't containe any important information, then just use SATA Secure Erase / NVMe SES.
## Level 4 - paranoia
Well, if you paranoid enough to wipe device for sure, then we are combining stuff above in extreme maner (your disk should be like 3 times overwritten)
```sh
shred -v -n 1 /dev/SSD
echo 3 > /proc/sys/vm/drop_caches
blkdiscard -v /dev/SSD
echo 3 > /proc/sys/vm/drop_caches
# !!!ISSUE SATA Secure Erase / NVMe SES!!!
echo 3 > /proc/sys/vm/drop_caches
# We will do random data wipe once again by encrypting 0s and verifying encrypted 0s later
cryptsetup open --type plain --cipher aes-xts-plain64 /dev/SSD cryptyourssd
# Pass:Three unicorns went into a bar and got stuck in the door frame
badblocks -b 4096 -t 0 -s -w -v /dev/mapper/cryptyourssd
# Power off your PC and boot it again
# Open drive again
cryptsetup open --type plain --cipher aes-xts-plain64 /dev/SSD cryptyourssd
# Pass:Three unicorns went into a bar and got stuck in the door frame
# verify that you did good
cmp /dev/zero /dev/mapper/cryptyourssd
# expected result: EOF on /dev/mapper/cryptyourssd
```
pros:
- tranquility knowing that drive is wiped
- you still have a working drive!
cons:
- The longest, expect it to take a few hours
- You need to understand what you are doing
## Level 5
<!-- ![](https://i.imgur.com/q2ZIwQ7.mp4) -->
{{< rawhtml >}}
<video width=100% controls autoplay loop>
<source src="https://i.imgur.com/q2ZIwQ7.mp4" type="video/mp4">
Your browser does not support the video tag.
</video>
{{< /rawhtml >}}
(If you cant see a video, then the answer is - physical destruction)
{{< source >}}
https://superuser.com/questions/1284450/quickest-way-to-wipe-an-ssd-clean-of-all-its-partitions-for-repartitioning-in-li
https://unix.stackexchange.com/questions/681521/securely-erase-ssds-the-whole-ssd
https://grok.lsu.edu/Article.aspx?articleid=16716
https://superuser.com/questions/1671399/remove-unknown-ata-password-with-hdparm
https://unix.stackexchange.com/questions/659931/how-secure-is-blkdiscard
https://superuser.com/questions/1530363/how-to-securely-erase-an-nvme-ssd
https://serverfault.com/questions/147759/dd-vs-secure-erase-for-reconditiong-ssds
{{< /source >}}