In einem fremden Programm das Klickereignis eines Knopfes umbiegen
-
Alternativ "CreateRemoteThead"
oder eben einen globalen Hook mit dem Du eine DLL in jeden Prozess einschleussen kannst
-
Hmm, OK, danke für die Hilfe.
Muss mal schauen, wie das mit den Hooks so geht. Habe noch NULL Ahnung.
Aber irgendwie haben wir noch alles hingebracht.- Adrian
-
Jochen Kalmbach schrieb:
Alternativ "CreateRemoteThead"
nö, das geht nicht. eine windowproc braucht keinen zweiten thread
-
net schrieb:
Jochen Kalmbach schrieb:
Alternativ "CreateRemoteThead"
nö, das geht nicht. eine windowproc braucht keinen zweiten thread
Da hast Du wohl was falsch verstanden... ein Subclassing macht man (wie Du gesagt hast) mit SetWindowLong. Wie Du aber in den externen Prozess kommst ist ja was anderes. Da geht auch mit einem RemoteThread.
Das eine hat aber direkt mit dem anderen nichts zu tun.
-
Jochen Kalmbach schrieb:
Da hast Du wohl was falsch verstanden... ein Subclassing macht man (wie Du gesagt hast) mit SetWindowLong. Wie Du aber in den externen Prozess kommst ist ja was anderes.
er muss aber code in den prozess einschleusen und keinen zusätzlichen thread starten. CreateRemoteThread() fügt keinen zusätzlichen code ein, an der startadresse des threads muss sich schon was befinden. guckst du: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createremotethread.asp
Jochen Kalmbach schrieb:
Das eine hat aber direkt mit dem anderen nichts zu tun.
so ist es.
@Abader
mit VirtualAllocEx und WriteProcessMemory() haste noch 'ne möglichkeit code einzuimpfen
-
@Abader
mit VirtualAllocEx und WriteProcessMemory() haste noch 'ne möglichkeit code einzuimpfenJa, dann könnte ich auch gerade den Disassembler nehmen und einen HexEditor...
Ich denke, die Methode mit der DLL wäre einfacher?Ich bin eben noch nicht so der Hacker ...
Danke aber für die flotte Hilfe!
- Adrian
-
net schrieb:
er muss aber code in den prozess einschleusen und keinen zusätzlichen thread starten.
Du willst mich nicht verstehen... aber bevor wir hier uns über sinnlose Sachen Diskutieren hier mal ein konkreter Vorschlag:
Das einfachste ist ein globaler Hook mit "SetWindowsHookEx" mit "WH_MSGFILTER" oder "WH_CALLWNDPROC"...
Oder du machst diesen obigen Hook nur um die DLL reinzubekommen und beim ersten Aufruf des Hookst machst Du ein Subclassing mit "SetWindowLong" mit "GWL_WNDPROC"Beispiele für globale Hooks und Subclassing gibt es genügend auf Codeproject...
-
Jochen Kalmbach schrieb:
net schrieb:
er muss aber code in den prozess einschleusen und keinen zusätzlichen thread starten.
Du willst mich nicht verstehen...
kann ich irgendwie nicht. bin schon der verzweiflung nahe. mit CreateRemoteThread() kann ich in dem zusammanhang irgendwie garnix anfangen.
-
Naja:
1. Daten bzw. Code in den anderen Prozess schreiben (also wie schon erwähnt wurde mit VirtualAllocEx und WriteProcessMemory)
2. Diese Code sollte natürlich den Code für ein Subclassing und sonstige aktionen enthalten
3. CreateRemoteThread aufrufen
4. Fertig.Aber ist etwas umständlich und ich würde nicht zu diesem Weg Raten.
-
Jochen Kalmbach schrieb:
Naja:
1. Daten bzw. Code in den anderen Prozess schreiben (also wie schon erwähnt wurde mit VirtualAllocEx und WriteProcessMemory)
2. Diese Code sollte natürlich den Code für ein Subclassing und sonstige aktionen enthalten
3. CreateRemoteThread aufrufen
4. Fertig.das ist wenigstens eine erklärung. dir muss man auch jedes wort aus der nase ziehen *grins*
Jochen Kalmbach schrieb:
Aber ist etwas umständlich und ich würde nicht zu diesem Weg Raten.
stimmt. das mit der dll ist eindeutig besser. bei DLL_PROCESS_ATTACH die änderungen machen...braucht keinen extra thread.
-
Und so wie ichs verstehe bringt man das zu Patchende Programm auch ohne EXE-Hack dazu, die DLL zu laden, eben mit dem Hook, richtig?
Naja, sooo einfach ist es eben schon nicht. Aber man hat ja über das Neujahr *vielleicht* etwas Zeit
Danke für Eure wertvollen Hinweise!- Adrian
-
net schrieb:
stimmt. das mit der dll ist eindeutig besser. bei DLL_PROCESS_ATTACH die änderungen machen...braucht keinen extra thread.
Das ist aber nicht erlaubt, da die SetWindowLong sich in user32.dll befindet!
Und da es ja ein globaler Hook ist betrifft es auch andere Prozesse u.a. auch neue und da kann dies zu massiven Problemen führen!Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose.
Siehe: DllMain: http://msdn.microsoft.com/library/en-us/dllproc/base/dllmain.asp
Add: Deshalb mein Hinweis das SetWindowLong erst in dem ersten Aufruf des Hooks zu machen
-
Jochen Kalmbach schrieb:
net schrieb:
stimmt. das mit der dll ist eindeutig besser. bei DLL_PROCESS_ATTACH die änderungen machen...braucht keinen extra thread.
Das ist aber nicht erlaubt, da die SetWindowLong sich in user32.dll befindet!
na, immer diese fallstricke. nun meint man fast 'dann rufe ich zuerst LoadLibrary auf um user.dll zu laden' aber das kann auch böse crashen. eine thread zu starten, der wartet bis sich die anwendung initialisiert hat, und der dann die wndproc umbiegt könnte auch abschmieren wenn er sich mit dem window-thread ins gehege kommt. man sollte vielleicht einen weg finden, dass sich der window-thread selber die wndproc umbiegt...
-
Der Weg den Jochen Kalmbach beschrieben hat per CreateRemoteThread ist der standard weg und auch der beste. Einziges manko ist daß es CreateRemoteThread nicht unter Win9x gibt, aber wen stört das heute noch gross.
und net du spielst dich aber ganz schön auf dafür daß du vom Thema nicht viel Ahnung hast.
-
zerotolerance schrieb:
und net du spielst dich aber ganz schön auf dafür daß du vom Thema nicht viel Ahnung hast.
so bin ich nun mal....