probleme beim api-hooking



  • hi,

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

    ciao, neonew



  • 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



  • 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



  • if is ein relativ jump 😉



  • 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.



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



  • 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



  • 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.


Anmelden zum Antworten