Log in

View Full Version : Runing PIN in IDA 6.4?

Aimless
June 1st, 2013, 23:36
Hello,

I am trying to use PIN (from Intel) as the debugger, so that I can get instruction traces.

The first step, of course, is to download the source code for IDADBG.DLL from hex-rays site and compile it. The compilation was done in VS2010 and successful (not even a single warning).

Now then, I disassembled notepad.exe (remember, everything here is 32bit --- I am using WinXP SP3, with IDA 6.4) and chanced the debugger to PIN.

2769

Pressing OK, I move forward and select the debugging options to further configure my PIN debugger setup. And here it is.

2770

Perfect, no issues so far. Now I run the program in the debugger and here is the error I get:

2771

AND, a configuration box opens up for the PIN parameters. This is how they are filled.

2768

Unfortunately, after saying OK, I get the same error message as in Step 3. And it loops infinitely.

My questions are:

1. Do you think I am configuring PIN correctly?

2. Are there any additional PARAMETERS that need to be given in the last dialog box?

If anyone has successfully managed to get pin running in IDA, please give me a yell.

On a side note, running pin seperately outside IDA, AND also running Dereko's pinlogger, everything is running perfect. But IDA does not seem to want to play.

Any suggestions?

Thank you in advance.

Have Phun
naides
June 2nd, 2013, 06:17
Stupid suggestion: try loading a different .exe that loads at the conventional 0x00400000 memory address, instead of high memory 0x10000000, the way notepad does. Somewhere, someone may have assumed the usual 0x00400000 memory arrangement, and is fucking things up.
Aimless
June 2nd, 2013, 09:18
Quote:
[Originally Posted by naides;94813]Stupid suggestion: try loading a different .exe that loads at the conventional 0x00400000 memory address, instead of high memory 0x10000000, the way notepad does. Somewhere, someone may have assumed the usual 0x00400000 memory arrangement, and is fucking things up.


Thank you. I did. But it didn't work.

Strangely, running PIN (on it's own, without IDA) works. Running Dereko's PINTOOL works. ONLY when combined with IDA, it does not seem to work.

And yes, I did try with a simple EXE (built using cl.exe) and running in 4x range. Nope.

Still waiting for something...

Have Phun
[yAtEs]
June 3rd, 2013, 08:35
For me it works fine, i followed the instructions here https://www.hex-rays.com/products/ida/support/tutorials/pin/pin_tutorial.pdf

i unpacked the pin zip to c:\pin

my pin binary path then becomes: C:\pin\ia32\bin\pin.exe
and my tool path becomes: C:\pin\source\tools\pin\Release

I built the plugin using vc2010 - release/win32
Aimless
June 3rd, 2013, 09:10
Quote:
[Originally Posted by '[yAtEs];94817']For me it works fine, i followed the instructions here https://www.hex-rays.com/products/ida/support/tutorials/pin/pin_tutorial.pdf

i unpacked the pin zip to c:\pin

my pin binary path then becomes: C:\pin\ia32\bin\pin.exe
and my tool path becomes: C:\pin\source\tools\pin\Release

I built the plugin using vc2010 - release/win32


Bang on, yates. Bang on.

But still...nada!

And it's not just my OS (winXP 7)

I did it on a variety of VMs (xp, vista, 7) but no avail.

the only problem I think is, I just opened the solution in VC2010 and rebuilt the same. Mayhaps I should be specifying win32 somewhere?

Let me try.

Thanks for the heads up, though.

Have Phun

PS: Did you download the Apr 11 or Jan 20 version of pin? I am assuming here you went with vc10.
[yAtEs]
June 3rd, 2013, 09:45
I downloaded the april 11th vc10

also after copying the pin folder directly from the idaSDK into the \pin\source\tools folder i loaded vc2010 express manually
then did file/open project/solution on IDADBG.sln then at the top changed Debug to Release, i also had to add
C:\pin\source\include\pin and C:\pin\source\include\pin\gen to my include folder in the studio properties for it to build.

I'm going to eventually play around with editing the IDA plugin to enable and disable block tracing on a chosen function
with a block execution counter for function internal profiling.

Perhaps your IDAsdk does not match your IDA version in some minor way
Aimless
June 3rd, 2013, 10:05
Quote:
[Originally Posted by '[yAtEs];94819']I downloaded the april 11th vc10

also after copying the pin folder directly from the idaSDK into the \pin\source\tools folder i loaded vc2010 express manually
then did file/open project/solution on IDADBG.sln then at the top changed Debug to Release, i also had to add
C:\pin\source\include\pin and C:\pin\source\include\pin\gen to my include folder in the studio properties for it to build.

I'm going to eventually play around with editing the IDA plugin to enable and disable block tracing on a chosen function
with a block execution counter for function internal profiling.

Perhaps your IDAsdk does not match your IDA version in some minor way


Thanks yates. But I did not compile mine from the SDK. Instead, I compiled mine from a seperate download from hex-rays (the source, that is).

Quote:
https://www.hex-rays.com/products/ida/support/freefiles/idapin.zip


So, I guess let me try doing it from the SDK then. Thanks for the drive-by.

Have Phun
Aimless
June 3rd, 2013, 11:42
Right then.

Did the SDK way (yes, the IDA 6.4 release and SDK match -- they're from the same distribution).

Everything compiles ok. Until it comes to the bloody linker. And here is the rush:

Quote:

1>idadbg.obj : error LNK2019: unresolved external symbol __imp__WSAStartup@8 referenced in function "bool __cdecl sockets_startup(void)" (?sockets_startup@@YA_NXZ)
1>idadbg.obj : error LNK2019: unresolved external symbol __imp__accept@12 referenced in function "bool __cdecl init_socket(void)" (?init_socket@@YA_NXZ)
1>idadbg.obj : error LNK2019: unresolved external symbol __imp__listen@8 referenced in function "bool __cdecl init_socket(void)" (?init_socket@@YA_NXZ)
1>idadbg.obj : error LNK2019: unresolved external symbol __imp__bind@12 referenced in function "bool __cdecl init_socket(void)" (?init_socket@@YA_NXZ)
1>idadbg.obj : error LNK2019: unresolved external symbol __imp__htons@4 referenced in function "bool __cdecl init_socket(void)" (?init_socket@@YA_NXZ)
1>idadbg.obj : error LNK2019: unresolved external symbol __imp__setsockopt@20 referenced in function "bool __cdecl init_socket(void)" (?init_socket@@YA_NXZ)
1>idadbg.obj : error LNK2019: unresolved external symbol __imp__socket@12 referenced in function "bool __cdecl init_socket(void)" (?init_socket@@YA_NXZ)
1>idadbg.obj : error LNK2019: unresolved external symbol __imp__recv@16 referenced in function "int __cdecl pin_recv(unsigned int,void *,unsigned int,char const *)" (?pin_recv@@YAHIPAXIPBD@Z)
1>idadbg.obj : error LNK2019: unresolved external symbol __imp__send@16 referenced in function "int __cdecl pin_send(unsigned int,void const *,unsigned int,char const *)" (?pin_send@@YAHIPBXIPBD@Z)
1>C:\pin\source\tools\pin\Release\idadbg.dll : fatal error LNK1120: 9 unresolved externals
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========


Now, all the definitions for the external symbols are given in idadbg.h and idadbg_local.h in the /source/tools/pin directory iteself, which is also, by the way, added as an include path in the project.

And then, bang, the above errors.

Any kind soul willing to tell me just what it is that Ilfak wants here? :P

Have Phun
[yAtEs]
June 3rd, 2013, 11:56
did you open the IDADBG.sln file in vc2010 ?
Aimless
June 3rd, 2013, 12:20
Quote:
[Originally Posted by '[yAtEs];94822']did you open the IDADBG.sln file in vc2010 ?


Yes. In VC2010 Express.

Compiling asks for a lot of .H and .HPP files, but these errors are easily solved using the additional directories.

Then, the Linker starts giving errors saying it cannot find so-and-so lib files. This is also easily corrected with the Additional Dependencies and Additional lib paths in the LINKER and Directories options.

So, it can now find ALL .H and .LIBs. But this is coming around. And yes, I've also included idadbg.h and idadbg_local.h where these external symbols are defined.

On second thoughts, is it possible for you to attach your PIN solution directory? Or even better, attach the released version of IDADBG.DLL that you have managed to compile?

I am using the IDA 6.4 version (before the one with 6.4 service pack).

Thanks

Have Phun
[yAtEs]
June 3rd, 2013, 13:16
sent you a msg, also it might be worth mentioning that the plugin works by setting up sockets communicating
to pin.exe via network so check AV/Firewalls etc. (for you last compiled version of course, or if mine also doesnt work)
Aimless
June 3rd, 2013, 14:27
Quote:
[Originally Posted by '[yAtEs];94824']sent you a msg, also it might be worth mentioning that the plugin works by setting up sockets communicating
to pin.exe via network so check AV/Firewalls etc. (for you last compiled version of course, or if mine also doesnt work)


Solved the errors, not the problem.

You needed to add the ws2_32.lib (winsock32) lib from the Platform SDK. THEN my sample from 6.4 sdk compiled. No errors this time as above.

But still, same problem of my ORIGINAL THREAD STARTER Message. The file can't be loaded, yadda-yadda.

Yes, the firewall is OFF in XP.

I'll try out your release and update the result here.

In the meanwhile, a question --- In my snaps above, if you look at the last one, the one with the window titled "DEBUG APPLICATION SETUP:PIN", is that same for you? I mean, are you using any different ports, or anything additional in the PARAMETERS entry box?

Thanks -- Much appreciated.

Have Phun

UPDATE: Nope, Yates. Your release also gives the exact same error. I'm thinking its probably something, somewhere in my OS that's breaking this up.

To verify this, I just need a small favor. Forget PIN. Just select the normal win32 debugger and open notepad. Travel to the code where it calls ShellAboutW and select any one code (call ds:ShellAboutW). Breakpoint at START. When the debugger hits, run an INSTRUCTION trace. When notepad opens, go to Help->About. WHen you hit the breakpoint, just continue. Then Exit notepad. Now, IDA should have yellowed the traced instructions. Go to the location where it says call ds:ShellABoutW. Are the instructions there yellow? Mine are NOT! That means, even though IDA is covering these instructions, they are not appearing in the trace. But if I use Dereko's IDALOG tool, then these instructions are shown as excuted (hence using PIN in the first place rather than the default win32 debugger). If, on your system, you can see the yellow tracemarks when it calls ds:ShellAboutw, then I know something is definitely wrong with my system.

Thanks for the asssit. REALLY appreciate it. And thanks again for the release.

Have Phun
[yAtEs]
June 3rd, 2013, 16:45
i have the same port number but for hostname mine is blank and doesnt say localhost, not sure that should make a difference.

I set a bpx on the shellaboutw call and start entry point of notepad, when the first breakpoint hit i enabled instruction tracing with the win32 debugger
and continued, upon the break of shellabout(when clicking help about in notepad) i continued and exited notepad.

The code around shellabout was not yellow! however the code at the entrypoint was, so not sure whats going on there, maybe
some buffer issue or bug, but i dont think thats anything related to Pin not working. Weird that you had to do lots of stuff to make it
compile, i just downloaded vc2010, opened the sln and added 2 paths ,, the mystery continues ...

Try load IDA with admin rights, the error msg suggestions the plugin cannot access the target file.
Aimless
June 3rd, 2013, 21:21
Quote:
[Originally Posted by '[yAtEs];94828']
The code around shellabout was not yellow! however the code at the entrypoint was, so not sure whats going on there, maybe
some buffer issue or bug, but i dont think thats anything related to Pin not working. Weird that you had to do lots of stuff to make it
compile, i just downloaded vc2010, opened the sln and added 2 paths ,, the mystery continues ...

Try load IDA with admin rights, the error msg suggestions the plugin cannot access the target file.


Goddamn PIN...such a drama queen! :P

But I digress.

Point 1 --- The reason I wanted to switch to using PIN is because the default win32 debugger does not do a proper path coverage, as evidenced with the lack of yellowing of the areas near the call ds:ShellAboutW in 6.4 (without the service pack, though I am sure that is not one of the problems solved there). If that coverage was working properly, there was no need for me to use PIN in the first place. For me, what it implies is that the next time I do a binary instruction trace, I cannot be sure that IDA 6.4 has done a proper coverage --- if I use the win32 debugger, that is. Not only that, I did it with the 6.1 PRO version also and same thing! The call at call ds:ShellAboutw is not shown anywhere in the trace window (essentially meaning, somewhere the TRACE INSTRUCTION facility in WIN32 debugger, from Version 6.1 onwards, is broken --- Hey Ilfak, if you are lurking on this board, maybe you can do something about it! :P).

Now, if you wait till you hit the call ds:ShellAboutW breakpoint, then SINGLE STEP, the remaining instructions are YELLOWED! This means, that the normal TRACE INSTRUCTION facility "IS" indeed broken. And since version 6.1, I reckon.

So, to counter this, I ran Dereko's PINLOG tool. Now THIS tool actually marks the coverage , including the call to call ds:ShellAboutW and the nearby lines. (Though, its purple, instead of yellow, but I'm not finicky you can change it if you want in the loader.py --- Way to go, Dereko!)

Point 2 --- I took up your suggestion. And I ran pin under IDA running as Administrator. And in the IDA output window, here is the message I get:

Quote:

Connected to IDA PIN controller!
Network error: Not enough space
Connected to IDA PIN controller!
Network error: Not enough space


Well, poring over PIN documents, trying to see what this error is going to do. And wondering if it's PIN release specific, or IDADBG specific.

Thanks for sticking with me for this long. Mucho appreciated Yates.

Will keep this updated.

Have Phun

EDIT: (First Cut) And...the result is...blank! No ideas what the "Network error: Not enough space" means. Tried searching for this on the internet. Too much noise. Continuing search...

EDIT: Now, this is strange. I am now getting another error (after rebooting my machine and doing everything anew). This happens only once. Then, the error in my original message with screenshot number 4 comes up.

2773

AND, in the IDA output window, this error:

Quote:

Connected to IDA PIN controller!
Network error: Not enough space


Unfortunately, this error does not seem to go even after running and re-compiling and running again on ALL 12 versions of PIN available on the PIN download side (Yes, I did that!). Goddamn! What a mess!!! :P

Still trying something here and there...

Yates, you with me still? (heh!). I walked in with my head full of hair. I guess I'm going to walk out bald!! :P And the missus says she's not seen me this glued to the computer since I registered for the membership at brazzers.com [NSFW boys!) :P

Thanks again.

Have Phun
[yAtEs]
June 4th, 2013, 04:46
lol i dont have any further suggestions at this point :P
Aimless
June 4th, 2013, 05:32
Quote:
[Originally Posted by '[yAtEs];94831']lol i dont have any further suggestions at this point :P


But your willingness to engage was HIGHLY appreciated.

Have Phun.
deepzero
June 5th, 2013, 17:04
It looks like you did not link to the winsock library properly.
Try adding it in the project settings or dump this under the relevant include file:

Quote:
#pragma comment(lib, "wsock32.lib"
Inliferty
June 5th, 2013, 18:31
Quote:
[Originally Posted by deepzero;94835]It looks like you did not link to the winsock library properly.
Try adding it in the project settings or dump this under the relevant include file:


This problem would cause the Linker to fail, and since he gets a .dll-File this is not the case.

A few Ideas after looking at the SDK:
.) Attach a debugger to IDA and check if CreateProcess is failing
.) Get some network monitoring tool and check if IDA is listening on port 23946, maybe try to connect with a dummy client to check that it is working.
-> If the port is closed attach a debugger again and break on listen() and see why it fails? (or try another Port Number)
Aimless
June 7th, 2013, 05:58
Quote:
[Originally Posted by deepzero;94835]It looks like you did not link to the winsock library properly.
Try adding it in the project settings or dump this under the relevant include file:



Quote:
[Originally Posted by Inliferty;94836]This problem would cause the Linker to fail, and since he gets a .dll-File this is not the case.

A few Ideas after looking at the SDK:
.) Attach a debugger to IDA and check if CreateProcess is failing
.) Get some network monitoring tool and check if IDA is listening on port 23946, maybe try to connect with a dummy client to check that it is working.
-> If the port is closed attach a debugger again and break on listen() and see why it fails? (or try another Port Number)



Thank you for your contribution. I tried these things out, including shutting down the Win XP default firewall, disabling the AV, (hell, I installed an XP VM without an AV, just for this) and many other things. Just...nothing.

Worse, PIN on it's own works. PINLOG, from Dereko (hey D, hello, again!) works. Just the one from IDA is not working.

Well, will keep on trying. If something new pops up, I'll update this thread again. Or unless someone has a wonderful idea.


Have Phun
zadow
February 3rd, 2014, 16:06
wont you need the pin_user.plw as stated in the plugins.cfg

Code:
;       plugin_name                 filename    hotkey  arg  flags

;       --------------------------- ----------  ------  ---  --------



        ; Debugger plugins

        Windbg_debugger             windbg_user 0       0  DEBUG

        Local_Windows_debugger      win32_user  0       0  DEBUG

        Remote_Windows_debugger     win32_stub  0       0  DEBUG

        Local_Bochs_debugger        bochs_user  0       0  DEBUG

        Local_Linux_debugger        linux_user  0       0  DEBUG

        Remote_Linux_debugger       linux_stub  0       0  DEBUG

        Remote_ARMLinux/Android_debugger armlinux_stub 0 0 DEBUG ; only remote

        Remote_WinCE_debugger       wince_stub  0       0  DEBUG ; only remote

        Local_Mac_OS_X_debugger     mac_user    0       0  DEBUG

        Remote_Mac_OS_X_debugger   mac_stub    0       0  DEBUG

        Remote_Symbian_debugger     epoc_user   0       0  DEBUG ; only remote

        Remote_iPhone_v1.x_debugger iphone_stub 0       0  DEBUG ; only remote

        Remote_GDB_debugger         gdb_user    0       0  DEBUG ; only remote

        PIN_debugger                     pin_user      0       0  DEBUG


the source only build the idadbg.dll
i tried building it for the ida 64 demo but then i noticed that it needed the pin_user, and all the other debuggers uses there own binary(plw) to launch the debugger.
I could be wrong
by the way setting project option to Multi-threaded (/MT) correct the building error.!
Aimless
February 4th, 2014, 08:17
Well, nice to see a reply after so long.

Yes, the plugin is also compiled and put in the correct place.

But I've stopped using PIN now. Something more homegrown works fine for me, these days.

Have phun
zadow
February 4th, 2014, 09:31
They only released the source for idadbg.dll not the pin_user.plw.
I cant seem to find the source for the plugin.
roocoon
February 5th, 2014, 03:00
Trying to get over the frustration by being unable to get rid of the damn irs_recv timeout error that kills IDA, I surfed a bit.
I came across another site with a small IDA section that had a discussion on PIN and its successful compilation.
No point repeating what they said so here's the link:
http://techbliss.org/threads/help-with-plugin-pin-debugger.478/ ("http://techbliss.org/threads/help-with-plugin-pin-debugger.478/")

Interesting threads there too about IDA and Python.
zadow
February 5th, 2014, 03:23
lol thats my site.
I just didnt wanna do any promosion for my own site, on this one.
roocoon
February 5th, 2014, 03:41
Quote:
[Originally Posted by zadow;96099]lol thats my site.
I just didnt wanna do any promosion for my own site, on this one.

Really? I guess I did it for you now
I liked the detailed write-ups in those threads and that's a plus in my book.
zadow
February 5th, 2014, 12:13
Quote:
[Originally Posted by roocoon;96100]Really? I guess I did it for you now
I liked the detailed write-ups in those threads and that's a plus in my book.


To bad im the only Ida freak there
Do you have the compiled pin_user
roocoon
February 5th, 2014, 13:32
Quote:
[Originally Posted by zadow;96105]To bad im the only Ida freak there
Do you have the compiled pin_user

Sorry, I don't.
I haven't looked for it either. Too preoccupied trying to avoid irs_recv errors in vanilla IDA x64.
zadow
February 5th, 2014, 13:37
Connection error/timeout
not sure what Vanilla is ?
IF you mean mac os i made an good thread on remote debugging .via WMware

http://techbliss.org/threads/ida-pro-debugging-via-wmware-linux-os-x.474/#post-1130
roocoon
February 5th, 2014, 13:47
Quote:
[Originally Posted by zadow;96107]Connection error/timeout
not sure what Vanilla is ?

Vanilla as in "I haven't modified any IDA code".

irs_recv is a connection timeout (RPC probably) caused either by some tasks in the system (maybe some protected software), or a signature problem having to do with running IDA Remote x64 on the same machine as IDA.
Pretty obscure problem and not much info around.
zadow
February 5th, 2014, 13:56
what operating system are you using, and does it do it everytime.
roocoon
February 5th, 2014, 14:28
Quote:
[Originally Posted by zadow;96109]what operating system are you using, and does it do it everytime.

I use Win7 SP1 x64.

It does it 95% of the time but only for anything I trace under some application group (different programs, same vendor, dozens of plugins). It started almost a year ago so something must have been modified in my system.

Anyway, we should keep the PIN topic clean.
If you have some ideas to try, we can continue privately or in the thread about the irs_recv problem I have posted here: http://www.woodmann.com/forum/showthread.php?14621-IDA-x64-strange-error
Cheers.