64bit process reading from 32bit process copies too large addresses.

[Kiiyya]

I was debugging why something isn't working, and then I realized CopyAddress::get_offset() is copying too many bytes. My program is 64bit, whereas the game I read from is 32bit.

I believe the culprit is this: https://github.com/Tommoa/rs-process-memory/blob/5bd1055857dab817e54a12c3c2a3523c338d90ac/src/windows.rs#L46 Why are we using from_native() here? I thought the whole point of having Architecture was to support reading from 32bit processes? Gonna work on a fix while waiting for replies.

If I miss something, sorry, I'm new to rust :).

[Kiiyya]

A fix (for Windows only. Issue remains on Linux/macOS) is here: https://github.com/Kiiyya/rs-process-memory/commit/707eae2237df01de787828eccd27162f7353191d

But since it's based on https://github.com/Tommoa/rs-process-memory/pull/4 I won't open a PR yet.

[Tommoa]

I think you might have missed that Architectures work on ProcessHandles and should be called on them.

So some working code for you might be something like:

let process_handle = get_pid("32-bit.exe").try_into_process_handle()?;
let process_handle = process_handle.set_arch(Architecture::Arch32Bit);

let member = ...

The reason for this structure is that even though you can (likely) determine the correct architecture of a Windows program by looking for SysWOW64, I don't think that the same can be done for Linux and OSX and I'm not sure about trying to include functionality that doesn't work on all supported OSes and may not even function correctly across different architectures (e.g. does SysWOW64 still exist to show 32-bit programs on Windows on ARM?).

Please let me know if this solves your issue or if you think that there might still be room for improvement on handling varying architectures.

[Kiiyya]

I think a functionality to get the architecture of an executable/process would be super convenient. Setting it to native by default creates issues like I ran into, debugging things which are difficult to debug, since most of the time copying 8 byte pointers instead of 4 bytes pointers will work just fine (if there's an extra few zeros just by chance), but then some other times it will fail. And it's not obvious what causes that. Imagine users just assuming the library knows what it's doing. Also, at least trying to consult IsWow64Process is better than just blindly choosing native architecture. I'll have a look into whether determining arch will be possible on Linux on the weekend.

I'd suggest something like my_raw_handle.try_into_arch(), which returns a Option<Architecture> (or Result), which then has to be used with .try_into_process_handle. I would remove .set_arch then, since an architecture doens't just change during runtime, heh. Though this is just a first wild suggestion, maybe something more fancy with traits can be thought of.

As far as I know, there exists IsWow64Process2 which had something mentioned about ARM, but I'll look into that on the weekend.