exref.pl

a very common problem in static code analysis is finding an exported functions that refers to some desired address. For example KseEngine has 21 references in windows kernel but only 5 of these functions are exported
So I wrote simple perl script for IDA Pro to automate this boring work. Sample of output for KseEngine:
_KseQueryDeviceFlags@12: 74A6C1 addr 74A6E2
_KseQueryDeviceData@20: 74A75B addr 74A77A
_KseQueryDeviceDataList@16: 7A5E74 addr 7A5E95
_KseSetDeviceFlags@16: 7A672D addr 7A6760
_KseUnregisterShim@12: 7A692B addr 7A698B


wincheck rc8.49

Download mirror
Changelog:

• add checking of shims inside apphelp.dll
• add checking of ole32 hook callbacks like pfnInitHookOle/pfnUninitHookOle/pfnEnableHookObject etc
• add some identification of applications within AppContainer
• add checking of KernelBase.dll!pfnAdjustObjectAttributesForPrivateNamespace (windows 8.1 only)
• some other bugs were fixed

how to find ntdll!LdrpHashTable

Old article (warning - it is written in French and has eye-breaking font) describes a good idea of loaded modules cross-scaning using LdrpHashTable. But Ivanlef0u did not show how you can find address of LdrpHashTable with static analysis
It seems that this is not easy task - xrefs to LdrpHashTable are not inside exported functions and they called too deeply from nearest export:

• LdrpResolveDllName
• LdrpFindLoadedDllByName
• LdrpInsertDataTableEntry

so ordinary code-flow graph analysis is very difficult. But actually there is more easy way to find address of LdrpHashTable

Inside the Microsoft Build Engine

it seems that book contains huge amount of misprints. for example on page 79:

The syntax when accessing a static property would be as follows:
$({ClassName}::{PropertyName})

o`k, lets check sample of using static properties:
<Message Text="DataTime.Now: $([System.DateTime]::Now)"/>
and below in PropertyFunctions02.proj was used GetPathToSystemFile('msbuild.exe') but output shows path to mspaint.exe