Zitat von
Arnulf:
also ich hab vor 10 jahren aufgehört zu programmieren
Autsch ...
Zitat von
Arnulf:
und da hatte man nur 2 register
und von multithreading gabs nur theorie - und zeitscheiben schon garnicht
*Uargs*
Methode 1 und (eine etwas abgewandelte) methode 2 haben einiges gemeinsam, denn den LoadLibrary-Befehl muss ja ebenfalls der "fremde" Prozess aufrufen. Und das geht mit "methode 2": Per VirtualAllocEx Speicher reservieren, per WriteProcessMemory den LoadLibrary Code "injezieren", und schliesslich per CreateRemoteThread aufrufen. D.h. "methode 1" ist also nur eine art "Erweiterung" von "methode 2".
Und wenn du für das quelltext haben willst, schau mal hier rein:
Meine DLL-Injection Lib (allerdings ist da noch ein kleiner, aber besch*** fehler drin, den ich demnächst mal ausbessern muss)
Zitat von
Arnulf:
Das würde aber auch vorraussetzen, daß der prozess noch garnicht läuft.
Exakt. Entweder oder, denn bei methode 1 und 2 muss der Prozess erst laufen ...
Zitat von
Arnulf:
Zitat:
Die Fake
DLL sollte allerdings nicht "sich selbst" finden, wenn sie nach der original
dll sucht
Damit meinst du umbenennen? - oder wenn die im verzeichnis des prozesses liegt, einfach den pfad mit angeben wo die originale liegt?
Damit meinte ich nur, dass die (fake)
DLL nicht versuchen sollte, ihre eigenen Funktionen wieder zu importieren, wobei ich glaube, dass da sowieso irgendwo ein Schutz dagegen im System vorhanden ist (z.B. man kein ein und die selbe library nicht 2x (im selben prozess) laden, am ende bleibt es doch nur eine ... oder?; nur was würde dann beim funktionsaufruf passieren?!? Eine rekursive Endlosschleife? TESTEN!
) ...
ciao, Philipp