So i've been trying to write a pintool that monitors call/ret instructions but i've noticed that threre was a significant inconsistency between the two. For example ret instructions without previous call.

I've run the tool in a console application from which a number of inconsistencies can be observed. Below are the first 3 log entries showing this inconsistency:

1. Call from ntdll!LdrpCallInitRoutine+0x69, expected to return to 7ff88f00502a
2. RETURN to 7ff88f00502a
//call from ntdll!LdrpInitializeNode+0x1ac which is supposed to return at 7ff88f049385 is missing (the previous instruction)
3. RETURN to 7ff88f049385 (ntdll!LdrpInitializeNode+0x1b1)

The above are the first 3 log entries for the call/ret instructions. As one can see, the monitoring appears to start a bit late, at the call found at ntdll!LdrpCallInitRoutine+0x69, after which it returned to the expected address but then returned to 7ff88f049385 without first tracking the call found in the previous instruction.

Any ideas of what could be the fault?

The program is traced with INS_AddInstrumentFunction with a callback that more or less does:

if INS_IsCall(ins) INS_InsertCall(ins,...
if INS_IsRet(ins) INS_InsertCall(ins,...

I've tried the same program on Linux which worked as expected, without any mismatch. Any ideas of the reason behind this behavior?

  • You don't have to use CALL instruction to call a function, you can for example do push back_address; jmp func_address, and it will work as the call instruction
    – morsisko
    Jul 26 '20 at 23:06
  • that's true, but is this what's happening? For example, for some of those "inconsistencies" i have checked, there was always a call instruction before the return address, which makes me believe that they are actually called.
    – tturbox
    Jul 27 '20 at 4:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.