|An API Monitor That Speaks My Language – Perfect for AppCompat and Application Virtualization (and it’s Free)!|
|Written by Darwin Sanoy|
|Sunday, September 26, 2010 9:00pm|
I am an unapologetic WinDbg illiterate. I can’t read it and don’t understand it. My 3 GB, dual-core computer can functionally translate any web page I visit into my native human language – does tracing Windows applications really have to be THIS difficult? Not anymore.
Every time I’ve ventured to get more familiar with WinDbg (pronounced “Wind Bag”) I have become more aware that maintaining expertise with it will continue to demand a significant portion of my waking hours – for the rest of my natural life. Granted, you can see any and everything with WinDgb, but the ever growing popularity of tools like Process Monitor point to a strong desire by all to have tools that are not hovering barely above reading binary code directly.
Tools from Sysinternals and Nirsoft have steadily made “post compile” debugging and troubleshooting easier – but there are still fundamental disconnects.
Process Monitor deals with the results of the API calls occurring between your application and the OS. It sits under everything. Application Compatibility Toolkit applies fixes at the API or “DLL Function” level. Making the translation between these two is black art only know to the likes of Windows internals expert Mark Russionvich and Chris Jackson – the App Compat Guy.
Configuring Process Monitor (Procmon.exe) with debug symbols allows it to expose much more useful data to be determined – especially with the stack summary tool. However, the critical missing piece is the parameters that are being passed among the APIs.
Among the useful things parameter data can reveal are:
To be fair, debugging tools, when used with the APILogging shim give the same information, however, it requires several manual configuration steps and additional configuration steps if logging an EXE running with standard user permissions. To the plus side of the debugging tools logviewer is the ability to do output filtering - in Rohitab you have to apply filters and re-run your trace.
Enter “Rohitab API Monitor”. Rohitab API Monitor creates a heirarchical tree view of all the API calls of each of the threads in a process or list of processes you choose to monitor. Which APIs to monitor can also be selected.
Below I have included some screenshots that tell how I am pretty sure I figured out how this EXE was checking for Admin rights in a way that is not trapped by AppCompat’s ForceAdminAccess.
Learn how to use Rohitab API Monitor, Procmon and other great troubleshooting tools by registering for our AppCompat training course today! Details: CSI-450 – Windows 7 LUA/Non-Admin Application Integration.
Figure 1 – API Selection
Figure 1 shows the api selection filter – it is somewhat more helpful than a list by API name, but generally check them all for this type of debugging since I can never be certain which ones will yield the insights needed to find the problem.
Figure 2 – DLL Load Including Path Information.
Figure 2 shows a call to load a DLL (advapi32.dll) and includes the search path used in this particular case. It is easy to see how .LOCAL and SideBySide isolation would be revealed here.
Figure 3 – API Call Showing AppCompat Intercept
Figure 3 shows AppCompat (AcLayers.DLL) successfully intercepting a well known method of determining Admin rights using the ForceAdminAccess shim. Searhing RegOpenKeyExW in the AppCompat help file (ACT.chm) shows the fixes that are capable of intercepting this API call. In Process Monitor the registry write becomes invisible once it is handled by AppCompat, but API Monitor picks it up.
For AppCompat monitoring it is very helpful that the API references in this monitor match the references in the AppCompat documentation.
Figure 4 – API Call Monitor Showing Missed Admin Check
ForceAdminAccess is not catching how this particular program checks for admin rights. Figure 4 shows the program opening Service Control Manager (OpenSCManager) when this EXE does not use services at all. This makes me suspicious that it is being used to determine whether the EXE has admin rights. One of the API parameters is a big hint – it’s called “SC_MANAGER_LOCK” – I’m thinking not just anyone can do a lock
Figure 5 – Built in Googling of DLL Functions
Figure 5 shows the built in ability to Google the API.
Figure 6 – Admin privileges required.
Figure 6 shows information on that page that helps confirm this suspicion.
Figure 7 – Service Control Manger permissions.
Click “Service Security and Access Rights” from the API documentation showed the information in Figure 7 detailing that the SC_MANAGER_LOCK permission is required to make a call to lock the service database.
This means that opening the service configuration manager with this permission would provide a non-destructive (not changing anything) method of determining Admin rights. If you are denied access you know you don’t have admin rights. If you are given access you know that you have admin rights and can immediately close the service control manager using CloseServiceHandle.
To prove out this theory I compared the above failed trace information with a successful trace where the EXE was elevated upon start up. In the trace of the successful run the call to OpenSCManagerW was followed by three calls not in the failed trace, these were (in order) to the functions: LockServiceDatabase, UnlockServiceDatabase and CloseServiceHandle.
This exciting tool is free and you can run it in a portable mode – no need to install it!
Learn how to use Rohitab API Monitor and other great troubleshooting tools by registering for our AppCompat training course today! Details: CSI-450 – Windows 7 LUA/Non-Admin Application Integration.
You can download it at: http://www.rohitab.com/downloads