Tastatur/Maus-Hook: Internet Explorer stürzt wegen DLL ab

[blackdrake]

Hallo.

Zitat:

Zitat von Apollonius

Wenn du eine DLL mit LoadLibrary lädst und die DllProc dieser DLL false zurückgibt (in Delphi wird das in System.pas über ExitCode geregelt), gibt LoadLibrary nil zurück. Wie sich das bei Hook-Dlls verhält (bedenke, dass jede Applikation ihre eigene DLL-Instanz hat!), weiß ich nicht, ich vermute aber mal, dass Windows dort pragmatisch vorgeht und die DLL nur in diesen Prozess nicht lädt.

Mh, ein bisschen Problematisch.

Ich habe folgendermaßen getestet:

Delphi-Quellcode:

if FileExists('C:\ary.txt') then ExitCode := 2;

InstallHook() wird durch die Host-Applikation zu Beginn 1 Mal aufgerufen. Anschließend wird der Hook gesetzt.

Das Problem: Wird dieser ExitCode nach dem Installieren der Hooks auf 2 gesetzt (durch die Anwesenheit der Datei ary.txt als eine Art "Signal"), dann interessiert Windows die LoadLibrary=False nicht. Der Hook wird trotzdem ausgeführt. Die Tastaturereignisse gehen weiterhin an die Host-Applikation.

Möglicherweise müsste ich innerhalb der Hook-Funktion in der DLL auf ExitCode != 0 prüfen. Wäre das sinnvoll?

Zitat:

Zitat von Apollonius

Bezüglich der Rechte: Ausschlaggebend sind die angegebenen Rechte bei OpenFileMapping. Du solltest dir in deinem Hauptprogramm Security Attributes erstellen, die allen Benutzern Lese-Zugriff erlaubt, und diesen dann als Parameter für CreateFileMapping angeben. Eine solche Struktur lässt sich sehr elegant mit der JWSCL erzeugen; direkt über die API ist es etwas schwieriger.

Das hört sich ja schon wieder so kompliziert an :pale: Außerdem kann ich bei meinem Turbo Delphi keine 3rd Party VCLs direkt installieren. Gibt es keine andere Möglichkeit?

@Sir Rufo: Wie machst du das mit MTANWT? Verwendest du JWSCL oder einen anderen API-Trick?

Gruß
blackdrake

[Sir Rufo]

Ich habe auf den ganzem Krams verzichtet und prüfe in der Haupt-EXE per Timer ab, ob die DLL noch sperrt :mrgreen: das ist simpel und robust.

[blackdrake]

Genau das mache ich doch auch. Die DLL frägt die Host-App per Message, ob der Mausklick OK ist oder nicht. Wurde mir ja auch empfohlen, weil eine Prüfung innerhalb der DLL nicht ressourcenschonend ist.

[Sir Rufo]

Falsch, bei mir sperrt die DLL und die Haupt-EXE fragt nur ab, ob die DLL noch sperrt, du machst das andersherum.

Zu den Ressourcen in der DLL: Da werde ich doch wohl noch zwei Cardinal-Werte vergleichen dürfen?

Die Aussage habe ich auch nie verstanden aber auch nie dementiert :mrgreen:

[blackdrake]

Das Problem bei der DLL-Internen Prüfung war ja, dass dann Timer innerhalb der DLL bei jedem Prozess anders wären. Ich finde das mit der Host-App im Endeffekt auch viel besser.


Weiß niemand, wie ich dieses Benutzerrechte-Hubbiflubbi beheben kann? Und ist es denn dann auch möglich, dass es dann mit Internet Explorer funktioniert? Ich verstehe einfach nicht, wieso der IE verbietet, dass ein Hook auf ein MemMap-File zuzugreift.

[Apollonius]

Die JWSCL ist keine Komponentensammlung, sondern eine Bibliothek. Diese müsstest du nur in das Hauptprogramm einbinden.
Zur Frage, warum der IE den Zugriff nicht erlaubt: In Vista gibt es sogenannte Integrity Labels. Prozesse mit einem niedrigen Integrity Label dürfen nicht auf Objekte mit einem höheren Label zugreifen. Der IE hat gewöhnlich ein IL von "niedrig", um zu verhindern, dass dein ganzer Rechner kompromittiert wird, wenn der IE einem Hack zum Opfer fällt. Dies halte ich für einen sinnvollen Schutzmechanismus, den du nebenbei bemerkt sicherlich abschalten kannst.
Bei CreateFileMapping hast du für die Security Attributes nil angegeben. Das führt dazu, dass ein Standard-Security-Descriptor gesetzt wird. Dieser hat nun das IL "normal". Daher kann Code aus dem IE nicht auf das MMF-Objekt zugreifen. Um das zu verhindern, musst du manuell einen Security Descriptor mit einem IL von "niedrig" erstellen. Eben dieses Erstellen vereinfacht die JWSCL erheblich, indem sie Security Descriptors als Objektinstanzen kapselt. Einen Blog zur JWSCL inklusive Downloadlink findest du hier.

[Sir Rufo]

Zitat:

Zitat von blackdrake

Das Problem bei der DLL-Internen Prüfung war ja, dass dann Timer innerhalb der DLL bei jedem Prozess anders wären. Ich finde das mit der Host-App im Endeffekt auch viel besser.

Wenn man Timer benutzt, dann mag das wohl stimmen, aber wer braucht dafür schon einen Timer :mrgreen:

[blackdrake]

Hallo

Apollonius, vielen Dank für die Ausführliche Beschreibung.

Ich habe nun versucht, JWSCL und JWAPI (was auch benötigt wird) einzubinden. Nachdem ich alle Pfade hingebogen habe, erhalte ich

[Pascal Fehler] JwsclToken.pas(4311): E2010 Inkompatible Typen: 'JwaWinNT.PSid' und 'JwsclSid.PSid'

Ich hoffe, dass meine EXE später noch auf eine CD passt, denn es scheint mir, als ob er versucht, alle 680 PAS Dateien einzubinden :lol:

[Apollonius]

Bist du dieser Anleitung gefolgt? Der Fehler sieht so aus, als versuchest du, Einzelunits und JwaWindows gleichzeitig zu nutzen.

[blackdrake]

Ich komm mir langsam wie ein DAU vor...

Mein Suchpfad ist gesetzt auf:

jedi_api22a_jwscl092a\jwapi2.2a\Win32API;
jedi_api22a_jwscl092a\jwapi2.2a\Common;
jedi_api22a_jwscl092a\jwscl0.9.2a\source

Und im Projekt habe ich wie in dem einen Example-Code folgende Units eingebunden:

Delphi-Quellcode:

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, ExtCtrls, ComCtrls, XPMan, Registry, ComObj, ShlObj,
  ActiveX, Menus, ImgList,

  JwaVista,
  jwaWindows,
  JwsclSecureObjects,
  JwsclDescriptor,
  JwsclMapping,
  JwsclAcl,
  JwsclTypes;

Und die Fehlermeldung kommt wieder.

Dabei habe ich die JWAPI vor der JWSCL deklariert.

Und im Blog steht ja nur "when you set JWAPI up, then just ..." - wie denn aufsetzen? Gibt es denn kein gescheites Schritt-für-Schritt Tutorial?