[
https://issues.apache.org/jira/browse/TIKA-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18122233#comment-18122233
]
ASF GitHub Bot commented on TIKA-4936:
--------------------------------------
dschmidt commented on PR #3263:
URL: https://github.com/apache/tika/pull/3263#issuecomment-5969627181
Thanks, all of it was right. Pushed as cb76702d51 and 3587532965, with main
merged in (no force push):
- Amplification: images are deduplicated per group by their data (offset,
size), and all rebuilt icons together may take at most 4x the bytes of the
resource section; beyond that extraction stops with a warning. The "closes a
256x amplification" claim was wrong. I have not run your PoC;
`testOutputBudgetAcrossGroups` and `testSharedImageDataInGroupIsRejected` cover
the two paths, and I am happy to add yours if you send it. Is 4x the multiple
you had in mind?
- The section buffer grows with the bytes that arrive. File-backed input is
no longer buffered at all, it is read at the offsets the tree points to.
- `@deprecated since 4.2.0`, and a CHANGES entry that names default-on and
`extractIcons`.
- Fixture sources and build commands are in the test's class comment. A
rebuild on Ubuntu 24.04 differs from the committed files only in the link
timestamp and the checksum.
- Config shape: left as is, as you suggested deferring it.
A second review pass found more, fixed in the same commits: `e_lfanew ==
0x3f` threw an IllegalArgumentException since the switch to `skipFully`, a
failing source was recorded as an embedded exception instead of failing the
parse, the entry budget could run out among the icons before any group was
read, and resource names went unchecked into the file name and the relationship
id.
> Extract icons from PE executables (EXE/DLL) as embedded documents
> -----------------------------------------------------------------
>
> Key: TIKA-4936
> URL: https://issues.apache.org/jira/browse/TIKA-4936
> Project: Tika
> Issue Type: New Feature
> Environment:
>
>
>
> Reporter: Dominik Schmidt
> Priority: Major
>
> h3. Background
> {{ExecutableParser}} currently only reads the COFF file header of PE files
> (EXE/DLL) and emits basic metadata (machine type, architecture bits,
> endianness, created date). The resource section ({{.rsrc}}) is not parsed, so
> resources such as the application icon are not accessible via Tika.
> h3. Proposal
> Parse the PE resource directory and emit each icon group as an embedded
> document:
> * Parse optional header, data directories and section table to locate the
> resource directory (RVA → file offset).
> * Walk the resource tree (type → name/ID → language).
> * For each {{RT_GROUP_ICON}} (type 14), reconstruct a standalone {{.ico}}
> file from the {{GRPICONDIR}} and the referenced {{RT_ICON}} (type 3) entries:
> write an {{ICONDIR}} header and replace the 2-byte resource IDs ({{nID}})
> with 4-byte image offsets.
> * Pass each reconstructed file to the {{EmbeddedDocumentExtractor}} with:
> ** {{Content-Type}}: {{image/vnd.microsoft.icon}}
> ** {{resourceName}}: e.g. {{icon_<id-or-name>.ico}}
> ** {{embeddedResourceType}}: {{THUMBNAIL}} for the first icon group (the icon
> shown by Windows Explorer), {{ATTACHMENT}} for all others
> ** the resource language ID
> Single {{RT_ICON}} entries are intentionally not emitted on their own:
> BMP-based entries are not valid standalone images (no {{BITMAPFILEHEADER}},
> double height for the AND mask), and emitting them would duplicate the group
> data.
> h3. Robustness
> The parser must handle malformed or malicious binaries gracefully:
> * bound the resource tree depth (normally 3 levels) and the number of entries
> * validate all offsets and sizes against the file size
> * guard against cycles in the resource directory
> * failures while extracting resources must not break the existing metadata
> extraction
> h3. Out of scope (possible follow-ups)
> * {{RT_GROUP_CURSOR}}/{{RT_CURSOR}} → {{.cur}}
> * {{RT_MANIFEST}} as an embedded XML document
> * {{VS_VERSIONINFO}} (product name, file version, company) as metadata
> h3. Acceptance criteria
> * Icons of 32- and 64-bit EXE and DLL test files are extracted as valid
> {{.ico}} files that are detected as {{image/vnd.microsoft.icon}}.
> * Icon groups containing both PNG- and BMP-encoded entries are supported.
> * Files without a resource section, or without icons, are parsed as before,
> with no embedded documents.
> * Truncated or corrupted resource sections do not throw and still yield the
> existing metadata.
> * Unit tests use small, license-compatible test files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
