Closed landaire closed 3 years ago
Can you describe the build process which created this PDB? My best information is summarized here and it's… murky.
I understand the problematic PDB is private. Would you be able to use a similar process on a separate codebase to produce a new problematic PDB which could be published?
The PDB was created by Microsoft's internal build system for a component of Windows that I don't personally build myself.
What I did notice is that the "broken" symbols all fit the following criteria:
__imp_
-prefixedDataSymbol
s__declspec(selectany)
or __declspec(dllimport)
.For this project I don't think I care about resolving any of these addresses so an easy mitigation is to just ignore any symbols whose PdbInternalSectionOffset::section
is 0. I also just now read from the PdbInternalSectionOffset
docs that a section of 0 is invalid or missing, which makes sense.
Oh, that's a good point. Does this work?
diff --git a/src/omap.rs b/src/omap.rs
index b7f6026..cfd62ac 100644
--- a/src/omap.rs
+++ b/src/omap.rs
@@ -448,8 +448,9 @@ fn get_section_offset(sections: &[ImageSectionHeader], address: u32) -> Option<(
}
fn get_virtual_address(sections: &[ImageSectionHeader], section: u16, offset: u32) -> Option<u32> {
- let section = sections.get(section as usize - 1)?;
- Some(section.virtual_address + offset)
+ (section as usize).checked_sub(1)
+ .and_then(|i| sections.get(i))
+ .map(|section| section.virtual_address + offset)
}
impl Rva {
I haven't tested but that looks great to me.
When parsing private symbols in my application I get the following panic:
get_virtual_address
is implemented as follows:I believe that this would indicate
section
has a value of0
in this context but I have not dumped it yet. Unfortunately I cannot provide a reproducible testcase considering the PDB is private. I can however provide any additional metadata required to help debug the issue in full.