Hello. I've spent the last weeks working a new module built around a new idea to avoid using signatures.
I've also took the chance to add it features based on the experience with the making of orpheu.
So this module should be more funnier to use but more powerful than orpheu.

The new idea, is about to identify a function, in an easy manner, hopefully resistant to game updates.
It consists on the following notions:

Half-Life functions are an interconnected tree around a core of engine and dll functions.
Each function has a great chance of being connected to the core functions, and for each connection,
there is a minimal length path between the points.
The idea is to identify a function, based on a group of minimal path length between that function and the core functions.
The tree is built with simple parsing of the assembly call instructions (for example, indirect calls are not parsed)
in the libraries, but the results are solid, from my testing. Trees vary a great deal between mod's and operative systems but
for the main purpose of providing a way of identifying a function in a manner resistant to game updates, they seem quite ok.

So let's see an example. Remember that the purpose of this kind of identifier is to resist to game updates, so I will use and old version
of half life dedicated server, against the latest version. This is to see if identifiers for one of them, find the same function on the other and vice-versa.
I don't know if there is a legal way of testing this for an old cs server, but if you know I would like you to tell me.

I had to pick a name for this identifier and I chose "treemap". From now on I will use this name to refer to them.

hlds versions used:
Now I will take a "random" function and use it to exemplify how treemaps work.

This is a function present in the engine library of the old HLDS server:

http://oi59.tinypic.com/2vci89f.jpg

Below, it has this portion that will make easy to identify it, in the other HLDS, to verify that we are dealing with the same function.


http://oi58.tinypic.com/in63o4.jpg


The first step now is to get it's treemap. This is done executing in the console the command:

http://oi60.tinypic.com/dzcpu.jpg

This part:

is the group of minimal distances that our function 0x550F0, takes to each of engine library core functions.

This:

It's the same information, compressed in a string. That is what we will use in plugins.
This string is what I refer to as "treemap".

Now, we will use try to use it as identifier to search it in the new hlds.

http://oi59.tinypic.com/2ibnc6r.jpg

In this image we can see a order list of the function that best match the given treemap.
The wanted case is that the first one is the same function in this hlds version as 0x550F0 is in the old one.

We can verify that it is the case in IDA:


http://oi60.tinypic.com/29qocv5.jpg


Now we can do the inverse:

http://oi61.tinypic.com/aayele.jpg


Now I will exemplify the use of a treemap in CS, with the InstallGameRules functions.
This would be the code to use the treemap, and create and hook the function.

Note that calls to okapi_get_treemap_ptr can take like 1 to 2 seconds, because many calculations are involved but, the results are then cached so
it just takes that time when the server is put on.

I will extend the talk about treemaps on a later ocasion.

Now, to show more of the module, I will continue from the previous code to show how to generically hook virtual functions.

Note that 3 is the offset of the function CHalfLifeMultiplay::FAllowFlashlight in the CHalfLifeMultiplay vtable.

The module supports also searching for signatures with the functions

You can read about those functions and many others in the includes. Everything is sufficiently documented and I believe it's easy to use.

The signatures should look like this:

using the symbol "𐌻", or any value above 0xFF, means that the particular bit is to be skipped from comparisons.

You can hook any function that uses a combination of these types:

that represent: int,CBaseEntity*,float,Vector,entvars_s*,char *,edict_t*,Vector*

The only exceptions is that when the function return a Vector. That is because when the function returns a Vector, a pointer is passed
in the beginning of the stack, so to handle that situation I would have to make a messy code so I prefered to ignore it.
Still, if you really need to hook or use a function that returns a Vector, it can be made with some lines of code using some tricks.

use "int" for long or for any value that you want to ignore.

Other thing present in the module are natives to handle memory directly.
You can use them to change any value in memory and for example to use structures not exposed via an API like playermove_s.

Example of replacing a string that was painful to do with orpheu, now takes one line:

This will change the max value of money a player can hold (note that this is probably not safe to use since there can be values replaced not related to the money)

The module ended up a little big so I will show more stuff about it later.

Notes:

I tested the module alone since I wanted to make it a surprise so I expect it to need some enhancements or have some bugs.
When you use signatures to use functions, after you attach the module to a function, it modifies the bytes of the functions.
That means that if you use the same signature twice, the second will fail. This means that if you use the same signature in two
plugins, it will fail in one. To avoid this you can as an example, just to signature search in plugin_precache and hooking in plugin_init.

Again, I invite you to check the include files, I'm sure you will find there information that you will put to good use.
Also check the server console commands available, within the command okapi.

:twisted:

Originally Posted by yokomo (Post 2097174) //new const SignA[] = {0x3D,0x1C,0xDEF,0xDEF,0xDEF,0x7E,0x1C,0x68} //new const SignB[] = {0x68,0xDEF,0xDEF,0xDEF,0x41,0x68,0x84,0xE9} //new const SignC[] = {0xC7,0x46,0x3C,0x1C,0xDEF,0xDEF,0xDEF,0xEB} public plugin_init() { register_plugin("Okapi Test", "0.0.1", "wbyokomo") //Just testing searching signature, found and no crash. //server_print("SignA: %s", okapi_mod_find_sig(SignA,8) ? "Found":"Not Found") //server_print("SignB: %s", okapi_mod_find_sig(SignB,8) ? "Found":"Not Found") //server_print("SignC: %s", okapi_mod_find_sig(SignC,8) ? "Found":"Not Found") //Patch roundtime, game crash here. okapi_set_ptr_int(RoundtimeMaxCheck, 32400) //max check 0x94163 okapi_set_ptr_int(RoundtimeMaxCvarSet, 540) //max cvar set 0x9416A okapi_set_ptr_int(RoundtimeMaxSet, 32400) //max set 0x9417D } [/PHP]

] version Protocol version 48 Exe version 1.1.2.7/Stdio (cstrike) Exe build: 13:14:12 Aug 29 2013 (6153)

Originally Posted by bibu (Post 2097368) Doesn't this work in listen server?

Originally Posted by DruGzOG (Post 2097379) You mf, I like it. :twisted:

Originally Posted by JusTGo (Post 2097526) nice module; too bad i can use it or undrestand it.

Originally Posted by joaquimandrade (Post 2097206) This step is incorrect PHP Code: okapi_set_ptr_int(RoundtimeMaxCheck, 32400) //max check 0x94163  That's because you are passing an offset, not the actual address you want. You would do PHP Code: okapi_set_ptr_int(okapi_mod_get_offset_ptr(RoundtimeMaxCheck), 32400)  To check if the signature is being searched correctly do: PHP Code: new offset = okapi_mod_get_ptr_offset(okapi_mod_find_sig(SignA,8)) server_print("offset %x^n",offset)  (Notice the name of this function is "the inverse" of the one used before) After you patch the value by using a signature, remember that after map restart, the signature will be searched again, but now will not be found in the same memory location since it was altered. So be sure to check if the result from okapi_mod_find sig is not null, and be sure to confirm that your signature is unique.

Originally Posted by Arkshine (Post 2097772) Otherwise it will break most likely at each update..

Doubt there will be any update anymore

Originally Posted by Arkshine (Post 2097772) There is nothing wrong having extra files, and this is wrong to hardcode things in a plugin. Config file allows to organize and group together static data. Way more easy to maintain and to share. Working with offset directly could be fine if you know you will never update your server, which is probably only for non-steam server. Otherwise it will break most likely at each update, so it may appear more simple but it's just an horrible way.

Anyone already have tried to work with treemaps?

Originally Posted by joaquimandrade (Post 2098196) The reason I decided not to use configuration files is that changing an sma and compiling is very easy and actually makes it faster for someone to: notice that a plugin was updated, updating by replacing files (you just have one file to update), see signatures that are being used in a plugin just by looking at a sma.

Originally Posted by joaquimandrade (Post 2098196) But what Arkshine said about centralizing signatures makes sense. And it can be added to okapi without changing it's way of working just like an extra feature. I may make it one day.

Originally Posted by Arkshine (Post 2118572) You can put the translation, but I think it says basically it doesn't found such function in Kernel32.dll, right ? Do you have win XP or 2003 ?

Originally Posted by Arkshine (Post 2118583) What about this.

Originally Posted by Arkshine (Post 2118610) In s_library.cpp, where it uses GetModuleInformation, I've added : #pragma comment(lib, "Psapi.lib") #pragma comment(lib, "Kernel32.lib") #define PSAPI_VERSION 1 So, it will use Psapi.lib instead. With windows 7, some changes have been done around this function and to keep compatibility with XP, you need to laod Psapi and define PSAPI version to 1.

Originally Posted by Arkshine (Post 2098053) About orpheu signatures, we need someone to create a thread regrouping all known signatures; then it would be more easy to deal with updates and having a more consistent use. But, the problem is all people are lazy or/and busy as hell, ahah.

---


] okapi desc mod 0x550F0

######### OKAPI #########


#########################

---

---

] okapi search "[TG.;nC'.pbG.sXQ.J=g(.;OS'.ueA.1/.*K}.`/F'. 8u{.s9s{.Ohi(.,lm{.s9s{.2/#&.*0J.lE>'.1`}&.-]}&.vMa(.zp='.<cN'.=j12"

######### OKAPI #########


#########################

---

Originally Posted by Bos93 (Post 2215202) meTaLiCroSS, i don't found your signature. Try: PHP Code: 0x83,0xEC,0x0C,0x53,0x57,0x8B,0x7C,0x24,0x1C,0x33,0xDB,0x3B,0xFB

Originally Posted by meTaLiCroSS (Post 2155965) Does it is wrong? It just crashes PHP Code: stock ModCall_PackPlayerItem(iId, iWeaponEnt, bool:bAllAmmo) {     static okapi_func:hPackPlayerItem;     if(!hPackPlayerItem)     {         new iSig[] = { 0x83,0xDEF,0xDEF,0x85,0xDEF,0x89,0xDEF,0xDEF,0xDEF,0x89,0xDEF,0x89,0xDEF,0xDEF,0xDEF,0x89,0xDEF,0x89,0xDEF,0xDEF,0xDEF,0x89 }         hPackPlayerItem = okapi_build_function(okapi_mod_find_sig(iSig, sizeof iSig), /*ret*/arg_void, arg_cbase, arg_cbase, arg_int)     }     okapi_call_ex(hPackPlayerItem, iId, iWeaponEnt, bAllAmmo ? 1 : 0) }  okapi_mod_find_sig returned 0 as from I see

---

83 ? ? 53 57 8B ? ? ? 33 ? 3B

---

Originally Posted by meTaLiCroSS (Post 2154844) Any way to reproduce OrpheuSetParamStructMember? By some way orpheu no longer works on my linux machine, and I don't wanna keep arguing with it and I changed to okapi.

Originally Posted by Arkshine (Post 2216864) I can't find your signature in mp.dll. I don't know what build you're using but for me, signature of packPlayerItem is more: Code: 83 ? ? 53 57 8B ? ? ? 33 ? 3B