Very helpful debugging macro

Index > Macroinstructions > Very helpful debugging macro

Author

Thread

ejamesr

Joined: 04 Feb 2011
Posts: 52
Location: Provo, Utah, USA

ejamesr 26 Oct 2012, 20:20

When debugging with OllyDbg, many times I will put "int 3" at various points where I want the code to stop. BUT... sometimes I can't determine where, exactly, the code has stopped, especially when I have many code paths that are very similar.

So I created this very simple macro that makes it easy for me to find exactly where the code has stopped. It inserts the "int 3", but then includes a string that tells me exactly where I am. Here's the macro:

Code:

macro debug msg
{
    if 1      ; set to 0 to turn off all debug statements
    if msg eq
        int 3
    else
        int       3
        jmp       @f
        db "DBG:"
        db `msg
        db "    ", 0
    @@:
    end if
    end if
}

Assume a code fragment like this:

Code:

MainFunction:
    xor       eax, eax
.Part.a:
    add       eax, 3
; I want to stop here and show the string ".Part.a" at the debug point...
    debug .Part.a   
    add       edx, 5
; Here I want a simple "int 3"...
    debug
    lea        ecx, [esi + 32]
; Here, I want a longer message...
    debug "Stopped at this point..."

This macro will stop execution with the "int 3" command. In OllyDbg, click just after the jmp instruction after the "int 3", the right click and choose Follow In Dump > Selection to see your message in the memory dump view. Your message can be as descriptive as you like if you put quotes around it, otherwise just make sure there are no spaces.

If I don't want any message, I just use "debug" with no parameter, and it inserts a simple "int 3". And if i want to turn off all debugging interrupts, I can comment out the macro statements inside the braces

This makes debugging simpler and faster!

26 Oct 2012, 20:20

Mike Gonta

Joined: 26 Dec 2010
Posts: 240

Mike Gonta 27 Oct 2012, 11:33

The use of local labels in macros instead of anonymous labels prevents conflicts with anonymous labels in the code
that the macro is used in.
The use of a define is so the macro does not need to be edited.
int 3 is two bytes, int3 is one.

Code:

define debugging 1

macro debug msg {
local next
  if defined debugging
    int3
    if ~msg eq
        jmp next
      db "DBG:"
      db `msg
      db "    ", 0
      next:
    end if
  end if
}

_________________
Mike Gonta
one man's journey of discovery

https://the-idiom.com

27 Oct 2012, 11:33

ejamesr

Joined: 04 Feb 2011
Posts: 52
Location: Provo, Utah, USA

ejamesr 27 Oct 2012, 18:55

Very good points, Mike -- but that breaks my code. The problem is that the local label needs a '.' in front so that it doesn't conflict with previous labels. Here's a version with your improvements that works for me:

Code:

define debugging 1

macro debug msg {
local .next
  if defined debugging
    int3
    if ~msg eq
        jmp .next
      db "DBG:"
      db `msg
      db "    ", 0
      .next:
    end if
  end if
}

ejamesr

27 Oct 2012, 18:55

JohnFound

Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria

JohnFound 27 Oct 2012, 20:05

The best practice is to use labels with two dots prefix: "..next". They are global labels, but does not change the current global label set previously.

27 Oct 2012, 20:05

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 19254
Location: In your JS exploiting you and your system

revolution 27 Oct 2012, 21:16

JohnFound wrote:

The best practice is to use labels with two dots prefix: "..next". They are global labels, but does not change the current global label set previously.

Using a single dot here also works just fine.

27 Oct 2012, 21:16

JohnFound

Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria

JohnFound 28 Oct 2012, 03:54

Of course it works. I am talking about "best practice". Using two dots is always safe in such situations.

28 Oct 2012, 03:54

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 19254
Location: In your JS exploiting you and your system

revolution 28 Oct 2012, 04:41

JohnFound wrote:

Of course it works. I am talking about "best practice".

Hmm. Best is subjective.

JohnFound wrote:

Using two dots is always safes in such situation.

One dot is also always safe in such situation.

28 Oct 2012, 04:41

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum