My advice is... don't use WriteProcessMemory()- it's not hard for someone to open up your trainer; find the call and steal your pokes.
Usually, you can't write to game memory directly- if it's code (e.g; it's in the .TEXT section); because this page is marked with EXECUTE/READ_ONLY protection.
Luckily however, you can use
VirtualProtect() to change the target memory page's protection attributes. Once you've called this- you can poke directly.
Additionally though, I don't like using this function that way... people can still rip your codes pretty easy. Since you're still passing in the start address of your pokes, and the length....
To get around this- I created my own little hack to stop prying eyes... it's based on the fact that changing the protection attributes for a few bytes actually changes the whole page(s) protection that enclose these bytes; which could be any multiple of 4096 bytes.
I don't mind discussing it here because even if someone knows how this technique works it still doesn't get them much closer to finding the pokes.
Say you have a small 3 byte poke @ 0x341535326.
PBYTE pbyPokeAddr = (PBYTE)0x341535326;
On a typical machine, pages are aligned every 4kb- thats 4 * 1024 bytes = 4096 bytes so
#define PAGE_SIZE 4096
To get the start of the page boundary (round down), use this forumula:
PBYTE pbyPokeAddrPageStart = (DWORD)pbyPokeAddrPageStart & (DWORD)0xFFFF8000;
In DllMain(), call VirtualProtect()
VirtualProtect(pbyPokeAddrPageStart, PAGE_SIZE, ...)
And in your DrawIndexedPrimitive(), poke the codes directly e.g.
DrawIndexedPrimitive()
{
...
static BYTE byPokeCodes[3] = { 0x41, 0x24, 0xFF };
memcpy(pbyPokeAddr, byPokeCodes, sizeof(byPokeCodes));
...
}
in most cases, memcpy is substituted with direct inline assembly (by the compiler)- so no calls show up in debugger etc.
This method is easy to follow with source, and very time consuming to trace in binary.
It assumes the Dll is injected into the address space of the process you're changing memory, too.
Hope that helps!
Subsky
