https://github.com/Ayuto/DynamicHooks

Switch to amtl Vector.

The custom return value was lost when calling the original function.
Save and restore our own return value, if we're about to call the original function.

ecx might get cleared before the original function returns leading to garbage in the post handler.

The esp pointer wasn't removed from the map after the function was called and the original return address was retrieved.
If the same function was called again with the same esp this would fail due to there already being an (old) return address associated with the esp.

If the compiler decided to pass an argument in a register on an internal function instead of pushing it on the stack to save time, allow us to specify the register the parameter is going to be in.

DHookAddParam received another parameter to set the register.

The post hook would have cleared the esp value from the return address map, but there seems to be a case where the post hook isn't called, but the function gets called with the same esp again. This is probably just masking a different error :(

…s on the stack

If a function was optimized to only pass one parameter in a register, but still pass other parameters on the stack, save the registers at the correct offset in the buffer.

…ignore it

The this pointer was always passed to the plugin callback if the calling convention was a thiscall. Even if the plugin author set the this pointer type to ThisPointer_Ignore.

A "Functions" section is parsed in gamedata files that allow you to define the signature of functions including metadata like the calling convention and specifying the register an argument is passed in.
A new native DHookCreateFromConf can be used to setup a hook or detour from one of that function sections in the "Functions" section.

The this-pointer is always pushed first on the stack.

Just return null if a user tries to access an invalid argument that wasn't defined when detouring the function.

Some registers were upper case and HookParamType_CBaseEntity didn't follow the naming scheme of the other types.

Encourage passing the callback when hooking instead of when setting the hook up.

Deduplicate code for changed return values.

Add comments for non-trivial code.

…in gamedata

ke::HashMap doesn't keep the order the elements are added of course. Switch to a vector structure instead.

AutoPtr boxing fuckup here.

…in thread

The SourcePawn VM isn't threadsafe.

The "offset" key wasn't included in the validation of having the target function set.
https://bitbucket.org/Peace_Maker/dhooks2/issues/1/missing-check-for-offsets

The previous fix messed up parameter getters and setters.

When removing a plugin's callback from the list of callbacks of a detour
the next callback in the list would be skipped. Don't only check every second callback,
but every single one!

If the Functions section was parsed before and the gamedata file is loaded again,
the arguments were all added again instead of keeping the old number of arguments.

Floats are always returned in FPU register st0. Since the value in st0 doesn't matter in a pre-hook before the function was executed, don't try to save and restore the value of the FPU stack top for a pre-hook.
Only replace st0 after a post hook.

movaps requires the memory address to be 16-byte aligned. Make sure our buffer is properly aligned for the xmm0-7 registers.

When the this pointer is set to ThisPointer_CBaseEntity and the address is null, just return INVALID_ENT_REFERENCE instead of trying to access the pointer.

MacroAssembler base is now in the |sp| namespace.

Callee cleans the stack and first two arguments are passed in registers ecx and edx.
You could emulate this by choosing stdcall and setting the custom_registers on the arguments manually, but this is easier.

The new buffer/vector was freed before the old function was called with the new parameters
or the return value could be used by the called. This caused undefined behavior which seemed
to be fine before, where free didn't change the user-payload. free does change the user data now,
causing the changed values to be garbage.

Wait until the next frame before deleting the newly allocated buffers/vectors, so the original code had a chance
to use the live pointers. AddFrameAction might be a bad choice if our hook happens before the game ticks, but
we can tackle that problem when it happens ;)

This workaround already exists for the windows thiscall calling convention.
Since the this-ptr of CBaseEntity's is automatically dereferenced, there's no way for
plugin authors to avoid a crash if the pointer gets invalid.

The "Functions" section gamedata parser didn't skip the event of leaving an ignored sub section (like a "windows" section on a linux host) correctly, but counted it as leaving the parent section instead. This corrupted the parser state and made it parse the following entries in the wrong level.

Thanks vanz.

This fix was pushed to DynamicHooks a few hours ago. The stack space of the return address can be reused in recursive calls, causing us to overwrite the return address of the parent.

See the PR by L'In20Cible @jordanbriere Ayuto/DynamicHooks#4

The saved values of the inner, recursive call would overwrite the values of the outer calls.

Save them in a stack as well.

Thanks Alienmario!

If there were no pre-detour handlers registered for a detour, there was no return Action of the pre hook available in a post hook, so don't try to access it.

Needed when using the DHookSetFromConf native for the SDKFuncConfSource enum.

When a plugin which registered an entity vtable hook with a remove callback is unloaded OnMapEnd, dhooks still tried to call the removal callback on the next frame after the map ended and all entities were destroyed.

Remove the plugin's hooks from the removal list when a plugin is unloaded. The hooks are free'd anyways.

Drifter321#3

Don't try to pop values from any other stacks if there was nothing pushed in a pre-hook.

The previous fix in ac44af9 did not remove the hook itself instead of only not calling the removal callback. So yes, the removal callback wouldn't be called anymore, but the hook wouldn't be removed causing the normal hook callback to fire after the plugin unloaded.

Drifter321#3

Vtable hooks are wrapped in a `DynamicHook` methodmap and detours in a `DynamicDetour` methodmap. Parameters and return values pushed to the callbacks are of methodmap types `DHookParam` and `DHookReturn` to easily access the values.

Most functions are mapped 1:1 with the exception of creating vtable hooks, where the callback function has to be passed in the hook function instead of during setup.

`HookRaw` dropped the `removecb` parameter, since it was never called. There currently is no way to know when to unhook the raw object.

This change doesn't affect the legacy API at all.

Save the value of arguments in a seperate buffer for the post callback.
Compiler optimizations might cause the registers or stack space to be reused
and overwritten during function execution if the value isn't needed anymore
at some point. This leads to different values in the post hook.

When the callback signature is missing a parameter that gets pushed due to the hook setup, print a nicer error message telling the user they tried to call e.g. DHookGetParam(hReturn, 1).

Forgot to increase the buffer offset.

Automatic msvc detection ftw!

Save all arguments before calling the original function

When the server is shutdown the map ends which destroys all entities. DHooks listens on OnEntityDestroyed and adds all vhooks on that entity to a list to call the removal callback on the next frame. SourceMod unloads all plugins first before unloading extensions. All plugins are unloaded on the same frame, so the removal callbacks aren't worked down on the next frame. The second plugin to be unloaded runs through the list of removed entity vhooks and checks which one belongs to itself. The first plugin was unloaded already though and left a dangling pointer in that list which is accessed by the second plugin unloading.

Clear the plugin callback reference as well. Hopefully no hook is fired on the same frame after entity removal.. Will have to revisit in that case.

Allows to compile against SourceMod 1.11+ which uses an updated AMTL without ke::Vector.

…ourcemod repo

The GameData methodmap was added in SourceMod 1.10. Strip all references from the include file to support compilation with older SourceMod versions.

This helps with debugging crashes.

Also update the author list in the extension info.

Some servers (e.g. l4d2) ship an outdated libstdc++.so.6 which lacks the features we need.

We setup a Recall (changing the parameters of the called function from within the hook handler) when a plugin wants to supercede, but never call the function again. This causes a copy of the current context to be pushed, but never properly removed by actually calling the function.

This is wrong, since the original function should be skipped, so don't setup a Recall in SourceHook.

This fixes a long standing issue causing a growth of the internal context stack in SourceHook. This caused very long delays on unhook during iteration of the context stack. Another issue was that the hook result further up the call stack would be misaligned due to the additional unused context pushed in DoRecall.
 Drifter321#2

Use the known-rwx code allocator of SourcePawn like we do for the other code parts of the detour hooking logic.

There seem to be problems with trying to make the C++ heap executable on CentOS 7+, so avoid using executable heap memory in the first place.

Fixes #11
Fixes #22

If the function is optimized to expect some parameter through a register instead of the stack, DHookParam.IsNull might validate the wrong parameter. First we store the stack parameters, then the register parameters in orgParams.

The return buffer wasn't constructed correctly.