Questions about Proxy

Page 2 of 3

08/08/2010 12:59 tanelipe#16

For authentication cipher they've used to change key(s) in the past. They only recently, like a year ago, changed to blowfish from their previous encryption, which is still used for authentication part. They tend to change the encryption if the hacking/botting starts to make a noticable difference in the gameplay.

I believe that the blowfish encryption was initially cracked in weeks but it wasn't released to public until several months after that. (There's people who prefer it to remain private)

08/08/2010 15:16 pro4never#17

It's been answered already but the authentication flows as follows.

Client connects

Server sends 8 byte password seed so it can encrypt the password (decrypt/log only if you want to log the passwords)

Client sends login request (user, password, server)

Server checks info and returns login response packet. If valid login it will contain the game server port, ip and other info such as character uid, a login token and some values i haven't identified (they are unique to character but make no real diff to the client)

Client then disconnects from login server and connects to the game server using the info in the packet. Editing the packet is the simplest way to forward the connection. Simply change the ip and you're good to go.

NOTE: USING LOCAL IPS WILL CAUSE THE CLIENT TO CRASH: USE HAMACHI

08/08/2010 15:40 fm_sparkart#18

I've tried to PM unknownone to help me out with encryption but haven't gotten a reply, so I tried to convert the following C# code to C++: [Only registered and activated users can see links. Click Here To Register...]

Just wondering if anyone could proof-read for me.

edit:
Rewrote the code

Code:

#define NULL 0
#define BYTE unsigned char


class Cryptography
{
public:
    ~Cryptography()
    {
        delete[] _key1;
        _key1 = NULL;
        delete[] _key2;
        _key2 = NULL;
    }
    void Init()
    {
        _key1 = new BYTE[256];
        _key2 = new BYTE[256];
        BYTE iKey1 = 0x9D;
        BYTE iKey2 = 0x62;

        for ( unsigned short i = 0; i < 256; i++ )
        {
            _key1[i] = iKey1;
            _key2[i] = iKey2;
            iKey1 = (BYTE)((0x0F + (BYTE)(iKey1*0xFA)) * iKey1 + 0x13);
            iKey2 = (BYTE)((0x79 - (BYTE)(iKey2*0x5C)) * iKey2 + 0x6D);
        }
        _decryptCounter = 0;
        _encryptCounter = 0;

    }


    void DecryptClientPacket( unsigned char* packet, unsigned short length )
    {
        for ( unsigned short i = 0; i < length; i++ )
        {
            packet[i] = (BYTE)(packet[i] ^ 0xAB);
            packet[i] = (BYTE)((packet[i] << 4) | (packet[i] >> 4));
            packet[i] = (BYTE)(_key2[_decryptCounter >> 8] ^ packet[i]);
            packet[i] = (BYTE)(_key1[_decryptCounter & 0xFF] ^ packet[i]);
            _decryptCounter++;
        }
    }


    void EncryptClientPacket( unsigned char* packet, unsigned short length )
    {
        for ( unsigned short i = 0; i < length; i++ )
        {
            packet[i] = (BYTE)(packet[i] ^ 0xAB);
            packet[i] = (BYTE)((packet[i] << 4 ) | (packet[i] >> 4));
            packet[i] = (BYTE)(_key2[_encryptCounter >> 8] ^ packet[i]);
            packet[i] = (BYTE)(_key1[_encryptCounter & 0xFF] ^ packet[i]);
            _encryptCounter++;
        }
    }

    void DecryptServerPacket( unsigned char* packet, unsigned short length )
    {
        for ( unsigned short i = 0; i < length; i++ )
        {
            packet[i] = (BYTE)(_key1[_decryptCounter & 0xFF] ^ packet[i]);
            packet[i] = (BYTE)(_key2[_decryptCounter >> 8] ^ packet[i]);
            packet[i] = (BYTE)((packet[i] >> 4) | (packet[i] << 4));
            packet[i] = (BYTE)(packet[i] ^ 0xAB);
            _decryptCounter++;
        }
    }


    void EncryptServerPacket( unsigned char* packet, unsigned short length )
    {
        for ( unsigned short i = 0; i < length; i++ )
        {
            packet[i] = (BYTE)(_key1[_encryptCounter & 0xFF] ^ packet[i]);
            packet[i] = (BYTE)(_key2[_encryptCounter >> 8] ^ packet[i]);
            packet[i] = (BYTE)(packet[i] >> 4 | packet[i] << 4);
            packet[i] = (BYTE)(packet[i] ^ 0xAB);
            _encryptCounter++;
        }
    }

private:
    unsigned short _encryptCounter;
    unsigned short _decryptCounter;
    BYTE* _key1;
    BYTE* _key2;
};

08/08/2010 16:41 flowerpot!#19

Not sure why you need a class for CryptCounter... it's actually just two numbers when first one reaches 256 reset to 0 and increment the other one.

08/08/2010 17:03 fm_sparkart#20

Quote:

Originally Posted by flowerpot!

Not sure why you need a class for CryptCounter... it's actually just two numbers when first one reaches 256 reset to 0 and increment the other one.

Not sure why either, but when I was writing it I wasn't giving it much thought, just copying the piece of code. lol.

08/13/2010 16:56 fm_sparkart#21

Okay, so I'm making an aimbot by simply changing the target coordinates but I've read somewhere that aimbot tricks the server into thinking its nado. How is this possible because if it tricks the server into thinking its nado then the server will most likely see that its impossible, since the aimbotter is most likely a trojan.

I am just curious if this is even an aimbotting method because it doesn't make sense.

08/13/2010 17:05 pro4never#22

It tricks the client. Send the skill to client (on login all char skills are sent) for nado so they can see it. Then client on cast will send magic attack packet using nado to server. Proxy intercepts, does NOT send to server but instead casts fb on target actual coords (or locks on w/ aimbot targeting)

08/16/2010 10:28 fm_sparkart#23

Quote:

Originally Posted by pro4never

It tricks the client. Send the skill to client (on login all char skills are sent) for nado so they can see it. Then client on cast will send magic attack packet using nado to server. Proxy intercepts, does NOT send to server but instead casts fb on target actual coords (or locks on w/ aimbot targeting)

Okay, that makes sense... maybe I read it wrong or the person wrote it wrong.

So right now I've got the client connected to the proxy and the proxy connected to the game server. The proxy simply relays the packets back and forth.

Right now I am not quite sure how to handle the two packets sent for the key exchange.

[Only registered and activated users can see links. Click Here To Register...]

08/16/2010 19:26 pro4never#24

You use them to set up two independent key exchanges.

Server>Proxy: Server key for dhkey exchange (don't send to client).

Generate a client key (use an existing source as reference if needed) and send the client dhkey back to server (this sets up SERVER blowfish encryption)

Proxy>Client: Generate a server key and send it to the client

Client will then respond with it's own CLIENT key which you use to set up CLIENT blowfish encryption.

That way you have two different encryptions. One for server and one for client. Then in your Send function for theclient you will want a bool for ToServer and switch between the two encryption types.

This is a man in the middle attack where you don't worry about really doing anything with intercepting and deciphering the two keys being sent between the two, you simply masquerade as who you are expected to be (server for client and client for server)

08/17/2010 00:23 fm_sparkart#25

Quote:

Originally Posted by pro4never

You use them to set up two independent key exchanges.

Server>Proxy: Server key for dhkey exchange (don't send to client).

Generate a client key (use an existing source as reference if needed) and send the client dhkey back to server (this sets up SERVER blowfish encryption)

Proxy>Client: Generate a server key and send it to the client

Client will then respond with it's own CLIENT key which you use to set up CLIENT blowfish encryption.

That way you have two different encryptions. One for server and one for client. Then in your Send function for theclient you will want a bool for ToServer and switch between the two encryption types.

This is a man in the middle attack where you don't worry about really doing anything with intercepting and deciphering the two keys being sent between the two, you simply masquerade as who you are expected to be (server for client and client for server)

Yes, I am aware of the whole process but I did not know how to process the packets containing the public keys.

But I got it resolved, basically I was supposed to decrypt them using Blowfish using a constant key. I was using the authentication encryption to decrypt the packets because I thought it was still part of the login sequence, lol.

08/17/2010 00:49 pro4never#26

Quote:

Originally Posted by fm_sparkart

Yes, I am aware of the whole process but I did not know how to process the packets containing the public keys.

But I got it resolved, basically I was supposed to decrypt them using Blowfish using a constant key. I was using the authentication encryption to decrypt the packets because I thought it was still part of the login sequence, lol.

Sorry for the missunderstanding. Thought you were asking about the process more so than the specifics.

08/18/2010 05:50 fm_sparkart#27

Why do people prefer to use hex literals: [Only registered and activated users can see links. Click Here To Register...]

They're great for masks and flags because it is easier to convert to binary. In fact, that's the only reason I've used them.

Packet values? Not so much considering there is no reason you need to know the binary equivalent.

08/18/2010 07:02 pro4never#28

I never use hex when documenting packets. It's all personal preference but maybe it's just they are used to seeing it that way from their packet dumps.

08/21/2010 19:26 fm_sparkart#29

I've read around the forums that there are "bot packets" that are used as part of the anti-bot system.

What exactly are these packets used for? Are they sent to the client so that the client must reply with a valid response? Does the client simply send these packets to notify the server of an infraction?

How do you properly avoid bot detection with these anti-bot packets around?

08/21/2010 22:39 Ian*#30

I always use hex :) Less converting. Why should I have to take the calc out when I can do 0x27 - 8 anyways?

Botcheck packets are for clientless bots. On a proxy you can completely ignore the fact they're there. The client will handle all of it for you.

For an aimbot, if you wan't to do the nado lock thing, what you have to do is tell the client you know nado, then pick a target, reverse the spell encryption (for sending spells) so you can get the uid of the play you want to lock onto, then take that uid, encrypt it, along with his coords and send spell packets for that. Basically nado just used for grabbin the UID

Page 2 of 3