Software Diagnostics Library

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 -

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 -

This pattern (we call it String Hint) covers traces of ASCII and UNICODE strings that look suspicious such as website, password and HTTP forms or strange names that intuitively shouldn’t be present according to the purpose of a module or its container process (example is taken from Victimware presentation case study):

0:005> s-sa 00040000 L1d000
0004004d  "!This program cannot be run in D"
0004006d  "OS mode."
00040081  "3y@"
000400b8  "Rich"
000401d0  ".text"
000401f7  "`.rdata"
0004021f  "@.data"
00040248  ".reloc"
[...]
00054018  "GET /stat?uptime=%d&downlink=%d&"
00054038  "uplink=%d&id=%s&statpass=%s&comm"
00054058  "ent=%s HTTP/1.0"
000540ac  "%s%s%s"
000540d8  "ftp://%s:%s@%s:%d"
000540fc  "Accept-Encoding:"
00054118  "Accept-Encoding:"
00054130  "0123456789ABCDEF"
00054144  "://"
00054160  "POST %s HTTP/1.0"
00054172  "Host: %s"
0005417c  "User-Agent: %s"
0005418c  "Accept: text/html"
0005419f  "Connection: Close"
000541b2  "Content-Type: application/x-www-"
000541d2  "form-urlencoded"
000541e3  "Content-Length: %d"
000541fc  "id="
00054208  "POST %s HTTP/1.1"
0005421a  "Host: %s"
00054224  "User-Agent: %s"
00054234  "Accept: text/html"
00054247  "Connection: Close"
0005425a  "Content-Type: application/x-www-"
0005427a  "form-urlencoded"
0005428b  "Content-Length: %d"
000542a4  "id=%s&base="
000542b8  "id=%s&brw=%d&type=%d&data="
000542d8  "POST %s HTTP/1.1"
000542ea  "Host: %s"
000542f4  "User-Agent: %s"
00054304  "Accept: text/html"
00054317  "Connection: Close"
0005432a  "Content-Type: application/x-www-"
0005434a  "form-urlencoded"
0005435b  "Content-Length: %d"
00054378  "id=%s&os=%s&plist="
00054390  "POST %s HTTP/1.1"
000543a2  "Host: %s"
000543ac  "User-Agent: %s"
000543bc  "Accept: text/html"
000543cf  "Connection: Close"
000543e2  "Content-Type: application/x-www-"
00054402  "form-urlencoded"
00054413  "Content-Length: %d"
00054430  "id=%s&data=%s"
00054440  "POST %s HTTP/1.1"
00054452  "Host: %s"
0005445c  "User-Agent: %s"
0005446c  "Accept: text/html"
0005447f  "Connection: Close"
00054492  "Content-Type: application/x-www-"
000544b2  "form-urlencoded"
000544c3  "Content-Length: %d"
000544e0  "GET %s HTTP/1.0"
000544f1  "Host: %s"
000544fb  "User-Agent: %s"
0005450b  "Connection: close"
00054528  "POST /get/scr.html HTTP/1.0"
00054545  "Host: %s"
0005454f  "User-Agent: %s"
0005455f  "Connection: close"
00054572  "Content-Length: %d"
00054586  "Content-Type: multipart/form-dat"
000545a6  "a; boundary=--------------------"
000545c6  "-------%d"
000545d4  "-----------------------------%d"
000545f8  "%sContent-Disposition: form-data"
00054618  "; name="id""
00054630  "%sContent-Disposition: form-data"
00054650  "; name="screen"; filename="%d""
00054670  "Content-Type: application/octet-"
00054690  "stream"
000546a0  "%s(%d) : %s"
000546ac  "%s failed with error %d: %s"
000546c8  "%02X"
000546d8  "BlackwoodPRO"
000546e8  "FinamDirect"
000546f4  "GrayBox"
000546fc  "MbtPRO"
00054704  "Laser"
0005470c  "LightSpeed"
00054718  "LTGroup"
00054720  "Mbt"
00054724  "ScotTrader"
00054730  "SaxoTrader"
00054740  "Program:   %s"
0005474f  "Username:  %s"
0005475e  "Password:  %s"
0005476d  "AccountNO: %s"
[...]

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

Injected code address may not be in the address ranges of loaded modules. In such cases, in the execution call history we would see plain EIP and RIP return addresses on stack traces. We call this pattern RIP Stack Trace partly because we have seen these addresses after something had gone wrong and a process crashed:

0:005> k
ChildEBP RetAddr
02aec974 77655620 ntdll!KiFastSystemCallRet
02aec978 77683c62 ntdll!NtWaitForSingleObject+0xc
02aec9fc 77683d4b ntdll!RtlReportExceptionEx+0x14b
02aeca3c 7769fa87 ntdll!RtlReportException+0x3c
02aeca50 7769fb0d ntdll!RtlpTerminateFailureFilter+0x14
02aeca5c 775f9bdc ntdll!RtlReportCriticalFailure+0x6b
02aeca70 775f4067 ntdll!_EH4_CallFilterFunc+0x12
02aeca98 77655f79 ntdll!_except_handler4+0x8e
02aecabc 77655f4b ntdll!ExecuteHandler2+0x26
02aecb6c 77655dd7 ntdll!ExecuteHandler+0x24
02aecb6c 7769faf8 ntdll!KiUserExceptionDispatcher+0xf
02aecee0 776a0704 ntdll!RtlReportCriticalFailure+0x5b
02aecef0 776a07f2 ntdll!RtlpReportHeapFailure+0x21
02aecf24 7766b1a5 ntdll!RtlpLogHeapFailure+0xa1
02aecf6c 7765730a ntdll!RtlpCoalesceFreeBlocks+0x4b9
02aed064 77657545 ntdll!RtlpFreeHeap+0x1e2
02aed080 75e47e4b ntdll!RtlFreeHeap+0x14e
02aed0c8 77037277 kernel32!GlobalFree+0x47
02aed0dc 774b4a1f ole32!ReleaseStgMedium+0x124
02aed0f0 77517feb urlmon!ReleaseBindInfo+0x4c
02aed100 774d9a87 urlmon!CINet::ReleaseCNetObjects+0x3d
02aed118 774d93f0 urlmon!CINetHttp::OnWininetRequestHandleClosing+0x60
02aed12c 76432078 urlmon!CINet::CINetCallback+0x2de
02aed274 76438f5d wininet!InternetIndicateStatus+0xfc
02aed2a4 7643937a wininet!HANDLE_OBJECT::~HANDLE_OBJECT+0xc9
02aed2c0 7643916b wininet!INTERNET_CONNECT_HANDLE_OBJECT::~INTERNET_CONNECT_HANDLE_OBJECT+0x209
02aed2cc 76438d5e wininet!HTTP_REQUEST_HANDLE_OBJECT::`vector deleting destructor'+0xd
02aed2dc 76434e72 wininet!HANDLE_OBJECT::Dereference+0x22
02aed2e8 76439419 wininet!DereferenceObject+0x21
02aed310 76439114 wininet!_InternetCloseHandle+0x9d
02aed330 0004aaaf wininet!InternetCloseHandle+0x11e
WARNING: Frame IP not in any known module. Following frames may be wrong.
02aed33c 774c5d25 0×4aaaf
02aed358 774c5d95 urlmon!CINet::TerminateRequest+0×82
02aed364 774c5d7c urlmon!CINet::MyUnlockRequest+0×10
02aed370 774c5d63 urlmon!CINetProtImpl::UnlockRequest+0×10
02aed37c 774c5d49 urlmon!CINetEmbdFilter::UnlockRequest+0×11
02aed388 774b743d urlmon!CINet::UnlockRequest+0×13
02aed394 774b73e1 urlmon!COInetProt::UnlockRequest+0×11
02aed3a8 774b7530 urlmon!CTransaction::UnlockRequest+0×36
02aed3b4 774b74e0 urlmon!CTransData::~CTransData+0×3a
02aed3c0 774b74c9 urlmon!CTransData::`scalar deleting destructor’+0xd
02aed3d8 774e221f urlmon!CTransData::Release+0×25
02aed3e0 774b6d0a urlmon!CReadOnlyStreamDirect::~CReadOnlyStreamDirect+0×1a
02aed3ec 774b7319 urlmon!CReadOnlyStreamDirect::`vector deleting destructor’+0xd
02aed404 774b72be urlmon!CReadOnlyStreamDirect::Release+0×25
02aed410 774b71f4 urlmon!CBinding::~CBinding+0xb9
02aed41c 774b71dd urlmon!CBinding::`scalar deleting destructor’+0xd
02aed434 6b20b0e8 urlmon!CBinding::Release+0×25
02aed448 6b20b0ba mshtml!ATL::AtlComPtrAssign+0×2b
02aed458 6b20b8de mshtml!ATL::CComPtr<IBindCallbackInternal>::operator=+0×15
02aed464 6b20b8aa mshtml!CBindingXSSFilter::TearDown+0×2b
02aed46c 6b20b887 mshtml!BindingXSSFilter_TearDown+0×19
02aed478 6b0da61a mshtml!CStreamProxy::Passivate+0×12
02aed484 6b0ddf3a mshtml!CBaseFT::Release+0×1d
02aed4ac 6b0e0b70 mshtml!CDwnBindData::TerminateBind+0×11d
02aed4b8 6b11a2a9 mshtml!CDwnBindData::TerminateOnApt+0×14
02aed4ec 6b105066 mshtml!GlobalWndOnMethodCall+0xfb
02aed50c 7742fd72 mshtml!GlobalWndProc+0×183
02aed538 7742fe4a user32!InternalCallWinProc+0×23
02aed5b0 7743018d user32!UserCallWinProcCheckWow+0×14b
02aed614 7743022b user32!DispatchMessageWorker+0×322
02aed624 6ecac1d5 user32!DispatchMessageW+0xf
02aef72c 6ec5337e ieframe!CTabWindow::_TabWindowThreadProc+0×54c
02aef7e4 760f426d ieframe!LCIETab_ThreadProc+0×2c1
02aef7f4 75e4d0e9 iertutil!CIsoScope::RegisterThread+0xab
02aef800 776319bb kernel32!BaseThreadInitThunk+0xe
02aef840 7763198e ntdll!__RtlUserThreadStart+0×23
02aef858 00000000 ntdll!_RtlUserThreadStart+0×1b

However, such addresses need to be checked whether they belong to .NET CLR JIT code.

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

We skip parts 5 (Module Collection), 6 (No Component Symbols, for looking at import tables), 7 (Stack Trace Collection, for listing active processes, threads and their stack traces), 8 (Hidden Module), and 9 (Hidden Process). The new pattern here is called Driver Device Collection and can be used to compare the current list of device and driver objects with some saved reference list to find out any changes. This listing can be done by using !object command:

0: kd> !object \Driver
[...]

0: kd> !object \FileSystem
[...]

0: kd> !object \Device
[...]

Note that the collection is called Driver Device and not Device Driver.

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

The next pattern is closely linked to packed and/or obfuscated code. We call it Pre-Obfuscation Residue. Depending on a level of obfuscation and/or packing some initial code and data structures and patterns including fragments of strings may leak in post-obfuscation data giving a clue to intended software behavior:

0:000> s-sa 00000000`00fd4000 L6000
[...]
00000000`00fd943d  "o__"
00000000`00fd9449  "91!We"
00000000`00fd945d  "H5!"
00000000`00fd94d2  "zQ@"
00000000`00fd94dd  "ommandS"
00000000`00fd94f4  “IsDeb”
00000000`00fd94fd  “uggerP”
00000000`00fd9507  “Enc”
00000000`00fd950c  “v)3Po4t”
00000000`00fd9515  “DeXU”
00000000`00fd9520  “xFe”
00000000`00fd952a  “5Eb”
00000000`00fd9533  “SI=l8kev”
00000000`00fd953e  “Z_1m”
00000000`00fd9547  “@IF”
[…]

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

Packed Code is frequent ingredient of armored malware. Here we demonstrate a few WinDbg commands to detect UPX packed modules with little or no expected strings:

0:000> !dh 00000000`00fd40b0

File Type: DLL
FILE HEADER VALUES
14C machine (i386)
3 number of sections
time date stamp Fri Jan 18 21:27:25 2013

0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2102 characteristics
Executable
32 bit word machine
DLL

OPTIONAL HEADER VALUES
10B magic #
11.00 linker version
6000 size of code
1000 size of initialized data
F000 size of uninitialized data
15600 address of entry point
10000 base of code
----- new -----
0000000010000000 image base
1000 section alignment
200 file alignment
2 subsystem (Windows GUI)
6.00 operating system version
0.00 image version
6.00 subsystem version
17000 size of image
1000 size of headers
0 checksum
0000000000100000 size of stack reserve
0000000000001000 size of stack commit
0000000000100000 size of heap reserve
0000000000001000 size of heap commit
140  DLL characteristics
Dynamic base
NX compatible
16274 [      AC] address [size] of Export Directory
161DC [      98] address [size] of Import Directory
16000 [     1DC] address [size] of Resource Directory
0 [       0] address [size] of Exception Directory
0 [       0] address [size] of Security Directory
16320 [      10] address [size] of Base Relocation Directory
0 [       0] address [size] of Debug Directory
0 [       0] address [size] of Description Directory
0 [       0] address [size] of Special Directory
0 [       0] address [size] of Thread Storage Directory
157CC [      48] address [size] of Load Configuration Directory
0 [       0] address [size] of Bound Import Directory
0 [       0] address [size] of Import Address Table Directory
0 [       0] address [size] of Delay Import Directory
0 [       0] address [size] of COR20 Header Directory
0 [       0] address [size] of Reserved Directory
SECTION HEADER #1
UPX0 name
F000 virtual size
1000 virtual address
0 size of raw data
400 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
E0000080 flags
Uninitialized Data
(no align specified)
Execute Read Write

SECTION HEADER #2
UPX1 name
6000 virtual size
10000 virtual address
5A00 size of raw data
400 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
E0000040 flags
Initialized Data
(no align specified)
Execute Read Write

SECTION HEADER #3
.rsrc name
1000 virtual size
16000 virtual address
400 size of raw data
5E00 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0000040 flags
Initialized Data
(no align specified)
Read Write

0:000> s-sa 00000000`00fd40b0 L6600
00000000`00fd40fd  "!This program cannot be run in D"
00000000`00fd411d  "OS mode."
00000000`00fd4188  "Rich"
00000000`00fd4290  “UPX0″
00000000`00fd42b8  “UPX1″
00000000`00fd42e0  “.rsrc”
00000000`00fd448b  “3.08″
00000000`00fd4490  “UPX!”
00000000`00fd449b  “YhHM4″
00000000`00fd44d1  “vqx”
[…]

Such in-memory modules (not yet initialized by a loader) can be saved to disk using .writemem command and unpacked. Once loaded and relocated into some address they still have UPX sections but also they now have more strings:

0:000> s-sa 00000000`691c0000 L300
00000000`691c004d  "!This program cannot be run in D"
00000000`691c006d  "OS mode."
00000000`691c00d8  "Rich"
00000000`691c01e0  “UPX0″
00000000`691c0207  “`UPX1″
00000000`691c022f  “`.rsrc”
[…]
00000000`691d620b  “uGC”
00000000`691d621c  “KERNEL32.DLL”
00000000`691d622a  “LoadLibraryA”
00000000`691d6238  “GetProcAddress”
00000000`691d6248  “VirtualProtect”
00000000`691d6258  “VirtualAlloc”
00000000`691d6266  “VirtualFree”
[…]

0:000> s-su 00000000`691c0000 L(00000000`691d7000-00000000`691c0000)
[...]
00000000`691c8178  “http://www.dumpanalysis.com”
00000000`691c8260  “mscoree.dll”
[…]

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

Here we provide a definition of malware that highlights the importance of structural and behavioral patterns:

Malware: software that uses planned alteration of structure and behaviour of software to serve malicious purposes.

Notice the recursive character of that definition that includes self-modifying malware and also rootkits where a malicious purpose is to conceal.

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

As was announced earlier we start cataloguing elemental malware detection and analysis patterns. We skip Part 1 because we assign Deviant Module to it. Part 2 deals with Fake Module pattern where one of loaded modules masquerades as a legitimate system DLL or a widely known value adding DLL from some popular 3rd party product. To illustrate this pattern we modeled it as Victimware: a process crashed after loading a malware module:

0:000> k
*** Stack trace for last set context - .thread/.cxr resets it
Child-SP          RetAddr           Call Site
00000000`0026f978 00000001`3f89103a 0x0
00000000`0026f980 00000001`3f8911c4 FakeModule!wmain+0x3a
00000000`0026f9c0 00000000`76e3652d FakeModule!__tmainCRTStartup+0x144
00000000`0026fa00 00000000`7752c521 kernel32!BaseThreadInitThunk+0xd
00000000`0026fa30 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

When we inspect loaded modules we don’t find anything suspicious:

0:000> lmp
start             end                 module name
00000000`76e20000 00000000`76f3f000   kernel32 <none>
00000000`77500000 00000000`776a9000   ntdll    <none>
00000001`3f890000 00000001`3f8a6000   FakeModule <none>
000007fe`f8cb0000 000007fe`f8cc7000   winspool <none>
000007fe`fdb30000 000007fe`fdb9c000   KERNELBASE <none>

However, when checking modules images for any modifications we find that winspool was not compared with existing binary from Microsoft symbol server:

0:000> !for_each_module "!chkimg -v -d @#ModuleName"
Searching for module with expression: kernel32
Will apply relocation fixups to file used for comparison
Will ignore NOP/LOCK errors
Will ignore patched instructions
Image specific ignores will be applied
Comparison image path: C:\WSDK8\Debuggers\x64\sym\kernel32.dll\503285C111f000\kernel32.dll
No range specified

Scanning section:    .text
Size: 633485
Range to scan: 76e21000-76ebba8d
Total bytes compared: 633485(100%)
Number of errors: 0
0 errors : kernel32
Searching for module with expression: ntdll
Will apply relocation fixups to file used for comparison
Will ignore NOP/LOCK errors
Will ignore patched instructions
Image specific ignores will be applied
Comparison image path: C:\WSDK8\Debuggers\x64\sym\ntdll.dll\4EC4AA8E1a9000\ntdll.dll
No range specified

Scanning section:    .text
Size: 1049210
Range to scan: 77501000-7760127a
Total bytes compared: 1049210(100%)
Number of errors: 0

Scanning section:       RT
Size: 474
Range to scan: 77602000-776021da
Total bytes compared: 474(100%)
Number of errors: 0
0 errors : ntdll
Searching for module with expression: FakeModule
Error for FakeModule: Could not find image file for the module. Make sure binaries are included in the symbol path.
Searching for module with expression: winspool
Error for winspool: Could not find image file for the module. Make sure binaries are included in the symbol path.
Searching for module with expression: KERNELBASE
Will apply relocation fixups to file used for comparison
Will ignore NOP/LOCK errors
Will ignore patched instructions
Image specific ignores will be applied
Comparison image path: C:\WSDK8\Debuggers\x64\sym\KERNELBASE.dll\503285C26c000\KERNELBASE.dll
No range specified

Scanning section:    .text
Size: 302047
Range to scan: 7fefdb31000-7fefdb7abdf
Total bytes compared: 302047(100%)
Number of errors: 0
0 errors : KERNELBASE

Checking module data reveals that it was loaded not from System32 folder and doesn’t have any version information:

0:000> lmv m winspool
start             end                 module name
000007fe`f8cb0000 000007fe`f8cc7000   winspool   (deferred)
Image path: C:\Work\AWMA\FakeModule\x64\Release\winspool.drv
Image name: winspool.drv
Timestamp:        Fri Dec 28 22:22:42 2012 (50DE1BB2)
CheckSum:         00000000
ImageSize:        00017000
File version:     0.0.0.0
Product version:  0.0.0.0
File flags:       0 (Mask 0)
File OS:          0 Unknown Base
File type:        0.0 Unknown
File date:        00000000.00000000
Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

We could see that path from running this command as well :

0:000> !for_each_module
00: 0000000076e20000  0000000076f3f000         kernel32 C:\Windows\System32\kernel32.dll                      kernel32.dll
01: 0000000077500000  00000000776a9000            ntdll C:\Windows\System32\ntdll.dll                            ntdll.dll
02: 000000013f890000  000000013f8a6000       FakeModule C:\Work\AWMA\FakeModule\x64\Release\FakeModule.exe  FakeModule.exe
03: 000007fef8cb0000  000007fef8cc7000         winspool C:\Work\AWMA\FakeModule\x64\Release\winspool.drv
04: 000007fefdb30000  000007fefdb9c000       KERNELBASE C:\Windows\System32\KERNELBASE.dll                  KERNELBASE.dll

or from PEB:

0:000> !peb
PEB at 000007fffffdf000
[...]
7fef8cb0000 50de1bb2 Dec 28 22:22:42 2012 C:\Work\AWMA\FakeModule\x64\Release\winspool.drv
[…]

Another sign is module size in memory which is much smaller than real winspool.drv:

0:000> ? 000007fe`f8cc7000 - 000007fe`f8cb0000
Evaluate expression: 94208 = 00000000`0001700

Module size can help if legitimate module from well-known folder was replaced. Module debug directory and the size of export and import directories are also different with the former revealing the development folder:

0:000> !dh 000007fe`f8cb0000
[...]
   0 [       0] address [size] of Export Directory
[…]
9000 [     208] address [size] of Import Address Table Directory
[…]
Debug Directories(2)
Type       Size     Address  Pointer
cv           49        e2c0     cac0 Format: RSDS, guid, 1, C:\Work\AWMA\FakeModule\x64\Release\winspool.pdb

This can also be seen from the output of !lmi command:

0:000> !lmi 7fef8cb0000
Loaded Module Info: [7fef8cb0000]
Module: winspool
Base Address: 000007fef8cb0000
Image Name: winspool.drv
Machine Type: 34404 (X64)
Time Stamp: 50de1bb2 Fri Dec 28 22:22:42 2012
Size: 17000
CheckSum: 0
Characteristics: 2022
Debug Data Dirs: Type  Size     VA  Pointer
CODEVIEW    49,  e2c0,    cac0 RSDS - GUID: {29D85193-1C9D-4997-95BA-DD190FA3C1BF}
Age: 1, Pdb: C:\Work\AWMA\FakeModule\x64\Release\winspool.pdb
??    10,  e30c,    cb0c [Data not mapped]
Symbol Type: DEFERRED - No error - symbol load deferred
Load Report: no symbols loaded

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

Not all processes are linked into a list that some commands traverse such as !process 0 0. A processes may unlink itself or be in an initialization stage. However, a process structure is allocated from nonpaged pool and such pool can be searched for ”Proc” pool tag (unless a process changes that in memory). We call such pattern Hidden Process. For example:

0: kd> !poolfind Proc

Searching NonPaged pool (83c3c000 : 8bc00000) for Tag: Proc

*87b15000 size:  298 previous size:    0  (Free)      Pro.
*87b18370 size:  298 previous size:   98  (Allocated) Proc (Protected)
[...]
*8a35e900 size:  298 previous size:   30  (Allocated) Proc (Protected)
*8a484000 size:  298 previous size:    0  (Allocated) Proc (Protected)
*8a4a2d68 size:  298 previous size:   28  (Allocated) Proc (Protected)
[…]

One such structure is missing from active process linked list (note that it has a parent PID):

0: kd> !process 8a484000+20
PROCESS 8a484020  SessionId: 0  Cid: 05a0    Peb: 00000000  ParentCid: 0244
DirBase: bffc2200  ObjectTable: e17e6a78  HandleCount:   0.
Image: AppChild.exe
VadRoot 8a574f80 Vads 4 Clone 0 Private 3. Modified 0. Locked 0.
DeviceMap e1002898
Token                             e1a36030
ElapsedTime                       00:00:00.000
UserTime                          00:00:00.000
KernelTime                        419 Days 13:24:16.625
QuotaPoolUsage[PagedPool]         7580
QuotaPoolUsage[NonPagedPool]      160
Working Set Sizes (now,min,max)  (12, 50, 345) (48KB, 200KB, 1380KB)
PeakWorkingSetSize                12
VirtualSize                       1 Mb
PeakVirtualSize                   1 Mb
PageFaultCount                    5
MemoryPriority                    BACKGROUND
BasePriority                      8
CommitCharge                      156

No active threads

We may think that this process is zombie (note that unlike terminated processes it has a non-zero data such as VAD and object table and zero PEB and elapsed time) but inspection of its parent process thread stacks reveals that it was in the process of creation (note an attached process field):

THREAD 8a35dad8  Cid 0244.0248  Teb: 7ffdd000 Win32Thread: bc3aa688 WAIT: (Unknown) KernelMode Non-Alertable
ba971608  NotificationEvent
Impersonation token:  e2285030 (Level Impersonation)
DeviceMap                 e1a31a58
Owning Process            8a35e920       Image:         AppParent.exe
Attached Process          8a484020       Image:         AppChild.exe
Wait Start TickCount      2099           Ticks: 1 (0:00:00:00.015)
Context Switch Count      279                 LargeStack
UserTime                  00:00:00.046
KernelTime                00:00:00.046
Win32 Start Address AppParent!mainCRTStartup (0×0100d303)
Start Address kernel32!BaseProcessStartThunk (0×77e617f8)
Stack Init ba972000 Current ba971364 Base ba972000 Limit ba96e000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0
ChildEBP RetAddr
ba97137c 80833f2d nt!KiSwapContext+0×26
ba9713a8 80829c72 nt!KiSwapThread+0×2e5
ba9713f0 bad3c9db nt!KeWaitForSingleObject+0×346
[…]
ba971b94 8094cfc3 nt!MmCreatePeb+0×2cc
ba971ce4 8094d42d nt!PspCreateProcess+0×5a9
ba971d38 8088b4ac nt!NtCreateProcessEx+0×77
ba971d38 7c82845c nt!KiFastCallEntry+0xfc (TrapFrame @ ba971d64)
0006f498 7c826d09 ntdll!KiFastSystemCallRet
0006f49c 77e6cf95 ntdll!ZwCreateProcessEx+0xc
0006fcc0 7d1ec670 kernel32!CreateProcessInternalW+0×15e5
0006fd0c 01008bcf ADVAPI32!CreateProcessAsUserW+0×108
[…]

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

Sometimes I hear voices saying that Linux, FreeBSD, and Mac OS X core dumps are uninteresting. This is not true. If you haven’t seen anything interesting there it just simply means you have only encountered a limited amount of abnormal software behaviour. The widespread usage of Windows OS means that most patterns have been diagnosed and described first and other OS are waiting their turn.

My goal is to have a pattern catalog with examples from different OS. For example, currently, all Mac OS X patterns I provide are just examples to existing Windows pattern names. All OS share the same structure and behavior, for example, structural memory analysis patterns and the same computational model. Although structural patterns are different from behavioral patterns I also plan to expand the structural list significantly especially in relation to forthcoming Windows malware analysis training. Regarding behavioral patterns it is possible to model and predict specific pattern examples for another OS by using already existing catalog.

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

Memory Dump Analysis Services organizes a free Webinar on Unified Software Diagnostics (USD) and the new scalable cost-effective software support model called Pattern-Driven Software Support devised to address various shortcomings in existing tiered software support organizations. Examples cover Windows, Mac OS  and Linux.

Date: 22nd of June, 2012
Time: 17:00 (BST) 12:00 (EST) 09:00 (PST)
Duration: 60 minutes

Space is limited.
Reserve your Webinar seat now at:
https://www3.gotomeeting.com/register/172771078

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

More than 4 years passed since I provided a longer structuralist definition. Recently I came to recognize a pattern-driven iterative and incremental nature of memory and software trace analysis and post-construction software problem solving in general and therefore a one sentence definition became necessary:

“Recognition and interpretation of patterns of software behavior”

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

Memoretics promotes pattern-driven memory dump and software trace analysis which has many uses but not limited to:

• Software and site reliability
• Software Debugging
• QA and Software Testing
• Computer Security
• Software Troubleshooting
• Malware Research and Analysis
• Tools as a Service (TaaS)
• Supportability
• Software Diagnostics

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

Memoretics as a science of memory snapshots borrows many ideas from the following disciplines (the list is not exhaustive):

• Troubleshooting and Debugging
• Intelligence Analysis
• Critical Thinking
• Forensics
• Linguistics
• Archaeology
• Psychoanalysis
• History
• Mathematics: Sets and Categories
• Literary Criticism and Narratology

It also contributes many ideas back. The following diagram depicts such an interaction:

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

To model software behavior at application and system levels, test generative debugging scenarious and construct software defects using metaprogramming I started working on MdTL (Metadefect Template Library). Its consists of C++ templates for structural and behavioral patterns. The simplest examples include Threads<Spike> and Spike<Thread>. The template classes can be more complex, of course, utilizing the full power of C++, STL, and existing libraries like Boost. The unique and novel feature of this library is the inclusion of dual classes of behaviour such as Leak<>, Deadlock<>, Overflow<>, Residue<>, Exception<>, Contention<>, etc. parameterized by various structural memory classes like Process<>, Thread<>, Heap<>, Stack<>, Region<>, Buffer<>, etc. MdTL also includes classes to model software tracing and this will be used for simultaneous software trace and memory dump analysis case study in the forthcoming presentation. I also plan to extend this metaprogramming approach in the future to model malware analysis patterns by introducing Metamalware Template Library (MmTL).

Forthcoming parts will introduce template classes and examples.

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

The presentation materials from the webinar (25th of March, 2011) are available for download:

http://www.dumpanalysis.com/PDSPSI-materials

Thanks to everyone who registered and attended!

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

The first Webinar to start an in-depth discussion of pattern-driven software troubleshooting, debugging and maintenance:

Date: 25th of March 2011
Time: 18:30 (GMT) 14:30 (EST) 11:30 (PST)
Duration: 60 minutes

Space is limited.
Reserve your Webinar seat now at:
https://www3.gotomeeting.com/register/448268158

Topics include:

• A Short History of DumpAnalysis.org
• Memory Dump Analysis Patterns
• Troubleshooting and Debugging Tools (Debugware) Patterns
• Software Trace Analysis Patterns
• From Software Defects to Software Behavior
• Workaround Patterns
• Structural Memory Patterns
• Memory Analysis Domain Pattern Hierarchy
• New Directions

Prerequisites: experience in software troubleshooting and/or debugging.

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