BlackBoard (http://www.black-board.net/index.php)
- Design, Programmierung & Entwicklung (http://www.black-board.net/board.php?boardid=55)
-- Programmieren (http://www.black-board.net/board.php?boardid=4)
--- tastatur sperren (http://www.black-board.net/thread.php?threadid=9362)


Geschrieben von scr!pTk!d am 26.12.2002 um 13:50:

  tastatur sperren

hi!

weiß irgendjmd welche speichersektoren im ram für tastatureingaben vorgesehen sind? (wenn man diese dauerhaft überschreibt, würde dadurch doch die komplette tastatur geperrt oder?)

mfg scr!pTk!d



Geschrieben von Lektor am 07.02.2003 um 02:14:

 

Also der Datentransport der Tastatur läuft über
das Interruptsystem. Das heist, wenn Daten von oder zu einem Speichermedium oder einer Schnittstelle transportiert werden müssen, muß der PC seine aktuelle Arbeit unterbrechen. Obwohl diese Unterbrechungen nur millionstel Sekunden betragen, ist man bemüht, solche Unterbrechungen auf ein Mindestmaß zu beschränken. So sollen zum Beispiel unnötige Wartepausen, die ein ständiges Überprüfen der Schnittstelle bzw. des Speichermediums erfordern würde, vermieden werden. Um das zu vermeiden, führt der Rechner nur dann Unterbrechungen ein, wenn auch wirklich Bedarf dafür besteht. Deshalb meldet die Controller-Karte dem Hauptprozessor eine Art Unterbrechungs-anforderung, einen Interrupt Request ( IRQ ) wenn ein solcher Bedarf besteht.

Jeder Kommunikationspartner eines PCs bekommt eine eigene Interrupt-Nummer. Für jede dieser Nummern gibt es im PC eine Signalleitung. Hierbei ist zu beachten, dass jedes in Frage kommende Teil eine eigene und freie Interrupt-Nummer hat bzw. bekommt. Gäbe es eine Doppel- belegung, so würden zwei unterschiedliche Erweiterungen oder Systemkomponenten auf die Anforderung reagieren, und es käme zu einer Art Kollision auf dem Datenbus, so dass keine der beiden Komponenten richtig funktionieren würde. Fordert eine Karte oder eine Baugruppe eine Unterbrechung ( Interrupt ) an, so erkennt der Prozessor anhand der Nummer, welche Komponente diese Unterbrechung angefordert hat.

Eine Reihe von Interrupt-Nummern sind im System bereits fest vergeben : Sie werden von unverzichtbaren Funktionsgruppen wie etwa Festplatte, Diskettenlaufwerk, Tastatur usw. genutzt. Andere Nummern sind frei geblieben und dürfen mit Hilfe von Treibern bzw. Jumpern auf den Karten an zusätzlich eingebaute Erweiterungen vergeben werden.

So weit ist uns das ja allen klar.
Jetzt liegt der Tastaturpuffer standartmäßig auf IRQ 1.
Die vom I/O-Bereich verwendeten Adressen sind im MS-DOS-Standart festgeschrieben.

Systeminterne Nutzung
0000h bis 00FFh

Diese I/O-Bereiche befinden sich bereits am Anfang des Hauptspeichers und umfassen meistens nur einige Bytes.

Windows benutzt meisten 0060-00064. (E/A-Bereich)
Wenn man jetzt ein treibervergleichbares Tool beim Systemstart mitstartet, was die selben Speicheradresssen, wie der Interrupt 01 belegt,
müßte es theoretisch zu einem Speicherkonflikt kommen oder scr!pTk!d(dy)?

Auf so eine Frage kann nur jemand mit Assembler-Programmierungserfahrung antworten, was Du genau weist. Also sollte der, der die Frage stellt, eine sehr hohe Assemblerprogrammiererfahrung haben, sonst seh ich das als Provo-Verarschung an. Also können wir beide uns ja auf nem dezenten Hex-Edit-Level unterhalten oder?

Grüßle

Lektor

_________________
Wrecking Crew



Geschrieben von Compuholic am 07.02.2003 um 16:36:

 

Lektor hat recht:

Normalerweise kann man so etwas nur erreichen indem man sich an einen Interrupt hängt. Wenn Du genaueres darüber wissen willst empfehle ich dir dokumentierte (DOS)Viren sourcecodes. Die benötigten nämlich um Dateien zu infizieren den allseits bekannten INT21-Hook mit dem der Virus die Request zum öffnen von Dateien abfangen konnte. Das aber nur so am Rande.

Win32 bietet dafür einige nette Funktionen wie z.B.
BlockInput(BOOL bBlock);

Wenn auch Strg+Alt+Entf blockiert werden soll, muß man zu einem kleinen Trick greifen. Man setzt den Systemparameter für den Bildschirmschoner so, das Windows glaubt, daß der Bildschrimschoner läuft. Dann wird Strg+Alt+Entf deaktiviert.

Zum blockieren:
SystemParametersInfo(SPI_SCREENSAVERRUNNING, TRUE, 1, 0);

Zum Aufheben der Blockierung:
SystemParametersInfo(SPI_SCREENSAVERRUNNING, FALSE, 1, 0);



Geschrieben von CDW am 07.02.2003 um 19:35:

 

Da muss ich jemanden enttäuschen *g*
Zitat:
- How can i restrict CTRL+ALT+DEL,ALT+TAB+CTRL+ESC keys ?

invoke SystemParametersInfo,SPI_SCREENSAVERRUNNING,1,NULL,NULL
; Windows98 only 1 disables 0 enables

<TOP>

das steht zwar nicht in der Microsoftdoku (da steht nur, dass dieser Befehl nur zu internen Zwecken benötigt wird)
Aber auf einer infoffiziellen Doku irgendwo auf meiner Platte. Überprüft hab ich das allerdings noch net.

Zitat:

Auf so eine Frage kann nur jemand mit Assembler-Programmierungserfahrung antworten, was Du genau weist. Also sollte der, der die Frage stellt, eine sehr hohe Assemblerprogrammiererfahrung haben, sonst seh ich das als Provo-Verarschung an. Also können wir beide uns ja auf nem dezenten Hex-Edit-Level unterhalten oder?


Lektor: woher willst du wissen, dass er das genau gewusst hat? Außerdem ist seine formulirung halb so wild...
Assemblerkenntnisse hin oder her, ring0 Zugriff unter win2k/XP zu bekommen (um die Interrupts zu blockieren) dürfte viel,viel Spass und Spannung bereiten *g*



Geschrieben von Compuholic am 08.02.2003 um 15:47:

 

@CDW: wo wild ist das nicht. Zumindest nicht, wenn man als Administrator angemeldet ist. Man lädt einfach einen kleinen Kernel-Mode-Treiber und schon hat man ring0 Zugriff.



Geschrieben von CDW am 08.02.2003 um 19:28:

 

@Compuholic: irgendwo hab ich ja auch einen (von Icz-Seite), aber ich würde es trotzdem mal gerne selber versuchen.
Außerdem muss man dann Ralfs Interrupt liste herauskramen und ich hab die nicht mal vollständig.Jedoch würden mich schon die ring0 experimente reizen (Die Abstürze,die man dann produziert *g*)



Geschrieben von scr!pTk!d am 12.02.2003 um 16:12:

 

@lektor: wie kommst du darauf, dass ich mich gut mit assembler auskenne? ich kenne damit überhauptnicht aus. warum sollte die frage denn deshalb eine "Provo-Verarschung" sein???


Forensoftware: Burning Board 2.3.6, entwickelt von WoltLab GmbH