How to decode Intune Win32 App Packages

The new Intune Win32 app management is a great way to deploy Win32 apps with Microsoft Intune. Imagine you have a kind of source share for all the .intunewin files you have created. At some point in time you like to modify a package but you do not have the source files right now, only the .intunwin package. Wouldn’t it be nice to convert the .intunewin package back to an unencrypted package? Additionally what is if you lost your complete sources, can we get them back directly from the Intune tenant?

As a quick reminder, the packaging workflow is like this:

  1. Compressing the source folder of the Win32 apps and its files to a sub folder ‘Contents’ with the new extension .intunewin
  2. Encrypting the compressed file
  3. Computing a SHA265 hash
  4. Generating a detection.xml file in a sub folder ‘Metadata’
  5. Compressing complete working folder and create again an .intunewin file
.intunewin compressed file – internal folder structure

As described in my previous post “Part 3, Deep dive Microsoft Intune Management Extension – Win32 apps” the portal and the Intune service gets all necessary information from the detection.xml file to deal with the Win32 app. The EncryptionInfo in the detection.xml file is stored with your Intune tenant to gain access to the uploaded encrypted .intunewin package. The encrypted .intunewin (located in the contents folder) can be distributed safely by Microsoft to the Intune back-end services responsible for content distribution without getting exposed to others, only the tenant who uploaded the file has the EncryptionInfo and can decrypt the file. The clients will get this information also when they are requesting Win32 apps for installation via policy.

If we try to open the inner encrypted .intunewin file with 7-Zip, it is expected to be not working. We will see the following error message:

I’m using the fact that the encryption information is stored along with the package before uploading. As long as this information is available we can make use of it. I wrote a small .net tool “IntuneWinAppUtilDecoder” to extract the .intunewin file content, read the EncryptionInfo from the detection.xml file to get the encryption key and initialization vector and decrypt the inner .intunewin package from the contents folder back to an unencrypted .intunewin package. Et voila – we have an unencrypted .intunewin.decoded file, which we can open with our favorite archiver like 7-Zip.

The IntuneWinAppUtilDecoder is available on my GitHub account here:

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

The direct download link to the zipped binary file is here.

Let’s have a look how the tool looks like when running. The command line utility is pretty simple to use, just point to the path of the .intunewin file and optionally you can run it in silent mode to prevent output. If you already have the encrypted .intunewin, and the encryption key, and the Initialization Vector you can provide these information on the command line as well:

IntuneWinAppUtilDecoder.exe <FullPathToIntunewinFile> [/s | /silent]
[/key:base64encodedKey /iv:base64encodedIV]

In my following example I’m decrypting an Adobe Acrobat Reader DC package:

As you can see the tool will ask for any overwrite and cleanup of extracted files before proceeding. Sometimes it is useful to keep the extracted content for further inspection. For easy proceeding just hit enter and let the tool do the cleanup of the extracted .intunewin content. After successful decryption we have now an additional .intunewin.decoded file in the same directory as the original .intunewin file:

This .decoded file can be opened with 7-Zip and easily extracted and here we have back the original sources:

When running the tool in silent mode /silent it will not ask for overwrite or cleanup, the overwrite of existing .decoded file and the cleanup of the extracted files is always done in silent mode.

How to get the sources back from the Intune tenant directly?

I discovered that all relevant download and decryption information to get the sources back from your tenant are in the regular log files of the Intune Management Agent here:
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

So I wrote a small PowerShell script to parse the logfile and extract all relevant information of the already installed .intunewin files (otherwise we would not have the log file entry :-)). This is an example of that log file entry:

<![LOG[Get content info from service,ret = {
"odata.metadata":"https://fef.msub03.manage.microsoft.com/SideCar/StatelessSideCarGatewayService/$metadata#SideCarGatewaySessions/@Element","odata.id":...
LOG]!>

Basically I’m searching for this particular log entry which I then decode with the certificates on the device as they include decryption information of the installed .intunewin file. The installed .intunewin file is encrypted and can only be decrypted by your device with the right certificate. The log entry does include the download location also. It would be possible to write a tool to request the file from Intune directly to get to this information but in fact then I would write lots of the parts of the agent my self again. Getting tokens for requests, dealing with discovery, decryption, etc. So I decided to not do that and let the agent to its job and grab the necessary information from the log files. In case of missing entries you can simply enroll a device and install all software via Company Portal on it to get all log entries and then parse this info for further usage.

So in the log entry we have everything we need. If we run the script provided below on an Azure AD joined device with Intune enrollment you can successfully decrypt the encryption information which you get from the Intune GatewayService to decrypt and download the encrypted .intunewin file. The agent itself does nothing else during a normal install. It requests a policy which includes the package info, content info and decryption info. I decode this as well and provide it as plain text to you, or we can simply pass this to the IntuneWinUtilDecoder as parameters for instant decryption.

The script can also be found on my GitHub account here: https://github.com/okieselbach/Intune/blob/master/Get-DecryptInfoFromSideCarLogFiles.ps1

Here the script in action, downloading an app discovered in the log entry (yellow is the download URL, cyan is the encryption info highlighted) and in the end decoding it:

I hope this small utility and script is as useful for you as for me as I deal with a lot of test deployments in my lab and miss from time to time my source files. With the IntuneWinAppUtilDecoder and the script I’m now able to simply extract my source files again in any case.

Have fun at decrypting 🙂 your .intunewin files!

Deploying Win32 app BGInfo with Intune

Deploying BGInfo to quickly find your test devices or provide easy VM access during trainings with more visibility of the available user permissions.

Deploying the well known Sysinternals tool BGInfo is popular since a very long time. Often people use it for more visibility of vital OS parameter to end users. It is used mostly to support in-house help desk personal. Today I’m using this approach, to provide a handy solution for your development or test environment to quickly identify your devices and logged on user including their permissions (local admin or standard user) in that session like this:

The undiscovered need for this was there all the time, e.g. during intensive testing in my development environments with a lot of virtual test devices and during class room training’s to make student life’s easier. I often test various features so Windows Version and Edition is important to know for me. As a nice addition I added the local permissions of the logged on user. Following an user logged on to an Autopilot device with standard user permission and a device without Autopilot and local administrator permissions:

Now you know my intention for this blog post. I was inspired by Nick Hogarth blog post (Intune – Win32 app Deploying BGInfo) about this and re-discovered my need 🙂 and took his solution and developed it a little further for my needs (thanks Nick!). I can recommend to read his blog as well as he has a nice walk through how to create and upload the Intunewin package for Intune and trace the installation itself. Like Nick I only focus on the x64 Edition of BGInfo64 as I’m not dealing with x86 devices for a long time now.

First I had to came up with a way to identify if the user is a local admin. BGInfo supports various ways to get OS information and one option is to use vbs scripts. So I wrote a short vbs script to verify local Administrators group membership. To handle this in a way to be language independent I’m resolving the local Administrators group SID S-1-5-32-544 (read about well known SIDs here) to the localized display name to finally enumerate account membership. 

GitHub Listing – CheckAdmin.vbs

The vbs script is dynamically written by the install script as CheckAdmin.vbs to the BGInfo install folder (C:\Program Files\BGInfo) during install. This way I do not have to maintain several files, only my install script. I followed the same way and created an install.ps1 to install BGInfo64.exe with the custom background information file custom.bgi. In addition I modified the startup shortcut creation to create the shortcut with the ActiveX object WScript.Shell in the PowerShell install script. The startup shortcut is needed to always have actual information on the background. Following the complete install.ps1:

GitHub Listing – install.ps1

To also provide uninstall capabilities I created the small uninstall.ps1 as well:

GitHub Listing – uninstall.ps1

The custom background information file custom.bgi was adjusted to present all information needed. Especially the CheckAdmin.vbs is referenced to get the user permission information:

For completeness I list the two registry keys I used for displaying the complete Version string e.g. 10.0.17763.194 (1809) 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ReleaseId

-> Windows Release e.g. 1809

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR

 -> Patchlevel e.g. 194

All files for the complete Intune Win32 app package can be found in my GitHub account here:
https://github.com/okieselbach/Intune/tree/master/Win32/BGInfo64

As always when dealing with Intune Win32 apps we need to package it as .intunewin and upload the package to Intune. Use the Packaging tool from here: https://github.com/Microsoft/Intune-Win32-App-Packaging-Tool. The complete conversion can be done in an one liner when the conversion tool is in the same folder structure level as the BGInfo folder with all needed files:

.\IntuneWinAppUtil -c .\BGInfo -s Bginfo64.exe -o .\ -q

For more details regarding packaging see my post: Part 3 Deep Dive Microsoft Intune Management Extension Win32 Apps. As soon as we have the BGInfo64.intunewin package we can upload it and specify the install and uninstall command lines with the install behavior System:

powershell -ex bypass -file install.ps1
powershell -ex bypass -file uninstall.ps1

As the detection rule we use a simple file exists for BGInfo64.exe in the install folder:

C:\Program Files\BGInfo
Bginfo64.exe

Finally you can assign it to your devices or users. I assigned it to all my devices as I like to have it on all my test devices:

If successfully installed you should see the following files:

Because it is installed in System context we need to logon once to trigger the startup shortcut to finally execute BGInfo in user context and create the background information. If everything runs fine you should get nice information about the device you are currently using and in which context you are running (admin or user permission).

I hope it may help you as it helps me and gives you an idea how to dynamically get OS parameters for BGInfo and display them.

Happy tattooing you backgrounds!

Part 3, Deep dive Microsoft Intune Management Extension – Win32 Apps

IntuneWin32ComboLogo

Microsoft made it finally happen and provides an integrated way to deploy Win32 Apps via the Intune Management Extension. This is by far the biggest step forward in the Modern Management field. Until now the community came up with lots of ways to utilize PowerShell scripts to finally install some Win32 Apps. By doing this you need to take care of the content location, availability, distribution, the app install, and verification logic. All this is now available in the enhanced Intune Management Extension. As a short refresh regarding Intune Management Extension, I recommend to read my blog articles about it, where you find a lot of information regarding the architecture, the inner workings, and troubleshooting advises:

Part 1 Deep dive Microsoft Intune Management Extension – PowerShell Scripts
Part 2 Deep dive Microsoft Intune Management Extension – PowerShell Scripts

Both articles are very relevant to this new feature as they all describe the architecture and technical details regarding the Intune Management Extension itself. Exactly this Intune Management Extension is used now for deploying Win32 apps packaged as .intunewin file format. It’s even better, the new functionality can be used to basically transport everything in a package and trigger a certain command line for execution. This is not a end to end walk-through how to use the feature in regards of the Intune portal or on the client itself. For this check out other great articles found in my last section End to end usage walk-throughs?. This is an article all about the inner workings of this new capability, a deep dive into the new technology itself.

Table of content for easy navigation

How do we get packaged apps now?

To get a Win32 apps deployed via the Intune Management Extension we first need to package the content we want to distribute. Microsoft decided to use the same approach like they did for the macOS world, where they provide a small tool to create the packages – Microsoft Intune App Wrapping Tool for macOS. A similar tool to create these packages is available for the Windows world now. This tool is called:

Microsoft Intune Win32 App Packaging Tool

For all of you with ConfigMgr experience, the new feature to deploy Win32 apps with Intune can be compared a little bit with the Packages and Programs functionality within ConfigMgr, but with some additions.

The usage of the Microsoft Intune Win32 App Packaging Tool (IntuneWinAppUtil.exe) is quite simple. We specify a folder and the executable and create then an yourappname.intunewin file. This is our packaged app which we then can upload to the Intune service. The command line of the tool is this:

IntuneWinAppUtil -c  -s  -o  <-q>

To dig a little deeper we inspect the resulting package in detail now. After successful execution it will generate the .intunewin file from the specified source folder and setup file. For MSI setup files, this tool will retrieve required information for later usage in the Intune portal. To explore this a little bit I captured the output and highlighted some important facts there, to gain understanding how the tool is working.

IntuneWin32AppToolOutput

As seen the tool is executed with the necessary parameters to create a package for Google Chrome Enterprise Edition Browser, which is provided as a .msi file. A sub folder called Chrome is in the same folder as the IntuneWinAppUtil. The command line then is:

IntuneWinAppUtil.exe -c .\Chrome -s GoogleChromeStandaloneEnterprise64.msi -o .\ -q

If we look at the green highlighted output now we find some very important information appearing which is exactly describing the workflow:

  1. Compressing the source folder and its files to a sub folder ‘content’ with the new extension .intunewin
  2. Encrypting the compressed file
  3. Computing SHA265 hash
  4. Generating a detection.xml file in a sub folder ‘metadata’
  5. Compressing complete working folder and create again an .intunewin file

As we can see a normal zip compression is used and therefore it is easy to verify all this by opening the generated package with our favorite archive application:

IntuneWinContentRoot

We can see the content folder and metadata folder. Where the content folder stores the encrypted .intunewin file:

IntuneWinContentSubContent

and the metadata folder contains the detection.xml file:

IntuneWinContentSubMetadata

If we now have a look at the detection.xml file we can see the information gathered about the package and msi file:

<ApplicationInfo xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ToolVersion="1.0.0.0">
<Name>Google Chrome</Name>
<UnencryptedContentSize>52284458</UnencryptedContentSize>
<FileName>GoogleChromeStandaloneEnterprise64.intunewin</FileName>
<SetupFile>GoogleChromeStandaloneEnterprise64.msi</SetupFile>
<EncryptionInfo>
<EncryptionKey>Rj9EtHeHGYMv5HYBpyobrmp0rVg0pzIy0TwO9PnSRg8=</EncryptionKey>
<MacKey>5kxZeuk6xfeMak+r/9hzbwS0vBUW1jBMhgN10Jy7XBQ=</MacKey>
<InitializationVector>2AK05qM3tm/5ijDnlFPISA==</InitializationVector>
<Mac>zI8vragiGb1VtbVRiKo3lPkJldZGZB4juX50MCNrmDw=</Mac>
<ProfileIdentifier>ProfileVersion1</ProfileIdentifier>
<FileDigest>Nzl3O6e70W1P0kJDJiWh3eU6gCVOhODNNy7mspfplQA=</FileDigest>
<FileDigestAlgorithm>SHA256</FileDigestAlgorithm>
</EncryptionInfo>
<MsiInfo>
<MsiProductCode>{A4BC9C54-4589-3A4C-8217-9FA00262F471}</MsiProductCode>
<MsiProductVersion>67.92.84</MsiProductVersion>
<MsiUpgradeCode>{C1DFDF69-5945-32F2-A35E-EE94C99C7CF4}</MsiUpgradeCode>
<MsiExecutionContext>System</MsiExecutionContext>
<MsiRequiresLogon>false</MsiRequiresLogon>
<MsiRequiresReboot>false</MsiRequiresReboot>
<MsiIsMachineInstall>true</MsiIsMachineInstall>
<MsiIsUserInstall>false</MsiIsUserInstall>
<MsiIncludesServices>false</MsiIncludesServices>
<MsiIncludesODBCDataSource>false</MsiIncludesODBCDataSource>
<MsiContainsSystemRegistryKeys>true</MsiContainsSystemRegistryKeys>
<MsiContainsSystemFolders>false</MsiContainsSystemFolders>
</MsiInfo>
</ApplicationInfo>

A detailed review shows us the file and encryption information and in addition the MSI file information. This information is used by the Intune portal to pre-populate some Intune app definitions for us.

The MSI information is only available when a msi file is packaged. If we package a setup.exe for example you will not see the entire section in the detection.xml file.

How can we decode Intune Win32 app packages?

I wrote a small utility to convert a .intunewin package back to it’s original sources. You can read more about it on my separate blog post here: How to decode Intune Win32 App Packages

Why is the .intunewin packaged like this?

This is pretty simple to explain. The portal and the Intune service gets all necessary information to deal with the app (in this case Google Chrome). The msi information listed in the detection.xml is used to simplify the setup within the Intune UI by pre-filling the app form during creation. For example by adding the install and uninstall commands for the msi automatically:

IntuneWin32AppsMSIInstallCommand

The EncryptionInfo is used to store it with your Intune tenant to gain access to the uploaded .intunewin package. The encrtypted .intunewin (located in the content folder) can be distributed safely to the Intune back-end services responsible for content distribution without getting exposed to others, only the tenant who uploaded the file has the EncryptionInfo and can decrypt the file.

Where can I find details of the Win32 App deployment?

The Intune Management Extension tracks some details of the Win32 apps in the registry at: HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Apps\

IntuneWin32AppDetailsRegistry

The yellow highlighted names provide us the execution commands for install and uninstall and the attempts and results of it.

If we look at the green highlighted GUID at HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\73d664e4-0886-4a… we can see it matches my Azure AD user object ID. To compare it I got the details via Azure AD PowerShell:

GetAzureADUser

The red highlighted GUID (b0f62b79-e464-4f95-afe2-ed99eb612fe5) is the application GUID which is assigned by the Intune service back-end. This can be easily traced by looking at the graph data with the Graph Explorer from Microsoft:

In my example I used this to retrieve the details of my uploaded app:

https://graph.microsoft.com/beta/deviceAppManagement/mobileApps/b0f62b79-e464-4f95-afe2-ed99eb612fe5

This is the detailed information about the uploaded Win32 .intunewin app:

{
"@odata.context": "https://graph.microsoft.com/beta/$metadata#deviceAppManagement/mobileApps/$entity",
"@odata.type": "#microsoft.graph.win32LobApp",
"id": "b0f62b79-e464-4f95-afe2-ed99eb612fe5",
"displayName": "Google Chrome (new)",
"description": "Google Browser",
"publisher": "Google",
"largeIcon": null,
"createdDateTime": "2018-09-21T09:38:11.4343585Z",
"lastModifiedDateTime": "2018-09-21T09:39:16.2037636Z",
"isFeatured": true,
"privacyInformationUrl": null,
"informationUrl": null,
"owner": "",
"developer": "",
"notes": "",
"uploadState": 1,
"publishingState": "published",
"committedContentVersion": "1",
"fileName": null,
"size": 52284512,
"installCommandLine": "msiexec /i \"GoogleChromeStandaloneEnterprise64.msi\" /q",
"uninstallCommandLine": "msiexec /x {A4BC9C54-4589-3A4C-8217-9FA00262F471} /q",
"applicableArchitectures": "x64",
"minimumFreeDiskSpaceInMB": null,
"minimumMemoryInMB": null,
"minimumNumberOfProcessors": null,
"minimumCpuSpeedInMHz": null,
"msiInformation": null,
"setupFilePath": null,
"minimumSupportedOperatingSystem": {
"v8_0": false,
"v8_1": false,
"v10_0": false,
"v10_1607": true,
"v10_1703": false,
"v10_1709": false,
"v10_1803": false
},
"detectionRules": [
{
"@odata.type": "#microsoft.graph.win32LobAppProductCodeDetection",
"productCode": "{A4BC9C54-4589-3A4C-8217-9FA00262F471}",
"productVersionOperator": "notConfigured",
"productVersion": null
}
],
"installExperience": {
"runAsAccount": "system"
},
"returnCodes": [
{
"returnCode": 0,
"type": "success"
},
{
"returnCode": 1707,
"type": "success"
},
{
"returnCode": 3010,
"type": "softReboot"
},
{
"returnCode": 1641,
"type": "hardReboot"
},
{
"returnCode": 1618,
"type": "retry"
}
]
}

Intune Management Extension Agent working folders?

If we have a look at the file system at:

C:\Program Files (x86)\Microsoft Intune Management Extension\Content

we can find some interesting folders where the agent is downloading the content and detection scripts and stores the actual MSI log files:

ItnuneWin32AppsFolders

Agent execution context when processing .intunewin files?

The agent is bound to the same restrictions during execution like we know them for PowerShell scripts, meaning the calling process (the Intune Management Extension agent) is a 32-bit process. This can result in some unexpected behavior. For example when trying to package a simple .ps1 file within a .intunewin and trying to execute cmdlets in this scripts which are only available in a 64-bit environment. We then have to use a technique to restart the PowerShell script as a 64-bit process. This is described in my previous articles and I have built a Intune PowerShell script template to simplify the start for this, which can be found on my GitHub here https://github.com/okieselbach/Intune/blob/master/ManagementExtension-Samples/IntunePSTemplate.ps1. This can also affect installers packaged as .intunewin when they assume a 64-bit environment!

If no restart technique is used keep in mind that environment variables must be handled with care from 32-bit processes. For example if you like to target the %windir%\System32 environment from a 32-bit process you have to use %windir%\Sysnative otherwise you will land in %windir%\SysWOW64. Visit the linkt to read more about the file system redirector: https://docs.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector


What are the retry and execution intervals?

The agent has default values for retry and execution:

  • max. of 3 retries
  • interval between the retries is 5 min.
  • max. execution run time is 60 min.

these limits are not adjustable at the moment.


Current Limitations (as per date Oct-2018)?

End to end usage walk-throughs?

Good walk-throughs on how to use the feature with the Intune portal and the end user experience can be found here:

Deploy Win32 Applications with Microsoft Intune
http://www.scconfigmgr.com/2018/09/24/deploy-win32-applications-with-microsoft-intune/

Deploy customized Win32 apps via Microsoft Intune
https://www.petervanderwoude.nl/post/deploy-customized-win32-apps-via-microsoft-intune/

Intune – sidecar for Win32 apps revealed
http://gerryhampsoncm.blogspot.com/2018/09/intune-sidecar-for-win32-apps-revealed.html

Intune Win32 App deployment – A gamechanger
https://ccmexec.com/2018/10/intune-win32-app-deployment-a-gamechanger/

Official documentation can be seen here

Intune Standalone – Win32 app management
https://docs.microsoft.com/en-us/intune/apps-win32-app-management

Remember to check back frequently as Intune progresses and the feature will be enhanced in short cycles. I will update the article accordingly.

Happy packaging, deploying and troubleshooting Win32 apps with Intune!