Shred'NBurn Android app open testing (no ads, freeware, no Internet usage, no in store purchase)

[Al T 12]

Hi,

 

I'm a freeware developer and have created "Shred'N'Burn" using Delphi 11.0

 

In the credits of this application, I give credit to Delphi 11.

 

It took 5 days for Google Play to approve this application.

 

Main purpose: If you don't know it, most operating systems don't wipe your files before they delete them.  So, Shred'N'Burn utility can wipe the whole storage space by filling it up with random data.

 

Hint: This Program can take quite a while to run depending on space.  I have about 90gb of free space and I've got a Pixel 6.  It took roughly an 30 minutes to just get a random.txt file created then several hours to fill the space.  This isn't a quick job and can get some phones pretty hot.

 

There is so many apps that claim they can do this without proof of work.  My application does request permissions to use external storage so it can create a folder called "filler" in the downloads directory.  There it will create a random.txt file that you can view while it's being made.  After that file is created, it will begin to copy it over and over until it fills up all the free storage space.  Once it reaches the end of free storage space, it will automatically clean up by deleting those files. You can watch the process using any file manager.  The process isn't hidden from a users view.

 

I'll be adding more features, but I really wanted to get this out there for a few of my friends.  One of the major features I plan to add is throttling because it can make some phones get hot.

 

It's in open testing, so if you use it and have problems, please report them here.  Thank you!

 

https://play.google.com/store/apps/details?id=com.embarcadero.ShredNBurn

 

Edited August 27, 2022 by Al T

[Fr0sT.Brutal 900]

Good job, there was several times I felt I needed such a tool. Why are you copying files instead of just filling one large file? Are you taking cluster sizes into account (data tails could survive if your filler file is not aligned to cluster)? Are you handling the case when remaining free space is smaller than your filler file?

Edited August 29, 2022 by Fr0sT.Brutal

[Al T 12]

Copying is so much faster than that filling a file.  The time it takes to create a random.txt file filled with random data takes incredibly much longer than just trying to create 1 file.

 

The process is... Create a file with random data at percentage of the free space available.  Then start copying files. When the size of free space gets close to reaching the free space storage size, it'll create a new random data file and then continue copying files.  This process repeats as the free space gets smaller until it's down to copying bytes of data.

 

(Edit: My phone starts at stage 11.  When it reaches stage 0 it's almost ready to clean up. You'll see the stage your in ...in [brackets])

 

My Samsung rings me when the space is empty.  Google pixel goes berserk!  So, your phone will let you know when your out of space..lol.

 

As far as "cluster sizes".. I haven't read anything on cluster sizes.  I just wanted something basic that will wipe the drive.

 

I just know, if you write data on a drive multiple times, your practically wiping the drive.

 

The file location of all the filler files is in your download directory named "FILLER".  If you stop Shred'N'Burn mid way thru, you can tell it not to delete the files.  You can then go "view" the files in that directory.

 

I do have a road map to add more functions that will increase the smartness of the program.

Edited August 30, 2022 by Al T

[SwiftExpat 65]

56 minutes ago, Al T said:

The time it takes to create a random.txt file filled with random data takes incredibly much longer than just trying to create 1 file.

You should probably review the NIST guidelines, no need to randomize the data, just fill it with 0 & 1.  NIST uses the word pseudorandom a lot.

Good summary:

https://www.bitraser.com/article/use-nist-hard-drive-erasure.php

Reference:

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf

 

Writing some strings in parallel might be a lot faster, I believe you have 8 channels on most controllers, so you can probably get 4-5 writes in parallel.

1 hour ago, Al T said:

I just know, if you write data on a drive multiple times, your practically wiping the drive.

This is only true if you write sector by sector, the OS controls where that file is placed.  You would have to write 1 file the size of the free space to make that true in your scenario.

[Fr0sT.Brutal 900]

7 hours ago, SwiftExpat said:

Writing some strings in parallel might be a lot faster, I believe you have 8 channels on most controllers, so you can probably get 4-5 writes in parallel.

I doubt it. The bottleneck is the flash memory not the CPU

8 hours ago, Al T said:

The time it takes to create a random.txt file filled with random data takes incredibly much longer than just trying to create 1 file.

This shouldn't happen. Probably OS has the option to set file size at start? This will remove file growth at every write. Anyway are you writing blocks or byte by byte?

8 hours ago, Al T said:

As far as "cluster sizes".. I haven't read anything on cluster sizes.

But the app won't do exactly what it claims to do. Data remnants will survive

8 hours ago, Al T said:

I just wanted something basic that will wipe the drive.

There's almost nothing "basic" in this world 🙂 even with steel anvil there's hundreds of hidden nuances to consider