Welche Möglichkeiten gibt es denn ein fremdes Programm so zu patchen, daß bestimmte Funktionen, die das Programm aus einer externen DLL aufruft, zu ändern bzw. zu deaktivieren. Ich fand bislang keine "leere" Funktion. Auch die korrekte Beibehaltung der Stackposition, also Eliminierung der Aufrufparameter ist schwierig. Gibts da nette Tricks? Bzw. welche Tools sind empfehlenswert? Danke!
Abdul K. schrieb: > Welche Möglichkeiten gibt es denn ein fremdes Programm so zu > patchen, daß bestimmte Funktionen, die das Programm aus einer externen > DLL aufruft, zu ändern bzw. zu deaktivieren. Ich fand bislang keine > "leere" Funktion. Auch die korrekte Beibehaltung der Stackposition, also > Eliminierung der Aufrufparameter ist schwierig. Gibts da nette Tricks? Zwischenschalten einer DLL die alle Funktionen weiterreicht bis auf die abzufangenden. Unter gleichem Namen früher im Pfad gefunden.
Kommt halt auf die verwendete Schnittstelle zur DLL an. Wenn die DLL Funktionen als Exports zur Verfügung stellt (am besten in C-Linkage), dann ist's relativ einfach, komplizierter wirds bei C++-Linkage (wegen des "name mangling") und endgültig komplex wird es, wenn die DLL via (D)COM, d.h. per Automation angesteuert wird, wie es in Vorformen auch OLE und ActiveX-Objekte machten. Allerdings kann auch die simpelste Variante schon tricky werden, wenn nämlich die DLL nur numerierte Exporte zur Verfügung stellt, und keine benannten. Was die DLL anbietet, kann man bei installiertem Visual Studio o.ä. mit dem Kommandozeilentool "dumpbin" und dem Parameter /exports herausfinden, also
1 | dumpbin /exports meinetolle.dll |
Abdul K. schrieb: > elche Möglichkeiten gibt es denn ein fremdes Programm so zu patchen, > daß bestimmte Funktionen, die das Programm aus einer externen DLL > aufruft, zu ändern bzw. zu deaktivieren. früher (tm) hab ich das immer so gemacht: programm im w32dasm geladen. zu patchende stelle/funktionsaufruf gesucht (zb über referenzierte Strings) lokal den Code nachvollzogen und relevante (conditional) jmps oder calls nachvollzogen. Dann die Adresse der relevanten stelle vermerkt. Progrmm im "hiew" geöffnet, zu der stelle geprungen und diese ausge-NOP-t, oder den conditional in einen unconditional jmp gedreht. geht heut wahrcheinlich ähnlich, nur die Tool werden unter 64bit Windows eventuell nicht mehr laufen. w32dasm konnte ich spontan auf jeden Fall nicht mehr starten.
:
Bearbeitet durch User
Vlad T. schrieb: > w32dasm konnte ich spontan auf jeden Fall nicht mehr starten. Ja, w32dasm ist nur für 16 und 32 Bit gedacht und wird schon seit Ewigkeiten nicht mehr weiterentwickelt. Vielleicht finden sich hier Alternativen: https://en.wikibooks.org/wiki/X86_Disassembly/Disassemblers_and_Decompilers
Georg Grünhut schrieb: > Ja, w32dasm ist nur für 16 und 32 Bit gedacht und wird schon seit Naja, das is ne 32bit Anwendung. Das alleine ist also kein Grund, warum es unter win7 64 nicht laufen sollte
Vlad T. schrieb: > Das alleine ist also kein Grund, warum es unter win7 64 nicht laufen > sollte Sicher, aber kann es 64-Bit-Code disassemblieren?
Ohne Vorkenntnisse ist das nicht so ganz einfach. Aber dennoch: Wenn es eine 32Bit Anwendung ist, benutzt man am besten OllyDbg. Adresse der DLL-Funktion ermitteln, den Assemblercode der Funktion entsprechend ändern (Rücksprung o.ä), abspeichern, fertig.
Danke für die Stichworte. Ich habe sowas schon auf dem Mac vor 30 Jahren gemacht, möchte allerdings nicht unnötig tief in die Win-Programmierwelt einsteigen. Also nur so weit rein wie gerade nötig. Da werde ich mal die erwähnten Tools ansehen. Hatte ich schonmal erwähnt, daß ich auf dem Mac per Hand binäre Allocationtables des Dateisystems repariert habe? Man was man alles schafft, wenn man jung ist und nächtelang an der Kiste sitzt. Aber das ist vorbei. Noch ne konkrete Frage: Wie heißt ein "NOP" Funktionsaufruf? Z.B. wenn ich ne Funktion einer untergeordneten DLL ausschalten möchte. Anscheinend kann man die Namen der Funktionen ändern und der Rest geht automatisch. Aber wie heißt eben die leere Funktion, die nichts bewirkt? Sorry, wenn ich die falschen Win-Programmierer Begriffe verwende. Deswegen kann ich ja auch schlecht selbst erfolgreich danach googeln...
Abdul K. schrieb: > Wie heißt ein "NOP" Funktionsaufruf? "No Operation", ist aber keine Funktion sondern ziemlich Low-Level; Assembler. Gruss Chregu
In der EXE ist ja ne Importtabelle der Funktionen, die von anderen DLLs entliehen werden. Da soll dann anstatt eines echten bisherigen Funktionsnamen eben sozusagen NOP sein. Da man in dieser Tabelle keine Funktionsparameter oder Rückwerte ändern kann, ist das nicht direkt mit Assembler-NOP vergleichbar. NOPs kann man dann in den eigentlichen Funktionsaufruf reinpatchen, also wenn z.B. ein PUSH xy vor dem CALL steht, dann dort eben NOP passend einarbeiten. Damit habe ich auch kein Problem. Funzt wie es soll. Wenn die Funktion mehrfach im Programmcode aufgerufen wird, dann müßte man alle Stellen finden und den CALL durch NOPs ersetzen. Einfacher wärs aber, man könnte nur diese eine Stelle in der Importtabelle ändern in eine leere Funktion.
Abdul K. schrieb: > Wie heißt ein "NOP" Funktionsaufruf? Den Funktionsaufruf auszunopen wird selten reichen, z.B. weil die Funktion Werte zurückliefert. Unter Windows sehr häufig einen Fehlercode, den ein ordentlicher Programmierer auch abfragt. Und davon gibt es abertausende. Von den Fehlercodes, nicht von den ordentlichen Programmierern. Georg
Abdul K. schrieb: > In der EXE ist ja ne Importtabelle der Funktionen, die von anderen DLLs > entliehen werden. Das kann so sein, aber das muss nicht so sein. Verwendet wird das beim "quasistatischen" Linken der DLL beim Programmstart durch den Programmlader. Fehlt die DLL, oder kann einer der Importe nicht aufgelöst, kann das Programm nicht gestartet werden und der Programmlader gibt eine entsprechende Fehlermeldung aus ("Funktionseinsprungspunkt blafusel nicht gefunden" oder "DLL sülzblubber nicht gefunden"). DLLs können aber auch zur Laufzeit geladen werden (mit LoadModule und GetProcAddress), dann gibt es keine Importtabelle. Und wenn DLLs Automationsserver sind (d.h. über COM angesprochen werden), dann gibt es ebensowenig eine Importtabelle.
In dem Programm ist es so, also die Importtabelle ist vorhanden ;-) Den Namen möchte ich nicht verraten, da der Programmierer eventuell sauer wird.
Ohne weitere Infos wird es schwer zu helfen. Darf denn die DLL selbst gepacht werden? Man kann natürlich die RVAs in der EXE auf eigenen Code umleiten, aber man sollte halt wissen, was gePUSHt ond gePOPt wird.
Es werden DLLs vom Win BS aufgerufen. Daher möchte ich die ungern ändern. Ein Test in Richtung MaWins Idee ging schief. Eine neuere user.dll einfach in den Programmordner gelegt, wurde offensichtlich nicht benutzt.
Die user.dll könnte eine "knowndll" sein die niemals im Anwendungspfad gesucht wird. Kannst du das Programm umpatchen so das die usel.dll gesucht wird?
Ich denke ein praktikabler Weg wäre die Import-Tabelle in der EXE zu modifizieren. Wenn die gewünschte Funktion nicht zu oft aufgerufen wird, kann man auch alle Calls auf die DLL-Funktion auf eine eigene Routine umJumpen. Beispiel mit Olly: EXE öffnen Menü view -> executable modules Rechtsklick auf die exe (in der Regel an 00400000) und "View names" aus dem Kontextmenü wählen Im neuen Fenster werden jetzt alle Import/Export Funktionen angezeigt Rechtsklick auf die gewünschte Funktion und und "Find references to import" aus dem Kontextmenü auswählen Im neuen Fenster werden jetzt alle Adressen angezeigt an der die Funktion aufgerufen wird. Alle Calls in "JMP Patch" abändern (Patch muss natürlich erstellt werden)
Zum Abschluss meinerseits möchte ich noch den Begriff "Function Hooking" nennen. Hier gibt es ein kleines Tutorial xxx.moddb.com/tutorials/function-hooking
Danke erstmal. Schaue ich mir alles an.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.