Crash Dump Analysis Patterns (Part 55)

Now it’s time to write about Wild Pointer pattern I briefly mentioned in Local Buffer Overflow post which shows examples of pointers having UNICODE structure in their values. I have also observed pointers with ASCII structure as .formats WinDbg command indicates:

FAILED_INSTRUCTION_ADDRESS: 
65747379`735c5357 ??              ???

IP_ON_HEAP:  65747379735c5357

0:012> .formats rip
Evaluate expression:
  Hex:     65747379`735c5357
  Decimal: 7310595060592825175
  Octal:   0625643467456327051527
  Binary:  01100101 01110100 01110011 01111001 01110011 01011100 01010011 01010111
  Chars:   etsys\SW
  Time:    Wed May 10 22:00:59.282 24767 (GMT+1)
  Float:   low 1.7456e+031 high 7.21492e+022
  Double:  5.30388e+180

Here is another example of a pointer having UNICODE structure:

FAILED_INSTRUCTION_ADDRESS: 
0045004c`00490046 ??              ???

0:014> .formats rip
Evaluate expression:
  Hex:     0045004c`00490046
  Decimal: 19422099815333958
  Octal:   0001050004600022200106
  Binary:  00000000 01000101 00000000 01001100 00000000 01001001 00000000 01000110
  Chars:   .E.L.I.F
  Time:    Wed Jul 19 07:46:21.533 1662 (GMT+1)
  Float:   low 6.70409e-039 high 6.33676e-039
  Double:  2.33646e-307

When we have EIP or RIP pointers I have another pattern to name when the value is coincidentally lies inside some valid region of memory: Wild Code. Here is one example of the latter pattern I’m going to write about soon:

IP_ON_STACK:
+e11ffa8

STACK_TEXT:
0e11ff7c 098eeef2 0xe11ffa8
0e11ff84 77b6b530 dll!StartWorking+0xcab
0e11ffb8 7c826063 msvcrt!_endthreadex+0xa3
0e11ffec 00000000 kernel32!BaseThreadStart+0×34

0:020> u
0e11ffa8 dcff fdiv st(7),st


We see that EIP is very close to EBP/ESP and this explains why !analyze -v reports IP_ON_STACK. Clearly floating-point code is not what we should expect. This example shows that wild pointers sometimes are valid but either through code chain or pointer chain execution reaches Invalid Pointer and a process or a system crashes.

- Dmitry Vostokov @ DumpAnalysis.org -

6 Responses to “Crash Dump Analysis Patterns (Part 55)”

  1. newsoft Says:

    BTW, if EIP/RIP has been subverted to this point, you have a clear security issue in your code :)

  2. Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 6a) Says:

    […] the pointer value to be non-NULL might not work if the pointer value is random (Wild Pointer pattern) but at least it eliminates this class of problems. NULL pointers can be NULL data […]

  3. Crash Dump Analysis » Blog Archive » Manual dump, virtualized process, stack trace collection, multiple exceptions, optimized code, wild code pointer, incorrect stack trace and hidden exception: pattern cooperation Says:

    […] code is through an invalid address 0×161dc2c so we might guess that this was an instance of wild code pointer or the case of incorrect stack trace. However using techniques to get exception context from hidden […]

  4. Software Generalist » Blog Archive » Reading Notebook: 09-April-10 Says:

    […] m_CodeOrIL: 00920070 (p. 61) - the address looks like as UNICODE string but I belive this is just a coincidence, the false positive of Wild Pointer pattern: http://www.dumpanalysis.org/blog/index.php/2008/03/11/crash-dump-analysis-patterns-part-55/ […]

  5. Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 110) Says:

    […] call stack) boundaries. Its effect is visible when the buffer data contains pointers that become wild after the overwrite and are later dereferenced resulting in a crash. For example, when the […]

  6. Dmitry Vostokov Says:

    Another example:

    0:001> k
    # Child-SP RetAddr Call Site
    00 00000005`8d71deb8 00007ffb`322b918f ntdll!NtWaitForMultipleObjects+0xa
    01 00000005`8d71dec0 00007ffb`322b908e KERNELBASE!WaitForMultipleObjectsEx+0xef
    02 00000005`8d71e1c0 00007ffb`32c2155c KERNELBASE!WaitForMultipleObjects+0xe
    03 00000005`8d71e200 00007ffb`32c21088 kernel32!WerpReportFaultInternal+0×494
    04 00000005`8d71e770 00007ffb`322e03cd kernel32!WerpReportFault+0×48
    05 00000005`8d71e7a0 00007ffb`34e48cd2 KERNELBASE!UnhandledExceptionFilter+0×1fd
    06 00000005`8d71e8a0 00007ffb`34e34296 ntdll!RtlUserThreadStart$filt$0+0×3e
    07 00000005`8d71e8e0 00007ffb`34e4666d ntdll!_C_specific_handler+0×96
    08 00000005`8d71e950 00007ffb`34dc3c00 ntdll!RtlpExecuteHandlerForException+0xd
    09 00000005`8d71e980 00007ffb`34e4577a ntdll!RtlDispatchException+0×370
    0a 00000005`8d71f080 00007ffb`2fb57749 ntdll!KiUserExceptionDispatch+0×3a
    0b 00000005`8d71f790 00007ffb`2fbafba5 uDWM!CBaseObject::Release+0×15
    0c 00000005`8d71f7c0 00007ffb`2fb9f6dc uDWM!CWindowData::SetIconicBitmap+0×21
    0d 00000005`8d71f7f0 00007ffb`2fbaddde uDWM!`ScalingCompatLogging::Instance’::`2′::`dynamic atexit destructor for ‘wrapper”+0×1497c
    0e 00000005`8d71f820 00007ffb`2fbae13b uDWM!CIconicBitmapRegistry::AcceptBitmap+0×56
    0f 00000005`8d71f860 00007ffb`2fbb9d09 uDWM!CIconicBitmapRegistry::BitmapReceived+0×267
    10 00000005`8d71fa50 00007ffb`2fb9d9b0 uDWM!CWindowList::SetIconicThumbnail+0×105
    11 00000005`8d71fac0 00007ffb`2fb12c0f uDWM!`ScalingCompatLogging::Instance’::`2′::`dynamic atexit destructor for ‘wrapper”+0×12c50
    12 00000005`8d71fc40 00007ffb`2fb1d171 dwmredir!CSessionPort::ProcessCommand+0×34f
    13 00000005`8d71fcf0 00007ffb`2fb1c889 dwmredir!CPortBase::PortThreadInternal+0×241
    14 00000005`8d71fda0 00007ffb`32c12d92 dwmredir!CPortBase::PortThread+0×9
    15 00000005`8d71fdd0 00007ffb`34db9f64 kernel32!BaseThreadInitThunk+0×22
    16 00000005`8d71fe00 00000000`00000000 ntdll!RtlUserThreadStart+0×34

    0:001> .cxr 00000005`8d71f080
    rax=0000000000000001 rbx=00390035003a0039 rcx=00390035003a0039
    rdx=0000000000000000 rsi=00000000ffffffff rdi=00000005919e6f20
    rip=00007ffb2fb57749 rsp=000000058d71f790 rbp=000000058d71f960
    r8=00000000000002e3 r9=00000000000002e3 r10=000000058bcc7630
    r11=000000059400fbd0 r12=000000058bcc7620 r13=00000005920e0000
    r14=0000000000000047 r15=000000000000006c
    iopl=0 nv up ei ng nz na po nc
    cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010286
    uDWM!CBaseObject::Release+0×15:
    00007ffb`2fb57749 f00fc17108 lock xadd dword ptr [rcx+8],esi ds:00390035`003a0041=????????

    0:001> .formats rcx
    Evaluate expression:
    Hex: 00390035`003a0039
    Decimal: 16044301309575225
    Octal: 0000710003240016400071
    Binary: 00000000 00111001 00000000 00110101 00000000 00111010 00000000 00111001
    Chars: .9.5.:.9
    Time: Sat Nov 4 19:02:10.957 1651 (UTC + 0:00)
    Float: low 5.32654e-039 high 5.2347e-039
    Double: 1.39072e-307

Leave a Reply

You must be logged in to post a comment.