casualx / pelite Goto Github PK

How can I use this to get the offset of APEX,
I'm sorry I don't understand rust, there are more than 70 errors when trying to execute ^_^

Please check this file, it is a file complied by .NET Core targeting linux x64. It is a PE file and you can check its file version in Windows explorer. But pelite cannot retrieve its version.

From the demo/Demo.dll example have the following two sections:

Notice how [.text].VirtualAddress + [.text]SizeOfRawData = [.rdata].VirtualAddress, ie. they touch.

This is problematic for PeFile::range_to_slice helper which checks if a range is inside a section as such: if rva >= it.VirtualAddress && rva <= VirtualEnd.

If you request a slice from the beginning of rdata, it will erronously be caught in the range check of .text causing a zero length slice to be returned, the end of the text section. Instead it should return the slice containing the entire rdata.

This is fallout from a fix a long time ago that allowed slicing with zero length one byte past the range of a section... How to fix this without simply reverting to past behavior? What was the problem with past behavior?

Please help me get the version of the file in string format (for comparison with another version). I've been trying to do everything normally for several days, but it doesn't work out. I'm still studying Rust, so I don't know much, please explain.

use pelite::{
    resources::{version_info::VersionInfo, FindError, Resources},
    PeFile,
};

pub fn is_new_version(new_version: &str, application_path: &str) -> i32 {
    let file_map =
        pelite::FileMap::open(application_path).expect("Cannot open the file specified!");
    let image = pelite::PeFile::from_bytes(file_map.as_ref()).expect("File is not a PE image!");
    let current_version = get_file_version(image).replace(", ", "");
    println!("{} - {}", current_version, new_version);
    if current_version.contains(&new_version) {
        1
    } else {
        if current_version == "" {
            -1
        } else {
            0
        }
    }
}

fn get_file_version(bin: PeFile<'_>) -> String {
    let resources = bin.resources().expect("Resources not found!");
    let lang: Option<u16> = None;
    let version_info = match lang {
        Some(lang) => resources
            .find_resource_ex(&[pelite::resources::Name::VERSION, 1.into(), lang.into()])
            .and_then(|bytes| {
                Ok(pelite::resources::version_info::VersionInfo::try_from(
                    bytes,
                )?)
            }),
        None => resources.version_info(),
    }
    .expect("Version info not found!");
    let lang = version_info.translation()[0];
    // TODO Fix this error (?)
    let file_version = format!("{:?}", version_info.value(lang, "FileVersion"));
    file_version
}

Not really sure what's going on here, since it's not a file in github, and my understanding of cargo means the tests shouldn't be being run:

My current goal is to fix the imports, replacing the pointer to the imported function in the module i want to map from the process iat.
The problem is pelite only has a way to get the imports and not write them since i want to later on write them into the pefile, convert them back to an byte array and then overwrite the pe header.

Is there a manual way to do this?

I want to get back &[u8] or Vec containing the .exe binary code from pe and then save that to a file..

let file = FileMap::open("./name.exe").unwrap();
let mut pe = PeFile::from_bytes(file.as_ref()).unwrap();

I tried:

pe.image()

But it produces a value 900 +- bytes larger than the original.

Help me, please.
Thank you in advance.

Hey could you make a readme in the apex example and how to use it, it would be nice since i have very less knowledge on Rust :)

Kind Regards Dopepigeon

Just an idea I had, writing it down for the record:

To support mutation change the underlying data storage from &'a [u8] to *mut [u8] (and associated phantom data) then any copy of the Pe<'a> doesn't lock the entire image. Then provide accessor methods which return mut pointers (instead of shared borrows).

There will still be potential for UB, but it gets pushed to the user code and the library remains safe.

Hello,
first of all, thank you for providing this library. It's been of great use for me lately.
Unfortunately, i've seem to run into a issue, where when iterating the exported functions of kernel32.dll (32bit), some exported functions seem to be missing.

These seem to be:
HeapAlloc
HeapReAlloc
InitializeSListHead
SleepConditionVariableSRW
WakeAllConditionVariable
AcquireSRWLockExclusive
ReleaseSRWLockExclusive

Here is how I iterate the exports:

                            pe.exports()?
                                .by()?
                                .iter_names()
                                .filter_map(|result| match result {
                                    (Ok(name), Ok(export)) => export
                                        .symbol()
                                        .map(|symbol| (name.to_string(), base + symbol as u64)),
                                    _ => None,
                                })
                                .collect::<HashMap<_, _>>()

Am I doing something wrong?

Hello,

can anybody say me how i can extract files from an exe with this crate? I want to extract the files that are in /.rsrc included. I need only to copy the files like an unpacker or receive an ImageBuffer.

thx

First of all: Thank you for your crate. I failed miserably, to read the export table of a dll. I was just not smart enough.

In using this crate, I stumbled across the traits, mentioned in the title. I have noticed, that the functions in the traits are almost identical.

So my question: Could this library just detect the bitness, of a dll/binary, and use the required functions as needed?
For me parsing the DOS and NT -Headers was no problem, using the bindings of winapi. That worked on x64 and x86 dlls.

This is my current implementation, of reading all exports, of a dll. The branches cannot be merged, because the types differ. Due to what I am trying to accomplish, with this, I need both branches. The code below could be reduced, to 50%, of it's size, if there was a trait/type, which would hide the different types, from the user.

if dll_is_x64 {
			let dll = result!(pelite::pe64::PeFile::from_bytes(k32.as_slice()));
			let exports = result!(dll.exports());
			let name = result!(result!(exports.dll_name()).to_str());
			debug!("dll name is {}",name);
			let fns = result!(exports.functions());
			let names = result!(exports.names());
			for name in names{
				if let Ok(name_c_str) = dll.derva_c_str(*name){
					if let Ok(name_str) = name_c_str.to_str(){
						info!("got {} as function",name_str)
					}else{
						debug!("get {} as function", String::from_utf8_lossy(name_c_str.to_vec().as_slice()))
					}
				}else{
					error!("Couldn't read specified rva");
				}
			}
		}else{
			let dll = result!(pelite::pe32::PeFile::from_bytes(k32.as_slice()));
			let exports = result!(dll.exports());
			let name = result!(result!(exports.dll_name()).to_str());
			debug!("dll name is {}",name);
			let fns=result!(exports.functions());
			let names=result!(exports.names());
			for name in names{
				if let Ok(name_c_str) = dll.derva_c_str(*name){
					if let Ok(name_str) = name_c_str.to_str(){
						info!("got {} as function",name_str)
					}else{
						debug!("get {} as function", String::from_utf8_lossy(name_c_str.to_vec().as_slice()))
					}
				}else{
					error!("Couldn't read specified rva");
				}
			}
		}

just pulled all updates on master. sample does not work anymore.

F:\git\pelite>cargo run --example readme --verbose
       Fresh rand_core v0.4.2
       Fresh derive_pod v0.1.0
   Compiling pelite-macros v0.1.0 (F:\git\pelite\src\proc-macros)
       Fresh lde v0.3.0
       Fresh format_xml v0.1.4
     Running `rustc --edition=2018 --crate-name pelite_macros src\proc-macros\lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type proc-macro --emit=dep-info,link -C prefer-dynamic -C debuginfo=2 -C metadata=151799de88e00789 -C extra-filename=-151799de88e00789 --out-dir F:\git\pelite\target\debug\deps -C incremental=F:\git\pelite\target\debug\incremental -L dependency=F:\git\pelite\target\debug\deps`
       Fresh winapi v0.3.8
       Fresh rand_core v0.3.1
       Fresh dataview v0.1.1
       Fresh rand v0.5.6
warning: Hard linking files in the incremental compilation cache failed. Copying files instead. Consider moving the cache directory to a file system which supports hard linking in session dir `\\?\F:\git\pelite\target\debug\incremental\pelite_macros-2q51qzau2rdk2\s-foffd03rb1-1m2wgq5-working`

error[E0432]: unresolved import `proc_macro`
 --> src\proc-macros\lib.rs:1:5
  |
1 | use proc_macro::*;
  |     ^^^^^^^^^^ use of undeclared type or module `proc_macro`

error[E0412]: cannot find type `TokenStream` in this scope
  --> src\proc-macros\lib.rs:15:33
   |
15 | pub fn pattern_attribute(_args: TokenStream, input: TokenStream) -> TokenStream {
   |                                 ^^^^^^^^^^^ not found in this scope

error[E0412]: cannot find type `TokenStream` in this scope
  --> src\proc-macros\lib.rs:15:53
   |
15 | pub fn pattern_attribute(_args: TokenStream, input: TokenStream) -> TokenStream {
   |                                                     ^^^^^^^^^^^ not found in this scope

error[E0412]: cannot find type `TokenStream` in this scope
  --> src\proc-macros\lib.rs:15:69
   |
15 | pub fn pattern_attribute(_args: TokenStream, input: TokenStream) -> TokenStream {
   |                                                                     ^^^^^^^^^^^ not found in this scope

error: aborting due to 4 previous errors

Some errors have detailed explanations: E0412, E0432.
For more information about an error, try `rustc --explain E0412`.
error: could not compile `pelite-macros`.

Caused by:
  process didn't exit successfully: `rustc --edition=2018 --crate-name pelite_macros src\proc-macros\lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type proc-macro --emit=dep-info,link -C prefer-dynamic -C debuginfo=2 -C metadata=151799de88e00789 -C extra-filename=-151799de88e00789 --out-dir F:\git\pelite\target\debug\deps -C incremental=F:\git\pelite\target\debug\incremental -L dependency=F:\git\pelite\target\debug\deps` (exit code: 1)

It appears that IMAGE_DYNAMIC_RELOCATION64 size constraint is violated on 32-bit Linux environments. See the error in our CI: https://github.com/memflow/memflow-qemu/runs/7271610781. Could this be an alignment issue? Or should size of an array be checked instead, like done in memflow?

I'm not certain this is a problem with the library, so apologies if this is a waste of your time. This library is really well put-together, but I'm having one significant problem.

I'm reading an array out of a PE with an RVA I got from the pdb crate. I've marked the structure as [repr(C)] and POD. The code is something like this:

    let file = FileMap::open(filename)?;
    let pe_file = PeFile::from_bytes(&file)?;

    // ...

    for sym in &pdb.symbols {
        let fields = pe_file.derva_slice::<myStruct_t>(sym.rva, sym.count)?;
        println!("{:?}", fields);
    }

The element is something like 40 bytes and the array has 2600 elements. After 500-or-so elements I start getting all zeroes. Prior to that the data is correct.

I'm wondering if there's something big that I'm missing here. I get identical results if I do any of the following:

• Switch to ImageMap and PeView instead of PeFile.
• Read the file directly using std::fs::read.
• Read each element manually by incrementing the rva by the structure size.
• Switch from an optimized executable to a debug executable.

I've debugged into derva_slice and everything looks ok... the array fully fits into the section's memory. I just get zeroes for most of the data.

Edit: Now I've also looked at it in CFF explorer and can confirm that the zeroes are there, which further exonerates the library, but it's still unclear where the data is coming from when the PE is actually loaded.

Any ideas what's going wrong?

I'd like to contribute to this project, however it seems like the style is mostly ad-hoc and rustfmt is not being used for the most part?

I propose adding a .rustfmt.toml to the root of the project to ensure that contribution style is consistent, then running cargo fmt on the repo to format the code.

I've tried to come up with a .rustfmt.toml which is minimally imactful while still providing some benefits:

edition = "2021"
hard_tabs = true
match_block_trailing_comma = true
control_brace_style = "ClosingNextLine"

Unfortunately this still leads to a large number of changes due to many small adjustments.

More settings can be found here

One other potential issue is the lack of a setting for preserving aligned spaces such as

const SOME_LONG_NAME: i32       = 5;
const SHORT: i32                = 6;

This patten is found in a few places, especially src/image.rs
In this case if you want to preserve the nice alignment there are a few options:

• Add #[rustfmt::ignore] annotations to each line that you want to preserve formatting
• Move the aligned variables into an inline module and mark it as #[rustfmt::ignore]
• Add #![rustfmt::ignore] to the top of the file to avoid formatting the whole thing

When Windows maps a PE32+ executable in memory and ASLR is enabled, OptionalHeader.ImageBase is relocated to the virtual address at which the image is loaded. However, this does not happen for PE32 executables (at least under WoW64); OptionalHeader.ImageBase is still the preferred virtual address. Hence when creating a Pe object via PeView::module, for example, the Pe methods that perform VA to RVA translation using this value may end up reading unnacessible or out-of-bounds memory.

I have encountered this issue while trying to use the provided pe32::msvc RTTI structs to extract class names and virtual function tables from a loaded DLL in the same 32-bit process, as these structs have Ptr<T> fields (whose values have been adjusted by the OS due to ASLR).

EDIT: After more testing, it appears that OptionalHeader.ImageBase is normally relocated for 32-bit DLLs as well. I checked a couple 32-bit DLLs but only the one I was initially working with, steamclient.dll from Steam, had this weird behaviour. After inspecting steam_api.dll, which is responsible for loading steamclient.dll, it does so by using a call to LoadLibraryEx with only the LOAD_WITH_ALTERED_SEARCH_PATH flag set. I doubt this should affect how the ImageBase value behaves under ASLR, but did not find any difference in the DLL's headers that should do so either.

One thing provided in the python pefile package is a get_imphash method.

https://github.com/erocarrera/pefile/blob/4c57c1443bb504281dcc00e1ddec9d62c5e39b35/pefile.py#L3824

This would be a great feature.

Here https://crates.io/crates/pelite the project erroneously has the category "Command line utilities".

Could you please remove it?

Thanks,
Yuri

The following code works well on Windows, but on Linux in our CI environment, it cannot extract version.

We are running cross-compilation in containers of GitLab CI, the PE files are fine. I download them and try to parse on Windows, and it works. But when the code executes on Linux, it fails.

fn parse_pe_version(file_path : &str) -> String {
    match FileMap::open(file_path) {
        Err(e) => format!("FileMap::open failed. {}", e),
        Ok(file_map) => {
            match PeFile::from_bytes(&file_map) {
                Err(e) => format!("PeFile::from_bytes failed. {}", e),
                Ok(file) => {
                    match file.resources() {
                        Err(e) => format!("file.resources() failed. {}", e),
                        Ok(resources) => {
                            match resources.version_info() {
                                Err(e) => format!("resources.version_info() failed. {}", e),
                                Ok(version_info) => {
                                    match version_info.fixed() {
                                        None => format!("No fixed version info"),
                                        Some(fixed_info) => {
                                            let version = fixed_info.dwFileVersion.to_string();
                                            if version.len() > 0 {
                                                version
                                            } else {
                                                fixed_info.dwProductVersion.to_string()
                                            }
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        },
    }
}

PeFile::from_bytes failed. try again with correct parser

Hi! Сould you help me?

main.rs

extern crate pelite;

use std::mem;

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

fn main () {
	let fmap = pelite::FileMap::open("hello.dll").unwrap();
	let pf = PeFile::from_bytes(&fmap).unwrap();
	unsafe {
		// ManualMap the module
		let module = pf.mmap().load().unwrap();
		println!("mapped module at {:?}", module);

		// Call an exported function as a very basic test
		let f: unsafe fn() = mem::transmute(module.offset(0x1230));
		f();
	};
}

hello.rs

#[no_mangle]
pub extern fn main() {
    println!("Hello, world!");
}

I get an exception:

thread 'main' panicked at 'called Result::unwrap() on an Err value: Imports(Misalign)', libcore\result.rs:945:5
note: Run with RUST_BACKTRACE=1 for a backtrace.

Hey, I'm new to Rust so this may be the issue since im not familiar with it's wild syntax sugary appeal yet..

So i use this crate very well, other than getting an RVA.. I've tried like a dozen different ways and haven't saved them to show all possible examples of my issue, so ill show you what I have now that doesn't give a compilation error..

for sect in image.section_headers() { let va: Va = sect.VirtualAddress.into(); let rva = image.va_to_rva(va.into()); println!("Section Name: {:?} -- VirtualAddress {:#x} -- Size {} Bytes -- RVA: {:#?}", sect.name().unwrap(), sect.VirtualAddress, sect.VirtualSize, rva) }

Example output: Section Name: ".text" -- VirtualAddress 0x1000 -- Size 584160 Bytes -- RVA: Err(Bounds,)

Not really sure where to go, tried searching this repo for usage and couldn't find anything along the same context of what im trying to accomplish.

Apparently there doesn't need to be a US English VERSIONINFO resource - I've come across a DLL that only has a version info resource for language 1049 (Russian). This is an unnecessary problem if you're only after the VS_FIXEDFILEINFO structure, which is language-independent and doesn't require a language code to be provided to VerQueryValueW.

It would be useful to have a few methods (names are provisional, I'm happy to bikeshed them):

• Resources::fixed_version_info() -> Option<&'a VS_FIXEDFILEINFO> for when you only want the language-independent bit
• Resources::first_version_info() -> Result<VersionInfo<'a>, FindError> for when you don't know or care what language's version info to get
• Resources::localised_version_info(language: u16) -> Result<VersionInfo<'a>, FindError> for when you know what language to try for

Alternatively, the latter two could be replaced by a method that returns a collection of all VersionInfo resources and leaves it up to the user to pick which to use. That would also make it easier to inspect what languages have VersionInfo structures available.

(The language for Resources::manifest() is also hardcoded to 1033, presumably that can have the same issue, but I haven't looked into it.)

It would be great if the pedump tool would have a cli flag to dump all of the data as a Json document. This way it would become a safe alternative to the widely used python pefile tool:

https://github.com/erocarrera/pefile

First, thanks for this great crate, it's been a huge help!

While trying to look at the import table of C:\Program Files (x86)\Common Files\Microsoft Shared\Phone Tools\CoreCon\11.0\bin\IpOverUsbSvc.exe, I'm getting a misaligned address error. This appears to be caused by the IMAGE_IMPORT_DESCRIPTOR table being misaligned, which is confirmed when looking at the binary in a hex editor:

The binary can be found here:
IpOverUsbSvc.exe.zip

Here's some test code:

use pelite::PeFile;

static IP_OVER_USB_SVC: &[u8] = include_bytes!("IpOverUsbSvc.exe");

#[test]
fn test() {
    let pefile = PeFile::from_bytes(IP_OVER_USB_SVC).unwrap();
    let imports = pefile.imports().expect("Grabbing the import table to work.");
}

Hello there!

You seem to be very experienced at coding cheats and overall in C+ from your posts on UC.

I'm looking for a coder, who is interested to code for me ESP (Wallhack) in APB:Reloaded (EAC - easy anti cheat).

The only features i'm looking for is enemy box.

[U][B]I offer 200 USD monthly for this project.[/B][/U]

Please add me on discord: excommunicado#1173 if you are interested!

If the price is too low for you, add me anyway i'm sure we can work this out.

I'm hoping to hear back from you soon.

The attached binary has the size of the resource directory set to 350720, while it's .rsrc section is only 340996 bytes long (virtual size). Windows is okay with this file, and is capable of loading and running it correctly, while pelite returns Error::Bounds

HxD.exe.zip

Adding a proc macro for WideStr would allow having WideStr constants.

#[proc_macro]
pub fn wstringify(item: TokenStream) -> TokenStream {
    let item = syn::parse_macro_input!(item as LitStr);
    let value: String = item.value();
    let mut chars: Vec<u16> = value.encode_utf16().collect();
    chars.insert(0, u16::try_from(chars.len()).unwrap());
    let result = quote!{[#(#chars),*]};
    TokenStream::from(result)
}
// 
pub const ABC : [u16; 4] /* WideStr */ = wstringify!("ABC");

Uses quote and syn

This would also require WideStr to be sized though.

code:

    let unwind = fun.unwind_info().unwrap();
    let codes = unwind.unwind_codes();
    println!("RVA {:02x} has {} unwind codes:", fun.image().BeginAddress, codes.len());
    for code in codes {
        println!("CodeOffset {:02x} UnwindOpInfo {:02x} FrameOffset {:04x}", code.CodeOffset, code.UnwindOpInfo, code.FrameOffset);
    }

output:

RVA 00200010 has 4 unwind codes:
CodeOffset 02 UnwindOpInfo 06 FrameOffset 0603
CodeOffset 06 UnwindOpInfo 32 FrameOffset 3002
CodeOffset 02 UnwindOpInfo 04 FrameOffset 0003
CodeOffset 01 UnwindOpInfo 06 FrameOffset 0602

real data:

RUNTIME_FUNCTION(00200010h, 00200040h)
  UNWIND_INFO: 00041B70h
    version: 2
    flags: (none)
    prolog: 6h
    count: 4
    frame register: (none)
    frame register offset: 0h
    unwind codes:
      02h UWOP_EPILOG(at_end: false, size: 02h)
      03h UWOP_EPILOG(offset: 0003h)
      06h UWOP_ALLOC_SMALL(32)
      02h UWOP_PUSH_NONVOL(RBX)

likely caused by mismatch of type. here:

#[derive(Copy, Clone, Debug)]
#[cfg_attr(feature = "serde", derive(::serde::Serialize))]
#[repr(C)]
pub struct UNWIND_CODE {
	pub CodeOffset: u8,
	pub UnwindOpInfo: u8,
	pub FrameOffset: u16,
}

real (in C):

struct UNWIND_CODE
{
    BYTE offset;
    BYTE code : 4;
    BYTE info : 4;
};

docs: https://docs.microsoft.com/en-us/cpp/build/exception-handling-x64?view=msvc-160

In pelite 0.8.1, pelite-macros is pinned to ^0.1.0 (per crates.io). This now horribly breaks with pelite-macros 0.1.1:

   Compiling pelite v0.8.1
error[E0432]: unresolved import `pelite_macros::pattern_attribute`
  --> /Users/zunder/.cargo/registry/src/github.com-1ecc6299db9ec823/pelite-0.8.1/src/lib.rs:35:9
   |
35 | pub use pelite_macros::pattern_attribute;
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `pattern_attribute` in the root

error[E0432]: unresolved import `pelite_macros::Pod`
  --> /Users/zunder/.cargo/registry/src/github.com-1ecc6299db9ec823/pelite-0.8.1/src/lib.rs:55:9
   |
55 | pub use pelite_macros::Pod;
   |         ^^^^^^^^^^^^^^^^^^ no `Pod` in the root

error[E0432]: unresolved import `pelite_macros::_Pod`
  --> /Users/zunder/.cargo/registry/src/github.com-1ecc6299db9ec823/pelite-0.8.1/src/lib.rs:58:16
   |
58 | pub(crate) use pelite_macros::_Pod;
   |                ^^^^^^^^^^^^^^^^^^^ no `_Pod` in the root

error: cannot find derive macro `Pod` in this scope
  --> /Users/zunder/.cargo/registry/src/github.com-1ecc6299db9ec823/pelite-0.8.1/src/image.rs:69:23
   |
69 | #[derive(Copy, Clone, Pod, Debug)]
   |                       ^^^
...

This can be solved by pinning pelite-macros directly:

pelite-macros = "=0.1.0"
pelite = "0.8.1"

You might consider bumping the version number more significantly for breaking changes in future? :)

pelite 0.9.0 also broke the way resources work, I guess the changelog reference "Refactored resources paths" means this? pelite::resources::RSRC_TYPES isn't really documented/is internal, so the find()/find_data()/find_dir() methods are super brittle. Looking into the code, I did finally figure out how to use the methods that take Names, which initially I thought I couldn't until I saw Name::Id() this time around.

(On that note, it's also kind of confusing the commit for 0.8.1 is not merged into the main branch. If you just look at the master history, it jumps from 0.8.0 to 0.9.0, and 0.8.1 is only accessible from the tag (although there is no tag for 0.9.0))

Alright, hope this helps! I do love using this library, it does exactly what I want and does it well. This release was a bit of a mixed bag, but small things like by_name help a lot. Cheers!

Hi! Can I run PE file from memory using this package, not just to find information? Thank you!

I tested this on C:\Windows\System32\winmm.dll, and dumpbin gives me the following report:

C:\Windows\System32 ❯ dumpbin /exports winmm.dll
Microsoft (R) COFF/PE Dumper Version 14.39.33519.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file winmm.dll

File Type: DLL

  Section contains the following exports for WINMM.dll

    00000000 characteristics
    3C007A3E time date stamp
        0.00 version
           2 ordinal base
         193 number of functions
         192 number of names

// snip -> 192 functions follows

But when I call .iter_name_indices I am getting only 180, with quite a few of the names missing. Not only that, but many of the indexes returned do not match up with the actual functions that dumpbin is telling me, causing me to generate incorrect function -> index data

use pelite::{util::CStr, FileMap, PeFile};

fn main() {
    let mapping = FileMap::open(r"C:\Windows\System32\winmm.dll").unwrap();
    let pe_file = PeFile::from_bytes(&mapping).unwrap();
    let exports = pe_file.exports().unwrap();
    let exports_by = exports.by().unwrap();

    let mut export_names = Vec::<Option<&CStr>>::new();
    export_names.resize(exports_by.functions().len(), None);
    for (name, index) in exports_by.iter_name_indices() {
        export_names[index] = Some(name.unwrap());
    }

    let ordinal_base = exports.ordinal_base() as usize;

    println!(
        "ordinal base {ordinal_base:?}\n{export_names:#?}\nnum_funcs: {}",
        exports_by.functions().len()
    );
}

HI, how can I get your contacts for private conversation? here are my telegram: @rm and jabber: [email protected]

Hello,

when i try to extract icons or group_icons from this dll

c:\windows\system32\imageres.dll
C:\Windows\System32\wmploc.DLL

as an example, i have not tested all dlls.
Exe functioned very well.
For my programm what i have write in have used an example-lnk and there i have used this dlls. Are only examples but i wonder why some dlls are have icons/group_icons and some not.

The newest versions don't have the function group_icons no more and only icons?

Your PeKit shows the same zero icons on resources.

thx

edit: the group iterator in resources have the same state. no groups i resorces on some dlls.

for (name, group) in resources.icons().filter_map(Result::ok)
	{
		// println!("{:?}", group.entries());
		for entry in group.entries()
		{
			println!("{:?}", entry);
		}
	}

C:\Users\user1\Downloads\pelite-master> cargo run --example apex --release -- C:\Users\user1\Downloads\pelite-master\EasyAntiCheat_launcher_dump > C:\Users\user1\Downloads\pelite-master\examples\apex\stdout.md

This is the command I run, and i verified that the apex dump is in pelite master directory. any help? thanks in advance