From: no.top.post on
Although, learnt at the 8-bit device level, I KNOW computers
down to the transistor level. So I get very annoyed and insulted
by these art-students and journalist's stories.

> http://seattlepi.nwsource.com/business/351670_picframevirus18.html
>
> While some advise disabling Autorun in Windows, which allows
> devices to run automatically when they're plugged into a USB port,
> it's not a fail-safe. Doing so requires some computer expertise,
> and this Trojan re-enables Autorun if it's turned off, according to
> Brian Grayek of Computer Associates. "If you plug in (the frame),
> you're already infected," he said.
>
> Deborah Hale at SANS suggested that PC users find friends with
> Macintosh or Linux machines and have them check for malware before
> plugging any device into a PC.

OK, while writing this, I've realised that eg. the facility :"boot from
a USB, or any other device" is where the virus could be introduced.

For the PC to 'become infected' it must either:
1. execute some code in the USB-device -> autoboot is disasterous !
2. have the active USB device write to the PC memory, which will
later be executed by the PC. But the PC controls what is written to
its executable RAM/ROM.
Although the USB-device is an active device, which can independantly
'talk' to the PC, the PC will decide if/when to 'listen' and the input from
the USB will be interpreted/treated as data. So the received bytes will
never get a chance to be executed.

Since the operation of the CPU is via:
1. fetch the instruction via the program-counter/pointer current value,
2. execute the fetched instruction,
3. step the program-counter/pointer;
the boot-device must provide the code to be executed ON REQUEST
BY THE PC, to first be cached in RAM. I.e. where steps 1,2,3 can be
performed.

Perhaps modern systems can fake a delivery of a data request
[via the normal adr-bus mechanism] by hardware
diversion/multiplexing and waiting for the byte/s to arrive
from the device other than RAM/ROM, instead of first loading
some bytes to cache. But this seems pointless.

Q what [explained, down to the level like I've done] is the
"auto run" mode of Windows ?

== TIA
From: Maxwell Lol on
no.top.post(a)gmail.com writes:

> OK, while writing this, I've realised that eg. the facility :"boot from
> a USB, or any other device" is where the virus could be introduced.

It's not simply booting. But simply plugging in the USB drive, that
allows the virus to infect a computer.

See ArameFarpodo's post.

I disable auto-run on my computers for all external drives
(network mounted, USB, etc.)

One of the easy ways to hack into a computer facility is to drop
infected USB drives in the parking lot. A lot of people will pick them
up and plug them in to see what's on the drive.
From: Greegor on
ML > One of the easy ways to hack into a computer facility is to drop
ML > infected USB drives in the parking lot. A lot of people will pick
them
ML > up and plug them in to see what's on the drive.

I know I shouldn't laugh, but I just couldn't help it!
From: J G Miller on
On Thu, 14 Jan 2010 01:38:51 -0800, Greegor wrote:

> I know I shouldn't laugh, but I just couldn't help it!

Well security on Micro$loth windoze systems is rather a laugh, is it not?

If the USB key was plugged into a BSD or GNU/Linux system and then
examined with the usual tools, without any HAL automounting and clever
script to automagically run any .autorun files present through WINE, no
infection would result would it?
From: The Natural Philosopher on
J G Miller wrote:
> On Thu, 14 Jan 2010 01:38:51 -0800, Greegor wrote:
>
>> I know I shouldn't laugh, but I just couldn't help it!
>
> Well security on Micro$loth windoze systems is rather a laugh, is it not?
>
> If the USB key was plugged into a BSD or GNU/Linux system and then
> examined with the usual tools, without any HAL automounting and clever
> script to automagically run any .autorun files present through WINE, no
> infection would result would it?

why would one ever run automount and WINE anyway?