Avoiding the user to start the game through the client

[tnrh1]

Hi guys.
I ran into this challenge before and I still don't have a solution so I want to know if someone found a way to do that.
The launcher provides many security checks for the server but he is totally useless if the user can start the game through the game.exe

Is it possible to identify who opened the exe?if it's a program or normally opened?

 

[rxaicy]

yes..game.exe will send a checksum by some protocols,you can try to login my server whatever game.exe except mine you use..you must be dc. but if you know what protocols send this and nop it,the server will not accept it,and then you can use yours which can be changed by yourself..so firstly my friend,you should check the game send this protocol if or not in your server side,secondly,you had better change some protocols like rpt,he cannot use other games to play normally. i use these methods to prevent hackers ,to insure unique game.exe,and so on...

 

[bobsobol]

That's no the point rxaicy. What if I launch your, unedited game.exe, without going through the launcher? Will I disconnect then?

Many Western (yea, I know, Israel is not very far west, unless you live in Asia) clients can only be secured against hackers by hooking protection and monitoring code into the launcher. So, the Launcher acts as a watchdog, like your Anti-Virus, and watches over game.exe when it launches it, to ensure that no other process injects, or attaches to it after it's launched.

This is what most devs need.

The answer is that you write into *your* game.exe code to look for *your* watchdog injections. If they are not present, or neutered in any way, you jmp to DC code.

Your client is secured by server-side checksums and the launcher, the launcher is secured by the game.exe, and the server is secured by the launcher and the checksums. Anything wrong in that setup and the player will DC.

 

[SheenBR]

What about those "PLAY" buttons inside the website, that somehow can launch the game? And you cant run the game.exe directly, just from the website. how do they do that?

 

[bobsobol]

Those "Play" buttons take me to a login / signup page which, when completed take me to the download page... nothing more.

No webpage can start a program installed on your computer unless you allow insecure plugins. (Microsoft have had several insecure ActiveX plugins in the past, because of the way they tie Internet Explorer into their OS Help system... but it should be disabled now)

 

[rxaicy]

Yes. I absolutely agree with u, bob,i use CRC checksum to check all of the codes of the game.exe.so anywhere you changed , you will DC by server,exe.

 

[tnrh1]

Can you think on an average solution by Launcher side ONLY? well doing all those checks is easy for me in java and almost impossible in assembly.
By saying average I mean less secured, well everything I came up with seems to be too easy to crack.

 

[SheenBR]

I guess its simple. Take the packet 484700E4 which is responsible for sending the game chhecksum to the server. if it is wrong u got disconnected. but if you remove that packet from the client, server will never disconnect you. but u can do this: when server parses the E4 packet, set a flag for the user, like: passedChecksum = 1.

Then, in another place, I suggest the routine that handles 48470013 packet, you check if that flag is 1. if it is not, then disconnect the player.

I know it is easier to say than to make, but the theory is there ( I suppose it is safe ), now it is up to you or anyone who might want to test it and release to the public. :

 

[Vormav]

DRM like security will always fail. Move some coded from game.exe to launcher or make game.exe a launcher.

 

[bobsobol]

DRM like security will always fail. Move some coded from game.exe to launcher or make game.exe a launcher.

Yea... not a Java one though.

I have never used game launchers for any game I can get away with it. They always mess with my carefully hand crafted registry keys and config text files, or download updates I didn't want to implement. XD

There aren't many games I can't bypass the launcher on, and those that there are usually only block me from the server when I don't do the auto-update. (version check fails)

You are *never* going to force people to use your launcher unless you do it in game.exe, or by server firewall.

The latter you could use in your Java launcher. Here's how:-

1. Set all IPs on your client port blocked in the server firewall, bar exceptions.
2. Run a listener on an open port, looking for launcher authentication packets.
3. Have the launcher send a salted, time sensitive encrypted authentication packet before game.exe tries to connect.
4. If the packet is valid, the listener should set an exclusion for the sending IP on the regular client port, for a limited time only.
5. Launcher runs in the background and requests a re-auth if the time limit runs out and the player is still playing.

No Launcher, not port auth packet. No port auth packet, no open port for you.

Never mind DC, you can't connect in the first place.

Spoiler

I don't think you can obfuscate Java enough to keep your packet encryption secure though.

 

[rxaicy]

I guess its simple. Take the packet 484700E4 which is responsible for sending the game chhecksum to the server. if it is wrong u got disconnected. but if you remove that packet from the client, server will never disconnect you. but u can do this: when server parses the E4 packet, set a flag for the user, like: passedChecksum = 1.

Then, in another place, I suggest the routine that handles 48470013 packet, you check if that flag is 1. if it is not, then disconnect the player.

I know it is easier to say than to make, but the theory is there ( I suppose it is safe ), now it is up to you or anyone who might want to test it and release to the public. :

bro remember that game just send packet 484700e4 one time

 

[tnrh1]

Bobsobol that sounds good but what if I start the launcher and play as you said and in that time while the game is running I'm trying to open the game.exe? I will be able to log directly from it.

 

[SheenBR]

bro remember that game just send packet 484700e4 one time

it doesnt matter... you can add a magic number inside E4 packet that only your client knows, and use that value to set the flag's value :

 

[rxaicy]

it doesnt matter... you can add a magic number inside E4 packet that only your client knows, and use that value to set the flag's value :

i mean if you hack the game after it sensed the packet. How can you deal with it?

 

[bobsobol]

Bobsobol that sounds good but what if I start the launcher and play as you said and in that time while the game is running I'm trying to open the game.exe? I will be able to log directly from it.

Yes. Obviously, if your launcher doesn't disable process launching it's not a secure launcher and I wouldn't have bothered writing it. I performed global hooks to prevent the creation of new processes in mine, because there's no point scanning active processes if a new one can begin that you haven't scanned.

The longer your time window for the open port, the more chance you could quit the secure game and start a fresh insecure one using the open port... but it will be DC once the time window closes. So it's not perfect, but it's a lot safer. Additionally, if you are within a NAT, you can get the port open by securing a dummy PC behind the NAT, and cheating on an insecure one. From your servers point of view, they both have the same IP. You may be able to secure that by keeping the packet encryption out of the client and injecting it to the client from the launcher. Particularly if the launcher doesn't know it, but it's included in an acknowledgement packet from your auth server.

Again, if I can decompile your Java launcher, I can write my own insecure one, and there is no way to obfuscate Java binaries sufficiently to prevent that. That's the nature of Java, and considered a positive feature. You cannot "hide" malicious code in Java programs. They can always be decompiled and analysed by experts to prove they are safe... which means they can always be decompiled by experts and neutered so they are not safe. ^_^

i mean if you hack the game after it sensed the packet. How can you deal with it?

Via your launcher. Which goes back to the core question of this topic. The launcher scans existing processes for potential threats, and prevents malicious processes starting up... so how do you stop the client being started while the launcher isn't nannying the system. ^_^

 

[tnrh1]

This topic is so annoying!
A lot of times when I surf in the internet some temp files are downloaded to my temp local folder so what about downloading the client each time the player clicks play to the temp folder and delete it after he quits?well no one will know that the client is there unless he sees this topic xD
If the file couldn't be copied that would be perfect! but you can't just mark "can't be copied" since it's impossible so I'm trying to think about a different way to do that.
A funny answer that I saw around is creating a file that uses up more than 50% of the total space on that machine and that is not compressible but that would be horrible downloading such a file over and over.

Maybe causing this error by force will do the job:

 

[bobsobol]

No no no... horrible.

You can download just the client into the memory from the server. That's fine.

You could even have the client executable be nothing but empty memory space and a downloader which fills that memory from the net. But you'd have to do it in something which interfaces directly with the Win32 API. ^_^ (ie. Not Java XD)

 

[botjam]

I guess this topic points to some servers that are using mpt clients with admin.exe or admin3a.exe by gzuz.. they use the released launcher source which points the the xtrap address to the main xtrap server and upadates the it automatically but unfortunately, players could launch the game by using only the game.exe/admin.exe..

Is there anyway to reassemble the Xtrap in the mpt game.exe/admin.exe? Or anyone could point the address to which we should assemble it?

 

[bobsobol]

It doesn't "point to" such servers at all. That's off topic. The topic of this thread is how Imri should protect his game.exe against his Java based launcher without going into assembler at all. (if possible)

If that's an honest question, it's fine, but it's not what this thread is about IMHO.

 

[SheenBR]

One solution is command parameters... But they are tricky. You should make your launcher identify the game.exe, otherwise I could simply write an app to print the command parameters and then I would know how to launch your game directly.

Create somekind of checksum of your game and then compare it in your launcher. I can't find a better solution to this... at least not as simple as this one