Dynamic detouring library
 

Hey everyone,

I've been researching/working on a dynamic detouring library for the past few months.

Link here. It's windows only for now, until I can get it completely stable.

I've currently got it so someone can actually bind the library to any language they want. All he/she would need to do is inherit from ICallBack and provide an implementation of the required methods.

I've got a test_cdecl.cpp (test_thiscall.cpp coming sometime) on the repo if anyone wants to see some examples.

PS: I actually have this bound to python right now. I've been able to hook member functions of a class and modify their parameters.
PPS: I have no idea why my name switches on the repo, it's probably me being absent minded and forgetting to keep my name consistent across machines :)

Let me know what you guys think (/me looks at BAIL).

Re: Dynamic detouring library
 

Forgive my ignorance, but does this mean you can dynamically call DECLARE_HOOK from a function, instead of having to globally declare it like CDetour?
You still call it globally in your test code, but your sentence about Python implies you can.

Re: Dynamic detouring library
 

DECLARE_HOOK was really a macro I wrote for making my life easier, so it's not a "function".

To answer your question, yes you can hook functions dynamically without hardcoding the prototypes for them. This can be done with any scripting language you can bind DynDetours to :)

You can block the function call and override the return value, or you can modify the parameters of the function and call the original. All dynamically without hardcoding :)

Re: Dynamic detouring library
 

Did I mention I love you?

Re: Dynamic detouring library
 

someone already start making this thing in sourcmod?

Re: Dynamic detouring library
 

I agree with ツツ, I haven't played with sigscanning/detouring yet (it's high on my list), but this library looks very nice.

Good Job =D

Re: Dynamic detouring library
 

generic interop and sourcepawn don't mix. the type system is too weak to do structure/class or pointer interop in any sane way. this is why bug 2616 is basically WONTFIX for now, despite SourceHook being able to generate hooks dynamically.

you're better off finding functions which you need to detour. if none need interop, then exposing dynamic API to scripts can win. otherwise, it's very complicated to get right.

Re: Dynamic detouring library
 

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.

Re: Dynamic detouring library
 

from a cursory look, it does what pRED's structs extension does. lets you describe record types of primitive types.

orpheu does not look type or memory safe, which is not what we're looking for. unfortunately it's very hard to get type and memory safety in Pawn. natives, although verbose, help - GetXFloat() etc can check the requested type and enforces the return type.

memory safety is harder. handles work, but we don't have GC or RAII. if you have an array of structs or a struct that is composed of other structures, you open a ton of handles and then have to manually free them. a single RTE and they all leak. also, direct composition means an inner handle must be bound to the lifetime of the outer. if you don't use handles, you lose the ability to check whether a property exists or even whether it has the correct type.

so what you end up with in Pawn, no matter what, is a verbose api with unpleasing syntax and ultimately limited functionality. we're not ready to resort to that yet.

this is not meant to be a bad rap against orpheu - it's amazing where people are taking pawn given its limitations. on the other hand, the main purpose of our project is software engineering research, and we'd rather create an environment where creative tools like that (and the one in this thread) can flourish without 1980-era restrictions. thus, at the moment, dynamic hooks (virtual or not) are off our table.

i highly encourage playing around with ideas in extensions though. short-term insight into community needs can solve these problems simpler and faster.

Re: Dynamic detouring library
 

Ok fair enough BAIL. It's unfortunate that we have to resort to using x86, but I don't think there is any other way to detour. I couldn't manage to find a single detour library that was "dynamic" in this sense, so I took on the task of writing my own.

On a side note: If you've have any suggestions at all feel free to tell me.

@Tsunami: :)

Anyway, this was really a pet project of mine, and I was surprised I could even get anywhere with it. If anyone wants to use it in an extension, you are free to do so. I'd love to hear what you do with it.

The only problem I've got right now is I haven't even begun to test this on Linux yet

Thanks for the comments so far guys.

EDIT: I've been reading through bug 2616. You've got some great discussion going on there BAIL. It shows that I need to put more thought into how I'm engineering my library.