Skip to content

Commit

Permalink
docs: improve readme
Browse files Browse the repository at this point in the history
  • Loading branch information
maxihafer committed Oct 22, 2024
1 parent 07a2f80 commit 169b832
Showing 1 changed file with 10 additions and 12 deletions.
22 changes: 10 additions & 12 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,16 +22,15 @@ docker run ghcr.io/maxihafer/content-prep:latest \


## Motivation
Microsoft provides its closed-source [Content-Prep-Tool](https://github.com/microsoft/Microsoft-Win32-Content-Prep-Tool). For packaging Applications for intune.
Microsoft provides its closed-source [Content-Prep-Tool](https://github.com/microsoft/Microsoft-Win32-Content-Prep-Tool) for packaging Applications for intune.
Being just a checked in `.exe` file, it is neither possible to verify the code nor its behavior.
It is also not possible to run it on a non-Windows platform.

There exist great open-source projects that implement the same functionality. Even though some of them work cross-platform, they still rely on `.NET` and `PowerShell` which is not ideal for my usecase of publishing intune packages from CI/CD.
There exist great open-source projects that implement the same functionality. Even though some of them work cross-platform, they still rely on `.NET` and `PowerShell` which is not ideal for the use case of easily publishing intune packages from CI/CD.

The great work of [@svrooij](https://github.com/svrooij) really helped alot in understanding the inner workings of Intune packages:

- [Content-Prep](https://github.com/svrooij/ContentPrep) - `.NET/PowerShell` implementation of the Content-Prep functionality.
- [WinTuner](https://github.com/svrooij/wingetintune) - Very Sophisticated `PowerShell` Module for creating, deploying and managing Intune packages.
- [WinTuner](https://github.com/svrooij/wingetintune) - Very sophisticated `PowerShell` Module for creating, deploying and managing Intune packages.
- [The Intune series in his blog](https://svrooij.io/2023/08/30/apps-intune/) - Great insights into the inner workings of `.intunewin` packages. Very well written and concise.

## Intune package structure
Expand All @@ -47,7 +46,7 @@ foo.intunewin (zip)
```

### `IntunePackage.intunewin`
This is a encrypted `.zip` file containing the actual content of the package. More info can be found in the [Encryption Section](##encryption).
This is a encrypted `.zip` file containing the actual content of the package. More info can be found in the [Encryption Section](#encryption-process).

### `foo.intunewin/Metadata/Detection.xml`
The `Detection.xml` file is read by Intune to extract all kinds of information about the package. It is a `XML` file with the following structure:
Expand All @@ -72,13 +71,12 @@ The `Detection.xml` file is read by Intune to extract all kinds of information a
## Encryption Process

1. The source folder (`src`) is zipped without any compression to a temporary file.
2. The output file (`out`) is created and its write position is forwarded by the length of the HMAC.
4. The IV is written to the output file (at position `0 + len(HMAC)`) as well as the HMAC itself.
5. The zipped `src` is then XORKeyStreamed into the output file starting at position `0 + len(HMAC) + len(IV)` as well as into the HMAC.
6. The HMAC is then calculated and written to the output file at position `0`.
7. The output file digest is calculated and written to the `Detection.xml` file. **_NOTE:_** As `src` is a zip archive, the digest changes from execution to execution, though the content is the same. This is due to the fact that the zip archive contains the file creation time in its header.

The encryption key, HMAC key and IV are generated randomly at the start of the encryption process and stored in the `Detection.xml` file.
2. The output file (`out`) is created and its write position is advanced by the length of the HMAC.
3. The IV is written to the output file (at position `0 + len(HMAC)`) as well as the HMAC itself.
4. The zipped `src` is then XORKeyStreamed into the output file starting at position `0 + len(HMAC) + len(IV)` as well as into the HMAC.
5. The HMAC is then calculated and written to the output file at position `0`.
6. The metadata is written to the `Detection.xml` file.<br/>
**_NOTE:_** the digest changes from execution to execution,. This is due to the fact that the zip archive contains the file creation time in its header.

The resulting structure of the encrypted file is as follows:

Expand Down

0 comments on commit 169b832

Please sign in to comment.