[Suche] DLL Injector für Win7

[Ende!]

Originally Posted by rEdoX

Wie kommst du darauf? Habe autoit zwar noch nie angeruehrt, aber ein blick in die Docs brachte mich zu der Funktion .

Achso Edith meinte gerade noch, dass sie hier noch mehr Quatsch gelesen haette.



Woher nimmst du diese Informationen? Ein OpenProcess mit PROCESS_ALL_ACCESS (!) und liefert mir bei notepad ein gueltiges handle zurueck. _OHNE_ Adminrechte.

Wie willst du denn mit einer Skriptsprache (wie AutoIT) Code basteln, den du dann in den Zielprozess injectest und der dann die DLL lädt?

[rEdoX]

Shellcode?

[Ende!]

Originally Posted by rEdoX

Shellcode?

Ok, hast recht, an Shellcode hab ich jetzt nicht gedacht. Aber dafür muss er ja erstmal Assembler können oder sich von iwo einen passenden holen.

EDIT:
@Threadstarter: Blockiert dein AV Programm vll DLL Injections? Hatte ich nämlich mal bei Kaspersky, kein Injector ging xD

[rEdoX]

Wo ich's gerade lese, du braucht ueberhaupt keinen code injezieren LoadLibrary braucht nur einen Parameter, also kannst du es ueber CreateRemoteThread machen ohne Codecave. Gibt noch andere Wege, aber das ist der "einfachste".

[HardCore.1337]

ne, mein AV hab ich extra mal ausgeschaltet

€ Geht jetzt (zumindest bei CS:S)

[Ende!]

Originally Posted by rEdoX

Wo ich's gerade lese, du braucht ueberhaupt keinen code injezieren LoadLibrary braucht nur einen Parameter, also kannst du es ueber CreateRemoteThread machen ohne Codecave. Gibt noch andere Wege, aber das ist der "einfachste".

Hmm .. da bin ich noch gar nicht drauf gekommen. Danke für den Tipp ^^

[MrSm!th]

Originally Posted by rEdoX

Wie kommst du darauf? Habe autoit zwar noch nie angeruehrt, aber ein blick in die Docs brachte mich zu der Funktion .

Achso Edith meinte gerade noch, dass sie hier noch mehr Quatsch gelesen haette.



Woher nimmst du diese Informationen? Ein OpenProcess mit PROCESS_ALL_ACCESS (!) und liefert mir bei notepad ein gueltiges handle zurueck. _OHNE_ Adminrechte.

1. LOL? ich nicht Man ey, meine Trainer und sonstiges kriegen auf Vista nur einen Handle mit Adminrechten und auf XP gar nicht, da gibts nur Error6^^
2. CE,meine Trainer und kikis UCE können alle kein Solitär öffnen und Winject liefert einen Fehler (error 5 = Kein Zugriff) beim Injecten in notepad.
Daher nehme ich die Info...

[Akorn]

Originally Posted by Ende!

Ok, hast recht, an Shellcode hab ich jetzt nicht gedacht. Aber dafür muss er ja erstmal Assembler können oder sich von iwo einen passenden holen.

Um shellcode zu erzeugen muss man kein Assembler können. Man kann shellcode auch in anderen programmiersprachen machen.
Wo man Assembler für shellcode braucht ist wen man shellcode für Bufferoverflow exploits schreibt weil man nur mit assembler den code so optimieren kann das er z.b. keine null bytes enthalt was für einen solchen verwendungszweck wichtig ist.

Genaugenommen beantwortet das ja nicht wirklich seine frage. Man kann zwar shelcode schreiben der eine DLL lädt und diesen mit AutoIt in einen anderen process injecten haber den shellcode selber kann man nicht in Autoit schreiben.

Und selbst wen man es so macht wär das eine schlechte art.
Den eigentlich schreibt eine DLL injector ja nicht nur die Funktion zum laden der DLL in den fremden prozess sondern auch noch eine structur in dem der Name und Pfad der Dll und ein zeiger auf funktion LoadLibrary steht(Je nachdem auch noch ein zeiger auf die funktion "GetProcAddress" und den Namen der funktion die aufgerufen werden soll die beiden funktionszeiger werden natürlich vor dem injecten Mittels GetProcAddress ermittelt).

Wen man das mittels shellcode macht müsste man die funktionszeiger und den Namen&Pfad der DLL hardcoden. Das würde heissen das man man immer nur die selbe DLL injecten kann und der Injector würde nur auf dem Windows laufen bei dem die funktionszeiger gültig sind und die zeiger würden bereits ungültig(bzw auf andere Addressen zeigen) wen ein anderes Service pack installiert ist als auf dem pc auf dem die Funktionsaddressen ermittelt wurden.

[rEdoX]

Originally Posted by Akorn

Genaugenommen beantwortet das ja nicht wirklich seine frage. Man kann zwar shelcode schreiben der eine DLL lädt und diesen mit AutoIt in einen anderen process injecten haber den shellcode selber kann man nicht in Autoit schreiben.

Deswegen nennt man ihn ja auch Shellcode.

Originally Posted by Akorn

Und selbst wen man es so macht wär das eine schlechte art.
Den eigentlich schreibt eine DLL injector ja nicht nur die Funktion zum laden der DLL in den fremden prozess sondern auch noch eine structur in dem der Name und Pfad der Dll und ein zeiger auf funktion LoadLibrary steht(Je nachdem auch noch ein zeiger auf die funktion "GetProcAddress" und den Namen der funktion die aufgerufen werden soll die beiden funktionszeiger werden natürlich vor dem injecten Mittels GetProcAddress ermittelt).

Wieso sagst du, es sei eine schlechte Art und erlaeuterst diese anschließend? Zugegeben, der Overhead laesst sich meistens (so wie du es beschreibst sogar _IMMER_) vermeiden, manchmal kommt man einfach nicht drum rum.

Originally Posted by Akorn

Wen man das mittels shellcode macht müsste man die funktionszeiger und den Namen&Pfad der DLL hardcoden. Das würde heissen das man man immer nur die selbe DLL injecten kann und der Injector würde nur auf dem Windows laufen bei dem die funktionszeiger gültig sind und die zeiger würden bereits ungültig(bzw auf andere Addressen zeigen) wen ein anderes Service pack installiert ist als auf dem pc auf dem die Funktionsaddressen ermittelt wurden.

Man kann Shellcode auch dynamisch veraendern.

Desweiteren gibt es nicht _den_ Weg eine Dll bzw. Code in einen anderen Prozess zu schmuggel, es gibt 1000de.


Edit:

Originally Posted by MrSm!th

1. LOL? ich nicht Man ey, meine Trainer und sonstiges kriegen auf Vista nur einen Handle mit Adminrechten und auf XP gar nicht, da gibts nur Error6^^
2. CE,meine Trainer und kikis UCE können alle kein Solitär öffnen und Winject liefert einen Fehler (error 5 = Kein Zugriff) beim Injecten in notepad.
Daher nehme ich die Info...

Wie gesagt, bei mir liefert OpenProcess mit den hoechst moeglichen Rechten die man anfordern kann ein gueltiges Handle zurueck. Egal ob einer der beiden Prozesses Adminrechte hat oder nicht.

W7 x68

[Akorn]

Deswegen nennt man ihn ja auch Shellcode.

Willst du mir nur sagen das ich einmal mich verdrückt hab und shellcode mit nur einem "L"geschreiben habe anstatt mit zwei wie im restlichen text? Ansonsten ergibt der Text keinen sinn.

Man kann Shellcode auch dynamisch veraendern.

Das wäre aber für diesen zweck vollkommen unnötig da es viel einfachere wege gibt.

Desweiteren gibt es nicht _den_ Weg eine Dll bzw. Code in einen anderen Prozess zu schmuggel, es gibt 1000de

Mag sein aber wir sprechen hier ja beide um eine DLL injection mittels LoadLibrary.

[rEdoX]

Originally Posted by Akorn

Willst du mir nur sagen das ich einmal mich verdrückt hab und shellcode mit nur einem "L"geschreiben habe anstatt mit zwei wie im restlichen text? Ansonsten ergibt der Text keinen sinn.

Doch, tut er. Shellcode kann man nur mit Assembler "schreiben", wobei das indirekt auch nicht stimmt (man kann ihn nur mit einem hexeditor schreiben). Und deswegen kann man ihn auch nicht mit Autoit "erstellen".
Du kannst ein Kompilat erstellen, welches OpCodes enthaelt, diese kannst du wiederum als Shellcode interpretieren.

Originally Posted by Akorn

Das wäre aber für diesen zweck vollkommen unnötig da es viel einfachere wege gibt.

Also Pointer Arithmetik sollte man schon vorraussetzen koennen, wenn man ueber DLL-Injection spricht.

Originally Posted by Akorn

Mag sein aber wir sprechen hier ja beide um eine DLL injection mittels LoadLibrary.

Gut, LoadLibrary hängt in vielen fällen mit drinnen, da es einer der einzigen offiziellen Wege ist eine DLL zu laden.

Fuer die das Laden einer DLL in einen fremden Prozes mittels LoadLibrary wird keinerlei "Shellcode" benoetigt.