ImpTune/.planning/debug/phase-10-rtval-01-intunewin-parse-fail.md

---
status: awaiting_human_verify
trigger: "phase-10-rtval-01-intunewin-parse-fail"
created: 2026-04-13T00:00:00Z
updated: 2026-04-13T10:30:00Z
---

## Current Focus

hypothesis: HMAC is computed over `ciphertext` only, but the reference (svrooij/ContentPrep, confirmed by multiple sources) computes it over `IV + ciphertext`. This causes Intune's HMAC verification to fail silently, producing the exact symptom: empty fields, OK button greyed, no error banner.
test: Inspect svrooij C# DecryptFileAsync: after reading first 32 bytes (HMAC), it hashes "remaining bytes" = IV+ciphertext. ImpTune computes HMAC over ciphertext only (line 81: `hmac.new(mac_key, ciphertext, ...)`).
expecting: If confirmed, fixing HMAC to cover `iv + ciphertext` will fix the package.
next_action: Fix HMAC computation in intunewin_builder.py and update tests.

## Symptoms

expected: Uploading the .intunewin to Intune parses metadata, populates Name/Platform/Size/MAM-enabled fields, enables OK button.
actual: Intune accepts upload but never populates the metadata form. All fields stay empty. OK button stays greyed out. No error banner.
errors: Silent metadata-parse failure inside the wizard.
reproduction: Build with ImpTune, upload to Intune Apps > Windows > Add > Windows app (Win32).
started: First time the generator has been tested against a real Intune tenant. Never worked in production.

## Eliminated

- hypothesis: archive layout is wrong (different folder structure)
  evidence: python -m zipfile -l confirms correct IntuneWinPackage/Contents/ and IntuneWinPackage/Metadata/ layout
  timestamp: 2026-04-13T00:00:00Z

- hypothesis: encryption algorithm (AES mode, IV size, padding) is wrong
  evidence: code uses AES-256-CBC with PKCS7 padding, 16-byte IV — matches reference. Algorithm itself correct.
  timestamp: 2026-04-13T00:00:00Z

- hypothesis: Detection.xml structural defects alone caused the failure (prior hypothesis)
  evidence: Detection.xml was fixed in commit 7716246 (no xmlns, no XML decl, added ToolVersion attr, removed MacAlgorithm). Human verification came back with IDENTICAL symptom. Fix was real but not sufficient. Bug is deeper.
  timestamp: 2026-04-13T10:30:00Z

## Evidence

- timestamp: 2026-04-13T00:00:00Z
  checked: Copieur_2eme.intunewin archive layout
  found: Correct paths — IntuneWinPackage/Contents/IntunePackage.intunewin + IntuneWinPackage/Metadata/Detection.xml
  implication: Archive layout is not the issue

- timestamp: 2026-04-13T00:00:00Z
  checked: Detection.xml from Copieur_2eme.intunewin
  found: Has xmlns="http://schemas.microsoft.com/IntuneWin", has <?xml version="1.0" ?> declaration, missing ToolVersion attribute, has MacAlgorithm child element
  implication: Multiple structural deviations from reference

- timestamp: 2026-04-13T00:00:00Z
  checked: svrooij/ContentPrep reference implementation (Packager.cs + ApplicationInfo.cs)
  found: (1) ToolVersion="1.8.6.0" is an XML ATTRIBUTE on ApplicationInfo, (2) NO xmlns namespace ([XmlRoot("ApplicationInfo")] with no Namespace param + empty XmlSerializerNamespaces), (3) OmitXmlDeclaration=true so no <?xml?> header, (4) FileEncryptionInfo model has NO MacAlgorithm field
  implication: ImpTune's Detection.xml deviates in 4 ways from the reference. The missing ToolVersion and wrong namespace are the most likely causes of Intune wizard silence.

- timestamp: 2026-04-13T10:30:00Z
  checked: Human verification result after Detection.xml fix (commit 7716246)
  found: Same exact symptom — empty fields, OK greyed, no error banner. Bit-for-bit identical failure. Post-fix package was NOT checked into evidence/.
  implication: Either (a) stale build tested, or (b) additional structural bug beyond Detection.xml. Must assume (b) since symptom is bit-for-bit identical.

- timestamp: 2026-04-13T10:30:00Z
  checked: svrooij decryption article — DecryptFileAsync algorithm
  found: After reading first 32 bytes (HMAC), method computes hash of "remaining bytes" (= IV + ciphertext). Multiple web sources confirm: "HMAC is computed over IV + ciphertext combined".
  implication: ImpTune computes HMAC over ciphertext only (intunewin_builder.py line 81: hmac.new(mac_key, ciphertext, ...)). Reference computes over iv+ciphertext. This is a cryptographic mismatch that Intune would detect silently.

- timestamp: 2026-04-13T10:30:00Z
  checked: packages.py get_intunewin_package endpoint
  found: output_path = os.path.join(tmpdir, "out.intunewin") — output file is inside source_dir passed to build_intunewin(). build_intunewin walks source_dir FIRST (step 1), output_path does not exist yet, so it is NOT included in inner ZIP.
  implication: No self-inclusion bug. Endpoint code is structurally correct.

## Resolution

root_cause: TWO bugs, both in intunewin_builder.py:
  (1) Detection.xml structural errors — 4 deviations from IntuneWinAppUtil.exe reference: missing ToolVersion attribute, spurious xmlns namespace, <?xml?> header, extra MacAlgorithm element. Fixed in commit 7716246.
  (2) HMAC scope bug — HMAC was computed over ciphertext only, but the reference (svrooij/ContentPrep DecryptFileAsync) hashes the "remaining bytes" after the stored HMAC = IV+ciphertext. Intune's HMAC verification uses HMAC(mac_key, iv+ciphertext) but the stored value was HMAC(mac_key, ciphertext). This is a silent authentication mismatch that would cause Intune to reject the encrypted payload, manifesting identically to the XML bug: empty form fields, greyed OK button, no error banner. Fixed in commit [new commit].
fix: Changed HMAC computation from hmac.new(mac_key, ciphertext, ...) to hmac.new(mac_key, iv + ciphertext, ...). Updated test_hmac_matches to verify HMAC over iv_and_ciphertext = blob[32:] (matches reference decryption: hash all bytes after the stored MAC).
verification: 114/114 tests pass. Awaiting human confirmation from Intune upload retry.
files_changed:
  - imptune/generators/intunewin_builder.py (HMAC scope fix)
  - tests/test_intunewin.py (test updated for corrected HMAC scope)