Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 13 Dec 2017, 07:35
All times are UTC - 4
 Forum index » Off-Topic Area » Security
Plugging an infected USB/HD into a Puppy
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 3 [35 Posts]   Goto page: Previous 1, 2, 3 Next
Author Message
amigo

Joined: 02 Apr 2007
Posts: 2632

PostPosted: Sat 18 Nov 2017, 13:54    Post subject:  

Nothing is getting across by itself. Mounting the drive also does nothing except make it available. mount succeeds because the drive is there. It knows it is there because udev has gotten a message from the kernel which has recognized a 'connect' event. udev will normally create the device file and can do other things. You can create custom udev rules to control what happens when something gets plugged in or unplugged.

These infected devices are mainly aimed at windows OS -which nicely has a system which can automatically do arbitrary stuff -it's called the autorun.inf. These are found on lots of CD's, so that when you stick the CD in the MS machine, the OS runs whatever commands are found in the autorun.info file -lovely little feature there!
I think the autorun.info files also work on other removable media like USB, etc. But only under windows AFAIK.

I used to use the 'supermount' kernel patch, which would automaount CD's on insertion, and it included some support for autorun -I think. But that was long ago and far away...

Otherwise, that beasty can't hurt you and your machine/OS -unless it can entice you to click on anything or execute anything there. It coud even have you open a pdf on the drive which exploits a bug in a reader to do evil. But, blasting it with dd and repartitioning it poses no risk.
Back to top
View user's profile Send private message 
SFR


Joined: 26 Oct 2011
Posts: 1645

PostPosted: Sat 18 Nov 2017, 15:28    Post subject:  

amigo wrote:
the autorun.inf

Back then when I was on Windows, I used to use my custom autorun.inf with the following content:
Code:
[AutoRun]
label=SFR
icon=.\SFR.ico

to display my own label and icon in File Explorer.

Sadly, inserting a USB stick with it to a virus infested PCs resulted in overwriting it with virus' own autorun.inf, so I set hidden, read-only and system attributes to that file and soon enough it turned out that this actually prevents most of them (viruses) from overwriting it and therefore spreading via my USB sticks.
IIRC there was only one case when a virus was smart enough to overwrite it anyway.

Ironically, antivirus programs were reporting that custom autorun.inf (most likely the mere exsitence of it) as a potential threat...

Greetings!

_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 11260
Location: Gatineau (Qc), Canada

PostPosted: Sat 18 Nov 2017, 17:57    Post subject:  

Thanks, guys.
_________________
musher0
~~~~~~~~~~
"Logical entities must not be multiplied beyond necessity." | |
« Il ne faut pas multiplier les entités logiques sans nécessité. » (Ockham)
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3103
Location: The Blue Marble

PostPosted: Sun 19 Nov 2017, 00:42    Post subject:  

Excellent answers from amigo and SFR.

I will just add a little.

Quote:
Is it ok to boot up a Puppy, with that infected USB/HD plugged in too

Not OK.

DO THIS: (when computer is off) Boot Puppy, **then** insert the drive..
DON'T DO THIS: (when computer is off) plug the USB, and boot Puppy.

Order makes a GREAT difference.

Quote:
and use terminal to DD-wipe it, then Gparted to format it?

That would work.

Quote:
Or are you risking infection, in some way, leaping across to the Puppy you're in?
If you want to speak theoretically, the answer is yes it can. If you want to speak realistically / practically, the answer is not it is NOT possible (if you do it the safe way above).

Quote:
Puppy obviously knows the infected drive is there, has in someway communicated with it, otherwise how could Puppy create an desktop icon for us to click on to "officially" mount it?
The communication is on a side-channel. It does not bring any "infected" information to the system.

Quote:
So when Puppy communicates, what is exchanged?

Do you really want to know? Smile At "Puppy" level, it's the information you see - the "port" it's connected to (sda, sdb, sdc), the volume type, the volume name, size of the disk, etc.

Quote:
At what level?
You really want to know?

Quote:
Can malware/infections jump across at this level of communication between the plugged-in-infected-drive-that-is-not-yet-mounted and the puppy OS???

As above. Theoritically, yes. Practically, no.

================

Now the paranoid bit. When does the game changes? When does theoretically possible becomes a practical attack?

a) when somebody founds a kernel exploit by using an oddly/invalidly formatted partition table and filesystem headers.
b) When USB drive firmware can be re-programmed so it is no longer a flash drive, but acts as something else. Example: https://www.jaycar.com.au/usb-keystroke-pranker/p/GE4300

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1355

PostPosted: Sun 19 Nov 2017, 07:15    Post subject:  

jamesbond wrote:
Excellent answers from amigo and SFR.

I will just add a little.

Quote:
Is it ok to boot up a Puppy, with that infected USB/HD plugged in too

Not OK.

DO THIS: (when computer is off) Boot Puppy, **then** insert the drive..
DON'T DO THIS: (when computer is off) plug the USB, and boot Puppy.

Order makes a GREAT difference.



Thanks, Jamesbond, for replying.

Could you point me, or give me hints/tips, what I could read about to learn more about this difference in what you wrote for "DO THIS" and "DON'T DO THIS".

I honestly don't understand why if both an infected drive and a puppy OS, both connected, and the bios boots up, and you explicitly choose the "Puppy OS" to boot, why it is important to "DON'T DO THIS"?

I mean, why is that any different than booting only the Puppy OS first (with the infected drive NOT plugged in), and then the infected drive plugged in??

What is happening during the boot process that is so worrisome that both drives cannot be connected where the user is explicitly choosing (through the bios boot choices) to boot the Puppy OS only? Is it something to do with how a Puppy OS starts? Or how all Linux OSes start...are they incredibly vulnerable during the boot process or something?? Is there some exposed exchange of info during boot that is sacred yet--again---vulnerable?? That can make the Puppy OS more susceptible?? Is there hard data to back this up? Industry papers? Cited research/tests?? Links????

I am just trying to learn here....reason being is that across the web, even across home users and across many business users, drives and servers that have been known (or thought) to be infected are never disconnected. They are isolated, yes, from the network. But infected drives are 99.999% times rarely ever turned off. All technicians I know in the industry cannot afford to power them completely off, as things go (and have gone) terribly wrong when they do. It is a $$$$ thing. Thus, these possibly infected drives/servers/etc are cleaned and reset, while they are plugged in and using another OS that is booted up along with them on the same controlling bios board. Heck, many of the servers you cannot even physically reach location-wise, so fixing them has to be done the way I am describing for cost purposes alone as mentioned above.

So I am trying to understand what is so worrisome here about the booting process and/or such. Is it something you are intimate with knowledge-wise, or is this something that is an opinion and is thought to be just "good-practice"?


Thanks very much for any insight!
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 11260
Location: Gatineau (Qc), Canada

PostPosted: Sun 19 Nov 2017, 09:57    Post subject:  

To me, jamesbond's explanation is as clear as day, and my background is in
music and "humanities".

To me it's like a radio wave carrying a signal that has some music on it.

Where the "wave" originates from commands its direction. If the "wave" originates
from the Puppy, then the wave has music on it, and when you plug in the infected
drive, the "wave" remains musical.

On the other hand, should the "wave" originate from the infected drive, there
would be "noise" on the wave, and this "noise" would be carried to the Puppy.

BFN.

_________________
musher0
~~~~~~~~~~
"Logical entities must not be multiplied beyond necessity." | |
« Il ne faut pas multiplier les entités logiques sans nécessité. » (Ockham)
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3103
Location: The Blue Marble

PostPosted: Sun 19 Nov 2017, 23:00    Post subject:  

Quote:
Could you point me, or give me hints/tips, what I could read about to learn more about this difference in what you wrote for "DO THIS" and "DON'T DO THIS".

I honestly don't understand why if both an infected drive and a puppy OS, both connected, and the bios boots up, and you explicitly choose the "Puppy OS" to boot, why it is important to "DON'T DO THIS"?


Because, the boot process always involves of reading something from the disk, and executing it.

When you turn on the computer, the firmware (BIOS/UEFI) is in control.
In case of BIOS, it will read physical sector zero of the boot disk, load it to RAM at address 0x7c00, and then execute it.
In case UEFI, it will read /EFI/boot/bootx64.efi, load it to RAM at its chosen address, and then execute it.
In case of UEFI with Secure Boot, it will read /EFI/boot/bootx64.efi, make sure it is signed by a proper "authority", and then load it to RAM, and then execute it.

And that program can then do anything it pleases.

This is the boot process of all x86/x86_64 desktop/laptop PCs. **ALL** of them, without exception.

================

The only "safety" you have is your firmware configuration ("BIOS Setup").
Sensible people these days set it to "first harddisk".I don't think so.
But sometimes people don't know how the BIOS is configured. The settings could easily be:
a) try USB first,
b) if not exist then harddisk.
And for a long while, if you don't have anything plugged in (or if the USB doesn't contain anything), you won't notice the difference.

Of course, you can specify the settings of "always ask me which boot drive to use". If you do it this way, then yes it will in fact avoid the above problems.
But:
a) most people won't do this because they get very annoyed to be asked the questions at boot time, every time.
b) I haven't seen a firmware where you can configure it to "ask for boot drive" on every boot up.

================

And then there is another problem, which may or may not be "configurable".
Some motherboards have "upgrade-able" BIOS aka "flashable" BIOS where you can "upgrade" the BIOS firmware with new versions (aka re-write the BIOS with new version).
Old motherboards require you to boot to DOS, and then run a special DOS program do it.
Newer motherboards don't need DOS at all, you just need to put the "upgrade image" to USB, and the choose "Upgrade" from the BIOS setup and select that file.
Some motherboards make this even less painful - you just need to put a specially formatted file in the USB, and plug it in, then reboot. At boot time the BIOS will scan for this special file, if it finds it, it will flash and "auto-upgrade" itself. This happens even before the boot process starts.

I think it is obvious what danger it poses.

And here we are, talking about the usual normal process. We haven't touched the bugs in the firmware themselves, of which there are many. Nobody wants to talk about it, because it doesn't pay. Who wants to keep providing "updates" and "bugfixes" for an UEFI firmware of a motherboard which has been shipped, sold and fully paid for 5 years ago? Anybody paid a "maintenance support" when they bought a motherboad? Exactly.

=================

So what can we do?

Simple. DON"T plug a known infected USB before the computer is powered on. Especially if you don't know the kind of infection it has.

Quote:
Is there hard data to back this up? Industry papers? Cited research/tests?? Links????
By now, I think you should have already known whether I'm a trustable source (or not) Laughing
_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3103
Location: The Blue Marble

PostPosted: Mon 20 Nov 2017, 10:34    Post subject:  

Not wanting to go between whatever happens between belham2 and musher0, but in this particular thread at least, I see that musher0 has been trying to help, not to disrupt. There is no insults thrown. no swear words spoken. It doesn't matter that he got the questions wrong, or the answer is a bit off, or the language is a bit flowery. Everyone can make a mistake. The point is, I personally don't see any malevolent intention from him.
_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2632

PostPosted: Mon 20 Nov 2017, 15:36    Post subject:  

jamesbond is filling in some details that are often missing when this gets discussed. The obvious sticking point for me, is that any puppy is going to try and automount the thing -probably even if you insert after full bootup. Most DE's will also do that. If you're gonna dd it, then it should not be mounted anyway.

The BIOS only executes the code in the MBR/.CO of the first drive it recognizes as being 'bootable'. Other drives may or may not be mounted, but mounting itself doesn't cause any code to be executed on them.
Back to top
View user's profile Send private message 
8Geee


Joined: 12 May 2008
Posts: 1293
Location: N.E. USA

PostPosted: Mon 20 Nov 2017, 16:03    Post subject:  

jamesbond makes an excellent point or three.
From my own experience building desktops and seeing the migration to convenience BIOS, it has become a dangerous "world of computing" notwithstanding CPU management set-ups.

The one computer I use has a BIOS that deliberately asks what to load first, and that setting needs to be changed from "CD/DVD" to "USB Harddrive" to "HDD (SSD)". Upon exit, that choice remains until "you" need to change it. There is also a boot order, but none is an option as second choice, and is recommended.

Flashing BIOS... I suppose there is a need, but in older set-ups like mine, its easy to get borqed. And some systems are unreliable/nonfunctional.

If its infeccted... toss it. If you think its infected... toss it. USB sticks/stubs are cheap, computers and their data are not.

Regards
8Geee

_________________
Linux user #498913

Good God!, by the stars in the sky we are lost!
And into the breach we got tossed!
And the world is comin' on fast! --Florence Welch
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1355

PostPosted: Sat 25 Nov 2017, 05:34    Post subject:  

jamesbond wrote:
Quote:
Could you point me, or give me hints/tips, what I could read about to learn more about this difference in what you wrote for "DO THIS" and "DON'T DO THIS".

I honestly don't understand why if both an infected drive and a puppy OS, both connected, and the bios boots up, and you explicitly choose the "Puppy OS" to boot, why it is important to "DON'T DO THIS"?


Because, the boot process always involves of reading something from the disk, and executing it.

When you turn on the computer, the firmware (BIOS/UEFI) is in control.
In case of BIOS, it will read physical sector zero of the boot disk, load it to RAM at address 0x7c00, and then execute it.
In case UEFI, it will read /EFI/boot/bootx64.efi, load it to RAM at its chosen address, and then execute it.
In case of UEFI with Secure Boot, it will read /EFI/boot/bootx64.efi, make sure it is signed by a proper "authority", and then load it to RAM, and then execute it.

And that program can then do anything it pleases.

This is the boot process of all x86/x86_64 desktop/laptop PCs. **ALL** of them, without exception.

================

The only "safety" you have is your firmware configuration ("BIOS Setup").
Sensible people these days set it to "first harddisk".I don't think so.
But sometimes people don't know how the BIOS is configured. The settings could easily be:
a) try USB first,
b) if not exist then harddisk.
And for a long while, if you don't have anything plugged in (or if the USB doesn't contain anything), you won't notice the difference.

Of course, you can specify the settings of "always ask me which boot drive to use". If you do it this way, then yes it will in fact avoid the above problems.
But:
a) most people won't do this because they get very annoyed to be asked the questions at boot time, every time.
b) I haven't seen a firmware where you can configure it to "ask for boot drive" on every boot up.

================

And then there is another problem, which may or may not be "configurable".
Some motherboards have "upgrade-able" BIOS aka "flashable" BIOS where you can "upgrade" the BIOS firmware with new versions (aka re-write the BIOS with new version).
Old motherboards require you to boot to DOS, and then run a special DOS program do it.
Newer motherboards don't need DOS at all, you just need to put the "upgrade image" to USB, and the choose "Upgrade" from the BIOS setup and select that file.
Some motherboards make this even less painful - you just need to put a specially formatted file in the USB, and plug it in, then reboot. At boot time the BIOS will scan for this special file, if it finds it, it will flash and "auto-upgrade" itself. This happens even before the boot process starts.

I think it is obvious what danger it poses.

And here we are, talking about the usual normal process. We haven't touched the bugs in the firmware themselves, of which there are many. Nobody wants to talk about it, because it doesn't pay. Who wants to keep providing "updates" and "bugfixes" for an UEFI firmware of a motherboard which has been shipped, sold and fully paid for 5 years ago? Anybody paid a "maintenance support" when they bought a motherboad? Exactly.

=================

So what can we do?

Simple. DON"T plug a known infected USB before the computer is powered on. Especially if you don't know the kind of infection it has.

Quote:
Is there hard data to back this up? Industry papers? Cited research/tests?? Links????
By now, I think you should have already known whether I'm a trustable source (or not) Laughing


Thank you, Jamesbond, for taking the time to reply. Really appreciate it.

It is worrisome to me that many of Murga here, over the years, keep telling people that they use a usb-installed Pup to fix and/or clean their broken and/or infected machines. and the advice is they are telling people to plug the Pup-usb into a BIOS motherboard that is set the way you described---with the internal sata/ide HD looked at & spoken to first. I would think people (on Murga here) at a minimum need to educate themselves---based on what you wrote----about the advice they are giving.


I understand (I think) about the BIOS, especially non-UEFI bios machines----which is honestly what myself and most of my friends have. Also, when helping anyone, I rarely come across...still, despite UEFI being out for years now...people with UEFI machines.

My friends and I, we all run various versions of puppy, your Fatdog, and Ddogs. We talked about your post the past few days, and almost all of us, on our non-UEFI bios motherboards, ranging in age anywhere from 5-6 years to 12-13 years old, had long ago set our motherboards boot order to be:

1) First device checked: usb
2) Second device checked: cdrom
3) Third device checked: internal sata/ide hard drive
4) Fourth--check other devices: Disabled

Out of our little club of 7 guys, we all to a T had things set up this way. Now, each of us helps quite a few different people, from family members to other friends, when things go wrong with the computers/laptops/etc. So the web is probably 25-35 people over the years we've helped (and most likely much greater).

If I (or we) are to understand your post correctly, we should not have to worry about any possibly "infected" hard drive connected to any of our machines whether at boot or after the pup/fatdog/ddog is booted up.

Why? Because, since ALL of our pups/fatdogs/ddogs are installed "frugally" and since our BIOS motherboard are told to first look for USB connected devices & boot them 1st, then that possibly connected "infected" internal hard drive isn't even looked at and/or spoken to until after the pup/fatdog/ddog is booted up----and thus when the pup/fatdog/ddog tells you the hard drive is available for mounting.

Would this be a correct assumption????


Thank you again for your replies. This is really interesting to me, sort of like learning about hardware and software & the intricate dance they play when electricity first hits them.



P.S. At our little gang of club meeting last night, we each had tried a test with various of our motherboards using the BIOS firmware installed on usb, cdrom and hard drives, respectively. All to see what happens with that booted. None of us could get our motherboards to even recognize there was a BIOS firmware version there on any device--- even the 13-15 year old ECS ones required you to manually first go into or enter the BIOS, and initiate the BIOS firmware upgrade process, and then tell the BIOS where to look. Otherwise, all non-UEFI BIOSes just ignored a stored BIOS firmware version on any storage device. Maybe it might have to do with the fact we all--based on something we read many years ago---have complex character/number/symbol machine-bios-passwds set up where the BIOS cannot be accessed unless this passwd is entered, or you physically get in there and pop the board's battery while everything is unplugged. So that was a relief, again, based on what you wrote Wink
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2632

PostPosted: Sat 25 Nov 2017, 13:24    Post subject:  

The BIOS is not on any disk at all -it's on the motherboard.

Here's a nice exercise for your club:
take an extra computer which is working. Take out all the disks and then turn it on -count any beeps you hear or note any warnings.
Now, start taking more things out -like the RAM. Then turn the machine on and count/beeps note errors
Then take out the CPU and repeat.
Then put the RAM and CPU back in. Turn on again to refresh your memory of how that looks.
Then add a blank hard disk and repeat -should see a different error now.
Now finally, put in a hard drive with(take out the blank one) a fake system -create it by including this:
/bin/sh
/sbin/init
/dev/console
Make the console device a real device node, but have 'sh' and 'init' be empty files.
Reboot machine and see what happens.
Then make /bin/sh be areal working shell -statically linked. Reboot and see what happens. Should get errors here about init not running, but the kernel will fall back to /bin/sh

By now you should be getting a good idea of where/when things happen near the transitions from BIOS to MBR(use a normal DOS-style MBR for your disk). And you'll see the transition when the kernel first tries to mount the root partition and then turn execution over to 'init'.
For the next bit of learning study a simple use-case of init scripts -far, far from puppy. Like Slackware just downlaod the sysvinit-scripts package. The init scripts are run in this order:
rc.S
rc.M
Study the rc.S very closely to see how 'real' init always was. Unfortunately nearly all distros now use systemd, so finding other examples to look at is harder -try CRUX linux or find some really old CD's from debian, suse or redhat.

The study the initrd used by the slackware installer -it's even busybox init, but you'll see the similarity. Then compare an installer initrd to the one created by the slackware 'mkinitrd' script -which does very, very little -mostly loading any kernel modules needed to access the root filesystem.

Study the old slackware 'live' system, comparing it with Alien Bob's modern slackware live -similar to linux-live. Notice very well what they *do not* do in the initrd.
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1355

PostPosted: Sat 25 Nov 2017, 16:46    Post subject:  

amigo wrote:
The BIOS is not on any disk at all -it's on the motherboard.


Hi Amigo,

Not sure where this is coming from....what we were testing is whether, like Jamesbond said, some BIOS-es on motherboards can automatically grab their update.bin file if they sense it on anything attached (usb, cdrom, etc). I, or we, know the BIOS is on the motherboard Smile . Sorry if the way I wrote it was confusing and made it appear we didn't Embarassed

As far as the other ideas, thanks!! I'm gonna try them in the next few days....I love learning more about the interaction between hardware and software, whether it is the BIOS and/or the OS loading, and what happens in sequence. I've tried to study Barry's old diagrams with pups too, explaining things---though I gotta admit, I get lost quite a bit.

For about 15 years now I've built my own computers, or rather, put them together, buying all components separately, and then loading stuff and finally the OS. But I can see when I talk to you guys I never understood the why(s) behind so many things. Sort of just stumbling along. Wink

Thanks again!
Back to top
View user's profile Send private message 
purple379

Joined: 04 Oct 2014
Posts: 80

PostPosted: Mon 27 Nov 2017, 21:13    Post subject: Low Level Format of USB Keys  

These programs were mentioned to me in a question to Kingston, in regards to Windows. Likely there are some Linux equivalents.

"In order to completely format your USB drives please try to carry out a so-called low level format on the USB drives using a freeware utility such as Active Killdisk, TestDisk or HDD Guru.

A low level format goes much deeper than the standard Windows format, removing the tertiary and secondary data layers - only the primary layer remains intact.

Once you have formatted the product with a low level format utility, please reformat it again in Windows using the options FAT32, NTFS or exFAT. "

Since I know that in Windows, there used to be a way a USB would infect the computer, such that every USB Key plugged in later would receive the malware infection, and that could be transferred to another computer. I want a program that explicitly re-sets my computers USB to what it should be, and some where in there, allows me to reset the USB key to normal, while not clobbering the useful data on the Key. A warning wouldn't hurt either. Some Windows Security programs seem to imply that they will warn me, and keep things functional. Not sure if I trust them. How do we do it in Linux? Or did I miss someone telling me an easy way to keep up on this problem?
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1355

PostPosted: Tue 28 Nov 2017, 13:49    Post subject: Re: Low Level Format of USB Keys  

purple379 wrote:
These programs were mentioned to me in a question to Kingston, in regards to Windows. Likely there are some Linux equivalents.



Hi Purple379,

Is maybe the dd command in Linux equivalent to the "low-level" thing Kingston replied to you about?

When I really want a USB or HD (not SSD, though) throrougly wiped, I dd it. Something like:

Code:
# dd if=/dev/zero of=/dev/sd# bs=4096


...and if I am giving a USB or DD to someone, I also (after the above) hit it with:

Code:
# dd if=/dev/urandom of=/dev/sd# bs=4096



DD is even great for just wiping an MBR (that got corrupted, or whatever) by doing this:

Code:
 dd if=/dev/zero of=/dev/hd# bs=446 count=1


.....or if you just want to wipe a partition and/or securely wipe it:

Code:
 dd if=/dev/zero of=/dev/sd## bs=1M


with security:
Code:
 dd if=/dev/urandom of=/dev/sd## bs=1M



Then after I am through with DD-ing, I next hit it with Gparted, and also set it up there. But what is super interesting is what data the OS you are using to run DD (on another USB or HD) is sharing with the DD-target. That is mucho interesting, and I am learning more about this right now over on Stack Exchange & a Reddit subthread (that both are admittedly hard to follow since inhabitants there are all, or seem to be, high level kernel developers/programmers).



Lastly, I was confused about this sentence you wrote:

Quote:
I want a program that explicitly re-sets my computers USB to what it should be, and some where in there, allows me to reset the USB key to normal, while not clobbering the useful data on the Key.


Does such a program actually exist? For any type of OS (Windows, Mac, all flavors Linux)???
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 3 [35 Posts]   Goto page: Previous 1, 2, 3 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Security
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1007s ][ Queries: 14 (0.0087s) ][ GZIP on ]