Archive for the ‘Security’ Category
Sunday, September 21st, 2008
Opcodes “- so innocent and powerless as they are, as standing in a” manual “, how potent for good and evil they become in the hands of one who knows how to combine them.”
Nathaniel Hawthorne, American Notebooks
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Assembly Language, Bugtations, Debugging, Security | No Comments »
Friday, September 19th, 2008
Previously I introduced Hooked Functions pattern where I used !chkimg WinDbg command and today after accidentally discovering yet another patched DLL module in one process I created this simple command to check all modules:
!for_each_module !chkimg -lo 50 -d !${@#ModuleName} -v
0:000:x86> !for_each_module !chkimg -lo 50 -d !${@#ModuleName} -v
[...]
Scanning section: .text
Size: 74627
Range to scan: 71c01000-71c13383
71c02430-71c02434 5 bytes - WS2_32!WSASend
[ 8b ff 55 8b ec:e9 cb db 1c 0d ]
71c0279b-71c0279f 5 bytes - WS2_32!select (+0x36b)
[ 6a 14 68 58 28:e9 60 d8 15 0d ]
71c0290e-71c02912 5 bytes - WS2_32!WSASendTo (+0x173)
[ 8b ff 55 8b ec:e9 ed d6 1b 0d ]
71c02cb2-71c02cb6 5 bytes - WS2_32!closesocket (+0x3a4)
[ 8b ff 55 8b ec:e9 49 d3 19 0d ]
71c02e12-71c02e16 5 bytes - WS2_32!WSAIoctl (+0x160)
[ 8b ff 55 8b ec:e9 e9 d1 1e 0d ]
71c02ec2-71c02ec6 5 bytes - WS2_32!send (+0xb0)
[ 8b ff 55 8b ec:e9 39 d1 14 0d ]
71c02f7f-71c02f83 5 bytes - WS2_32!recv (+0xbd)
[ 8b ff 55 8b ec:e9 7c d0 17 0d ]
71c03c04-71c03c08 5 bytes - WS2_32!WSAGetOverlappedResult (+0xc85)
[ 8b ff 55 8b ec:e9 f7 c3 1f 0d ]
71c03c75-71c03c79 5 bytes - WS2_32!recvfrom (+0x71)
[ 8b ff 55 8b ec:e9 86 c3 16 0d ]
71c03d14-71c03d18 5 bytes - WS2_32!sendto (+0x9f)
[ 8b ff 55 8b ec:e9 e7 c2 13 0d ]
71c03da8-71c03dac 5 bytes - WS2_32!WSACleanup (+0x94)
[ 8b ff 55 8b ec:e9 53 c2 25 0d ]
71c03f38-71c03f3c 5 bytes - WS2_32!WSASocketW (+0x190)
[ 6a 20 68 08 40:e9 c3 c0 11 0d ]
71c0446a-71c0446e 5 bytes - WS2_32!connect (+0x532)
[ 8b ff 55 8b ec:e9 91 bb 18 0d ]
71c04f3b-71c04f3f 5 bytes - WS2_32!WSAStartup (+0xad1)
[ 6a 14 68 60 50:e9 c0 b0 29 0d ]
71c06162-71c06166 5 bytes - WS2_32!shutdown (+0x1227)
[ 8b ff 55 8b ec:e9 99 9e 12 0d ]
71c069e9-71c069ed 5 bytes - WS2_32!WSALookupServiceBeginW (+0x887)
[ 8b ff 55 8b ec:e9 12 96 0f 0d ]
71c06c91-71c06c95 5 bytes - WS2_32!WSALookupServiceNextW (+0x2a8)
[ 8b ff 55 8b ec:e9 6a 93 10 0d ]
71c06ecd-71c06ed1 5 bytes - WS2_32!WSALookupServiceEnd (+0x23c)
[ 8b ff 55 8b ec:e9 2e 91 0e 0d ]
71c090be-71c090c2 5 bytes - WS2_32!WSAEventSelect (+0x21f1)
[ 8b ff 55 8b ec:e9 3d 6f 20 0d ]
71c09129-71c0912d 5 bytes - WS2_32!WSACreateEvent (+0x6b)
[ 33 c0 50 50 6a:e9 d2 6e 22 0d ]
71c0938e-71c09392 5 bytes - WS2_32!WSACloseEvent (+0x265)
[ 6a 0c 68 c8 93:e9 6d 6c 24 0d ]
71c093d9-71c093dd 5 bytes - WS2_32!WSAWaitForMultipleEvents (+0x4b)
[ 8b ff 55 8b ec:e9 22 6c 1a 0d ]
71c093ea-71c093ee 5 bytes - WS2_32!WSAEnumNetworkEvents (+0x11)
[ 8b ff 55 8b ec:e9 11 6c 21 0d ]
71c09480-71c09484 5 bytes - WS2_32!WSARecv (+0x96)
[ 8b ff 55 8b ec:e9 7b 6b 1d 0d ]
71c0eecb-71c0eecf 5 bytes - WS2_32!WSACancelAsyncRequest (+0x5a4b)
[ 8b ff 55 8b ec:e9 30 11 26 0d ]
71c10d39-71c10d3d 5 bytes - WS2_32!WSAAsyncSelect (+0x1e6e)
[ 8b ff 55 8b ec:e9 c2 f2 26 0d ]
71c10ee3-71c10ee7 5 bytes - WS2_32!WSAConnect (+0x1aa)
[ 8b ff 55 8b ec:e9 18 f1 22 0d ]
71c10f9f-71c10fa3 5 bytes - WS2_32!WSAAccept (+0xbc)
[ 8b ff 55 8b ec:e9 5c f0 27 0d ]
Total bytes compared: 74627(100%)
Number of errors: 140
140 errors : !WS2_32 (71c02430-71c10fa3)
[...]
CMDTREE.TXT was also updated with this command.
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Crash Dump Analysis, Crash Dump Patterns, Debugging, Malware Analysis, Security, WinDbg Tips and Tricks | 2 Comments »
Friday, September 12th, 2008
Last week I noticed this book on Amazon and I would have passed over it if I didn’t discover 2600 magazine when browsing Microsoft Encyclopedia of Security a few months ago
This morning it arrived in post and I’m looking forward reading it during my lunch time. Anthology books are well suited for such breaks because articles are not long and usually self sufficient to learn about something discrete:
The Best of 2600: A Hacker Odyssey


- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Books, Hardware, Security | No Comments »
Tuesday, September 9th, 2008
Previously I wrote about security options in WinDbg but recently discovered that PEB is included with sensitive data for full user dumps despite stack and page cleaning and removing module paths. Module paths are removed indeed from lmv command output but _PEB.Ldr lists contain full module path information:
0:000> dt _PEB Ldr
ntdll!_PEB
+0x018 Ldr : Ptr64 _PEB_LDR_DATA
0:000> dt _PEB_LDR_DATA
ntdll!_PEB_LDR_DATA
+0x000 Length : Uint4B
+0x004 Initialized : UChar
+0x008 SsHandle : Ptr64 Void
+0×010 InLoadOrderModuleList : _LIST_ENTRY
+0×020 InMemoryOrderModuleList : _LIST_ENTRY
+0×030 InInitializationOrderModuleList : _LIST_ENTRY
+0×040 EntryInProgress : Ptr64 Void
0:000> !peb
PEB at 000007fffffdb000
[...]
You can see this in the dump sample saved with /r and /R options:
ftp://dumpanalysis.org/pub/LargeHeapAllocations.zip
The only options I see currently are:
-
- Custom minidumps: do not save process dumps containing full user space with /ma or /mf option for .dump command
-
- Include PEB but erase specific sections and regions pointed to like environment blocks. See the previous Data Hiding in Crash Dumps post.
-
- Erase specific ASCII or UNICODE fragments manually using any binary editor. This was done for the dump file above.
-
Do not send dumps but logs. See All at once: postmortem logs and dump files.
Anyway manual inspection of a dump saved with security options is recommended before sending it.
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Crash Dump Analysis, Debugging, Security | No Comments »
Friday, August 15th, 2008
In the previous post about resolving security issues with crash dumps I mentioned the solution to use logs generated from memory dump files. In the case of process dumps the obvious step is to save logs by a postmortem debugger at the moment of the crash. Here WinDbg scripts come to the rescue. Suppose that CDB is set as a postmortem debugger (see Custom postmortem debuggers on Vista) and AeDebug \ Debugger registry key value is set to:
"C:\Program Files\Debugging Tools for Windows\cdb.exe" -p %ld -e %ld -g -y SRV*c:\mss*http://msdl.microsoft.com/download/symbols -c "$$><c:\WinDbgScripts\LogsAndDumps.txt;q"
Here we specify MS symbols server and the script file. The symbol path is absolutely necessary to have correct stack traces. The script file has the following contents:
.logopen /t c:\UserDumps\process.log
.kframes 100
!analyze -v
~*kv
lmv
.logclose
.dump /m /u c:\UserDumps\mini_process
.dump /ma /u c:\UserDumps\full_process
.dump /mrR /u c:\UserDumps\secure_mini_process
.dump /marR /u c:\UserDumps\secure_full_process
.kframes WinDbg meta-command is necessary to avoid the common pitfall of looking at cut off stack traces (see Mistake #1). In addition to logging the output of any command we want, the script writes 4 memory dumps of the same process:
- mini dump
- full dump
- secure mini dump
- secure full dump
My previous post WinDbg is privacy-aware explains secure dumps in detail. If you need to tailor dump file names and logs to include real process name might need to try the following or similar technique explained here:
Generating file name for .dump command
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Crash Dump Analysis, Debugging, Security, WinDbg Scripts | 2 Comments »
Thursday, August 7th, 2008
Sometimes we look for modules that were loaded and unloaded at some time. lm command lists unloaded modules but some of them could be mapped to address space without using runtime loader. The latter case is common for drm-type protection tools, rootkits, malware or crimeware which can influence a process execution. In such cases we can hope that they still remain in virtual memory and search for them. WinDbg .imgscan command greatly helps in identifying MZ/PE module headers. The following example just illustrates this command without implying that the found module did any harm:
0:000> .imgscan
MZ at 000d0000, prot 00000002, type 01000000 - size 6000
Name: usrxcptn.dll
MZ at 00350000, prot 00000002, type 01000000 - size 9b000
Name: ADVAPI32.dll
MZ at 00400000, prot 00000002, type 01000000 - size 23000
Name: javaw.exe
MZ at 01df0000, prot 00000002, type 01000000 - size 8b000
Name: OLEAUT32.dll
MZ at 01e80000, prot 00000002, type 01000000 - size 52000
Name: SHLWAPI.dll
[…]
We don’t see usrxcptn in either loaded or unloaded module lists:
0:002> lm
start end module name
00350000 003eb000 advapi32
00400000 00423000 javaw
01df0000 01e7b000 oleaut32
01e80000 01ed2000 shlwapi
[...]
Unloaded modules:
This is why I call this pattern Hidden Module. We can use Unknown Component pattern to see the module resources if present in memory:
0:002> !dh 000d0000
[...]
SECTION HEADER #4
.rsrc name
418 virtual size
4000 virtual address
600 size of raw data
1600 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
40000040 flags
Initialized Data
(no align specified)
Read Only
[...]
0:002> dc 000d0000+4000 L418
[…]
000d4140 […] n…z.)…F.i.l.
000d4150 […] e.D.e.s.c.r.i.p.
000d4160 […] t.i.o.n…..U.s.
000d4170 […] e.r. .D.u.m.p. .
000d4180 […] U.s.e.r. .M.o.d.
000d4190 […] e. .E.x.c.e.p.t.
000d41a0 […] i.o.n. .D.i.s.p.
000d41b0 […] a.t.c.h.e.r…..
0:002> du 000d416C
000d416c "User Dump User Mode Exception Di"
000d41ac "spatcher"
This component seems to be loaded or mapped only if userdump package was fully installed where usrxcptn.dll is a part of its redistribution. Although from the memory dump comment we also see that the dump was taken manually using command line userdump.exe we see that the full userdump package was additionally installed which was probably not necessary (see Correcting Microsoft article about userdump.exe):
Loading Dump File [javaw.dmp]
User Mini Dump File with Full Memory: Only application data is available
Comment: 'Userdump generated complete user-mode minidump with Standalone function on COMPUTER-NAME'
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Crash Dump Analysis, Crash Dump Patterns, Debugging, Malware Analysis, Memory Analysis Forensics and Intelligence, Security, WinDbg Tips and Tricks | 8 Comments »
Tuesday, June 10th, 2008
Suppose we want to send a complete memory dump to a vendor but want to remove certain sensitive details or perhaps the whole process or image from it. In this case we can use f WinDbg command (virtual addresses) or fp (physical addresses) to fill pages with zeroes. Let’s open a complete memory dump and erase environment variables for a process:
kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
PROCESS fffffadfe7afd8e0
SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 0014a000 ObjectTable: fffffa8000000c10 HandleCount: 730.
Image: System
PROCESS fffffadfe6edc040
SessionId: none Cid: 0130 Peb: 7fffffdf000 ParentCid: 0004
DirBase: 34142000 ObjectTable: fffffa80009056d0 HandleCount: 19.
Image: smss.exe
[...]
PROCESS fffffadfe67905a0
SessionId: 0 Cid: 085c Peb: 7fffffd4000 ParentCid: 0acc
DirBase: 232e2000 ObjectTable: fffffa8000917e10 HandleCount: 55.
Image: SystemDump.exe
kd> .process /r /p fffffadfe7287610
Implicit process is now fffffadf`e7287610
Loading User Symbols
kd> !peb
PEB at 000007fffffd4000
[...]
Environment: 0000000000010000
kd> dd 10000
00000000`00010000 004c0041 0055004c 00450053 00530052
00000000`00010010 00520050 0046004f 004c0049 003d0045
00000000`00010020 003a0043 0044005c 0063006f 006d0075
00000000`00010030 006e0065 00730074 00610020 0064006e
00000000`00010040 00530020 00740065 00690074 0067006e
00000000`00010050 005c0073 006c0041 0020006c 00730055
00000000`00010060 00720065 002e0073 00320057 0033004b
00000000`00010070 00410000 00500050 00410044 00410054
kd> f 10000 10000+1000 0
Filled 0x1000 bytes
kd> dd 10000
00000000`00010000 00000000 00000000 00000000 00000000
00000000`00010010 00000000 00000000 00000000 00000000
00000000`00010020 00000000 00000000 00000000 00000000
00000000`00010030 00000000 00000000 00000000 00000000
00000000`00010040 00000000 00000000 00000000 00000000
00000000`00010050 00000000 00000000 00000000 00000000
00000000`00010060 00000000 00000000 00000000 00000000
00000000`00010070 00000000 00000000 00000000 00000000
Now we can save the modified complete dump file:
kd> .dump /f c:\Dumps\SecuredDump.dmp
If we want to find and erase read-write pages, for example, we can use !vad WinDbg command to get the description of virtual address ranges:
kd> !process
PROCESS fffffadfe67905a0
SessionId: 0 Cid: 085c Peb: 7fffffd4000 ParentCid: 0acc
DirBase: 232e2000 ObjectTable: fffffa8000917e10 HandleCount: 55.
Image: SystemDump.exe
VadRoot fffffadfe6f293e0 Vads 65 Clone 0 Private 388. Modified 84. Locked 0.
DeviceMap fffffa80020777c0
Token fffffa80008e5b50
ElapsedTime 00:00:06.265
UserTime 00:00:00.031
KernelTime 00:00:00.062
QuotaPoolUsage[PagedPool] 113464
QuotaPoolUsage[NonPagedPool] 5152
Working Set Sizes (now,min,max) (1429, 50, 345) (5716KB, 200KB, 1380KB)
PeakWorkingSetSize 1429
VirtualSize 61 Mb
PeakVirtualSize 63 Mb
PageFaultCount 1555
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 471
kd> !vad fffffadfe6f293e0
VAD level start end commit
fffffadfe682bdf0 ( 6) 10 10 1 Private READWRITE
fffffadfe73a0e10 ( 5) 20 20 1 Private READWRITE
fffffadfe73a0dd0 ( 4) 30 12f 8 Private READWRITE
fffffadfe71a4770 ( 5) 130 134 0 Mapped READONLY
fffffadfe781bbe0 ( 3) 140 141 0 Mapped READONLY
[…]
fffffadfe772d630 (-2) 7fffffdc 7fffffdd 2 Private READWRITE
fffffadfe788e180 (-1) 7fffffde 7fffffdf 2 Private READWRITE
Total VADs: 65 average level: 66076419 maximum depth: -1
In the output start and end columns refer to virtual page numbers (VPN). To get an address we need to multiply by 0×1000, for example, 7fffffde000.
Filling memory with zeroes to hide data with subsequent saving of a modified crash dump is applicable to user dumps too. Please also check for additional security-related flags in .dump command:
WinDbg is privacy-aware
Another application for data hiding and modification could be the creation of the customized crash dumps for digital forensics exercises and contests.
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Crash Dump Analysis, Debugging, Memory Analysis Forensics and Intelligence, Security | 5 Comments »
Friday, May 30th, 2008
Following the introductory division of memory analysis into two broad categories I decided to plan yet another book with the following title and preliminary product details:
- Title: Memory Analysis Forensics and Intelligence: An Integral Approach
- Author: Dmitry Vostokov
- Publisher: Opentask (01 September 2009)
- Language: English
- Product Dimensions: 22.86 x 15.24
- ISBN-13: 978-1-906717-05-6
- Paperback: 256 pages
As you might have noticed, I prefer to put 128, 256 or 512 pages in my book announcements. What that would say about the author’s background?
I would like to set 1024 pages for my memory dump analysis anthology series but 740 or 800 pages is the limit for POD technology I use.
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Announcements, Books, Crash Dump Analysis, Crash Dump Patterns, Memory Analysis Forensics and Intelligence, Science of Memory Dump Analysis, Security, Software Technical Support, Troubleshooting Methodology | No Comments »
Friday, May 23rd, 2008
Recently being interested in forensic science and intelligence I decided to elaborate on memory analysis classification and came up with the following division:
- Memory Analysis Forensics
Answering questions related to a committed computer crime. The suspect may be a human or a software / hardware component. Incident response, troubleshooting and debugging belong to this category. Postmortem memory analysis is usually analysis of dump files saved and detached from the original system or operating conditions.
- Memory Analysis Intelligence
Monitoring memory state for behavioural and structural patterns to prevent certain events from occurring. Usually done in situ. However digital dumpster divers and spies may also collect and analyze memory data that was detached from the original computer system.
Each category can be further subdivided into:
– Functional Memory Analysis
Tracing of events.
– Memoretics
Analysis of memory states and their evolution.
The latter can be subdivided into:
— Static Memory Analysis
Traditional memory dump analysis.
— Dynamic Memory Analysis
Live debugging.
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Crash Dump Analysis, Crash Dump Patterns, Debugging, Memory Analysis Forensics and Intelligence, Science of Memory Dump Analysis, Security | 1 Comment »
Friday, April 25th, 2008
Due to demand from people that prefer ebooks I published Memory Dump Analysis Anthology, Volume 1 in a digital format that can be purchased in Crash Dump Analysis Store. This format has color pictures inside.
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Announcements, Assembly Language, Books, Bugchecks Depicted, Citrix, Crash Dump Analysis, Crash Dump Patterns, Crash Dumps for Dummies, Debugging, Fun with Crash Dumps, GDB for WinDbg Users, Hardware, Kernel Development, Memory Dump Analysis Jobs, Memory Visualization, Minidump Analysis, Publishing, Science of Memory Dump Analysis, Security, Software Architecture, Software Technical Support, Stack Trace Collection, Tools, Troubleshooting Methodology, Vista, WinDbg Scripts, WinDbg Tips and Tricks, WinDbg for GDB Users, Windows Server 2008 | No Comments »
Tuesday, April 15th, 2008
I’m very proud to announce that it is finally available in both paperback and hardback. Why have I made available both editions? Because I personally prefer hardcover books. You can order the book today and it will be printed in 3-5 days (paperback) or 5-10 days (hardcover) and sent to you:
Memory Dump Analysis Anthology, Volume 1
Note: although listed on Amazon and other online bookstores it is not immediately available at these stores at the moment due to the late submission. I apologize for this. However, I expect that in a few weeks pre-orders taken there will be eventually fulfilled. In the mean time, if you want the book now, you can use the link above.
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Announcements, Assembly Language, Books, Bugchecks Depicted, CDF Analysis Tips and Tricks, Citrix, Crash Dump Analysis, Crash Dump Patterns, Crash Dumps for Dummies, Debugging, Fun with Crash Dumps, GDB for WinDbg Users, Hardware, Kernel Development, Memory Dump Analysis Jobs, Memory Visualization, Minidump Analysis, Publishing, Science of Memory Dump Analysis, Security, Software Architecture, Software Technical Support, Stack Trace Collection, Tools, Troubleshooting Methodology, Vista, WinDbg Scripts, WinDbg Tips and Tricks, WinDbg for GDB Users, Windows Server 2008 | 3 Comments »
Tuesday, March 25th, 2008
Although the first volume has not been published yet (scheduled for 15th of April, 2008) the planning for the second volume has already begun. Preliminary information is:
- Title: Memory Dump Analysis Anthology, Volume 2
- Paperback: 512 pages (*)
- ISBN-13: 978-0-9558328-7-1
- Author: Dmitry Vostokov
- Publisher: Opentask (01 Oct 2008)
- Language: English
- Product Dimensions: 22.86 x 15.24
Hardcover version is also planned. PDF version will be available for download too.
(*) subject to change
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Announcements, Assembly Language, Books, Bugchecks Depicted, Crash Dump Analysis, Crash Dump Patterns, Crash Dumps for Dummies, Debugging, Fun with Crash Dumps, Hardware, Kernel Development, Memory Dump Analysis Jobs, Memory Visualization, Minidump Analysis, Science of Memory Dump Analysis, Security, Software Architecture, Software Technical Support, Stack Trace Collection, Tools, Troubleshooting Methodology, Vista, WinDbg Scripts, WinDbg Tips and Tricks, WinDbg for GDB Users, Windows Server 2008 | 1 Comment »
Tuesday, February 19th, 2008
“Do Not Tolerate Easter Eggs” - hidden gem on page 293 in the book Secure Programming with Static Analysis prompted me to define this phenomenon as Software Securitism. I was looking for its definition but couldn’t find anything except the fact that the word was sometimes used in political discourse. Hence a definition is required and it is based on an analogy with Scientism with at least two meanings:
-
The view that Security has authority over other software engineering and support best practices usually at the expense of customers.
-
Improper usage of security terminology regardless of the project scope and common sense as a counter-argument.
If you heard about other abuses of security perhaps due to its current fashionable usage you can contact me anonymously using this contact form:
http://www.dumpanalysis.org/contact
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Security | No Comments »
Monday, February 18th, 2008
Comparing reference stack traces with the output of !process 0 ff command or just visually inspecting the long log and trying to spot anomalies is very difficult and largely based on personal experience with prior problem cases. A tool is needed and I’m currently writing the one. It will compare logs from problem memory dumps with reference stack traces and other information and automatically pinpoint any anomalies and highlight areas for more detailed manual inspection. This is similar to Kernel Memory Space Analyzer original intent but far more useful. Originally I thought about calling it WinDbg Log Analyzer but later decided to make it more general and extendable to other types of logs from different debuggers like GDB. Some people asked me the question: won’t a WinDbg debugger extension suffice? My answer was no - some companies cannot send complete, kernel and process memory dumps due to security considerations but they can send logs free from sensitive data as explained in my previous article:
Resolving security issues with crash dumps
Additionally I want it to be debugger independent at least in the second version and I want it to be web-based too and free from the choice of the hosting platform.
Stay tuned because the working prototype will be soon as a command line tool first. I personally need it for my day-to-day job. The latter always was my primary motivation to create various tools to automate or semi-automate data gathering and improve customer problem analysis.
The next version will have front-end GUI and I still haven’t decided yet whether to employ embedded HTML control like IE, RichEdit or revive my old text processor project. I’m inclined to choose the former due to endless possibilities with HTML and its platform independence. The choice of command line tool written in C++/STL will help to port it to FreeBSD/Linux/Solaris and adapt to other debuggers like GDB/ADB. The latter is my “wild fantasy” at the moment but its good to think towards other platforms that slowly increase their presence in my professional life
Any suggestions are very welcome especially if you have dealt with large debugger logs including not only backtraces but also various synchronization objects, module information, timing and I/O packet distribution.
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Announcements, Crash Dump Analysis, Crash Dump Patterns, Debugging, Security, Software Technical Support, Stack Trace Collection, Tools | 2 Comments »
Thursday, February 7th, 2008
It is very easy to become a publisher nowadays. Much easier than I thought. I registered myself as a publisher under the name of OpenTask which is my registered business name in Ireland. I also got the list of ISBN numbers and therefore can announce product details for the first volume of Memory Dump Analysis Anthology series:
Memory Dump Analysis Anthology, Volume 1
- Paperback: 720 pages (*)
- ISBN-13: 978-0-9558328-0-2
- Hardcover: 720 pages (*)
- ISBN-13: 978-0-9558328-1-9
- Author: Dmitry Vostokov
- Publisher: Opentask (15 Apr 2008)
- Language: English
- Product Dimensions: 22.86 x 15.24
(*) subject to change
PDF file will be available for download too.
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Announcements, Assembly Language, Books, Bugchecks Depicted, Crash Dump Analysis, Crash Dump Patterns, Crash Dumps for Dummies, Debugging, Fun with Crash Dumps, GDB for WinDbg Users, Hardware, Kernel Development, Memory Dump Analysis Jobs, Memory Visualization, Minidump Analysis, Science of Memory Dump Analysis, Security, Software Architecture, Software Technical Support, Stack Trace Collection, Tools, Troubleshooting Methodology, Vista, WinDbg Scripts, WinDbg Tips and Tricks, WinDbg for GDB Users, Windows Server 2008 | 4 Comments »
Thursday, November 22nd, 2007
Hooking functions using trampoline method is so common on Windows and sometimes we need to check Hooked Functions in specific modules and determine which module hooked them for troubleshooting or memory forensic analysis needs. If original unhooked modules are available (via symbol server, for example) this can be done by using !chkimg WinDbg extension command:
0:002> !chkimg -lo 50 -d !kernel32 -v
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:\mss\kernel32.dll\44C60F39102000\kernel32.dll
No range specified
Scanning section: .text
Size: 564445
Range to scan: 77e41000-77ecacdd
77e44004-77e44008 5 bytes - kernel32!GetDateFormatA
[ 8b ff 55 8b ec:e9 f7 bf 08 c0 ]
77e4412e-77e44132 5 bytes - kernel32!GetTimeFormatA (+0×12a)
[ 8b ff 55 8b ec:e9 cd be 06 c0 ]
77e4e857-77e4e85b 5 bytes - kernel32!FileTimeToLocalFileTime (+0xa729)
[ 8b ff 55 8b ec:e9 a4 17 00 c0 ]
77e56b5f-77e56b63 5 bytes - kernel32!GetTimeZoneInformation (+0×8308)
[ 8b ff 55 8b ec:e9 9c 94 00 c0 ]
77e579a9-77e579ad 5 bytes - kernel32!GetTimeFormatW (+0xe4a)
[ 8b ff 55 8b ec:e9 52 86 06 c0 ]
77e57fc8-77e57fcc 5 bytes - kernel32!GetDateFormatW (+0×61f)
[ 8b ff 55 8b ec:e9 33 80 08 c0 ]
77e6f32b-77e6f32f 5 bytes - kernel32!GetLocalTime (+0×17363)
[ 8b ff 55 8b ec:e9 d0 0c 00 c0 ]
77e6f891-77e6f895 5 bytes - kernel32!LocalFileTimeToFileTime (+0×566)
[ 8b ff 55 8b ec:e9 6a 07 01 c0 ]
77e83499-77e8349d 5 bytes - kernel32!SetLocalTime (+0×13c08)
[ 8b ff 55 8b ec:e9 62 cb 00 c0 ]
77e88c32-77e88c36 5 bytes - kernel32!SetTimeZoneInformation (+0×5799)
[ 8b ff 55 8b ec:e9 c9 73 01 c0 ]
Total bytes compared: 564445(100%)
Number of errors: 50
50 errors : !kernel32 (77e44004-77e88c36)
0:002> u 77e44004
kernel32!GetDateFormatA:
77e44004 e9f7bf08c0 jmp 37ed0000
77e44009 81ec18020000 sub esp,218h
77e4400f a148d1ec77 mov eax,dword ptr [kernel32!__security_cookie (77ecd148)]
77e44014 53 push ebx
77e44015 8b5d14 mov ebx,dword ptr [ebp+14h]
77e44018 56 push esi
77e44019 8b7518 mov esi,dword ptr [ebp+18h]
77e4401c 57 push edi
0:002> u 37ed0000
*** ERROR: Symbol file could not be found. Defaulted to export symbols for MyDateTimeHooks.dll -
37ed0000 e99b262f2d jmp MyDateTimeHooks+0×26a0 (651c26a0)
37ed0005 8bff mov edi,edi
37ed0007 55 push ebp
37ed0008 8bec mov ebp,esp
37ed000a e9fa3ff73f jmp kernel32!GetDateFormatA+0×5 (77e44009)
37ed000f 0000 add byte ptr [eax],al
37ed0011 0000 add byte ptr [eax],al
37ed0013 0000 add byte ptr [eax],al
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Crash Dump Analysis, Crash Dump Patterns, Security, WinDbg Tips and Tricks | 15 Comments »
Wednesday, November 14th, 2007
The pattern I should have written as one of the first is called Local Buffer Overflow. It is observed on x86 platforms when a local variable and a function return address and/or saved frame pointer EBP are overwritten with some data. As a result, the instruction pointer EIP becomes Wild Pointer and we have a process crash in user mode or a bugcheck in kernel mode. Sometimes this pattern is diagnosed by looking at mismatched EBP and ESP values and in the case of ASCII or UNICODE buffer overflow EIP register may contain 4-char or 2-wchar_t value and ESP or EBP or both registers might point at some string fragment like in the example below:
0:000> r
eax=000fa101 ebx=0000c026 ecx=01010001 edx=bd43a010 esi=000003e0 edi=00000000
eip=0048004a esp=0012f158 ebp=00510044 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000202
0048004a 0000 add byte ptr [eax],al ds:0023:000fa101=??
0:000> kL
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012f154 00420047 0x48004a
0012f158 00440077 0x420047
0012f15c 00420043 0x440077
0012f160 00510076 0x420043
0012f164 00420049 0x510076
0012f168 00540041 0x420049
0012f16c 00540041 0x540041
...
...
...
Good buffer overflow case studies with complete analysis including assembly language tutorial can be found in Buffer Overflow Attacks
book.

- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Assembly Language, Books, Crash Dump Analysis, Crash Dump Patterns, Debugging, Security | 4 Comments »
Sunday, August 19th, 2007
Almost finished reading the book and wrote a short review:
Secure Programming with Static Analysis
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Books, Code Reading, Security | No Comments »
Wednesday, August 15th, 2007
This security warning is related to sound files and pictures produced by Dump2Wave, Dump2Picture and WinDbg scripts based on them.
These tools do not change computer memory data and it is present in resulting WAV and BMP files unmodified. Do not publish these files on Internet, otherwise you might expose your private or sensitive data.
If you use lossy compression afterwards, like MP3 or JPEG, all original computer memory content is lost and becomes non-recoverable.
Therefore, if you create a piece of modern art using Dump2Picture and want to publish it electronically always transform it into JPEG, for example.
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Memory Visualization, Security | 3 Comments »
Friday, August 10th, 2007
The life of OS starts with BIOS and if you are curious about BIOS technology, x86 computer architecture and security the following book that I recently discovered and bought will help you:
BIOS Disassembly Ninjutsu Uncovered
- Dmitry Vostokov @ DumpAnalysis.org -
Posted in Assembly Language, Books, Hardware, Security | No Comments »