Globaler Keyboard-Hook gilt nicht wenn Admin-Prozess Fokus hat?

[Der schöne Günther]

Folgendes Szenario:

• Eine Kiosk-Anwendung läuft im Benutzerkontext (keine Adminrechte)
• Die Anwendung ist Vollbild, auch bei angeschlossener Tastatur soll der Benutzer nicht Standard Tastenkombos wie ALT+TAB usw verwenden können
• Dazu schiebt die Anwendung mittels SetWindowsHookEx(..) einen
  Delphi-Quellcode:

  WH_KEYBOARD_LL

  -Hook ins System

. Dieser Hook unterbindet die weitere Verarbeitung von unerwünschten Tasten wie Windows, ALT+TAB, ...

Das funktioniert super. Leider haben wir ein paar Systeme ausgeliefert welche unter Windows das "On Screen Keyboard" aufrufen können wenn man an den Bildschirmrand patscht. Und diese Bildschirmtastatur ist von Windows anscheinend "blessed", läuft also mit Adminrechten. Das Problem hierbei: Drückt man auf der Bildschirmtastatur ALT+TAB, wird das vom Keyboard-Hook nicht mehr abgefangen.

Was kann ich tun? Das automatische Aufrufen der Bildschirmtastatur unterbinden, klar. Aber ginge statt langwieriger Windows-Konfiguration nicht auch eine elegantere Code-Anpassung?

[Captnemo]

Ich kann zwar die Lösung nicht. Aber mir sind gleich mal 2 Gedanken durch den Kopf geschossen:

1. Wie schaut's den mit dem Hook aus, wenn du mal ein anderes Programm mit Adminrechten startest, und über die reale Tastatur bedienst? Geht das auch nicht?

2. Simuliert die Bildschirmtastatur wirklich Tastenanschläge? (Was ich meine, liegt es wirklich an den Adminrechten, oder laufen die Tastendrücke am Ende nur an dem Hook vorbei)

[BadenPower]

Wäre es eine Möglichkeit die ThreadId des virtuellen Tastatur-Prozesses zu ermitteln und diesen als 4.Parameter der SetWindowsHookEx-Funktion zu übergeben?

Ob das aber letzendlich funktioniert kann ich Dir nicht sagen und hab dies bislang auch noch nie getestet.


EDIT:

Die zwei Gedanken von Captnemo hatte ich auch.
Denn wenn man den Task-Manager startet laufen auch manche mit SetWindowsHookEx erstellten Hooks danach ins Leere.

[himitsu]

Dein Hook hat natürlich nur auf Prozesse Zugriff, die in seinem Kontext laufen, bzw. für die er die Rechte hat.

Als Admin ausgeführt würde er auch Zugriff auf die Adminprozesse haben.


PS: außerdem ist der Zugriff auf einen anderen Desktop sowieso gesperrt.
z.B. die Admin-Passwortabfrage (UAC) läuft in einem anderem Desktop, damit "böse" Programme (Keyboardlogging oder Eingabesimulation) keinen Zugriff darauf haben.

[CCRDude]

Womit himitsu ganz nebenbei schon eine wesentlich bessere Methode genannt hat. Ein neuer Desktop hat erstmal GAR nichts, nichtmal ne Explorer-Leiste.

Habe selber schon eine Anwendung geschrieben, die einen alternativen Desktop nutzt, und debuggen war äußerst nervig - bei gröberen Fehlern im switching kam ich gar nicht zurück und musste jeweils neustarten. Zwingt dann, mehr nachzudenken, also gar nicht verkehrt ;)

[Der schöne Günther]

Zitat:

Zitat von himitsu (Beitrag 1302461)

Dein Hook hat natürlich nur auf Prozesse Zugriff, die in seinem Kontext laufen, bzw. für die er die Rechte hat.

Das ist die vollkommen logische Erklärung dafür, ja. Aber hochoffiziell bei Microsoft habe ich das auf die Schnelle nicht gefunden. Liegt aber wohl an mir.

Und ja, wenn man es "richtig" macht, dann eigentlich gleich mit eigenem Desktop, aber das ist hier, aus verschiedenen Gründen, leider ausgeschlossen. Wir werden wohl an Windows-Einstellungen drehen müssen dass das OSK verschwindet.

Oder es aussitzen und hoffen dass es niemandem auffällt. So viele Systeme waren es nun auch wieder nicht :oops: