Plugging an infected USB/HD into a Puppy

[musher0]

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.

[jamesbond]

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.

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)

[jamesbond]

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.

[amigo]

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.

[8Geee]

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

[belham2]

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.

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)

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

[amigo]

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.

[belham2]

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 . Sorry if the way I wrote it was confusing and made it appear we didn't

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.

Thanks again!

[purple379]

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?

[belham2]

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: Select all

# 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: Select all

# 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: Select all

 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: Select all

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

with security:

Code: Select all

 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:

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)???

[purple379]

I seem to recall one of those programs had a Linux version. Is that version just a GUI for DD, I do not know. Seems unlikely that there is any program that Linux can not already emulate, if I chose the right program and right options.

To better explain what my concerns. To go back in time a bit. Used to be that Malware (in Windows) on a USB key would automatically install itself on Windows, and proliferate in both the Windows system, and to other USB keys that were plugged in. I know that some current Windows Security programs scan all USB keys plugged into system, but I am unclear whether that actually catches the latest current version of USB malware. Keeping in mind that the USB Malware might be the carrier for several different type of Malware.

I know some folks are going to say, but M$ said they fixed those things, and why are we talking about Windows here. Because I am not sure the same problems will not proliferate in Linux. Guessing that the it is the basic to the OS that is being corrupted, by the time I plug in the USB, how can be sure that the format will write over everything on the USB key.

I also thought that it might be a different program to format a USB 3.0 key versus USB 2.0, so it seems possible that some other things are possible in formatting USB keys.

Nope, I do not know any OS that will explicitly write over, what used to hide in the boot sector of the USB key, and not clobber my personal data. But if the malware can infect the OS at the first read of the USB key by the OS, I may be writing the Malware back onto the USB key myself.

My concern in writing Kingston, which because I was using TOR at that moment, ended up in Europe, not the US, was that I had several USB keys that showed substantially less space that they used to. Kingston first expressed that different OS's show different sizes. However, I have not updated my Apple- OS X in some time, and it showed less space. Once though, I once formatted some of these keys to NTFS, which I believe would take up space for a boot sector. However, Formatting them back to FAT did return the larger space. And I read that the OS X Disk Utility did not function as it once did.

So Yeah, I am looking a security blanket assurance that when I format a USB key, I have gotten rid Malware. Keeping the primary OS on the hard drive, Linux or Windows free of USB malware is likely always a moving target. I also wonder, since SSD's have sections to take care of bad spots on the drive, that its firmware can not be re programmed, and used to deliver a malware load.

You are correct in suggesting I know little of what I am talking about.

[Burn_IT]

Does such a program actually exist? For any type of OS (Windows, Mac, all flavors Linux)???

No! Magic does not exist.


editd to add quote for clarifiction.

[jamesbond]

I hope I don't scare you too much on my previous post.

To continue this thread - I need to emphasise that what I wrote about BIOS/UEFI-level of infection is at "plausible" level.
There are indeed malware that works like what I described above; but they don't come very often.
Usually at this level of infection, you don't call them malware anymore - you call them rootkit.

But does it mean that that putting an infected USB while the computer is off, and then plugging it on, automatically infects it?
The answer is of couse, "it depends". It depends on your BIOS settings, it depends on what kind of malware is inside the infected USB, etc.
It depends on the infection. Ebola is pretty nasty but cold will just give you an excuse to stay in bed for a few days.
If you know for sure that the infection is your typical Windows virus, then most of the time it would be okay because they can only infect when they are loaded and run properly as Windows programs.

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.

This is not the same. There is a difference between plugging an infected USB to a known clean system; and plugging a known clean USB to a known infected system (in its harddisk).

The difference is this: a clean system is normally clean. Plugging an infected USB may harm it, so you take precaution and insert the USB only when the computer is already ON. If you don't, you risk endangering the system. So be careful with what you're doing; because the loss is big (you lose your clean computer).

On a known infected system, all bets is off. The system is by default is already considered toast. Again, unless you know exactly what the infection is, you don't know how much damage is already done. Plugging an clean USB in order to try to "fix" and "clean" the system is valiant attempt; and it may or may not be successful (again, it dependson the infection); but it doesn't, the worst that can happen is that now you have an additional infected USB. Which you can toss away if you're so inclined.

So the advice given in the forum is indeed solid.

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.

This wasn't the what the original question was.

The original question (as I understood is) was: "is it risky to put a known infected USB drive?" - which (to me) implies that the your OS is in the harddisk, and you're trying to salvage data from your infected USB drive.

What you wrote above, now, inverts the situation.
You're now asking whether that booting from a known clean USB drive is okay, even if it is known that the harddisk is infected.
Well, I didn't say that previously because I was focusing on the original point.
You are correct to say that "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", but remember, this depends on the infection. See what I've just written above. If the infection is only of the usual kind, then yes it's safe. If your infection is the firmware rootkit type; this gets executed even before the OS starts (any OS for that matter) so all bets are off.

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

What I have written in my previous post is "what could plausibly happen"; and it has happened before. It is also true that this kind of attack is rare, because it requires very specific knowledge and it only attacks very specific hardware. So you may be very well not affected. But that doesn't mean you don't take precaution.

_______________________________________

"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.

I don't know about Acgive Killdisk or HDD Guru.
But TestDisk is definitely not a low-level formatter for USB drive.
"dd" isn't a low-level formatter either.

True generic low-level formatter died with controller-less MFM/RLL harddisk, in early 1990s.
These days, you can only get a true low-level formatter from the harddisk/USB manufacturer.

In modern times the low-level formatter program resides in the harddisk controller - if the manufacturer chooses to put it there.
That's the small PCB board that is attached on the harddisk itself.

To perform low-level format, you need to send secret magic codes to the harddisk controller to active this built-in program.
You can do this with "hdparm" in Linux.
But you must know the magic codes.
Most manufacturers don't share these magic codes.
Instead, the best they would do, is to provide a "advanced diagnostic" program that does it, internally.
And this program is specific to the manufacturer; sometimes, different disks requires different programs.

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.

Meaningless statements unless they define what exactly these layers mean.

I love startrek but I understand that most of what they say is technobabble.
Be careful of marketing statements disguised in technical terms.

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.

It doesn't exist.

[belham2]

I hope I don't scare you too much on my previous post.

..no worries, this is just a great learning exercise for me/us.

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.

This wasn't the what the original question was.

What you wrote above, now, inverts the situation.

..oops, typo, I did not mean USB but meant Hardrive. Problem is, with nomenclature, having internal HDs and external HDs in abundance, some with USB attached, others still "officially" internal drives even though they sit outside the computer, where they are easily unplug-able and, in some cases, swap-able, I have to remember to keep the terms right. So no "inverting" the situation was intended.


Lastly, found something enormously interesting......we've been using both Windows 10 testing OS that one can download for free (and is good for 3 months) and also using large Linux Distros (Ubuntu/Debian and Fedora) and playing with this plugging USB OSes into them, and booting both at the same time & seeing what happens. One of our club members purposely infected the Window OS with malware, a root worm, and then we tried various scenarios.

1) If you plug a pristine USB frugal installed pup in, they all were immediately infected at boot, and showed the worm upon booting into them with Windows OS waiting to be mounted.

2) But, if the USB frugal pup was booted alone, without the Windows 10 OS Harddrive plugged in, and only after the pup was booted and fully running, and then plugged in the root worm, it seemed it could not infect the pup, and we could clear the infected Windows 10 HD. But boy, if you did it the other way (#1 above, and left the infected Win10 HD plugged in at boot, it basically screwed every USB frugal pup we tried (we tried Slacko64 & XenialPup64).

Interesting: lesson to us is NEVER, if having a suspected drive, leave it plugged in while you are booting a pup-USB loaded thumbdrive up. IT seems too risky.


But, this next thing was even more interesting, or we thought:

We loaded Debian 9 Stretch full XFCE install on an internal HD, and then loaded a Debian 9 USB Ddog USB thumbdrive, left both plugged in, turned on the machine, and chose the Ddog USB, after booting, getting to the OS, then shutting down, to only run the Debian 9 XFCE HD, you no longer had Interent, among a few other things. Why? The Ddog USB completely overwrote all Internet settings that had been saved previously with whatever was in the USB Ddog stick. And the dEbian 9 Stretch full XFCE HD was never even mounted in Ddog! and the "automount" ability of Ddog was specifically removed ahead of time for this test.

So, here we have a case of info changing at boot (from an attached USB OS) where the internal HD was never even mounted during the whole test. This was repeated 3 times, and each time it happened.

I am wondering if the same will happen with Slacko USB and Slacko full HD installs? When OSes and pups are of the same derivative, something funny seems to going on at boot and bootup. There seems to be more info being exchanged, written and overwritten during/after bootups than people realize when using, say, a slacko-pup USB on a full HD slacko install (same goes for Debian, as noted above, and Ubuntu; Fedora, so far, has seemed impervious to everything we've thrown at it, plus not understanding Fedora/OpenSUSE at all makes even harder).


So the investigations continue.

[purple379]

Keeping in mind the difference to the MOBO in booting an USB plugged in drive in my laptop, and the one in my desktop.

Also guessing that when one writes an Optical disk with an ISO, it can or can not pick up malware on the computer writing the ISO.

[greengeek]

Well ok this thread has gone quiet but having stumbled across it I shall chuck my somewhat paranoid 2c worth in...

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???

Yes, definitely. For two reasons - firstly malware can act at the hardware level - below the level at which Puppy interacts with the drive. Infection can occur without any interaction from Puppy. It depends on bios, mobo, firmware etc etc. Secondly - Puppy does not always wait for you to mount a drive. Sometimes the drive is momentarily mounted then dismounted by Puppy invisibly.

One significant question is - exactly what type of malware exists on the usb stick? Could it be a "made-in-china" stick with embedded spyware? Could it be a promotional usb stick a friend brought back from a trip to Moscow or TelAviv? Is it poorly written Linux code that has the potential to damage your hardware?

For example - Linux code on a usb stick can damage the uefi hardware in the mobo. I suppose this could be called a type of malware. Certainly destructive anyway (and not only limited to Lenovo products):
https://bugs.launchpad.net/ubuntu/+sour ... ug/1734147
(uefi hardware allows the "bios" to be updated by the code run by the usb stick. It is not "fixed" like old style bios used to be)

Also usb sticks are not always what they seem:

- USB sticks are not just non-volatile RAM - they include a hardware controller that can bypass udev. The controller talks to the mobo and bios/uefi much more than it talks to udev.

- Malware controllers in USB sticks can falsify the amount of RAM they contain. This can work both ways - a stick can have 2GB of storage but advertise itself as being a 16GB stick. (There goes 14GB of valuable data constantly being overwritten without errors). Or it can be a 16GB stick that advertises itself as an 8GB stick. It can use the hidden storage for malware purposes.

- Some usb sticks have entire hidden partitions (hard drives can too)
http://www.instructables.com/id/Create- ... ive-which/
Some hidden partitions can be set up by the stick manufacturer and not discoverable by Linux. Hard drives out of scada-controlled machines or out of proprietary imaging devices often have hidden partitions holding hidden code (particularly prevalent in photocopier hard drives where hardwired anti-counterfeit measures are commonplace). DD and Gparted are inadequate at that level.

- Some usb sticks can harbour rootkits.
Even manufactureres with the best intentions can do sneaky things:
https://en.wikipedia.org/wiki/Sony_BMG_ ... it_scandal
If Lenovo made usb sticks I would not be keen to insert them into my PC!
https://thehackernews.com/2015/09/lenov ... virus.html

- Some usb sticks are actually data loggers or audio recorders (even though they look just like a normal usb stick)

- It is possible for a usb stick to have a wifi transmitter inside it and broadcast your information without you realising it is anything other than a normal storage device. Even some SD cards are wifi capable.

- You have no idea if the controller firmware in a usb stick is safe or hacked:
http://au.pcmag.com/opinion/23289/an-ev ... detectably
"At the Black Hat 2014 conference, two researchers from Berlin-based SRLabs revealed a technique for modifying a USB device's controller chip so it can "spoof various other device types in order to take control of a computer, exfiltrate data, or spy on the user." That sounds kind of bad, but in fact it's really, really dreadful."
"He next plugged the just-infected drive into a Linux notebook, where it visibly issued keyboard commands to load malicious code. Once again, the demo drew applause from the audience."

Stuxnet (introduced by infected usb sticks) affected scada devices by autorunning code that redistributed itself. Windows is really susceptible to that sort of thing but Linux can be hijacked too. Some malware is a tool used by "state level" hackers.
https://www.wired.com/2014/11/countdown ... y-stuxnet/

At that "nation state" level they work with hardware manufacturers (MOBO and USB devices etc) to build hacker interfaces into the hardware.

The BIOS itself can be hacked by various methods:
https://cansecwest.com/csw09/csw09-sacco-ortega.pdf
Entirely conceivable that a usb stick could harbour such code.

Although unlikely to happen to you or me, it is possible for state backed hackers to add hardware "malware" into various devices during shipment:
https://www.theverge.com/2013/12/29/525 ... -plant-spy
https://www.theatlantic.com/technology/ ... re/356548/
"NSA hackers have tools to crack systems created by Cisco, Western Digital, Huawei, or any other major cyber security firm. No target's computer is safe."
http://www.spiegel.de/international/wor ... 40994.html

I also recently read that bitcoin algorithms have contained spyware since day one. Something to do with an evergrowing blockchain retaining critical users info. Can't put my finger on the link at the mo.

[8Geee]

And bitcoin miners exist in some websites while you are there... the giveaway is the increased CPU usage (usually pegged at 100% especially on older machines). So youur computer is mining bitcoins for the webby.

my added 2 micro bitcoins
8Geee