eigener Debugger - Haltepunkte

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

[himitsu]

Funktional intern halt so, wie beim AQTime.

Allerdings (erstmal) keine Zeitmessung, sondern ein Tracing ... rückwirkend schauen was vorher und in welcher Reihenfolge gemacht wurde.
Oder einfach nur was innerhalb eines gewissen Zeitraums ausgeführt wurde, auch ohne Reihenfole.
Sowie ein Logging von Meldungen (Exceptions usw.)

Im Prinzip so, als wenn du im Delphi dauerhaft F7 drückst,
bis es irgendwo knallt oder anhält
und dann versuchst du dich zu erinnern, was vorher zuletzt für Zeilen ausgeführt wurden.
Funktionen rufen Funktionen auf -> im Stack zu sehn, aber

Code:

* Funktionsaufruf
  * weiterer Funktionsaufruf
    - usw.
      -
        - hier wird etwas Böses/Interessantes gemacht
      - end;
    - Code innerhalb gleicher Funktion/Ebene, wie das Nachfolgende
    * hier vielleicht das Except vom Try, oder einfach nur ein weiter Funktionsaufruf
      * hier bekomme ich vielleicht den Stacktrace aller/vieler * und sehe aber die - nicht mehr

Das Betrifft z.B. auch ausgelöste Events (PostMessage) aus, wo du im Event nicht wissen kannst, von wem das gekommen ist.
Beim SendMessage (innerhalb der eigenen Anwendung/Thread) müsste man es eigentlich erfahren können, aber da raucht das Auflösen vorher auch immer ab und du siehst nicht, wer das SendMessage aufgerufen hat.

[Uwe Raabe]

Damit sehe ich noch keine Anforderung, die mit den beschriebenen Bordmitteln nicht erfüllt werden kann.

Für Timing und Exceptions setze ich eher auf CodeSite anstatt Breakpoints - schon aus Performancegründen.

[Uwe Raabe]

Übrigens: Man kann im Eval-Ausdruck auch einfach einen Log-Call einsetzen.

[himitsu]

Leider knallt es gern "NUR" beim Kunden und dort hab'sch dann kein Delphi.

Auf der Todo-Liste steht aber mal, z.B. via TeamViwer ein VPN aufzubauen und dann via RemoteDebugging, aber auch das ist auch nicht immer möglich. (rechtliche und sicherheitstechnische Hindernisse)

Erstmal die besonders günstigen AQTime-Lizenzen und dann muß das Mistding
* installiert werden
* und als Admin starten



Ohne das Programm (Quellcode / EXE) selbst modifizieren zu müssen, da bietet sich ein Debugger halt an, um so von außen im Programm einiges mitbekommen zu können.

Der Debugger selbst ist "grundsätzlich" auch erstmal garnicht so das Problem.
https://learn.microsoft.com/de-de/wi...er-s-main-loop

Haltepunkte selbst sind schon möglich (durch Manipulieren des Speichers/Bytecodes) ... siehe #1
aber schön und effizient klingt das nicht und drum hatte ich hier gefragt, ob jemand mehr weiß (die Suche im Netz war halt nicht sehr ergiebig)


Im Moment hänge ich noch an ein paar Feinheiten und kämpfe mit 2-3 Problemchen / nervigen Stellchen
und bin noch nicht da hingekommen die Debuginfos zu lesen und Haltepunkte setzen zu können.

[dummzeuch]

Nur mal so am Rande bemerkt: Wenn ich mich recht erinnere, benutzt das Delphi Code Coverage Tool intern auch einen Debugger. Es setzt auf alle Codezeilen einen Breakpoint, sobald einer angesprungen wurde, wird das vermerkt (Unit + Zeilennummer) und anschließend der Breakpoint gelöscht. Das hört sich ziemlich nach dem an, was Du zu schreiben versuchst.

[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