[GH-ISSUE #7767] [Bug] inspect_pe_certificates skips the signer's unsigned attributes (RFC 3161 timestamp token, nested signature) without saying so #4638

Closed
opened 2026-10-31 00:51:41 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @Rinkia on GitHub (Oct 28, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7767

Before submitting

  • I searched the open and closed issues for a related report (pe certificates timestamp, unauthenticated attributes, countersignature, nested signature). Related: PR #7160 (raises the ASN.1 depth cap so dual-signed files stop failing). This report is about what the result contains once parsing succeeds.
  • I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

An Authenticode SignerInfo keeps its timestamp in unsignedAttrs: an RFC 3161 token (1.3.6.1.4.1.311.3.3.1), which is a complete SignedData with the TSA's own certificates and a TSTInfo.genTime. Dual-signed files also put their second signature there (1.3.6.1.4.1.311.2.4.1). inspect-pe-certificates reports only the outer SignedData's certificates and signers. Nothing from unsignedAttrs appears, and the result doesn't mention that they exist: coverage.status is complete and the limitations only say timestamps are not verified.

Public example: HidSharp.dll from the LibreHardwareMonitor v0.9.6 release (LibreHardwareMonitor.zip, sha256 086d9f1b…c001, matches the GitHub release digest; HidSharp.dll sha256 d86690ef…2f54).

asn1crypto 1.5.1 walk of the PKCS#7 inspect-pe-certificates
Outer certificates 3 (Sectigo Root R46, Sectigo CA R36, Illusory Studios LLC) the same 3
unsignedAttrs 1.3.6.1.4.1.311.3.3.1 (RFC 3161 token) not reported
Timestamp token certificates 3 (DigiCert Timestamp Responder 2025 1, DigiCert Trusted G4 TimeStamping CA1, DigiCert Trusted Root G4) not reported
TSTInfo.genTime 2025-10-14 14:27:26 UTC not reported
coverage complete, certificates: 3

I see the same on 8 Windows 11 system binaries (kernel32.dll, ntdll.dll, explorer.exe and others, PE32+ and PE32): each carries an RFC 3161 token with 3 entries in its own certificates set, and none of them is reported. For a dual-signed file the whole second signature is in there: an Office api-ms-win-core-file-l1-2-0.dll has a SHA-1 outer signature and a SHA-256 nested signature with its own signer and timestamp. Today that file fails on the depth cap that #7160 raises; with that cap raised, the SHA-256 signer would still be missing from the result.

Other files show it is not consistent: with a legacy PKCS#9 countersignature (1.2.840.113549.1.9.6) the TSA certificate is in the outer certificates set, so it does get reported.

Reproduction

unzip LibreHardwareMonitor.zip HidSharp.dll
rea inspect-pe-certificates HidSharp.dll --format json

Reference: extract the WIN_CERTIFICATE payload and read signer_infos[0].unsigned_attrs with asn1crypto.cms.ContentInfo.load(...) (or openssl cms -inform DER -cmsout -print).

Same on rea-agents@6.8.0 and on source at 60b55be7e (Linux x64 container, Node 24.22.1). main at 60bad9ed0 has no handling of unsigned attributes in PeCertificateParser.ts either.

Expected behavior

Either:

  • report each signer's unsigned attribute OIDs, and for the timestamp token and the nested signature decode them the same structural way as the outer SignedData (certificates, signer identifiers, digest algorithms, plus genTime for a timestamp), or
  • at least list the unsigned attribute OIDs and add a limitation that their contents are not decoded, so the caller knows the result leaves out the timestamp and any nested signature.

Impact and scope

Static inspection only. A caller asking who timestamped a file and when, or which signatures a dual-signed file carries, gets an answer that looks complete and leaves them out. Tested on PE32+ and PE32 images; I haven't checked other PKCS#7 consumers in REA (APK v1, kernel module signatures) for the same pattern.

Originally created by @Rinkia on GitHub (Oct 28, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7767 ### Before submitting - [x] I searched the open and closed issues for a related report (pe certificates timestamp, unauthenticated attributes, countersignature, nested signature). Related: PR #7160 (raises the ASN.1 depth cap so dual-signed files stop failing). This report is about what the result contains once parsing succeeds. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior An Authenticode `SignerInfo` keeps its timestamp in `unsignedAttrs`: an RFC 3161 token (`1.3.6.1.4.1.311.3.3.1`), which is a complete SignedData with the TSA's own certificates and a `TSTInfo.genTime`. Dual-signed files also put their second signature there (`1.3.6.1.4.1.311.2.4.1`). `inspect-pe-certificates` reports only the outer SignedData's `certificates` and signers. Nothing from `unsignedAttrs` appears, and the result doesn't mention that they exist: `coverage.status` is `complete` and the limitations only say timestamps are not *verified*. Public example: `HidSharp.dll` from the LibreHardwareMonitor v0.9.6 release (`LibreHardwareMonitor.zip`, sha256 `086d9f1b…c001`, matches the GitHub release digest; `HidSharp.dll` sha256 `d86690ef…2f54`). | | `asn1crypto` 1.5.1 walk of the PKCS#7 | `inspect-pe-certificates` | |---|---|---| | Outer certificates | 3 (Sectigo Root R46, Sectigo CA R36, Illusory Studios LLC) | the same 3 | | `unsignedAttrs` | `1.3.6.1.4.1.311.3.3.1` (RFC 3161 token) | not reported | | Timestamp token certificates | 3 (DigiCert Timestamp Responder 2025 1, DigiCert Trusted G4 TimeStamping CA1, DigiCert Trusted Root G4) | not reported | | `TSTInfo.genTime` | 2025-10-14 14:27:26 UTC | not reported | | `coverage` | | `complete`, `certificates: 3` | I see the same on 8 Windows 11 system binaries (`kernel32.dll`, `ntdll.dll`, `explorer.exe` and others, PE32+ and PE32): each carries an RFC 3161 token with 3 entries in its own `certificates` set, and none of them is reported. For a dual-signed file the whole second signature is in there: an Office `api-ms-win-core-file-l1-2-0.dll` has a SHA-1 outer signature and a SHA-256 nested signature with its own signer and timestamp. Today that file fails on the depth cap that #7160 raises; with that cap raised, the SHA-256 signer would still be missing from the result. Other files show it is not consistent: with a legacy PKCS#9 countersignature (`1.2.840.113549.1.9.6`) the TSA certificate is in the outer `certificates` set, so it does get reported. ### Reproduction ```sh unzip LibreHardwareMonitor.zip HidSharp.dll rea inspect-pe-certificates HidSharp.dll --format json ``` Reference: extract the `WIN_CERTIFICATE` payload and read `signer_infos[0].unsigned_attrs` with `asn1crypto.cms.ContentInfo.load(...)` (or `openssl cms -inform DER -cmsout -print`). Same on `rea-agents@6.8.0` and on source at `60b55be7e` (Linux x64 container, Node 24.22.1). `main` at `60bad9ed0` has no handling of unsigned attributes in `PeCertificateParser.ts` either. ### Expected behavior Either: - report each signer's unsigned attribute OIDs, and for the timestamp token and the nested signature decode them the same structural way as the outer SignedData (certificates, signer identifiers, digest algorithms, plus `genTime` for a timestamp), or - at least list the unsigned attribute OIDs and add a limitation that their contents are not decoded, so the caller knows the result leaves out the timestamp and any nested signature. ### Impact and scope Static inspection only. A caller asking who timestamped a file and when, or which signatures a dual-signed file carries, gets an answer that looks complete and leaves them out. Tested on PE32+ and PE32 images; I haven't checked other PKCS#7 consumers in REA (APK v1, kernel module signatures) for the same pattern.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#4638
No description provided.