Haha, yes I agree; despite my low post-count here I've been knocking around long enough to know the protocols (even if I don't follow all of them!). Just an opinion, not a call to arms.

Weeelll, I sorta jumped a bit past that stage (I can't stand mailing lists, the forum paradigm should have buried the damn archaic things by now) but that was a short conversation.

I already figured this must have been considered before at some point, and I'm satisfied with the reasons given. I mainly just updated the thread in case anyone else was looking for a /dev/one for their own reasons.

Understood. Thanks for coming back and clearing up the debris .

Read this thread months ago and since found something that works easier for me.

dd if=/dev/zero of=/dev/xxxx conv=swab

The key for me was the ( convert = swap bytes ) in the ( dd ) command. Read zeros ( /dev/zero ), swap the zeros to ones, then write out to ( /dev/xxx_whatever ).

I'm not sure why anyone would go to the trouble of writing more than one pass of /dev/urandom. All you're doing is wasting computer and disk-write cycles to stop the NSA from reading your drive and if you're really keeping information on your drive that the NSA want then you'll be too busy half-drowning in an orange jumpsuit every day for the rest of your life to care whether they got it or not.
Cyber criminals and rival businesses that can afford an electron microscope probably couldn't care less about your data.
The Gutmann paper was written around seven years ago about a possible method of recovering data from the hard drives at the time using an electron microscope and some luck. Drives have become massively more dense since then and nobody has ever recovered data from a wiped drive in practice that I have read about.

The man page says
In my understanding that means bytes A and B get to be bytes B and A. What I was aiming at would be inverting at the bit level, i.e. byte A and B coming from /dev/zero having the values of "00000000" and "00000000" get to be "11111111" and "11111111". That is not what "swab" is about as far as I can see.

Thanks to all for great support.
I learnet today "/dev/zero" and "/dev/one"

thank you

Due to popular demand, a practical use of /dev/one:

In order to erase a USB memory key (thumb drive, memory stick), you need to write all ones, not zeros. A /dev/one would come in handy for erasing memory sticks before discarding or selling them. With Kingston Technologies' terabyte thumb drive, erasing a large NAND flash device would be tedious using data manipulation with cpu cycles.

https://en.wikipedia.org/wiki/Flash_memory "Block Erasure"
https://en.wikipedia.org/wiki/Field_electron_emission

The memory chip is programmed using tunnel injection (a field electron emission effect) specifically a quantum process called Fowler–Nordheim tunneling. The process used for erasing is called tunnel release.

Why would /dev/urandom not work?

/dev/urandom and /dev/random will write bytes of ones and zeros. That will not trigger a "block erasure". You have no control over the location that the front-end controller will place those bytes. There may be blocks that are not even touched, or part of blocks. Only writing 0xFF onto a block will trigger the erasure of the entire block. Forensic analysis of the flash chip can read the entire block of parts that received a random-pattern byte. Refer to https://en.wikipedia.org/wiki/File:USB_flash_drive.JPG, it is the controller that is the interface between the USB hardware and the flash chip. Please refer to http://pdf.datasheetcatalog.com/data.../389202_DS.pdf, Page 9 (you may find other datasheets for the same product, look for the "Product Information" page). Erasure is executed on a block basis. You cannot execute a bit-by-bit erasure. Random data reads and writes could be anywhere, the controller chip keeps track of that. The chip has a 2-cycle block erase command: 0x60 - erase setup, then 0xD0 - erase confirm. With lots of writes of random bytes, most likely the bytes are written to cache registers while the data registers are being programmed into memory cells for speed.

Disclaimer: It has been twenty years since I've had to read a data sheet for timing diagrams. Forensic analysis starts by removing the flash chip and setting it up to apply pulses to the control pins and get the output pins on a digital storage scope (controlled and data stored on a VXI system). Then it's just a matter of scanning the pages for data.

So how is writing ones better than random? Why does ones tell the controller to write to all blocks and random doesn't?

"USB sticks, CompactFlash cards and other removable flash media are not MTD devices. They are block devices. They do contain flash chip inside, but they also contain some translation layer above which emulates block device. This translation layer is implemented in hardware. So for outside world these devices look exactly as hard drives, not like MTD devices.
...
"Also note, these devices are "black boxes". The way they implement this flash-to-block device translation layer is not usually published. And in many cases the algorithms used at this layer are far from brilliant. For example, many USB sticks and other cards lose data in case of unclean reboots/power cuts."

I was taught to read at least 3 times before thinking about using the data therein (timing diagrams, etc.). This site has lots of information about "Memory Technology Devices" and why they are not block devices. Recall the wiki image of the innards of a USB stick. Two chips, one is the flash device, which the datasheet describes in excruciating detail, the other is the mysterious controller device that sits between the USB interface and the flash chip, or MTD. It is the inner workings of the controller chip which makes the MTD appear like a block device to the OS. This FAQ explains the three operations that MTDs understand: read from eraseblock, write to eraseblock, and erase eraseblock. You invoke the "erase block" operation by sending 0xFF to the device (sixteen bits). Writing anything else gets mysteriously translated by the controller chip into MTD blocks in a way that simulates a block device.

http://www.linux-mtd.infradead.org/faq/general.html

Thank you, hpfeil, for your thorough explanation(s) and the enlightening statements concerning flash .

Most application that attempt such things will create a designated buffer with the values desired...

Then just write that buffer out as many times as it takes.

This is faster than actually READING buffers.... which does nothing but make your overhead larger.

/dev/zero gets used a good bit - creating swap files (not partitions), virtual disks, empty data files (preallocated files with nothing in it - makes for faster updates).

A simple C program to fill with any character passed in as hex:

Adjust the buffer size as needed (check cpuinfo for your cache size).

Example:

1 members found this post helpful.