A note about hard disk drives. It's possible that if you overwrite with 0 that some of the original data can be recovered from the edges of the original track. Programs exists that tell the HDD to overscan the magnetic area to try to recover the old data and Feds 100% use this. That's why the industry standard is to wipe with 0, then fill with random data, then wipe to 0 again.
"That's why the industry standard is to wipe with 0, then fill with random data, then wipe to 0 again."... so in bash will be something like... function deletehdd { command shred -zn $2 $1 && shred -n $2 $1 && shred -zun $2 $1 } right?
One note for SSDs, most have a firmware-level block selector to increase the lifespan of the drive, which means if you "overwrite" a file, you may not actually change the exact same bits the original file occupied. This also applies to certain types of filesystems, read shred's man page. That said, going nuclear by filling the entire drive (maybe even 8 times) should cover all contingencies. When your terminal gets messed up by binary files, type "reset" and press enter (even if you can't see the letters you type)
Was just about to mention this, I have opted for encrypting anything that goes into flash memory just in case, do SSDs even offer an option to access the memory without having to go through the remapping and other wear leveling systems?
@@RapiBurrito retard. one day you wont be able to decrypt your drive because decrypting writes data and if ssd runs out of write cycles. enjoy your brick
Most of this advice applies to HDD's. DO NOT SCRUB SSD'S or inexpensive flash drives with tools that overwrite multiple times. I suppose shred is fine for limited use on specific files but other wipe tools overwrite multiple times which is not necessary on SSDs. SSDs use a type of Flash Memory that has a limited number of writes. You'll wear out the SSD if you wipe it frequently. The magnetic properties of HDD do not apply to Flash SSD chips. When using SSD's there's a TRIM feature in most operating systems that will zero out the sectors marked for deletion while at idle. Most SSD's also have firmware that will do the same. When sectors become worn as they approach their write limits they will be swapped with spare extra sectors (over-provisioning - enterprise SSDs have many more spare sectors) and depending on the firmware those removed sectors may or may not be zeroed. It is very important to encrypt SSD's to better protect data. If someone removes the SSD flash chips they could recover data. But not if it is encrypted from day one of it's life. You can simply format SSD's that were encrypted and the data will be completely unrecoverable. Cheap thumb drive's use pretty crappy flash chips compared to SSDs, you should always encrypt them if you ever put anything sensitive on them. You can buy hardware encrypted thumb drives and external drives that also encase the chips in epoxy which will likely break the chips if someone tries to remove the epoxy. But these are not the ultra cheap thumb drives that are everywhere in the market. You'll pay more but it's worth it for piece of mind. I am talking about the drives that have a numeric keypad on them or a fingerprint reader where they need to be unlocked before you can mount the disk. We use apricorn.com/ drives at work as they meet very strict standards. Again, not cheap but trustworthy. Yes, they do work on Linux, etc. you can format them with any disk format you like. Not suitable as boot disks.
Always go for key codes if you can. From a legal level, biometric data like your iris, face scan, or finger print are not your own and are not conidered unreasonable search or seizure. Us and EU Law enforcement is known to legally force defendants to offer their face or fingers to unlock machines. But in the US key codes are different, they're covered as speech, so the government is restrained from compelling a defendant to "testify" against themselves by giving a code. If the government can crack the code in evidence it's back to fair game.
As much as I enjoy hearing your insights into life and society regardless of my agreement or otherwise with your outlooks, these practical videos of yours are my favorite.
If someone wants an analogy to help them understand this, imagine the data is a weight attached to a fishing line floating in a pool. When you delete the file you don't pull the weight out and destroy it. You just cut the line. Someone dedicated enough to recovering the data can go into the pool and pull out the weight if they go through every rock in the pool individually and examine it.
Even using shred or overwriting the specific file is not a guaranteed way to really overwrite those bits on the drive nowadays. Trap #1: SSDs and maybe even some flash drives even out the wear by writing to different physical location every time. If the drive was unencrypted (or the attacker has the key), the data may still be recoverable directly from nand even after overwriting. Trap #2: Modern filesystems do not guarantee the overwrite will work. Especially copy on write filesystems. (for example fedora uses btrfs by default) Those filesystems do similiar thing as SSDs. Mitigations: Always encrypt your drive. Use encrypted vaults for especially sensitive files you may want to delete later. This way after you delete your vault, attacker cannot recover the files if he doesn't have the key.
urandom takes in consideration the system entropy, it is a cryptographic secure random number generated, preferred to use compared to random, which takes a starting seed.
HDDs store data by electro magnetizing individual magnetic domains (also refferd as sectors) with either a north or a south magnetic polarity to represent either a binary of 0 or 1. To read it back, the head detects the magnetic polarities of the magnetic domains (sectors) which are physical (few nanometers) structures that are already present on the disk. The binary data is then sent to the CPU where it is translated into ASCII code using predefined algorithms and protocol. The best way to destroy data would be : Degaussing : Exposing the disk to a strong magnetic field, which will erase the magnetic polarities and destroy the data stored on the disk. You're welcome
I sold a hard drive to a friend (spinning rust) and did a 35 pass alternating 0's and 1's followed by every 3rd pass being pseudo random data. I then stuck it in an high magnetic field for a few hours, followed by a complete low format. Old drives that work I do this before even storing them, and if I have to trash them I put them to a butane torch. Probably paranoia but as they say just because you are paranoid doesn't mean they are not out to get you. :)
Shred is great. At my last job we were charged with securely disposing of some old hard drives with a bunch of financial data on them. Ram a 4 pass shred zeroing the bits at the end and it worked like a dream. 1 TB drive took about 7 hours or so to finish.
I bought a 1tb drive and it waz full of documents from a private school on it (employees info, finnances, student info, student reports and more). Luckily I ain't into blackmail
actually to explain better, when you write data in most filesystems a file is a pointer to the physical location of data and in unix like environments and windows and newer versions of dos too, when a all pointers to a file/data location is deleted, the data is ready to be over written for whatever takes its place, so its free space not occupied by any pointer pointing to it, this is the same on RAM for variables and stuff too which also how memory leaks happens, when the pointer isnt deleted
Oh my god I didn't know dd took status=progress as an argument... I've been finding its pid and sending a USR1 signal using kill all these years like a chump :O
Wouldn't it make more sense to use dd to write /dev/urandom straight to the drive itself, rather than a file, to actively destroy your data at the sector level?
I got paid 20$ when i was 17 to move file from an old laptop and then delete all data. I booted into a Linux live USB to run dd. Wrote the disk full of zeros and random couple of times.
Sadly, this is pretty lackluster and bad advice. There is nothing said aboud how SSD/NVMe/HDD handle data erasure (spoiler: they all do it different and only HDD's require overwiritng data) Currently the tech can recover the data form at least 17-20 overwrites from spinnig plate hdd's (hysteresis loop) What is TRIM SSD/NVMe does not write NAND's in linear fashion Filling the non-used space with /dev/rand does nothing, since the partition table will tell you exactly how big LUKS partition is
The text in your videos is has lots of weird colour fringing artifacts. Have you considered disabling subpixel font hinting in freetype while recording videos? I'm not sure if that would fix it but it looks like that's probably what is causing it.
The sign is a subtle joke. The shop is called "Sneed's Feed & Seed", where "feed" and "seed" both end in the sound "-eed", thus rhyming with the name of the owner, Sneed. The sign says that the shop was "Formerly Chuck's", implying that the two words beginning with "F" and "S" would have ended with "-uck", rhyming with "Chuck". So, when Chuck owned the shop, it would have been called "Chuck's Feeduck and Seeduck".
I've had SSDs make the data unrecoverable the moment you delete it. They don't have nearly the memory HD have. Which is annoying as I've so far only need to recover data not destroy it.
This is not something you do every time after you delete a delicate file; this is something you do when you wanna delete any evidence of that file ever existing along with all the other data on that data drive, so you wouldn't be doing this every day, only in special occasions. Also, couldn't you just encrypt the whole thing and forget about having to delete data?
For anybody that has had to try and forsensically recover files bc you deleted something you didn't mean to you realize this is only partially true. When you delete a file your operating system unallocates the storage where that file was, and in some cases that means it is relatively easy to recover but in others it means that the file can be really badly corrupted and not fully recoverable at all, even if some data associated with that file is still lingering on your drive.
Its not really true that "that space will never be overwritten until that space is needed" There are a lot of factors at play. When you delete a file in a typical fashion with an os, all you are doing is removing the os pointer to where that file was located on storage. But how that now freely available space is handled by the os can depend on a lot of factors. Size of file, frequency of use, physical location on the storage medium. These factors will play a role in how recoverable a file is after os deletion. I get your point is "to be safe wipe your storage" but on the recovery side it is important to note that, no, not necessarily the full intact file you deleted is still sitting around on your storage. I guess my point is if you have sensitive data, it is ok to back it up in case you accidently delete through user error. But your security protocol should be to have the back up stored to a drive with strong encryption and is relatively easy to render corrupted in an emergancy glowy situation.
My problem is that people have direct access to my phone and I have no way of proving that. It seems to be the police yet total strangers, as Ive witnessed have been involved. At this point I just have to live with it and not be able to prove anything but it seems like there HAS to be someone else experiencing this shit.
@Zoran Dušić dude it's a long, a long, arduous and nuanced story. I just can't explain in text. I just know that other people are experiencing this but it's very rare. All I can say is like it's a stasi wet dream.
To properly wipe a drive, you'll want to make at least three passes of random data so that even the most sophisticated hardware analysis and data recovery labs in the world can't recover what you deleted.
@@ggsap A single pass won't flip the bits to their greatest extent, but more than enough to write the data within spec. But the discrepancy can be detected by anyone using the right equipment and who knows what to look for. That is, on a hard disk drive. I don't know if that's true for SSDs.
I write on my hdd like 10-100 gb of data every day, no way in hell anybody is going to recover anything 5 years later. It's gonna be written over 1000 times by then. Gamers ftw
nope, i actually tried to recover an archive of about 300mb i deleted by mistake like 4 months ago from my 1T HDD and it doesn't exist anymore, and i never filled my HDD , i always have like 300-400 GB free because if it gets too full then my pc lags like crazy because low spec laptop garbage. I only managed to recover some files related to it and even those where so damaged and corrupted they couldn't be opened@@bryanrigby4429
For at least a couple years now, there's literally no difference between /dev/random and /dev/urandom in Linux. The two names exist for compatibility. Old kernels used to use /dev/random in a blocking mode exclusively, where it'd halt outputting data until some arbitrary threshold in Linux's PRNG was reached. It wasn't any "more random" or "more secure", but it fooled people into thinking it was. So that behavior is gone now. Many of your "dd if=file of=outfile" commands could just be simplified as "cp file outfile"; this works also for "cp /dev/random random". It's also well worth noting that shred is useless on CoW file systems (btrfs and ZFS, for example) and likewise useless on some journalling modes of ext4.
A note about hard disk drives. It's possible that if you overwrite with 0 that some of the original data can be recovered from the edges of the original track. Programs exists that tell the HDD to overscan the magnetic area to try to recover the old data and Feds 100% use this. That's why the industry standard is to wipe with 0, then fill with random data, then wipe to 0 again.
Military standards are 5 wipes of high entropy random data. I wouldn't do any less for anything sensitive.
@@ImperiumLibertas "Military standard" is meaningless nowadays.
10 times
"That's why the industry standard is to wipe with 0, then fill with random data, then wipe to 0 again."... so in bash will be something like...
function deletehdd {
command shred -zn $2 $1 && shred -n $2 $1 && shred -zun $2 $1
}
right?
@@AnotherAvaibleName nowadays? it's always just been a marketing ploy
In TempleOS, when you delete data it gets recalled back to God's Kingdom. Safe from all the glowies who are reddit-tier athiests.
based and TAD-pilled
Amen
fr though, does it handle deletion in a special way?
cold
@@chrisphoenix115 It is harsh that the nonbeliving glowies are denied the glories of holy C.
One note for SSDs, most have a firmware-level block selector to increase the lifespan of the drive, which means if you "overwrite" a file, you may not actually change the exact same bits the original file occupied. This also applies to certain types of filesystems, read shred's man page. That said, going nuclear by filling the entire drive (maybe even 8 times) should cover all contingencies.
When your terminal gets messed up by binary files, type "reset" and press enter (even if you can't see the letters you type)
Was just about to mention this, I have opted for encrypting anything that goes into flash memory just in case, do SSDs even offer an option to access the memory without having to go through the remapping and other wear leveling systems?
That’s why Apple uses effacable storage (no wear-leveling) to store certain ephemeral encryption keys.
@@RapiBurrito retard. one day you wont be able to decrypt your drive because decrypting writes data and if ssd runs out of write cycles. enjoy your brick
@@100thschool backups are a real mind bender to you aren't they? 😆
default runescape character explains how to evade law enforcement
Most of this advice applies to HDD's. DO NOT SCRUB SSD'S or inexpensive flash drives with tools that overwrite multiple times. I suppose shred is fine for limited use on specific files but other wipe tools overwrite multiple times which is not necessary on SSDs. SSDs use a type of Flash Memory that has a limited number of writes. You'll wear out the SSD if you wipe it frequently. The magnetic properties of HDD do not apply to Flash SSD chips. When using SSD's there's a TRIM feature in most operating systems that will zero out the sectors marked for deletion while at idle. Most SSD's also have firmware that will do the same. When sectors become worn as they approach their write limits they will be swapped with spare extra sectors (over-provisioning - enterprise SSDs have many more spare sectors) and depending on the firmware those removed sectors may or may not be zeroed. It is very important to encrypt SSD's to better protect data. If someone removes the SSD flash chips they could recover data. But not if it is encrypted from day one of it's life. You can simply format SSD's that were encrypted and the data will be completely unrecoverable. Cheap thumb drive's use pretty crappy flash chips compared to SSDs, you should always encrypt them if you ever put anything sensitive on them. You can buy hardware encrypted thumb drives and external drives that also encase the chips in epoxy which will likely break the chips if someone tries to remove the epoxy. But these are not the ultra cheap thumb drives that are everywhere in the market. You'll pay more but it's worth it for piece of mind. I am talking about the drives that have a numeric keypad on them or a fingerprint reader where they need to be unlocked before you can mount the disk. We use apricorn.com/ drives at work as they meet very strict standards. Again, not cheap but trustworthy. Yes, they do work on Linux, etc. you can format them with any disk format you like. Not suitable as boot disks.
Always go for key codes if you can.
From a legal level, biometric data like your iris, face scan, or finger print are not your own and are not conidered unreasonable search or seizure. Us and EU Law enforcement is known to legally force defendants to offer their face or fingers to unlock machines. But in the US key codes are different, they're covered as speech, so the government is restrained from compelling a defendant to "testify" against themselves by giving a code. If the government can crack the code in evidence it's back to fair game.
Do you work for apricorn? 69 to 1000 dollars.
Sounds exactly like what a glowie would say. I'm gonna wipe my ssds x16 now.
As much as I enjoy hearing your insights into life and society regardless of my agreement or otherwise with your outlooks, these practical videos of yours are my favorite.
Where did you buy that gaming chair?
My best guess is it's second hand, possibly from an acquaintance
From his grandfather, veteran hero
With creditcard cash xD
@@smotheredbyPrincessPeach he calls it credit card rotation lol 😂
fossbook marketplace probably
Another reinforcement of the adage "physical access is total access"
Reject storage, embrace ramdisk
Unironically would consider this but my power regularly goes out in storms
@@user-vk2cd9qw7i usp?
If someone wants an analogy to help them understand this, imagine the data is a weight attached to a fishing line floating in a pool. When you delete the file you don't pull the weight out and destroy it. You just cut the line. Someone dedicated enough to recovering the data can go into the pool and pull out the weight if they go through every rock in the pool individually and examine it.
luke smith posting actual tech videos? impossible
hey! i like his other videos!
Where I'm from we don't call them friends we call them something else.
glowN
glow ninjas
@@meuko glowI
@@travv88 GlowG
Glowggers
Even using shred or overwriting the specific file is not a guaranteed way to really overwrite those bits on the drive nowadays.
Trap #1: SSDs and maybe even some flash drives even out the wear by writing to different physical location every time. If the drive was unencrypted (or the attacker has the key), the data may still be recoverable directly from nand even after overwriting.
Trap #2: Modern filesystems do not guarantee the overwrite will work. Especially copy on write filesystems. (for example fedora uses btrfs by default) Those filesystems do similiar thing as SSDs.
Mitigations: Always encrypt your drive. Use encrypted vaults for especially sensitive files you may want to delete later. This way after you delete your vault, attacker cannot recover the files if he doesn't have the key.
urandom takes in consideration the system entropy, it is a cryptographic secure random number generated, preferred to use compared to random, which takes a starting seed.
I love this series Luke! Please keep going!
Haha thought this was a Mental Outlaw vid from the thumbnail XD
It is, they're the same person as we all know
HDDs store data by electro magnetizing individual magnetic domains (also refferd as sectors)
with either a north or a south magnetic polarity to represent either a binary of 0 or 1.
To read it back, the head detects the magnetic polarities of the magnetic domains (sectors)
which are physical (few nanometers) structures that are already present on the disk.
The binary data is then sent to the CPU where it is translated into ASCII code using
predefined algorithms and protocol.
The best way to destroy data would be :
Degaussing :
Exposing the disk to a strong magnetic field, which will erase the magnetic polarities and destroy the data stored on the disk.
You're welcome
I sold a hard drive to a friend (spinning rust) and did a 35 pass alternating 0's and 1's followed by every 3rd pass being pseudo random data. I then stuck it in an high magnetic field for a few hours, followed by a complete low format. Old drives that work I do this before even storing them, and if I have to trash them I put them to a butane torch. Probably paranoia but as they say just because you are paranoid doesn't mean they are not out to get you. :)
You're definitely paranoid and just wasting time by going so overkill
Cp on there?
Who's out to get you? They gotta be important for that level of overkill.
Shred is great. At my last job we were charged with securely disposing of some old hard drives with a bunch of financial data on them. Ram a 4 pass shred zeroing the bits at the end and it worked like a dream. 1 TB drive took about 7 hours or so to finish.
I bought a 1tb drive and it waz full of documents from a private school on it (employees info, finnances, student info, student reports and more). Luckily I ain't into blackmail
That is very lucky for them you got it and not someone malicious.
@@RenamedChannel Yeah, we weren’t that big. We just did this then took drills and hammers to the platters.
@@RenamedChannel How can you make such a far reaching statement ("always")? Did you work in every big company? In every department?
@@unbekannter_Nutzer Yes.
/dev/random and urandom were different but they are now pm the same thing and we only have two for backward compatibility.
Now I'll make sure to fill up the drive after deleting the homework folder.
actually to explain better, when you write data in most filesystems a file is a pointer to the physical location of data and in unix like environments and windows and newer versions of dos too, when a all pointers to a file/data location is deleted, the data is ready to be over written for whatever takes its place, so its free space not occupied by any pointer pointing to it, this is the same on RAM for variables and stuff too which also how memory leaks happens, when the pointer isnt deleted
Oh my god I didn't know dd took status=progress as an argument... I've been finding its pid and sending a USR1 signal using kill all these years like a chump :O
status=progress is non-standard to GNU dd.
Rip Terry.
14:20 Luke channels Charles Manson's spirit
Hi Luke, do you have any videos on file recovery?
Wouldn't it make more sense to use dd to write /dev/urandom straight to the drive itself, rather than a file, to actively destroy your data at the sector level?
luke shredding his own disk for us
step one. acquire metallurgy furnace.
step two. use critical thinking to figure out the rest.
I got paid 20$ when i was 17 to move file from an old laptop and then delete all data. I booted into a Linux live USB to run dd. Wrote the disk full of zeros and random couple of times.
Sadly, this is pretty lackluster and bad advice.
There is nothing said aboud how SSD/NVMe/HDD handle data erasure (spoiler: they all do it different and only HDD's require overwiritng data)
Currently the tech can recover the data form at least 17-20 overwrites from spinnig plate hdd's (hysteresis loop)
What is TRIM
SSD/NVMe does not write NAND's in linear fashion
Filling the non-used space with /dev/rand does nothing, since the partition table will tell you exactly how big LUKS partition is
Has Luke mention what laptop he decided to use moving forward after the laptop video
The text in your videos is has lots of weird colour fringing artifacts. Have you considered disabling subpixel font hinting in freetype while recording videos? I'm not sure if that would fix it but it looks like that's probably what is causing it.
sneed
Nice
The sign is a subtle joke. The shop is called "Sneed's Feed & Seed", where "feed" and "seed" both end in the sound "-eed", thus rhyming with the name of the owner, Sneed. The sign says that the shop was "Formerly Chuck's", implying that the two words beginning with "F" and "S" would have ended with "-uck", rhyming with "Chuck". So, when Chuck owned the shop, it would have been called "Chuck's Feeduck and Seeduck".
I've had SSDs make the data unrecoverable the moment you delete it. They don't have nearly the memory HD have. Which is annoying as I've so far only need to recover data not destroy it.
How the heck you move the cursor without touching the mouse 🤨🤨
haven't watched video yet, but can i wipe a phone using same technique?
Whaaaaaaaaat? Sending files to the bin will NOT make me a invisible untrackable Super-Hacker? 😱😱😱
man , please tell me the chair that u using name ??
John Smith
Why not just psychically destroy the drive? Like set in on fire?
Great video. Thank you!
Careful, you can reduce life-span of SSD if you overwrite it!
Yeah if you overwrite it everyday
plus you're not actually overwriting the file, because it gets mapped to different areas internally. need to overwrite the whole device :/
sounds like the data can be transalated using the same software. unless original data is totally replaced somehow, where data is no longer usable
This is not something you do every time after you delete a delicate file; this is something you do when you wanna delete any evidence of that file ever existing along with all the other data on that data drive, so you wouldn't be doing this every day, only in special occasions. Also, couldn't you just encrypt the whole thing and forget about having to delete data?
If you didn't encrypt, and you have something on the drive requiring this, I doubt you're worried about the longevity of an $80 drive.
Luke pulling the mental outlaw content strat to farm normies smart lol
That's exactly why I clicked
Thank you Luke I shall now commit crimes
New luke smith video 😁👍
This is the content i like to watch dude. bless u
When I format a drive I always saturate it with dumb files before .
shoutouts to ya boy terry davis. RIP king
sheeesh missing u already plez come back !!
Is this Arch or Parabola ?
For anybody that has had to try and forsensically recover files bc you deleted something you didn't mean to you realize this is only partially true.
When you delete a file your operating system unallocates the storage where that file was, and in some cases that means it is relatively easy to recover but in others it means that the file can be really badly corrupted and not fully recoverable at all, even if some data associated with that file is still lingering on your drive.
Its not really true that "that space will never be overwritten until that space is needed"
There are a lot of factors at play.
When you delete a file in a typical fashion with an os, all you are doing is removing the os pointer to where that file was located on storage.
But how that now freely available space is handled by the os can depend on a lot of factors.
Size of file, frequency of use, physical location on the storage medium.
These factors will play a role in how recoverable a file is after os deletion.
I get your point is "to be safe wipe your storage" but on the recovery side it is important to note that, no, not necessarily the full intact file you deleted is still sitting around on your storage.
I guess my point is if you have sensitive data, it is ok to back it up in case you accidently delete through user error.
But your security protocol should be to have the back up stored to a drive with strong encryption and is relatively easy to render corrupted in an emergancy glowy situation.
Thank you so much. I learn so much from your videos.
Glowing friends
Consider using hidden volume features of veracrypt. Plausible deniability needs to be known.
nice gaming setup
My problem is that people have direct access to my phone and I have no way of proving that. It seems to be the police yet total strangers, as Ive witnessed have been involved. At this point I just have to live with it and not be able to prove anything but it seems like there HAS to be someone else experiencing this shit.
What makes you think that someone has access to your phone?
Based schizo. The gangstalkers are after you. All your electronics are compromised.
@Zoran Dušić dude it's a long, a long, arduous and nuanced story. I just can't explain in text. I just know that other people are experiencing this but it's very rare.
All I can say is like it's a stasi wet dream.
@@ThirdDimensionalBeing God damn man, sounds tough. I hope they don't get you. Privacy doesn't exist in the 21. century.
@@ThirdDimensionalBeing you're paranoid. Nuance doesn't count.
To properly wipe a drive, you'll want to make at least three passes of random data so that even the most sophisticated hardware analysis and data recovery labs in the world can't recover what you deleted.
Even better, take a hammer to it
why more than 1 pass?
@@ggsap A single pass won't flip the bits to their greatest extent, but more than enough to write the data within spec. But the discrepancy can be detected by anyone using the right equipment and who knows what to look for. That is, on a hard disk drive. I don't know if that's true for SSDs.
@@RAndrewNeal wdym by "greatest extent"
@@ggsap All the way as far as it can go.
Shred is good, but i still gonna take care my ssd life expectancy
I thought he was going to talk about inodes
I didn't know shred. I only knew wipe and wipefs.
The real best way to delete files on your computer is to go the nuclear route. USB Killer
can someone explain me if MentalOutlaw is actually a Luke Smith's deepfake? i see this channel 1st time
It's a meme
You'll eff up your ssd with Shred tho...it will burn right thru them.
TempleOS doesn't use files cause that's bloat
What are you talking about normies would just drag their files into the recycle bin and call it a day.
2:50 hard same
Actually you can also run `cat /bin/ls` to recover the terminal.
Not a word.
TempleOS is chad only!!!
th-cam.com/video/0WcrgvhO_mw/w-d-xo.html What about Veracrypt?
classic video
Nail gun it
Bleach
I write on my hdd like 10-100 gb of data every day, no way in hell anybody is going to recover anything 5 years later. It's gonna be written over 1000 times by then. Gamers ftw
But dont you have to rewrite to full capacity the drive to have everything deleted?
nope, i actually tried to recover an archive of about 300mb i deleted by mistake like 4 months ago from my 1T HDD and it doesn't exist anymore, and i never filled my HDD , i always have like 300-400 GB free because if it gets too full then my pc lags like crazy because low spec laptop garbage. I only managed to recover some files related to it and even those where so damaged and corrupted they couldn't be opened@@bryanrigby4429
cat /dev/zero > file works too.
For at least a couple years now, there's literally no difference between /dev/random and /dev/urandom in Linux. The two names exist for compatibility. Old kernels used to use /dev/random in a blocking mode exclusively, where it'd halt outputting data until some arbitrary threshold in Linux's PRNG was reached. It wasn't any "more random" or "more secure", but it fooled people into thinking it was. So that behavior is gone now.
Many of your "dd if=file of=outfile" commands could just be simplified as "cp file outfile"; this works also for "cp /dev/random random".
It's also well worth noting that shred is useless on CoW file systems (btrfs and ZFS, for example) and likewise useless on some journalling modes of ext4.
thirtysix
🫠