Ergebnis 1 bis 6 von 6
  1. #1
    ASM Freak Avatar von DerAssembler
    Registriert seit
    02.03.2010
    Beiträge
    40

    Standard GetThreadContext - Read 'Kernel Context'

    Hey Leute, mich plagt seit einiger Zeit schon ein kleines Problem.
    Und zwar:

    Starte ich einen Prozess im DEBUG_PROCESS Modus und setze/schreibe einen Breakpoint (0xCC) auf eine Kernel32 API-Funktion. Soweit läuft dann auch alles gut, dann beim Debug-Event möchte ich den derzeitigen Context via GetThreadContext auslesen, doch blöderweiße liefert diese Funktion komplett falsche Werte zurück. Zum Beispiel statt ESP: 1298FF eben 1235AB.
    Wenn ich die Funktion im "normalem" Code-Bereich aufrufe stimmen die ganzen Werte.

    Nun wäre ich euch sehr verbunden, wenn jemand die Ursache und eine Lösung dafür wüsste. Vielen Dank.

    p.s. vielen Dank nochmal an DizzY_D, der mir da schon sehr sehr viel geholfen hat.

  2. #2
    OpCodeKiddy Avatar von EBFE
    Registriert seit
    30.03.2009
    Beiträge
    442

    Standard

    Bist du sicher, dass nicht mehrere Threads laufen (vor allem bei NET&Co, aber auch bei "komplexeren" Programmen, die mittels RAD-Tools (Delphi/Borland IDEs)) öfters der Fall. Prüfbar z.B mit ProzessExplorer.
    Wie liest du die Werte ein, um zu prüfen, ob GetThreadContext richtig ausgeführt wurde?

    Edit/PS: um sicherzustellen: verstehe ich den Satz "Breakpoint (0xCC) auf eine Kernel32 API-Funktion" richtig, dass du damit einen BP in der Kernel32.DLL setzt (und nicht etwa bei einem Call dieser Funktion in der Exe)?
    Geändert von EBFE (30.08.2010 um 12:05 Uhr)
    TrueCrypt/RAR/Zip Passwort vergessen und das Bruten dauert ewig? Oder brauchst du fein abgestimmte Wortlisten? Hilf dir selbst mit WLML - Word List Markup Language
    Gib Stoned/Mebroot/Sinowal und anderen Bootkits keine Chance: Anti Bootkit v 0.8.5

  3. Folgende Benutzer haben sich für diesen Beitrag bedankt:

    Zweitopf (30.08.2010)

  4. #3
    Der mit Anatidaephobie Avatar von blackberry
    Registriert seit
    11.07.2008
    Beiträge
    2.350

    Standard

    You cannot get a valid context for a running thread. Use the SuspendThread function to suspend the thread before calling GetThreadContext.
    (Quelle: GetThreadContext Function (Windows))

    Vielleicht hilft's ja.

    PDFTT cr3w a.E. — ReiDC0Re, lindor, Sera, berry
    please do feed the trolls crew and elk
    Ehrenwerte Mitglieder im Ruhestand: OpCodez, SFX.
    "Was sich blackberry gerade denkt" — Vorsicht! Frei laufender Wahnsinn!
    Zitat von fuckinghot19: "PS: Blackberry ist auf FH der Trollkönig ^^."
    An dieser Stelle danke ich all meinen Fans und Hatern gleichermaßen ^.^

  5. Folgende Benutzer haben sich für diesen Beitrag bedankt:

    Zweitopf (30.08.2010)

  6. #4
    ASM Freak Avatar von DerAssembler
    Registriert seit
    02.03.2010
    Beiträge
    40

    Standard

    Zitat Zitat von EBFE Beitrag anzeigen
    Bist du sicher, dass nicht mehrere Threads laufen (vor allem bei NET&Co, aber auch bei "komplexeren" Programmen, die mittels RAD-Tools (Delphi/Borland IDEs)) öfters der Fall. Prüfbar z.B mit ProzessExplorer.
    Wie liest du die Werte ein, um zu prüfen, ob GetThreadContext richtig ausgeführt wurde?

    Edit/PS: um sicherzustellen: verstehe ich den Satz "Breakpoint (0xCC) auf eine Kernel32 API-Funktion" richtig, dass du damit einen BP in der Kernel32.DLL setzt (und nicht etwa bei einem Call dieser Funktion in der Exe)?
    Soweit ich es beurteilen kann läuft nur 1 Thread im Debuggee. Die Anwendung (also das Debuggee) ist in C++ geschrieben. Nunja wenn ich den "Debugger" debugge bekomm ich keinen Error (auch nicht GetLastError). Und die Werte überprüfe ich wenn ich das Debuggee manuell in Olly debugge.

    Ja du verstehst den Satz richtig. Der BP befindet sich in der Kernel32.dll.

    @BlackBerry: Danke ich werds mal versuchen.

  7. #5
    OpCodeKiddy Avatar von EBFE
    Registriert seit
    30.03.2009
    Beiträge
    442

    Standard

    Abgesehen von BlackBerrys Hinweis:
    wohin zeigt eigentlich der ESP? (also der Wert an 0x1298FF) lies den mal aus und vergleiche mit dem Wert, den dir Olly anzeigt <-- ist nämlich die Rücksprungsadresse. Damit lässt sich leicht herausfinden, wer der Caller ist. Und du kannst prüfen, ob du in Olly die gleiche "Situation" betrachtest, wie in deinem Programm.

    Auch wenn die Exe die API nicht nativ aufruft, sondern gewrapt (z.B über RuntimeDLL) - sowas lässt sich relativ leicht herausfinden, in dem man einmal in Olly den Stack durchgeht und die Rücksprungadresse in den Exe-Mem-Bereich sucht. Der Abstand zwischen ESP Wert am BP-Event und der Stackadresse, die den Rücksprung in die Exe beinhaltet, ändert sich nicht. D.h wenn API-BP-Event auftritt, Thread einfrieren, ESP auslesen, Abstand dazuaddieren und schauen, ob der Wert an dieser Adresse gleich Exe-Bereich ist. Dient quasi der Identifikation, um zwischen internen Calls und dem gewünschten unterscheiden zu können.

    Zum Olly:
    Alt+O für Optionen ->Events -> Make first pause at -> System BP
    nun restarten und den BP machen.
    Damit kannst du halt prüfen, ob die API nicht intern, vor dem eigentlichen Exestart, aufgerufen wird .

    alternativ platzierst du in deine Programm noch einen BP am EntryPoint, liest zusätzlich EIP aus und merkst dir irgendwo, ob BP am EntryPoint aufgerufen wurde. Damit kannst du (in deinem Programm) auch prüfen, ob die API noch vor dem EP aufgerufen wird. Eine Art "identifikation" mittels Parameterprüfung oder Rücksprungadresse (wie oben beschrieben) sollte man aber trotzdem einbauen.
    Geändert von EBFE (30.08.2010 um 13:35 Uhr) Grund: letzten Absatz ergänzt -> BP am EP im Programm und nicht in Olly gemeint
    TrueCrypt/RAR/Zip Passwort vergessen und das Bruten dauert ewig? Oder brauchst du fein abgestimmte Wortlisten? Hilf dir selbst mit WLML - Word List Markup Language
    Gib Stoned/Mebroot/Sinowal und anderen Bootkits keine Chance: Anti Bootkit v 0.8.5

  8. Folgende Benutzer haben sich für diesen Beitrag bedankt:

    DerAssembler (30.08.2010), Zweitopf (30.08.2010)

  9. #6
    ASM Freak Avatar von DerAssembler
    Registriert seit
    02.03.2010
    Beiträge
    40

    Standard

    Danke EBFE, ich werde jetzt mal BlackBerrys Ratschlag versuchen und anschließend mal prüfen ob die API schon vorher aufgerufen wird. Eben ist es mein Ziel die Rücksprungaddresse auszulesen um den Caller zufinden um dann mit meiner Analyse fortzusetzen.

    Vielen dank ihr beiden, ich werd dann Feedback geben obs geklappt hat.

    Feedback:

    EBFE du bist der Beste! Es war genau so wie du vermutet hast. Die API wurde schon vorher einmal intern aufgerufen! Und dort stimmen die ganzen Werte/Register.

    Vielen dank nochmal EBFE!
    Geändert von DerAssembler (30.08.2010 um 17:44 Uhr) Grund: Automerged Doublepost

Ähnliche Themen

  1. Kann Kernel nicht downgraden! Boot Ordner leer!?
    Von Darti401 im Forum Linux und UNIX-Systeme
    Antworten: 1
    Letzter Beitrag: 09.07.2009, 18:21
  2. For all read this.
    Von 2970ernesto im Forum Instant Messaging
    Antworten: 3
    Letzter Beitrag: 17.03.2009, 16:24
  3. Antworten: 0
    Letzter Beitrag: 21.01.2009, 16:56

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •