0

I am implementing an exception handling function using Pin. In my exception handling code, I particularly search for memory access error, say, memory read error and memory write error. I wrote some code below:

BOOL catchSignalTest(THREADID tid, INT32 sig, CONTEXT *ctx, BOOL hasHandler, const EXCEPTION_INFO *pExceptInfo, VOID *v)
{
    ADDRINT exptAddr = PIN_GetExceptionAddress(pExceptInfo);
    ADDRINT exptAddr = PIN_GetExceptionAddress(pExceptInfo);
    FAULTY_ACCESS_TYPE ty = PIN_GetFaultyAccessType(pExceptInfo); <----- ty is unknown type!!!
}

.....
 PIN_InterceptSignal(SIGSEGV, catchSignalTest, 0);

What really confuses me is that, even for a typical memory read access error below:

mov eax, [ebx] <--- ebx = 0x01, which makes the read operation failed

The FAULTY_ACCESS_TYPE of my code above is still UNKNOWN. Note that according to its definition, I suppose the access type should be FAULTY_ACCESS_READ.

Am I doning anything wrong here?

lllllllllllll
  • 8,519
  • 9
  • 45
  • 80

1 Answers1

1

Before you call PIN_GetFaultyAccessType, you probably want to:

(1) call PIN_GetExceptionCode to get the EXCEPTION_CODE

(2) call PIN_GetExceptionClass to get the EXCEPTION_CLASS

as the fault access type may only be valid/useful if the class is EXCEPTCLASS_ACCESS_FAULT

At a guess, since you're accessing an odd location [with a 32 bit word fetch], the PIN library may set [probably sets] the x86's hardware "alignment check" (#AC) bit.

Then, you'll get EXCEPTCODE_ACCESS_MISALIGNED which would explain the results you get for the type (e.g. the alignment gets checked first, before the access). Since it's an alignment exception, the other access type codes don't really fit.

IMO, if the PIN library does not set #AC, then, EXCEPTCODE_ACCESS_MISALIGNED is kind of a pointless NOP.

You could try various ebx values like 4 against a known page that you changed the memory protections on (e.g. generate an access exception that you know is not also misaligned).

Craig Estey
  • 30,627
  • 4
  • 24
  • 48
  • Hello, thank you a lot for your reply! I tried the `PIN_GetExceptionClass` API, and got the `EXCEPTCLASS_ACCESS_FAULT` return value. So it seems that Pin is able to figure out the correct reason for the exception... – lllllllllllll Mar 23 '16 at 07:08
  • You're welcome! As noted in your linked API docs, `EXCEPTCODE_ACCESS_MISALIGNED` _is_ part of `EXCEPTCLASS_ACCESS_FAULT` [but it didn't specify what the access type code would be]. Whenever I've been confronted with such an "error code" --> "error class" API, I've usually found it useful to print/deal with both. – Craig Estey Mar 23 '16 at 07:17