VB.Net game security unkillable/kill game.exe when killed.

Question

0.00/5 (No votes)

See more:

I am trying to create a game security process to run in the background as the user plays. The process will basically just be scanning for programs such as cheat engine, injectors, packet sniffers etc.

The problem I ran into is that users can kill the process and be on their cheating way again. Anyone have any good examples of VB.Net code to make the process unkillable until the game.exe is closed? I do not have the game.exe source code or it would be 100x easier.

Someone recommended having 2 processes run, one checking the other constantly and restarting it if it is killed. But I believe there is a more efficient way to do this.

I am mostly interested in something that would kill the game.exe process if the security process is killed.

Posted 28-Oct-13 21:00pm

Pandora's Box

Updated 28-Oct-13 21:01pm

v2

Add a Solution

Comments

Kschuler 29-Oct-13 10:07am

Why not have your game process check periodically if the security one is running, and shut down if it is not?

Pandora's Box 29-Oct-13 12:35pm

And I quote: "I do not have the game.exe source code or it would be 100x easier."

Kschuler 29-Oct-13 13:40pm

Ha. I knew I was missing something.

CHill60 3-Nov-13 12:38pm

If it helps, a rather large company that I worked at recently used the "restart if killed" method on a process. It could occasionally cause performance issues but that was deemed the lesser of two evils :-)

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)