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.