[GH-ISSUE #6709] [Bug] PE certificate inspection rejects valid TeletexString names as malformed PKCS#7 #4078

Closed
opened 2026-10-31 00:46:40 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @coygeek on GitHub (Oct 23, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6709

Before submitting

  • I searched the open and closed issues for a related report.
  • I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

inspect-pe-certificates <file> --json returns invalid_request / invalid_format and discards the certificate-table inventory when an issuer or subject uses an ASCII-valued ASN.1 TeletexString (tag 0x14). The same bytes encoded as UTF8String succeed. This was observed through the compiled CLI and the production parser, using inert repository fixtures.

Reproduction

From the source revision below, after npm ci and npm run build:cached, run this as a TypeScript script from the repository root with node --import tsx:

import { writeFileSync } from "node:fs";
import { pkcs7SignedDataFixture, peCertificateFixture } from "./src/native/pe/PeCertificates.fixture.ts";
import { readAsn1 } from "./src/native/pe/PeCertificateAsn1.ts";
const payload = pkcs7SignedDataFixture("Plain Name", "Plain Org");
writeFileSync("/tmp/name-utf8.exe", peCertificateFixture(false, payload));
const root = readAsn1(payload);
function visit(node: ReturnType<typeof readAsn1>) {
  if (node.tag === 0x0c) payload[node.start] = 0x14;
  for (const child of node.children) visit(child);
}
visit(root); // Only change the six ASCII-valued name tags; lengths/values stay identical.
writeFileSync("/tmp/name-teletex.exe", peCertificateFixture(false, payload));

Then:

node scripts/rea.mjs inspect-pe-certificates /tmp/name-utf8.exe --json
node scripts/rea.mjs inspect-pe-certificates /tmp/name-teletex.exe --json

The UTF8String control returns certificate Evidence. The TeletexString variant returns the error below. Each CLI variant was run once; both variants were also exercised once through parsePeCertificates.

Expected behavior

Preserve the structural certificate facts and these unambiguous ASCII name values, or accurately identify an unsupported name encoding while retaining usable facts. Do not diagnose the entire PKCS#7 as malformed solely because a valid DirectoryString choice is unimplemented. RFC 5280 section 4.1.2.4 includes TeletexString among the DirectoryString choices and discusses continued support for existing certificates that use it. This concerns metadata decoding, not cryptographic verification.

Impact and scope

A certificate name encoding prevents all requested table, certificate, and signer facts from being returned. Verified with a PE32 type-2 WIN_CERTIFICATE fixture whose only change is the name tag. PE32+, real signed executables, historical certificate prevalence, and Windows trust behavior were not tested. The input is not changed by inspection.

REA version

Source package 6.7.0, revision 5d6b8a0ab693c03ab85cf0807d40bedf021e76d8; latest published npm version checked: 6.7.0.

Runtime and platform

Node.js 26.12.1; Linux x86_64; npm 11.16.0. No Hopper, Ghidra, or target execution is involved.

Target and artifact context

Inert PE32 fixture containing structural PKCS#7 SignedData. The fixture is not a cryptographically valid Authenticode signature; REA explicitly does not verify signatures in this workflow. ASCII name contents are valid under both selected string encodings.

Interface

CLI

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

Observed CLI result, reduced to the relevant fields:

{"code":"invalid_request","category":"invalid_input","details":{"operation":"inspect_pe_certificates","issues":[{"path":["path"],"reason":"invalid_format","message":"PKCS#7 signedData is malformed: Unsupported certificate name encoding (DER tag 0x14)."}]}}

The UTF8String control returned subject.text: "commonName=Plain Name, organizationName=Plain Org" and a complete certificate inventory. The direct parser check returned that same subject for UTF8String and ArtifactReaderFailure with reason format for TeletexString.

Source: decodeDirectoryString supports UTF8String, PrintableString, UniversalString, and BMPString but sends tag 0x14 to its failure branch. parsePeCertificates converts that exception into malformed input before retaining the entry.

Typed outcome or recovery expected

Successful structural Evidence for supported ASCII content, or a precise unsupported-encoding limitation that preserves readable table metadata. Schema rediscovery and unchanged retries cannot resolve this file-content-dependent error.

Analysis or suspected cause

Source-derived: the name decoder omits one DirectoryString alternative, and its caller conflates an unsupported encoding with malformed PKCS#7. No signature-validity or trust-policy defect is alleged.

Additional context

Related closed report #6574 concerns indefinite BER envelope lengths, which this fixture does not use. Open #6439 concerns APK v1 signer matching across name encodings, a different workflow and failure.

Triage assessment

  • Impact level: P2
  • Assessment status: supported
  • Impact basis: The observed valid name encoding causes the entire requested static inventory to fail; the equivalent UTF8String control succeeds.
  • Workaround status: unverified
  • Workaround basis: No same-artifact REA workaround was demonstrated. Re-encoding a copy changes the selected bytes and digest.
Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6709 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior `inspect-pe-certificates <file> --json` returns `invalid_request` / `invalid_format` and discards the certificate-table inventory when an issuer or subject uses an ASCII-valued ASN.1 TeletexString (tag `0x14`). The same bytes encoded as UTF8String succeed. This was observed through the compiled CLI and the production parser, using inert repository fixtures. ### Reproduction From the source revision below, after `npm ci` and `npm run build:cached`, run this as a TypeScript script from the repository root with `node --import tsx`: ```ts import { writeFileSync } from "node:fs"; import { pkcs7SignedDataFixture, peCertificateFixture } from "./src/native/pe/PeCertificates.fixture.ts"; import { readAsn1 } from "./src/native/pe/PeCertificateAsn1.ts"; const payload = pkcs7SignedDataFixture("Plain Name", "Plain Org"); writeFileSync("/tmp/name-utf8.exe", peCertificateFixture(false, payload)); const root = readAsn1(payload); function visit(node: ReturnType<typeof readAsn1>) { if (node.tag === 0x0c) payload[node.start] = 0x14; for (const child of node.children) visit(child); } visit(root); // Only change the six ASCII-valued name tags; lengths/values stay identical. writeFileSync("/tmp/name-teletex.exe", peCertificateFixture(false, payload)); ``` Then: ```sh node scripts/rea.mjs inspect-pe-certificates /tmp/name-utf8.exe --json node scripts/rea.mjs inspect-pe-certificates /tmp/name-teletex.exe --json ``` The UTF8String control returns certificate Evidence. The TeletexString variant returns the error below. Each CLI variant was run once; both variants were also exercised once through `parsePeCertificates`. ### Expected behavior Preserve the structural certificate facts and these unambiguous ASCII name values, or accurately identify an unsupported name encoding while retaining usable facts. Do not diagnose the entire PKCS#7 as malformed solely because a valid DirectoryString choice is unimplemented. [RFC 5280 section 4.1.2.4](https://www.rfc-editor.org/rfc/rfc5280.html#section-4.1.2.4) includes TeletexString among the DirectoryString choices and discusses continued support for existing certificates that use it. This concerns metadata decoding, not cryptographic verification. ### Impact and scope A certificate name encoding prevents all requested table, certificate, and signer facts from being returned. Verified with a PE32 type-2 WIN_CERTIFICATE fixture whose only change is the name tag. PE32+, real signed executables, historical certificate prevalence, and Windows trust behavior were not tested. The input is not changed by inspection. ### REA version Source package 6.7.0, revision `5d6b8a0ab693c03ab85cf0807d40bedf021e76d8`; latest published npm version checked: 6.7.0. ### Runtime and platform Node.js 26.12.1; Linux x86_64; npm 11.16.0. No Hopper, Ghidra, or target execution is involved. ### Target and artifact context Inert PE32 fixture containing structural PKCS#7 SignedData. The fixture is not a cryptographically valid Authenticode signature; REA explicitly does not verify signatures in this workflow. ASCII name contents are valid under both selected string encodings. ### Interface CLI ### Earliest failure stage Native analysis or reconstruction ### Relevant output or evidence Observed CLI result, reduced to the relevant fields: ```json {"code":"invalid_request","category":"invalid_input","details":{"operation":"inspect_pe_certificates","issues":[{"path":["path"],"reason":"invalid_format","message":"PKCS#7 signedData is malformed: Unsupported certificate name encoding (DER tag 0x14)."}]}} ``` The UTF8String control returned `subject.text: "commonName=Plain Name, organizationName=Plain Org"` and a complete certificate inventory. The direct parser check returned that same subject for UTF8String and `ArtifactReaderFailure` with reason `format` for TeletexString. Source: [`decodeDirectoryString`](https://github.com/morluto/rea/blob/5d6b8a0ab693c03ab85cf0807d40bedf021e76d8/src/native/pe/PeCertificateAsn1.ts#L166) supports UTF8String, PrintableString, UniversalString, and BMPString but sends tag `0x14` to its failure branch. [`parsePeCertificates`](https://github.com/morluto/rea/blob/5d6b8a0ab693c03ab85cf0807d40bedf021e76d8/src/native/pe/PeCertificateParser.ts#L48) converts that exception into malformed input before retaining the entry. ### Typed outcome or recovery expected Successful structural Evidence for supported ASCII content, or a precise unsupported-encoding limitation that preserves readable table metadata. Schema rediscovery and unchanged retries cannot resolve this file-content-dependent error. ### Analysis or suspected cause Source-derived: the name decoder omits one DirectoryString alternative, and its caller conflates an unsupported encoding with malformed PKCS#7. No signature-validity or trust-policy defect is alleged. ### Additional context Related closed report #6574 concerns indefinite BER envelope lengths, which this fixture does not use. Open #6439 concerns APK v1 signer matching across name encodings, a different workflow and failure. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: The observed valid name encoding causes the entire requested static inventory to fail; the equivalent UTF8String control succeeds. - Workaround status: unverified - Workaround basis: No same-artifact REA workaround was demonstrated. Re-encoding a copy changes the selected bytes and digest.
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#4078
No description provided.