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.

[freimatz]

Zitat von himitsu:

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

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

[Uwe Raabe]

Zitat von himitsu:

Benötige nur die Meldungen vom Debugger, wann es wo vorbei kam.

Ich habe zwar immer noch nicht das große Ganze begriffen, worauf du hinaus willst, aber eine Meldung beim Durchlaufen eines Haltepunkts ohne dort wirklich anzuhalten bekommt man auch mit den Bordmitteln hin:

• Haltepunkt setzen
• Eigenschaften des Haltepunkts...
• Weitere...
• Anhalten abwählen
• Meldung protokollieren ausfüllen

Die Haltepunkte lassen sich auch in einem IDE-Plugin entsprechend setzen. Im DelphiCodeCoveragePlugin findest du ein Beispiel dazu.