Coder Social home page Coder Social logo

partialvolume / shredos.x86_64 Goto Github PK

View Code? Open in Web Editor NEW
1.3K 22.0 54.0 92.03 MB

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

License: Other

Makefile 65.33% Arc 0.05% Shell 6.99% Tcl 0.17% Batchfile 0.21% M4 0.05% Lua 0.20% C 9.36% C++ 0.81% CMake 0.08% Dockerfile 0.03% Perl 0.73% Lex 0.10% Yacc 0.26% Python 15.39% Java 0.05% Roff 0.15% Forth 0.03% JavaScript 0.01% Gnuplot 0.01%
disk eraser erase erase-disk delete dod wipe prng prng-methods hdparm

shredos.x86_64's Introduction


Logo

Buy Me A Coffee

ShredOS x86_64 - Disk Eraser

For all Intel and compatible 64 & 32 bit processors

As well as a 64bit versions, also included are 32bit .img & .iso images of ShredOS that will run on both 32bit and 64bit processors, see Release Assets and the table of download links below. For those that wish to build their own ShredOS from source, rather than just burn the .img/.iso images, instructions for modififing the x86_64 build to generate 32bit code as well as .iso images will be included below in the notes in due course.

For those that just want to get on with using ShredOS, you can download the pre-built .img or .iso images and burn them straight to USB flash drive or CD/DVD. Boot from the USB flash drive or CD/DVD and nwipe will appear ready for you to select your preferred wipe options.

GitHub all releases

Download the Latest ShredOS .img and .iso files for burning to USB flash drives and CD-R/DVD-R.

NOTE! There may be pre-release versions that are newer than the latest versions listed below, To see all versions, pre-release & latest The latest versions contain a full set of .img & .iso images in 32bit & 64bit while the pre-releases generally only contain a 64bit .img. Which should you use? Well, unless you need either 32 bit images or .iso images I would tend to download the very latest pre-release. Even the pre-releases are subjected to a fair amount of testing before they become a pre-release.

ShredOS version v2024.02.2_26.0_x86-64_0.37 (Latest Release)

Nwipe Version File to download
v0.37 ShredOS .img x86_64bit for USB Vanilla
v0.37 ShredOS .iso x86_64bit for CD/DVD/Ventoy, Vanilla
v0.37 ShredOS .iso x86_64bit for CD/DVD/Ventoy nomodeset

ShredOS version v2023.08.2_25_x86-64_0.35 (Previous Release)

Nwipe Version File to download
v0.35 ShredOS .img x86_64bit for USB Vanilla DRM
v0.35 ShredOS .iso x86_64bit for CD/DVD, Ventoy Vanilla DRM
v0.35 ShredOS .iso x86_64bit for CD/DVD, Ventoy nomodeset NoDRM
v0.35 ShredOS .img i586_32bit for USB Vanilla
v0.35 ShredOS .iso i586_32bit for CD/DVD

For all releases including latest and more recent pre-releases releases

Note: The .img files for burning to USB flash drives support both bios/UEFI booting. The .iso image currently supports legacy bios booting only and not UEFI, however, a bios/UEFI version of the .iso is in development and will be released shortly. You can also consider VENTOY (Open Source tool to create bootable USB drive for ISO/WIM/IMG/VHD(x)/EFI files) as a workaround to avoid bios/UEFI issues.

Demo video below: ShredOS automatically displays Nwipe's interactive GUI at boot.

You can then select one or more drives to be erased, wipe method or pattern to be used, number of rounds, whether a zeros blanking pass is applied, verification options such as last pass, all passes or no verification. ShredOS and nwipe are highly configurable so if you prefer to run nwipe without a GUI then you can configure nwipe by applying nwipe options to the linux command line in grub.cfg on the USB flash drive.

Example wipe

Below: Example of ShredOS's (Nwipe) multi page PDF certificate.

A certificate can optionally be created for each drive erased, the default is to create the certificate, but can be disabled by either an nwipe option applied in grub.cfg or via the nwipe configuration menu. The status of which is saved to the USB stick you booted from, so next time you boot from the USB stick the configuration settings are remembered. The first page of the PDF certificate contains details of the erasure and whether it was succesfully erased, failed due to drive errors, or partially erased due to HPA/DCO hidden sectors. Pages two and three contain the drives smart data. Example Certificate

  1. What is ShredOS?
  2. What do I do after I've erased everything on my disk? What is actually erased?
  3. Nwipe's erasure methods
  4. Obtaining and writing ShredOS to a USB flash drive - The easy way!
    1. Linux and MAC users
    2. Windows users
    3. Multi OS with VENTOY
    4. How to edit the ShredOS /EFI/BOOT/grub.cfg and boot/grub.cfg files when using Ventoy with ShredOS .img files
  5. A word about the MAC Book Pro
  6. Having trouble with USB adapters not working/hanging, want to buy one that works properly!
  7. Virtual terminals
  8. How to exclude the fat formatted shredos boot drive from nwipe interactive and autonuke modes
  9. How to run nwipe so you can specify nwipe command line options
  10. How to change the default nwipe options so the change persists between reboots
  11. How to set the keyboard map using the loadkeys command (see here for persistent change between reboots
  12. How to make a persistent change to keyboard maps
  13. Saving nwipes PDF certificates and log files to USB ftp or tftp servers
    1. Transferring nwipe log files to a USB storage device
    2. Transferring nwipe log files to a ftp server using lftp
  14. How to wipe drives on headless systems or systems with faulty display hardware. (For use on secure LANs only)
  15. Nwipe's font size is too small, How to double the size of the text
  16. Shredos includes the following related programs
    1. smartmontools
    2. hexedit
    3. hdparm
  17. Compiling shredos and burning to USB stick, the harder way!
    1. Install the following prerequisite software first. Without this software, the make command will fail
    2. Download the ShredOS source using the git command and build ShredOS
    3. Commands to configure buildroot, you will only need to use these if you are making changes to ShredOS
  18. Important ShredOS files and folders when building from source
    1. ../board/shredos/doimg.sh
    2. ../board/shredos/version.txt
    3. ../board/shredos/fsoverlay/
    4. ../board/shredos/fsoverlay/etc/init.d/S40network
    5. ../board/shredos/fsoverlay/usr/bin/nwipe_launcher
    6. ../package/nwipe/
    7. ../package/nwipe/nwipe.mk
    8. ../package/nwipe/nwipe.hash
    9. ../package/nwipe/Config.in
    10. ../package/nwipe/002-nwipe-banner-patch.sh

What is ShredOS?

ShredOS is a USB bootable (BIOS or UEFI) small linux distribution with the sole purpose of securely erasing the entire contents of your disks using the program nwipe. If you are familiar with dwipe from DBAN then you will feel right at home with ShredOS and nwipe. What are the advantages of nwipe over dwipe/DBAN? Well as everybody probably knows, DBAN development stopped in 2015 which means it has not received any further bug fixes or support for new hardware since that date. Nwipe originally was a fork of dwipe but has continued to have improvements and bug fixes and is now available in many Linux distros. ShredOS hopefully will always provide the latest nwipe on a up to date Linux kernel so it will support modern hardware.

ShredOS supports either 32bit or 64bit processors. You will need to download the appropriate 64bit or 32bit .img or .iso file, depending upon your target processor and whether you want to burn ShredOS to a USB memory stick, in which case you would download the .img file. Alternatively, if you wanted to burn ShredOS to CD/DVD, then you would download the .iso file.

Because ShredOS boots and runs straight from a USB flash drive or DVD/CD, it doesn't matter what operating system already exists on the computer. It will remove all data/directories/operating systems, from the drive or drives you have selected for wiping, leaving a disk with no trace of what originally existed. It will wipe PC's & Intel based MACs, such as MAC Book Pros. It doesn't care what operating system previosuly existed, be it Windows/MAC OSX/Linux/VXWorks.

ShredOS can be used as a software image and booted via the network using a client PC that supports Preboot execution environment (PXE) via a PXE enabled server. A procedure for creating a simple UEFI PXE server based on Debian/Ubuntu and serving up ShredOS can be found here #148

You can also use ShredOS on headless systems or systems with faulty display hardware as it includes a user enabled telnet server. Further details can be found here. How to wipe drives on headless systems or systems with faulty or missing display hardware or keyboards

ShredOS includes the latest Nwipe official release, but in addition includes other disk related utilities such as Smartmontools, hdparm, a hexeditor hexedit, and, the program loadkeys which can be used for setting the keyboard layout. Nwipe automatically starts it's GUI in the first virtual terminal (ALT-F1), hdparm, smartmontools and hexeditor can be run in the second virtual terminal, (ALT-F2). Nwipe will erase drives using a user selectable choice of seven methods. hdparm - amongst many of its options - can be used for wiping a drive by issueing ATA erase commands to the drive's internal firmware. This is a planned feature addition to nwipe.

ShredOS boots very quickly and depending upon the host system can boot in as little as 2 seconds (typically 4 to 6 seconds) on modern hardware, while on an old Pentium4 may take 40+ seconds. Nwipe automatically starts in GUI mode and will list the disks present on the host system. In fact, on version of ShredOS earlier than v2023.08.2_25.0_x86-64_0.35 nwipe can launch so fast that the USB devices have not yet initialised so the first time nwipe appears it may not show any USB drives, this behaviour has been fixed from version v2023.08.2_25.0_x86-64_0.35 onwards so there will usually be a delay of about 5-10 seconds while the USB devices are initialised. On older versions of ShredOS you would use Control-C to exit and restart nwipe to see any attached USB devices. You can then select the methods by which you want to securely erase the disk/s. Nwipe is able to simultanuosly wipe multiple disks using a threaded software architecture. I have simultaneously wiped 28 loop devices in tests and know of instances where it's been used to simultaneuosly wipe upwards of fifty drives on a rack server.

The vanilla version of ShredOS boots into nwipe's GUI and shows the available discs that can then be selected for wiping. It does not autonuke your discs at launch, however it is capable of doing that, if you edit the grub.cfg file and specify the appropriate nwipe command line option. Details of configuring nwipe's launch behaviour is shown below How to run nwipe so you can specify nwipe command line options

What do I do after I've erased everything on my disk? What is actually erased?

This paragraph is for those that are not familiar with wiping disks. if you know what you are doing skip to the next section. So you have erased your disk with ShredOS/nwipe and nwipe reported zero errors and the disk was erased. In it's erased state and depending upon the method you used every block on the drive contains either zero's or meaningless random data. In this state the disk won't be recognised by your operating system except at a very low level or by specialised programs. You won't be able to write files to the disk because nwipe has removed everything, absolutely everything, the operating system is gone, all your data is gone, the partition table is gone, the file system gone, the MBR and all the files have been erased without a trace and will never ever be recovered from the disk. The only thing left is a whole load of zeros or random data. To make the disk usable again you will either need to format the disk, which creates a partition table and directory structure or install a new operating system such as Linux or Windows. Of course, if you are just disposing of or reselling the disk then you don't need to do anything else. So if you are reasonably happy that you know what you are doing and you understand that you will need to format the disk then I hope this software does it's job and is useful to you. Before you press that 'S' key to start the wipe, pause and double check you have selected the correct drive/s, something I always do !

Nwipe's erasure methods

  • Fill With Zeros - Fills the device with zeros (0x00), one round only.
  • Fill With Ones - Fills the device with ones (0xFF), one round only.
  • RCMP TSSIT OPS-II - Royal Canadian Mounted Police Technical Security Standard, OPS-II
  • DoD Short - The American Department of Defense 5220.22-M short 3 pass wipe (passes 1, 2 & 7).
  • DoD 5220.22M - The American Department of Defense 5220.22-M full 7 pass wipe.
  • Gutmann Wipe - Peter Gutmann's method (Secure Deletion of Data from Magnetic and Solid-State Memory).
  • PRNG Stream - Fills the device with a stream from the PRNG.
  • Verify Zeros - This method only reads the device and checks that it is filled with zeros (0x00).
  • Verify Ones - This method only reads the device and checks that it is filled with ones (0xFF).
  • HMG IS5 enhanced - Secure Sanitisation of Protectively Marked Information or Sensitive Information

Nwipe also includes the following pseudo random number generators:

  • Mersenne Twister (mt19937ar-cok)
  • ISAAC (rand.c 20010626)
  • ISAAC-64 (isaac64.c)
  • Lagged Fibonacci (from v2024.02.2_26.0_x86-64_0.37)
  • XORoshiro-256 (from v2024.02.2_26.0_x86-64_0.37)

Obtaining and writing ShredOS to a USB flash drive, the easy way!

You can of course compile ShredOS from source but that can take a long time and you can run into all sorts of problems if your not familiar with compiling an operating system. So if you just want to get started with using ShredOS and nwipe then just download the ShredOS image file and write it to a USB flash drive. Please note this will over write the existing contents of your USB flash drive.

Download the latest ShredOS for either 32bit, 64bit, .img or .iso from here

Linux (and MAC) users

Check it's not corrupt by running the following command and comparing with the checksum shown in the release notes:

$ sha1sum shredos.img.tar.gz (shasum instead of sha1sum if you're using a MAC)
(example) sha1 db37ea8526a17898b0fb34a2ec4d254744ef08a1 shredos.img.tar.gz

If the image file has a .img.tar.gz extension then use the following commands to extract the .img file. If the file extension simply ends with .img and there is no tar.gz then skip this step.

$ gunzip shredos.img.tar.gz
$ tar xvf shredos.img.tar

If you are using linux or a MAC write the shredos.img file (also sometimes called shredos-2020MMDD.img i.e. shredos-20200418.img etc) to your USB flash drive using the following command. (/dev/sdx is the device name of your USB drive, this can be obtained from the results of sudo fdisk -l on linux and diskutil list on a MAC)

sudo dd if=shredos.img of=/dev/sdx

Windows users:

If you are a windows user, use a program such as Rufus or etcher to write the image file to a USB stick, remembering that the entire contents of the USB flash drive will be overwritten. Winzip can be used to extract the shredos.img file from the compressed shredos.img.tar.gz file that you downloaded. hashtab can be downloaded and used to confirm the sha1 checksum.

Multi OS with VENTOY

As explained on the GitHub repository:

Ventoy is an open source tool to create bootable USB drive for ISO/WIM/IMG/VHD(x)/EFI files. With ventoy, you don't need to format the disk over and over, you just need to copy the image files to the USB drive and boot it. You can copy many image files at a time and ventoy will give you a boot menu to select them. You can also browse ISO/WIM/IMG/VHD(x)/EFI files in local disk and boot them. x86 Legacy BIOS, IA32 UEFI, x86_64 UEFI, ARM64 UEFI and MIPS64EL UEFI are supported in the same way. Both MBR and GPT partition style are supported in the same way. Most type of OS supported(Windows/WinPE/Linux/Unix/ChromeOS/Vmware/Xen...) 920+ ISO files are tested (List). 90%+ distros in distrowatch.com supported (Details).

Once your USB removable drive is having VENTOY installed, you just have to copy the latest .img or .iso version of ShredOS to the root of your Ventoy USB stick

How to edit the ShredOS /EFI/BOOT/grub.cfg and boot/grub/grub.cfg files when using Ventoy with ShredOS .img files

As Ventoy simply requires you to copy the .img file to the root of the Ventoy USB stick, to edit the ShredOS grub.cfg files it's neccessary to unpack the ShredOS .img, edit the files and re-create the .img file that now includes the modified grub files. The procedure below shows you how to do this on a Linux distro.

Create a file on the disk that is slightly larger than the size of the ShredOS .img. In this example we will use shredos-2023.08.2_25.1_x86-64_0.35_20231202.img which is 260646656 bytes in size (260.64MByte, 248.57MiByte). So if we create a empty file that is 270Mbyte in size that should be sufficient. I'm going to go a bit over the top and create a 500MB file for this example but that isn't necessary if all you are doing is editing the grub files

>truncate -s 500M loopbackfile.img

Create a virtual disk, i.e /dev/loopx that uses the file we just created

>sudo losetup -fP loopbackfile.img

We need to determine what device name our loopbackfile.img is associated with. In our example we will assume losetup returns the device /dev/loop30

>sudo losetup -a | grep -i loopbackfile.img
/dev/loop30

We now have a virtual disk called /dev/loop30 that is 270MB in size. Now copy the shredos-2023.08.2_25.1_x86-64_0.35_20231202.img file onto this virtual disk using the dd command

>sudo dd if=shredos-2023.08.2_25.1_x86-64_0.35_20231202.img of=/dev/loop30

Determine the partition name of this ShredOS virtual drive. As can be seen below the partition name is /dev/loop30p1

>sudo fdisk -l /dev/loop30
	Disk /dev/loop30: 500 MiB, 524288000 bytes, 1024000 sectors
	Units: sectors of 1 * 512 = 512 bytes
	Sector size (logical/physical): 512 bytes / 512 bytes
	I/O size (minimum/optimal): 512 bytes / 512 bytes
	Disklabel type: dos
	Disk identifier: 0x00000000

Device        Boot Start    End Sectors  Size Id Type
/dev/loop30p1       1263 509075  507813  248M  c W95 FAT32 (LBA)

Mount the /dev/loop30p1 partition to a folder called virtual_disc

>mkdir virtual_disc
>sudo mount /dev/loop30p1 virtual_disc

You can now edit the grub.cfg files

>vi virtual_disc/EFI/BOOT/grub.cfg
>vi virtual_disc/boot/grub/grub.cfg

Once you have finished making your changes unmount the drive

>sudo umount virtual_disc

Create the new ShredOS .img file

>sudo dd if=/dev/loop30 of=shredos_with_mods.img

Copy shredos_with_mods.img to the root of the Ventoy USB stick and boot the Ventoy USB stick. You can confirm your changes to the kernel commmand line by booting ShredOS, switching to a virtual terminal ALT F2, and type more /proc/cmdline

Virtual Terminals

ShredOS has three tty terminals, ALT-F1 (Where nwipe is initially launched), ALT-F2 (A virtual terminal), ALT-F3 (console log, login required which is root with no password). Typical use of a virtual terminal might be to run other disk related tools such as hdparm to remove hidden sectors or hexedit to display the contents of the disk as hexadecimal values.

How to exclude the FAT formatted ShredOS Boot drive from Nwipe, interactive and autonuke modes

There are two methods that can be used to exclude the FAT formatted ShredOS boot drive from appearing in nwipe's interactive mode or autonuke modes.

  • Method 1: The first method is to place the following string shredos_exclude_boot_disc="yes" on the kernel command line in /boot/grub/grub.cfg and EFI/BOOT/grub.cfg on the ShredOS boot drive. This method obviously requires access to the grub.cfg file so is particularily suitable if you are creating your ShredOS boot drive using dd, Rufus or a similiar program however it's not possible to use this method if you are copying the .iso or .img file to a Ventoy USB drive as you would need to either unpack, edit the grub.cfg files and repack the .img or build the .iso or .img from source after editing the grub.cfg in the source. So for Ventoy users who want to exclude the FAT formatted ShredOS boot drive you should consider method 2 below.
set default="0"
set timeout="0"
menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3 shredos_exclude_boot_disc="yes"
  • Method 2: The second method is to create a empty file on the ShredOS boot disk at this specific location /etc/shredos/shredos_exclude_disc. This method will work irespective of whether you created the ShredOS boot disk with dd, Rufus or copied the .iso/.img to a Ventoy flash drive.

WARNING You should not place the string /etc/shredos/shredos_exclude_disc on multiple FAT formatted drives or for that matter any drive irrespective of formatting, expecting all the drives with this string to not appear in nwipe or not get wiped in interactive mode. The file /etc/shredos/shredos_exclude_disc should only appear on the one and only ShredOS boot drive on the system. Any other drives that contain /etc/shredos/shredos_exclude_disc will appear in nwipe and WILL get wiped in autonuke mode.

A word about the MAC Book Pro

Yes, ShredOS will boot on MAC Book Pros, however here's a few tips you may find useful.

  • Booting from USB. Power off then power on holding down the alt key. After a few seconds select EFI boot.
  • Due to the high resolution screens on a MAC Book Pro you may find the text displayed by nwipe and in the virtual terminals is very small. To enlarge the text follow the instructions here.
  • How to switch between virtual terminals on a MAC. On a PC it's usually (but not always) ALT F1 (/dev/tty1 - nwipe), ALT F2 (/dev/tty2 or /dev/tty0 - terminal), ALT F3 (/dev/console - console). However on a MAC you switch virtual terminals as follows. FN+ALT F1 (/dev/tty1 - nwipe), FN+ALT F2 (/dev/tty2 or /dev/tty0 - terminal), FN+ALT F3 (/dev/console).

How to make a persistent change to the terminal resolution

This procedure only applies to setting the resolution of the frame buffer in legacy boot. Using set gfxpayload=1024x768x16 appears to have no affect on UEFI resolution.

After you have created the bootable ShredOS USB flash drive, you may want to increase the resolution from the default value which is usually quite low, i.e. 640x480 in legacy boot.

If you prefer a higher resolution than 640x480, then edit the /boot/grub/grub.cfg file as shown below. However very occasionally it might be necessary to change the resolution. Case in point, a blank screen after booting ShredOS. Sometimes you may come across a monitor that will not work with 640x480 resolution, such as the HP compaq LA2405X. In which case you should increase the resolution to 1024x768x16 which seems to work with the majority of monitors, even 16:10/16:9 ratio monitors.

Example resolutions based on screen aspect ratio:

4:3 aspect ratio resolutions: 640ร—480, 800ร—600, 960ร—720, 1024ร—768, 1280ร—960, 1400ร—1050, 1440ร—1080 , 1600ร—1200, 1856ร—1392, 1920ร—1440, and 2048ร—1536.

16:10 aspect ratio resolutions: 1280ร—800, 1440ร—900, 1680ร—1050, 1920ร—1200, 2560ร—1600 and 2880x1800.

16:9 aspect ratio resolutions: 1024ร—576, 1152ร—648, 1280ร—720, 1366ร—768, 1600ร—900, 1920ร—1080, 2560ร—1440 and 3840ร—2160.

Add the command set gfxpayload=1024x768x16 prior to the kernel command line, changing the resolution as required for your hardware/monitor. See the example below:

set default="0"
set timeout="0"
set gfxpayload=1024x768x16
menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3
}

How to run nwipe so you can specify nwipe command line options

The version of nwipe that runs in the default terminal will automatically restart when you exit it, either at the end of a wipe or using CONTROL-C to abort. So if you want to run nwipe in the traditional way, along with any command line options you require, then use the second terminal ALT-F2, as an example, you could then use the command nwipe --nousb --logfile=nwipe.log etc. If you do use ALT-F2 to run a second copy of nwipe, please remember that if you already have one copy of nwipe wiping, the second copy of nwipe will hang on starting. Therefore nwipe in the default terminal should be left at the drive selection screen to prevent the second occurence of nwipe from hanging. Alternatively, a second occurrence of nwipe could be started by specifying the drive on the command line as long as that drive is not already being wiped by the first instance of nwipe, i.e.nwipe /dev/sdc etc.

How to change the default nwipe options so the change persists between reboots

To change the default settings of nwipe you will need to place the nwipe options required on the kernel command line in /boot/grub/grub.cfg and /EFI/BOOT/grub.cfg

Example of default grub.cfg

set default="0"
set timeout="0"

menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3
}

Adding nwipe_options="..." to grub.cfg to make the default nwipe start up with zero method, no verification, no blanking, ignore USB devices and automatically power off the computer at the end of the wipe.

set default="0"
set timeout="0"

menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3 nwipe_options="--method=zero --verify=off --noblank --nousb --autopoweroff"
}

You are not only limited to nwipe options, you can also specify devices along with those options. As would be the case when using nwipe from the command line, the devices to be wiped come after the options, as shown in the example below.

set default="0"
set timeout="0"

menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3 nwipe_options="--method=zero --verify=off --noblank --nousb --autopoweroff /dev/sdd /dev/sde"
}

For reference and as of nwipe v0.37 (from v2024.02.2_26.0_x86-64_0.37), listed below are all the options that you can use with nwipe and can place on the kernel command line in grub.cfg as described in the examples above.

sudo nwipe --help
Usage: nwipe [options] [device1] [device2] ...
Options:
  -V, --version           Prints the version number

  -v, --verbose           Prints more messages to the log

  -h, --help              Prints this help

      --autonuke          If no devices have been specified on the command line,
                          starts wiping all devices immediately. If devices have
                          been specified, starts wiping only those specified
                          devices immediately.

      --autopoweroff      Power off system on completion of wipe delayed for
                          for one minute. During this one minute delay you can
                          abort the shutdown by typing sudo shutdown -c

      --sync=NUM          Will perform a sync after NUM writes (default: 100000)
                          0    - fdatasync after the disk is completely written
                                 fdatasync errors not detected until completion.
                                 0 is not recommended as disk errors may cause
                                 nwipe to appear to hang
                          1    - fdatasync after every write
                                 Warning: Lower values will reduce wipe speeds.
                          1000 - fdatasync after 1000 writes etc.

      --verify=TYPE       Whether to perform verification of erasure
                          (default: last)
                          off   - Do not verify
                          last  - Verify after the last pass
                          all   - Verify every pass
                          
                          Please mind that HMG IS5 enhanced always verifies the
                          last (PRNG) pass regardless of this option.

  -m, --method=METHOD     The wiping method. See man page for more details.
                          (default: dodshort)
                          dod522022m / dod       - 7 pass DOD 5220.22-M method
                          dodshort / dod3pass    - 3 pass DOD method
                          gutmann                - Peter Gutmann's Algorithm
                          ops2                   - RCMP TSSIT OPS-II
                          random / prng / stream - PRNG Stream
                          zero / quick           - Overwrite with zeros
                          one                    - Overwrite with ones (0xFF)
                          verify_zero            - Verifies disk is zero filled
                          verify_one             - Verifies disk is 0xFF filled
                          is5enh                 - HMG IS5 enhanced

  -l, --logfile=FILE      Filename to log to. Default is STDOUT

  -P, --PDFreportpath=PATH Path to write PDF reports to. Default is "."
                           If set to "noPDF" no PDF reports are written.

  -p, --prng=METHOD       PRNG option (mersenne|twister|isaac|isaac64|add_lagg_fibonacci_prng)

  -q, --quiet             Anonymize logs and the GUI by removing unique data, i.e.
                          serial numbers, LU WWN Device ID, and SMBIOS/DMI data
                          XXXXXX = S/N exists, ????? = S/N not obtainable

  -r, --rounds=NUM        Number of times to wipe the device using the selected
                          method (default: 1)

      --noblank           Do NOT blank disk after wipe
                          (default is to complete a final blank pass)

      --nowait            Do NOT wait for a key before exiting
                          (default is to wait)

      --nosignals         Do NOT allow signals to interrupt a wipe
                          (default is to allow)

      --nogui             Do NOT show the GUI interface. Automatically invokes
                          the nowait option. Must be used with the --autonuke
                          option. Send SIGUSR1 to log current stats

      --nousb             Do NOT show or wipe any USB devices whether in GUI
                          mode, --nogui or --autonuke modes.

  -e, --exclude=DEVICES   Up to ten comma separated devices to be excluded
                          --exclude=/dev/sdc
                          --exclude=/dev/sdc,/dev/sdd
                          --exclude=/dev/sdc,/dev/sdd,/dev/mapper/cryptswap1

How to set the keyboard map using the loadkeys command (see here for persistent change between reboots)

You can set the type of keyboard that you are using by typing, loadkeys uk, loadkeys us, loadkeys fr, loadkeys cf, loadkeys by, loadkeys cf, loadkeys cz etc. See /usr/share/keymaps/i386/ for full list of keymaps. However you will need to add an entry to loadkeys=uk etc to grub.cfg for a persistent change between reboots.

Examples are: (azerty:) azerty, be-latin1, fr-latin1, fr-latin9, fr-pc, fr, wangbe, wangbe2

(bepo:) fr-bepo-latin9, fr-bepo

(carpalx:) carpalx-full, carpalx

(colemak:) en-latin9

(dvorak:) ANSI-dvorak, dvorak-ca-fr, dvorak-es, dvorak-fr, dvorak-l, dvorak-la, dvorak-programmer, dvorak-r, dvorak-ru, dvorak-sv-a1, dvorak-sv-a5, dvorak-uk, dvorak, no

(fgGIod:) tr_f-latin5, trf

(include:) applkey, backspace, ctrl, euro, euro1, euro2, keypad, unicode, windowkeys

(olpc:) es, pt

(qwerty:) bashkir, bg-cp1251, bg-cp855, bg_bds-cp1251, bg_bds-utf8, bg_pho-cp1251, ... by, cf, cz, dk, es, et, fi, gr, il, it, jp106, kazakh, la-latin1, lt, lv, mk, nl, nl2, no, pc110, pl, ro, ru, sk-qwerty, sr-cy, sv-latin1, ua, uk, us (for the full list see /usr/share/keymaps/i386/qwerty)

How to make a persistent change to keyboard maps

The default grub.cfg looks like this

set default="0"
set timeout="0"

menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3
}

Add the following options to the kernel command line, i.e. loadkeys=uk, loadkeys=fr etc

set default="0"
set timeout="0"

menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3 loadkeys=uk
}

Saving nwipes PDF certificates and log files to USB ftp or tftp servers

Nwipe creates a log file and one or more PDF certificates which show details of the disks and/or system being wiped. ShredOS creates a transfer.log and copy of the dmesg output which can be used for diagnostics. These files are automatically saved to the USB flash drive, if the user booted from a USB flash drive. Alternatively, if ShredOS has been configured, using the kernel command line options shredos_output="...", lftp="..." in grub.cfg to output these file to a ftp or tftp server then the PDF & log files will be sent there instead. Please be aware the the lftp option is deprecated and may be removed in a new version. shredos_output="..." currently supports ftp and tftp with sftp to be added in a new release. Described below are details of how you can configure ShredOS to output log and PDF files automatically to network servers.

What is the nwipe log file

The nwipe that is automatically launched in the first virtual terminal ALT-F1, creates a log file that contains the details of the wipe/s and a summary table that shows successfull erasure or failure. The file is time stamped within it's name. A new timestamped log file is created each time nwipe is started. The files can be found in the / directory. A example being nwipe_log_20200418-084910.txt. As of version v2021.08.2_23_x86-64_0.34 ShredOS will automatically copy the nwipe log files to the first FAT32 partition it finds, which is normally the ShredOS USB flash drive. In addition you can manually copy the log files or send them to a ftp server on your local area network. Both methods are described below starting with manually writing to a USB storage device.

Transferring nwipe log files to a USB storage device

  1. Locate the device name of your USB stick from it's model & size.

For Linux: If the | character isn't displayed properly use loadkeys fr etc to select the correct keyboard if not US qwerty prior to running this pipe command.

fdisk -l | more

For MACS:

diskutil list
  1. Create a directory that we will mount the USB flash drive on
mkdir /store
  1. Mount the USB flash drive, replacing sdx with the device name of your USB flash drive found in step 1
mount /dev/sdx1 /store
  1. Copy the log files to the USB flash drive
cp /nwipe_log* /store/
  1. Unmount the USB flash drive
cd /;umount store

Transferring nwipe log files to a ftp server using lftp

ShredOS uses the lftp application to transfer files to a remote server. To enable the automatic transfer of nwipe log files, you will need to edit both grub.cfg files (/boot/grub/grub.cfg and /EFI/BOOT/grub.cfg) on the ShredOS USB memory stick. In much the same way you you specify loadkeys or nwipe options which are described above, you edit the linux kernal command line and add the following lftp="open 192.168.1.60; user your-username your-password; cd data; mput nwipe_*.txt", changing the IP, username and password as required. As ftp does not encrypt data you should really only use it to transfer data on your local area network and not over the internet. sftp may be implemented at a future date if users request that feature. You can also manually use lftp on the command line (ALT-F2 or ALT-F3) if you prefer. I use this feature with a chrooted vsftpd ftp server on a Linux PC. The automatic transfer of nwipe log files will be initiated on completion of all wipes and after pressing any key in nwipe to exit. The lftp status will be shown after the nwipe summary table.

IMPORTANT

  • I would recommend you setup a new user account on the system that hosts your ftp server and only use that new user's account, username and password with ShredOS. You don't want to use your own personal user account details as you will be placing those details on the ShredOS USB storage device in a plain text format.
  • For security reasons, you should setup your ftp server as chrooted.

Example grub.cfg with the lftp option appended:

set default="0"
set timeout="0"

menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3 lftp="open 192.168.1.60; user your-username your-password; cd data; mput nwipe_*.txt; mput *.pdf"
}

vsftpd configuration for a chrooted server

For those using vsftpd as your ftp server, you will need to change /etc/vsftpd.conf as follows. Some of these entries may already be present but commented out, make a backup of /etc/vsftpd.conf prior to editing and the uncomment or alter as below:

anon_mkdir_write_enable=YES
listen=YES
listen_ipv6=YES
local_root=/home/yournewftpuser/ftpdata/
write_enable=YES
anon_mkdir_write_enable=YES
chown_uploads=YES
chown_username=yournewftpuser
nopriv_user=ftpsecure
ftpd_banner=Welcome to the ShredOS log server.
chroot_local_user=YES
chroot_list_enable=NO
secure_chroot_dir=/home/yournewftpuser/ftpdata

Disclaimer: The above settings should get you going but may or may not be ideal for your local situation. Refer to the vsftp website and forums if things aren't working as they should. The lftp application that ShredOS uses, should also work with any Microsoft Windows based ftp server, as well as Linux and MAC based systems.

How to wipe drives on headless systems or systems with faulty display hardware. (For use on secure LANs only)

ShredOS includes a user enabled telnet server. The downloadable .img images are supplied with telnet disabled as default.

To enable the telnet server, edit /boot/grub/grub.cfg or/and /EFI/BOOT/grub.cfg and on the USB flash drive, add telnetd=enable to the kernel command line.

Example:

set default="0"
set timeout="0"

menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3 telnetd=enable
}

Assuming the headless systems are configured to boot via USB and if UEFI that secure boot is disabled, just plug a USB stick containing ShredOS v2021.08.2_20_0.32.014 or higher into the system. Power cycle the system and then after giving ShredOS sufficient time to boot (4 to 60 seconds depending on the hardware) you can then, from another PC/laptop on the same network, use nmap as shown below to list all IP addresses that have open telnet ports on your local LAN:

nmap -p23 192.168.1.0/24 --open
$ nmap -p23 192.168.1.0/24 --open
Starting Nmap 7.80 ( https://nmap.org ) at 2021-11-29 20:54 GMT
Nmap scan report for 192.168.1.30
Host is up (0.071s latency).

PORT   STATE SERVICE
23/tcp open  telnet

Nmap scan report for 192.168.1.100
Host is up (0.050s latency).

PORT   STATE SERVICE
23/tcp open  telnet

Nmap done: 256 IP addresses (19 hosts up) scanned in 14.53 seconds
		

Telnet into the appropriate IP address telnet 192.168.1.100. ShredOS will respond with:

telnet 192.168.1.100
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.

shredos login: root
		{ no password }

sh-5.1# nwipe

Type nwipe as shown above and the nwipe GUI will be displayed and you can proceed with wiping the discs. On some terminals, i.e retro, nwipe doesn't display properly. If you find this then use a different terminal to launch nwipe. Terminals that do work ok are KDE's Konsole, terminator, guake, tmux, xfce terminal and xterm. Terminals that don't seem to work properly via a telnet session with nwipe are cool retro term and qterminal. Putty works but doesn't have the correct box characters but is usable. Putty may work perfectly if you can set the correct character encoding. These are my observations using KDE Neon, they may differ on your systems. If you find a workaround for those terminals that don't display nwipe perfectly over telnet, then please let me know.

Warning Due to the insecure nature of telnet as opposed to ssh, it goes without saying that this method of accessing ShredOS & nwipe should only be carried out on a trusted local area network and never over the internet unless via a VPN or SSH tunnel. ssh access may be provided at a future date if it's requested.

Nwipes font size is too small How to double the size of the text

If you are using a monitor with a native high resolution you may find that nwipe's font size is too small for your liking, if that's the case, you just need to type the following command in the second virtual terminal /bin/setfont -d -C /dev/tty1. To double the font size in other virtual terminals use /bin/setfont -d -C /dev/tty2 and /bin/setfont -d -C /dev/console.

Detail

Type ALT F2 (Fn ALT F2 on a MAC) to bring up the 2nd virtual console. Type the following tty command which will return the current console name. So from this result /dev/tty2 we can deduce that the default nwipe in ALT F1 is /dev/tty1. For reference ALT F3 is /dev/console.

tty
/dev/tty2

To set the font for the default nwipe in the first virtual console ALT F1 (/dev/tty1), type the following command in the 2nd virtual console (ALT F2)

/bin/setfont -d -C /dev/tty1

Warning Always specify the full path to setfont, setfont -d -C /dev/tty1 without the /bin/ prefix, will not work! There are actually two different versions of setfont on Linux and if you ommit the prefix path you will be running the wrong setfont which won't work.

image Default font size on a high resolution monitor. . image After running the setfont command.

ShredOS includes the following related programs

smartmontools

Nwipes ability to detect serial numbers on USB devices now works on USB bridges who's chipset supports that functionality. Smartmontools provides nwipe with that capability. Smartmontools can be used in the second or third virtual terminal. ALT-F2 and ALT-F3.

hexedit

Use hexedit to examine and modify the contents of a hard disk. Hexedit can be used in the second or third virtual terminal. ALT-F2 and ALT-F3.

hdparm

hdparm has many uses and is a powerfull tool. Although Nwipe will be adding ATA secure erase capability, i.e using the hard disk own firmware to initiate an erase, nwipe currently wipes drives using the traditional method of writing to every block. If you want to initiate a ATA secure erase using the drives firmware then hdparm will be of use.

Compiling ShredOS and burning to USB stick, the harder way !

The ShredOS system is based on the buildroot tool whos main application is to create operating systems for embedded systems. The image (.img) file is approximately 260 MiB and can be written to a USB memory stick with a tool such as dd or Etcher.

You can build shredos using the following commands. This example build was compiled on KDE Neon (Ubuntu 20.04).

Install the following prerequisite software first. Without this software, the make command will fail

$ sudo apt install git
$ sudo apt install build-essential   pkg-config   automake   libncurses5-dev   autotools-dev   libparted-dev   dmidecode   coreutils   smartmontools
$ sudo apt-get install libssl-dev
$ sudo apt-get install libelf-dev
$ sudo apt-get install mtools

Download the ShredOS source using the git clone command, build ShredOS and write to a USB memory device.

$ git clone https://github.com/PartialVolume/shredos.x86_64.git (or shredos.i686.git for 32bit)
$ cd shredos
$ mkdir package/shredos
$ touch package/shredos/Config.in
$ make clean
$ make shredos_defconfig
$ make
$ ls output/images/shredos*.img
$ cd output/images
$ dd if=shredos-20200412.img of=/dev/sdx (20200412 will be the day you compiled, sdx is the USB flash drive)

Issues that you may get when building ShredOS

  • Error: "Internal Size Too Big" If you are compiling the vanilla version of ShredOS and have made no alterations or additions but it fails to build the .img with the error "Internal error: size too big" then you may have a version of mtools that has a version of mcopy which has a bug whenever the -b option is used. This bug is known to exist in mcopy version 4.0.32 and maybe others but is fixed in v4.0.42. The solution is to upgrade your copy of mtools to a later version. However, if you have altered ShredOS by adding more packages you may need to update the size of the fat32 partition. You can do this by increasing the 'size' in ../board/shredos/genimage.cfg. Depending on how much extra software you have added increase the size by 10MB or more. Currently as of March 2023 the current size is size = 130000000, this is in bytes, so adding 10MB will mean you need to edit this value so that it reads size = 140000000. After the edit, just run make which will result in a quicker build. You don't need to run make clean first as that would result in a full rebuild which is not neccessary when all you are doing is increasing the final image size. If your repository does not supply a later version of mtools, then you can obtain mtools packages for various distros from here

INFO: vfat(boot.vfat): cmd: "MTOOLS_SKIP_CHECK=1 mcopy -bsp -i '/home/shredos/Downloads/shredos/mcopybug/shredos.x86_64/output/images/boot.vfat' '/home/shredos/Downloads/shredos/mcopybug/shredos.x86_64/output/images/grub.cfg' '::boot/grub/grub.cfg'" (stderr): Internal error, size too big Streamcache allocation problem:: 5 INFO: vfat(boot.vfat): cmd: "rm -f "/home/shredos/Downloads/shredos/mcopybug/shredos.x86_64/output/images/boot.vfat"" (stderr): ERROR: vfat(boot.vfat): failed to generate boot.vfat make[1]: [Makefile:823: target-post-image] Error 1 make: [Makefile:84: _all] Error 2

Commands to configure buildroot, you will only need to use these if you are making changes to ShredOS

Change buildroot configuration, select the architecture, install software packages then save the buildroot config changes to shredos_defconfig, the location if which is defined in the buildroot config within make menuconfig ALWAYS RUN make savedefconfig AFTER CHANGES are made in menuconfig.

$ make menuconfig
$ make savedefconfig # save the changes

Edit the linux kernel configuration, install kernel drivers .. then save the configuration.

$ make linux-menuconfig
$ make linux-update-defconfig # save the changes

Edit the busybox selection of software and save the configuration.

make busybox-menuconfig
make busybox-update-config # save the changes

Important ShredOS files and folders when building ShredOS from source

../board/shredos/doimg.sh

doimg.sh is a bash script, the main purpose of which is to generate the .img file located in output/images/. However it is also used to copy the pre-compiled .efi file and other files such as the shredos.ico, autorun.inf for Windows, README.txt. The contents of board/shredos/version.txt is also used to rename the .img file with version info and the current date and time.

../board/shredos/fsoverlay/etc/shredos/version.txt

This file contains the version information as seen in the title on nwipe's title bar, i.e. '2021.08.2_22_x86-64_0.32.023'. This version ingformation is also used when naming the .img file in ../output/images/ ../board/shredos/fsoverlay/etc/shredos/version.txt is manually updated for each new release of ShredOS.

../board/shredos/fsoverlay/

This fsoverlay directory contains files and folders that are directly copied into the root filesystem of ShredOS. A example of this is the ../board/shredos/fsoverlay/etc/inittab file where the tty1 and tty2 virtual terminals are configured. This is where you will find the script /usr/bin/nwipe_launcher that automatically starts in tty1 after ShredOS has booted. If you want to place or overwrite a specific file in the root filesystem of ShredOS, the ../board/shredos/fsoverlay/ directory is one way of inserting your own files.

../board/shredos/fsoverlay/etc/init.d/S40network

S40network is responsible for starting the network & obtaining a IP address via DHCP by starting a ShredOS script called /usr/bin/shredos_net.sh The shredos_net.sh script can also be found in the fsoverlay directory ../board/shredos/fsoverlay/usr/bin/shredos_net.sh which then ends up in the directory /usr/bin/ of the ShredOS filesystem.

../board/shredos/fsoverlay/usr/bin/nwipe_launcher

nwipe_launcher starts the nwipe program in tty1, see ../board/shredos/fsoverlay/etc/inittab which is where nwipe_launcher is called from. The nwipe_launcher script, apart from starting nwipe in tty1 also is responsible for calling the lftp program to automatically transfer log files to a remote ftp server on your local area network, assuming lftp has been enabled on the kernel command line. It also contains the 4,3,2,1 countdown and nwipe restart code.

../package/nwipe/

All programs in ShredOS appear under their individual sub-directory under the package directory, therefore, you will find all the information relating to the build of nwipe under ../package/nwipe. The four files contained here are involved in downloading the nwipe source from https://github.com/PartialVolume/nwipe, checking the integrity of the source by comparison of the hash, patching the nwipe version.c and compiling the code. Each file in ../package/nwipe/ is descibed below.

../package/nwipe/nwipe.mk

This is the buildroot make file for nwipe. This is where the nwipe source download is initiated & hash checked. It also patches the nwipe code, in the case of ShredOS the only patching to the vanilla nwipe code is to change the nwipe title bar from nwipe [version] to ShredOS [shredos version] i.e ShredOS 2021.08.2_22_x86-64_0.32.023. This file also includes nwipe dependencies and nwipe version number. Therefore is file should have the nwipe version number updated if a new version of nwipe is incorporated into ShredOS.

../package/nwipe/nwipe.hash

This file contains the sha1 hash for the nwipe tar file, i.e. nwipe-v0.32.023.tar.gz. The hash and filename contained in this file is manually updated with each new release of nwipe.

../package/nwipe/Config.in

This is a buildroot file that exists in each package. The only time it would be manually edited is if nwipe's dependendencies changed.

../package/nwipe/002-nwipe-banner-patch.sh

This script contains the changes that are made to nwipe's version.c

END OF README.md

shredos.x86_64's People

Contributors

exaneserverteam avatar itjamie avatar partialvolume avatar petski avatar rarzberger4 avatar tlschenkjr avatar wibeasley avatar wikijm avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

shredos.x86_64's Issues

Is shredos USB stick able to be removed once a wipe is started?

First of all, I have to say that I love this software; it is a very welcome upgrade from the now outdated DBAN. My organization is looking to use this software to sanitize a large number of HDDs, but I would like to know if it is safe to remove a shredos USB stick from a device after a wipe is started so that it can be used on another machine. I tested this out on a couple of desktops, and it seemed like everything was loaded to RAM and that removing the USB stick had no adverse effects. However, I thought that I would come here just to confirm that this was the case.

Other devices/drives no longer appearing

First, thanks for fixing that USB keyboard issue.

On the new version (v2020.02.004-0.30.001), I am unable to see any disks besides the USB drive I am booting off of. Going back to the old version, I can see them (but not wipe as the keyboard did not work).

The device I have connected is using nvme, not SATA.

shredOS terminal compressed to top line of screen on multi GPU laptop [fixed]

Thank you for fixing this! :D

17/11/2021: shredOS hangs (or crashes) during launch [fixed].

18/11/2021: added new drivers to shredOS.
18/11/2021: shredOS now working on some newer machines but GUI is not loading properly [fixed].
27/11/2021: shredOS GUI loading properly.

analysis: missing drivers for 10th and 11th gen CPU's and GPU's [fixed].

i7-10750H
i7-11800H

[fixed]
I've tried booting with USB; the 32-bit and 64-bit .img files both hang at recal with _.
I've tried using an external cd writer/reader with the 64-bit .iso, disc spins up but fails to boot to the black screen.

ACER Predator Helios 300 15.6" Gaming Laptop - Intelยฎ Coreโ„ข i7, RTX 3070, 1 TB SSD

Laptop SN look-up link for exact specifications:

https://snlookup.com/acer-predator-ph315-53-notebook-nh-qatek-001-p382646?sn=NHQATEK001120026843400#ffs-tabbed-17|tab6

example of the hanging (or crash) [fixed]:
142283314-6c147bed-fdcf-41ba-9554-b745ed7a1123

example of shredOS working with new drivers but GUI isn't loading properly [fixed]:
142498192-01b226e3-8092-4404-8f68-300e47700288

hit and miss success with USB keyboard use once booted in shred gui/cli

I can force boot a computer to boot into ShredOS stick.

BUT...

Some computers will loose the connection to keyboard (also, power seems to go out from keyboard as in light turns of on it).

I have an Asus server with 10 USB ports (4 front, 6 back) and none of the USB ports will work.

It happens at blank screen before landing in ShredOS cli/gui which it does.

Please let me know what kinds of details are required so you can help me make sure it works 100% of the time.

Stuck on "Booting `shredos`"

When I attempt to boot using a USB stick, the screen says it's booting but when it gets to 100% it just sits there and does nothing. I've tried different USB sticks and it hasn't changed anything. It seems to also only do it on this one laptop for some reason, as it works fine on others. Is there something specific that might cause it to not work on a single device? (It should also be a 64 bit device)

The last 'verifying' work is shown as 'blanking' in GUI

Bug report.

In GUI, shredos shows current work as 'writing', 'blanking', 'verifying' and 'syncing' each drive.
But on the last verify AFTER blanking, current status does not change and still shows 'blanking'.
I guess it actually does verify properly. I've tested it on virtual machine by making currupt bit on drive right after shredos blanked it and right before shredos verify it. shredos detected the currupt bit and told me there was an error. Stdout log also shows verifying work was started, finished. (and errors if they exist)
So the only problem is displaying status in GUI.

To reproduce this bug:

  1. Boot shredos (I've tested in UEFI boot)
  2. Set Method: prng
  3. Select drive and Start.
  4. It shows 'writing' status and intermittently 'syncing'.
  5. After around 33%, status changes to 'blanking' and intermittently 'syncing'.
  6. After around 66%, status should change to 'verifying'. But it never changes and still shows 'blanking'. This time, 'syncing' does not happen.
  7. You can check time lines on log screen when you quit shredos, that says it actually DOES verify.

Feature Request: show temperature

For NVMe:

the NVMe HWMON support to allow reporting the current NVMe drive temperature sensor(s) and min/max thresholds via this kernel infrastructure. This in turn allows user-space to simply query the data over sysfs without the need for any utilities, no root requirement, and should gracefully work with the various programs that report HWMON sensor readings to Linux desktop users.

source https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.5-NVMe-HWMON-Support

  • possible since 5.5 kernel (current ShredOS runs 5.6.3)
  • grep . /sys/class/nvme/nvme0/device/hwmon/hwmon[1-9]/{name,temp1_input}
    The number 1 to 9 probably depends on the mainboard/device and will list temperatures from other devices as well.
    Example on my box:
    cat /sys/class/nvme/nvme0/device/hwmon/hwmon3/temp1_input
    The value that it spits out (e.g. 31850] needs to be divided by 1000 for human readable format, i.e. 31.85 Celsius
  • or use nvme-cli: nvme smart-log /dev/nvme0 | grep -i '^temperature'

For SATA:

hot swap support

Is / Would it be possible to have hot swap support with auto wiping?

We want to build a system that we can pop drives into and have them automatically wipe and unmount when complete. we would remove them once there is no more drive activity.

ShredOS not detecting HDD Latitude 5400

I have some Dell Latitude 5400 laptops where shredOS is not detecting the internal hard drive. It detected the flash drive that contains ShredOS but not the internal drive. The laptops have a disk encryption utility we use which I thought might hide it from ShredOS but I removed it and there is no difference. I also deleted all partitions on the HDD and flashed the BIOS to the latest release. I've reviewed the BIOS settings and after trying to change a number of settings I still cannot get it to work. If you have any thoughts about this, it would be appreciated. Thanks.

Add keymap selection

Prior to nwipe starting and if no shredos.conf keymap entry found, run a keymap selection routine which displays in alphabetical order the common country keymaps and allows the user to select the keyboard they are using by number.

Later we can add an additional feature that allows you to save the keymap selection across reboots.

For instance,
1 azerty, 2 by, 3 cf, 4 cz, 5 dk, 6 es, 7 et, 8 fi, 9 gr, 10 hu101, 11 il, 12 is-latin1, 12 it ...... etc
Please select keymap by number >

Add temperature support for USB devices

Add temperature support for USB devices.

USB memory sticks don't provide temperature support, at least all the sticks I've come across don't. However a 2.5", 3" or SSD that are connected to the USB port with a USB to SATA adapter that supports 'ATA pass through' do provide temperature data.

USB temperature support to be scheduled for 0.33 release.

Update NWipe's Wiping Methods

So, the documentation on your site says NWipe uses the following wiping techniques to wipe HDDs. However, all of them are from the 1990s, before there was SSD & Flash Memory. So I think it's time to update and use more advanced and optimized shredding techniques.

NWipe uses the following methods:

  • Quick erase - Fills the device with zeros, one round only.
  • RCMP TSSIT OPS-II - Royal Candian Mounted Police Technical Security Standard, OPS-II
  • DoD Short - The American Department of Defense 5220.22-M short 3 pass wipe. 1,2,& 7.
  • DoD 5220.22M - The American Department of Defense 5220.22-M full 7 pass wipe. 1-7
  • Gutmann Wipe - Peter Gutmann's method. (Secure Deletion of Data from Magnetic and Solid-State Memory)
  • PRNG Stream - Fills the device with a stream from the PRNG.
  • Verify only - This method only reads the device and checks that it is all zero.
  • HMG IS5 enhanced - Secure Sanitisation of Protectively Marked Information or Sensitive Information

Unfortunately, most of these are outdated and one (the Gutmann method) is a flat out waste of time.

The RCMP level 3 wipe has been superseded by CSEC ITSG-06.

What Does CSEC ITSG-06 Do?
All data sanitization methods are similar, but what sets them apart from each other are the small details. For example, Write Zero is a method that only uses one pass of zeros. Gutmann overwrites the storage device with random characters, possibly up to dozens of times. However, the CSEC ITSG-06 data sanitization method is a little different in that it uses a combination of zeros and random characters, plus ones. It's usually implemented in the following way:

Pass 1: Writes a one or zero
Pass 2: Writes the complement of the previously written character (e.g. one if Pass 1 was zero)
Pass 3: Writes a random character and verifies the write

So, it's just a 3 wipe algorithm, but it's much more advanced. Here is what I believe is the white paper on it: IT Media Sanitization (ITSP.40.006)

Next is DoD 5220.22M ECE (7 wipes) and DoD 5220.22M aka DoD Short (3 wipes). These also have been superseded by standards from NIST.

The DoD 5220.22M was developed during a time when we were still using tape backup drives, optical memory, EEPROM, cathode ray tubes and the like. You can read an interesting history of it on White Canyon's DoD 5220.22-M Relevancy & The Evolution Of Wipe Standards. Apparently, the DoD is working on a 5200.48 standard, which they leaked the white paper on here: DoD Instruction 5200.48 "Controlled Unclassified Information CUI (PDF). However, it may be in alpha/beta stages and not fully ready for prime time. That's why they let NIST, a very capable agency (they picked AES aka Rijndael as the standard encryption scheme, as opposed to a host of others, and it has proven to be a very fast and versatile & fast encryption standard. Advanced Encryption Standard Process & Competition

NIST Special Publication 800-88 Revision 1 Guidelines for Media Sanitization: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf

These are called NIST 800-88 Clear and NIST 800-88 Purge. Both of these are described in the above document.

Finally, we have the Gutmann Wipe, which it's inventor, Peter Gutmann, has said it is outdated and unnecessary.

Most of the patterns in the Gutmann method were designed for older MFM/RLL encoded disks. Gutmann himself has noted that more modern drives no longer use these older encoding techniques, making parts of the method irrelevant. He said "In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques"

Source

I searched and searched for an updated version of HMG IS5 enhanced aka "HMG Infosec Standard 5", which is what the British (apparently still even currently) use to scrub sensitive data. Either that, or they are keeping their secure wipe methods very close to their chest, which is what intelligence agencies usually do anyway. There is apparently a HMG IS6 but it's still either in development or classified by the UK government. In light of that, IS5 should be fine, as I found many currenct documentats saying something along the lines of the "The British Agent will use Infosec Standard 5 to wipe the file"

So, the documentation on your site says NWipe uses the following wiping techniques to wipe HDDs. However, all of them are from the 1990s, before there was SSD & Flash Memory. So I think it's time to update and use more advanced and optimized shredding techniques.

I searched and searched for an updated version of HMG IS5 enhanced aka "HMG Infosec Standard 5", which is what the British (apparently still even currently) use to scrub sensitive data. Either that, or they are keeping their secure wipe methods very close to their chest, which is what intelligence agencies usually do anyway. There is apparently a HMG IS6, and I was approached by two gentlemen in suites and manhandled a little bit about finding this document. But, they eventually gave up and left. The documents read like they're only at the green or blue paper stage, and not full white paper stage.

Use of HMG Cryptography Policy left. The documents read like they're only at the green or blue paper stage, and not full white paper stage.

Use of HMG Cryptography Policy

Quick Erase would be good for SSD drives, as would PRNG Stream (although it doesn't specify the levels it does that at) they have a finite number of reads/writes they can do before they are completely destroyed. It's quit a lot, but if you're wiping your SSD HDD with the Gutmann method multiple times, running CCleaner with different level wipes, wiping free space, defragging often, you're more likely to encounter SSD failure (especially on how cheap or expensive the brand of the drive is).

As far as the two PSRNGs, it appears Mersenne Twister is not out of date, as much as there are better PSRNGs available, not to mention they were created in the 90s.

Letting Go Of The Mersenne Twister?

The author recommends instead, using CRNGs or Crypto Random Number Generators like [url=https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom]CryptGenRandom[/url] which was developed by Microsoft, but is now deprecated by Windows other CRNGs built into the OS, you couldn't use an API call from Windows to generate the random numbers in a bootable CD/USB environment.

CryptGenRandom - Wikipedia - Not to mention, the source code to wincrypt.h is available on the Wine Project's GitHub - WinCrypt.H. As well as one of MIcrosoft's alternatives, BCrypt.H, another CRNG. Bcrypt was developed using Blowfish, Blowfish is a cryptographic algorithm developed by the famous Bruce Schneier, who also went on to make it's successor, Twofish.

Blowfish
General
Designers Bruce Schneier
First published 1993
Successors Twofish
Cipher detail
Key sizes 32โ€“448 bits
Block sizes 64 bits
Structure Feistel network
Rounds 16
Best public cryptanalysis
Four rounds of Blowfish are susceptible to a second-order differential attack (Rijmen, 1997);[1] for a class of weak keys, 14 rounds of Blowfish can be distinguished from a pseudorandom permutation (Vaudenay, 1996).

So, Bcrypt might not be the best option, but thee are two alternative Crypto Random Number Generators w/publicly available source codes. Lets see what else we can find...

There's the AES CRT DRBG (Deterministic Random Bit Generator)
Then there's the [Linear_Feedback_Shift_Register](https://en.wikipedia.org/wiki/Linear-feedback shift register) made with NIST's test suites and has some actual studies posted on it. Linear-feedback shift register source code . We have NIST's SP 800-90A Rev. 1, which has a bit of a negative history because one of its PRNGs had a backdoor installed into it by the NSA. There was the Dual_EC_DRBG which was based on an elliptical curve model that had some sort of backdoor from the NSA or RSA. But, NIST patched it out and opened it back up for public comment. "NIST Released Special Publication (SP) 800-90A Revision 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators" (PDF). So, you would be safe to use this one now, although I don't know why they didn't rename it Revision 2 or change any of the code numbers for the project, so it was so tainted by then. So, for individuals who still remember that, it might be a problem.

Finally, there is a very promising one called ChaCha20 that is used by NetBSD, OpenBSD, FreeBSD, and even Google when they were using their SPDY protocol for faster web traffic.

ChaCha family of ciphers, which aim to increase the diffusion per round while achieving the same or slightly better performance. The Aumasson et al. paper also attacks ChaCha, achieving one round fewer: for 256 bits ChaCha6 with complexity 2139 and ChaCha7 with complexity 2248. 128 bits ChaCha6 within 2107, but claims that the attack fails to break 128 bits ChaCha7. ChaCha's initial state is similar to the initial state of Salsa20, however there are some differences. ChaCha's initial state includes a 128-bit constant, a 256-bit key, a 32-bit counter, and a 96-bit nonce, arranged as a 4ร—4 matrix of 32-bit words. ChaCha also re-arranges some of the words in the initial state.

ChaCha is based off another algorithm called Salsa20, which uses addโ€“rotateโ€“XOR ARX to generate PSRNs. The main thing is that it's fast, which is why Google choose it to help speed up web browsing.

Both ciphers are built on a pseudorandom function based on add-rotate-XOR (ARX) operations โ€” 32-bit addition, bitwise addition (XOR) and rotation operations. The core function maps a 256-bit key, a 64-bit nonce, and a 64-bit counter to a 512-bit block of the key stream (a Salsa version with a 128-bit key also exists). This gives Salsa20 and ChaCha the unusual advantage that the user can efficiently seek to any position in the key stream in constant time. Salsa20 offers speeds of around 4โ€“14 cycles per byte in software on modern x86 processors, and reasonable hardware performance.

And since there are literally hundreds of thousands of PRNGs out there, I'm going to stop there and take a look at ISAAC. Which looks like your standard run of the mill RNGs. Although, it is also a bit old and uses RC4, which has shown to be insecure. But that's really only if you were going to use it as algorithm to connect to a VPN or something, not really pretty much instantly generating random numbers - although security researchers have even abandoned it as a RNG and switched to other ones.

RC4-based random number generators

Several attacks on RC4 are able to distinguish its output from a random sequence.
Source

Ain't that a bitch?

So, I feel I've posted enough suggestions in this thread. I didn't want to make a new thread for a suggestable replacement for each algorithm (unless you really want me to) because I felt it would fill up the Issues forum with TONs of suggestions.

Also, to the author(s) of this project, I think it's good and a good idea since DBAN stopped development in 2015 and has become commercial software, we need a HDD wiping tool that's good, free and open source. But, as I read through the documentation I saw the same algorithms for wiping that I've seen everywhere in the last ~15 years. So, I thought there has GOT to be some newer secure wiping algorithms out there that are drop in replacements for these old ones. And there are several good ones! NIST 800-88 Clear and NIST 800-88 Purge are much more secure than the current DoD 5220.22 one, and it works on SSDs, which DoD 5220.22 was never intended to, as it was invented before the idea of SSD and Flash memory was just a teardrop in it's father's eye. CSEC ITSG-06 also sounds very promising. I also wanted to mention you did an excellent job of porting this project to multiple operating systems and architectures.

The thing is you don't need a dozen different secure wiping algorithms for the software to work good. You only need one to three good ones. People can pick for themselves. As far as RNGs, I think I would use ChaCha20 for one. Btw, I forgot to link the source code for it, which is here:

Simple C99 ChaCha20 Implementation

Then, I might give the user a second option to use a [Cryptographically-secure pseudorandom number generator](Cryptographically-secure pseudorandom number generator), of which there are many, which will slow down the overall process, but you know you'll be getting more secure entropy at the parts being wiped. Since I believe this project is being written in Python, the Python library has it's on CSRNG called Secrets although it might not be ideal for what you're using. If I'm correct that you're writing this in Python, I can dig around and try to find Python implementations of those new cryptographic algorithms to use.

And just searching Google, I found a TON of people making their own Crypto RNGs just using the calls in Python's OS.

Anyway, that was a long write up for me, but if you want me to break them into individual posts for each algorithm I can do so if you are actually interested in trying them.

I hope that might give you a few ideas and it wasn't too boring or tedious to read.
Thanks and keep up the good work!
pogue

Monitor says "no signal detected" after shredOS has been running for awhile [SOLVED]

I started shredOS with default settings on a hard drive last night before I went to sleep, and when I woke up in the morning and turned my monitor on I had no signal. My HDD light was blinking in a fashion that made me think shredOS could've still been working but I have no way to know. So I just restarted my computer because there seemed to be nothing else I could do. This has happened twice now. If it matters, I've got an i9-9900K and an RTX 2080 Ti.

Is there any way I can circumvent this problem so I can wipe this drive and see confirmation of shredOS' completion?

shredos doesn't work with PS/2 to USB adapter

Maybe related to #1. I don't have an USB keyboard, but a PS/2 keyboard and a PS/2-to-USB adapter. While this adapter works e.g. with DBAN and in the BIOS, it doesn't work with shredos.

lsusb output on deskop Linux:

ID 0a81:0205 Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter

dmesg output on deskop Linux:

[  358.655665] usb 1-1.3: new low-speed USB device number 5 using ehci-pci
[  358.772943] usb 1-1.3: New USB device found, idVendor=0a81, idProduct=0205, bcdDevice= 0.10
[  358.772946] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  358.772948] usb 1-1.3: Product: PS2 to USB Converter
[  358.772950] usb 1-1.3: Manufacturer: CHESEN
[  358.780063] input: CHESEN PS2 to USB Converter as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:0A81:0205.0003/input/input6
[  358.844016] hid-generic 0003:0A81:0205.0003: input,hidraw2: USB HID v1.10 Keyboard [CHESEN PS2 to USB Converter] on usb-0000:00:1a.0-1.3/input0
[  358.851711] input: CHESEN PS2 to USB Converter Mouse as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.1/0003:0A81:0205.0004/input/input7
[  358.911868] input: CHESEN PS2 to USB Converter System Control as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.1/0003:0A81:0205.0004/input/input8
[  358.912050] input: CHESEN PS2 to USB Converter Consumer Control as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.1/0003:0A81:0205.0004/input/input9
[  358.912322] hid-generic 0003:0A81:0205.0004: input,hidraw3: USB HID v1.10 Mouse [CHESEN PS2 to USB Converter] on usb-0000:00:1a.0-1.3/input1

When UEFI CSM disabled, screen does not appear but it boots and shreds.

With CSM(Compatibility Support Module), ShredOS works with both CSM UEFI and CSM BIOS. I can see large screen resolution with UEFI and small screen resolution with BIOS.

When I disable CSM in mother board firmware(del key on boot), my PC boots until POST, and string recalbox appears on screen, and it freezes. BUT I think ShredOS boots and works, because HDD LED blinks, and stops blinking when I hit Ctrl+c. I can even turn off my PC with Alt+F2, poweroff command.

I did not enable fast boot. Just disabled CSM.

Is this a problem of my own mother board, or ShredOS?

Test environment:
CPU Intel Celeron G5905 (Cometlake S)
M/B ASUS PRIME H410M-A
RAM 4GiB*1
with following grub.cfg edit:
grub.cfg.txt

Kernel Panic on the latest version

Looks like there is a kernel panic when booting from a usb image on v2020.05.018_x86-64_0.32.014. It boots fine on v2020.05.017_x86-64_0.32.003.

Temperature not displayed for Maxtor Model 6Y080P0, Seagate ST3320620A, ST340014A - drivetemp has not populated hwmon.

Also see:
martijnvanbrummelen/nwipe#384 (comment)
https://github.com/groeck/drivetemp/issues/1#issuecomment-1000128093

The temperature is not displayed for the Maxtor Model 6Y080P0 - drivetemp has not populated hwmon, drivetemp is working for a Seagate drive on the same computer. So drivetemp is working ok, just not recognising the Maxtor drive.

For reference here's the smartctl -x output for the Maxtor 6Y080P0, note the attribute ID 194 Temperature_Celsius data.

smartctl 7.2 2020-12-30 r5155 [i686-linux-5.13.19] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Maxtor DiamondMax Plus 9
Device Model:     Maxtor 6Y080P0
Serial Number:    Y2DG23HE
Firmware Version: YAR41BW0
User Capacity:    81,964,302,336 bytes [81.9 GB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA/ATAPI-7 T13/1532D revision 0
Local Time is:    Thu Jan  1 20:08:51 2004 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM level is:     254 (maximum performance), recommended: 192
APM feature is:   Disabled
Rd look-ahead is: Enabled
Write cache is:   Enabled
DSN feature is:   Unavailable
ATA Security is:  Disabled, NOT FROZEN [SEC1]
Wt Cache Reorder: Unavailable

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82)	Offline data collection activity
					was completed without error.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		(  241) seconds.
Offline data collection
capabilities: 			 (0x5b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					No General Purpose Logging support.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 (  37) minutes.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  3 Spin_Up_Time            POS--K   224   222   063    -    11955
  4 Start_Stop_Count        -O--CK   253   253   000    -    949
  5 Reallocated_Sector_Ct   PO--CK   253   253   063    -    0
  6 Read_Channel_Margin     P-----   253   253   100    -    0
  7 Seek_Error_Rate         -O-R--   253   252   000    -    0
  8 Seek_Time_Performance   POS--K   253   243   187    -    37052
  9 Power_On_Minutes        -O--CK   246   246   000    -    277h+16m
 10 Spin_Retry_Count        PO-R-K   253   252   157    -    0
 11 Calibration_Retry_Count PO-R-K   253   252   223    -    0
 12 Power_Cycle_Count       -O--CK   252   252   000    -    615
192 Power-Off_Retract_Count -O--CK   253   253   000    -    0
193 Load_Cycle_Count        -O--CK   253   253   000    -    0
194 Temperature_Celsius     -O--CK   253   253   000    -    31
195 Hardware_ECC_Recovered  -O-R--   253   252   000    -    2390
196 Reallocated_Event_Count ---R--   253   253   000    -    0
197 Current_Pending_Sector  ---R--   253   253   000    -    0
198 Offline_Uncorrectable   ---R--   253   253   000    -    0
199 UDMA_CRC_Error_Count    ---R--   199   199   000    -    0
200 Multi_Zone_Error_Rate   -O-R--   253   252   000    -    0
201 Soft_Read_Error_Rate    -O-R--   253   252   000    -    0
202 Data_Address_Mark_Errs  -O-R--   253   252   000    -    0
203 Run_Out_Cancel          PO-R--   253   252   180    -    0
204 Soft_ECC_Correction     -O-R--   253   252   000    -    0
205 Thermal_Asperity_Rate   -O-R--   253   252   000    -    0
207 Spin_High_Current       -O-R-K   253   252   000    -    0
208 Spin_Buzz               -O-R-K   253   252   000    -    0
209 Offline_Seek_Performnce --S--K   189   188   000    -    0
 99 Unknown_Attribute       --S---   253   253   000    -    0
100 Unknown_Attribute       --S---   253   253   000    -    0
101 Unknown_Attribute       --S---   253   253   000    -    0
                            ||||||_ K auto-keep
                            |||||__ C event count
                            ||||___ R error rate
                            |||____ S speed/performance
                            ||_____ O updated online
                            |______ P prefailure warning

Read SMART Log Directory failed: scsi error badly formed scsi parameters

General Purpose Log Directory not supported

SMART Extended Comprehensive Error Log (GP Log 0x03) not supported

SMART Error Log Version: 1
No Errors Logged

SMART Extended Self-test Log (GP Log 0x07) not supported

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

SCT Commands not supported

Device Statistics (GP/SMART Log 0x04) not supported

Pending Defects log (GP Log 0x0c) not supported

SATA Phy Event Counters (GP Log 0x11) not supported

** END **

Secure Boot and keeping logs

Hello,

Really love this project, exactly what one expects when you go looking for a tool like this. I've been playing around with it a bit and hit two bumps at the moments:

  • The USB key does not boot when Secure Boot is enabled. I think there are already systems out there which don't have Legacy Mode anymore and/or only support Secure Boot. I'm aware that Secure Boot is... complicated. But I was wondering if this is a limitation of buildroot which you are using and if there are any plans to support this in this future?
  • Would it be possible to keep the logs permanently on the USB key? I'm aware that you provide instructions but I think it would be a good addition to have this by default somehow on the image you provide (or a more simple way to get the files off).

Keep safe and thanks for your time!

Icon & autorun.inf & readme

Hi,

I noticed that ShredOS USB has no icon and basic description when plug in windows.

Because it could be unpleasant surprise if IT made "--autonuke --nowait" (btw works great!) and then lost or forgot the USB.
Some "lucky" finder could connect to his PC, found no info in USB,
forgot there and rebooted, and have(known or unknown) USB in boot order

Don't know if this project has some official logo, so I made 5 versions by quickly combining icons from https://remixicon.com/
( I'm not a designer )
5_ideas
Added autorun.inf -> icon + drive name changes to "ShredOS - DANGER"
Also added minimal description

shred_OS_icon.zip

example

USB_root

Keyboard inoperable on Atom Pineview platform

Issue: Boot into shredOS works fine, but USB support seems partially functional. I can see one USB device (the internal flash drive), but nothing else USB seems to work. I end up at the nwipe screen listing drives, but no action is possible. Pressing a key will flash the capslock LED at me on keypress and beep.

Plugging in a second USB keyboard does nothing - I assume it is not enumerating?

This is an old QNAP ts-439 pro ii NAS. Not a spritely critter, but it suffices for wiping drives.

Here's a lspci from partedmagic.

lspci.txt
lspci-v.txt

CPU info: https://ark.intel.com/content/www/us/en/ark/products/49489/intel-atom-processor-d425-512k-cache-1-80-ghz.html

nwipe fails to build on Arch Linux

I am running into a strange issue where make nwipe (likely autogen.sh in nwipe) manages to symlink output/build/nwipe-v0.30.001/{compile,config.guess,config.sub,install-sh,missing,depcomp} to the respective files in /usr/share/automake-1.16/, which belong to a system package, are owned by root, and not writable by my normal user. Any clues what could be causing this? No other package is exhibiting the same issue.

[repentinus@Mandalore shredos.x86_64]$ make nwipe
nwipe-v0.30.001.tar.gz: OK (sha1: c784e1413543dd290296071db1a36e86b0d3d0f0)
>>> nwipe v0.30.001 Extracting
gzip -d -c /home/repentinus/Software/shredos.x86_64/dl/nwipe/nwipe-v0.30.001.tar.gz | /home/repentinus/Software/shredos.x86_64/output/host/bin/tar --strip-components=1 -C /home/repentinus/Software/shredos.x86_64/output/build/nwipe-v0.30.001   -xf -
>>> nwipe v0.30.001 Patching
(cd /home/repentinus/Software/shredos.x86_64/output/build/nwipe-v0.30.001 && cp ../../../package/nwipe/002-nwipe-banner-patch.sh /home/repentinus/Software/shredos.x86_64/output/build/nwipe-v0.30.001 && ./002-nwipe-banner-patch.sh  && ./autogen.sh);
configure.ac:12: installing './compile'
configure.ac:65: installing './config.guess'
configure.ac:65: installing './config.sub'
configure.ac:6: installing './install-sh'
configure.ac:6: installing './missing'
src/Makefile.am: installing './depcomp'
configure.ac:7: warning: AC_OUTPUT should be used without arguments.
configure.ac:7: You should run autoupdate.
>>> nwipe v0.30.001 Updating config.sub and config.guess
for file in config.guess config.sub; do for i in $(find /home/repentinus/Software/shredos.x86_64/output/build/nwipe-v0.30.001 -name $file); do cp support/gnuconfig/$file $i; done; done
cp: cannot create regular file '/home/repentinus/Software/shredos.x86_64/output/build/nwipe-v0.30.001/config.guess': Permission denied
cp: cannot create regular file '/home/repentinus/Software/shredos.x86_64/output/build/nwipe-v0.30.001/config.sub': Permission denied
make: *** [package/pkg-generic.mk:233: /home/repentinus/Software/shredos.x86_64/output/build/nwipe-v0.30.001/.stamp_patched] Error 1

I am seeing this on commit 87d0a4e.

Little mistake at the ShredOS img flash guide for MAC users

At
" Obtaining and writing shredos to a USB flash drive, the easy way ! "
under the section "Linux (and MAC) users"

there is written something like
(where sdx is the device name of your USB drive, this can be obtained from the results of sudo fdisk -l)

I don't know if that's is happening after the MacOS Big Sur update or something but the command sudo fdisk -l doesn't work on MacOS. It just gives me this error "fdisk: illegal option - l"

Please add to the installation guide that the fdisk command should be used on Linux and for MAC users should use the diskutil list command in order to display all storage devices connected to your machine.

Here is the screenshot, what happens is if I type the fdisk command from the readme file and what happens if you type the diskutil command I mentioned before, in case you don't own any device that runs MacOS and you might think that this command formats the hard drive

Bildschirmfoto 2020-12-08 um 14 38 20

Sorry for my bad English and I hope to see some correction made in the readme file : )

Include arch in release filename

Hello,

At present, both the x86_64 and the i686 versions have the same release download filename โ€“ shredos-20210106.img, at the time of reporting. This is problematic for easily identifying files after download and easy downloading by utilities such as wget.

For users that want/need both versions, running, for example, wget with the URL for one version would overwrite an existing copy of the other version. The only way of subsequently checking what's already downloaded would be by comparing checksums of local files with the release notes.

I suggest something like shredos-<release-date>-i686.img and shredos-<release-date>-x86_64.img.

Thanks for considering.

How to create bootable ISO from .IMG?

Hi! I'm sorry for my question, but is there any option make from your .IMG bootable ISO for using in VirtualBox? Because latest IMG cannot boot.

Thanks for reply!

Question: SAS Drive Support?

Hi all!

Question:
Does the current version of shredOS support SAS drives? Thank you!

Background (no need to read)
I have to wipe the disks of multiple IBM System X3650 M4 (https://lenovopress.com/tips1102-system-x3650-m4-bd) which are equipped with SAS/SATA-Drives. Unfortunatly, I cannot access the servers myself, as they are in a datacenter where I do not have access to. So I have to send multiple USB sticks to a field engineer who will insert them for me.

I simply want to make sure I can expect everything is working, so I do not have to exchange the USB sticks over and over again.

Thank you

Error "The futex facility returned an unexpected error code". 32bit and only when a wipe is aborted.

Note. As far as I'm aware this issue isn't in any released code, it's only relevant to the latest .img/.iso build for 32 bit which has not yet been released. I'm only raising this issue here, just in case somebody else builds for 32bit and comes across this issue. It seems to be a fairly minor issue in that it doesn't affect the main operation of shedos on 32bit systems.

This is an interesting puzzle. When building shredos for 32bit systems I get the error "The futex facility returned an unexpected error code". 64bit shredos doesn't exhibit this error. I only get this error if I abort an in-progress wipe or verify operation with a CNTRL-C. The nwipe log, summary table and error log fail to get displayed in the terminal.

If I let the wipe operation complete then exit by pressing a key on the keyboard then the nwipe log, error & summary tables are displayed correctly and there is no futex error.

If I abort a nwipe before a wipe has been started then the nwipe log is displayed correctly and without any futex error.

This doesn't happen running on a 32bit Debian 11 running in virtual box. Everything works as expected.

I've been working on this for a few days and although it doesn't affect an actual wipe it's a behaviour that I don' expect. So although it's a fairly minor issue and probably affects a very small minority of users, I would like to get to the bottom of this before I release the 32bit version of shredos.

This also gets the prize for annoying error messages from the pthread library "....unexpected error code". What? Not an unknown error code, just unexpected?. That seems to imply it's a known error code, so why not give us a clue and tell us what the error code is. ;-)

Luckily I love dealing with difficult bugs.

Add auto hotplug ethernet support with lftp

Add auto hotplug ethernet support with lftp so nwipe logs can be easily transferred to a chrooted ftp server on the local network.

Code complete, in testing. To be released shortly.

4 minute boot on Sony VAIO Model PCG-3B1M while other laptops boot quickly.

Initially I thought ShredOS 64bit wouldn't boot on this device, while the exact same ShredOS on the exact same flash drive boots within six seconds on my I7 laptop. I can see from the activity light on the flash drive its reading the ShredOS image file for about 8 seconds then all activity stops, nothing. It just says ShredOS Booting. However wait for just under 4 minutes and nwipe appears. dmesg shows nothing that jumps out at me as being the cause. Win7 boots fine.

I'm not sure if it's hardware or software related at this stage. Thought I'd mention it here just in case anybody else has a ShredOS that takes several minutes to boot when it should be seconds.

Shutdown / --autopoweroff is broken

my grub.cfg entry:

menuentry "ShredOS-ZERO-NoUSB-AutoOFF-AllDrives" {
linux /boot/shredos console=tty3 loglevel=3 loadkeys=de nwipe_options="--method=zero --verify=off --noblank --nousb --autonuke --autopoweroff"
}

After wipping my disk i get a error/message

"shutdown: -H and -P flags can only be used along with -h flag".
...
...
...

"Paused, press any key to restart nwipe."

Any Ideas?

Can't see USB devices and SATA Devices

Computer Specifications
Dell Optiplex 3040
BIOS Version: 1.18.1

I have been messing with the BIOS for about 3 days now and I can't get Shred OS to have storage devices connected to the SATA ports inside the computer and the external HDDs I have connected through USB show up at the same time. I have one HDD connected via SATA and 3 via USB (There is only 2 SATA connections), and the only way I can see the USB is if I change the SATA configuration to "Disabled", but then it takes away the HDD I have connected via SATA. The only way I have found to see the SATA drive is to turn the SATA Configuration back to AHCI. There are only 2 options in that menu, AHCI or Disabled. Is there any way to work around this or am I stuck having to switch between the two?

Drivers for HW cards

Is it possible to add drivers that support HW cards/adapters such as Dell Perc 310 so I can erase all 24 drives in my server case? Is there an easy way I could add to the USB boot stick?

Dark Theme to help save monitors from burn in

Would be nice to change the current Blue/White theme to Black background with Light Gray text theme to help save monitors from burn in. The blue color if I remember correctly is the biggest contributor to burn in after white.

Shredos USB doesn't appear in Win10 file explorer (requires manual assign using diskpart)

I'm on windows 10 home, updated to the latest stable release.

after making bootable USB, windows doesn't automatically assign the volume a drive letter which prevents it from appearing in file explorer. unplugging and plugging back in the USB doesn't prompt windows to assign a letter either. you have to manually assign the volume a letter using diskpart.

example using diskpart in CMD (administrator):

diskpart
list disk
select disk 2 (disk 2 was the USB with shredOS on for me)
list volume
select volume 4
assign (auto assigns a drive letter to volume 4)

Am I able to pick which drives to wipe?

Am I able to select which disks to erase or is my only option to nuke everything?

There are no videos of this anywhere online (like DBAN) so I don't know what I'm going to see. Would appreciate any reassurance; screenshots? I do not want to wipe everything, just certain drives.

Thanks.

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

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"
} 
  1. Boot shredos. (I've tested in UEFI boot)
  2. Set method to prng.
  3. Set verify to all passes.
  4. Select drive and Start.
  5. 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.

ShredOS fails to wake from suspend

rtcwake -m mem -s 5 does indeed put the device to sleep but upon waking reboots ShredOS rather than the expected behaviour of restoring the running ShredOS from RAM.

shred OS does not boot on old Notebook

Hi,

I made a bootable USB-Stick with ShredOS. It worked fine on newer Laptops, but on an older one I do not get past a black screen with just one line: "ShredOS - booting".

The computer in question is a Fujitsu Siemens AMILO Pro.

I can rule out the stick as it worked on other hardware. I can give more information if needed.

Request for smartctl -i info

If anybody is seeing UNK in the bus type field as opposed to USB or ATA in the GUI, can you post the output from either smartctl -i /dev/... Or nwipe -v

Also if you have an IDE or SCSI drive, can you also post the smartctl -i /dev/... Or nwipe -v output. And tell me what's in the bus type field in the GUI.

Thanks

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.