isaacmarovitz / pe-parser

PE Parsing, but blazing fast

PE Parser

A blazing fast 🔥 PE Parser written in Rust

Motivation

The main goals of pe-parser is to write something suitable for a PE Loader.

Is editing supported?

Currently no, but it wouldn't be too difficult to add from the current backbone.

How does it handle unsual or malformed PEs?

As long as the PE conforms to the standard outlined in Microsoft's documentation, it should read fine. Malformed PEs would likely run into issues of either returning an error or misreading data.

What is parsed right now?

• COFF Header
• Optional Header
• Data Directories
• Section Tables/Headers

What is not parsed yet?

• COFF Relocations
• COFF Line Numbers
• COFF Symbol Table
• COFF String Table
• Certificate Table
• Delay-Load Import Table
• .debug Section
• .drectve Section
• .edata Section
• .idata Section
• .pdata Section
• .reloc Section
• .tls Section
• Load Config Structure
• .rsrc Section
• .cormeta Section
• .sxdata Section

pe-parser's Issues

vma from pe-parser does not match vma from objdump

I'm currently trying to use pe-parser to get section headers from the systemd efi stub(all uefi executables are pe exectuables) however when I try and get the vma it doesn't match what comes from objdump which is what i require.

objdump -h (only output headers) gives the following output

/usr/lib/systemd/boot/efi/linuxx64.efi.stub:     file format pei-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         0000fcdf  000000014df91000  000000014df91000  00000400  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       000029d4  000000014dfa1000  000000014dfa1000  00010200  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         000002d8  000000014dfa4000  000000014dfa4000  00012c00  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  3 .sdmagic      00000027  000000014dfa5000  000000014dfa5000  00013000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .sbat         000000cb  000000014dfa6000  000000014dfa6000  00013200  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .reloc        00000080  000000014dfa7000  000000014dfa7000  00013400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

we want the last part reloc, which makes size and vma 128, 5603225600 respectively in rust the code i came up with is

if !systmd_stub.exists() {
        return Err(anyhow!(
            "the efi stub {} does not exist",
            systmd_stub.display()
        ));
    }

    let bin = read(systmd_stub)?;
    let parse = parse_portable_executable(&bin)?;
    let sections = parse.section_table;
    let reloc = match sections.last() {
        Some(header) => header,
        None => {
            return Err(anyhow!("unable to parse systemd efi stub"));
        }
    };

   println!("{}\n{}",reloc.virtual_address, reloc.virtual_size);

the output given is 94208 and 128 which means the VMA is wrong. I'm a bit lost why the vma is so different.

Usage with nostd

I'd like to use this library in a nostd program.

My code will run in a UEFI environment, so it has to be nostd and is a PE/COFF binary file. I mostly want to use pe_parser::pe::parse_portable_executable to find the offset of a few sections

I think a sane approach would be to add an std feature flag (which is enabled by default to avoid breaking existing usages).

The main breaking change that I can see is that parse_portable_executable returns std::io::Error. The only way around this is to use a custom error type. This shouldn't be too hard to pull off, since there's not that many scenarios where std::io::Error is used (and many usages are just ErrorKind::Other, so a cusotm error type might actually improve the API a bit).

Obviously the main function would not work on nostd; only the library aspect of this crate.

Load DLL/EXE from memory

Hello, can you add the ability to load DLL/EXE from memory, and also provide access to the public functions of the DLL/EXE?