PDA

View Full Version : keyboard/mouse programming


Eccentric OpenBSD User Dave
November 23rd 07, 03:22 PM
Is there any way on an x86 system that a working ps2 keyboard/mouse can be
disabled by writing data to the device?

Thanks.

Ed[_4_]
November 24th 07, 06:45 AM
On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
> wrote:

>Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>disabled by writing data to the device?
>
>Thanks.

If using Windows (95-XP) you can use BlockInput.
http://msdn2.microsoft.com/en-us/library/ms646290.aspx

Eccentric OpenBSD User Dave
November 24th 07, 12:46 PM
In alt.comp.hardware.amd.x86-64 Ed > wrote:
> On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
> > wrote:
>
>>Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>disabled by writing data to the device?
>>
>>Thanks.
>
> If using Windows (95-XP) you can use BlockInput.
> http://msdn2.microsoft.com/en-us/library/ms646290.aspx

Thanks. Actually, I am running X windows and I was looking for info
about a possible exploit that I may be experiencing.

Eccentric OpenBSD User Dave
November 24th 07, 10:30 PM
In alt.comp.hardware.amd.x86-64 Eccentric OpenBSD User Dave > wrote:
> In alt.comp.hardware.amd.x86-64 Ed > wrote:
>> On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
>> > wrote:
>>
>>>Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>>disabled by writing data to the device?
>>>
>>>Thanks.
>>
>> If using Windows (95-XP) you can use BlockInput.
>> http://msdn2.microsoft.com/en-us/library/ms646290.aspx
>
> Thanks. Actually, I am running X windows and I was looking for info
> about a possible exploit that I may be experiencing.

The question I am really trying to get an answer to is whether it is
possible for the cpu to send commands to the x86 keyboard/mouse that
will cause those devices to shut down permanently, effectively making
them useless.

Marcus Red
November 25th 07, 09:06 AM
Eccentric OpenBSD User Dave wrote:
> In alt.comp.hardware.amd.x86-64 Eccentric OpenBSD User Dave > wrote:
>> In alt.comp.hardware.amd.x86-64 Ed > wrote:
>>> On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
>>> > wrote:
>>>
>>>> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>>> disabled by writing data to the device?
>>>>
>>>> Thanks.
>>> If using Windows (95-XP) you can use BlockInput.
>>> http://msdn2.microsoft.com/en-us/library/ms646290.aspx
>> Thanks. Actually, I am running X windows and I was looking for info
>> about a possible exploit that I may be experiencing.
>
> The question I am really trying to get an answer to is whether it is
> possible for the cpu to send commands to the x86 keyboard/mouse that
> will cause those devices to shut down permanently, effectively making
> them useless.
>
Why would you want to do this?

YANSWBVCG
November 25th 07, 12:31 PM
In alt.comp.hardware.amd.x86-64 Marcus Red > wrote:
> Eccentric OpenBSD User Dave wrote:
>> In alt.comp.hardware.amd.x86-64 Eccentric OpenBSD User Dave > wrote:
>>> In alt.comp.hardware.amd.x86-64 Ed > wrote:
>>>> On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
>>>> > wrote:
>>>>
>>>>> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>>>> disabled by writing data to the device?
>>>>>
>>>>> Thanks.
>>>> If using Windows (95-XP) you can use BlockInput.
>>>> http://msdn2.microsoft.com/en-us/library/ms646290.aspx
>>> Thanks. Actually, I am running X windows and I was looking for info
>>> about a possible exploit that I may be experiencing.
>>
>> The question I am really trying to get an answer to is whether it is
>> possible for the cpu to send commands to the x86 keyboard/mouse that
>> will cause those devices to shut down permanently, effectively making
>> them useless.
>>
> Why would you want to do this?

I don't want to do this, but I suspect that some X-related exploit is doing
it to me as a simple DOS attack. If this is *not* happening to me, then I
am buying really crappy mice and keyboards and need to switch to better
brands.

Rod Pemberton
November 25th 07, 02:43 PM
"Eccentric OpenBSD User Dave" > wrote in message
> The question I am really trying to get an answer to is whether it is
> possible for the cpu to send commands to the x86 keyboard/mouse that
> will cause those devices to shut down permanently, effectively making
> them useless.
>

Permanently?...

Does your BIOS may allow you to disable them, e.g., for USB or embedded? If
so, maybe CMOS is being corrupted. But, I'd think that would be temporary
and would block other keyboards from working...

You can temporarily disable access by reprogramming PIC's or sending
commands to the keyboard controller, if your OS gives you the privilege.
For the later to become "permanent," it could be written into the
bootloader, some part of the early OS stages, BIOS, video BIOS, etc. The
sequences are small and short. Of course, this wouldn't allow replacement
keyboards and mice to work...

If it's an exploit, as you mentioned elsewhere, you need to systematically
replace all possible "bad" code with good. First, wipe the CMOS, or you
could try toggling all the BIOS settings, saving, toggling back, resaving,
to "wipe" CMOS, then reinstall your bootloader, reinstalling FreeBSD,
reinstalling XWindows, and as a last resort reflashing your BIOS (taking
care with this one...), etc.


Rod Pemberton

YANSWBVCG
November 25th 07, 07:50 PM
In comp.lang.asm.x86 Rod Pemberton > wrote:
>
> "Eccentric OpenBSD User Dave" > wrote in message
>> The question I am really trying to get an answer to is whether it is
>> possible for the cpu to send commands to the x86 keyboard/mouse that
>> will cause those devices to shut down permanently, effectively making
>> them useless.
>>
>
> Permanently?...

As in 'the keyboards and mice don't work any more on other computers'.

> Does your BIOS may allow you to disable them, e.g., for USB or embedded? If
> so, maybe CMOS is being corrupted. But, I'd think that would be temporary
> and would block other keyboards from working...

Actually, one of the other problems I was having was the loss of the ability
to enter the bios at boot time by pressing the delete key. This was the
problem that made me start thinking that it might be time to reflash the bios.

> You can temporarily disable access by reprogramming PIC's or sending
> commands to the keyboard controller, if your OS gives you the privilege.
> For the later to become "permanent," it could be written into the
> bootloader, some part of the early OS stages, BIOS, video BIOS, etc. The

Don't forget SMM.

> sequences are small and short. Of course, this wouldn't allow replacement
> keyboards and mice to work...
>
> If it's an exploit, as you mentioned elsewhere, you need to systematically
> replace all possible "bad" code with good. First, wipe the CMOS, or you
> could try toggling all the BIOS settings, saving, toggling back, resaving,
> to "wipe" CMOS, then reinstall your bootloader, reinstalling FreeBSD,

Did all that multiple times.
I'm running OpenBSD. I reinstall early and often :-).

One of the problems that suggests to me that there is a backdoor in OpenBSD is
that, after installing OpenBSD from cdrom and doing nothing else, within a few
hours the cdrom would not open when the OS was running. This happened several
times immediately after installing the OS and verifying that the cdrom drive
was working properly. At one point all of the usb devices malfunctioned althoughthe devices I was trying to read worked without error on a different system.

> reinstalling XWindows, and as a last resort reflashing your BIOS (taking
> care with this one...), etc.

Thanks for the ideas!

>
> Rod Pemberton
>

Esra Sdrawkcab
November 25th 07, 09:02 PM
YANSWBVCG wrote:
> In alt.comp.hardware.amd.x86-64 Marcus Red > wrote:
>> Eccentric OpenBSD User Dave wrote:
>>> In alt.comp.hardware.amd.x86-64 Eccentric OpenBSD User Dave > wrote:
>>>> In alt.comp.hardware.amd.x86-64 Ed > wrote:
>>>>> On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
>>>>> > wrote:
>>>>>
>>>>>> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>>>>> disabled by writing data to the device?
>>>>>>
>>>>>> Thanks.
>>>>> If using Windows (95-XP) you can use BlockInput.
>>>>> http://msdn2.microsoft.com/en-us/library/ms646290.aspx
>>>> Thanks. Actually, I am running X windows and I was looking for info
>>>> about a possible exploit that I may be experiencing.
>>> The question I am really trying to get an answer to is whether it is
>>> possible for the cpu to send commands to the x86 keyboard/mouse that
>>> will cause those devices to shut down permanently, effectively making
>>> them useless.
>>>
>> Why would you want to do this?
>
> I don't want to do this, but I suspect that some X-related exploit is doing
> it to me as a simple DOS attack. If this is *not* happening to me, then I
> am buying really crappy mice and keyboards and need to switch to better
> brands.
>
Ah good, I found the requirement a bit suspicious; I can't think of (not
to say there aren't any) any exploit to kill keyboard input (mouse
disabling being covered earlier).
OTOH, way back when (early 80's) there used to be games that required
the original boot floppy to run off, and some code on there disabled
Ctrl-Alt-Delete; so it may be possible.

YANSWBVCG
November 26th 07, 12:09 AM
In alt.comp.hardware.amd.x86-64 Esra Sdrawkcab > wrote:
> YANSWBVCG wrote:
>> In alt.comp.hardware.amd.x86-64 Marcus Red > wrote:
>>> Eccentric OpenBSD User Dave wrote:
>>>> In alt.comp.hardware.amd.x86-64 Eccentric OpenBSD User Dave > wrote:
>>>>> In alt.comp.hardware.amd.x86-64 Ed > wrote:
>>>>>> On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
>>>>>> > wrote:
>>>>>>
>>>>>>> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>>>>>> disabled by writing data to the device?
>>>>>>>
>>>>>>> Thanks.
>>>>>> If using Windows (95-XP) you can use BlockInput.
>>>>>> http://msdn2.microsoft.com/en-us/library/ms646290.aspx
>>>>> Thanks. Actually, I am running X windows and I was looking for info
>>>>> about a possible exploit that I may be experiencing.
>>>> The question I am really trying to get an answer to is whether it is
>>>> possible for the cpu to send commands to the x86 keyboard/mouse that
>>>> will cause those devices to shut down permanently, effectively making
>>>> them useless.
>>>>
>>> Why would you want to do this?
>>
>> I don't want to do this, but I suspect that some X-related exploit is doing
>> it to me as a simple DOS attack. If this is *not* happening to me, then I
>> am buying really crappy mice and keyboards and need to switch to better
>> brands.
>>
> Ah good, I found the requirement a bit suspicious; I can't think of (not
> to say there aren't any) any exploit to kill keyboard input (mouse
> disabling being covered earlier).
> OTOH, way back when (early 80's) there used to be games that required
> the original boot floppy to run off, and some code on there disabled
> Ctrl-Alt-Delete; so it may be possible.

Today I discovered that a kvm switch I have just started using is defective.
The mouse port to the kvm switch no longer works although a mouse taken
from that port and plugged directly into the computer does work. The kvm
switch joins the list of new equipment going mysteriously bad within weeks
of being placed into service with the AMD64 computer which itself has run
flawlessly in 64-bit mode for over a year now.

Jerry Coffin
November 26th 07, 02:42 AM
In article >,
says...

[ ... ]

> Today I discovered that a kvm switch I have just started using is defective.
> The mouse port to the kvm switch no longer works although a mouse taken
> from that port and plugged directly into the computer does work. The kvm
> switch joins the list of new equipment going mysteriously bad within weeks
> of being placed into service with the AMD64 computer which itself has run
> flawlessly in 64-bit mode for over a year now.

I'd put odds at about 1000:1 that this is a hardware problem. In theory,
it's probably even a repairable one, though given the cost of a
motherboard, it's rarely worthwhile to do so.

It's very likely that the signals your computer's mouse port are
generating are no longer within specifications -- something like a bad
voltage regulator or even just a bad capacitor can allow it to send out
signals it's not supposed to. The circuits that attach to the port
normally have small electrostatic discharge protection circuits (like
tiny surge protectors) on their inputs, so they can last a while -- but
much like a surge protector, there's a limit to the protection they
provide before the protection is gone. After that, the bad signal kills
them.

You've got a couple of obvious ways to deal with this. One is to simply
replace the motherboard. Another is to treat your current mouse port as
dead, and hook your mouse to a different port (e.g. USB). Yet another
possibility is to use that machine only in a headless configuration.

To conclude: you're not going to find this mysterious mouse-killing
software, because that's not what's causing the problem.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Rod Pemberton
November 26th 07, 09:38 AM
"YANSWBVCG" > wrote in message
. ..
> Today I discovered that a kvm switch I have just started using is
defective.
> The mouse port to the kvm switch no longer works although a mouse taken
> from that port and plugged directly into the computer does work. The kvm
> switch joins the list of new equipment going mysteriously bad within weeks
> of being placed into service with the AMD64 computer which itself has run
> flawlessly in 64-bit mode for over a year now.
>

Dave or YANSWBVCG,

Okay, this thread has become a "mystery novel" and I'm getting bored with
it. Each response seems to adds more information that wasn't mentioned
earlier... Since it seems we are no closer to finding the issue, I'll
"shotgun" some ideas for you:

1) The "hard errors" on the keyboards and mice suggest electrical problems
to me (blown circuitry, flaky cable, pepsi, heavy handedness).
2) The loss of usb etc., implies electrical problems to me (power dropout),
but could be software.
3) The "blown" KVM port implies electrical problems to me.
4) The locking of the cdrom drive is normal for Live-CD's if the OS has
mounted the CD for access or install or swap file, etc.
5) The locking of the cdrom drive if not mounted, e.g., hardisk or floppy
boot, suggests memory corruption to me.
6) The inability to access BIOS via delete key at boot could be a failure to
detect the CPU (overheated, overclocked), CMOS corruption (wrong cpu or bus
speed setting), or A20 issue (can't execute part of BIOS or video BIOS).
Does the BIOS detect the CPU? If CPU, this implies an electrical or heat
problem to me. If CMOS, this implies a software bug, like A20 being
disabled.

Completely unrelated questions, just in case there are multiple unrelated
issues...:

Is this a normal home computer, with a tower case? Or, is it this
"corporate?" If corporate, could it be sabotage, say from a vendor trying
to sell you stuff? What about a vendor stealing or a coworker (different
department) swapping bad stuff for the good "hardly used" stuff your
department has (I've seen this happen...a few times.)? Do the serial
numbers match what you bought? If a home PC, why the KVM switch? Could the
KVM switch be blowing stuff as you replace it? Is this system being
overclocked (overheating, underpowered, "aged" circuitry from overclocking
or poor ventilation)? Was it moved just recently to near a window (memory
corruption from cosmic rays, solar rays, high energy particles, or
background radiation)? What are the PS ratings? What are the 12V current
rating(s) (underpowered)? Since it's an AMD, what are the 3.3V current
rating (since AMD's need more current on the 3.3V line)? Was the PC
recently "upset" by relocating, opening, dusting, vacuuming, etc. (loose
cables, memory or cpu not set in socket or slot, ventilation esp. rack unit,
static zapped)? Are you using RAID (hard disk failures)? Are you using
Western Digital hard disks?

This link indicates that harddisk, raid, or memory errors occur far more
often than detected:
http://storagemojo.com/2007/09/19/cerns-data-corruption-research/


Rod Pemberton

ArarghMail711NOSPAM
November 26th 07, 10:34 AM
On Mon, 26 Nov 2007 03:38:15 -0500, "Rod Pemberton"
> wrote:

<snip>
>
>Okay, this thread has become a "mystery novel" and I'm getting bored with
>it. Each response seems to adds more information that wasn't mentioned
>earlier... Since it seems we are no closer to finding the issue, I'll
>"shotgun" some ideas for you:
<snip>

I was thinking much the same way. I was about to suggest:

A) Get a *GOOD* memory test program, and let it run for 5 or 10 passes
(that would probably be several days for a really good one)

B) Get a new *OVERSIZED* power supply - at least 50 or 100 watts
bigger than the current one.

C) Get a new system. If neither A or B solve the problem, there isn't
really any other choice.
--
ArarghMail711 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

mr deo[_2_]
November 26th 07, 10:56 AM
> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
> disabled by writing data to the device?
>
> Thanks.
>

No..

Hardware fault.
Faulty Motherboard &/ Power Supply.

YANSWBVCG
November 26th 07, 12:59 PM
In alt.comp.hardware.amd.x86-64 Rod Pemberton > wrote:
>
> "YANSWBVCG" > wrote in message
> . ..
>> Today I discovered that a kvm switch I have just started using is
> defective.
>> The mouse port to the kvm switch no longer works although a mouse taken
>> from that port and plugged directly into the computer does work. The kvm
>> switch joins the list of new equipment going mysteriously bad within weeks
>> of being placed into service with the AMD64 computer which itself has run
>> flawlessly in 64-bit mode for over a year now.
>>
>
> Dave or YANSWBVCG,
>
> Okay, this thread has become a "mystery novel" and I'm getting bored with
> it. Each response seems to adds more information that wasn't mentioned
> earlier... Since it seems we are no closer to finding the issue, I'll
> "shotgun" some ideas for you:
>
> 1) The "hard errors" on the keyboards and mice suggest electrical problems
> to me (blown circuitry, flaky cable, pepsi, heavy handedness).
> 2) The loss of usb etc., implies electrical problems to me (power dropout),
> but could be software.
> 3) The "blown" KVM port implies electrical problems to me.
> 4) The locking of the cdrom drive is normal for Live-CD's if the OS has

I'm not using live cds.

> mounted the CD for access or install or swap file, etc.
> 5) The locking of the cdrom drive if not mounted, e.g., hardisk or floppy
> boot, suggests memory corruption to me.
> 6) The inability to access BIOS via delete key at boot could be a failure to
> detect the CPU (overheated, overclocked), CMOS corruption (wrong cpu or bus
> speed setting), or A20 issue (can't execute part of BIOS or video BIOS).
> Does the BIOS detect the CPU? If CPU, this implies an electrical or heat
> problem to me. If CMOS, this implies a software bug, like A20 being
> disabled.
>
> Completely unrelated questions, just in case there are multiple unrelated
> issues...:
>
> Is this a normal home computer, with a tower case?

Yes.

> Or, is it this
> "corporate?" If corporate, could it be sabotage, say from a vendor trying
> to sell you stuff? What about a vendor stealing or a coworker (different
> department) swapping bad stuff for the good "hardly used" stuff your
> department has (I've seen this happen...a few times.)? Do the serial
> numbers match what you bought? If a home PC, why the KVM switch?

I'm running more than one computer and I have very little space.

> Could the
> KVM switch be blowing stuff as you replace it? Is this system being
> overclocked (overheating, underpowered, "aged" circuitry from overclocking
> or poor ventilation)? Was it moved just recently to near a window (memory
> corruption from cosmic rays, solar rays, high energy particles, or
> background radiation)? What are the PS ratings? What are the 12V current
> rating(s) (underpowered)? Since it's an AMD, what are the 3.3V current
> rating (since AMD's need more current on the 3.3V line)? Was the PC
> recently "upset" by relocating, opening, dusting, vacuuming, etc. (loose
> cables, memory or cpu not set in socket or slot, ventilation esp. rack unit,
> static zapped)? Are you using RAID (hard disk failures)? Are you using
> Western Digital hard disks?

No.

> This link indicates that harddisk, raid, or memory errors occur far more
> often than detected:
> http://storagemojo.com/2007/09/19/cerns-data-corruption-research/
>
>
> Rod Pemberton

Thanks for all your ideas!
Dave Feustel