probleme beim api-hooking

was meinst du damit?
falls du meinst ob ich nen treiber verwende: nein.

ich verwende nen iat-hook (mit virtualprotect).

mit nem absturz hätt ich auch eher gerechnet als mit so ner komischen anzeige. und der taskmgr ist ja auch das einzige programm das so fehlerhaft reagiert.

ciao, neonew

ScriptGod

Ja API hooken kann mal KernelMode (also per Treibern in ServiceTable etc.) und im UserMode...

Aber wie hookst du neue Prozesse? Besser gesagt wann "infizierst" du sie? Oder trifft das Problem bei einem bereits laufeneden Taskmanager auf?

ne tritt nur auf wenn ich den taskmanager starte.

und wie gesagt ich hooke vor NtResumeThread()...

hab mal jetzt versucht NtResumeThread() aufzurufen bevor ich hooke, dann klappt es auf dem einen pc nahezu perfekt, auf nem anderen gar nicht?!?

ciao, neonew

ScriptGod

Wenn du per IAT hookst, kannst du ja nur Porzess mäßig hooken? Oder veränderst du die NTDLL.dll?

Hookst du mit einer eingenen DLL oder haust du den Code per Hand in den Prozess?

hi,

ne, ntdll.dll bleibt unangetastet.
ich hooke jeden prozess mit ner kombination aus WriteProcessMemory/CreateRemoteThread (ohne dll).

ciao, neonew

ScriptGod

Also du schreibst den Assembler Code direkt in die Anwendung? Vielleicht gibt es dort einen Fehler wenn der Code an einer anderen Stelle gemapped wird?

hi,

nee ich benutz keinen assembler und ich glaube nicht dass da der fehler liegt.

pseudo:

int WINAPI hookProcess(void *)
{
  // überschreibe iat
}

// main:
WriteProcessMemory(process, memoryInOtherProcess, hookProcess, 4096 /*size*/);
CreateRemoteThread(memoryInOtherProcess, NULL);

ich weiß die parameter kommen nich wirklich hin aber ich denke man ahnt wie es gemacht ist.

ciao, neonew

ScriptGod

Also, dass das so überhaupt funktionert wunder mich. Da hookProcess nicht genau an der selben stelle im Speicher, bei deiner Anwendung und bei der RemoteAnwendung ist, ist eigentlich der Normalfall. Dann stimmen die Adresse nicht mehr. Alleine schon ein if würd nicht mehr funktionieren.

cya

Mart

if is ein relativ jump

ScriptGod

kommt auf den compiler an, mache jumps werden als absolut gemacht...

naja, des ist noch das kleinst problem, alleine schon die ganzen imports mittels IAT sind an anderer Stelle.

Mart

imports sind kein problem, du kannst ja dem injected code funktionszeiger mitgeben....

ScriptGod

Mart schrieb:

imports sind kein problem, du kannst ja dem injected code funktionszeiger mitgeben....

Dies trifft auf kleine Anwendung zu. Aber wenn man svchost.exe, services.exe anschaut hat man dlls die nicht mehr an ihrere Standardbaseadresse sind, wenn man das berücksichtige gehts im Grunde genommen. Wobei manchen Funktionen in kernel32.dll auf TLS zurückgreifen, der Thread/Prozess abhängig ist - sollte jedoch kaum vorkommen

Aber wie gesagt bei sowas wär ich extrem vorsichtig, entweder DLL oder direkt Assembler sollte dann in jedem Fall gehn

hi,

hmm ne hab lange getestet etc, funktioniert ja auch vom prinzip (hab die beschreibung der methode danach auch auf ner page im netz gefunden), ich glaube auch nicht das in der methode an sich ein fehler liegt...

ciao, neonew

ScriptGod

Schon mal versuchen ein __asm int 3; oder DebugBreak(); reinzumachen und dann den Code debuggen? Evtl. findest du so den Fehler, wenn er in der Funktion ist.