eigener Debugger - Haltepunkte

[himitsu]

Tachchen,

hat hier schonmal jemand selbst einen Debugger gebastelt?

Bin noch in den Planungen/Überlegungen,
aber bezüglich Haltepunkte finde ich fast keine Infos.
https://learn.microsoft.com/de-de/wi...ging-functions

Im Grunde heißt es (Stackoverflow usw.),
* ich sollte die Stellen mit RAM/Code patchen (WriteProcessMemory) -> INT 3
* dann im Debugger warten (EXCEPTION_BREAKPOINT)
* die Stelle wieder zurück patchen
* den CodeZeiger um 1 zurückstellen
* und dann kann es weiter gehn
* (auch wenn es niemand sagte) am Ende muß ich die Stelle ja wieder neu patchen, damit der Haltepunkt erneut auslösen kann

* im Grunde müsste ich dann auch erst einen Einzelschritt machen, dann patchen und nun weiter (damit der Patch drin ist, bevor das Programm da wieder vorbei kommt)
* und natürlich immer schön FlushInstructionCache

Aber ich dachte man kann sich da auch irgendwo "registrieren" und die Haltepunkte beim OS quasi in eine Liste eintragen, ohne den Code patchen zu müssen.



Bei VirtualAlloc/VirtualProtect hatte ich auch schon nachgesehn, ob man da vieleicht ein Flag setzen kann, aber das Einzige (PAGE_GUARD) klingt nicht vielversprechend.




Ach ja, es wird nicht wirklich ein Debugger ... ich möchte nur dessen Funktionen nutzen, für einen kleinen Profiler/Tracer.

[Kas Ob.]

Hi,

This subject is deep, i mean really deep, yet it is not that hard once you got the idea, and it is not that straight forward, as you drawn it, i had built small debugger (-ish) for fun and learning and dropped it when felt i got what i need to know and the whole thing started to become boring.

See, if the break point happened by a simple trap like INT3 then the thread triggered it will change its execution and jump, hence losing and corrupting its own thread context at that moment.
To prevent that you need to set the debugging environment first, and that include using the CPU debug registers https://en.wikipedia.org/wiki/X86_debug_register , and this is the tricky part or the complicated part, yet it is pretty straight forward from here.

I suggest reading about the subject and i have very nice resources about that:
1) The Wikipedia page mentioned above is hard to interpret but can be used as reference.

2) There is great blog posts from an expert, an ex member of Microsoft Debugger Platform team:
https://www.timdbg.com/
Part 5 is about breakpoints https://www.timdbg.com/posts/writing...cratch-part-5/ and he is using https://wiki.osdev.org/CPU_Registers...ebug_Registers as reference instead of Wikipedia.

3) My favorite one ! and this one i am using in many places when i need to do runtime stuff.
https://github.com/x64dbg/TitanEngine
This engine is used in xdbg64 as main debugging engine, it is very powerful, also have unique capabilities for hooking, a Pascal header is here, but it might be out-dated
https://github.com/jsj2008/TitanEngi...ter/SDK/Delphi

4) The one that really might help you is CheatEngine, it is not for moding/patching games, but it can do many many things, i use it as debugging tool as it is one mighty debugger written in Pascal:
https://github.com/cheat-engine/cheat-engine

Hope that helps.

[Rollo62]

Willst Du Dir das wirklich antun? Das genzt schon an Masochismus
Reicht nicht eventuell schon eine Scriptsprache?
https://www.delphitools.info/dwscript/

[dummzeuch]

Multithreading nicht vergessen! Das ist ja schon nicht einfach, ohne dass man einen Debugger schreiben will. Wie viele Jahre willst Du investieren?

[himitsu]

'nen Tag/Woche?

Wie gesagt, Debuggen selbst (also Variablen auslesen/ändern/sonstwas) nicht.
Benötige nur die Meldungen vom Debugger, wann es wo vorbei kam.

Das Grundgerüst bastl ich grad mal zusammen (ohne Haltepunkte), also Starten/Anhängen, Stoppen und Loggen,
um was zum Testen zu haben.

Ich glaub der StackTrace, beim Halt, wird wohl das Größte.
In der Pipeline hab ich noch das Auslesen der TDS (in 'nem anderem Projekt) ... die DebugInfos von Windows/C++ bekomm ich problemlos über die API vom Windows (schon benutzt, um Stacktraces auszulesen, wobei ich da noch Programme wie tds2pdb dazwischen hab, wegen dem was Delphi fabriziert).

[Kas Ob.]

Zitat von himitsu:

'nen Tag/Woche?

Wie gesagt, Debuggen selbst (also Variablen auslesen/ändern/sonstwas) nicht.
Benötige nur die Meldungen vom Debugger, wann es wo vorbei kam.

Das Grundgerüst bastl ich grad mal zusammen (ohne Haltepunkte), also Starten/Anhängen, Stoppen und Loggen,
um was zum Testen zu haben.

With Titan Engine you can have your own prototype debugger in few hours, just build the UI.

[Kas Ob.]

One more thing about the Debugger Loop mentioned and recommended in https://learn.microsoft.com/en-gb/wi...er-s-main-loop

You can see that the full loop is already and fully taken care of in TitanEngine, including break points and threading
https://github.com/x64dbg/TitanEngin...gLoop.cpp#L513

[freimatz]

Zitat von himitsu:

Ich glaub der StackTrace, beim Halt, wird wohl das Größte.

http://help.madshi.net/madStackTraceUnit.htm

[himitsu]

Nee nee, nicht im Programm, sondern in meinem "Debugger", von der anderen Anwendung
(wie im Delphi, da der Stacktrace, vom Programm)


* Grundstruktur der Grundfunktionen erstmal überlegt
* zwei "einfache" Testanwendungen gebastelt (um die Funktionen des Debuggers ausprobieren zu können)
* starten/stoppen der Testanwendung
* Prozesse auflisten (kommt heute dran)

[himitsu]

* Also, bezüglich Haltepunkten hab ich noch nichts angefangen.
* Ich kann sie empfangen, wenn sie im Zielprogramm explizit ausgelöst werden. (BebugBreak; oder asm int 3 end; )
* Haltepunkte sind "Exceptions".
* Die Detailbehandlung von Exceptions hab ich bisher nur rudimentär. (keine Detailinfos und Messages)
* beim Auslesen vom Stack bricht es immer vorher ab. (gleich nach 1 oder 3-6 Sprüngen ... mein Limit steht auf 10, aber vorher kommt schon als ReturnAddr eine 00000000 vorbei)
* Nein, es gibt noch keine Namensauflösungen im Stack, also nur die Adresse, um zu sehn, ob überhaupt was kommt. (WalkStack ... noch nicht WalkStack64 oder WalkStackEx oder ...)
* aktuell nur 32 Bit Debugger mit 32 Bit Testprogramm getestet (erstmal das zum Laufen bringen und dann weiter)

* DebugInfos auslesen und dann vielleicht Haltepunkte setzen gibt es noch nicht ... bin noch hart am Kämpfen, mit den Grundfunktionen

* Dokumentation (Microsoft) und Artikel/Tutorials sind teilweise sogar in sich schon wiedersprüclich.
* So weiß ich noch nicht welche Handles ich wann freigeben darf/soll/muß.
* Jedenfalls ist da garantiert bestimmt noch was falsch
. * wenn der Prozess endet, dann verschwindet er und teilweise sein Fenster nicht sofort (erst wenn mein DebugThread oder ganzer Debugger endet)
. * wenn ich im Debugger den Prozess oder das Debuggen auf verschiedenste Weisen beende, dann verschwindet es auch nicht
. . bin mir fast sicher, dass ich noch irgendwo ein Handle auf den Prozess/Thread offen habe und das alles festhält

* Delphi hat enorme Probleme mit dem Debuggen von Consolenanwendungen
. ich kann extrem leicht immer einen "schweren Ausnahmefehler" im Delphi-Debugger und der IDE auslösen (mit einem einfachen Programm, noch ohne selbst Debugger spielen zu wollen)

* zusammen mit Parnassus wird es noch viel extremer
* besonders auf Windows 11 mit dem Terminal knallt es am Besten ... im Gegensatz zu Windows 10 und ohne dass das neue Terminal installiert ist
> Debuggen der Konsolenanwendung starten
> in einen Haltepunkt laufen
> im angehaltenen Zustand das Konsolenfenster schließen
> nach einigen Sekunden beendet sich dann der ConsoleHost (manchmal nimmt er auch die eigene EXE mit)
> Delphi bekommt natürlich nichts mit
> wird danach dann Fortsetzen oder ein STOP im Debugger ausgeführt, war's das
. > der Debugger raucht ab und Delphi lässt sich fast nicht mehr beenden (will dabei immer den Debugger beenden, aber dabei knallt es)
. > mit viel Glück wird dann ach nichts gespeichert (der gespeicherte Desktop ist im Arsch) ... Haltepunkte und "geöffnete Dateien" werden vergessen
. > einmal war auch das ganze noch ungespeicherte Projekt weg (nichtmal __history und __recovery vorhanden) ... da die BDS aber auch garnicht mehr reagierte hatte ich noch genug Zeit für einen Snapshot (Taskmanager) und dann in den 2 GB RAM wichtige Teile geborgen ... vielen Dank an HxD (keine Lust nochmal alles zu suchen und neu machen zu müssen)



Quellcodes aktuell vielleicht auf liebe Nachfrage.



* So, hab hier auch gleich endlich mal mit dem neuen Streaming der Console gespielt, gegenüber der alten ConsoleAPI.
* das Terminal reagiert ja auch teilweise anders, gegenüber der alten Console (CMD)
. * Eingaben landen standardmäßig sofort im ECHO (Anzeige) ... mitten in der laufenden Ausgabe und nicht, wie früher, erst dann, wenn die Console/Anwendung in den Eingabemodus wechselt
. * der Curso blinkt standardmäßig immer, auch wenn nichts eingegeben werden soll
. * Markieren und Anhalten geht nicht mehr ... läuft im Hintergrund weiter und wenn Programm fertig, dann geht das Terminal auch sofort zu (egal ob noch was markiert/angehalten ist)

* wenn ich den Prozess selbst starte, inkl. Debuggen, dann erhalte ich teilweise andere Ergebnisse, als wenn ich mich an ein laufendes Programm angänge.
. * einmal immer nur EINE StackAdresse oder auch Mehrere (aber immernoch nicht genug)
. * die Namen der EXE/DLLs sind anders C:\... oder \Device\HarddiskVolume3\...

* Hier mal paar Test-Aufrufe aus dem Delphi-Projekt:
> SuperMiniDebugger.exe -process <ID>
> SuperMiniDebugger.exe -process <NAME>
> SuperMiniDebugger.exe -process <MASK>
> SuperMiniDebugger.exe -executable <FILENAME> -all
> SuperMiniDebugger.exe -executable <FILEMASK> -all
> SuperMiniDebugger.exe -demo-executable -all
> SuperMiniDebugger.exe -help
Da wird dann auch zusätzlicher DBBUG-Code in meinem Debugger genutzt. (TestApp starten und PID suchen, anstatt das jedesmal selbst machen/suchen/eingeben zu müssen)




https://github.com/microsoft/terminal
https://learn.microsoft.com/de-de/windows/terminal/
https://apps.microsoft.com/detail/9n...hl=de-de&gl=DE

Ups, ein Fehler in der Logausgabe (letzer Screenshot).
Das "-process" mit dem langen Dateiname, inkl. Pfad, müsste "-executable" heißen.