Software Diagnostics Library

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

Suppose we form an adjoint thread based on some message or operation type or some other attribute:

But we do not know where to start to look backwards for any anomalies relevant to our problem:

We go back to our full trace and find a problem message:

Although it is not in our adjoint thread we formed previously it is still considered as Pivot Message helping us to go backwards there:

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

If Implementation Discourse focuses on objective technology specific discourse then Traces of Individuality pattern focuses on subjective elements in a software log and its messages. Here we mean some specific naming or tracing conventions either from an individual engineer habit or from some corporate coding standard. As an example of it consider a trace message from a catch statement:

"Surprise, surprise, should have never been caught"

More examples for this pattern will be added later.

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

… what an ideal engineer should be in the eyes of his contemporaries: […] a man of hardware and a child of software.

Amir Alexander, From Voyagers to Martyrs

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

There is an extension shortcut to the usual WinDbg command .effmach for 64-bit memory dumps of 32-bit processes:

0:000> .load wow64exts

0:000> !sw

Switched to 32bit mode

0:000:x86> !sw

Switched to 64bit mode

Also !k command will display both thread stacks (32-bit and 64-bit):

0:000> !k
Walking 64bit Stack...
Child-SP          RetAddr           Call Site
00000000`0016e018 00000000`74f9aea8 wow64win!NtUserGetMessage+0xa
00000000`0016e020 00000000`74fecf87 wow64win!whNtUserGetMessage+0x30
00000000`0016e080 00000000`74f72776 wow64!Wow64SystemServiceEx+0xd7
00000000`0016e940 00000000`74fed07e wow64cpu!ServiceNoTurbo+0x2d
00000000`0016ea00 00000000`74fec549 wow64!RunCpuSimulation+0xa
00000000`0016ea50 00000000`77c54956 wow64!Wow64LdrpInitialize+0x429
00000000`0016efa0 00000000`77c51a17 ntdll!LdrpInitializeProcess+0x17e4
00000000`0016f490 00000000`77c3c32e ntdll! ?? ::FNODOBFM::`string'+0x29220
00000000`0016f500 00000000`00000000 ntdll!LdrInitializeThunk+0xe
Walking 32bit Stack...
ChildEBP RetAddr
002cf6a0 76ba790d user32!NtUserGetMessage+0x15
002cf6bc 0048148a user32!GetMessageW+0x33
002cf6fc 004816ec notepad!WinMain+0xe6
002cf78c 755533aa notepad!_initterm_e+0x1a1
002cf798 77e29ef2 kernel32!BaseThreadInitThunk+0xe
002cf7d8 77e29ec5 ntdll_77df0000!__RtlUserThreadStart+0x70
002cf7f0 00000000 ntdll_77df0000!_RtlUserThreadStart+0x1b

However, I don’t recommend its usage in iterative scripts because if something goes wrong at one iteration then all subsequent !sw commands will trigger the wrong machine mode but explicit .effmach will set the correct one.

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

Software Diagnostics Services launches its first cyber satellite to survey the state of cyber space and mine its patterns:

http://www.dumpanalysis.com/cybervostok

Notice a satellite logo: it has an UML 2.0 interface sink similar to Software Diagnostics Institute logo:

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

Injected Symbols pattern can be used to add missing symbols when we have Reduced Symbol Information like it was done previously in this old case study. For example, TestWER module was compiled with static MFC and CRT libraries and its private PDB file contains all necessary symbols including MSG structure. We can load that module into notepad.exe process space and apply symbols:

0:000:x86> lm
start             end                 module name
00fc0000 00ff0000   notepad    (pdb symbols)          c:\mss\notepad.pdb\E325F5195AE94FAEB58D25C9DF8C0CFD2\notepad.pdb
10000000 10039000   WinCRT     (deferred)
727f0000 7298e000   comctl32   (deferred)
72aa0000 72af1000   winspool   (deferred)
72b10000 72b19000   version    (deferred)
72e40000 72e48000   wow64cpu   (deferred)
72e50000 72eac000   wow64win   (pdb symbols)          c:\mss\wow64win.pdb\B2D08CC152D64E71B79167DC0A0A53E91\wow64win.pdb
72eb0000 72eef000   wow64      (deferred)
733d0000 733e3000   dwmapi     (deferred)
735b0000 73606000   uxtheme    (deferred)
746f0000 746fc000   CRYPTBASE   (deferred)
74700000 74760000   sspicli    (deferred)
747c0000 74817000   shlwapi    (deferred)
74830000 7547a000   shell32    (deferred)
755d0000 7564b000   comdlg32   (deferred)
75650000 7567e000   imm32      (deferred)
75770000 75810000   advapi32   (deferred)
75810000 75920000   kernel32   (pdb symbols)          c:\mss\wkernel32.pdb\1C690A8592304467BB15A09CEA7180FA2\wkernel32.pdb
75920000 759b0000   gdi32      (deferred)
759b0000 759f7000   KERNELBASE   (deferred)
75a00000 75b00000   user32     (pdb symbols)          c:\mss\wuser32.pdb\0FCE9CC301ED4567A819705B2718E1D62\wuser32.pdb
75b00000 75b8f000   oleaut32   (deferred)
75be0000 75c7d000   usp10      (deferred)
75ff0000 76009000   sechost    (deferred)
76010000 76100000   rpcrt4     (deferred)
76230000 762dc000   msvcrt     (deferred)
76470000 7647a000   lpk        (deferred)
76480000 7654c000   msctf      (deferred)
76550000 766ac000   ole32      (deferred)
766d0000 76753000   clbcatq    (deferred)
76e40000 76fe9000   ntdll      (deferred)
77020000 771a0000   ntdll_77020000   (pdb symbols)          c:\mss\wntdll.pdb\D74F79EB1F8D4A45ABCD2F476CCABACC2\wntdll.pdb

0:000:x86> .sympath+ C:\DebuggingTV\TestWER\x86
Symbol search path is: srv*;C:\DebuggingTV\TestWER\x86
Expanded Symbol search path is: SRV*c:\mss*http://msdl.microsoft.com/download/symbols;c:\debuggingtv\testwer\x86

0:000:x86> .reload /f /i C:\DebuggingTV\TestWER\x86\TestWER.exe=10000000

0:000:x86> lm
start             end                 module name
00fc0000 00ff0000   notepad    (pdb symbols)          c:\mss\notepad.pdb\E325F5195AE94FAEB58D25C9DF8C0CFD2\notepad.pdb
10000000 10039000   TestWER    (private pdb symbols)  c:\debuggingtv\testwer\x86\TestWER.pdb
727f0000 7298e000   comctl32   (deferred)
72aa0000 72af1000   winspool   (deferred)
72b10000 72b19000   version    (deferred)
72e40000 72e48000   wow64cpu   (deferred)
72e50000 72eac000   wow64win   (pdb symbols)          c:\mss\wow64win.pdb\B2D08CC152D64E71B79167DC0A0A53E91\wow64win.pdb
72eb0000 72eef000   wow64      (deferred)
733d0000 733e3000   dwmapi     (deferred)
735b0000 73606000   uxtheme    (deferred)
746f0000 746fc000   CRYPTBASE   (deferred)
74700000 74760000   sspicli    (deferred)
747c0000 74817000   shlwapi    (deferred)
74830000 7547a000   shell32    (deferred)
755d0000 7564b000   comdlg32   (deferred)
75650000 7567e000   imm32      (deferred)
75770000 75810000   advapi32   (deferred)
75810000 75920000   kernel32   (pdb symbols)          c:\mss\wkernel32.pdb\1C690A8592304467BB15A09CEA7180FA2\wkernel32.pdb
75920000 759b0000   gdi32      (deferred)
759b0000 759f7000   KERNELBASE   (deferred)
75a00000 75b00000   user32     (pdb symbols)          c:\mss\wuser32.pdb\0FCE9CC301ED4567A819705B2718E1D62\wuser32.pdb
75b00000 75b8f000   oleaut32   (deferred)
75be0000 75c7d000   usp10      (deferred)
75ff0000 76009000   sechost    (deferred)
76010000 76100000   rpcrt4     (deferred)
76230000 762dc000   msvcrt     (deferred)
76470000 7647a000   lpk        (deferred)
76480000 7654c000   msctf      (deferred)
76550000 766ac000   ole32      (deferred)
766d0000 76753000   clbcatq    (deferred)
76e40000 76fe9000   ntdll      (deferred)
77020000 771a0000   ntdll_77020000   (pdb symbols)          c:\mss\wntdll.pdb\D74F79EB1F8D4A45ABCD2F476CCABACC2\wntdll.pdb

0:000:x86> kv
ChildEBP RetAddr  Args to Child
0013fe34 75a1790d 0013fe74 00000000 00000000 user32!NtUserGetMessage+0x15
0013fe50 00fc148a 0013fe74 00000000 00000000 user32!GetMessageW+0×33
0013fe90 00fc16ec 00fc0000 00000000 00354082 notepad!WinMain+0xe6
0013ff20 758233aa 7efde000 0013ff6c 77059ef2 notepad!_initterm_e+0×1a1
0013ff2c 77059ef2 7efde000 57785ae5 00000000 kernel32!BaseThreadInitThunk+0xe
0013ff6c 77059ec5 00fc3689 7efde000 00000000 ntdll_77020000!__RtlUserThreadStart+0×70
0013ff84 00000000 00fc3689 7efde000 00000000 ntdll_77020000!_RtlUserThreadStart+0×1b

0:000:x86> dt -r MSG 0013fe74
TestWER!MSG
  +0x000 hwnd             : 0x0007149c HWND__
    +0x000 unused           : ??
  +0×004 message          : 0×113
  +0×008 wParam           : 0×38a508
  +0×00c lParam           : 0n1921500630
  +0×010 time             : 0×2079a177
  +0×014 pt               : tagPOINT
    +0×000 x                : 0n1337
    +0×004 y                : 0n448

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

Sometimes we have Reduced Symbolic Information for modules which can range from stripped or public symbol files to exported only function names. In such cases we can use API function prototypes, structure definitions and possible String Parameters to make sense of function arguments:

0:000:x86> kv
ChildEBP RetAddr  Args to Child
0013fe34 75a1790d 0013fe74 00000000 00000000 user32!NtUserGetMessage+0x15
0013fe50 00fc148a 0013fe74 00000000 00000000 user32!GetMessageW+0×33
0013fe90 00fc16ec 00fc0000 00000000 00354082 notepad!WinMain+0xe6
0013ff20 758233aa 7efde000 0013ff6c 77059ef2 notepad!_initterm_e+0×1a1
0013ff2c 77059ef2 7efde000 57785ae5 00000000 kernel32!BaseThreadInitThunk+0xe
0013ff6c 77059ec5 00fc3689 7efde000 00000000 ntdll_77020000!__RtlUserThreadStart+0×70
0013ff84 00000000 00fc3689 7efde000 00000000 ntdll_77020000!_RtlUserThreadStart+0×1b

The first parameter of GetMessage API is a pointer to MSG structure:

0:000:x86> dt MSG 0013fe74
Symbol MSG not found.

From MSDN we find this structure definition:

typedef struct tagMSG {
    HWND   hwnd;
    UINT   message;
    WPARAM wParam;
    LPARAM lParam;
    DWORD  time;
    POINT  pt;
} MSG, *PMSG, *LPMSG;

0:000:x86> dc 0013fe74 L7
0013fe74  0007149c 00000113 0038a508 7287c5d6  ……….8….r
0013fe84  2079a177 00000539 000001c0           w.y 9…….

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

Sometimes we have a Truncated Stack Trace and need to perform manual stack trace reconstruction of the missing part to get approximate full stack trace. Often we are only able to reconstruct some parts and glue them together perhaps with some missing intermediate frames:

For example, we have this truncated stack trace due to the lack of symbols:

1: kd> k
ChildEBP RetAddr
97543b6c 85adf579 nt!KiTrap0E+0x2ac
WARNING: Stack unwind information not available. Following frames may be wrong.
97543be8 85adf770 myfault+0x579
97543bf4 85adf7fc myfault+0x770
97543c2c 81827ecf myfault+0x7fc
97543c44 81988f65 nt!IofCallDriver+0x63
97543c64 81989f25 nt!IopSynchronousServiceTail+0x1e0
97543d00 8198ee8d nt!IopXxxControlFile+0x6b7
97543d34 8188c96a nt!NtDeviceIoControlFile+0x2a
97543d34 77510f34 nt!KiFastCallEntry+0x12a
0012f9a0 7750f850 ntdll!KiFastSystemCallRet
0012f9a4 77417c92 ntdll!NtDeviceIoControlFile+0xc
0012fa04 00401a5b kernel32!DeviceIoControl+0x14a
0012fa94 7700becf NotMyfault+0x1a5b
0012facc 00000000 USER32!xxxDrawButton+0xc1

Manual stack reconstruction brings this fragment:

1: kd> k L=0012fb94 0012fb94 0012fb94
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012fb94 77001ae8 0x12fb94
0012fc0c 7700286a USER32!UserCallWinProcCheckWow+0x14b
0012fc4c 77002bba USER32!SendMessageWorker+0x4b7
0012fc6c 7700c6b4 USER32!SendMessageW+0x7c
0012fc84 7700c7c9 USER32!xxxButtonNotifyParent+0x41
0012fca0 7700c7e8 USER32!xxxBNReleaseCapture+0xf7
0012fd24 7701632e USER32!ButtonWndProcWorker+0x910
0012fd44 77001a10 USER32!ButtonWndProcA+0x4c
0012fd70 77001ae8 USER32!InternalCallWinProc+0x23
0012fde8 77002a47 USER32!UserCallWinProcCheckWow+0x14b
0012fe4c 77002a98 USER32!DispatchMessageWorker+0x322
0012fe5c 76ff11fc USER32!DispatchMessageW+0xf
0012fe80 76fe98d2 USER32!IsDialogMessageW+0x586
0012fea0 00401cc9 USER32!IsDialogMessageA+0xff
0012ff10 004022ec NotMyfault+0x1cc9
00000000 00000000 NotMyfault+0x22ec

And finally we get the 3rd usual thread start fragment:

1: kd> k L=0012ffa0 0012ffa0 0012ffa0
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012ffa0 77413833 0x12ffa0
0012ffac 774ea9bd kernel32!BaseThreadInitThunk+0xe
0012ffec 00000000 ntdll!_RtlUserThreadStart+0x23

Gluing them together we get this approx. stack trace:

97543b6c 85adf579 nt!KiTrap0E+0x2ac
WARNING: Stack unwind information not available. Following frames may be wrong.
97543be8 85adf770 myfault+0x579
97543bf4 85adf7fc myfault+0x770
97543c2c 81827ecf myfault+0x7fc
97543c44 81988f65 nt!IofCallDriver+0x63
97543c64 81989f25 nt!IopSynchronousServiceTail+0x1e0
97543d00 8198ee8d nt!IopXxxControlFile+0x6b7
97543d34 8188c96a nt!NtDeviceIoControlFile+0x2a
97543d34 77510f34 nt!KiFastCallEntry+0x12a
0012f9a0 7750f850 ntdll!KiFastSystemCallRet
0012f9a4 77417c92 ntdll!NtDeviceIoControlFile+0xc
0012fa04 00401a5b kernel32!DeviceIoControl+0x14a
0012fa94 7700becf NotMyfault+0x1a5b
0012fc0c 7700286a USER32!UserCallWinProcCheckWow+0x14b
0012fc4c 77002bba USER32!SendMessageWorker+0x4b7
0012fc6c 7700c6b4 USER32!SendMessageW+0x7c
0012fc84 7700c7c9 USER32!xxxButtonNotifyParent+0x41
0012fca0 7700c7e8 USER32!xxxBNReleaseCapture+0xf7
0012fd24 7701632e USER32!ButtonWndProcWorker+0x910
0012fd44 77001a10 USER32!ButtonWndProcA+0x4c
0012fd70 77001ae8 USER32!InternalCallWinProc+0x23
0012fde8 77002a47 USER32!UserCallWinProcCheckWow+0x14b
0012fe4c 77002a98 USER32!DispatchMessageWorker+0x322
0012fe5c 76ff11fc USER32!DispatchMessageW+0xf
0012fe80 76fe98d2 USER32!IsDialogMessageW+0x586
0012fea0 00401cc9 USER32!IsDialogMessageA+0xff
0012ff10 004022ec NotMyfault+0x1cc9
0012ffac 774ea9bd kernel32!BaseThreadInitThunk+0xe
0012ffec 00000000 ntdll!_RtlUserThreadStart+0x23

We call this pattern Glued Stack Trace.

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

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

Inter-Correlation analysis between a normal and a problem logs to find a Bifurcation Point (and a possible root cause) becomes a difficult task when both traces come from different environments with widely differing Background Components. Here a new analysis pattern called Sheaf of Activities (borrowed from sheaves from mathematics) can help. Basically this pattern is also a tool in tracking properties of trace message subsets. First we find out important message types around some Activity Region where we hope to find a difference between two traces:

Then we create several Adjoint Threads from different message types, for example, based on operation type or function name:

Then we analyze subtraces separately to find out a bifurcation point in each of them and then use this knowledge to find out differences between the original full traces.

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

The discovery of a “black hole horizon” in a complete memory dump inspired this fictitious malware. There in a dump we discovered an innocuous ASCII message:

fffff880`15925010  fffff880`159250d0 "Dumping physical memory to disk:  80% ."

A little thought and we realized that this page was saved to a page file at the time when only 80% of memory were dumped. So we do not know what were in that page during the rest of the time (and would never know). I guess Cadaver Worms live there spreading from PC to PC and causing blue screens immediately upon infection to minimize discovery. They are not in crash dumps because they relocate themselves during the system dump procedure. They thaw frozen CPUs and send themselves to network. Who would suspect a computer showing a blue screen sending network packets?

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

Out-of-Module Pointer pattern is about pointers to addresses outside the container module range. Typical example here would be some kernel table or structure, for example, a driver IRP dispatch table having pointers to outside that driver module address range. Other examples may include 32-bit SSDT pointing outside nt module range and IDT entries pointing outside hal and expected drivers:

[...]
818809dc 8193c4e7 nt!NtQueryOpenSubKeys
818809e0 8193c76b nt!NtQueryOpenSubKeysEx
818809e4 81a909b0 nt!NtQueryPerformanceCounter
818809e8 819920e7 nt!NtQueryQuotaInformationFile
818809ec 819e34f2 nt!NtQuerySection
818809f0 819f470b nt!NtQuerySecurityObject
818809f4 81a882fe nt!NtQuerySemaphore
818809f8 819eff54 nt!NtQuerySymbolicLinkObject
818809fc 81a8a223 nt!NtQuerySystemEnvironmentValue
81880a00 81a8a831 nt!NtQuerySystemEnvironmentValueEx
81880a04 96ca1a73
81880a08 81a7ac06 nt!NtQuerySystemTime
81880a0c 81a8f913 nt!NtQueryTimer
81880a10 81a7aeeb nt!NtQueryTimerResolution
81880a14 8193985a nt!NtQueryValueKey
81880a18 819e9273 nt!NtQueryVirtualMemory
81880a1c 8199274e nt!NtQueryVolumeInformationFile
81880a20 81a1a655 nt!NtQueueApcThread
[…]

0: kd> lm m nt
start end module name
81800000 81ba1000 nt

Such pointers may also be Raw Pointers but it also could be the case that all pointers are raw in the absence of symbols with only a few outside of the expected range.

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

Raw Pointer pattern is about pointers without matching symbol files. They may be in the expected module range or in some other known module range in the form of module+offset or can be completely out of range of any module from the loaded module list and therefore just a number. For example, usually we have certain structures or arrays (tables) where we expect pointers with matching symbols such as IAT, IDT and 32-bit SSDT where an occurrence of a raw pointer immediately triggers a suspicion such as in this Import Address Table from ProcessA:

[...]
00000001`3f8a9048 00000000`76e282d0 ntdll!RtlSizeHeap
00000001`3f8a9050 00000000`76bf9070 kernel32!GetStringTypeWStub
00000001`3f8a9058 00000000`76c03580 kernel32!WideCharToMultiByteStub
00000001`3f8a9060 00000000`76e33f20 ntdll!RtlReAllocateHeap
00000001`3f8a9068 00000000`76e533a0 ntdll!RtlAllocateHeap
00000001`3f8a9070 00000000`76bfc420 kernel32!GetCommandLineWStub
00000001`3f8a9078 00000001`3f8a1638 ProcessA+0×10ac
00000001`3f8a9080 00000000`76c2cc50 kernel32!IsProcessorFeaturePresent
00000001`3f8a9088 00000000`76c02d60 kernel32!GetLastErrorStub
00000001`3f8a9090 00000000`76c02d80 kernel32!SetLastError
00000001`3f8a9098 00000000`76bf3ee0 kernel32!GetCurrentThreadIdStub
[…]

Note that structures are not limited to the above and can me any OS or even application specific structure where we have symbol files. Raw pointers that are outside of expected module range are covered in the next pattern.

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

Hooksware pattern originally came from memory dump analysis pattern catalog and is too general for malware analysis pattern catalog. So we decided to factor out 3 separate patterns. The first one is called Patched Code and includes cases such as in-place patching:

0:004> u ntdll!ZwQueryDirectoryFile
ntdll!ZwQueryDirectoryFile:
77814db4 b8da000000      mov     eax,0DAh
77814db9 bae8af0500      mov     edx,5AFE8h
77814dbe ff12            call    dword ptr [edx]
77814dc0 c22c00          ret     2Ch
77814dc3 90              nop
ntdll!NtQueryDirectoryObject:
77814dc4 b8db000000      mov     eax,0DBh
77814dc9 ba0003fe7f      mov     edx,offset SharedUserData!SystemCallStub (7ffe0300)
77814dce ff12            call    dword ptr [edx]

and detour patching:

0:004> u wininet!InternetReadFile
wininet!InternetReadFile:
7758654b e98044ac88      jmp     0004a9d0
77586550 83ec24          sub     esp,24h
77586553 53              push    ebx
77586554 56              push    esi
77586555 57              push    edi
77586556 33ff            xor     edi,edi
77586558 393db8116277    cmp     dword ptr [wininet!GlobalDataInitialized (776211b8)],edi
7758655e 897df4          mov     dword ptr [ebp-0Ch],edi

In case of WinDbg such pattern is usually detected on the crash spot such as from RIP Stack Trace or from !chkimg command output.

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

Indexical Trace pattern describes an Inter-Correlation pattern variant when we have a trace that has messages of interest pointing to specific activity regions in another trace. The latter trace can be very huge, from another computer and split into many parts (Split Trace). This pattern is very helpful when the problem needs to be diagnosed in the large split trace but we don’t know when it happened. Then an index trace that may have recorded software execution account (for example, in the case of a broker-like architecture) and can point to the right trace fragment from the split trace.

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

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

If debugging were profitable, everybody would be debugging.

Thomas More

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

Steps:

1. Open a crash dump or attach WinDbg to a process you can sacrifice.

2. Enter this command: eb rsp <UNICODE string> [00 00]

0: kd> eb rsp 42 00 65 00 65 00 74 00 68 00 6F 00 76 00 65 00 6E 00 3A 00 20 00 53 00 79 00 6D 00 70 00 68 00 6F 00 6E 00 69 00 65 00 73 00 20 00 31 00 20 00 61 00 6E 00 64 00 20 00 33 00 00 00

Note: use esp for a 32-bit dump. Last NULL terminators 00 00 are not necessary if the string already has them.

3. Enter this command: du rsp

0: kd> du rsp
fffff880`15925ae8  "Beethoven: Symphonies 1 and 3"

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

As usual a new pattern arises with the need to communicate analysis findings. Most often when analyzing malware we don’t have symbol files (No Component Symbols) for an Unknown Module. By looking at IAT (if any present) we can guess module purpose. Sometimes a module itself is not malicious but is used in the larger malicious context such as screen grabbing:

[...]
10002000  76376101 gdi32!CreateCompatibleDC
10002004  763793d6 gdi32!StretchBlt
10002008  76377461 gdi32!CreateDIBSection
1000200c  763762a0 gdi32!SelectObject
10002010  00000000
10002024  77429ced user32!ReleaseDC
10002028  77423ba7 user32!NtUserGetWindowDC
1000202c  77430e21 user32!GetWindowRect
10002030  00000000
10002034  744a75e9 GdiPlus!GdiplusStartup
10002038  744976dd GdiPlus!GdipSaveImageToStream
1000203c  744cdd38 GdiPlus!GdipGetImageEncodersSize
10002040  744971cf GdiPlus!GdipDisposeImage
10002044  744a8591 GdiPlus!GdipCreateBitmapFromHBITMAP
10002048  744cdbae GdiPlus!GdipGetImageEncoders
[...]

There are also cases where these API names are not in IAT but found as String Hint in raw data such LoadLibrary / GetProcAddress and even a group of modules themselves as a collective API:

[...]
00058e20  "kernel32.dll"
00058e3c  "user32.dll"
00058e54  "ws2_32.dll"
00058e6c  "ntdll.dll"
00058e80  "wininet.dll"
00058e98  "nspr4.dll"
00058eac  "ssl3.dll"
[...]

We name this pattern Namespace.

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