PartialVolume / shredos.x86_64

Shredos Disk Eraser 64 bit for all Intel 64 bit processors as well as processors from AMD and other vendors which make compatible 64 bit chips. ShredOS - Secure disk erasure/wipe
Other
1.52k stars 64 forks source link

shredos does not write proper prng data on drive if "--prng=isaac" option is in grub.cfg #33

Closed alphanis closed 3 years ago

alphanis commented 3 years ago

Bug report.

shredos writes some kind of log data instead of actual prng data on drive.

To reproduce this bug:

  1. Make shredos boot USB stick.
  2. Edit grub.cfg as below:
    
    set default="0"
    set timeout="0"

menuentry "shredos" { linux /boot/shredos console=tty3 loglevel=3 nwipe_options="--prng isaac" }


3. Boot shredos. (I've tested in UEFI boot)
4. Set method to prng.
5. Set verify to all passes.
6. Select drive and Start.
7. Verify will fail.

If you want to look into the drive using hex editor to find out weird data like kind of log was written, do 1~4 above and follows:
5. Disable final blanking pass. (BTW, you can see verifying option cannot be enabled when you do this. Is this intended?)
6. Select drive and Start.
7. Look into your drive using hex editors.
PartialVolume commented 3 years ago

@alphanis Does this happen every time you do the wipe using prng=isaac and does the log entry occur at the start or end of the drive or randomly somewhere in the middle? What size of drive, can you post the log data in hex? A .jpg snapshot will do. Can you post the entire log entry. You will need to save the log entry using the command line option and then copy back to the USB. What I need to determine is whether the verify failed due to an I/O error and the data you are seeing wasn't generated by the wipe but already existed on the drive or whether the data you are seeing matches the log typically generated by nwipe.

My first thought is that it's some bug in nwipe but I'll run some tests tonight and see if I can reproduce it.

PartialVolume commented 3 years ago

@alphanis Confirmed, I've completed some tests on nwipe and can reproduce this bug.

I found it's specific to the following configuration ISAAC PRNG (it doesn't appear to error out with the default Mersenne Twister PRNG) and with 'All passes verified'. It doesn't occur with the default last pass verify.

I'll open a issue with nwipe and investigate. Thanks for reporting.

Addendum: It also only occurs if --prng=isaac is specified on the command line but not if you use nwipe's GUI to change from mersenne to isaac having not specified --prng on the command line.

alphanis commented 3 years ago

@PartialVolume

I found it's specific to the following configuration ISAAC PRNG (it doesn't appear to error out with the default Mersenne Twister PRNG) and with 'All passes verified'. It doesn't occur with the default last pass verify.

Last pass verifying enables final blanking pass as I wrote:

  1. Disable final blanking pass. (BTW, you can see verifying option cannot be enabled when you do this. Is this intended?)

So I think nwipe would still write wrong prng data on disk and just skip verifying write pass. Final verifying would be successful because of final blanking.

alphanis commented 3 years ago

I confirmed shredos writes wrong prng data also with default last pass verify. I've tested following order:

  1. Run shredos with "--prng=isaac".
  2. Set method to prng.
  3. Leave prng option default. (Last pass verify)
  4. Start.
  5. I stopped shredos by Ctrl+c after some writing progress, before final blanking begins.

And this is the result.

1 2

As you can see, there are 4 KiB blocks. Each blocks begin with log text followed by bunch of 0x00, and 0x41F00100, 0xF1EF0100 in footer.

PartialVolume commented 3 years ago

@alphanis Confirmed, this is also a bug in nwipe. I'm currently working on a fix. If you have time could you open an issue over on nwipe, don't worry about mentioning the grub.cfg in ShredOS as I can reproduce this on the command line in ubuntu as well using the command sudo ./nwipe -v --prng=isaac --verify=all /dev/loop29.

You can also reproduce this issue without the verification errors by zeroing the drive, confirming it zero'ed with a hexeditor then putting --prng=isaac on the command line sudo ./nwipe -v --prng=isaac /dev/loop29 and in the GUI switching to PRNG, no verification and no final blanking. The wipe completes without errors however using the hexeditor I just see the zero'ed drive rather than the PRNG stream. If I then do a mersenne prng, no verification, no blanking, then check with the hexeditor for the prng stream it's there on the disc. If I then repeat the sudo ./nwipe -v --prng=isaac /dev/loop29 with no verification, no blanking I should see a different stream however what I see is the disc filled with zero's.

So the disc is being written as confirmed by the log but apparently not with the isaac prng. I suspect it's writing the uninitialized buffer, that should have been initialized with the prng stream which is probably why you are seeing random log messages.

As you previously mentioned, if you don't specify --prng=isaac on the command line but do a PRNG, isaac, no verify, no blanking, the stream gets written correctly. So the problem only shows itself when you put prng=isaac on the command line.

I hope to get this fixed over the next few days in nwipe and issue a 0.31 release that I'll pull into ShredOS, time permitting by the end of the weekend.

Thanks again for the detailed info, it was very helpful.

PartialVolume commented 3 years ago

As the bug is specifically in nwipe rather than ShredOS, the conversation can be followed over at https://github.com/martijnvanbrummelen/nwipe/issues/318