[pRED*]

Recon: When copy_bytes is passed 0 as the second parameter it will return a count of how many bytes need to be copied.

The third parameter (6) is how many bytes of space we are going to be overwriting, and copy_bytes will find the next instruction boundary at or beyond 6, so that we only copy whole instructions. (Leaving half an instruction at the source wouldn't be pretty).

You are absolutely correct with the fixing jump/call code!

Keeper: Yes, he's using the 6 byte version of jump.

[recon0]

Originally Posted by pRED* Recon: When copy_bytes is passed 0 as the second parameter it will return a count of how many bytes need to be copied. The third parameter (6) is how many bytes of space we are going to be overwriting, and copy_bytes will find the next instruction boundary at or beyond 6, so that we only copy whole instructions. (Leaving half an instruction at the source wouldn't be pretty). You are absolutely correct with the fixing jump/call code! Keeper: Yes, he's using the 6 byte version of jump.

That's what I read in the function.

That makes sense.

Cool.

That's what threw me off. I thought the most a jump could be was 1 (op) + 4 (address). In case anyone's looking for it, I found a page of Intel's on jumps (also, Intel's 64 and IA-32 manual has a page on the jump instruction's variations).

How could a jump be six bytes though? Sun's IA-32 manual has some interesting information on the subject:

Description The jmp instruction transfers execution control to a different point in the instruction stream; records no return information. Jumps with destinations of disp[8|16|32] or r/m[16|32] are near jumps and do not require changes to the segment register value. jmp rel{16|32} adds a signed offset to the address of the instruction following the jmp instruction to determine the destination; that is, the displacement is relative to the next instruction. The displacement value is stored in the EIP register. For rel16, the upper 16 bits of EIP are cleared to zero resulting in an offset value not to exceed 16 bits. ljmp ImmPtr or *mem48 use a four- or six-byte operand as a long pointer to the destination. In Real Address Mode or Virtual 8086 mode, the long pointer provides 16 bits for the CS register and 16 or 32 bits for the EIP register. In Protected mode, both long pointer forms consult the AR (Access Rights) byte of the descriptor indexed by the selector part of the long pointer. The jmp performs one of the following control transfers depending on the value of the AR byte: A jump to a code segment at the same privilege level A task switch

Shouldn't the instruction use seven bytes (1 op code + 6 operand)?

EDIT: After some time with the disassembler, I think I figured it out.

    
jmp dword ptr [cs:11BB22EEh]
00B71010 2E FF 25 EE 22 BB 11    jmp         dword ptr cs:[11BB22EEh] 
     

jmp dword ptr [ds:11BB22EEh]
00B71017 FF 25 EE 22 BB 11       jmp         dword ptr ds:[11BB22EEh]

A jump that loads cs has a three byte op code, 2E FF 25, and a jump that loads ds has a two byte op code, FF 25. The length of the operand doesn't change (4 bytes), so the sizes for the jumps are 7 and 6 bytes respectively.


Thanks for the clarification everyone.

[recon0]

Added question above ^

[your-name-here]

I'll take a look at it when I get home. It looks like I've messed up! :O

I really need to revisit that code. It looks like some of those comments are from dead code/random testing I did. Probably would be a good bet to make sure the logic makes sense

[API]

You should really start development on a memory patching API.
My idea:

ProbeMemory *x = api->ProbeAddress(0x123);
if(!x->IsPatched())
{
x->Patch(...);
}

[your-name-here]

Originally Posted by pimpinjuice You should really start development on a memory patching API. My idea: ProbeMemory *x = api->ProbeAddress(0x123); if(!x->IsPatched()) { x->Patch(...); }

If you're interested, I can add you to my googlecode SVN. PM me a way to IM you and we'll get started
That goes for anyone else who's interested as well.

My stuff was originally a proof of concept, but it's starting to become a bit more than that (for me at least). I'd love to contribute in any way possible to a dynamic hook library

[your-name-here]

One theory I had was having a single dll file (called dyndetours.dll) under /<game-dir>/addons. We could then have people LoadLibrary it, then using interfaces, access the patching API. That way, it won't rely on the source engine, and won't need to be statically linked into other plugins. We'd thereby have a centralized detour storage system and potentially avoid conflicts (unless someone detours without using the library).

Does this concept sound like a good plan to anyone?

[API]

You should really make it a SourceMod extension / Metamod plugin.

[DJ Tsunami]

If it has a decent API anyone can turn it into an MM:S plugin/SM extension. The core should be independent of that, and it looks like that's already the case

[your-name-here]

I agree with Tsunami.

I'd rather have the core completely independent of the source engine. That way multiple plugins MMS/SM, ES, and Mani can use the core provided that they use the interfaces I am planning to provide.

That way people can LoadLibrary/dlopen the DLL/so and I can have all the hooks in a central place. Updating the library would mean just updating a single file versus updating it for non-mms + mms.

I'm very lazy so I tend to write code that does work for me