CODEWITHSUNDEEP
linuxdebuggingprofilingptraceintel-pin
G Ashwin
G Ashwin

Reputation: 23

Profiling anti-debugging checks in linux

My main requirement is to profile the mentioned anti-debugging check program twice ( Once in the presence of a debugger and the other without it ) to collect some information for analysis during run-time (Assuming only the binary is available)

#include <stdio.h>
#include <sys/ptrace.h>

int i_am_debugged()
{
    if (ptrace(PTRACE_TRACEME, 0, 1, 0) < 0) 
     {  
            printf("Avoid debugging please");
        return 1;
     }

    return 0;
}

int main()
{
    if(i_am_debugged())
    {
        return 1;
    }

  printf("It's going well ! No debugging !\n");

return 0;

}

Currently , I wrote a Intel PIN tool for the same but I am unable to profile a run when a debugger is not attached because of the way PIN works and always executes 'It's going well ! No debugging !'.

So, my question:

Is there anything I can do (attach a debugger and run the pin tool or something) to profile both types of runs using my PIN tool or will any other type of profiling (for ex Binary translation, etc) help me in this case?

I want to collect specific information about instructions and not just Call graph,etc and hence would like some functionality similar to PIN's C++ programmer interface.

A detailed answer would be great, Thanks.

Upvotes: 0

Views: 783

Answers (2)

nitzanms
nitzanms

Reputation: 1718

Pin uses ptrace to inject itself into the application. This means that using gdb won't be possible when attempting to launch an application with Pin, and also that Pin won't successfully attach to an application that is being debugged.

My suggestion is to start Pin with the -pause_tool knob, and then attach gdb to the process. This will make the application's ptrace call return what you want.

Upvotes: 1

Felix M.
Felix M.

Reputation: 246

I hope i get what you want.

Intel PIN is NOT a debugger. It's more like a VM which on-the-fly instruments binary code (for x86/x64) and then executes this freshly instrumented code. Because PIN is not opensource, it's internals are rather "secret" ;). But its CLEARLY not a debugger.

If i understand you correctly you want some sort of test-suite which runs your application twice, one time with a debugger attached and one time without? Then you probably should use gdb.

Just start:

./a.out for the normal run

and e.g. (this one is a little hacky ;-) ) for the debugger-run:

Create a file mygdbscript (needs arguments to gdb like: gdb -x ./mygdbscript)

The content of this file is just:

# you probably dont want gdb to stop under ANY circumstances
# as this is an automatic check. So pass all signals to the application.
handle all nostop print pass
run
quit

Then run with gdb -x ./mygdbscript --args ./a.out

Hope this helps :)

Upvotes: 0

Related Questions