The FPointer address is never the same as the actual function address which seems odd to me.
Yet when I do:
std::cout << (*FPointer)(4, 4);I get the expected result.
Can anyone explain why this happens?
Function pointer mishaps!
Author
I've been messing with function pointers (Particularly I was trying to see if I could extract the machine code of a function at runtime) in C++ and this threw me a little:
The FPointer address is never the same as the actual function address which seems odd to me.
Yet when I do:
I get the expected result.
Can anyone explain why this happens?
The FPointer address is never the same as the actual function address which seems odd to me.
Yet when I do:
I get the expected result.
Can anyone explain why this happens?
The address shouldn't be the same, but take a look at the value of FPointer. It should be 0x009313a0.
Author
@ilmarinen That's what I meant. If I'm assigning the address of the function "Test" (Which is 0x009313a0) to FPointer then why doesn't FPointer contain the address 0x009313a0?
Maybe you are getting confused and forgetting that pointer can have its own address as well.
Author
Maybe I am. But I would've thought that the debugger would have made that clear to me. Maybe it's just a feature of function pointers? When I cast "Test" to an integer pointer however I get the same result and I can click the expand icon to see what data is being stored at said address which makes me think that this is not the address of the pointer itself if that makes sense!
EDIT: I'll try and illustrate what I'm talking about there:
So you see how an integer pointer results in the same pattern and I can see the data that it is pointing to (0x000351e9) as well as where this data is stored (0x00f4100a)
EDIT 2: I've also noticed that the address my FPointer is pointing to always seems to end in 100a. Probably coincidence though.
EDIT: I'll try and illustrate what I'm talking about there:
So you see how an integer pointer results in the same pattern and I can see the data that it is pointing to (0x000351e9) as well as where this data is stored (0x00f4100a)
EDIT 2: I've also noticed that the address my FPointer is pointing to always seems to end in 100a. Probably coincidence though.
The address you get (if you look at the disassembly) is actually an address to a jump table, which jumps to the appropriate function.
For example in my case:
Test = 0x428260
FPointer = 0x426096
The assembly I get for the function call is:
and way above my code at 0x00426096 I get:
Jumping to what's expected. I think its there for debugging. In release mode I get a direct call to the function (in fact the function pointer has been optimized right out):
For example in my case:
Test = 0x428260
FPointer = 0x426096
The assembly I get for the function call is:
int (*fp) (int,int) = Test;004282AE mov dword ptr [fp],offset Test (426096h) fp(5,6);004282B5 mov esi,esp 004282B7 push 6 004282B9 push 5 004282BB call dword ptr [fp] and way above my code at 0x00426096 I get:
Test:00426096 jmp Test (428260h) Jumping to what's expected. I think its there for debugging. In release mode I get a direct call to the function (in fact the function pointer has been optimized right out):
fp(5,6);00401010 push 6 00401012 push 5 00401014 call Test (401000h) 00401019 add esp,8
Author
Aha! Well spotted! This makes sense now. This means that I can extract the real address in debug mode by grabbing the JMP instruction stored where FPointer is pointing at.
Thanks a lot!
Thanks a lot!
Author
I'm trying to see if I can write a function in C++, extract it's machine code at run time and then re-implant said machine code into another executable.
The reason being that I had a thought about being able to take a custom script, map each command to a function that implements said command and then outputting a unique executable that is that script in machine code. No real practical reason for this, just an experiment really.
The reason being that I had a thought about being able to take a custom script, map each command to a function that implements said command and then outputting a unique executable that is that script in machine code. No real practical reason for this, just an experiment really.
Interesting, you'll probably get more predictable results if you compile to a library and use that to extract the source code. As libraries are designed to be pulled apart, jumped into, ect... Not to mention the file formats are well defined and can be compiled with tons of extra info to properly enumerate and extract said code.
Pulling code right out of an executable is a bit unstable at best (though for experimentation/shits 'n giggles that doesn't really matter) as functions can be inlined, modified, ect...
Pulling code right out of an executable is a bit unstable at best (though for experimentation/shits 'n giggles that doesn't really matter) as functions can be inlined, modified, ect...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
