Thoughts requested regarding antihack scheme

[PenguinJoe]

Looking for your thoughts on an antihack scheme I have in mind.

Has a few client-side components as well as server side packet forwarder, monitor & authorization processes.

Launcher starts an initiator which contacts a server registration process. Registration process will register (authorize the client's IP address).
Registration process responds with an encrypted list of hacking and packet sniffer programs that the client side monitor uses.

The initiator kicks off the monitor that uses the received memory hacker/sniffer signatures. Monitor polls the the task list for any of these to show up. Meanwhile a subtask is started to respond to gateway heartbeat messages.

Once everything is in place and running, the game client is launched and client connects to the server at a custom port. That port is to a gateway function rather than the 'real' game server process.

The gateway examines the source IP of each packet and matches it to the authorized IP list. If matches the packet is forwarded to the real server's port. If not, the client connection is terminated. The other side of the gateway is the heartbeat function that connects to the client monitor on each registered client. Any that IP fails to connect are removed from the authorized table (effectively blocking that client). The packet check/forwarding requires very little overhead that can be done within a few milliseconds. Likewise responses returning to the clietn from the server can be forwarded on through without even that check since we already know the client is authorized.

The idea is that the server ends up with a simple packet forwarding firewall based on arrival of authorized packets. The authorization is driven by the continued health of the client-side components.

The idea behind all this is that most game hacking required the use of a packet sniffer and/or a process memory editor. If we block the use of these (much the same idea ad behind gameguard), we reduce the tools available to game hackers. It won't stop them all and those that have modified clients to circumvent game restrictions can still get around this (until I put in things like client authenticity verifications), but It seems somewhat better than a lot of the solutions I have seen so far. As well the blacklist of tools can be updated on the server side at any time, without shutting down or restarting and be immediately available for use on the next client to register. The list is not stored on disk at the client in either encrypted or clear format.

Oh, and the client components will be protected from casual decompiling

What do you guys think? Suggestions/critique welcome.

 

[Reqviem]

So, you're saying that the flow should go like this :
Client ---> Clientside gateway ---> Serverside gateway ---> Mapserver.

The only thing keeping players from bypassing the Clientside gateway is the heartbeat. But, what would happen if one more application is added to the flow?
Client --> Clientside gateway ---> Cheating gateway ---> Serverside gateway ---> Mapserver.

The easiest way to abuse a cheating gateway is to allow speedhacking, without any client alterations. However, it can be used to make CheatEngine look like a little boy sniffing glue in terms of accessibility.

The only effective way to implement this scheme is if you encrypt the traffic in the Clientside Gateway and decrypt it in the Serverside Gateway.
Ofcourse, you are forced to use a symmetric encryption algorithm. This either means that you send the key back to the client or you have it hardcoded in the exe.

If you send it back to the client, it can be sniffed.
If it's hardcoded, it can be extracted.

There's no real way to prevent a 3rd party application from becoming the middle man.

P.S. I'm against any type of client side protection. They are eventually bypassed and it just harms the normal player.

 

[PenguinJoe]

The flow is more like
(authenticate) initiator -> serverside registration

clientside monitor <--> serverside gateway (side band)

client <--> serverside gateway <-auth lookup-> mapserver (primary band)

Your point about the client gateway to encrypt the stream is a good one. Key handling is not an issue. There are really creative ways for both sides to generate unique keys for each client without transmitting them over the net or hard coding them. Sure any encryption can be broken. The only question remains will the casual game hacker really have the skill needed to break this? I doubt it.

So let's modify the primary band to this:
client <--> clientside gateway <--> serverside gateway <-auth lookup-> mapserver (primary band)
This now adds an encrypt/decrypt to the packet forwarding.

There is still one weakness in this setup:
The blacklist. All it really takes is to rename the process memory editor to something like skype.exe or firefox.exe and it will run undetected.
If those go into the blacklist, things would get rather dicey - blacklist handling would need to be intelligent - don't throw things in that can cause widespread grief

I guess it comes down to that client side alone is not good enough and server side alone is not good enough. Either one alone can cause widespread mayhem. Perhaps the best solution is one that includes both styles, but is less aggressive than either alone.

 

[Reqviem]

If you implement the server side protection good enough the client side one becomes redundant.

There will always be the case of new exploits being abused that are unpatched by the server side gateway, and that's the only reason for a client side gateway. However, it's time consuming and that time is better spent for actual developing of the game.

But, for the sake of the argument, let's discuss it.
So you have the main traffic, encrypted and secured and you have the side traffic that informs the server that everything is ok or that the user is trying something shady.

That only works until someone actually reverses your encryption algorithm.
Or, they can hide the memory editing tool process, turning your clientside protection useless.
Sanboxing it?
Renaming it?

What would be real funny is to hook the hooking API Windows offers and inform your clientside gateway if something shady is going on.

There's no point in adding too much client side protection to the game. You're better of rewriting the mapserver from scratch to be honest.

 

[PenguinJoe]

Sandboxing the editor would hide it from the monitor, sure, but it would also block it from main system's memory space (sandboxes are in essence a VM partitioned away from the physical system memory space).

Yes, renaming the editor would hide it from the monitor (I think I mentioned that myself) and one of the biggest holes in this.

There's no point in adding too much client side protection to the game. You're better of rewriting the mapserver from scratch to be honest.

That is a good point and one of the things I would consider (set up an open source googlecode project for a Rohan emu) if I saw enough developer interest in Rohan to make it worth the effort of laying down the ground work. At present I do not see much of that.

At present I am a member of the Aion Lightning Reloaded core dev team. A very large part of the work done there can be reused for the core of a Rohan server emulator. I believe the are a few game servers that are based on that emulator core.

 

[HuninHune]

There aren't alot of hacks for Rohan TBH... The forge hack I'm fairly sure I could fix with a server end hook, Speed hack is overrated and even that can be fixed with a hook. the other various hacks can also be hooked.... I'm working on a .ddl loader for Rohan on and off atm to make hooking a bit easier for beginners(and for myself) If I ever finish it I'll release it with some mainserver functions and maybe people can get some poop added to Rohan for once...

Another thing I'm working on is replacing the full packet encryption on Rohan... There are a few packet hacks I developed back on iRohan that are still working and I'd rather they not get found/exploited on pservers also xD

 

[Yurneroo]

I guess I shouldnt say it to often but im done recoding rohan, that means client and server with a modern game engine called Unity3D. Its more like I used rohan as a base though, and created a completly new game out of it.

Req and me once thought about creating an event server, which would simply hook in our antihack gateway, fetching packets and requesting stuff via another map serversided backend which would directly hook into the mapserver.

However, if anyone plans to code an emulator, I highly suggest using Unity3D. You just need to respond to the packets send in a correct way and can go completly custom on the logic itself.

 

[HuninHune]

I guess I shouldnt say it to often but im done recoding rohan, that means client and server with a modern game engine called Unity3D. Its more like I used rohan as a base though, and created a completly new game out of it.

Req and me once thought about creating an event server, which would simply hook in our antihack gateway, fetching packets and requesting stuff via another map serversided backend which would directly hook into the mapserver.

However, if anyone plans to code an emulator, I highly suggest using Unity3D. You just need to respond to the packets send in a correct way and can go completly custom on the logic itself.

I'm thinking you have misspoken here... From what you have put here it sounds like you are saying you completely wrote a Client emulator for rohan using Unity3d... Beyond this being a absurdly complicated project that would take a team of hobbyist coders years to do it would also require a knowledge of the rohan packets so vast that a server emulator would be childs play... You should also understand that a 3d library/engine has no place in server sided programming if you understand it enough to write a full client emulator as you seem to be claiming... It would have also been easier to hook the existing client to add new graphical settings rather then rewriting it to use a new engine...

I'm sorry but until you provide a little more evidence I'm going to have to assume you're not being 100% honest here.

 

[Yurneroo]

I guess I should redo my previous post. I havent said I coded a client EMULATOR nor a server EMULATOR. I neither did recode rohan itself. So much to the facts to be cleared.

What I did, I took rohans complete graphic pipeline, means meshes, animations, effects, skeletons, materials, textures, GUI elements aswell as the whole meta data, means general items, monsters, treasury, npc's, pets, so like most of the usefull meta data bins and converted them to be properly importable and useable by a client and server I WROTE in unity3D. That means a bunch of clientsided and serversided systems. I havent coded any emulator at all, I've coded a completly new client AND server using unity3D, taking the resources and meta data of rohan as a base for a completly new game. It definitly sounds like I'd claiming poop or biting more than I can chew but yea its true. Thing is, coding system in rohan fashion style aint hard. The nice thing is that you can build up many systems in a generic fashion via C# and Unity3D, saving you thousand lines of code. Im aswell currently rewriting several system to be alot more generic and dynamic to sell them on unity's asset store, which by now, btw, I can make a living of. Just ask Reqviem or Ishtaria, both will give you evidence of this. Search the post of ishtaria, you will see two videos of mobs imported into unity3D, animating correctly. That was basically about 1 1/2 years ago. I started about 2 years ago on this project and I've got close to all systems in place. The only things remaining now are more content setup and waiting for unity 5.x.

Im sorry hunin, you have been gone for a good long time period, much has changed. When it comes to me, Im an IT master student, developing with unity for several years now and being an active developer and programmer since I was 12. C# is my weapon and I consider me one of the top three coders, if not even the best coder in the rohan community when it comes to C# and the .net/mono runtime. Furthermore Im a skilled game developer for years now.

To be serious, Im acctually pretty surprised that you didnt know this yet, since most people in the scene do.


/E: Oh and dont speak with me as if I'd be a little child, I know exactly what im talking about. :huh:
/E2: About 3D engines not having their place at serversided backends. Unity3D does have its place as backend. You effectivly can build up a Unity<->Unity networking which will get you rid of lots of headaches since both server and client will behave similar. Just consider physics. Furthermore, when building unity for servers, you specify it to build and run in headless mode stripping the full rendering pipeline.
As of unity networking and database usage, general network handling :

You must be registered to see links

Though, this will be deprecated soon, when unity 5.x arrives which brings a way better integrated networking utility called UNET to unity itself.

 

[HuninHune]

Alright that's a different story but a few notes on that... the client you have as I understand it is just GFX at this point? It's also not really rohan at all it's your own game using the Rohan content so it's a Rohan clone?

And a server emulator would be required to work with the existing client otherwise you're making a clone rather then an emulator... You are wording things a bit strangely.


I'd be interested to see how far your clone has come exactly though, are you just reading the GFX files and rendering the game world at this point or do you have working AI and skills and such? Do you have a Rohan explorer or are you closing in on a full Rohan clone?

 

[Yurneroo]

Alright that's a different story but a few notes on that... the client you have as I understand it is just GFX at this point? It's also not really rohan at all it's your own game using the Rohan content so it's a Rohan clone?

Its not a rohan clone, I rather like to call it rohan 2. >.> The client is not just graphics, It's a fully working client with close to every system implemented (and lots of new stuff), just like inventory, skills, input, battle, chat, way more.
And yea, its pretty much a completly new game but with the feeling and content of rohan. Though, I've been pimping the graphics with normalmapping, lots of details etc. Stuff which gets possible with a modern game engine.

And a server emulator would be required to work with the existing client otherwise you're making a clone rather then an emulator... You are wording things a bit strangely.

Yes and I have never said to have coded an emulator for client and/or server. The client and server I coded via unity are completly standalone and nothing comparable to a emulator. Its simply a completly new game retaining the feel and look of rohan.

I'd be interested to see how far your clone has come exactly though, are you just reading the GFX files and rendering the game world at this point or do you have working AI and skills and such? Do you have a Rohan explorer or are you closing in on a full Rohan clone?

The game is completly standalone. About 2 years ago I reversed the full graphics pipeline of rohan, means .gmf, .grf, .gsf, .gbf, .gaf files and imported the data into unity, creating the acctual meshes, materials, skeletons, animations in the unity formats. That means infact that the data is stored right in unity and im not reading out any of the rohan files at runtime. The terrains are btw developed by aries, he's handpainting all of them and they look just duck awesome.
Just to name it again, I've written importers for various stuff so I do not use any of rohans files at runtime nor at edittime. The data is imported into unity once and thats it, thats what im working with.

As of how far the project is, review my or ishs posts. Im done with close to every system. That includes skills and AI's, yes, aswell as combat, item handling like forging, crafting, gathering. Movement and general optimizations. If I'd name every system currently implemented, I'd still be writing this post tomorrow.
But like I said, the systems are in place, just the content is missing. Take skills as an example, I've written a generic skill system plus editor with which I can create close to any skill. Just the content of the skills is missing. Means, I did some beta skills and tested them plus the system but havnt yet set up the acctual final skills. Though, setting up the skills wont take longer than a day or two. Thats the power of unity, ultra editor extendability which makes workflow a breeze.

Oh and dont call it clone!

 

[HuninHune]

Oh and dont call it clone!

You must be registered to see links

is to

You must be registered to see links

as
Your Rohan is to Rohan.

By definition it's a clone I'm not saying that as a bad thing, I love clones. It's absolutely not Rohan 2 If you're using the existing Rohan as a base. It's more like Rohan+.

I understand the power of engines btw xD I've done alot of work on my own game using Hero Engine(imo a better engine then Unity)

You must be registered to see links

<3 the collaborative editing



PS: I wasn't saying you coded an emulator I'm saying unity wouldn't work FOR coding an emulator

 

[Yurneroo]

Well, I'd really call it rohan2 instead. Theres simply stuff in my version, which aint used in the common rohan. The looks are up to date, not to mention that we added two new maps, new buildings, we even going to implement halflings down the road. Though, thats content for post post post release. ;D
Well yea, we aswell do have the basic modell for r6 set up.

As of hero engine, I dont want to start a war here, but hero engine is by far not even 1% a challange to unity. The engine is pretty basic and just simply doesnt carry the possibilties which come with unity. Together with UE4, unity is the leading engine for making games on any modern platform. As of team servers, you can connect unity instances via cloud and other similar tools/methods. Not to step on anyone's feeds now since choice of engine is definitly something we could discuss forever about. XD


And contrary to what you said about unity not being able to be used as emulator. I tell you it is. The antihack I've coded together with reqviem is pretty much just a C# gateway which receives packets and dispatches them to the mapserver. The same theory can be applied to a unity emulator. Let the unity mapserver receive sockets on port xy which will effectivly be your client connection. Just parse the packets corretly (which will be lots of reversing work) and implement your own logic. I just dont see a reason why unity wouldnt be suited for an emulator.

 

[HuninHune]

As of hero engine, I dont want to start a war here, but hero engine is by far not even 1% a challange to unity. The engine is pretty basic and just simply doesnt carry the possibilties which come with unity. Together with UE4, unity is the leading engine for making games on any modern platform. As of team servers, you can connect unity instances via cloud and other similar tools/methods. Not to step on anyone's feeds now since choice of engine is definitly something we could discuss forever about. XD

Games developed using HeroEngine

Released

• You must be registered to see links
  (2011) -
  You must be registered to see links
• You must be registered to see links
  (2011) -
  You must be registered to see links
  [SUP]
  You must be registered to see links
  [/SUP]
• You must be registered to see links
  (2014) -
  You must be registered to see links

Just saying I don't see many AAA titles coming out using Unity3D where even just wikipedia has 2 very big games listed with Hero

 

[ParraStudios]

Best solution for client side is making a driver, avoiding hooks or calls to winapi in a low level.

This can be also bypassed as memory / process heuristic analisis (another solution).

The most difficult to bypass is server side security, for example, taking care about intervals, packet integrity, user behavior.

Solutions as encryptation are not valid. This is just for password for example, because of some Internet laws about information protection.

Hacker can do what he/she want in client side.

 

[Yurneroo]

Just parts of the available unity games, with lots of known titles aswell.

You must be registered to see links

You must be registered to see links

You must be registered to see links

You must be registered to see links

Aginst Hero engine:

You must be registered to see links

You must be registered to see links

There might be more but im not able to find it.


Furthermore
Hero
Quote : "SWTOR success helps HeroEngine surpass 5,000 licensees"

Unity
2.9M Registered developers
630K Monthly active developers
400M Total Web Player Installs
10.7M Editor Sessions May


But like I said, game engines are somewhat subject of personal choice. We could discuss about it for ages.
Just again, Im sure with the system I got in place I could write an sever emulator within unity in no time as long as I get a list of sorted, reversed packets and packet branches. Considering You, Requviem and me could get something like this work in no time, especially since my game server already has so much reuseable parts implemented.

 

[HuninHune]

Furthermore
Hero
Quote : "SWTOR success helps HeroEngine surpass 5,000 licensees"

Unity
2.9M Registered developers
630K Monthly active developers
400M Total Web Player Installs
10.7M Editor Sessions May

Unity full version costs $1500 vs Hero engine costing $75,000 and 7% profit share so it's understandable that less would use it as it's directed twards AAA companies rather then indies... Though they now have an indie license where they offer to cover all hosting and payment processing for you..

I'm a firm believer in you get what you pay for btw but yeah that's off topic

But like I said, game engines are somewhat subject of personal choice. We could discuss about it for ages.
Just again, Im sure with the system I got in place I could write an sever emulator within unity in no time as long as I get a list of sorted, reversed packets and packet branches. Considering You, Requviem and me could get something like this work in no time, especially since my game server already has so much reuseable parts implemented.

It's an interesting project I'd love to give a hand at it and see where it goes


EDIT : Especially if it can be built on Linux

 

[Yurneroo]

Unity full version costs $1500

For companies with a turnover of less then 100k a year. Infact, this license is an indie license.

Hero engine costing $75,000 and 7% profit share

And thats why I can only find 2 titles.

I'm a firm believer in you get what you pay for btw but yeah that's off topic

I infact believe that 75k and !7% CUT! aint worth hero engine.

It's an interesting project I'd love to give a hand at it and see where it goes
EDIT : Especially if it can be built on Linux

Yep, unity can be build for any modern platform, so unix systems included. It's definitly an interesting idea. But I guess, it'll be more like I'd step back a bit since time is money and I dont really have both of it.