Greetings, it's me Bishop here with another fun filled guide to the wonderful world of .dll modding. In today’s episode we will discuss a mod deterrent, the server side check. First off I would like to state that this is a simplified version of how this process works, it is by no means detailed to the point of how the system actually checks these things, and it is just to give you an idea of how the system works. I aware it’s more complicated. Just bear with me. For this little instructional guide we will be using Fireballs section of code, if you don't know what that is, hop on over to epvpers and read Kevs guide. I am not explaining how to do the edit I am just using that section of code as an example. I can't be any more clear. On that note let's begin shall we?
Let's say you’re a provider of a free to play online game and you are having issues with a certain group of bad people editing a particular line of, or sequence of code and you want them to knock it off. What can you do? You could go and make all of the skill context files and .dll's and executables run off of your servers. But this would cause the game to be sluggish and there would be lots of lag and people would hate you and leave and you would stop making money. In short, this is bad, to transfer everything to the server. But, when codes executed and stored in the server, none of those bad people can go in and make this modification that is giving them an unfair advantage. Would if you just put that particular function, or better yet that particular operand call into the server, to make sure that it was executed as intended? Yes, that should work!
If you are not completely new to the modding scene you might have noticed that no matter how many modifications you make to certain sections of code *cough*enchant*cough* nothing ever seems to happen. You don't disconnect, you don't get a weird cryptic error. Everything just works exactly the same as before, it’s as if you didn't just spend all that time modifying the file. What's going on?
What’s happening, in short, is that that particular, vulnerable section of code is in part being executed by the server, rather than on your machine. It's a nice little failsafe put in place by the programmers to make sure the mean nasty modders don't screw up there game. In its most basic incarnation we can think of this check as being 2 tracks of code side by side.
Your .dll->the server’s execution manager
*execute code->*no action
*execute code->*no action
*protected code//execute this on the server -> *executed by server
*protected code->*executed by server//returns value to your .dll
*execute code ->*no action
*execute code ->*no action
And so on and so forth.
By only checking certain vulnerable sections of code and routines you can prevent certain edits from being made while at the same time no impeding the speeds and lagging the game play of your customers.
What's this mean to you, as an aspiring script kitty?
It means that if one of your mods is patched during an update, it's not the end of the world. You may just have to look somewhere else to accomplish the same task.
Let's use the 1 charge fireball edit as an example.
Thanks to the release of the tutorial, everyone now knows how the fireball edit works and can make that simple change of JNB->JNZ or JMP or JB or any other manner of edits that make the code jump to the section that tells it "Ok, you now have enough charges to execute fireball."
But what if there's an update? What if changing that line of code does absolutely nothing? We look for another way. If we are lucky the only line of code that the server is checking is going to be that single operation, that JNB.
So now we need to look for another way to make that edit. Changing that JNB no longer has any impact on game play. Lets' explore the code surrounding it. Right above this JNB is a test. This little line of code checks to see how your current stack compares to the number of needed charges. It looks something like this;
CMP al, 5.
Or in words we should all be able to understand Compare allocated stack to value 5.
That's 1 possible thing we could change. If we edit that to;
CMP al, 1.
We don't even have to change the JNB, because 1 is not below 1. YAY we've bypassed the server check.
But what if that doesn't work either?
This could mean that the entire section of code that tests for comparison AND for the operation is being checked.
This means we will have to look at the code after this section. What happens after the JNB, if the value is less than 5? It moves around some addresses and makes note that you still require charges and them it jumps you right back to the beginning so that the next charge will go through the same process.
After this small section of code we then have the bits and info to be executed if you do have the correct number of charges. Because code executes in a logical progression, moving down continuously until terminated, called or jumped, if we simply eliminate the actions the code is to take in the case we don't have enough charges it will take us to the section of code that allows us to use the spell. We can accomplish this removal by NOP'ing the code after the JNB up until the address that the JNB is referencing. YAY, another successful bypass of the check.
But wait what if the entire block of code is checked up until that JMP that sends you back to the beginning of the code structure? We still have 1 weapon left, we change change the address that the JMP goes to, to the address that the JNB directs us to.
YAY, another way to bypass the server check. ^^
Any questions, comments, criticism? You know how to ask. Hope this was educational and informational.
~Bishop
::No this does not mean OCF is possible anymore... It's just an example used to illustrate a concept.
 |
