Archive for July 19th, 2012

Crash Dump Analysis Patterns (Part 36, Mac OS X)

Thursday, July 19th, 2012

This is a Mac OS X / GDB counterpart to Local Buffer Overflow pattern previously described for Windows platforms. Most of the time simple mistakes in using memory and string manipulation functions are easily detected by runtime:

(gdb) bt
#0 0x00007fff885e982a in __kill ()
#1 0x00007fff83288b6c in __abort ()
#2 0×00007fff8325a89f in __chk_fail ()
#3 0×00007fff8325a83e in __memcpy_chk ()
#4 0×000000010914edf3 in bar ()
#5 0×000000010914ee5e in foo ()
#6 0×000000010914ee9b in main (argc=1, argv=0×7fff68d4daf0)

This detection happens in a default optimized release version as well:

(gdb) bt
#0 0x00007fff885e982a in __kill ()
#1 0x00007fff83288b6c in __abort ()
#2 0×00007fff8325a89f in __chk_fail ()
#3 0×00007fff8325a83e in __memcpy_chk ()
#4 0×000000010f59cea8 in bar [inlined] ()
#5 0×000000010f59cea8 in foo [inlined] ()
#6 0×000000010f59cea8 in main (argc=,
argv=)

The more sophisticated example which overwrites stack trace without being detected involves overwriting indirectly via a pointer to a local buffer passed to the called function. In such cases we might see incorrect and truncated stack traces:

(gdb) bt
#0 0x00007fff885e982a in __kill ()
#1 0x00007fff83288b6c in __abort ()
#2 0×00007fff83285070 in __stack_chk_fail ()
#3 0×000000010524de77 in foo ()
#4 0xca4000007fff64e5 in ?? ()

(gdb) bt
#0 0x00007fff885e982a in __kill ()
#1 0x00007fff83288b6c in __abort ()
#2 0×00007fff83285070 in __stack_chk_fail ()
#3 0×0000000105ad8df7 in foo ()

Inspection of the raw stack shows ASCII-like memory values around foo symbolic reference instead of expected main and start functions:

(gdb) info r rsp
rsp 0x7fff656d79d8 0x7fff656d79d8

(gdb) x/100a 0x7fff656d79d8
0x7fff656d79d8: 0x7fff83288b6c <__abort+193> 0x0
0x7fff656d79e8: 0x0 0xffffffdf
0x7fff656d79f8: 0x7fff656d7a40 0x7fff656d7a80
0x7fff656d7a08: 0x7fff83285070 <__guard_setup> 0x6675426c61636f4c
0x7fff656d7a18: 0x7265764f726566 0x0
0x7fff656d7a28: 0x0 0x0
0x7fff656d7a38: 0x0 0x73205d343336325b
0x7fff656d7a48: 0x65766f206b636174 0x776f6c6672
0x7fff656d7a58: 0x0 0x0
0x7fff656d7a68: 0x0 0x343336326d7ab0
0x7fff656d7a78: 0x0 0x7fff656d7ab0
0x7fff656d7a88: 0x105ad8df7 0xb1887b8452358ac4
0×7fff656d7a98: 0×794d000000000000 0×6769422077654e20
0×7fff656d7aa8: 0×6666754220726567 0×7265
0×7fff656d7ab8: 0×0 0×0
0×7fff656d7ac8: 0×0 0×0
0×7fff656d7ad8: 0×0 0×0
0×7fff656d7ae8: 0×0 0×0
[…]

The modeling application source code:

void bar(char *buffer)

{

      char data[100] = “My New Bigger Buffer”; 

      memcpy (buffer, data, sizeof(data));

}

 

void foo()

{

    char data[10] = “My Buffer”;

    bar(data);

}

 

int main(int argc, const char * argv[])

{

    foo();

 

    return 0;

}

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Forthcoming Training: Accelerated Mac OS X Core Dump Analysis

Posted in Core Dump Analysis, Crash Dump Patterns, GDB for WinDbg Users, Mac Crash Corner, Mac OS X, x64 Mac OS X | No Comments »

Network Trace Analysis Patterns (Part 1)

Thursday, July 19th, 2012

After some thinking I’ve decided to apply software trace analysis pattern approach to network trace analysis which lacks a unified pattern language. Here I consider a network trace as essentially a software trace where packet headers represent software trace messages coupled with associated transmitted data:

Since we have a trace message stream formatted by a network trace visualization tool we can apply most if not all trace analysis patterns for diagnostics including software narratology for interpretation, discourse and different representations. We provide a few trivial examples here and more in subsequent parts. The first example is Discontinuity pattern:

Other similar patterns are No Activity, Truncated Trace and Time Delta. The second example is Anchor Messages:

Additional example there include Significant Event and Bifurcation Point patterns. Layered protocols are represented through Embedded Message pattern (to be described and added to the pattern list soon). Such traces can be filtered for their embedded protocol headers and therefore naturally represent Adjoint Thread pattern (for the more detailed description of adjoint threads as extension of multithreading please see the article What is an Adjoint Thread):

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Posted in Network Trace Analysis Patterns, Software Behavior Patterns, Software Diagnostics, Software Diagnostics Pattern Language, Software Diagnostics Patterns, Software Narratology, Software Trace Analysis | No Comments »