Fix obscure incorrect percentage on completion.

[PartialVolume]

This bug only applies to ones wipe and one or zero's verification.

A very rare occurrence of a incorrect percentage on completion. The actual wipe was completed correctly it was just that the percentage calculation was wrong.

This was due to a variable that was initialised for all methods except ones, & ones & zeros verification.

For those three method's the uninitialised variable would have had to have the value 1 or 6 for the incorrect percentage to be calculated, this is why it was so rare.

Corrected by initialising the variable with a -1 so that if no method was found in the array then no extra calculations as regards the percentage are performed.

[mdcato]

PartialVolume, I ran two sets of wipes with the same two drives, a 500GB SSD and a 4TB spinning. First set was with USB adapters, 2nd set with the same drive connected via SATA. When using the USB adapters, the PDF reports had correct bytes erased & percentage. They also report no hidden area. When using the SATA interface, the PDF reports had the LARGE percentage values, and that Hidden Area Found with the warning that hidden sectors were not erased. It sounds like you had to do some sleuthing to find the bug giving the wrong percentage, hopefully this will be similar.

I also note that with the USB adapters, the Model is the mfr (Sabrent) of the USB-SATA adapter that the SSD was attached rather than the drive model. The drive model is correct in the smartctl data: [2023/03/20 17:10:15] info: smartctl: device model: Samsung SSD 860 EVO 500GB I'm not sure where the USB adapter name came from, it's not listed individually in the log. I recommend that if the smartctl device model info is available, that it be used rather than the USB adapter name since people are more insterested in matching the drive info rather than how it was attached.

Here are the generated files using the USB adapters: nwipe-20230320-1.log nwipe_report_2023-03-20-18-10-52_Model__SABRENT_Serial_S3Z1NB1KC20617F.pdf nwipe_report_2023-03-21-09-26-14_Model_ST4000VN_008_2DR166_Serial_ZGY1DA5C.pdf

Here are the generated files using the SATA interface: nwipe-20230320-2.log nwipe_report_2023-03-21-14-04-58_Model_Samsung_SSD_860_Serial_S3Z1NB1KC20617F.pdf nwipe_report_2023-03-22-05-18-25_Model_ST4000VN008_2DR1_Serial_ZGY1DA5C.pdf

[PartialVolume]

Re the 'Sabrent' appearing in model, I think that's the USB adapter changing one of the drive model fields that we obtain from the disk, I think drive model appears in different places in the drive including in the smart data which is why smartctl shows the correct info. I've not seen a USB adapter do that before. The Unitek one I've got shows the drive model correctly.

We use the libparted library to obtain the drive model. I'll have a think about that. Maybe with a USB device I could use the smart data device name if it can be accessed that is via the USB adapter.

I'm not sure where the USB adapter name came from, it's not listed individually in the log.

Yes, it does appear in the log [2023/03/20 17:10:15] notice: Found /dev/sda, USB, SABRENT, 500 GB, S/N=S3Z1NB1KC20617F

Hopefully a quiet day tomorrow and I can get some revised code to you. I think I've fixed those issues you see, I'm just running various test cases to see if I've missed anything.

[mdcato]

I was unclear, I wasn't sure which method (libparted, Smartctl, etc) was supplying the name. Sabrent is the brand of the USB adapter, it's just not what I think is important in identifying the drive. The important part is the model name of the drive (and it's ser#, but that has been accurate).

(Sent from mobile)

---

From: PartialVolume @.> Sent: Wednesday, March 22, 2023 8:53:04 PM To: martijnvanbrummelen/nwipe @.> Cc: Mike Cato / Hays Technical Services @.>; Comment @.> Subject: Re: [martijnvanbrummelen/nwipe] Fix obscure incorrect percentage on completion. (PR #459)

Re the 'Sabrent' appearing in model, I think that's the USB adapter changing one of the drive model fields that we obtain from the disk, I think drive model appears in different places in the drive including in the smart data which is why smartctl shows the correct info. I've not seen a USB adapter do that before. The Unitek one I've got shows the drive model correctly.

We use the libparted library to obtain the drive model. I'll have a think about that. Maybe with a USB device I could use the smart data device name if it can be accessed that is via the USB adapter.

I'm not sure where the USB adapter name came from, it's not listed individually in the log.

Yes, it does appear in the log [2023/03/20 17:10:15] notice: Found /dev/sda, USB, SABRENT, 500 GB, S/N=S3Z1NB1KC20617F

Hopefully a quiet day tomorrow and I can get some revised code to you. I think I've fixed those issues you see, I'm just running various test cases to see if I've missed anything.

— Reply to this email directly, view it on GitHubhttps://github.com/martijnvanbrummelen/nwipe/pull/459#issuecomment-1480471199, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANGK2PS263WJ2PXMA7E3463W5OUIBANCNFSM6AAAAAAWBRFZWE. You are receiving this because you commented.Message ID: @.***>

[PartialVolume]

@mdcato apologies for the delay getting back to this. It got suddenly busy in the day job and will be for the next couple of weeks. I should then be able to get back to this with some revised code.

I'm thinking of ways to integrate the removal of the HPA/DCO into the user interface. What I'm thinking is this. Currently you run nwipe and you get a flashing "Hidden Sectors Detected". From what I've found with clearing HPA's or resetting DCOs, some drives don't behave properly after a reset of the DCO, in terms of getting SG_IO errors and such, unless you power cycle the drive. Also there's the issue of Linux not recognising the new correct size of the drive unless you reboot.

So I'm thinking, what if a new method might be "Expose Hidden Sectors". So when you see the drive has hidden sectors you just select the method "Expose Hidden Sectors", that methods info screen is displayed where it will describe the process it will perform i.e it will reset the HPA & DCO then issue the message powering off the system with instructions that you need to power it back on manually and the hidden sectors are now exposed, i.e HPA/DCO reset.. So you go ahead and power it back up and drives come up in nwipe with no more hidden sectors messages. At this point you could then do a standard wipe or select the "secure erase" method.

Regarding secure erase, I've noticed that most drives I've completed 'secure erase enhanced' on just wipe with zeros, however I've come across one that didn't. Each block was the same but consisted of something like 0h31ee31ee31ee31ee31ee31ee31ee31ee ..... Now I want to have nwipe be able to verify those wiped blocks so when secure erase is selected with verification, there will be a new type of verification, 'auto'. The code would sample say 100 random blocks from the disc to determine what the secure erase used to wipe the blocks actually was. If all 100 blocks match then verification will proceed using the value of the block it found. In this may it doesn't matter if the secure erase wiped using zeros, ones or some pattern repeated for every block nwipe could still verify it. I've not come across any drives that do a PRNG type secure wipe which of course would be impossible to verify as we wouldn't know what the PRNG method was or the seed.

From a user perspective they would just select method "ATA Secure Erase" and verification "Auto". It would default to "Auto" if you had selected "ATA secure erase". It would issue the secure erase enhanced wipe to the drive and once that was completed, read 100 random blocks to determine what secure erase used to wipe the drive then proceed with the verification.

For the actual secure erase wipe, nwipe's user interface would count down from the estimated time rather than use a percentage as we cannot determine how many blocks the firmware has wiped but we do know the estimated time. So say the estimated time to wipe is 52 minutes the wipe progress would be T-005200, then T-005159, T-005158 etc until it reached T-000000 and if the wipe was still running would become T+000001 and so on. When the wipe finished it would then do the verification but this would display as a percentage as normal. In this way the user can see the progress of the secure erase even though we don't know exactly when it will complete. I prefer the T- & T+ as going over the 100% would just look like the percentage code was broken.

How does that sound? I feel it integrates these methods without making drastic changes to the existing user interface, so anybody that's already familiar with nwipe or dwipe (DBAN) would have no problem understanding it.

[PartialVolume]

oh, and of course nwipe would need to automatically cope with a frozen drive by issueing a rtcwake -m mem -s 5 to power down the system and rewake to unfreeze it so it could perform a secure erase. Also it would need to cope with a locked or security enabled disc. One where the operator had purposely or accidentally aborted a secure erase without letting it complete resulting in a unresponsive drive. Nwipe would need to recognise that and suggest a secure erase be performed to unlock the drive.

So there could be three extra methods in all

Expose Hidden Sectors (Reset HPA/DCO) ATA Secure Erase ATA Secure Erase plus PRNG

With those last two methods you could also add a standard blanking pass. If I added the option to select either a ones or zeros blanking pass then that would provide the option for those that wanted to do a secure erase on a SSD followed by a standard ones wipe or if they are paranoid about their data and not concerned about it's longevity too much, then a ATA Secure Erase plus PRNG with ones blanking pass and verification on all three passes, could be performed.