nx_authenticode_sign.nx

nx_authenticode_sign.nx -- F103e RUNG 10: attach an Authenticode signature to a PE32+ EFI image. The last software step before enrolment. Real EDK2 with MS keys refuses our unsigned .efi (Access Denied) while the SAME secboot firmware in SETUP mode runs it (debt 1786237435), so the image must carry a signature and our cert must be in db. Assembles, bottom-up: SpcIndirectDataContent ::= SEQUENCE { SpcAttributeTypeAndOptionalValue, DigestInfo } PKCS#7 ContentInfo ::= SEQUENCE { OID signedData, [0] SignedData } WIN_CERTIFICATE ::= dwLength || wRevision(0x0200) || wCertificateType(0x0002) || PKCS#7 then appends it 8-byte aligned and points data directory 4 at it. ★★★★★★THE TOOTH THIS RUNG WAS BUILT AROUND: **AFTER SIGNING, THE AUTHENTICODE HASH MUST BE BYTE-IDENTICAL TO BEFORE.** The certificate table and its data-directory entry are two of the three ranges the hash excludes, so if attaching a signature CHANGES the hash, the exclusion logic in nx_pe_authhash is wrong and every signature we ever produce is invalid. Nothing else in the chain tests that interaction -- the hasher alone cannot, because it never sees a signed file. ★Every OID is DERIVED by `der_oid_from_arcs` (validated in nx_x509_emit against the estate's own shipped SHA-256 OID), never a remembered byte string. ⚠SCOPE, NAMED: this produces a structurally complete Authenticode blob whose signature our own verifier accepts over the SpcIndirectDataContent DER. It is NOT yet proven against EDK2's AuthenticodeVerify -- that proof is the enrol-and-boot rung, and until it runs this organ's claim is "well-formed and self-consistent", not "accepted by firmware". Saying otherwise would be the exact self-certification the third reference exists to prevent. Usage: nx_authenticode_sign selftest [image.efi] Exit: 0 GREEN | 1 RED. Log -> knowledge/status/nishi_os.log, verdict= LAST. license_tier: ORIGINAL