IME debugging and Intune Win32 App decoding – Part 2

Three years ago, I coded a small utility to decode Intune Win32 Apps and wrote a blog post about it – How to decode Intune Win32 App Packages. In addition to the small Decoder utility, I wrote a short PowerShell script to parse the Intune Management Extension (IME) log file to extract the necessary decryption information received by IME via Policy request. This changed lately as Microsoft changed the IME and what is finally written into the log file. The necessary policy request with the decryption information is not written into the log file anymore. Though there is no chance to extract any decryption information anymore.

I looked at different ways to get this information again. As a quick reminder the uploaded Win32 App content is stored in encrypted form on a CDN by Microsoft. The decryption information is stored at the Intune service and transferred by policy request when the client requests a Win32 App.

So why not do the exact same thing as the IME does? Figuring out how the IME requests Win32 App content and do the same in a small C# utility to receive the Policy, containing decryption information and et voilà we can use it once again to decrypt the encrypted .intunewin file from the CDN. I was in the middle of analyzing the IME requests, monitored the traffic, constructed the HTTP requests with the necessary headers for authentication and so on. Compared everything with the original requests of the IME on a test client, figured out the Win32 App policy request and step by step I was closer to my goal to be able to request Win32 app content via a small utility. During all this research I looked a lot at the traffic, IME workflow, log files, and so on. At one point in time, I thought about an initial idea I had a few months ago. My initial thought was not to replicate IME policy requests (too much danger something changes, why not leave the work to the IME and still get the information somehow), better would it be to get the information from the IME itself. This way changes from Microsoft to IME do not impact my small utility. So how can we get IME to log the policy requests once more? Another thought was to look at the Debug output with DebugView. Maybe IME does some debug output and I can capture it…

But guess what, no real luck with that. But what about the typical .NET Trace Listeners used to create log files? .NET Programs are coded in general by using Trace Listeners to wirte log files. These Trace Listeners have a .NET configuration in the typical .NET application settings config. We can find such a config for the IME in the IME install folder as well:

If we open this with our favorite editor Visual Studio Code, we can find the SCClientFileTrace listener config I’m talking about. And as you can see a value called switchValue wich typically defines the log level, the level of output to generate. Information, Verbose and Trace are typical values here:

How about modifying the trace listener config to switchValue=”Verbose” and restart the IME service?

Chackaaa!!! A plan that worked flawlessly! The IME log file immediately showed more log entries even the requested Token is logged to the log file and with some hawk eye observations I spotted my missed entry for the DecryptInfo again in a logged Response entry. That’s what we are looking for!

Finally, it was only necessary to change my PowerShell download script and provide a convenient way to enable Verbose logging in IME. But here a very important advice!! As you can see in the example output above sensitive information may be logged into the log file and is resting on the client after enabling the Verbose logging.

Please enable Verbose logging only for troubleshooting purposes or to download and decrypt the Intune Win32 Apps. Afterwards you should revert the log level back to Information and delete the log files to prevent any misuse of the log file content.

So, I changed the PowerShell script to extract the DecryptInfo and call my Decoder utility to directly download the encrypted .intunewin and decrypt it.

On my test device I had installed 2 apps and the parsing of the log file returned them back in an unencrypted way. A small modification on the Decoder utility lets you now specify the output folder with a new parameter /filePath:

The result is a nice “{ApplicationId}.decoded.zip” archive in addition to the encrypted downloaded file. The id is the ApplicationID received from the log file. I’m not aware of a quick and easy way to translate the Application ID to DisplayName. There is the option to parse the log file once again, there are corresponding entries where you can find the Application ID and the DisplayName. I might add this to the script but it might also break easily if these log entries change.

The ‘ApplicationId.decoded.zip’ archive can be opened with your favorite Archiving tool like 7-zip:

As you can see everything is accessible 💪👌

The change of the log level of IME might give a lot of other opportunities to get more insights into the way IME does its job. Not only for this purpose it is helpful, it might help in various troubleshooting scenarios as well.

To make life easier now I added PowerShell script parameters (EnableVerboseLogging, DisableVerboseLogging) to enable and disable Verbose logging.

The functionality is simple, reading the xml config file, changing the value to Verbose or Information:

The final PowerShell script must be run as Administrator on a device joined to Azure AD and enrolled into Intune. We need to enable Verbose logging upfront. The Apps should be scoped to the device and installed, via Available or required trigger, both results in the needed log file entries. We need the enrollment certificates for decryption and the log file containing the Win32 app information. Finally, we run the script to extract the log file information for download and decryption via:

GetDecryptionInfoFromLogFile.ps1 -RunDownloadAndExtract -TargetDirectory C:\Temp

The PowerShell script and the updated Decoder utility can be found here:

https://github.com/okieselbach/Intune/tree/master/IntuneWinAppUtilDecoder

Have a look into the subfolder IntuneWinAppUtileDecoder for the PowerShell Script and in the Subfolder Release for the binary of the decoder as exe or zip.

The small research endeavor showed me once more that the solutions finally found might be simple, which is my favorite outcome :-D. My work already done to replicate the request would have been way more work finally and is vulnerable to break as Microsoft might change the way of interaction, which would lead to once more intensive reverse engineering.

I hope the Log Level might help in various situations and I’m glad I have a way to get back my Intune Win32 Apps again.

Until next time, happy debugging and Win32 App downloading to all!