diff --git a/docs/ci-validate-file-object.md b/docs/ci-validate-file-object.md index ddbf516..62be7f6 100644 --- a/docs/ci-validate-file-object.md +++ b/docs/ci-validate-file-object.md @@ -1,8 +1,9 @@ # CiValidateFileObject: validation flag 0x00000020 -Issue #3 is **documented; kernel runtime verification is pending**. The probe -builds and its plumbing is covered by host tests, but those tests do not execute -Windows Code Integrity. Do not close the runtime-testing portion on that basis. +Issue #3 is **documented; its TESTSIGNING-off runtime experiment is pending**. +A related signer-selection experiment has now run successfully on Windows 11 +22631 with TESTSIGNING enabled (below). That run does not close the requested +19041/19045 flag 0 versus 0x20 TESTSIGNING-off comparison. ## Meaning supported by the evidence @@ -181,6 +182,41 @@ Self-signed acceptance must be reported explicitly, not confused with public-CA publisher trust. Do not use this flag as a new production default based only on one positive fixture. +## Multiple signatures: a separate kernel experiment + +`0x20` is an accepted-root control, not a recovered "PE image" type flag. +In the examined 22621.2792 and modern 26100 x64 bodies it leaves the +preferred-signing-level search active. `PolicyInfo` can therefore describe a +nested Microsoft signature even when the primary company signature also verifies. + +The first-success guard tests aggregate masks `0xE47FFF87` (22621.2792) and +`0xE41FFF87` (modern 26100). `0x20` intersects neither; `0x80` intersects both. +Compare flags `0x20` versus `0xA0`, requested signing level zero, on the same +stable dual-signed file. Record the actual selected leaf/thumbprint, both policy +statuses and signing time. Do not interpret status success alone as selection +of the company certificate. First successful does not necessarily mean first +listed: CI may reject the primary and continue. + +`0x80` has additional policy and fallback effects. It has not been published as +a supported Domito constant or a production default. The companion research +`SIGNATURE-SELECTION.md` provides the full static evidence and an alternative +primary-signature path using `CiCheckSignedFile`. + +A user-run kernel probe on Windows 11 **10.0.22631 x64**, CI options **0x00080207** +(TESTSIGNING enabled), confirms the selection difference for the exact dual-signed +BthPS3 fixture: `0x20` returns Microsoft, while `0xA0` returns the Nefarius leaf +`FF0CCF318FD8C14775023A0B52C28FFCCA59D7F7` and signing time +**2026-10-02T18:32:01.000Z**. Direct primary SHA-256 `CiCheckSignedFile` returns +the same Nefarius leaf, signer/timestamp policies and signing time. All three +calls return STATUS_SUCCESS; all policy VerificationStatus fields also succeed. +The file digest is identical across calls, before/after file hashes match, and +TraceFmt reports 149 events with no losses, format errors or unknown formats. + +The companion `signature-selection/runtime-22631-bthps3.json` records exact +trace hashes and the on-disk CI hash. This is one test-signing-enabled run; +TESTSIGNING-off, other builds/policies and general signature enumeration remain +unverified. `0xA0` does not mean "select any desired publisher". + ## Checks available without the VM From an x64 Visual Studio developer shell: diff --git a/docs/implementation-status.md b/docs/implementation-status.md index 7cc0d5c..8f8db0c 100644 --- a/docs/implementation-status.md +++ b/docs/implementation-status.md @@ -51,8 +51,10 @@ it should not be read as describing the corrected source unchanged. ## Requires the test VM or additional matching binaries -Live kernel testing is not available yet. Extracted VM artifacts, host mocks, -and compilation do not close these: +The first user-run kernel trace is available for Windows 11 22631 x64 with +TESTSIGNING enabled. It confirms the BthPS3 signer-selection comparison and +primary-signature CI path below. That one run, extracted artifacts, host mocks +and compilation do not close the remaining work: 1. Run the paired `CiValidateFileObject` flag `0`/`0x20` probe on 19041/19045 with TESTSIGNING off and a loadable signed test driver. Preserve complete @@ -77,8 +79,14 @@ and compilation do not close these: 5. Measure signing-time propagation, zero/sentinel values, timestamp expiry, revocation freshness/network policy and weak-crypto policy. Record OS policy, Secure Boot/HVCI/WDAC and exact files, not just a boolean result. -6. Establish multiple/nested signature-selection behavior with a signed corpus; - extend supported PE gaps/overlays only after differential evidence. +6. Extend the observed multiple/nested selection result beyond the first run. + On Windows 11 22631 x64 with TESTSIGNING enabled, `0x20` returns Microsoft; + `0xA0` and direct primary SHA-256 `CiCheckSignedFile` return Nefarius with the + same signing time and matching signer/timestamp policy observations. All + calls and policy statuses succeed, the file snapshots match, and no trace + events are lost. TESTSIGNING-off, general enumeration, full `0x80` semantics + and cross-build/policy behavior remain open. Extend supported PE gaps/overlays + only after differential evidence. 7. Resolve page-hash allocation destruction, normalized-entry/truncation meaning, terminal-entry handling and cross-version layouts before publishing a general page-hash API. `CiFreePolicyInfo` is not an established destructor for it. diff --git a/docs/mincrypt-contracts.md b/docs/mincrypt-contracts.md index e032656..438dea2 100644 --- a/docs/mincrypt-contracts.md +++ b/docs/mincrypt-contracts.md @@ -158,6 +158,42 @@ later conversion failure. It is not owned by either policy object. Evidence: `MincryptFreePolicyInfo`, `MincryptCopyPolicyInfo`, `I_MincryptAddChainInfo`, `CiVerifyHashInCatalog`, and `CiGetCertPublisherName`. +## Multiple signatures and selected results + +`CiValidateFileObject` returns one selected signature result and its timestamp +policy. Those two policy outputs do not enumerate two file signatures. The +output file digest and algorithm are not expected-certificate selectors. + +REA tracing of x64 CI 22621.2792 and the original 26100 sample found a +flag-dependent distinction: ordinary `0x20` can continue nested-signature +verification and retain a policy-preferred signing level. Adding `0x80` enters +an early-exit path after the first successful full candidate verification. +`0xA0` is therefore a concrete kernel experiment, not a proved stable +"select primary signature" flag: `0x80` also affects other policy/fallback paths. +An arbitrary signer index, expected-certificate predicate and continuation +interface are not exposed by these examined wrappers. + +For the supplied BthPS3 fixture, host SignTool verifies a primary Nefarius +SHA-256 signature and a nested Microsoft SHA-256 signature. On both examined CI +builds, `CiCheckSignedFile` with the matching SHA-256 digest follows the primary +signature directly. This gives a CI-based alternative worth testing without +implementing RSA/ECDSA, chain or timestamp verification. A subsequent user-run +probe on Windows 11 22631 x64 with TESTSIGNING enabled confirms that `0x20` +returns Microsoft while `0xA0` and direct SHA-256 `CiCheckSignedFile` return the +Nefarius leaf and its signing time. Every top-level and signer/timestamp policy +status succeeds; the two company-signer routes have matching policy observations. +The companion `signature-selection/runtime-22631-bthps3.json` retains exact +fixture/trace identities. This does not establish TESTSIGNING-off or general +cross-build behavior. A different layout may still require bounded signature +framing/enumeration. + +The companion CodeIntegrity-RE `SIGNATURE-SELECTION.md` retains fixture hashes, +56 procedure bodies, assembly, flag side effects and the kernel test plan. +The 23H2 batch is +`ev_049bd7d3aa492a9e3e4d8fcbf365ae00a6057751b26f93f3c1663c9436952ff7`; +its primary-selection helper is in +`ev_c867c73ca7eae7e4fbca2f44c6f6fb5904fb00459d0b84f2da8294b5b05a3866`. + ## Digest-based verification inputs `CiCheckSignedFile` consumes a caller-computed file digest. It does not reopen