Wrong address size populated for win32 x86 process #116
Comments
|
Hey there, thanks for your first issue! Im not sure if i understood the request correctly though. The read_addr32 and read_addr64 as well as read_addr_arch functions are still present. However they are not exported to the C layer due to constraints in the implementation. You can easily re-implement them in your C code however by reading a uint32_t or uint64_t respectively and then put this into an address. They are currently implemented like this: memflow/memflow/src/mem/memory_view/mod.rs Line 222 in 99889b6 In case you want to read into a struct directly then of course pointers will not be sufficient as they the struct will have the pointer widths of the architecture you compile it for. To circumvent that you could for example either replace the pointers in the structs with uint32_t values or uint64_t values respectively and then read the struct they are pointing to. Having raw points in a struct that you read with memflow will point to invalid memory anyways (in the context of your application). Currently there is no way to resolve raw pointers in a way that would work for this use case. #[repr(C)]
#[derive(Copy, Clone, Pod)]
pub struct Prop {
pub table: Pointer64<Table>, // table_t *
pub name: Pointer64<ReprCString>, // const char *
}
#[repr(C)]
#[derive(Default, Copy, Clone, Pod)]
pub struct Table {
//
}
// ...
let virt_mem = &mut process.forward_mut();
let prop_name = prop.name.read_string(virt_mem)?.to_string();
// ...
let mut table = Table::default();
prop.table.read_into(virt_mem, &mut table)?;Hope that helped. |
|
@ko1N Thank you for the clarification! "In case you want to read into a struct directly then of course pointers will not be sufficient as they the struct will have the pointer widths of the architecture you compile it for" I have thought about that, but this is what I have got where there was a try to build with the x32 arch ("-m32" flag in Cmake file): /usr/bin/ld: i386:x86-64 architecture of input file Is it possible to have x32 memflow-ffi build? |
|
The current solution would be to manually build memflow-ffi as a 32bit target. You could try compiling the main repo for i686. Something like this could work: Edit: I will try and see if we could add a test case to the ci for this. |
|
Thanks @ko1N! But it showed this error: alex@fedora:~/repo/memflow$ cargo build --target i686-pc-windows-msvc --release --all-features --workspace Does this build expects WinOS to be running on? I am using Fedora as host Os and Win10 as guest Os |
|
Then you probably want to use something like i686-unknown-linux-gnu instead. Please refer to the rustup docs on how to setup different targets: https://rust-lang.github.io/rustup/cross-compilation.html |
Hello!
Using memlow-ffi and reading x32 process inside Win10x64 VM, so every pointer is an actually a DWORD(uint). So reading a c++ structure object with pointers, which are being read by memflow read_raw as x32 pointers (ulong) so it is impossible to normally read a structure data after any pointer inside a structure.
Could someone please add a fix or feature for supporting reading pointers as x86? I saw there is a feature for original Rust implementation for reading x32 addresses like "read_addr32", but probably it is only for an address or it supports the structures too, nit sure.
Please add possibility for reading pointers as x32 for a pointer type if reading into a structure.
Or at least please point me to the place where it could be added/updated, maybe I could contribute and add this.
Thanks!
The text was updated successfully, but these errors were encountered: