From Collaborative RCE Tool Library
Usermode Hook Detection Tools
| Tool name: | HookShark |
| ||
|---|---|---|---|---|
| Author: | DeepBlueSea | |||
| Website: | http://forum.gamedeception.net/threads/20596-HookShark-BETA-0.9-(with-a-vengeance) | |||
| Current version: | BETA 0.9 | |||
| Last updated: | September 1, 2010 | |||
| Direct D/L link: | Locally archived copy | |||
| License type: | Free | |||
| Description: | HookShark is a detector of installed hooks and patches installed on the system (only usermode for now). It scans through the code-section of every loaded module of each running process and compares it with the file-image. If it detects discrepancies it tries to determine the type of hook or patch and reports it to the user. Currently implemented hook detection: * - Inline patches / Hooks (NOP, Exceptionhandler, relative Jumps, Custom patches) * - Other custom patches [...] * - VTable Hooks * - IAT and EAT Hooks * - Relocation Hooks * - Hardware Breakpoints * - PAGE_GAURD Candidates FAQ Why is IAT-Scanning / Hook-Scanning so slow? There are faster tools. ===================================================================== That's because other tools suck. They just walk the IAT Entrys and look for addresses that are out of the module bounds. Thats bollocks. The callback function of the hook, or a redirection (JMP) could be planted well within the module bounds, and there you have a stealth IAT Hook, which HookShark recognizes as "IAT - Local". And HookShark scans EVERY IAT-Table of EVERY Module. Unlike some other tools, which just examine the main process module. And HookShark does not only check for hooks in exported/known functions. No, byte by byte of disk/memory image is compared, and even one-byte-patches are revealed. That is only for read-only code-sections though. What the hell is all that crap? So many patches WTF? ====================================================== HookShark looks for differences between the disk image and the scanned memory. There might be cases where you are just looking at a packed module. To counter these false positives, there is an option to filter patches, which are bigger than n-bytes. (Look in the GlobalOptions Tab) Sometimes after i scanned a process and want to scan another one and it crashes. ================================================================================= Yeah, i hate when that happens. I have no idea why. If i get my lazy ass on the debugger i try to check it out. Until then, just restart HookShark. The mnemonics of patched instructions are wrongly displayed. ============================================================ That's because HookShark just cant do a thorough analysis like IDA does for every module in this short time-span. The alignment of instructions is guessed and heuristically computed. | |||
| Also listed in: | (Not listed in any other category) | |||
| More details: | Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry) | |||
| Tool name: | HookShark64 |
| ||
|---|---|---|---|---|
| Author: | DeepBlueSea | |||
| Website: | http://www.gamedeception.net/threads/23612-Article-HookShark64-Beta-0.1 | |||
| Current version: | 0.1.0.6 BETA | |||
| Last updated: | December 27, 2011 | |||
| Direct D/L link: | Locally archived copy | |||
| License type: | Free | |||
| Description: | Disadvantages of HookShark64 0.1 in comparison with 0.9: - Hooks of relocated .data pointers are not detected - rudimentary vtable-hook detection not implemented yet - No scanning for Code Injections takes place - no disassembler, no hex editor - no Class Instance Browser - No Listing of code references - Cant null a region (why would you need hookshark for this anyway?) - Showing Pageguard Candidates (which was broken anyway) - no unhook support yet Advantages of HookShark64 0.1: - Full support of x64 processes - like a 15 times faster or something (you will need at least SSE2) - dumping modules from the module window - sorting the process list (PID/ImageName) - Exempt modules from being scanned (checkboxes in module window) - a lot of Win7 fixes (ApiSetMap, thx to deroko) - show function name of hook destination if available - multithreading (IAT/EAT Hooks and Patchscanner have an own thread) - it saves all settings/filters, window position and size in an ini file You will get a lot of errors and bogus access violations in your log window. Why? Because checking everything carefully is slow. In 0.9 more checks were implented, which slowed the process down. In 64 0.1 many checks are omitted and simply wrapped around an exception handler. If an exception occurs, the next dll or the next codesection wil be scanned, without losing any results. However, if HookShark really crashes, or the logwindow output is more suspicous than it should be, for example if you happen to know that it should have picked up something, then feel free to bugreport it right here in this thread. Also: Beware using the Unchecking function for modules too carelessly. It can have some unwanted implications. For example: If the unchecked module is the destination of a hook elsewhere, the listing in the hook-result-window might not be as detailed. Another case would be: If the module has exports, which other modules import, it will show errors in the log and you might miss IAT hooks. Version History 0.1.0.0 - Initial Release 0.1.0.3 - Fixed unchecking and checking an unlinked module being displayed as linked module (red -> blue) - Show exact HookShark Version Number and Build in Log at startup 0.1.0.5 - fixed attempt to start x64server process on x86 platforms, when CPU was 64bit capable - allow more user interactions with GUI while scanning 0.1.0.6 - the offset within a symbol is now shown (example:ntdll.dll!LdrLoadDll+0x15 ) | |||
| Also listed in: | (Not listed in any other category) | |||
| More details: | Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry) | |||
| Tool name: | System Virginity Verifier |
| ||
|---|---|---|---|---|
| Author: | Joanna Rutkowska | |||
| Website: | http://www.invisiblethings.org/code.html | |||
| Current version: | 2.3 | |||
| Last updated: | February 27, 2005 | |||
| Direct D/L link: | Locally archived copy | |||
| License type: | Free / Open Source | |||
| Description: | Joanna Rutswoka provides on her site (invisiblethings.org) interesting papers and tools about rootkits since a few years and is a well known contributors on the official rootkit web site. SYSTEM VIRGINITY VERIFIER or SVV is very interesting because it checks the system for malicious hooking and also checks the integrity of code section modules directly in memory. After the verification, SVV notifies the user with five level of infection or seriousness: -level 0: 100% Virgin (not expected to ocuur in the wild); -level 1: Seems ok; -level 2: Innocent hooking detected; -level 3: Very suspected but may be a false positive; -level 4: compromised. The final verdict uses a color codification from blue to deepred. Resource: the SVV powerpoint presentation (available at invisiblethings.org). It's important to note that many softwares can interfere with the verdict: antivirus such as Kaspersky, desktop intrusion systems which operate at a low level like AntiHook, ProcessGuard and so on. SVV in action: After rebooting the PC in the diagnose mode, SVV gives its first verdict: Microsoft Windows XP [version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:WINDOWSsystem32>svv check /m module ntoskrnl.exe [0x804d7000 - 0x806ebf80]: 0x804db4f0 [RtlPrefetchMemoryNonTemporal()+0] 1 byte(s): exclusion filter: single byte modification file :c3 memory :90 verdict = 1 0x804dc032 18 byte(s): exclusion filter: KeFlushCurrentTb() file :d8 0f 22 d8 c3 0f 20 e0 25 7f ff ff ff 0f 22 e0 0d 80 memory :e0 25 7f ff ff ff 0f 22 e0 0d 80 00 00 00 0f 22 e0 c3 verdict = 1 0x804dc04a 1 byte(s): exclusion filter: single byte modification file :c3 memory :00 verdict = 1 0x804df16a 1 byte(s): exclusion filter: single byte modification file :05 memory :06 verdict = 1 module ntoskrnl.exe: end of details SYSTEM INFECTION LEVEL: 1 0 - BLUE --> 1 - GREEN 2 - YELLOW 3 - ORANGE 4 - RED 5 - DEEPRED Nothing suspected was detected. Level 1/Green: this a good news for a beginning. Now let's hook some windows APIs and let's see the new verdict: Microsoft Windows XP [version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:WINDOWSsystem32>svv check /m ntoskrnl.exe (804d7000 - 806ebf80)... module ntoskrnl.exe [0x804d7000 - 0x806ebf80]: 0x804db4f0 [RtlPrefetchMemoryNonTemporal()+0] 1 byte(s): exclusion filter: single byte modification file :c3 memory :90 verdict = 1 0x804dc032 18 byte(s): exclusion filter: KeFlushCurrentTb() file :d8 0f 22 d8 c3 0f 20 e0 25 7f ff ff ff 0f 22 e0 0d 80 memory :e0 25 7f ff ff ff 0f 22 e0 0d 80 00 00 00 0f 22 e0 c3 verdict = 1 0x804dc04a 1 byte(s): exclusion filter: single byte modification file :c3 memory :00 verdict = 1 0x804df16a 1 byte(s): exclusion filter: single byte modification file :05 memory :06 verdict = 1 0x804e72c4 [ExAllocatePoolWithQuotaTag()+0] 6 byte(s): JMPing code (jmp to: 0xbab1dbfc) address 0xbab1dbfc is inside TRACE.SYS module [0xbab1a000-0xbab26000] target module path: ??C:DOCUMENTS AND SETTINGSMICHELMES DOCUMENTSKAPIMON 2TRACE.SYS file :8b ff 55 8b ec 51 memory :ff 25 fc db b1 ba verdict = 2 0x804eb321 [ExAllocatePoolWithTagPriority()+0] 6 byte(s): JMPing code (jmp to: 0xbab1dba4) address 0xbab1dba4 is inside TRACE.SYS module [0xbab1a000-0xbab26000] target module path: ??C:DOCUMENTS AND SETTINGSMICHELMES DOCUMENTSKAPIMON 2TRACE.SYS file :8b ff 55 8b ec 53 memory :ff 25 a4 db b1 ba verdict = 2 module ntoskrnl.exe: end of details SYSTEM INFECTION LEVEL: 2 0 - BLUE 1 - GREEN --> 2 - YELLOW 3 - ORANGE 4 - RED 5 - DEEPRED Nothing suspected was detected. | |||
| Also listed in: | Kernel Hook Detection Tools | |||
| More details: | Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry) | |||
Feed containing all updates and additions for this category.
Feed containing all updates and additions for this category, including sub-categories.
