Page 2 of 2 FirstFirst 12
Results 16 to 28 of 28

Thread: pinlog

  1. #16
    Pin 2.11 kit 49303
    E: Pintool version does not match pin
    Pin: @CHARM-VERSION: $Id: version.cpp 49303 2012-04-03 18:22:23Z nshalev $
    Tool: @CHARM-VERSION: $Id: version.cpp 53241 2012-08-06 11:18:41Z tevi $

  2. #17
    Ah, you need latest pin tool :

    This should solve your problem.

  3. #18
    ok. how to see the log ?

    This tool is better than the usual trace ?

    In my not

  4. #19
    Ah, you need IDA with python support so you can use to load log into IDA. This is the plugin you need for it :

    By default it comes with IDA, I even think that demo IDA 6.3 comes with it, or at least leaked version from ESET should have it (if I recall correctly it should be 6.1)

  5. #20
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Blog Entries
    Strange, I can't get it working under XP or Win7 VM either. The PATH variable is correct, else pin.exe would never run.

    Process Monitor indicates everything is going well until notepad tries to load trace.dll, then the process exits without starting up. The following output shows some relevant loading steps, the first column is the log index, so the sequential numbers show how LoadImage/trace.dll is immediately followed by a ThreadExit.

     10983    pin.exe    2528    Process Create    c:\pinlog\bin\notepad.exe    SUCCESS    PID: 136, Command line: "c:\pinlog\bin\notepad.exe"
     10984    notepad.exe    136    Process Start        SUCCESS    Parent PID: 2528
     10985    notepad.exe    136    Thread Create        SUCCESS    Thread ID: 1912
     11080    notepad.exe    136    Load Image    C:\pinlog\bin\NOTEPAD.EXE    SUCCESS    Image Base: 0x1000000, Image Size: 0x14000
     11082    notepad.exe    136    Load Image    C:\WINDOWS\system32\ntdll.dll    SUCCESS    Image Base: 0x7c900000, Image Size: 0xb2000
     11262    notepad.exe    136    Load Image    C:\WINDOWS\system32\kernel32.dll    SUCCESS    Image Base: 0x7c800000, Image Size: 0xf6000
     11305    pin.exe    2528    Load Image    C:\pintools\ia32\bin\pinvm.dll    SUCCESS    Image Base: 0x54000000, Image Size: 0x4a8000
     11332    notepad.exe    136    Load Image    C:\pintools\ia32\bin\pinvm.dll    SUCCESS    Image Base: 0x54000000, Image Size: 0x4a8000
     11358    notepad.exe    136    Load Image    C:\pinlog\bin\pin32\trace.dll    SUCCESS    Image Base: 0x55000000, Image Size: 0x1e7000
     11359    notepad.exe    136    Thread Exit        SUCCESS    User Time: 0.0156250, Kernel Time: 0.0156250
     11360    notepad.exe    136    Process Exit    SUCCESS    Exit Status: -1, User Time: 0.0312500, Kernel Time: 0.0156250
    I'll have to try to debug trace.dll loading to see if it gets as far as PIN_StartProgram().

    And also test pintools independantly of pinlog to see if there's some configuration step I need for my system. Deroko, do you have a recommendation how I should do that? Build one of the pin example tools and test that?

  6. #21

    As Above

    Hello K.

    You're not supposed to run pin.exe AT ALL. You're not even supposed to TOUCH anything from the intel pintools directory, except to unzip and put its path in the system variable.

    To generate a log, You'll need to run pinlog.exe from dereko's zipped files.

    Ignore this if that's what you are doing.

    Have Phun
    Blame Microsoft, get l337 !!

  7. #22
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Blog Entries
    Hi A.

    Yeah, "pinlog c:\pinlog\bin\notepad.exe notepad.exe notepad.log" is the only command I execute. Pintools is untouched in its own PATH defined directory.
    In turn pin.exe starts up, which executes notepad which begins loading its system dlls as normal. Then trace.dll gets loaded as indicated by the Process Monitor log, but notepad immediately exits, followed soon after by pin.exe then pinlog.exe, with no logfile created.

    Unless I've really fouled up something, several times, I can't understand why notepad just doesn't continue to load and display. That's why I wanted to test pintools by itself to see if there's some config or system setting required, unique to my system for some unknown reason.

  8. #23
    If there is pin.log generated by pintool, can you post it's content, so I can see what went wrong? Becuase from your loading trace, seems that process exits, so it might be older version of pintool, or some other error, but I can see this only from pin.log, which should be located in same directory from where you started pinlog.exe.

    @Kayaker, you can also run trace.dll as standalone as, pinlog.exe just allocated 50mb shared memory with low integrity so even sandboxed processes with low integrity can write to it:
    pin -follow_execv 1 -t <path_to_trace.dll> -- notepad.exe
    Last edited by deroko; November 17th, 2012 at 05:27.

  9. #24
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Blog Entries
    Quote Originally Posted by deroko View Post
    I've used, and compiled trace.dlls with version for msvc9 (although any of them should be fine).
    Apparently not. Unfortunately pintools only seems to generate a pin.log error log when the Revision number is different from the compiled Tool (like the error Indy got), but not when the compiler version used is different (which is what my problem was).

    To explain, I had originally downloaded the Rev. 53271 vc10 version of pintools, since I have vc10 and was envisioning recompiling the examples etc.

    Pinlog didn't work, but no error log was produced. I then used the Rev. 53271 vc9 version, which is what pinlog was compiled with, and finally got it working (yay!). I *thought* I had done that originally before I mentioned the problem, but must have screwed that up.

    I tried another malware analysis Tool example I found that had been compiled with Rev. 33543 vc8 version of pintools, and this one did give me a pinlog.log error log explaining the problem (mismatching Pin and Tool CHARM-VERSION).

    So unfortunately it seems you need the exact Revision *and* compiler version of pintools to run someone elses Tool. If the Revision number is incorrect, you will get an error log. If the compiler version is incorrect, you won't get an error log, which makes it even more confusing.

    Maybe someone else can confirm all this, but that's what my evidence points to. Just means you have to recompile a tool from source, but does make it a bit annoying when you want to share your tool with others.

    I did do some reversing on the problem before I came to a solution. I used Softice BPLOAD to break on trace.dll being loaded, followed that back to pintools pinvm.dll which calls the Tool (trace.dll) main() function. It quietly crashed in PIN_Init(argc, argv). A loop was being called, trying to match a string. When it wasn't found it seemed to record an unlogged "could not find match for attribute" error and simply exited. Further details are probably moot at this point.

    In any case, thanks for the tool Deroko and the introduction to Pintools. I used it on a upx packed file and it definitely highlights the most used loops. I wonder how many color ranges vs execution counts could be defined before the display got nauseating to look at?


  10. #25
    Glad it worked so after all tool and version used to compile have to match. Luckily I've provided sources, and makefile for sources

    Regarding colors, it's tough question. In my experiments everything more than 13 colors makes your eyes go crazy That why I use stepping of 10 execs to advance to next color. What I did, is to use this python script to find colors which would show the best count of executed instructions, and still not kill your eyes when having some code executed too many times:

    import colorsys
    import idaapi
    import idc
    some_random_func = 0x00402A17;
    #clear colors, so I can rerun code...
    function = idaapi.func_item_iterator_t();
    b_ok = function.first();
    for x in range(0, 25):
            ea = function.current();
            idc.SetColor(ea, CIC_ITEM, 0xFFFFFFFF);
    r = 0x00/255.0;
    g = 0x00/255.0;
    b = 0xff/255.0;
    dec = 0.0;
    #do colors again...
    function = idaapi.func_item_iterator_t();
    b_ok = function.first();
    (h,s,v) = colorsys.rgb_to_hsv(r,g,b);
    s -= 0.35;
    (r,g,b) = colorsys.hsv_to_rgb(h,s,v);
    for x in range(0, 15):
            (h,s,v) = colorsys.rgb_to_hsv(r,g,b);
            s -= dec;
    	(r,g,b) = colorsys.hsv_to_rgb(h,s,v);
    	ida_color = (int(b*255) << 16) + (int(g*255) << 8) + int(r*255);
            ea = function.current(); 
            idc.SetColor(ea, CIC_ITEM, ida_color);
            dec = 0.04;
    At the end what could have been done is to keep blue for all instructions in, lets say 0-100 execs, green 100-200, and above 200 as red, which is easy to implement, and would give even better overview of how many times instructions are executed

  11. #26
    What does this subj when it detects the sysgate(sysenter/syscall/int 2e) ?

  12. #27
    Well syscalls, it's up to pin to handle it, and it handles it properly

  13. #28
    In case someone needs, pinlog doesn't support the redirection operator > such as: pinlog.exe c:\victim\victim.exe victim.exe > log.log
    You should use: pinlog.exe c:\victim\victim.exe victim.exe > log.log
    like the example in readme.txt .


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts