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 -
March 18th, 2008 at 11:45 am
BTW, if EIP/RIP has been subverted to this point, you have a clear security issue in your code
April 28th, 2008 at 6:23 pm
[…] 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 […]
June 4th, 2009 at 10:34 am
[…] 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 […]
April 10th, 2010 at 12:25 am
[…] 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/ […]
October 18th, 2010 at 2:09 pm
[…] 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 […]
February 19th, 2017 at 10:23 am
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