Hooking & DLL-Injection

  • Die Aufgabe ist im Menü einer bestehenden Win-Prog einen Eintrag zu ändern, bzw. mit neuer Funktionalität zu versehen, oder auch eine zusätzlichen Menüpunkt für erweiterte Funktionalität zu implementieren.

    Dazu hatte ich gelesen, dass das ggf. mit den AutoIt-UDFs:

    - _WinAPI_SetWindowsHookEx,

    - _WinAPI_CallNextHookEx,

    - _WinAPI_UnhookWindowsHookEx

    (und ggf. noch andere) gehen soll.

    Die diesbezüglichen Hilfe-Beispiele erschließen sich mir nicht wirklich, da sie kaum kommentiert sind.

    Es soll aber auch noch andere Methoden geben ...

    Hat sich schon mal jemand mit dieser - zugegebenermaßen komplizierten - Thematik befasst und wenn ja, mit welchem Ergebnis?


    Grüsse aus Berlin

    PSblnkd

    • Offizieller Beitrag

    Das ist vorrangig ein rechtliches Problem. Die meisten Softwarelizenzen gestatten die Nutzung "as is". Du darfst keine Änderungen vornehmen. Einzige Ausnahmen stellen quelloffene Programme dar.

    Was m. E. möglich ist, da nicht in das Programm eingegriffen wird, sind Overlay Buttons/Menüs.

    Mit den von dir genannten Funktionen kann man durchaus auch direkt in den Programmablauf eingreifen. Aus vorab angeführten Gründen ist dies aber kaum mit Bsp. unterlegt. Es würde auch gegen unsere Forenregeln verstoßen und wird somit nicht supportet.

  • BugFix

    Danke für Deine Hinweise.

    Soweit ich das verstanden habe, betrifft "Änderungen vornehmen" das Eingreifen in die exe-Programmdatei, wie etwa das "Patchen" von einzelnen Bytes, um z.B. einen Passwortschutz o.ä. "auszuhebeln". Das ist hier aber nicht meine Absicht!

    Es soll hier lediglich der durch Windows vorgegebene Programmablauf geändert werden.

    Auch in Windows selbst kann durch DLL-Injection Zusätzliches oder - leider auch - Gegensätzliches bewirkt werden. Beispielweise kommt im Kontextmenü des Win-Explorers ein zusätzlicher Menüpunkt, wenn das Packerprogramm "winzip" oder "7-zip" installiert wurde.

    Wenn das nicht erlaubt wäre, gäbe es auch nicht die diesbezüglichen WinAPI-Funktionen.

    Was ich nicht verstehe - die AutoIt-UDF _WinAPI_SetWindowsHookEx hat nichts mit der gleichnamigen WinAPI-Funktion zu tun, d.h. sie basiert nicht auf deren Grundlage. Bisher war ich immmer noch der Ansicht, dass die UDFs des "WinAPI Management" einen Teil der in AutoIt umgesetzten WinAPI-Funktionen sind.

    Im englichen Forum gibt es haufenweise Hinweise zu _WinAPI_SetWindowsHookEx:

    https://www.autoitscript.com/forum/search/?…ortby=relevancy

    Wenn sich hier im deutschen Sprachraum noch niemand damit befasst hat, werde ich mich wohl oder übel durch den englischen Wust wühlen müssen ...

    Grüsse aus Berlin

    PSblnkd

    • Offizieller Beitrag

    Wenn du z.B. zusätzliche Menüpunkte in eine Software durch Hooking integrierst, verwendest du die Software nicht mehr bestimmungsgemäß. Der Autor hat für seine Software ein bestimmtes Verhalten und Aussehen bestimmt. Da darf man nicht ohne Weiteres dran basteln. Ich handhabe das so, dass eine extra Software läuft und wenn ein bestimmtes Menü der Warenwirtschaftssoftware geöffnet wird, blende ich ein Fenster ein mit zusätzlichen Optionen.

    Auch in Windows selbst kann durch DLL-Injection Zusätzliches oder - leider auch - Gegensätzliches bewirkt werden. Beispielweise kommt im Kontextmenü des Win-Explorers ein zusätzlicher Menüpunkt, wenn das Packerprogramm "winzip" oder "7-zip" installiert wurde.

    Wenn das nicht erlaubt wäre, gäbe es auch nicht die diesbezüglichen WinAPI-Funktionen.

    Einträge für Kontextmenüs werden in die Registry geschrieben, das hat nullkommanix mit Injection zu tun.


    Was ich nicht verstehe - die AutoIt-UDF _WinAPI_SetWindowsHookEx hat nichts mit der gleichnamigen WinAPI-Funktion zu tun, d.h. sie basiert nicht auf deren Grundlage. Bisher war ich immmer noch der Ansicht, dass die UDFs des "WinAPI Management" einen Teil der in AutoIt umgesetzten WinAPI-Funktionen sind.

    Mit der Meinung bist du aber ganz alleine. Mal in die Includes geguckt? :whistling:

    Zitat von Includes: WinAPISys

    Func _WinAPI_SetWindowsHookEx($iHook, $pProc, $hDll, $iThreadId = 0)

    Local $aResult = DllCall("user32.dll", "handle", "SetWindowsHookEx", "int", $iHook, "ptr", $pProc, "handle", $hDll, _

    "dword", $iThreadId)


    Wenn sich hier im deutschen Sprachraum noch niemand damit befasst hat, werde ich mich wohl oder übel durch den englischen Wust wühlen müssen ...

    Benutze mal die Erweiterte Forumssuche, Suchwort "Hook" - 216 Treffer.

  • Prinzipiell kann ich dir bei deinem Vorhaben helfen. Allerdings müsstest du dafür erst einmal konkret beschreiben was du machen möchtest.

    Zitat

    Wenn du z.B. zusätzliche Menüpunkte in eine Software durch Hooking integrierst, verwendest du die Software nicht mehr bestimmungsgemäß. Der Autor hat für seine Software ein bestimmtes Verhalten und Aussehen bestimmt. Da darf man nicht ohne Weiteres dran basteln.

    Das kommt darauf an um was für eine Software es sich handelt und welche Lizenzen damit verbunden sind. Zudem darfst du für die reine Weiterbildung so ziemlich vieles machen. Aber das ist eine andere Geschichte. Lassen wir Ihn doch erst mal erklären was sein genaues Vorhaben ist, dann können wir ja immernoch feststellen auf welchen Zweig wir uns bewegen.

    Zitat

    Hat sich schon mal jemand mit dieser - zugegebenermaßen komplizierten - Thematik befasst und wenn ja, mit welchem Ergebnis?

    Ja, hab ich. Sehr umfangreich sogar. Ich bin in der Lage vorhandene Software so anzupassen wie es mir gefällt. Das sollte als Einschätzung reichen. Wenn dich das Themengebiet einfach nur interessiert kann ich dir anbieten Software zur Verfügung zu stellen je nach Bedarf. Oder schreib dir eigene kleine Programme wo du dran rumspielst.

    Einmal editiert, zuletzt von Yjuq (21. März 2020 um 13:17)

  • BugFix am Freitag

    Betr. "die AutoIt-UDF _WinAPI_SetWindowsHookEx hat nichts mit der gleichnamigen WinAPI-Funktion zu tun" - da hast Du natürlich Recht! - Hier muss ich meine Aussage korrigieren. Mir war nicht geläufig, dass die WinAPI-Funktion in der user32.dll enthalten ist und diese über die UDF referenziert wird. - Wieder was dazu gelernt - Danke! -

    Und danke auch für den Hinweis zum Suchwort "Hook" im deutschen AutoIt-Forum - da gibt es tatsächlich eine ganze Menge, wobei Vieles nicht mein Problem betrifft - "Fremde GUIs und Controls". Aber auch dazu bin ich fündig geworden:

    RE: Fremde GUIs und Controls?

    d.h. das ist jedenfalls schon mal ein Ansatz ...

    Von Dir habe ich auch ein Code-Beispiel (leider nicht mehr die Quelle) vom 30.07.2014: "WM_Message Hook". Auch davon habe ich einige Infos erhalten.

    "Hooking & DLL-Injection" von "arcker" https://www.autoitscript.com/forum/topic/87…njecting-a-dll/ scheint vielleicht das Richtige zu sein - muss ich aber noch durcharbeiten.

    Bin dabei mir selbst ein Bild zu machen ... wie bei http://www.ps-blnkd.de/Control_Events_AutoIt.pdf.

    @Yjug am Samstag

    Danke für Deine Hilfsbereitschaft! - Die ist mir sehr willkommen.

    Vielleicht hast Du ja Interesse an dem Projekt mitzuarbeiten:

    http://www.ps-blnkd.de/Seite3.htm - Bereich "Bücher - CDs (2): PS-Buch "SDK-TurboCAD™ - ein Tutorial (Teil 2)".

    Es werden dringend Co-Autoren gesucht ...

    Ein weiteres Problem wäre die Erweiterung des SciTE-Editors (IDE) mit der Funktionalität "STEP" u.ä. - so, wie es bei der VBA-IDE üblich ist. Der separate AutoIt-Debugger läuft bei mir leider nicht ... und ich bin es leid immer mit unzähligen MsgBoxen zu arbeiten.

    Grüsse aus Berlin

    PSblnkd

    • Offizieller Beitrag

    Ein weiteres Problem wäre die Erweiterung des SciTE-Editors (IDE) mit der Funktionalität "STEP" u.ä. - so, wie es bei der VBA-IDE üblich ist. Der separate AutoIt-Debugger läuft bei mir leider nicht ... und ich bin es leid immer mit unzähligen MsgBoxen zu arbeiten.

    Was ist STEP? Ich habe schon unzählige AddOns für SciTE erstellt (nimmt ein eigenes Unterforum ein). Wenn es lösbar ist wirds auch gelöst.

    Beschreibe mal das genaue Verhalten in allen Einzelschritten (Taste drücken, Taste lösen, Aktion-vor-Speichern, etc.)

  • BugFix vom 23.03.2020

    "STEP" ist der Schrittbetrieb im Debuggermodus. In der VBA-IDE kann man dann im Lokalfenster die einzelnen Variablen - auch Objekt-Variablen - beobachten.

    Anbei ein ScreenShot. Die gelb markierte Zeile ist die aktuelle. Außer dem Einzelschritt gibt es im Debuggermodus auch noch "Prozedurschritt", "Prozedur abschließen", "Ausführen bis Cursorposition", "Überwachung hinzufügen", Überwachung bearbeiten", Aktuellen Wert anzeigen", Haltepunkt ein/aus", "Alle Haltepunkte löschen", "Nächste Anweisung festlegen" und "Nächste Anweisung anzeigen".

    Grüsse aus Berlin - und bleibt gesund!

    PSblnkd

    • Offizieller Beitrag

    Das ist für eine Interpretersprache nicht realisierbar. Es gibt Ansätze, da wird das Skript übersetzt in ein Laufzeitskript (z. B. alle Schleifendurchläufe werden als einzelne Befehlszeilen mit jeweiligen Werten in das Skript geschrieben).

    Kann ich mich nicht mit anfreunden.

    Es ist also kein Problem der IDE, sondern ein Problem der Spracharchitektur.

  • Das ist für eine Interpretersprache nicht realisierbar.

    Na klar ist das realisierbar. Siehe AutoIt Debugger (den hat sogar PSblnkd angesprochen). Darüber, dass das alles andere als perfomant ist, brauchen wir uns aber glaube ich nicht zu streiten.

    Das wäre übrigens auch ein Killer-Plugin was Professor Bernd vielleicht selbstgebastelt in sein PSPad4AutoIt-Projekt einbauen möchte :^)

    • Offizieller Beitrag

    Na klar ist das realisierbar. Siehe AutoIt Debugger

    Das habe ich ja angesprochen, wie sinnfrei das Teil ist.

    Im reinen Interpreter ist live Debuggen nicht möglich. Erst muss der Code insgesamt interpretiert werden, um Wert für Wert Ausgabe, wie bei einem Hochsprachen Debugger zu erhalten.

    Das hat nichts mit Schritt für Schritt zu tun - auch wenn die Ausgabe es vorgaukelt.

  • Das ist für eine Interpretersprache nicht realisierbar.

    Na, da muss ich aber mal kurz widersprechen. Warum sollte das nicht realisierbar sein? Das ist jetzt zwar ein bisschen OT, aber grundsätzlich ist das natürlich möglich. Eine Interpretersprache geht ja im Endeffekt das Programm auch nur Schritt für Schritt durch, genau wie ein Hardware-Prozessor den Maschinencode. Und auch eine Interpretersprache könnte nach jedem Schritt den aktuellen Status des Programmes (Speicherinhalt, Program Counter usw.) zur Verfügung stellen, sodass man ihn mit einer interaktiven Befehlszeile (Debugger) auswerten kann. AutoIt kann das nicht, da hast du völlig recht. Aber die Spracharchitektur im Sinne einer Interpretersprache ist nicht der technische Grund dafür.

    Man müsste vielleicht mal in den Sourcecode der letzten Open Source AutoIt-Version gucken. Wenn wir uns mal kurz auf die reine technische Realisierbarkeit beschränken und jegliche juristischen/lizenzrechtlichen Hindernisse ignorieren... Soweit ich weiß, wird in den meisten Interpretersprachen auch eine Art Baumstruktur des Skriptes erzeugt, ähnlich wie beim Kompilieren bei einer Compiler-Sprache (Google-Stichwörter Lex und Yacc). In dieser Baumstruktur wird das komplette Skript in sogenannte Ausdrücke zerlegt. Zur Auswertung dieser Ausdrücke wird es eine einzelne Funktion innerhalb des AutoIt-Interpreters geben. Wenn man diese Funktion ausfindig machen kann und (meinetwegen auch live während der Ausführung) so modifiziert, dass diese unmittelbar vor dem Return eine von uns geschriebene Blockier-Funktion aufruft... Dann haben wir eigentlich schon eine schrittweise Ausführung hinbekommen.

    Man korrigiere mich, wenn ich falsch liege oder was übersehen habe.

    Ich möchte aber nochmal darauf hinweisen, dass das rein theoretische Überlegungen sind. Außer, irgendwer holt eine offizielle Erlaubnis des Rechteinhabers ein.

  • (So'n Mist - das hatte ich gestern schon geschrieben, war aber irgendwie nicht abgesendet ...)

    chesstiger

    Da kann ich Dir im Wesentlichen beipflichten.

    In "Debugger für AutoIt3 - sinnfrei oder sinnvoll?" hatte ich mein Statement zum AutoIt-Debugger dargelegt.

    BugFix

    Im Schrittbetrieb o.g. VBA-IDE wird m.E. jede Zeile einzeln interpretiert und die dazu gehörenden Ausgaben gemacht - natürlich in Abhängigkeit weiter oben liegenden Zeilen. Variable, die erst weiter unten vorkommen, sind (nach Deklaration) natürlich (noch) leer.

    Bei Schleifen kann man mittels Haltepunkt am Anfang oder Ende der Schleife sehr schön die Werte-Entwicklung der Variablen - auch von Objekt-Variablen beobachten. Das kann weder eine Consolen-Ausgabe noch MsgBoxen ...

    Aber jetzt muss ich mich wieder dem eigentlichen Thema zuwenden ... Hooking & DLL-Injection.

    Sollte es neue Erkenntnisse geben ... gibt's neue Postings ...

    Edit:

    Die ersten Erkenntnisse: - So einfach ist das wirklich nicht!

    Bisher ist es mir noch nicht gelungen - außer das Bsp. von Fremde GUIs und Controls? nach zu vollziehen - einen "Hook" auf ein Control einer fremden GUI hin zu bekommen. Die Quelle https://www.autoitscript.com/forum/topic/87…njecting-a-dll/ ist sehr kompliziert und für mich schwer zu verstehen - da wäre eine IDE mit integriertem Debugger wirklich sehr hilfreich!

    Wir werden sehen ...


    Grüsse aus Berlin

    PSblnkd

    Einmal editiert, zuletzt von PSblnkd (26. März 2020 um 10:41)

  • Mal abgesehen vom Screenshot. Wie, kein Debugger für VBA? Der ist doch in den MS Produkten drin. Hast du den noch nie etwa in Access gesehen Professor Bernd? Unter Visual Basic findest du Debugger und dort gibt es dann auch die Funktion "Einzelschritt".

    Grüße autoiter