question Source 6609 invalid acc and password

[Persis2]

Whats is the possible reason of this? No matter how many times i make a new account in mysql database. Still invalid if i log it in. Both Acc and game server run well.

 is this from Acc server problem?

 

Thanks to my good friend  @Airplist for helping me and providing Loader for my source.

Edited June 23 by Persis2

[Paradox]

if the image of your account server is how it looks even after you try to log in then yes your account server is not configured correctly. 

normally you would see some type of login attempt but you need to make sure that the account server is properly connected to the loader as well since you have changed it and make sure your account server is connected to the exact database you are using also. keep in mind almost everything if not everything is Cap sensitive so if your db is "Test" and you put "test" in your account server then it wont connect properly. 

Edited June 23 by Paradox

[cyano]

Your screenshot shows you're entering passwords in the DB as plain text.

Are you sure they're not supposed to be hashed (possibly also salted)? If they're not at least hashed... well I wouldn't guess how well the rest of the source is put together.

You have the source code? Take a look at what hashing algorithm (or none) it expects for the password and store the hash as the password in the DB, not plain text.

[Paradox]

1 hour ago, cyano said:

Your screenshot shows you're entering passwords in the DB as plain text.

Are you sure they're not supposed to be hashed (possibly also salted)? If they're not at least hashed... well I wouldn't guess how well the rest of the source is put together.

You have the source code? Take a look at what hashing algorithm (or none) it expects for the password and store the hash as the password in the DB, not plain text.

that is good advice on something to look into but if he is using any type of public source or some "bought" source there is a 98% chance that it uses plaintext account info and is expecting that. Should be one of the very basic things that every server should be setup for but for some reason that has been forgotten/ignored. I cant say for sure but im almost certain he is using some sort of this 6609 source that had a edited version of it released not long ago and it is just another "alex" base source which would then tell you that it definitely does not encrypt anything related to account info.

I just went through that source to double check since most account servers that are public dont use that color from what ive seen in my many years of testing and im like 99.999% sure he is using that source and he would 100% be getting a line saying "so and so account tried logging in on this ip" if the account server was setup correctly.

To the posts OP - 
I suggest going through your account server and making sure it is properly setup, just because it starts up and shows your ip and all that does not mean it is working properly. My bet is that it is not hooked up to your DB correctly as there are a ton of people using this 6609 source without this issue you are having. open it in VS and search for "localhost" or "root" and make sure it is setup to connect to your DB and keep in mind like i said before if your DB is named "test" make sure you are not using "TEST" or "Test" on accident because that could cause an issue. also make sure the loader is fully setup on the game server and account server, if all is correct when you go to sign in you will get a new line on the account server first saying so and so tried to login and then after that you will get the same thing on the game server once you get passed the "logging into account server".

[Persis2]

8 hours ago, Paradox said:

that is good advice on something to look into but if he is using any type of public source or some "bought" source there is a 98% chance that it uses plaintext account info and is expecting that. Should be one of the very basic things that every server should be setup for but for some reason that has been forgotten/ignored. I cant say for sure but im almost certain he is using some sort of this 6609 source that had a edited version of it released not long ago and it is just another "alex" base source which would then tell you that it definitely does not encrypt anything related to account info.

I just went through that source to double check since most account servers that are public dont use that color from what ive seen in my many years of testing and im like 99.999% sure he is using that source and he would 100% be getting a line saying "so and so account tried logging in on this ip" if the account server was setup correctly.

To the posts OP - 
I suggest going through your account server and making sure it is properly setup, just because it starts up and shows your ip and all that does not mean it is working properly. My bet is that it is not hooked up to your DB correctly as there are a ton of people using this 6609 source without this issue you are having. open it in VS and search for "localhost" or "root" and make sure it is setup to connect to your DB and keep in mind like i said before if your DB is named "test" make sure you are not using "TEST" or "Test" on accident because that could cause an issue. also make sure the loader is fully setup on the game server and account server, if all is correct when you go to sign in you will get a new line on the account server first saying so and so tried to login and then after that you will get the same thing on the game server once you get passed the "logging into account server".

thank you for the explaination but the acc server is full configured and infact i already run this source successfuly. The problem just appeard when i transfer it to another vps, because i change the loader instead of the loader from  the included client of the source because it has an protected loader. I cant edit the Gaurd.dat in the client because its encrypted and i can't replace the old ip address. So someone help me and give me different loader and the Its too crowded problem is fixed but this some acc server database problem replace it lol.

[Persis2]

8 hours ago, Paradox said:

that is good advice on something to look into but if he is using any type of public source or some "bought" source there is a 98% chance that it uses plaintext account info and is expecting that. Should be one of the very basic things that every server should be setup for but for some reason that has been forgotten/ignored. I cant say for sure but im almost certain he is using some sort of this 6609 source that had a edited version of it released not long ago and it is just another "alex" base source which would then tell you that it definitely does not encrypt anything related to account info.

I just went through that source to double check since most account servers that are public dont use that color from what ive seen in my many years of testing and im like 99.999% sure he is using that source and he would 100% be getting a line saying "so and so account tried logging in on this ip" if the account server was setup correctly.

To the posts OP - 
I suggest going through your account server and making sure it is properly setup, just because it starts up and shows your ip and all that does not mean it is working properly. My bet is that it is not hooked up to your DB correctly as there are a ton of people using this 6609 source without this issue you are having. open it in VS and search for "localhost" or "root" and make sure it is setup to connect to your DB and keep in mind like i said before if your DB is named "test" make sure you are not using "TEST" or "Test" on accident because that could cause an issue. also make sure the loader is fully setup on the game server and account server, if all is correct when you go to sign in you will get a new line on the account server first saying so and so tried to login and then after that you will get the same thing on the game server once you get passed the "logging into account server".

if i use the loader files from the included client of the source this acc server problem dont came up but i couldnt log in also because i cant edit the Guard.dat in the client which is where the old ip located. I got the its too crowded error.

[Konichu]

Your source and loader probably sets a custom encryption on the password submission or its just in another offset in the packet.

You must debug and see how the MsgAccount packet is being sent

[Persis2]

7 minutes ago, Konichu said:

Your source and loader probably sets a custom encryption on the password submission or its just in another offset in the packet.

You must debug and see how the MsgAccount packet is being sent

i guess its because of the different loader i used, because if i use the loader in the client i have the error its too crowded

[AndrejN.]

Hello all, @cyano I have a question, first of all I was able to use your method and make my original Conquer.exe launch on a clean conquer 6609 client, see the changed servers from the Server.dat file inside the login screen too, but when I try to login I am always getting the Invalid account and password message. I am using some private server source which has some patch in which I believe it has changed the encryption or even deleted it so it can log in through their modified Conquer.exe, but nevermind, the packet that it is sending is 1542 and in it, from the original Conquer.exe the password is maybe hashed or encrypted in some way and I don't know how to retrieve the original one. Does someone know a solution to this on what to do next ?

[cyano]

9 hours ago, AndrejN. said:

Hello all, @cyano I have a question, first of all I was able to use your method and make my original Conquer.exe launch on a clean conquer 6609 client, see the changed servers from the Server.dat file inside the login screen too, but when I try to login I am always getting the Invalid account and password message. I am using some private server source which has some patch in which I believe it has changed the encryption or even deleted it so it can log in through their modified Conquer.exe, but nevermind, the packet that it is sending is 1542 and in it, from the original Conquer.exe the password is maybe hashed or encrypted in some way and I don't know how to retrieve the original one. Does someone know a solution to this on what to do next ?

It sounds similar to: https://cooldown.dev/topic/823-source-6609-invalid-acc-and-password/  - has everybody suddenly got hold of this source 

That thread is probably best to move this discussion to... But my thoughts still:

Afaik "Invalid Account & Password" means its connected to some account server. I'd recommend opening wireshark and making sure that the packets are definitely going to your account server / IP address when you attempt to login.

Otherwise, if the client binary has been modified to change encryption key (unlikely, but possible) then you can reverse engineer the binary, there's a guide here: https://cooldown.dev/topic/12-client-how-to-disassemble-conquer-for-reverse-engineering/ (although I prefer to use ida, this a great getting started guide)

If you have the actual source code, assume its c#(?) - you can debug it in visual studio (set breakpoints, see the values it getting and comparing with) - trace the path of the login flow till you figure out why its rejecting that username/password.

Edited June 26 by cyano

[AndrejN.]

I don't think I have the same source tho, because I am able to log in and work the source for a longer time now, anyway the problem that it had with was the patch for DX9 version didn't work, I am working on the DX8 only and I was trying to resolve that. Also I know that the currently modified original Conquer.exe is sending the packets to my account server because I can see the packet dump that I am displaying for login. I can share them and you will see the difference, also I am able to log in without the password with your method and modifying the authserver login method to not require the password, but that is out of option .

So here is the packet from your method that I use on the original 6609 client is:
Packet Length : 312, PacketType: 1542
38 01 06 06 00 00 00 00 77 61 72 00 00 00 00 00      ;8war
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 4D 79 43 6F 6E 71 75 65 72  ;MyConquer
00 00 00 00 00 00 00 00 30 30 31 35 35 44 33 35      ;00155D35
43 37 45 33 00 00 00 00 00 00 00 00 00 00 00 00      ;C7E3
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 31 30 00 00 00 00 00 00 00 00 00 00 00 00 00      ;10
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 FE 98 CD 0F C6 01 92 93 F9 1F 8E B8      ;■?═╞??∙?╕
7D 80 82 FF 17 2A 4C AB D3 36 2D 91 7A DE EE 33      ;}?? *L½╙6-?z▐ε3
39 7F 6F 9A 6C BB 09 77 1D 62 A9 DA C1 13 8E 01      ;9o?l╗     wb⌐┌┴?
D0 B3 82 43 79 4C 27 EE 94 82 89 53 5E A6 64 7C      ;╨│?CyL'ε???S^ªd|
BD 58 10 4D 07 96 E3 41                              ;╜XM?πA

User: [war] Server: [MyConquer] MacID: [C7E3] Password: []

as you can see here the password field is empty, also I am also not sure if this is the right packet from which the client sends the password but highly likely...

and the one from the what I believe is the modified patched Conquer.exe that was used with this source sends this one:
Packet Length : 312, PacketType: 1542
38 01 06 06 00 00 00 00 77 61 72 00 00 00 00 00      ;8war
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 03 72 8C 81 00 00 00 00      ;r?ü
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 4D 79 43 6F 6E 71 75 65 72  ;MyConquer
00 00 00 00 00 00 00 00 30 30 31 35 35 44 33 35      ;00155D35
43 37 45 33 00 00 00 00 00 00 00 00 00 00 00 00      ;C7E3
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 31 30 00 00 00 00 00 00 00 00 00 00 00 00 00      ;10
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;
00 00 00 00 A0 DF FB 39 69 30 F7 8A C0 41 C5 6B      ;á▀√9i0≈?└A┼k
5D 46 E9 56 B9 12 CB 1B 99 98 2C F5 FA 09 5E F8      ;]FΘV╣╦?,⌡·        ^°
AF 46 53 61 78 5F A1 DD 02 62 B3 73 29 4D 5A 3A      ;»FSax_í▌b│s)MZ:
A0 E8 3C 4E C7 63 D0 F4 7A 5B BA 54 2A FB 09 43      ;áΦ<N╟c╨⌠z[║T*√    C
96 EB 4A 0F EE 49 24 1F                              ;?δJεI$

User: [war] Server: [MyConquer] MacID: [C7E3] Password: [war]

you can see here the 03 72 8C 81  or the ascii: ;r?ü is the password (war) sent from that client for which the server source uses this XOR decryption method which i believe is what was modified for the patched Conquer.exe on how to send the password, so it can decrypt it:
            public static string DecryptXor(byte[] data, byte size)
            {
                byte[] buffer = new byte[Math.Min(size, (byte)32)];
                for (int i = 0; i < Math.Min(size, (byte)32); i++)
                {
                    buffer[i] = (byte)(Key1[(i * 0x2c) % 0x20] ^ data[i]);
                    buffer[i] = (byte)(Key2[(i * 0x63) % 0x20] ^ buffer[i]);
                }
                return System.Text.Encoding.ASCII.GetString(buffer).Replace("\0", "");
            }

so what I am asking is how the original Conquer.exe sends the password, is it encrypted, hashed or maybe like a plain text(i doubt that). Also is that 1542 packet the right one to look for the password in?

ps. I am not so familiar with reverse engineering, tried it but that is out of my expertise 

Edited June 26 by AndrejN.

[Spirited]

Hey all, I'm going to politely ask that you use the other thread for this, because it's not related to this one. I'll move over the posts, if you'd like.

[AndrejN.]

If you can do that it would be great, I will be waiting for an answer there then... 

[zMagic]

Your source Login packet using a specific custom encryption algorithm ...

I recommend you bring the original packets from any public posted source  

And use Conquer LoaderV5.2 & Original TQ Conquer.exe to avoid any hashing/encryption 

 

[AndrejN.]

I can't find any public 6609 sources to relate to, does anyone have an example on how the auth should be, or even code example maybe, also which packet/packets should handle that whole process?.. By the way I don't think I need any specific loader since I have modified the original Conquer.exe with the cyano's method: 

 

[Konichu]

Since 5518 the login sequence uses SRP6 to authenticate the clients, this will require your passwords to be hashed and follow TQ pattern if you're willing to not inject a custom cipher.

SRP6 submits MsgSrpRequest (1542) with username and server, you must reply with MsgSrpChallenge(1213) and it will send you the packet you'll use for authentication that is MsgLoginProof(1214).

Seriously, it's easier to get CSV3 Loader which will be the easier to understand the process and is open source. This way you can set your own cipher or simply replace it with the cipher before SRP6.

[AndrejN.]

Thanks, yeah I tried to do it with the original conquer auth, but it is harder than I thought, so I did it with the open source loader and got both the dx8 and dx9 versions working!