Iterator stops in the middle about lde

[CasualX]

Hello and thanks for taking interest!

---

A windows binary (PE file) contains more than just code instructions, you cannot simply start at some point and iterate until the end. This very simple length disassembler will stop when it encounters an instruction it does not understand.

You may try to extract the 'code' section of the PE file, using eg. pelite whose job it is to parse the PE file structures (disclaimer: I am the author of pelite). You can use that library to extract the code section (assuming x64):

use pelite::pe64::{Pe, PeFile};

let map = pelite::FileMap::open("demo/Demo64.dll").unwrap();
let file = PeFile::from_bytes(&map).unwrap();
let code_section = file.section_headers().iter().find(|sect| &sect.Name == b".text\0\0\0").unwrap();
let code_bytes = file.get_section_bytes(code_section).unwrap();
for (opcode, va) in lde::X64.iter(code_bytes, code_section.VirtualAddress as u64) {
	println!("{:#x}: {}", va, opcode);
}

However even this isn't guaranteed to only contain executable code! jump tables for switch statements will put their tables in the code section as well as you can easily write source code in C++ or Rust which puts arbitrary data in the code section.

How to work around this issue depends on what your goal is. Here is an example where I'm looking for a particular bit of code which I know ahead of time what its structure is going to be, then I run through it with lde to find specific instructions which reveal the underlying data structures of the source code which generated that code.

---

I haven't found much time to work on this library in particular, I'd love to put more work into it (eg. supporting the new v -style sse instructions) but it should keep working for 32-bit and older x64 based instructions.

[cecton]

If I understand correctly, using pelite won't work either because there is no guarantee there will be only executable code.

What you suggest is, for example, to look for a particular piece of code and then run lde from there, am I correct?

I think that's what I have done so I will keep my approach to the problem as it is now then. I guess I was looking for a wrong abstraction. (The code is here if you want to check.)