Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Hmmm. I've never done work like this, i.e. programming kernel modules. But I guess, this is not the appropriate place to get it inserted into the kernel.
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.
Originally Posted by JZL240I-U
Perhaps asking in the kernel mailing list whether the kernel chiefs are interested?
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.
Click here to see the post LQ members have rated as the most helpful post in this thread.
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
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.
Distribution: openSuSE 42.1_64+Tumbleweed-KDE, Mint 17.3
Originally Posted by BruceFerjulian
dd if=/dev/zero of=/dev/xxxx conv=swab
...Read zeros ( /dev/zero ), swap the zeros to ones, then write out to ( /dev/xxx_whatever ).
The man page says
swab swap every pair of input bytes
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.
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.
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.
/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.
"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.