Changes on login sequence? 5018 - Now (5212)

[Trigorio]

Hi, I have been on this forum since late 2005 but I've been away for about a year now. I recently came back and wondered what had been changed since then server-client wise. It would be nice if someone could fill me in

5018( after blowfish was implented)
Alot of packets must of obviously been changed and some even added, no doubt about that, but how is it with like the Login sequence?
Has anything changed in the Login sequence?

[gabrola]

Nope, nothing has changed in the login sequence

[Trigorio]

Well there is a "new" password cryptography that you failed to mention about and it looks like 0x43e is a bit changed. I'm going to take a look at it in the morning, going to sleep now..

[I.M.Real]

Originally Posted by Trigorio

Well there is a "new" password cryptography that you failed to mention about and it looks like 0x43e is a bit changed. I'm going to take a look at it in the morning, going to sleep now..

[Only registered and activated users can see links. ]
thers Korv's wiki might be some help
the auth server still uses the old keys,then the blowfish-DH starts
there is a padding on the packets tqserver tqclient shit
and some random type garbage that might show up aswell
but now as for A complete list of changes,I dont know when you quit

[gabrola]

Originally Posted by Trigorio

Well there is a "new" password cryptography that you failed to mention about and it looks like 0x43e is a bit changed. I'm going to take a look at it in the morning, going to sleep now..

Well I never messed with the password at all tbh

[Trigorio]

Allright so I got another problem now, I am trying to get my proxy to work with SocksCap so that I can force the connection from the Client to localhost.

This is my Idea:

Client 127.0.0.1 port: 2324(random) -> Proxy 127.0.0.1 port:5555, then process the information to AuthServer so, ExternalIpAddress(81.651.51.23) 2652(random) -> AuthserverIP(Let's say) 56.515.166.41(made up) 9958/9959

Is it right?

[gabrola]

Originally Posted by Trigorio

Allright so I got another problem now, I am trying to get my proxy to work with SocksCap so that I can force the connection from the Client to localhost.

Let's say I use the port 5555 and localhost for SocksCap settings.

Then I make the proxy listen on port 5555 at localhost. Bingo it opens a connection on port 5555 and then this is were I get stuck. Shouldn't the Client open up a random port on local host that then connects to SocksCap on localhost 5555 that would then process the information to the Proxy? And If so then I have an issue, I can't seem to get the Client to open up a connection :S. Do I have to process something from the authserver to the Client to make it open a connection?

Edit:
This is my idea of it

Client 127.0.0.1 port: 2324(random) -> Proxy 127.0.0.1 port:5555, then process the information to AuthServer so, ExternalIpAddress(81.651.51.23) 2652(random) -> AuthserverIP(Let's say) 56.515.166.41(made up) 9958/9959

So are the ports that I marked as random really random or is there something that decides what they should be?

SocksCap connects using a socks4/5 connection so there's usually extra headers in the packet, the thing to do is that you can hook the connect function in the client and make it connect to the proxy instead, in my proxy here's my hooked function

int WINAPI __stdcall MyConnect(SOCKET s, const struct sockaddr_in *address, int namelen)
{
    if(address->sin_port == htons(9959))
    {
        struct sockaddr_in clientService; 
        clientService.sin_family = AF_INET;
        clientService.sin_addr.s_addr = inet_addr( "127.0.0.1" );
        clientService.sin_port = htons( 9958 );
        return OrigConnect(s, &clientService, sizeof(clientService));
    }
    else if(address->sin_port == htons(5816))
    {
        struct sockaddr_in clientService; 
        clientService.sin_family = AF_INET;
        clientService.sin_addr.s_addr = inet_addr( "127.0.0.1" );
        clientService.sin_port = htons( 5816 );
        return OrigConnect(s, &clientService, sizeof(clientService));
    }
    else
    {
	    return OrigConnect(s, address, namelen);
    }
}

Basically if it tries to connect to any host with port 9959 (auth server), it connects to my proxy on port 9958 (the port that handles auth server requests) and if tries to connect to any host with port 5816 (game server) it connects to my proxy on port 5816.
Current auth server my proxy connects to is 208.96.34.46 : 9959
To get the game server ip you either get it from the authentication reply from the auth server or from the server.dat file.

[Trigorio]

Originally Posted by gabrola

SocksCap connects using a socks4/5 connection so there's usually extra headers in the packet, the thing to do is that you can hook the connect function in the client and make it connect to the proxy instead, in my proxy here's my hooked function

int WINAPI __stdcall MyConnect(SOCKET s, const struct sockaddr_in *address, int namelen)
{
    if(address->sin_port == htons(9959))
    {
        struct sockaddr_in clientService; 
        clientService.sin_family = AF_INET;
        clientService.sin_addr.s_addr = inet_addr( "127.0.0.1" );
        clientService.sin_port = htons( 9958 );
        return OrigConnect(s, &clientService, sizeof(clientService));
    }
    else if(address->sin_port == htons(5816))
    {
        struct sockaddr_in clientService; 
        clientService.sin_family = AF_INET;
        clientService.sin_addr.s_addr = inet_addr( "127.0.0.1" );
        clientService.sin_port = htons( 5816 );
        return OrigConnect(s, &clientService, sizeof(clientService));
    }
    else
    {
	    return OrigConnect(s, address, namelen);
    }
}

Basically if it tries to connect to any host with port 9959 (auth server), it connects to my proxy on port 9958 (the port that handles auth server requests) and if tries to connect to any host with port 5816 (game server) it connects to my proxy on port 5816.
Current auth server my proxy connects to is 208.96.34.46 : 9959
To get the game server ip you either get it from the authentication reply from the auth server or from the server.dat file.

Nice, what if I just want to use SocksCap, I could make it connect to port 5555, have a method in my Proxy that would reply to the client until the client sends the login 0x43e packet and process the packet to the Auth server at port 9959. Then I should recieve the Auth response 0x41f packet and I can read the IP and Port and proceed to connect to the Client?

Edit: God damn your way is waaaaayy better...

My concerns are can TQ Patch your method?

I mean in the long run, Sockscap or hooking to connect function?

[gabrola]

Originally Posted by Trigorio

Nice, what if I just want to use SocksCap, I could make it connect to port 5555, have a method in my Proxy that would reply to the client until the client sends the login 0x43e packet and process the packet to the Auth server at port 9959. Then I should recieve the Auth response 0x41f packet and I can read the IP and Port and proceed to connect to the Client?

Edit: God damn your way is waaaaayy better...

My concerns are can TQ Patch your method?

I mean in the long run, Sockscap or hooking to connect function?

Well I hook the connect function by having the injected dll search for the address of the function so basically the dll should work on all patches, that's the function that gets the address

GetProcAddress(GetModuleHandle("Ws2_32.dll"), "connect")

The Bloodshed Dev C++ project is attached if you want to change the ports you want to use.
So in conclusion, it's much more efficient and convenient to use the hooking method while also it being patch proof.

[Trigorio]

Nvm, unnecessary question.

But I get address 1906985479. Is that correct?
If I call MyConnect function once, then it should hook on WS2_32.DLL, force it to redirect all 9958 and 5816 port connections to the desired ports/ IP that I've set in the MyConnect function.

Also the best part is, this doesn't even touch Conquer at all, basicly no TOS Violations.

If I said something incorrect, then please do correct me, thanks