As the following picture shows , I can get the code buff with asm in x86 platform. Has anyone know how to do this in x64 platform???

bool CheckCodeSnipeCrc32()
{
	DWORD addr1, addr2, size;
	_asm mov addr1, offset codeBegin;
	_asm mov addr2, offset codeEnd;
	codeBegin:
		//OutputDebugString(L"test");
		//OutputDebugString(L"test0");
		//OutputDebugString(L"test1");
		int a = 0;
		a = a + 1;
		a = a - 1;
	codeEnd:
		size = addr2 - addr1;
		DWORD curcrc32 = Crc32_ComputeBuf((void*)addr1, size);
		DWORD oldCrc32 = 0xbcf07446;
		assert(oldCrc32 == curcrc32);
}

There is no picture.

EDIT: It's edited in now, ignore my original post

1 hour ago, Lactose said:

There is no picture.

Edit: Some code has now been edited in. This post can be ignored

Why? I have pasted the code screenshot, but it didn't show. So I add the code here!

Just now, laiyierjiangsu said:

Why? I have pasted the code screenshot, but it didn't show. So I add the code here!

I mean my post could be ignored, since you edited it it. Sorry for the confusion

VS doesn't support inline assembly in x64 builds.

For CRC checking a function body... Hmm...

Let me fiddle with it for a minute.

No, I can't come up with anything reliable. Even trying to grab the function pointer as a starting point I ended up staring at a jump table.

21 minutes ago, Khatharr said:

Even trying to grab the function pointer as a starting point I ended up staring at a jump table.

Do you have edit-and-continue turned on and you're looking at the JMP thunk?

Probably.
You'd also have to prevent inlining if it was done that way, and there's still the problem of finding the end address of the function.

The other thing that I was looking at was getting label addresses, but apparently that's not a thing (though gcc may offer it).

I guess one other option may be to just write your own sort of sub-loader. You could dump the module memory from a loaded/running version, then load that into an x-flagged page at runtime and jump in. You'd need to have some jumpout for CRC checking, though, and that would have to be a static address somehow because otherwise it would change the CRC of the module, though I suppose it wouldn't be too hard to compensate for that if you have the address as zero in the file and then when you load it you set it to the target address and then add that value to the checksum.

Still, though, if I were hacking that game I'd just overwrite the CRC function to indicate success.

11 hours ago, Lactose said:

I mean my post could be ignored, since you edited it it. Sorry for the confusion

Thanks , Lactose ! My English is poor,

4 hours ago, Khatharr said:

Probably.
You'd also have to prevent inlining if it was done that way, and there's still the problem of finding the end address of the function.

The other thing that I was looking at was getting label addresses, but apparently that's not a thing (though gcc may offer it).

I guess one other option may be to just write your own sort of sub-loader. You could dump the module memory from a loaded/running version, then load that into an x-flagged page at runtime and jump in. You'd need to have some jumpout for CRC checking, though, and that would have to be a static address somehow because otherwise it would change the CRC of the module, though I suppose it wouldn't be too hard to compensate for that if you have the address as zero in the file and then when you load it you set it to the target address and then add that value to the checksum.

Still, though, if I were hacking that game I'd just overwrite the CRC function to indicate success.

Thanks, I just use this methed to detect that if my core code is being debugging . If someone wants to hack , it's achieveable.

58 minutes ago, laiyierjiangsu said:

I just use this methed to detect that if my core code is being debugging . If someone wants to hack , it's achieveable.

If you're looking for informational reasons, or for code to take special paths, most operating systems have code that politely indicates if  a debugger is attached. On windows those are IsDebuggerPresent() to see if the program was launched by a debugger, and CheckRemoteDebuggerPresent().

The programs are always hackable, and it is possible to attach debuggers without those flags getting set, but they can serve as good tools if you want to use different behavior while being debugged.