Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Server Sends Check To Client Tutorial
#1
Alright, since I have often wondered about the potential dangers of people connecting with a different client to my game to hack it, I decided to come up with a way for the server to check whether the player was using a proper client.

Basically, what this does is sends a packet & a string to the client as an 'acknowledgment' packet and a string attached to it, to make sure the client isn't just sending back a wrong 'received' packet.

The server gives the client 15 seconds to reply (15 seconds for reasons such as lag, slower computers, etc.) and if isn't received, it boots the player!

So basically, add this to your AccountRec :

Code:
LoginTimer as double

In the local non-saved variables section.

In modConstants, add this :
Code:
Public Const ACK_KEY as String = "6594sdfsd9r3"
REMEBMER TO CHANGE THE KEY TO YOUR OWN!

Add this to the ClearPlayer sub :

Code:
Player(index).LoginTimer = 0

Now, in modGeneral, in the GameAI Sub add this :

Optimization Tip : Add the High Index to speed up the loop Wink

Code:
For i = 1 To MAX_PLAYERS
        If GetTickCountNew > (Player(i).LoginTimer + 15000) And Player(i).LoginTimer  0 And Player(i).Login  "" Then
            Call HackingAttempt(i, "Invalid Client!")
        End If
        
    Next i

Now, in modHandleData, in sub HandleData, add this anywhere (preferably near the top) :


Code:
' :::::::::::::::::::::::::::::::::::
    ' :: Acknowledge has been received ::
    ' :::::::::::::::::::::::::::::::::::
    If LCase$(Parse(0)) = "ackrc" Then
        if trim(parse(1))  ACK_KEY then
            Call HackingAttempt(i, "Invalid Client!")
            Exit Sub
        end if
        Player(index).LoginTimer = 0
        Exit Sub
    End If

As you can see, this checks to make sure you got the right key, if not invalids you. Now, look for the "login" packet, and near the end of the if case, right under :

Code:
Call SendChars(index)

Add this :

Code:
' Show the player up on the socket status
            Call SendDataTo(index, "ackps" & SEP_CHAR & ACK_KEY & SEP_CHAR & END_CHAR)
            Player(index).LoginTimer = GetTickCount

Now, that's it for the server code! Very simple code on the client side. Near the top of sub HandleData, just add this :

Code:
' ::::::::::::::::::::::::
    ' :: Acknowledge Packet ::
    ' ::::::::::::::::::::::::
    If LCase(Parse(0)) = "ackps" Then
        Call SendData("ackrc" & SEP_CHAR & trim(parse(1)) & SEP_CHAR & END_CHAR)
        Exit Sub
    End If

And there you go Smile Should work perfectly ^_^ If you have any questions or comments, just say/ask Big Grin
Reply
#2
Dave Wrote:I hate to say it, but this wont stop anyone. It's a worthless addon that just adds 15 seconds to the login time.

If someone has the skills to reverse engineer your packets (which is EASY with MS), they will notice you send the "ack" packet and tip them in.

This is just the basics. There are many ways you can build upon this tut, and one of the most obvious ones would be changing the packet name to a more obscure one, such as playerinfohash or something along those terms, making the player think that the key is not an acknowledgment key, but more something like a key for player stats or something. And other options could be encrypting your packets.

Sorry if that playerinfohash thing didn't make sense, it's getting late xD
Reply
#3
Wouldn't it be best just to use the SEC_CODE tut somewhere?
Reply
#4
Da Undead Wrote:Wouldn't it be best just to use the SEC_CODE tut somewhere?

Yeah, but it's easy to get sec codes, you just look at the login packet Wink Although you can still look at this packet, not that many people think about it.
Reply
#5
how do u look at a packet o-O, mines like 100 characters long :p
Reply
#6
Da Undead Wrote:how do u look at a packet o-O, mines like 100 characters long :p

Add a debug.print in send data or load up your packet sniffer in string mode.
Quote:Robin:
Why aren't maps and shit loaded up in a dynamic array?
Jacob:
the 4 people that know how are lazy
Robin:
Who are those 4 people?
Jacob:
um
you, me, and 2 others?
Reply
#7
clients can do that o-O?

So how do u make them non-hackable :p
Reply
#8
Da Undead Wrote:clients can do that o-O?

So how do u make them non-hackable :p

lol, they can't debug.print, but they can sure as hell sniff your packets. And it's kind of hard to detect :wink:
Reply
#9
is there any tut or code that fixes all holes and loops? : x
Reply
#10
Da Undead Wrote:is there any tut or code that fixes all holes and loops? : x

Nope, and I don't think there ever will be, considering anyone can just use a simple packet sniffer + memory editor.
Reply
#11
:\ hmm k
Reply
#12
Heres an idea, instead of checking at login to match a key in the client to the one in the server, have it check often. Have a list of keys, all under the same packet name, that the client randomly picks to verify itself to the server. The server simply checks to see if the key sent to it matches any of its stored keys, if not its a boot.
Reply
#13
Thats good idea, but still crackable. But it'll just make it harder for them :p
Reply
#14
Best way is to have the server randomize numbers/letters, save it to the playerrec, and make the client encrypt it back. I'll maybe post a tutorial on this if someone wants it.
Reply
#15
Erm, I may not understand what you mean, but it doesnt sound any different than the rest of the ideas in this thread.

You are just sending a packet to the client, and the client sends it back with an encryption. Anyone who has toyed with a sniffer more than a couple times will notice an out of place packet of randomness. Sounds like because you are saving it to the playerrec makes this a 'l33t' idea.

You want some added protection from packet-sniffing noobs. Lock the use of the client while a packet-sniffer is active. I'm sure everyone here knows all of the most common sniffers, choose your method to block them.

Also everything in this thread stops someone from using a completely random client to access your server, but nothing has been said about altering your client... anything in this thread that will stop that?
Reply
#16
Yeah, I'm saying it's a randomized packet.. Not just the same packet every couple seconds, so they couldn't do it unless they had your encryption key. Might also want to block WPE Pro so they don't modify existing packets, and compress your game so that it can't be decompiled and modified.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)