Skip to content

pe: wrap ResourceData parse in or_permissive_and_default (follow-up to #508)#526

Open
CalebFenton wants to merge 2 commits intom4b:masterfrom
CalebFenton:rsrc-permissive-complete
Open

pe: wrap ResourceData parse in or_permissive_and_default (follow-up to #508)#526
CalebFenton wants to merge 2 commits intom4b:masterfrom
CalebFenton:rsrc-permissive-complete

Conversation

@CalebFenton
Copy link
Copy Markdown

@CalebFenton CalebFenton commented Apr 8, 2026

Follow-up to #508. That PR added or_permissive_and_default inside ResourceData::parse_with_opts but the call site in PE::parse() still uses bare ?:

// mod.rs line 367 — bare `?` means permissive mode doesn't help
let data = resource::ResourceData::parse_with_opts(
    bytes, resource_table, &sections, file_alignment, opts,
)?;

When VersionInfo::parse or ManifestData::parse fails inside that call (e.g. resource data RVAs that can't be mapped to file offsets), the error propagates through the bare ? and kills the entire PE parse — even in ParseMode::Permissive.

This wraps it in .map(Some).or_permissive_and_default(...), same as the debug_data, tls_data, load_config_data, and clr_data call sites nearby.

We hit this on packed PE malware (FSG, TELock) where the packer mangles the resource section but the rest of the PE is fine.

Follow-up to m4b#508 which added permissive support inside
ResourceData::parse_with_opts but missed the top-level call
site in PE::parse(). Without this, ParseMode::Permissive still
fatally rejects PEs with malformed resource sections (e.g.,
packed malware where the packer mangled RT_VERSION RVAs).

Matches the pattern used by every other data directory parse:
debug_data, tls_data, load_config_data, clr_data, etc.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant