Development record
The payload byte scan never matches a value written as UTF-16 text behind a byte-order mark, whatever its length: a PDF text string that opens with FE FF (the /Author, /Creator or /Title of a document with a non-ASCII field) or a little-endian string that opens with FF FE interleaves a zero byte with every letter, so the caller's real name, home path and email in it raise nothing and the file publishes. This is the UTF-16 half of iss-2609261659051539, split from its EXIF half, which needs an IFD reader; it reaches long values too, not only the short names that record names. Detector: the caller's name, home path or email written as byte-order-marked UTF-16 in a skip-listed file is a hard_fail finding in the payload scan, and a short name there is kept only where a person key stands within reach, as in plain bytes.
The payload byte scan never matches a value written as UTF-16 text behind a byte-order mark, whatever its length: a PDF text string that opens with FE FF (the /Author, /Creator or /Title of a document with a non-ASCII field) or a little-endian string that opens with FF FE interleaves a zero byte with every letter, so the caller's real name, home path and email in it raise nothing and the file publishes. This is the UTF-16 half of iss-2609261659051539, split from its EXIF half, which needs an IFD reader; it reaches long values too, not only the short names that record names. Detector: the caller's name, home path or email written as byte-order-marked UTF-16 in a skip-listed file is a hard_fail finding in the payload scan, and a short name there is kept only where a person key stands within reach, as in plain bytes.
Grounds
- pursued: a value written as byte-order-marked UTF-16 in a skip-listed file is found by the payload scan at linear cost without new false positives; a launch dry-run that reports a new finding on this tree's own assets, or a marked UTF-16 name the scan still passes, would show it wrong
Frontmatter
| id | iss-2609261827066511 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2609261827066511-the-payload-byte-scan-never-matches-a.md
open on GitHub ↗ · commit history ↗
mentions2
- iss-2609261659051539A short single-token real name in a JPEG's or TIFF's EXIF Artist tag (IFD0 tag 0x013B) is still dropped by the payload byte scan as chance noise. The byte scan keeps a short name only where a person metadata key stands as text within reach before it (metadataPersonKeys in internal/adapter/scanner/scanner.go: a PDF /Author, XMP dc:creator, a PNG text Author, an OOXML cp:lastModifiedBy), and EXIF stores the Artist tag as a binary IFD entry whose ASCII value sits at an offset with no key text beside it; a UTF-16 PDF string (/Author with a FEFF byte-order mark) is out of reach the same way. Closing it needs the IFD read structurally, the way container.go walks PNG chunks: find the Exif header, read the TIFF byte order, walk IFD0 and scan the Artist (and XPAuthor) value with the text rules. Residue of iss-2609090934372160. Detector: a short banned name in a camera-written EXIF Artist tag, with no XMP packet beside it, is a real_name finding in the payload scan.
- iss-2609261831352258A PDF text string written in hex (a FEFF-led run of hex digits between angle brackets) or with octal escapes (a backslash-376, backslash-377 opening inside parentheses), the forms several common PDF writers use for a non-ASCII document field, is read by neither the payload byte scan nor its UTF-16 view: neither spelling puts the UTF-16 bytes in the file, so the caller's name in such an /Author or /Creator raises nothing at any length. Reading them is a decode of the string syntax ahead of the UTF-16 view (hex pairs, and the PDF literal-string escapes), in the shape of the percent and JSON-escape views, not a format parser. Detector: the caller's name in a UTF-16 /Author written in hex or with octal escapes is a real_name finding in the payload scan.