Unwarranted Function Call

Question

So what I'm trying to do is simple; I want to write a function into the memory of another process and execute it. What I've done is gotten the size of the function and just used WriteProcessMemory to do this. I have successfully created a thread to run this function, confirmed using cheat engine's debugging features. The function looks like so:

inline void __cdecl Test( )
{ }

Looks pretty simple. It shouldn't rely on anything that needs to be relocated, so it should work just fine. It is inline because I defined it in a header, if that is relevant. Although this function does NOTHING, this is what is happening in cheat engine:

It's odd that it's copying a string, but more so that it's calling a function? Since this random function call is happening, the program crashes because the address isn't relocated to match where functions are in the new process. So, my question is: why in the world is it calling a function and how can I stop this from happening?

How do you know that's the function in question? And how are you getting the function's size? That's not something one can easily do in C or C++. — Jonathon Reinhart, Feb 15 '19 at 01:33
I'm disabling optimization and incremental linking, and creating another function below it. I then subtract the first function's address from the second function's. This gives me a size of 64, which is correct from what I see in cheat engine. I know this is my function because I got to this address from the return of VirtualAllocEx, and then watched the memory get written in. — , Feb 15 '19 at 01:35
`inline` functions won't normally have a stand-alone definition anywhere. Maybe when you compile with optimization disabled, but IDK why you'd want to declare it `inline` if you want to take the machine code from its stand-alone definition. — Peter Cordes, Feb 15 '19 at 02:56
`mov eax, 0xCCCCCCCC` / `rep stosd` makes me wonder if you're looking at function that copies the function, not the function itself. `0xcc` is the opcode for `int3`, and MSVC pads between functions with `int3`. So maybe you're copying a block of `int3`? Hmm, but IDK how that would end up as an immediate. Anyway, what is that the disassembly of? — Peter Cordes, Feb 15 '19 at 03:00
Compiling that empty function with MSVC even with optimization disabled doesn't emit any instructions. https://godbolt.org/z/BU7_2C. Because it's declared `inline`. Are you *sure* you were actually getting the right address / size? Or maybe you had some kind of MSVC incremental build option enabled. Anyway, probably that `0xCC` memset was a poison value for stack space, to help detect use of uninitialized variables. IDK why it would decide to allocate that much space, though. Maybe for incremental compilation while you're stopped at a breakpoint inside the function? — Peter Cordes, Feb 15 '19 at 03:44
MSVC inserts padding between functions when you're using the incremental linker (`/INCREMENTAL` switch) for rather obvious reasons, and as @Peter correctly points out, that padding is bytes of `0xCC` so that you get a break into the debugger if this "unreachable" code ever gets hit. — Cody Gray - on strike, Feb 16 '19 at 07:43
@CodyGray: I think this intentional memset with `rep stos` looks more like poisoning unused parts of the stack frame to make it easier to debug read-uninitialized, and out-of-bounds array access. The OP seems to be claiming this is just the code-gen for an empty `inline` function, not the result of copying it into somewhere else. — Peter Cordes, Feb 16 '19 at 07:47
Yup, `0xCC` is also used as a canary value to detect stack smashing via buffer overflows when [the `/RTCs` option](https://learn.microsoft.com/en-us/cpp/build/reference/rtc-run-time-error-checks?view=vs-2017) is specified. — Cody Gray - on strike, Feb 16 '19 at 08:12

score 0 · Accepted Answer · answered Feb 15 '19 at 03:28

0

So basically, debug mode was the cause for this issue and does not occur in release.

answered Feb 15 '19 at 03:28

Unwarranted Function Call

1 Answers1