CreateProcess importieren / API Hooks umgehen

[Zacherl]

Hi,

ich will die CreateProcess API dynamisch in mein Programm einbinden. Dazu verwende ich:

Delphi-Quellcode:

function CreateProcess(lpApplicationName: PChar; lpCommandLine: PChar;
  const lpProcessAttributes, lpThreadAttributes: PSecurityAttributes;
  bInheritHandles: BOOL; dwCreationFlags: DWORD; lpEnvironment: Pointer;
  lpCurrentDirectory: PChar; const lpStartupInfo: TStartupInfo;
  out lpProcessInformation: TProcessInformation): BOOL; stdcall;
var
  pCreateProcess: function(lpApplicationName: PChar; lpCommandLine: PChar;
  const lpProcessAttributes, lpThreadAttributes: PSecurityAttributes;
  bInheritHandles: BOOL; dwCreationFlags: DWORD; lpEnvironment: Pointer;
  lpCurrentDirectory: PChar; const lpStartupInfo: TStartupInfo;
  out lpProcessInformation: TProcessInformation): BOOL; stdcall;
begin
  pCreateProcess := GetRealProcAddress(GetModuleHandle('kernel32'), 'CreateProcess');
  Result := pCreateProcess(lpApplicationName, lpCommandLine, lpProcessAttributes,
                           lpThreadAttributes, bInheritHandles, dwCreationFlags,
                           lpEnvironment, lpCurrentDirectory, lpStartupInfo,
                           lpProcessInformation);
end;

Leider kommt nun nach dem Start des Programmes sofort die Meldung, dass ein Fehler verursacht wurde und das Programm beendet wird.

Woran kann das liegen?

PS: GetRealProcAddress ermittelt nur die "ursprüngliche" Adresse der API, somit werden Userlevel API Hooks nicht gecallt.

[sirius]

kernel32.dll

[Zacherl]

Geht leider auch nicht .. es müssen die Parameter Datentypen sein, die nicht stimmen =/

[Win32.API]

@pCreateProcess := GetRealProcAddress(GetModuleHandle('kernel32.dll') , 'CreateProcessA');

[turboPASCAL]

Zwischenfrage, warum möchtest du denn CreateProcess dynamisch implementieren?
Diese ist doch in der Unit Windows enthalen.

[Zacherl]

Argh das A hat gefehlt :wall: Danke ..

@TurboPascal: Ich möchte die API Hooks umgehen, deshalb ..

[Win32.API]

Das A und noch viel wichtiger das "@" ... Du solltest pointer _immer_ auf nil pruefen .

[Zacherl]

Ja, hab ich schon eingebaut ..

[brechi]

Damit umgehst du vielleicht 10% der API hooks, mehr aber auch nicht...

[Zacherl]

Die API Hooks werden komplett umgangen .. nur die Kernel Hooks nicht.

[brechi]

Quatsch, Code overwriting oder Exporttable hooks werden nicht umgangen und selbst bei Importtable hooks haben viele Hook-Funktionen schon automatisch eingebaut, dass bei einem Aufruf von GetProcAddress die falsche Adresse zurückgegeben wird.

[Zacherl]

Ich beharre weiterhin darauf. Hier die Funktion:

Delphi-Quellcode:

function GetRealProcAddress(hModule: HMODULE; lpProcName: pchar): pointer;
var
  Proc: pointer;
  CodeInfo: TCodeInfo;
  FunctionInfo: TFunctionInfo;
begin
  Proc := GetProcAddress(hModule, lpProcName);
  Result := Proc;
  CodeInfo := ParseCode(Proc);
  if not (CodeInfo.Call or CodeInfo.Jmp) then Exit;
  FunctionInfo := ParseFunction(Proc);
  if FunctionInfo.CodeLen <> 5 then Exit;
  repeat
    Result := FunctionInfo.FarCalls[Low(FunctionInfo.FarCalls)].Target;
    FunctionInfo := ParseFunction(FunctionInfo.FarCalls[Low(FunctionInfo.FarCalls)].Target);
  until FunctionInfo.CodeLen = 10;
end;

Benötigt wird die madDisAsm

[brechi]

Das ist zwar schön, aber ich habe die uallCollection selbst geschrieben. Es wird nur die richtige Adresse geholt, d.h. noch lange nicht das vorher ein Export Table hook installiert war oder die Funktion mit Code Overwriting gehookt ist.

[Zacherl]

Die madDisAsm Unit meine ich .. die sollte doch die Library disassemblieren und genau den Originalcode aufrufen, oder?

[brechi]

Ach wat, die macht auch nix besonderes. Kann sein, dass die für nen speziellen Hook funktioniert. Aber allein schon der gebracuht von GetProcAddress is blödssinn wenns nen Exporttablehook gibt.

[Zacherl]

Mh also da gibt es keine Möglichkeit das zu umgehen?

[brechi]

Nein, jedefalls nicht wenn man keine Ahnung hat wie das alles funktioniert.

[Zacherl]

Aber du hast Ahnung denke ich doch mal ..

[brechi]

Wofür wirds gebraucht?

[Zacherl]

Ich möchte eine EXE direkt im RAM ausführen. Dafür habe ich schon Teilweise Quelltexte von Nico gefunden (InMemExe).
Leider hat meine Firewall was dagegen (aus was für Gründen auch immer). Nun ist es für den Benutzer ja nicht sehr benutzerfreundlich, wenn seine Firewall zufällig grade die benötigten APIs hookt und somit das Programm nutzlos macht.

Daher will ich versuchen, zumindest die API Hooks zu ungehen. Wäre dir sehr dankbar, wenn du mir da helen könntest.

[brechi]

Exe im Ram ausführen ist bei meiner uallCollection dabei und da sollte auch keine Firewall meckern.

[Zacherl]

Norton 2007 meckert, wenn man mit WriteProcessMemory die Datei in den Speicher schreiben will. Ich habe jetzt nur mein Programm schon total an die Routinen von Nico angepasst.

Perfekt wäre es halt, wenn ich de Hooks von WriteProcessMemory umgehen kann.

[Win32.API]

wenn du userland hooks umgehen willst, lade eine temp kernel32 .. 100%tig keine hooks ;)

[brechi]

In welchen Speicher denn? Im eigenen brauchst du kein WriteProcessMemory... und im Speicher von anderen Programmen meckert Norton zurecht. Ohne zu sagen was du machen willst gibts keine weitere Hilfe.

@Win32.API: 100% bestimmt nicht...

[Win32.API]

ja gut, aber zu 99% :>

[Zacherl]

Zitat:

Zitat von Win32.API

wenn du userland hooks umgehen willst, lade eine temp kernel32 .. 100%tig keine hooks ;)

Wie mache ich das?

Zitat:

Zitat von brechi

In welchen Speicher denn? Im eigenen brauchst du kein WriteProcessMemory... und im Speicher von anderen Programmen meckert Norton zurecht. Ohne zu sagen was du machen willst gibts keine weitere Hilfe.

Alle Leute sind direkt so negativ zu den Dingen eingstellt .. der Packer Source von Nico:

http://www.luckie-online.de/dirindex.../Importe/Nico/ -> inmemexe.zip

Benötigt WriteProcessMemory, um die Datei im Speicher auszuführen. Es wird übrigens sozusagen im eigenen Speicher geschrieben, weil das Programm sich selbst nocheinmal startet. Und in diesen Speicherbereich kommen dann die Daten der auszuführenden EXE.

[Win32.API]

Du kopierst die kernel32.dll einfach in den Tempordner und laedst sie mit LoadLibrary.

Um in den eigenen Speicher zu schreiben brauchst du kein wpm.

[Zacherl]

Zitat:

Zitat von Win32.API

Du kopierst die kernel32.dll einfach in den Tempordner und laedst sie mit LoadLibrary.

Um in den eigenen Speicher zu schreiben brauchst du kein wpm.

Vielen Dank, das werde ich mal ausprobieren.

Es ist nicht ganz mein eigener Speicher. Mein Prozess startet sich selbst ein zweites mal; diesmal aber SUSPENDED. Dann schreibt er in den Adressbereich des zweiten Prozesses die Daten der auszuführenden EXE und lässt diesen weiterlaufen.

[brechi]

Als wenn Norton keinen Kernel-Hook hat. Den Sinn von deinem Vorgehen hab ich immer noch nicht verstanden...
Und ist ja auch super sauber die Kernel32.dll umzukopieren. Selbst das bringt dir nix wenn auf NtCreateProcess ein Hook ist.
Solange keine guten Argumente kommen warum so ein Vorgehen sinnvoll ist, werd ich dir keine saubere Lösung anbieten.
Es wird immer nur die Hälfte erklärt und am Schluß nach 50 Posts sellt es sich herraus, dass das ganze viel einfacher zu machen ist und man umsonst wieder seien Zeit geopfert hat um dem Threadersteller zu helfen.

[Zacherl]

1) Mir ist bekannt, dass ich Kernel Hooks damit nicht umgehen kann
2) Argumente:

* Ich habe mein Programm bereits voll auf den Code von Nico ausgelegt und es geht alles wunderbar
* Weil nur Norton (und vielleicht noch andere) Firewalls meckern beim Aufruf von WriteProcessMemory will ich die API Hooks aller verwendeten APIs umgehen
* Die Hooks zu umgehen ist wohl sinnvoller als den Kernel rumzukopieren, wie du schon gesagt hast
* Ich will den Benutzern ein funktionierendes Programm bieten können, dem nicht einige Firewall dazwischenfunken

Reichen die? Fals du weißt wie man einen API Hook umgehen kann, dann bitte ich dich mir dabei zu helfen. Wenn du dir Nicos Beispiel mal angeguckt hast, dann kannst du sicher erkennen, wie das mit dem WriteProcessMemory gemeint ist. Da steckt nichmal die Absicht hinter in einen wirklich "fremden" Prozess etwas zu schreiben.

Fals du denkst, das Vorgehen den API Hook zu umgehen ist ineffizient, da Norton eh einen Kernel Hook hat, dann kann man ja evtl auch da was machen, wobei ich vermute, dass dies höchst kompliziert ist.

[brechi]

Ich wollte eher ein Argument warum du einen 2. Prozess starten musst und dann da den COde nochmal reinzuladen. Ich sehe da keinen Sinn drin. Von den Umgehmethoden mal abgesehen, werden die eh beim nächsten Update wieder geschlossen. Zumal du hier versuchst ein Virenprogramm zu umgehen -> was im Forum nicht gedultet wird.
Deshalb schreib doch erstmal warum du überhaupt dein Programm in einen 2. Prozess laden willst, das ist imho total unklar...

[Zacherl]

Nein ich will nicht Norton Antivirus umgehen .. es geht mir um die Firewall. Diese stört anscheinend, dass ich Code in einen "fremden" Prozess schreibe.

Der zweite Prozess wird sozusagen nur als Container für die auszuführende Datei verwendet. Dieses Vorgehen gefällt mir, deshalb möchte ich es gerne verwenden. Es erfüllt nämlich alle Dinge, die ich brauche.

//Edit: ich glaube wir reden aneinander vorbei .. es soll in der zweiten EXE nicht der Prozess nochmal ablaufen, sondern im Speicherbereich der zweiten EXE befindet sich hinterher die auszuführende EXE, die ich aus einer Resource lade.

[brechi]

Du willst den Schutz von Norton umgehen, so ist das nunmal. Norotn meckert nicht wenn in der eigenen Exe geschrieben wird. Du kannst die Ressource auch im eigenen Prozess laden (der hat dann so viel ich noch weiß 2 Fenster).
Oder aber du musst den 2. Prozess Debuggen und dann WriteProzessMemory benutzen, dann müsste Norton nicht meckern.

Aber das vorgehen an sich ist für ein normales Programm einfach total unsinnig, du hast imemr noch nicht gesagt warum du es für dein Vorgehen undbedingt brauchst. Welchen VORTEIL hat es denn gegenüber einem normalen starten des Programs?

[Zacherl]

Ich möchte einen Packer erstellen.

[ErazerZ]

Zitat:

Zitat von Florian Bernd

Ich möchte einen Packer erstellen.

Lol, diese "Packer" die mittels z.b. aphex's CreateProcessEx funktionieren gibts wie Sand am Meer..

[Zacherl]

Ich verwende nicht Aphex CreateProzessEx ..

(Wenn ich die Kernel Datei kopiere und mittels LoadLibrary lade, dann der GetProcAddress Funktion das DLL Handle übergebe wird die Funktion perfekt geladen, allerdings sehe ich kein Resultat nach dem Ausführen)

[ErazerZ]

Zitat:

Zitat von Florian Bernd

Ich verwende nicht Aphex CreateProzessEx ..

(Wenn ich die Kernel Datei kopiere und mittels LoadLibrary lade, dann der GetProcAddress Funktion das DLL Handle übergebe wird die Funktion perfekt geladen, allerdings sehe ich kein Resultat nach dem Ausführen)

Schaue mal ob das Handle der original Kernel32 das selbe ist wie bei dem neu geladenen.

[Zacherl]

Wenn ich das Handle mit GetModuleHandle ermittele ist dies in der Tat der Fall. Das von LoadLibrary zurückgegebene Handle scheint ungültig zu sein .. zumindest ist es eine 10 Stellige Zahl :shock:

Woran liegt das, dass die Handles gleich sind?

//Edit 1: Ah mist .. falsch geguckt .. nein, die Handles sind unterschiedlich, wobei der original Kernel die 10 stellige Zahl hat.
//Edit 2: Der Prozess wird sogar gestartet, allerdings verabschiedet sich selbiger, wenn ResumeThread aufgerufen wird oO

Hier gehts weiter für das Kopieren der kernel32.dll:
http://www.delphipraxis.net/internal...t.php?t=104690