0

I'm trying to obtain a routine name for libc functions (e.g., scanf in this case) with the Intel PIN instrumentation. After trying a lot of ways, I am under the belief that this is difficult, but I figured to ask first.

For the sake of brevity, below is a minimal example of an input binary source code and Intel PIN instrumentation code of what I have tried, I feel that the result is close, yet missing the final detail.

Example source code (test.c):

#include <stdio.h>
#include <stdlib.h>

void foo(char *buffer) {
    scanf("%s", buffer);
    printf("Unsafe gets: %s\n", buffer);
    
}

int main() {
    char *buf = malloc(sizeof(char)*50);
    foo(buf);
    return 0;
}

Intel PIN instrumentation source code (test_pin.so):

VOID do_call(ADDRINT addr)
{
    printf("%p - %s\n", (void*)addr,  RTN_FindNameByAddress(addr).c_str());
    //fprintf(trace, "\n[%s]\n",  RTN_FindNameByAddress(addr).c_str())); 
    //fflush(trace);
}

VOID Instruction(INS ins, VOID *v)
{
    if (INS_IsCall(ins))
    {
        if (INS_IsDirectBranchOrCall(ins))
        {
            const ADDRINT addr = INS_DirectBranchOrCallTargetAddress(ins);
            INS_InsertPredicatedCall(ins, IPOINT_BEFORE, AFUNPTR(do_call),
                IARG_PTR, addr, IARG_FUNCARG_CALLSITE_VALUE, 0, IARG_END);

        }
    }
}
int main(int argc, char **argv)
{
    /* initialize symbol processing */
    PIN_InitSymbols();
    /* initialize Pin; optimized branch */
    if (unlikely(PIN_Init(argc, argv)))
        /* Pin initialization failed */
        goto err;
    INS_AddInstrumentFunction(Instruction, 0);

    /* start Pin */
    PIN_StartProgram();

    /* typically not reached; make the compiler happy */
    return EXIT_SUCCESS;
}

So the reason why I'm saying that I feel somewhat close is that running the above Intel PIN Instrumentation using the command pin -t test_pin.so -- ./test will result in the following output:

...
0x7f27aac14280 - brk                         
0x7f27aac142e0 - sbrk                        
0x7f27aab97a70 - pthread_attr_setschedparam
0x55a6dcbb8189 - foo                         
0x55a6dcbb8090 - .plt.sec           
0x7f27aab63a00 - psiginfo           
0x7f27aab91c30 - __uflow            
0x7f27aab91e80 - _IO_doallocbuf
...

where we can observe that two addresses start with 0x5 (to indicate that this is from the main application rather than calling from a shared library such as 0x7):

  • 0x55a6dcbb8189 - foo
  • 0x55a6dcbb8090 - .plt.sec

Doing additional investigation using objdump or gdb of the above source code example, it can be found that the entry address of foo function and the mystery target of .plt.sec from the Intel PIN is (after removing the relocation base address):

0000000000001189 <foo>:    
   ...
 11ac:       e8 df fe ff ff          call   1090 <__isoc99_scanf@plt>

So instead of getting the output of .plt.sec, is it possible to somehow resolve this mysterious .plt.sec name into __isoc99_scanf? I would appreciate any suggestions.

Jay
  • 373
  • 1
  • 10
  • https://rpmfind.net/linux/rpm2html/search.php?query=glibc-debuginfo – Hans Passant Dec 06 '22 at 20:55
  • Thank you for your reply @HansPassant I think that is probably the right direction, although I could not spend enough time to apply it on my PIN instrumentation. For those who might be curious, how I managed to solve this issue was to figure out the offset address using `IMG_LoadOffset` command and then use that to calculate the function address, which can be reverse-engineered using programs such as `radare2`. – Jay Dec 27 '22 at 22:55

0 Answers0