[Geesu]

HOLY CRAP!!! YAYA!!!

So can you explain why it's possible to hook virtual functions and not non-virtual functions?

[BAILOPAN]

it's not impossible, it's just not as easy. virtual functions are mapped in a nice table you can just edit.

[Geesu]

SO basically all that confusing code that lance/EKS has been posting looks in the vtable, and changes what function it points to?

So you're just intercepting it, and then you can forward it back to the original function pointer after you've changed the values?

Were there not many virtuals in HL1?

[XAD]

Originally Posted by Geesu SO basically all that confusing code that lance/EKS has been posting looks in the vtable, and changes what function it points to? So you're just intercepting it, and then you can forward it back to the original function pointer after you've changed the values? Were there not many virtuals in HL1?

Yepp... or blocking it...

What I know about HL1 there are no interfaces with virtual functions, thats why MetaMod had to be acting as the mod to have all calls sent through it... in HL2 we just "hook" the functions we want (so you can even make "hooks" online).

BUT remember it's get really uggly if you have more than one unloadable plugin using hooks as you can't just set it back when unloading as you don't know if you hooked the original function or another plugins hook (which might have been unloaded since your plugin made it's hook).
My suggestion is to use one MAIN plugin be the hook-manager and then lets the other plugins call this plugins functions or have something such as SourceMod doing it).

/X

PS! You can also check my version, if you think it's less confusing, but they do the same thing (and it was vancelorgin who gave me the idea, credits to him)...

[PM]

SourceMod will actually act as a sort of metamod, yes. The hooking will be function-based. More on this when it's done

I am trying not to use asm or VirtualProtect/mprotect here.

[vancelorgin]

Good luck avoiding memory protection... And the confusing code I pasted lets you get around having to write up an annoying and unweildy proxy class (try that crap for baseent :/), especially if you don't have the full class definition (engine.dll shit).

Pasted from a reply that I fell asleep typing yesterday:

When virtual funcs are called their address is looked up in a table, which both lets you find out its address insanely easily (just read the table) and hook them equally insanely easily (just write to the table). To find non virtual function, you have to be more creative (I use a signature scanner which scans the server module's code section for a sequence of bytes [the opcodes of the func with the static addresses that change per compile masked out]). To hook a non virtual function, you pretty much have to patch it (drx hooking is a bit unnecessary here). If you patch a function, you have complete control over it. I'll probably post my old detour class [which currently only works on windows, but thats *ONLY* because of VirtualProtect and stdcall support] later. This class will let you hook anything ever (TM). It's on my other site >)

A horribly notable exception here is exports / imports - you have the address of those with 1 function call, and can hook them by just modifying some other slightly harder to access tables (I know the PE format like the back of my hand, but elves are still foreign to me ).

[PM]

The thing I have is only for virtual functions.
Avoiding VirtualProtect on Windows seems to be pretty easy: I allocate my own vtable, put the function pointers I need in there, and then assign the vtable to the interface pointer.

[XAD]

Originally Posted by PM The thing I have is only for virtual functions. Avoiding VirtualProtect on Windows seems to be pretty easy: I allocate my own vtable, put the function pointers I need in there, and then assign the vtable to the interface pointer.

Ouch... and you of course will instantiate the "real" class and not the interface class then I hope... The problem with creating your copy is that valve can changes the classes private section (which also can be virtual) without notice you and then you get some real strange problems.

Also you get a problem when the extend the current interface classes...
For ex. in the last update they added a lot of new functions to the IPlayerInfo class and one to IPlayerInfoManager. Changing the function pointers in the virtual table for these didn't cause me any problem in my plugin but IF I would have instantiated my own vtable and replaced it then any mods or plugins using the new virtual functions would probably have crashed my server as the mod and the other dll/so would have expected the new functions to be in the vtable (but I can't allocate until I recompile with the new code) ...

Please do not make such a vulnarably implementation in SourceMod, as it will cause the same problem as we had with MetaMod and the update for CS:CZ/Steam which made all mods non-functionally, BUT with the difference that it will happen more often now when Valve has Steam...

/X

[BAILOPAN]

The real problem is, as I said they would earlier (but no one listened to me), is that Valve isn't complying with their own APIs.

IPlayerManagerInfo001 in HL2DM and 002 in CS:S. It's already happening, and they don't even respond to my inquery on hlcoders. Is it really our fault if Valve is going to change things and then not recompile their stuff?

[PM]

You have a very good point there, indeed.
I'm not so worried about Valve changing the public interfaces, because they then also change the interface version which forces us to recompile anyway.

The other thing about virtual functions that are hidden from us seems to be more important. If I won't find any workaround, I'll probably end up using VirtualProtect too ^^ (that's probably also what lance wanted to say but I have misunderstood him). Thanks for pointing this out, XAD.