Can we support reverse engineer friendly?

language design
1

okay,i have been using rust do some reverse engineer work about one year.In the past year,totally,all of the things i would love to use rust. Love those hmm, crate management,or dealing with error? 90 % area very comfortable. But can we support decltype keywork like cpp?,i just 100% don't wanna rewrite so much function params define again especially when using hook in wondows api,i know rust just pay attention more about the safety,but we have unsafe isn't it? and when i use pdb to do some patch then i try dump the struct from cpp Class.the inheritation can't support.

so eg..when i wanna get some inherited object i need to use like this one

#[repr(C)]
pub struct CAvatar {
    _p0: Padding<0x4e4>,
    pub move_action: i32,
    _p1: Padding<0xBD0>,
    pub p_body_origin: IWzVector2D, //0x1140
}

impl CAvatar {
    pub fn get_user(&self) -> &CUser {
        unsafe {
            let ptr = (self as *const CAvatar).byte_sub(0x88) as *mut CUser;
            ptr.as_mut().unwrap()
        }
    }
}

holyshit,it is painful.

i don't know if this will have some changes,i mean about the reserve engineer support friendly.i just try it.

2

if you want to ergonomically reinterpret memory as two different types, unions are quite handy.

although, it looks like you're looking for the rust equivalent of zig's @fieldParentPtr?

not sure what either of those have to do with decltype.

2 Likes
3

You are using a code block for your text which makes it hard to read on mobile. Can you post it as a normal text?

4

Sorry idk why some text became code block.i just use some white space in head line.well much better now.

1 Like
5
  1. I believe you meant reverse engineer where you said reserve engineer?
  2. Could you give an example of how you use decltype in C++ and how this avoids the problem you're having with Rust? I can imagine translating your example Rust code directly to C++ but I do not see how any C++ features would make it less annoying to write.
1 Like
6 
inline void HookCreateWindowExA()
{
	static auto create_window_ex_a = decltype(&CreateWindowExA)(
		GetProcAddress(LoadLibraryA("USER32"), "CreateWindowExA"));
	static const decltype(&CreateWindowExA) hook = [](
		DWORD dwExStyle,
		LPCSTR lpClassName,
		LPCSTR lpWindowName,
		DWORD dwStyle,
		int x,
		int y,
		int nWidth,
		int nHeight,
		HWND hWndParent,
		HMENU hMenu,
		HINSTANCE hInstance,
		LPVOID lpParam) -> HWND
	{
		dwStyle |= WS_MINIMIZEBOX; // enable minimize button
		return create_window_ex_a(dwExStyle, lpClassName, lpWindowName, dwStyle, x, y, nWidth, nHeight, hWndParent,
		                          hMenu, hInstance, lpParam);
	};

	Memory::SetHook(true, reinterpret_cast<void**>(&create_window_ex_a), hook);
}

See here,if we wann create a hook for CreateWindowExA we neendn't typedef a again right?

if we wanna use hook in rust we need to do this,

//this is a macro impl by retour static crate in rust.we need to declare type a gain when we use a hook.
dll_hook!("kernel32","CreateFileA","system",
(
    PCSTR,
    u32,
    FILE_SHARE_MODE,
    *const SECURITY_ATTRIBUTES,
    FILE_CREATION_DISPOSITION,
    FILE_FLAGS_AND_ATTRIBUTES,
    HANDLE
) -> HANDLE,
|lpfilename,dwdesiredaccess,dwsharemode,lpsecurityattributes,dwcreationdisposition,dwflagsandattributes,htemplatefile|{
    CreateFileA.call(lpfilename,dwdesiredaccess,dwsharemode,lpsecurityattributes,dwcreationdisposition,dwflagsandattributes,htemplatefile)
});
7

I imagine the same reasons for why you can't use type inference for statics also apply to why you can't use on demand type inference.

In this specific case Rust's current answer is presumably that the crate defining the import should also define the type (and symbol string), perhaps using macros, and a similar case on the usage side