eigener Debugger - Haltepunkte

[Kas Ob.]

@dummzeuch, that is really nice project !
I am not familiar with it, but it looks right.

@himitsu, Well i didn't download the project yet, but i would suggest a new and novel approach for patching a process memory, myself will test it, yet can't find the time.
See, it is almost 6 PM, and a blackout is planned for 3 or 6 hours for my city, so no more Internet or PC for me today.

My suggestion is read and try this brilliant attack/approach instead of ReadProcessMemory/WriteProcessMemory
https://dtsec.us/2023-04-24-Sleep/
https://www.ired.team/offensive-secu...code-injection

I believe you can easily use NtCreateSection + NtMapViewOfSection this without the injection of course, they might yield way less overhead by simply patch the shared section, hence they might be faster than WriteProcessMemory, yet this need to be proved.

[himitsu]

Ach ja, hier im Assembler sich stundenlang durchzukämpfen
oder mit F9 und Pause zu versuchen zufällig an der "interessanten" Code stelle zu landen.
https://www.delphipraxis.net/215375-...ml#post1538125

Stattdessen könnte man auch ein Profiling oder Tracing starten und schauen wo und wie lange die meiste Zeit drauf geht, bzw. was wirklich alles gemacht wird.




Bin nochmal kurz im Baumarkt, mir bissl Holz und 'nen Kantenfräser besorgen.
Danach schau ich dann hier weiter.

Aber zuerst versuche ich mal single-threaded im ConsolenDebugger (SuperMiniDebugger) das Grundsätzliche störungsfrei zum Laufen zu bringen
und danach wird dann im VCL-basierenden Debugger (MiniDebugger) weiter gemacht und dort mit den Haltepunkten angefangen.

[himitsu]

32 Bit Debugger + 32 Bit Anwendung = joar, knallt nicht mehr so oft
64 Bit Debugger + 64 Bit Anwendung = pfffffffffff niiiijaaa
64 Bit Debugger + 32 Bit Anwendung = hier hängt noch bissl mehr (muß man an vielen Stellen bezüglich WOW64 biss was beachten ... und dann kennt Delphi hier unter 64 Bit viele der 32 Bit APIs und Records nicht)
32 Bit Debugger + 64 Bit Anwendung = das geht natürlich garnicht

Das Code Coverige nutzt die Lösung, wo überall INT 3 reingeschrieben wird
und dann wie in #1 beschrieben, wird das nach Auslösen zurückgepatcht, der InstuctionPointer -1 und dann weiter.
Das Wieder-Aktivieren des Haltepunktes sparen sie sich ... wird eh nur geloggt WAS aufgerufen wurde (nicht wie oft)

Mit dem SingleStepping hab ich Probleme.
Nach dem Auslösen müsste ich den ja wieder aktivieren,
aber leider klappt das irgendwie nicht.
-> Im ThreadContext das Trap-Flag setzen hat keine Wirkung.
* innerhalb des EXCEPTION_BREAKPOINT, bevor ContinueDebugEvent(DBG_CONTINUE)
* oder sonstwann zwischen SuspendThread und ResumeThread

EXCEPTION_BREAKPOINT wird ausgelöst,
aber egal wann und wie ich es versuche, es kommt niemals ein EXCEPTION_SINGLE_STEP.

Auch im DelphiDebugger versucht, also anhalten und dann in der CPU-Ansicht das TF-Flag aktivieren ... nach F7/F8/F9 ist keine Auswirkung zu erkennen
und in der nächsten Pause ist das TF auch wieder aus.

https://microsoft.public.win32.progr...ingle-stepping
https://www.lowlevel.eu/wiki/EFLAGS
...

Mal sehn, ob ich bei dem noch was finde.
https://www.timdbg.com/posts/symbol-indexing/

Das RIP_EVENT konnte ich auch noch nicht triggern ... also vermutlich ist es wohl wirklich tot.
https://reverseengineering.stackexch...gers-rip-event
https://learn.microsoft.com/de-de/wi...bugging-events

[Kas Ob.]

@himitsu ,

If your offer for the source still up, and the source is compilable on XE8 then i would like to have look.
Who knows, i might track and find the cause of triggering EXCEPTION_SINGLE_STEP failure, but i don't want to take from you the joy of writing/fixing it !

Away from that, please have a look here:
https://stackoverflow.com/questions/...p-all-the-time

For single step there is only two ways,
1) hardware break point approach with the debugging registers, it must handle INT1, or
2) software one with the usual trap INT3 each for each step/instruction.

In all cases, what are the values of bit 14 in DR6 and bit 12 in DR7, did you track them ?
https://en.wikipedia.org/wiki/X86_debug_register

The last answer here also is nice and detailed but it does assume single step should work out of box after INT3, but again here comes this part

Zitat:

...

Was going to paste some text above, then changed my mind, the answer is written just fine and brilliantly, need to be understood in full,

the only thing i can do, is to point where what i can guess the problem in your code:
1) You myst not confuse these

Zitat:

exceptions: vector 1 (debug exception, #DB) and vector 3 (breakpoint exception, #BP).

and their usage.
2) DB and BP mode are controlled by bit 12 in DR7
3) you can/must switch to DB after a BP, for single step so INT3 comes first then INT1 (this one is an event/signal not instruction), in other words : for single step, BP once then DB all the way afterward.

Hope that helps you with tracer.

Update : Sorry missed the link
https://stackoverflow.com/questions/...ruction-on-x86

[Kas Ob.]

Sorry !!

I missed the link
https://stackoverflow.com/questions/...ruction-on-x86

[himitsu]

Also, in den DR-Registern soll man wohl "je einen Haltepunkt" angeben können ... noch nicht probiert, aber das wären eh zu wenige

Das Trap-Flag einfach so zu setzen, hat keine Wirkung,

Delphi-Quellcode:

hMainThread := OpenThread(…, MainThreadID);
GetThreadContext(hThread, Context);
Context.EFlags := Context.EFlags or $0100;  // Trap-Flag (TF)
SetThreadContext(hThread, Context);
CloseHandle(HThread)

jedenfals nicht, wenn ich es in meinem Debugger mache (Taste [S] während des Debugging).

In der TestApp gesetzt, bzw. während eines Debug-Ereignisses, geht es,
aber bleibt dann auch irgendwann wieder aus und es stoppt. (siehe BreakPoint- oder SingeStep-Taste in der TestApp)

http://fnse.de/MiniDebugger.7z
SuperMiniDebugger.exe -demo-executable -all

PS: In der -help die DebugTasten nicht aktualisiert ... siehe Console, zu Beginn des Debuggens (hochscrollen)

[Kas Ob.]

Looks nice and working fine, though the source is not XE8 friendly due the inline variables and may be missing constants.

Question :
Why the overhead of keep opening the (a) thread and closing its handle ?!!

You have in the debugger loop an very useful events CREATE_THREAD_DEBUG_EVENT, and EXIT_THREAD_DEBUG_EVENT, so build a list or dictionary and do the open/close only once, this should help in speeding the trace.

As for the trap bit in the EFlags:
Single step is hardware generated interrupt same as hardware breakpoints, but for the single step to work these DR0-DR3 should be put to 0, in other words either you have enabled hardware breakpoints at specific addresses or single step, but not both at the same time.

May be just 0 to DR7 could be enough (zeroing all the bits) , but in my opinion the best is to clear DR0-DR3 and DR7, and think it will work every time.


ps: ran the binary and clicked on the buttons many times and couldn't see a failure.

ps2: i found this, it does confirm my recall about hardware breakpoints:
https://stackoverflow.com/questions/...p-all-the-time