Launcher

Quote:

---

You have done what no other security team has ever managed 100% to achieve

---

I havn't done it yet, but hopefully I will manage it work.

And I think you got me wrong, I didn't block every single edit program, I got a black list which include programs names.
If one of them is in the memory the game won't start.
But even disabling the option to use Olly and Hex is a big progress.

About the "checking if the launcher.exe is in the memory", the client will be able to log in through the launcher as he should, then the game.exe and the launcher.exe are on the memory so if he tries to log in again through the client it will work which is bad.
The only way I've found to prevent it is to check if the game.exe is on the memory also and if it does, don't open the game.exe .
It has a disadvantage since you can't log in through 2 chars.

I can't even theoretically find a way!!!

Well, if you used the idea of passing a parameter to game.exe as Sandurr once did, and I suggested to earlier, this would work fine. I would also quit the Launcher once game.exe is running, but maybe you have background stuff you want it to keep doing.

However, there is a more advanced and "correct" method to achieve what you are looking for, known as a Mutex object. ^_^ (Mutual Exclusion)

We usually use a Mutex to ensure that only 1 copy of our program is run at once. For example, you don't want to run 15 copies of Outlook at once, who knows which one incoming mail will drop into!? XD

Code:

---

WINAPI WinMain(
  HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
  try {
    // Try to open the mutex.
    HANDLE hMutex = OpenMutex(
      MUTEX_ALL_ACCESS, 0, "MyApp1.0");

    if (!hMutex)
      // Mutex doesn’t exist. This is
      // the first instance so create
      // the mutex.
      hMutex =
        CreateMutex(0, 0, "MyApp1.0");
    else
      // The mutex exists so this is the
      // the second instance so return.
      return 0;

    RealMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow)

    // The app is closing so release
    // the mutex.
    ReleaseMutex(hMutex);
  }
  catch (Exception &exception) {
    Application->
      ShowException(&exception);
  }
  return 0;
}

---

Each Mutex has a "name" which is a plain string.

I suggest you pass a random, or unique string which the launcher has managed to create a Mutex for to game.exe as a parameter. game.exe should quit if no parameter was passed, or if there is no Mutex by that name on the system. The launcher will have to release the Mutex only when game.exe is running well and has initialised. (I suggest waiting for the window to be present in the systems window list, unless you don't quit the launcher till game.exe quits)

Because the Mutex is given a random name (and if the launcher can't lock the Mutex by the name it picks it will have to keep trying another name till it can get a lock, and before passing a Mutex name to game.exe) you can have as many copies of game.exe running as you like, and each will have their own Mutex.

--- EDIT ---
You can also have game.exe keep checking that the Mutex is still held open. If your launcher crashes, Windows should (I believe) release the Mutex automatically. ^_^ Otherwise, if Outlook crashed, you'd have to reboot your PC to get at your mail and calendars again. :(:

This is really nice, that would be a part of the solution.
The solution I thought about is like this:

Everyone are blocked and can't log in (ranging all the ip's).
If you'll try to log in from the game.exe of course you won't be able cause your ip is banned.
If you'll log from the launcher, the launcher will send your ip into the server (another exe that will run on the server) and the server will add you to the allowed list.
While the launcher is running your ip is on the allowed list.
Closing the launcher while the game.exe is opened will print an error box.
Now to the more complex part:
To avoid people to log from the game.exe after the launcher is running,
the launcher will save the game.exe process id in a list.
It will check every x seconds if there is another process of the game.exe with an id that isn't on the list, if true it'll close it.

Before I start to program it, I want to know if you think that there is a way to bypass this system.

Quote:

---

Originally Posted by tnrh1

Before I start to program it, I want to know if you think that there is a way to bypass this system.

---

I have to think carefully about answering this impartially. I think the best thing is to point out my bias right from the start.

First of all, I don't know if I mentioned it in other posts, or just private chats, but I always thought that banning all IPs until their launcher / modified client authenticates was a good idea. Don't just fail to recognise the packets / encoding, don't even give them to the server. Those I posed the idea too seemed vastly under-impressed with it though. I hope your attempt there can vindicate the notion.

What I'm not so keen on is limiting players to one copy of the client. I had to think carefully about why that should worry me as much as it does. These are the answers I came up with.

Primarily, many early MMOs placed sanctions on "boxing" (one player using multiple clients to play more than one character at a time) and I know for a fact that Sonys' EverQuest servers still have this in their TOS. When the original EQ was bigger than 2nd Life or WoW (because they hadn't been released yet XD) they where really hot on enforcing that but ultimately found they where fighting a loosing battle. (like Blizzard with players selling in-game gold)

I think the reason you can't win this fight is simple. You don't want to ban families (siblings, lovers, partners etc) joining in the fun from the same home. Most homes, at least where I live, rent only 1 IP from their ISP and connect from multiple systems from behind a NAT. They have the same IP, so they look like 1 machine. But "pro-gamers" will run more than 1 PC and just work multiple keyboards and mice / or macro with custom hardware input devices. (hardware automouse / KVM / programmable gaming keyboard etc.) The motherboard doesn't know an autoclick mouse / autofire gamepad from a steady hand, and there is no software install needed, so how can you stop it?

I think you mentioned above that it was a "disadvantage" to limit players to only one client. They will rebel, and try to find ways around this. I don't want them to be curious to break draconian security... I want legal players happy to run the game without tricks, so regular players aren't encouraging and helping cheats. :wink:

Now... to your idea, and means of breaking it, neutering it's functionality, or even causing problems for your server:-

• What happens if I start the launcher on one PC behind my NAT and run the game alone on another, with cheats?
• What happens if I run the launcher in a VM on my PC and cheat on the host without the launcher?
• What happens if I run the game from the launcher and park that toon in town, then copy the client with a different name (it's not in the task list as game.exe) and cheat that one?
• What happens when I pull the power cord on my PC when I'm in game... Can I reboot, and run the game without the launcher then?
• Can I kill the launcher with Task Manager, or an equally powerful program / replacement?
• What if I kill the task from a program run on another machine on my LAN... maybe my phone? (a decent smartphone can connect to Windows Admin shares and services, list and kill tasks on a remote machine with the local Administrators password ^_^)
• What if I don't even kill the launcher task... what if I suspend it and all associated threads?

I think some of these can be dealt with. (launcher needs to poll to hold that IP open :wink:) Most will be quite problematic, and because there are a few that I can't see any way of avoiding... I suspect that will make attempting the others impractical. :(:

I'd still encourage you (if you have the time and are still willing) to try... see how many you can stop etc. Just so you really understand the extent of the problem. But... if you can see, just from the list how impractical some of the possibilities are to defend against... you can save yourself some effort, and look at it a different way.

How? What if the client (game.exe) was making sure that the Launcher is there looking after the system for it rather then the launcher checking the client?

• Doesn't matter what it's called.
• game.exe not seeing the launcher running on another system on the same NAT is now an advantage, not a disadvantage.
• The client can't be suspended while you play, and can be programmed to quit if the launcher doesn't check in with it every so often. ^_^
• You can safely allow multiple client instances on the same system. (you may want to be careful about how though)

That would be my view. Maybe you can think of others?

Quote:

---

I think the reason you can't win this fight is simple. You don't want to ban families (siblings, lovers, partners etc) joining in the fun from the same home. Most homes, at least where I live, rent only 1 IP from their ISP and connect from multiple systems from behind a NAT. They have the same IP, so they look like 1 machine. But "pro-gamers" will run more than 1 PC and just work multiple keyboards and mice / or macro with custom hardware input devices. (hardware automouse / KVM / programmable gaming keyboard etc.) The motherboard doesn't know an autoclick mouse / autofire gamepad from a steady hand, and there is no software install needed, so how can you stop it?

I think you mentioned above that it was a "disadvantage" to limit players to only one client. They will rebel, and try to find ways around this. I don't want them to be curious to break draconian security... I want legal players happy to run the game without tricks, so regular players aren't encouraging and helping cheats.

---

I definitely agree with you, I think you got me wrong.
You won't be able to run more then 1 launcher, but from the launcher you'll be able to open many clients.

Quote:

---

What happens if I start the launcher on one PC behind my NAT and run the game alone on another, with cheats?

---

What do you mean by "behinde the net", but anyway if you start a client not from the launcher, the launcher will see that this process id is not on the "process id's list" that generated by the launcher and it will shut it down.

Quote:

---

What happens if I run the launcher in a VM on my PC and cheat on the host without the launcher?

---

Good point :glare:

Quote:

---

What happens if I run the game from the launcher and park that toon in town, then copy the client with a different name (it's not in the task list as game.exe) and cheat that one?

---

I thought about it, searching the process by name is a big problem, do you have another way to identify the client in the process list?

Quote:

---

What happens when I pull the power cord on my PC when I'm in game... Can I reboot, and run the game without the launcher then?

---

Another good point, but I can think about a solution, something like the server side launcher/exe will check every x time if all the allowed list ip's are connected to the host and if not, it will remove them from the list.

Quote:

---

Can I kill the launcher with Task Manager, or an equally powerful program / replacement?

---

Kill it, you are banned without it.

Quote:

---

What if I kill the task from a program run on another machine on my LAN... maybe my phone? (a decent smartphone can connect to Windows Admin shares and services, list and kill tasks on a remote machine with the local Administrators password ^_^)

---

Same answer, kill it.. you'll be banned.

Quote:

---

What if I don't even kill the launcher task... what if I suspend it and all associated threads?

---

Is it possible?:O::O::O:

Quote:

---

How? What if the client (game.exe) was making sure that the Launcher is there looking after the system for it rather then the launcher checking the client?

---

Making all the security system through the launcher theoretically is easy, but when it comes to write it in assemly it's almost impossible.. atleast for me.

If sandur could share with us in few words how his system works that could save me some hours :thumbup1:

Anyway thank you bobsbol for your constructive criticism.

Quote:

---

Originally Posted by tnrh1

I definitely agree with you, I think you got me wrong.
You won't be able to run more then 1 launcher, but from the launcher you'll be able to open many clients.

---

This sounds interesting but I smell security flaw.

Quote:

---

Originally Posted by tnrh1

Quote:

---

What happens if I run the launcher in a VM on my PC and cheat on the host without the launcher?

---

Good point :glare:

---

Block VM too? ;)

Quote:

---

Originally Posted by tnrh1

I thought about it, searching the process by name is a big problem, do you have another way to identify the client in the process list?

---

Learn from "Trojan Horse" tale "bug", check what's inside :)

Quote:

---

Originally Posted by tnrh1

Another good point, but I can think about a solution, something like the server side launcher/exe will check every x time if all the allowed list ip's are connected to the host and if not, it will remove them from the list.

---

What if I write .dll/app that will send check every x time to your server?

Quote:

---

Originally Posted by tnrh1

Kill it, you are banned without it.


Same answer, kill it.. you'll be banned.

---

What if I block it? Using windows software restriction policy or any app like that

Quote:

---

Originally Posted by tnrh1

Quote:

---

What if I don't even kill the launcher task... what if I suspend it and all associated threads?

---

Is it possible?:O::O::O:

---

Any "enhanced" task manager can do this.

Quote:

---

Originally Posted by tnrh1

If sandur could share with us in few words how his system works that could save me some hours :thumbup1:

---

Fighting with hackers is like fighting with the wind, you don't see them but they can "blow" your server away ;)
I think he had exactly same problem as others. Sure he probably where blocking faster and more cost effectively then others but still same problem exists... PT was never designed to be huge MMO.
There are still "moral" problems, on "some" official servers, you will not get permanent ban if you buy lot of cash shop items. Nobody would cut off hand that feed you.
Lesson: Even if your security is 100% flawless people will brake it with money :)

And there is also "brute force" method ;)

http://www.howtogeek.com/wp-content/...0/image339.png

Good luck with launcher because 1% security is always better than 0% and uncle google will not teach those kids how to "hack" & slash :)

I'm getting tired..
I think an exe that will check every x time for certain lines in the log file and ban them is the best solution.

Quote:

---

Originally Posted by tnrh1

What do you mean by "behinde the net", but anyway if you start a client not from the launcher, the launcher will see that this process id is not on the "process id's list" that generated by the launcher and it will shut it down.

---

Behind the NAT, not "net". NAT = Network Address Translation. On a different PC with the same IP. (that's what a NAT does. Usually provided by domestic router or VM) The processes are not hosted on the same PC so without the other PCs Administrative or Domain Admin password and comprehensive Windows network administration programming, the launcher cannot see the process list which houses the renegade. :wink:

Quote:

---

Originally Posted by tnrh1

I thought about it, searching the process by name is a big problem, do you have another way to identify the client in the process list?

---

Don't ever search on image name, it's too easy to change. Search on Window Title? Make sure the code that creates the window and titles it is well obscured, and look out for anything trying to patch or inject into the window creation code, or modify it's structure after the fact. (very easily done with AutoIt or AHK) Scan and checksum key addresses in each process is the only sure way.

Quote:

---

Originally Posted by tnrh1

Is it possible?:O::O::O:

---

It's common practice. I didn't realise it wasn't part of the standard Task Manager until I just tried. I'm just so used to it being there. Even many MacOS "Dock" clones or other "Taskbar replacements" implement it.

Quote:

---

Originally Posted by tnrh1

Making all the security system through the launcher theoretically is easy, but when it comes to write it in assemly it's almost impossible.. atleast for me.

---

Yes, I like that about your idea. Actually all you need to write in assembler is a thread which polls checking it's received a message (message queueing, TCP/IP on localhost, named pipe or even an actual file) from the Launcher on a regular basis. Try writing the system time in an encrypted form to a file named after the PID of the game.exe you are "watching" and get game.exe to read, decrypt it, confirm it's after the last check and before "now", then delete the file and if it's not, TerminateProcess() the client.

Quote:

---

Originally Posted by tnrh1

Anyway thank you bobsbol for your constructive criticism.

---

You're welcome

Quote:

---

Originally Posted by tnrh1

I'm getting tired..
I think an exe that will check every x time for certain lines in the log file and ban them is the best solution.

---

I think that is where most people get to.

Well, I've mentioned a security launcher I made a long time ago for another server. They don't exist now, and haven't really used it because of the Ring-0 code which needs signing to work on NT6. (Vista+) I may see if I can clean their branding out of it and release the source for people to study.

The idea was that it temporarily "broke" the Windows filesystem, making all executable files "invalid" with a "filter driver", scanned the task list for potentially dangerous programs and killed them before starting the game. (yes, it was checking "image name" too... and even then I knew, as you do, that that's not ideal)

If you managed to "kill" it from another machine, the filesystem would remain "broken" until you rebooted. XD

It does limit you to one client per-machine, but not specifically one per IP.