0

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.

Daniel Cheung
  • 4,779
  • 1
  • 30
  • 63
G Ashwin
  • 23
  • 1
  • 6
  • I don't really understand what issue you're running into here. Is the problem you're facing that you're not able to attach the debugger? – nitzanms Feb 13 '16 at 19:27
  • What I want is to attach a debugger and also profile with a pin tool at the same time. Please see Felix's answer and respective comments to know the exact problem I am facing. I have tried instructions in [https://software.intel.com/sites/landingpage/pintool/docs/67254/Pin/html/#APPDEBUG] . But still , gdb is not getting detected when I run the above code under the control of PIN and gdb. – G Ashwin Feb 15 '16 at 05:24
  • I see. Pin uses the Linux debugging interface (ptrace) to inject itself to the application. This makes the interaction between Pin and the debugger difficult. Specifically you can't launch Pin with gdb and get the expected behavior. Additionally, due to how Pin works, things like putting a breakpoint in the debugger won't work as expected. I think your best bet is to launch with Pin and then attach the debugger while Pin waits for you using -pause_tool knob. However, as mentioned before, don't expect to be able to use gdb transparently on the application. – nitzanms Feb 15 '16 at 09:05
  • Thanks, will give that a try. I have tried using -appdebug as given in [https://software.intel.com/sites/landingpage/pintool/docs/67254/Pin/html/#APPDEBUG] but the output still is 'It's going well ! No debugging !' . Do you think a tool like ATOM or others will be better for my use case? Since , I am new to instrumentation and profiling, I don't have much idea. – G Ashwin Feb 15 '16 at 09:52
  • Sorry , the above link should point to Pin Advanced Debugging Extensions , it keeps changing for some reason. And, when you said to pause the pin tool and then attach gdb , you meant to attach gdb to the Pin tool or the application? Attaching to the Pin tool doesn't help right? Also , it will then be pretty similar to -appdebug right? – G Ashwin Feb 15 '16 at 10:08
  • While PinADX acts like a debugger backend, it doesn't use ptrace to achieve its purpose. – nitzanms Feb 15 '16 at 11:13
  • For the purposes of detecting that something is `ptrace`-ing your app, simply attaching the debugger using -pause_tool knob will give you what you need (eg the application's ptrace call should return what you want). – nitzanms Feb 15 '16 at 11:14

2 Answers2

1

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.

nitzanms
  • 1,786
  • 12
  • 35
  • Thanks , that worked. One question , Pin has a section on 'advanced debugging extensions' which specifies -appdebug option for using gdb along with pin to debug the application. But, the -pause_tool is generally used for attaching the debugger to the Pin tool . But , how was the application able to detect gdb in the latter case and not in the former? – G Ashwin Feb 15 '16 at 17:34
  • In the former case, The app debug switch makes pin behave like the gdb backend (aka gdbserver). While it provides the functionality, it doesn't use the same means. Specifically the process isn't being ptraced. In the latter case, the process is being ptraced. – nitzanms Feb 16 '16 at 18:59
  • The pause tool knob simply allows you to attach gdb before code is executed. It is usually used for debugging the tool but it doesn't have to be used that way. – nitzanms Feb 16 '16 at 19:01
  • For more details on how pinadx works, look for the paper titled "PinADX: An interface for customizable debugging with dynamic instrumentation" – nitzanms Feb 16 '16 at 19:04
  • Great, If you have the time , I am stuck with another question too. [http://stackoverflow.com/questions/35454343/profile-32-bit-app-on-64-bit-system-using-intel-pin]. Thanks. – G Ashwin Feb 18 '16 at 04:44
0

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 :)

Felix M.
  • 246
  • 1
  • 6
  • Thanks , but a little clarification. I want to run the program twice , with and without a debugger **along with run-time profiling which is done by the PIN tool in this case** . As I said , I want to collect some run-time information about functions, branches etc and the problem is gdb doesn't provide any custom functionality for profiling like PIN does. Any thoughts? – G Ashwin Feb 12 '16 at 10:21
  • I just managed to do that using the above script invoking `gdb -x ./mygdbscript --args "bash /home//software/pin/pin.sh -t /home//software/.../tool.so -- ./a.out"` But still, straightforward debugging a 'pinized' application can be like fighting windmills... If you only want your ptrace check to work, i think this is fine. If you really want to debug this, you should read the passage in the PIN User Guide "The PIN Advanced Debugging Extensions" (see here https://software.intel.com/sites/landingpage/pintool/docs/67254/Pin/html/#APPDEBUG) – Felix M. Feb 12 '16 at 11:27
  • Okay , I tried both. `gdb -x ./mygdbscript --args /home/.../pin-2.14-71313-gcc.4.4.7-linux/pin -t obj-intel64/mine.so -- /home/.../ptra2` . This gave an error _Program received signal SIGUSR1, User defined signal 1. 0xf7fd9d80 in ?? () A debugging session is active. Inferior 1 [process 28168] will be killed._ Secondly , I ran gdb along with PIN as given in the link but then receive the output _It's going well ! No debugging !_ . Why wasn't gdb detected? – G Ashwin Feb 13 '16 at 06:29
  • Take a look at the other answer. I didn't know up to know that PIN uses ptrace to inject itself. But nice to know! You need some more sophistication in this case, to attach a debugger while launching (see above) – Felix M. Feb 18 '16 at 14:24