adrian

this is really impressive... would love to see you guys going ahead with great results.

I got into same thought, as I didnt see other file corruption in other threads... but, I have these files backed up, so no problem. and btw, did you take a look to see if it is possible to use this tutorial to get in a way to apply your own encryption to server.dat?

hi, guys. I've been offline for long time. I'm sorry to hear that you have been into problems to download the files. in fact, the files were damaged (maybe a problem with forum server that might corrupted the files). but, good news! I've re-uploaded the files, so you may now unzip without problems. let me know if the files are okay now.

this is where i want to get at. nice job, btw.

yes, next step further. currently working on 5967.

nevermind, i already found the socket creation addresses on the client. to update you guys, what i've got so far is that i could make the client ignore the flash error and "auto start" the login process... is like simulating the click on the "enter" button of the flash start. the problem now is that, when the auth server receives the connection, and sends the pcs packet, the client is crashing... so i'm trying to find a break point to debug and see where it actually breaks. i believe its because of the flash update, that shows the animation and stuffs... so if i could make the client bypass this animation update, i think the client will not break anymore and we can then keep the normal login flux... this being said, the last step is to introduce a custom login modal, window or whatever we can in the midst of client start and the "auto login" action. a custom login will be needed to set in the process memory the server chosen, the ip, and the account/pass data. putting this things in the right place, the client will find these values in the memory when running the login process and things will go on as before.. that's the plan...

guys, i suspect that the socket created for login server connection is created in login flash. do you know anything about this?

is not a copy paste, really... i got an idea to a start point. will see what i get and share with you guys.

that is how i do feel too. but "thinking out loud" now... what if we try to replicate what the new client does now?

maybe we should work on this together and search for a possibility to make a new login screen.

I'm glad you did it! this should work fine on 5517 client. thank you, @Mugaru.

I'm sure you can use these methods to make it work with any CO2 client, but I'm curious to see what you get.

I didn't have time to take a look on latest patch files. it's a bit confusing how TQ is handling these files encryption. but is it all that you want: "decrypt the ItemType.dat" ?

Would you be interested in share basic start steps into encryption reversering? I would like to try it soon by myself, but have no idea how to start... not the whole process, not every ".dat" file is decrypted into a temp file as "server.dat". for other files you just need to jump over the decryption and make sure the decrypted data is in the right place when the client will use it. there is a little hacky way to copy memory from address A to B in the memory if needed, I can tell you if you are interested.

thank you. :) the first time I was studying and trying to do this, i took almost one week to figure it out how it works and make things right. but this time, i took one afternoon to repeat and write all the process... also, I decide to leave it registered so myself could do it at any client in the future and not start from scratch again...

I never got around to learning how to get the client to use a decrypted server.dat file. Maybe you could write some tutorials here on the subjects? I'd be curious to learn because once you know how to bypass it, you can re-encrypt it and write your own hook for that. not sure if the method I used will allow you to apply your own crypto, but check my latest post to se how I made it: *also, if you could approve my last edits... the images was in low resolution, so i put the high urls.

introduction before we start, I must say that these methods described here are results of my study and some testing/failing process I came up with. it was intended to be used in my Koga project, that is still coming alive next year (maybe). so, none of this was released before, and this is the first place I'm sharing this, and hope you enjoy. I'm assuming you are familiar to CO2 client files, ollydbg and the basic assembly instructions (JMP, JNZ, JGE, CMP, PUSH, MOV, etc)... this was not supposed to work with CO3 (Conquer 3) clients, but should work fine with any CO2 client that uses the encrypted "Server.dat". btw, this walkthrough was made over the v5967 client. but following these steps you might be able to do it on any client. anyway, for other versions specific modifications, see the other versions topic. the guide consists in some steps in order to make it from a clean client without modifications: replace TQAnp and TQPlat bypass the "blacknull" verification (video) loading decrypted Server.dat (video) "gzipping" the decrypted Server.dat other versions final considerations *you are permitted to share this anywhere you want, but only if the credits are going together.* 1 - replace TQAnp and TQPlat replace TQAnp and TQPlat dlls with nulled ones (backup your originals). this must be done, so you will be able to debug the client with ollydbg. the credits goes to "Ultimation" from Epvpers. TQAnp+TQPlat.dll.zip 2- bypass the "blacknull" verification (video) this must be done, so we can continue to debug from the start of the process in the ollydbg. run "Conquer.exe" from ollydbg and keep resuming any stop until you see the "Please run Play.exe file." alert. press pause in ollydbg and search all referenced strings. search for "blacknull" string and create a breakpoint. (in my case 00602B97) note: make sure you are searching from the top of the strings window, otherwise you may not find the "blacknull" string. double click the "blacknull" string and you will get into the address on the modules window. scroll a little to top, and you will see something like this: seek upward till you find the "CMP" instruction, and right below, the MOV and the JGE instructions. select "JGE" instruction (in my case 00602B5C) and press space (assemble shortcut), and change "JGE" to "JMP". this will follow that address every time (JMP) and not only if after the comparison the value in the memory is greater or equal (JGE). next step, back to the "blacknull" string, go down till you see "JNZ" instruction. select "JNZ" instruction (in my case 00602BA7) and press space, and change "JNZ" to "JE". you may get something like this: now, save all modifications to a new executable. right click in modules window, select "Copy to executable", then select "All modifications", select "Copy all". in the new "Conquer.exe" window, right click and select "Save file". don't forget to save with a different name, like "Conquer-Play-Bypass.exe", to keep the original file as backup. you can see the video walkthrough below: https://www.youtube.com/watch?v=00tYpUcmDpc 3- loading decrypted Server.dat (video) note: remember to open the "play-bypass Conquer.exe" in ollydbg for this step, otherwise you will may not be able to debug from the very beginning of the process, where the server.dat is actually decrypted to be used by the client. rename your client's "Server.dat" to "Server2.dat" or anything else, to make the client not find your "Server.dat". you will see the login screen like this: go to the client's folder, enter the debug folder and search for the last modified file, you will see a message in the log file, saying something like this: close the client and re-rename the file to "Server.dat". run "Conquer.exe" from ollydbg, wait for it to load, but do not touch the play button. change to "Conquer" module if needed (right click, then select "View", then select "Conquer" module, and search all referenced strings. search for the start of the message we got when client did not found the "Server.dat". like "Error in Decrypt file" and set a breakpoint at that string. look upward until you see an ASCII string ".dat" (in my case, 007CEC7B) and set a breakpoint here. from this breakpoint, you can restart debug from ollydbg and debug by yourself to get the addresses and see how the client does handle the "Server.dat". I will skip this for you and give you a resume: 1. "Server.dat" is loaded into memory. 2. it is decrypted by the client and saved into a 4 char name temp file, like "s***". 3. client unzip the file (it's gzip compression) and loads outenserver.xml into memory. 4. client uses the data loaded to create login screen and the other stuff. so, from this point, all we have to do is to make the client load the file we want in the place of temp "s***" file. to do this, we search for referenced strings and the look for a file path that we want to use (our hidden "Server.dat" will be this file). I will take "ini/quickpay.dat" as my decrypted "Server.dat". save the dump address (it's the address after the "PUSH" instruction, 00912F18 in my case), we will use it later. now, go back to the last breakpoint set (that ".dat" ASCII string), and look up until you see a "MSVCR90.tmpnam" call, like this one: note: you can also right click and select "Search for", and select "All intermodular calls", and search for "MSVCR90.tmpnam", and don't worry, there is only one (at least at this version of mine, but there should be only one), and set a breakpoint here. here is the tricky part: how to change the file path that it will load decrypted gzip file. below the "tmpnam" breakpoint, scrolling down, you may see a "KERNEL32.DeleteFileA" call, set a breakpoint in the "CALL" instruction above this: run until stop at this breakpoint. step into this call. scroll down and get to the first "MSVCR90.fopen" call (screenshot) and set a breakpoint here and also in the "PUSH ECX" instruction above. note: see the "PUSH EDX" instruction above the "fopen" call? it's the path parameter of the "open" function call. it pushes the value in memory at "EDX" address to be used in the read file function. right below the "PUSH ECX" instruction, you will see a "JGE" instruction. change the "JGE" into "JMP" instruction, maintaining the address where it will go to (008525C8 in my case). go to that address and assemble to "MOV EDX,[PUT THE ADDRESS OF THE FILE YOU CHOSE HERE]", in my case it will be "MOV EDX,00912F18". on the "NOP" line below, we jump back to that "PUSH EDX" where it loads the path of the "fopen" function, so we assemble to "JMP 008525BF" in my case. it will end like this: now, save all modifications to a new executable. right click in modules window, select "Copy to executable", then select "All modifications", select "Copy all". in the new "Conquer.exe" window, right click and select "Save file". don't forget to save with a different name, like "Conquer-Server.dat-Bypass.exe", to keep the original file as backup. you can see the video walkthrough below: https://www.youtube.com/watch?v=n_xVi2lYej8 4- "gzipping" the decrypted Server.dat if you open the new executable we created you will see that no server will be shown in the login screen. that's because that file we have selected to replace our decrypted "Server.dat" does not exist (yet). grab the "outenserver.xml" (attached to the post), and use 7-Zip to create a gzip file: right click the file, select "7-Zip", select "Add to the file..." And you will see the 7-Zip options window. you must use this settings in order the client can read the file correctly: format: gzip compression level: Ultra compression method: Deflate dictionary size: 32KB word size: 64 note: don't forget to rename the gzip file to "quickpay.dat" or whatever file name you chose. Place the file in "ini" folder (or the correct folder according to the file path you chose) and start the game again from the new executable. outenserver.xml.zip 5- other versions for other versions, I'll be updating this section with specific modifications needed to got it working on other clients. if you have found anything you want to share, let me know. v5517 (thanks to @Mugaru) 6- final considerations this method allows you not only modifying the servers info and changing the IP, name and icon to yours without using any hooks or dll injections, but also to keep your file in secret as "Server.dat" is still needed by the client to do the decrypt or the client will fail. enjoy your decrypted (+hidden) "Server.dat". don't forget to leave a feedback.

that's something I was looking for. I've modified the windows client for using decrypted 'server.dat' and sending decrypted password in login packet, but I'm mac user, and have been using parallel's desktop to use the client... hopefully I can make the mac client connect to my server. big thanks.

does it still consumes an URL file for server status in newer clients (such as 5967)?

great and stable server. good to see how its going, Lipe! I follow WC since it was Ftw start (I guess), CDD, and now... great to see your evolution as well! wish you best luck!