You are browsing the archive for Reversing.

API Monitoring under Windows 10

April 4, 2020 in Reversing

I recently asked around about Win10 API Monitoring. The reason I asked about it is that I noticed that:

  • API monitoring tools from the past no longer work (e.g. Rohitab, WIn32Override non-commercial version)
  • They are usually focused on 32-bit anyway
  • Many of them use legacy approach (aggressive hooking) that causes troubles on win10

I am looking for an alternative that works…

The following are the ideas I gathered from various sources (thanks to anyone who replied):

  • Frida
    • https://github.com/FuzzySecurity/Fermion
  • DTRace
    • https://techcommunity.microsoft.com/t5/windows-kernel-internals/dtrace-on-windows/ba-p/362902
  • Pinitor
    • https://rayanfam.com/topics/pinitor/
  • WinDBG Time Travel Debugging
  • Commercial SpyStudio
    • https://www.nektra.com/products/spystudio-api-monitor/download/
  • Commercial WinAPIOverride
    • http://jacquelin.potier.free.fr/winapioverride32/

API Monitoring is pretty important to reverse engineers. Not only it speeds up analysis, but it also paves a way to understand rapidly developing changes in the Windows environment. Old API Monitors primarily worked in 32-bit, used aggressive hooking, and often leveraged kinda dodgy kernel drivers, and csrss code injection. They also don’t understand New Low-Level Binaries, WOW, .NET, and Metro apps.

As such… it’s time for some creative soul to kick off a new project :-). A full blown API Monitor for 64-bit userland…

How would we go about building a tool like this?

Today is so much better than 15 years ago. I still remember hunting down API definitions in early noughties (e.g. re-using files with VB API declarations) and later writing scripts to extract API definitions from .hlp, .chm, .hx* files that MSDN/SDK help was shipped as, as well as ‘talking’ to local MSDN server to retrieve XML definitions of API… It was tough, inconsistent, but doable. In fact, the definitions for 12000 APIs that HAM monitored were built this way. And today it’s… easier. Only a few days ago Microsoft released a full-blown API documentation that can be easily transformed to API definitions that any API monitor can digest. Times changed…

So now that we have API definitions… all we need is a good API hooking engine.

Which technology to use? There are actually many available today… Modern sandboxes use hypervisors, emulation, but I don’t see these being used in any available API Monitosr. Moreso, the nature of reverse engineering often asks for tools that work inside a limited VM guest environment so neither emulation or hypervisors can be efficiently used on these systems (someone correct me on this!).

But things are not too bad. Alex Ionescu outlined a few interesting ideas in his presentation from … 2015, including time travel debugging, app verifier, miniwin, shims and CFG. We can also probably force-patch system DLLs (a bad idea!), or use either DotLocal or KnownDll modification to force-redirect loading of OS DLLs to a local directory where we can use our own versions of these libraries. I have not tested these ideas, but it may work. And then there is Frida and PIN as well as ReactOS and Wine. And after I posted this, a couple of guys pinged me to let me know that Detours still works on win10 pretty well (thanks!). Also, one more update from me, apparently Quiling can work too, as well as EasyHook library.

I started playing with these ideas and will see if I have enough strength to make it a workable solution, but in the meantime… the notes are here, If you are bored… I am sure RCE world will welcome any contribution.

If you know any existing tool that should be added to the list, or know an engine that could be used for API hooking that is not listed here, please let me know.

ShimBad the Sailor, Part 2

March 20, 2020 in Anti-Forensics, Reversing, Sandboxing

This part is more about archaeology than anything else.

The built-in SHIM database includes a number of test shims, which I will cover below.

On Windows XP, you will find these two:

So, if you happen to name your executable one of these:

  • WindowsXPAppsHelpMechanismBlockedTestApp.exe
  • WindowsXPAppsHelpMechanismTestApp.exe

you can immediately see their effect after you try to run them on XP:

WindowsXPAppsHelpMechanismBlockedTestApp.exe

WindowsXPAppsHelpMechanismTestApp.exe

On Win7 we got a few more:

  • AppsHelpMechanismTestAppBadMsg.exe
  • AppsHelpMechanismTestAppBadMsgBlocked.exe
  • WindowsXPAppsHelpMechanismBlockedTestApp.exe
  • WindowsXPAppsHelpMechanismTestApp.exe

The first one runs with no issues.

The second one is blocked without any indication.

The visible messages are as follows:

WindowsXPAppsHelpMechanismBlockedTestApp.exe

WindowsXPAppsHelpMechanismTestApp.exe

Finally, on Win10 it goes as follows:

  • AppsHelpMechanismTestAppBadMsg.exe
  • AppsHelpMechanismTestAppBadMsgBlocked.exe
  • BlockedTestApp_AMD64.exe
  • BlockedTestApp_AMD64_ANY.exe
  • BlockedTestApp_WOW64.exe
  • BlockedTestApp_X86_AMD64.exe
  • BlockedTestApp_X86_ANY.exe
  • BlockedTestApp_X86_WOW.exe
  • WindowsXPAppsHelpMechanismBlockedTestApp.exe
  • WindowsXPAppsHelpMechanismBlockedTestApp2.exe
  • WindowsXPAppsHelpMechanismBlockedTestAppSpecific.exe

and visible outputs are:

AppsHelpMechanismTestAppBadMsgBlocked.exe /
BlockedTestApp_WOW64.exe /
BlockedTestApp_X86_AMD64.exe /
BlockedTestApp_X86_ANY.exe /
BlockedTestApp_X86_WOW.exe /
WindowsXPAppsHelpMechanismBlockedTestApp.exe /
WindowsXPAppsHelpMechanismBlockedTestApp2.exe /
WindowsXPAppsHelpMechanismBlockedTestAppSpecific.exe

Okay. That’s it.

Hmm not really… digging through internals of SDB on Windows 10 one more time I gathered the following (and hopefully complete) list of all the the test suite items:

  • AppsHelpMechanismTestAppBadMsg.exe
  • AppsHelpMechanismTestAppBadMsgBlocked.exe
  • BlockedTestApp_AMD64.exe
  • BlockedTestApp_AMD64_ANY.exe
  • BlockedTestApp_WOW64.exe
  • BlockedTestApp_X86_AMD64.exe
  • BlockedTestApp_X86_ANY.exe
  • BlockedTestApp_X86_WOW.exe
  • WICAMockAppReinstallUpgrade.exe
  • WICAMockAppReinstallUpgrade2.exe
  • WICAMockAppReinstallUpgrade3.exe
  • WICAMockAppReinstallUpgradeInfo.exe
  • WICAMockAppReinstallUpgradeWarn.exe
  • WICAMockAppReinstallUpgradeWarnBackup.exe
  • WindowsTH_BlockedSetupTestApp.exe
  • WindowsTH_TestApp_HardBlock_FWLink.exe
  • WindowsTH_TestApp_HardBlock_KBArticle.exe
  • WindowsTH_TestApp_HardBlock_NoInfo.exe
  • WindowsTH_TestApp_HardBlock_StoreId.exe
  • WindowsTH_TestApp_HardBlock_Wildcard1.exe
  • WindowsTH_TestApp_HardBlock_Wildcard2.exe
  • WindowsTH_TestApp_SoftBlock_FWLink.exe
  • WindowsTH_TestApp_SoftBlock_KBArticle.exe
  • WindowsTH_TestApp_SoftBlock_NoInfo.exe
  • WindowsTH_TestApp_SoftBlock_StoreId.exe
  • WindowsXPAppsHelpMechanismBlockedTestApp.exe
  • WindowsXPAppsHelpMechanismBlockedTestApp2.exe
  • WindowsXPAppsHelpMechanismBlockedTestAppSpecific.exe
  • WindowsXPAppsHelpMechanismTestApp.exe
  • WindowsXPAppsHelpMechanismTestApp2.exe
  • WindowsXPAppsHelpMechanismTestAppSpecific.exe

So, how could you use it for malicious purposes? I dunno… One thought I have is about emulators. If you created a child process using one of these names (creation of such process should fail by SHIM design), could you use the successful exitcode from that process to detect an emulator?