[joaquimandrade]

Originally Posted by DJ Tsunami I came across Orpheu recently though, which seems to make dynamic hooking possible for AMX Mod X. Unfortunately that code just made my head spin. Now I know Source is not the same as GoldSrc, but it still seems to be possible. Indeed the question remains if that's a sane way of doing it.

Ignore the code, the concept is easy. A base class that defines the virtual functions related to convert "between a C++ type and a pawn type" and vice versa. Implemented in a class per type for types like CBaseEntity, entvars_s, edict, "string", etc. Then, depending on how the function is described in a file, an array of objects of each type is created like:

[0] = CBaseEntity object
[1] = String object
[2] = Float object

Then, with inline assembly code (so functions can be given a variable number of arguments) the array is iterated to convert from pawn to C++ or vice-versa and pass them from plugin to module or vice-versa.

The bigger problems that I had were creating the code to handle all types because float por example uses different processor registers so I had to do some stuff and strings are returned by reference, etc. But I had no prior assembly and C++ experience (had C experience tough) so I know you can do it with less problems that I had (edit: if you do it, try to use this idea. I wish I had it before making it since now it's a pain to make all over again)

I don't know how sourcepawn or sourcemod works but I guess you can apply the same concept to it.

About what David Bailopan said, don't be scared. What he is saying is that since he produces base tools they have to be under solid grounds (like, when having errors failing the sooner possible) and this concept can never be that solid per se (from the few I know). But in the end a tool like this is for more experienced users so the unsafeness is not a big problem. And since what it let's people do can't be achieved otherwise is nice to have it and the approved plugins using it are the proof of that (And two that bailopan banned ).

To end this post, sorry for making it so long but it's the first time I talked about this with someone that has more knowledge than me with this stuff and I didn't send this as PM because I hope that someone might give me some insight of how I can improve the stuff I did using another concept for example (namely, the thread author).

Note to Bailopan: In the Modules section there are many modules stickied less useful than Orpheu.

[BAILOPAN]

joaquim: i don't visit that forum often - stickied now.

I don't know how sourcepawn or sourcemod works but I guess you can apply the same concept to it.

definitely, it works very similar to AMX Mod X.

base tools they have to be under solid grounds (like, when having errors failing the sooner possible) and this concept can never be that solid per se (from the few I know). But in the end a tool like this is for more experienced users

exactly, thanks for clarifying this. my post was directed as Tsunami rather than the OP. our main interest in exposing such a system to script is type and memory safety. in C++ these restrictions are less critical as the developer is more likely to be a systems engineer with powerful debuggers.

[BAILOPAN]

in regard to detouring in HL2 plugins, we need to start looking at a framework in MM:S for marking memory as patched, so plugins that rely on memory pattern matching won't break. as tools like this one become more popular it's bound to happen.

this suggests hoisting some sort of pattern matching into MM:S.

[your-name-here]

Originally Posted by BAILOPAN in regard to detouring in HL2 plugins, we need to start looking at a framework in MM:S for marking memory as patched, so plugins that rely on memory pattern matching won't break. as tools like this one become more popular it's bound to happen. this suggests hoisting some sort of pattern matching into MM:S.

I would love to contribute to said framework if possible.

[your-name-here]

An update: I added thiscall support to Windows.
I also broke out a bunch of code to make it less messy

@Bail, one of the secrets to DynDetours is using ASMJit. If you've never heard of it, here's the link .

Basically, it an object oriented ASM generator, doesn't depend on STL, exceptions or rtti, and supports both Windows and Linux. I'd suggest looking into it.

[your-name-here]

Another update if anyone is still interested in this (comments welcome!)
I managed to get post-call callbacks implemented and I broke out and cleaned up a ton of stuff.

I've yet to commit as I'm still testing and cleaning up but next update should be a good one.

[API]

Any updates on making this an extension? Honestly, I don't see alot of issues with your design but I am sure BAILOPAN knows better than myself.

[your-name-here]

Originally Posted by pimpinjuice Any updates on making this an extension? Honestly, I don't see alot of issues with your design but I am sure BAILOPAN knows better than myself.

Heh, thought interest in this died.

No actually, I've just been super busy IRL. However, I am still working on DynDetours.

Right now, I'll need to figure out how to deal with parameters I am passing by reference (meaning I have to have my ASM code clean the stack up). I'll see if I can commit what I've got currently as of today.

[recon0]

Looks very interesting.

I've been trying to figure out what this is about (dd_detour.cpp, Trampoline_Create, lines 136 - 148

    // Figure out how many bytes we need to save
    // Skip past the prologue.
    m_iSavedBytes = copy_bytes(m_pTarget, NULL, 6);

    // Create the space for it
    // Need 5 bytes for a jump back to the target + 5.
    m_pSavedBytes = new unsigned char[m_iSavedBytes + 5];

    // Now copy the bytes
    copy_bytes(m_pTarget, m_pSavedBytes, m_iSavedBytes);

    // Inject a jump to the target
    WriteJMP(m_pSavedBytes+m_iSavedBytes, m_pTarget +     m_iSavedBytes);

I read the first line as looking for at least 6 bytes of space at the beginning of the function. If a jump is five bytes (instruction 1, op 4), why are you looking for six?

I was trying to decipher what the copy_bytes function meant by fix calls and jumps. Is it trying to relocate the destination offset (can't modify the base address right?) relative to the destination?

Is it supposed to fix something like:

00  Source
01  call Func1 ($ + 3)
02
03
04  Func1
05
06
07  Dst
08  call Func1 (if $ + 3 was used, we'd have a problem)
09 
0A
0B  Func1 is not here :(

Would become:

00  Source
01  call Func1 ($ + 3)
02
03
04  Func1
05
06
07  Dst
08  call Func1 ($ - 4)
09 
0A
0B  Not going here anymore :D

[Keeper]

Here's an example of a detour on a function:

2000C610 56               push        esi  
2000C611 68 F4 29 2E 20   push        202E29F4h

becomes:

2000C610 FF 25 C4 19 8C 06 jmp         dword ptr ds:[68C19C4h]

I believe it's a far absolute jump. So you need 6 bytes for the jmp, not 5.

I've been trying to learn this, and may be off, but I believe it is right.