[c++] Help with Proxy

Page 1 of 2

11/13/2010 17:12 TomasLT#1

So still working on my proxy nad need lots of info.
1.What encryption AuthServer is using?
2.Maybe some1 can send me working encryption/decryption code. It will be good if it`s on c++ but if its not then i rewrite it in c++.
3.GameServer encryption ()? maybe some1 again can share some code in any language.

4.And the last question maybe some1 can explain how MemorybasedProxy works

11/13/2010 19:33 pro4never#2

Search..

#1: there is a sticky on the subject of bots/proxies that contains tons of links

#2: there is already released C++ and C# wrappers for encryption.

11/14/2010 03:25 Trigorio#3

A memory based proxy hooks the Clients Send and Recieve functions and takes use of that.

It hooks Send PreEncrypted and Recieve PostDecrypted.

So in short the client already has the information decrypted for you and now you can alter packets and let the client encrypt it and send it for you. Or whatever you now want to do.

However Memory based proxies do have their limitations

11/14/2010 17:34 TomasLT#4

Thx for basic information which i know already, Any advantage infomation about proxy`s (memory/internet) ?

11/14/2010 18:47 IAmHawtness#5

Quote:

Originally Posted by Trigorio

However Memory based proxies do have their limitations

Like what? I'd say that "real" proxies have more limitations that memory based bots.

11/14/2010 19:02 Trigorio#6

Quote:

Originally Posted by IAmHawtness

Like what? I'd say that "real" proxies have more limitations that memory based bots.

Well for instance, how would you plan on building a standalone memory based bot?

My future plans all relay on standalone bots, ofcourse a standalone bot isn't a proxy any longer but I can go from a proxy to a standalone bot with very few edits because the base is very much alike.

Or if I am creating clientless, how exactly would I do that with a memory based proxy bot that relies on the Clients Cryptographys? How about this, the Client handles the authentications correct? Well currently with a "real" proxy as you call it I can have the authentication take place at my auth server as a further layer of protection against crackers. Say I would make a memory based proxy, how far could I take that if the authentication is going to take place within the client?

How about when you want to block a packet sent by the client, and create your own example say the general data packet and then send that one instead?

Normally the client would crash because the packet it sent/was trying to send off/process was not what it expected.

I have many scenarios where I have to block a packet and send one or two of my own instead of the initial packet that was planned to be sent by the client.

When you say "limitations" on a "real" proxy, you mean perhaps? The cryptography that could change at any given time? I don't see that as a limitation, I see it as an obstacle that can be overcome.

I'd love to hear your limitations with a "real" proxy, because so far I have yet to meet any of them.

11/14/2010 19:43 IAmHawtness#7

Quote:

Originally Posted by Trigorio

Well for instance, how would you plan on building a standalone memory based bot?

My future plans all relay on standalone bots, ofcourse a standalone bot isn't a proxy any longer but I can go from a proxy to a standalone bot with very few edits because the base is very much alike.

Or if I am creating clientless, how exactly would I do that with a memory based proxy bot that relies on the Clients Cryptographys? How about this, the Client handles the authentications correct? Well currently with a "real" proxy as you call it I can have the authentication take place at my auth server as a further layer of protection against crackers. Say I would make a memory based proxy, how far could I take that if the authentication is going to take place within the client?

How about when you want to block a packet sent by the client, and create your own example say the general data packet and then send that one instead?

Normally the client would crash because the packet it sent/was trying to send off/process was not what it expected.

I have many scenarios where I have to block a packet and send one or two of my own instead of the initial packet that was planned to be sent by the client.

When you say "limitations" on a "real" proxy, you mean perhaps? The cryptography that could change at any given time? I don't see that as a limitation, I see it as an obstacle that can be overcome.

I'd love to hear your limitations with a "real" proxy, because so far I have yet to meet any of them.

You're right about the clientless part, however it's easy (or at least do-able) to prevent the client from initializing after login so that it won't load maps, textures, etc., thus saving a lot of memory.

As for blocking packets:

Code:

Sub OnSendPacketFunction(ExceptionInfo As EXCEPTION_POINTERS Ptr)

	Dim PacketAddress As UByte Ptr = Cast(Byte Ptr, *Cast(UInteger Ptr, ExceptionInfo->ContextRecord->Esp +4))
	Dim PacketLength As UShort = *Cast(UShort Ptr, ExceptionInfo->ContextRecord->Esp + 8)

	Dim PacketType As UShort = *Cast(UShort Ptr, PacketAddress + 2)

	Dim SkipPacket As Boolean = False

[COLOR="Green"]	'Packet handling code goes here[/COLOR]

	If SkipPacket = True Then
		ExceptionInfo->ContextRecord->Eip = CInt(@SkipPacket)
	End If

End Sub


Private Function SkipPacket As Integer
	Return 1
End Function

As simple as that

As for the limitations a "real" proxy has compared to a memory based bot:
[Only registered and activated users can see links. Click Here To Register...]
You can't do that with packets only.

11/15/2010 00:51 Trigorio#8

A simple client edit to remove the delay for jumps does what you are doing, so I don't see how it "limits" the "real" proxy? And I can do the same from my map built in to the proxy. Even better use pathfinding.

I didn't say blocking a packet was hard, I said blocking a general data packet and then sending one(or two) you just created yourself with small modifications/alterations creates complications. Try it out urself.

11/15/2010 06:49 IAmHawtness#9

Quote:

Originally Posted by Trigorio

A simple client edit to remove the delay for jumps does what you are doing, so I don't see how it "limits" the "real" proxy? And I can do the same from my map built in to the proxy. Even better use pathfinding.

I didn't say blocking a packet was hard, I said blocking a general data packet and then sending one(or two) you just created yourself with small modifications/alterations creates complications. Try it out urself.

Code:

    Private Shared Sub _OnJump(ByRef JumpPacket As DataPacket.JumpPacket) Handles Me.OnClientJump

        If JumpPacket.CharacterID = MyClient.Character.ID Then
            MyClient.Character.Coordinates = JumpPacket.Destination
            MyClient.Character.MapID = JumpPacket.MapID
        End If

        If IWantToDoSomething Then
            JumpPacket.Destination = New Point(100,100) [COLOR="Green"]'(Modifies the packet)[/COLOR]
            SendPacket(New DataPacket.JumpPacket(MyClient.Character.ID, Environment.TickCount, New Point(50,100), MyClient.Character.MapID).BuildPacket) 
        End If

    End Sub

That's how my "proxy" works. I'm just saying, you can do a lot more with memory + packets than with packets only, for example a targeting system that targets people by shift-clicking them instead of having to use a "fake" nado skill on them

11/15/2010 14:59 TomasLT#10

Whats wrong with my AuthCryptography ?

Code:

class AuthenticationCipher
{
public:
int EncryptCounter;
int DecryptCounter;
char *Key1, *Key2;
virtual void Init()
{
        Key1 = new char[256];
        Key2 = new char[256];
        char iKeyOne = 0x9D;
        char iKeyTwo = 0x62;
        for (int i = 0; i < 256; i++)
        {
                Key1[i] = iKeyOne;
                Key2[i] = iKeyTwo;
                iKeyOne = static_cast<char>((0x0F + static_cast<char>(iKeyOne * 0xFA)) * iKeyOne + 0x13);
                iKeyTwo = static_cast<char>((0x79 - static_cast<char>(iKeyTwo * 0x5C)) * iKeyTwo + 0x6D);
        }
        DecryptCounter = 0;
        EncryptCounter = 0;
}
virtual void Encrypt(char buffer[], int len)
{
        for (int i = 0; i < len; i++)
        {
                buffer[i] = static_cast<char>(buffer[i] ^ 0xAB);
                buffer[i] = static_cast<char>((buffer[i] << 4) | (buffer[i] >> 4));
                buffer[i] = static_cast<char>(Key2[EncryptCounter >> 8] ^ buffer[i]);
                buffer[i] = static_cast<char>(Key1[EncryptCounter & 0xFF] ^ buffer[i]);
                EncryptCounter++;
        }
}
virtual void IEncrypt(char buffer[], int len)
{
        for (int i = 0; i < len; i++)
        {
                buffer[i] = static_cast<char>(Key1[EncryptCounter & 0xFF] ^ buffer[i]);
                buffer[i] = static_cast<char>(Key2[EncryptCounter >> 8] ^ buffer[i]);
                buffer[i] = static_cast<char>(buffer[i] >> 4 | buffer[i] << 4);
                buffer[i] = static_cast<char>(buffer[i] ^ 0xAB);
                EncryptCounter++;
        }
}
virtual void Decrypt(char buffer[], int len)
{
        for (int i = 0; i < len; i++)
        {
                buffer[i] = static_cast<char>(buffer[i] ^ 0xAB);
                buffer[i] = static_cast<char>((buffer[i] << 4) | (buffer[i] >> 4));
                buffer[i] = static_cast<char>(Key2[DecryptCounter >> 8] ^ buffer[i]);         // here
                buffer[i] = static_cast<char>(Key1[DecryptCounter & 0xFF] ^ buffer[i]);      //here
                DecryptCounter++;
        }
}
virtual void IDecrypt(char buffer[], int len)
{
        for (int i = 0; i < len; i++)
        {
                buffer[i] = static_cast<char>(Key1[DecryptCounter & 0xFF] ^ buffer[i]);         //here
                buffer[i] = static_cast<char>(Key2[DecryptCounter >> 8] ^ buffer[i]);           //here
                buffer[i] = static_cast<char>((buffer[i] >> 4) | (buffer[i] << 4));
                buffer[i] = static_cast<char>(buffer[i] ^ 0xAB);
                DecryptCounter++;
        }
}
};

Here how i call Decrypt function

Code:

byte buffer[276];
                        byte rec2 = ServerSocket1->Socket->Connections[ii]->ReceiveBuf(buffer,276);
                        Sleep(50);
                        if(rec2 > 0)
                        {
                                Memo1->Lines->Add("rec2 = Done");
                                AuthenticationCipher().Init();
                                AuthenticationCipher().Decrypt(buffer,276);
                                Sleep(50);
                                Memo1->Lines->Add("-----------  276 bytes -----------");
                                for(int a=0;a<276;a+=6)
                                {
                                        Memo1->Lines->Add(IntToHex(buffer[a],2)+" "+IntToHex(buffer[a+1],2)+" "+IntToHex(buffer[a+2],2)+" "+
                                                IntToHex(buffer[a+3],2)+" "+IntToHex(buffer[a+4],2)+" "+IntToHex(buffer[a+5],2));
                                }

Its compile fine but decrypting/encrypting wrong.

11/15/2010 16:16 Trigorio#11

Quote:
Originally Posted by IAmHawtness
Code:
    Private Shared Sub _OnJump(ByRef JumpPacket As DataPacket.JumpPacket) Handles Me.OnClientJump

        If JumpPacket.CharacterID = MyClient.Character.ID Then
            MyClient.Character.Coordinates = JumpPacket.Destination
            MyClient.Character.MapID = JumpPacket.MapID
        End If

        If IWantToDoSomething Then
            JumpPacket.Destination = New Point(100,100) [COLOR="Green"]'(Modifies the packet)[/COLOR]
            SendPacket(New DataPacket.JumpPacket(MyClient.Character.ID, Environment.TickCount, New Point(50,100), MyClient.Character.MapID).BuildPacket) 
        End If

    End Sub
That's how my "proxy" works. I'm just saying, you can do a lot more with memory + packets than with packets only, for example a targeting system that targets people by shift-clicking them instead of having to use a "fake" nado skill on them

To start off, as I see it all you alter is the cordinates. Try altering the MapID and send that and see if the client will process it.

Well you know what, I think it's important that we also define a Proxy and a Memory Proxy.

A regular proxy that relies on its own cryptographys rather then the Clients Send/recv functions can also read/edit the clients memory, would that classify it as a memory proxy? Or a regular proxy that can work with client memory aswell?

I can easily add memory management in a regular proxy, but I wouldn't exactly want to call it a memory proxy all of the sudden, because it still relies on its own cryptographys.

When I think of a memory proxy, I think of a proxy that takes use of the send and recv functions by searching a pattern in memory and hooking send/recv. Not a proxy that has the capability to alter memory, because if we got a proxy that for example changes Client memory on runtime to enable multiclienting, I wouldn't classify that proxy as a memory proxy.

So I still stick with regular proxies being stronger and more functional and less limited then a proxy that has to rely on the clients send and recv functions.

For things such as removing jump delays, I can still make my regular proxy manage memory to ignore the delay.

Either way both proxies are powerful. I just rather lean to a proxy dealing with cryptographys on its own if I had the choice.

@ThomasLT, Encrypt is for packets from the Auth, IEncrypt for packets from the client. Same goes for Decrypt for packets from the Auth, IDecrypt, packets from the Client. But when looking at it it seems right.

But the first packet sent by the server is a 8 byte packet, with a password seed, are you sure you are decrypting that one first? Also as far as I know, there does not exist any 276 byte packet sent by the server, but there does exist one sent by the client, the login packet with username, password and server.

For some reason you are using the Server Decrypt algorythm for a packet that should be recieved from the Client? Yet it says ServerSocket1 aswell? Your code is confusing me, is ServerSocket1 a ServerSocket? And if so how can you possibly recieve a 276 packet from the server?

11/15/2010 17:21 TomasLT#12

ServerSocket1 is a socket which accept Conquer client connection and and ClientSocket is socket which connects to authserver. but i even cant decrypt first packets i getting Access violation at address ... at this line

Code:

buffer[i] = static_cast<char>(Key2[DecryptCounter >> 8] ^ buffer[i]);

11/15/2010 17:23 IAmHawtness#13

Quote:

Originally Posted by Trigorio

To start off, as I see it all you alter is the cordinates. Try altering the MapID and send that and see if the client will process it.

Well you know what, I think it's important that we also define a Proxy and a Memory Proxy.

A regular proxy that relies on its own cryptographys rather then the Clients Send/recv functions can also read/edit the clients memory, would that classify it as a memory proxy? Or a regular proxy that can work with client memory aswell?

I can easily add memory management in a regular proxy, but I wouldn't exactly want to call it a memory proxy all of the sudden, because it still relies on its own cryptographys.

When I think of a memory proxy, I think of a proxy that takes use of the send and recv functions by searching a pattern in memory and hooking send/recv. Not a proxy that has the capability to alter memory, because if we got a proxy that for example changes Client memory on runtime to enable multiclienting, I wouldn't classify that proxy as a memory proxy.

So I still stick with regular proxies being stronger and more functional and less limited then a proxy that has to rely on the clients send and recv functions.

For things such as removing jump delays, I can still make my regular proxy manage memory to ignore the delay.

Either way both proxies are powerful. I just rather lean to a proxy dealing with cryptographys on its own if I had the choice.

I don't see why you're so skeptical about a memory proxy being able to edit incoming/outgoing packets. If I were to alter the MapID, all I'd get is a pullback from the server.

The only obstacle I've come across with memory based proxies and editing packets is when trying to edit an incoming/outgoing packet to a packet with a different size, but that's easy to overcome, just block the packet and use the send/recv functions to process the new packet. Or, as I prefer, block every packet the client send/receives and add it to a custom packet queue that you manage and is handled in a seperate thread, sending/processing the packets in the queue within a certain time delay. That way you can also control the delay that packets are sent/received.

I still believe that a memory based proxy can beat a port listener proxy at any time. There are so many other functions that a memory based proxy can hook on to other than the send/recv functions, such as the shift-click function, certain button functions, or whatever.

11/16/2010 00:23 Trigorio#14

Quote:

Originally Posted by IAmHawtness

I don't see why you're so skeptical about a memory proxy being able to edit incoming/outgoing packets. If I were to alter the MapID, all I'd get is a pullback from the server.

The only obstacle I've come across with memory based proxies and editing packets is when trying to edit an incoming/outgoing packet to a packet with a different size, but that's easy to overcome, just block the packet and use the send/recv functions to process the new packet. Or, as I prefer, block every packet the client send/receives and add it to a custom packet queue that you manage and is handled in a seperate thread, sending/processing the packets in the queue within a certain time delay. That way you can also control the delay that packets are sent/received.

I still believe that a memory based proxy can beat a port listener proxy at any time. There are so many other functions that a memory based proxy can hook on to other than the send/recv functions, such as the shift-click function, certain button functions, or whatever.

I can use a proxy dependent on it's own cryptographys and still invoke events when shift control is being used. You aren't exactly thinking outside of the box, all these things I can do.

Tell me something that I can't do with a regular proxy.

11/16/2010 06:44 IAmHawtness#15

Quote:

Originally Posted by Trigorio

I can use a proxy dependent on it's own cryptographys and still invoke events when shift control is being used. You aren't exactly thinking outside of the box, all these things I can do.

Tell me something that I can't do with a regular proxy.

You can't get the character ID of the person you shift-click unless you hook the client's memory in some way, so if you had to do that, woulnd't it be easier if your whole proxy was memory based?

Page 1 of 2