From 35d4edc62389b1d0f595908da64003da7ba1ed33 Mon Sep 17 00:00:00 2001 From: Kawa Date: Mon, 13 Apr 2026 12:08:59 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20update=20debug=20session=20=E2=80=94=20?= =?UTF-8?q?HMAC=20scope=20bug=20identified=20and=20fixed?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Session now records the second root cause (HMAC over ciphertext-only vs IV+ciphertext) and the fix applied in commit 74535ea. Status moved back to awaiting_human_verify for next Intune upload retry. Co-Authored-By: Claude Sonnet 4.6 --- .../phase-10-rtval-01-intunewin-parse-fail.md | 43 ++++++++++++++----- 1 file changed, 32 insertions(+), 11 deletions(-) diff --git a/.planning/debug/phase-10-rtval-01-intunewin-parse-fail.md b/.planning/debug/phase-10-rtval-01-intunewin-parse-fail.md index b76895a..414af4e 100644 --- a/.planning/debug/phase-10-rtval-01-intunewin-parse-fail.md +++ b/.planning/debug/phase-10-rtval-01-intunewin-parse-fail.md @@ -2,15 +2,15 @@ status: awaiting_human_verify trigger: "phase-10-rtval-01-intunewin-parse-fail" created: 2026-04-13T00:00:00Z -updated: 2026-04-13T09:30:00Z +updated: 2026-04-13T10:30:00Z --- ## Current Focus -hypothesis: CONFIRMED — Detection.xml had four structural defects vs IntuneWinAppUtil.exe reference. -test: Fixed intunewin_builder.py, updated tests, 114/114 pass. -expecting: Rebuilt package will parse correctly in Intune wizard. -next_action: Rebuild package in ImpTune UI and retry upload to Intune tenant to confirm fix end-to-end. +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 @@ -26,10 +26,14 @@ started: First time the generator has been tested against a real Intune tenant. evidence: python -m zipfile -l confirms correct IntuneWinPackage/Contents/ and IntuneWinPackage/Metadata/ layout timestamp: 2026-04-13T00:00:00Z -- hypothesis: encryption algorithm is wrong - evidence: code uses AES-256-CBC with PKCS7 padding, 16-byte IV, HMAC-SHA256 — matches reference +- 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 @@ -47,11 +51,28 @@ started: First time the generator has been tested against a real Intune tenant. 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 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: intunewin_builder.py builds Detection.xml with four structural errors vs the IntuneWinAppUtil.exe reference (svrooij/ContentPrep Packager.cs + ApplicationInfo.cs verified): (1) missing required ToolVersion="1.8.6.0" XML attribute on ApplicationInfo, (2) spurious xmlns="http://schemas.microsoft.com/IntuneWin" namespace that changes element identity for Intune's XML parser, (3) XML declaration header which the reference omits (OmitXmlDeclaration=true), and (4) extra MacAlgorithm child element not present in reference FileEncryptionInfo model. -fix: Rewrote Detection.xml generation in intunewin_builder.py — added ToolVersion attribute, removed xmlns, switched to tostring(xml_declaration=False) + indent() instead of toprettyxml(), removed MacAlgorithm. Updated tests to match reference format. +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, 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 - - tests/test_intunewin.py + - imptune/generators/intunewin_builder.py (HMAC scope fix) + - tests/test_intunewin.py (test updated for corrected HMAC scope)