Hooksware
2009 (0x7D9) - The Year of Debugging
This is a new word I’ve just coined to describe applications heavily dependent on various hooks that are either injected by normal Windows hooking mechanism, registry or via more elaborate tricks like remote threads or patching code. Originally I thought of hookware but found that this term is already in use for completely different purpose.
Now I list various patterns in memory dumps that help in detection, troubleshooting and debugging of hooksware:
This is the primary detection mechanism for hooks that patch code.
Loaded hooks shift other DLLs by changing their load address and therefore might expose dormant bugs.
- Insufficient Memory (virtual memory)
Hooks loaded in the middle of address space limit the maximum amount of memory that can be allocated at once. For example, various virtual machines, like Java, reserve the big chunk of memory at the start up.
We can get an approximate picture of what a 3rd-party hook module does by looking at its import table or in the case of patching by looking at the list of deviations returned by .chkimg command.
Might give an idea about the author of the hook.
- Coincidental Symbolic Information
Sometimes hooks are loaded at round addresses like 0×10000000 and these values are very frequently used as flags or constants too.
When hooking goes wrong the execution path goes into the wild territory.
Here we can find various hooks that use normal Windows hooking mechanism. Sometimes the search for “hook” word in symbolic raw stack output of dds command reveals them but beware of Coincidental Symbolic Information. See also Raw Stack Dump of all threads (process dumps) and Raw Stack Dump of all threads (part 2) (complete memory dumps).
Some hooks may hide themselves.
- Dmitry Vostokov @ DumpAnalysis.org -
_1125.png)
New Books:
WinDbg: A Reference Poster and Learning Cards
Memory Dump Analysis Anthology, Volume 2
Also available:
Memory Dump Analysis Anthology, Volume 1
New Children's Book:
