Zitat von
NicoDE:
Der Trick bei CreateRemoteThread besteht ja darin, dass die TThreadFunc aufrufkompatibel zu LoadLibrary ist.
Das heisst, dass Du per CreateRemoteThread einen Thread an der Adresse von LoadLibrary erzeugst und als 'Thread'-Parameter die Adresse des Dateinamens im entfernten Prozess angibst. Und das schöne darin ist, dass man anhand des ExitCodes des Threads (= Rückgabe von LoadLibrary) feststellen kann, ob das Laden erfolgreich war.
Das gleiche gilt für FreeLibrary.
Hmm ... ja, wäre eine überlegung wert, aber bei dieser Methode müsste ich mir ja dann zwangsweise das Modulehandle, das LoadLibrary zurückgibt merken, oder? Außerdem könnte ich doch (so wie es jetzt ist) z.B.
DLL's die ich nicht geladen habe, damit entladen, oder?
Hmm ... naja, wie auch immer, es war mal interessant soetwas zu programmieren ... ^^ ... und es ist ja nicht "falsch"
Zitat von
NicoDE:
ps: wie oben schon erwähnt, sollte man nicht versuchen aus einem 32-Bit Programm einen RemoteThread in einem 64-Bit Prozess zu erzeugen, da sich die LoadLibrary-Funktion dort an einer anderen Adresse befindet (man müsste also die Adresse aus der 64-Bit-Version der kernel32.dll auslesen - nicht sonderlich trivial).
Hmm ... ja ... bisher hab ich noch nicht viel mit 64-Bit systemen (oder auch mit deren prozessen) am hals, obwohl ich nen AMD64 hab ^^ (M$'s gratis testversion von xp64 hab ich schon, nur noch keine zeit gefunden es zu installieren ...)
BTW, wie kann ich herausfinden, ob ich einen 64-Bit Prozess vor mir hab?
Andere Frage, wie schauts da eigentlich bei .NET Programmen aus? Ich mein, die arbeiten doch nicht mehr mit
DLL's, oder?
ciao, Philipp