Ok so there have been a ton of random questions that have boiled down to proxies (or memory based bots) recently so I figured I'd write up some of my knowledge on the subject in one random place for people who are trying to figure it out.
DISCLAIMER: I know very little on the subject. Anything I post here is simply research I've been doing for my own little projects and should NOT be viewed as a completed knowledge lol. If anyone has corrections for me, feel free to post and I'll give full credit obviously.
What are you trying to do:
So the first question that should be asked is what are you trying to do? Level bot, aimbot, speed hack, packet logger, etc... Most if not all of these things are easiest to accomplish by creating or editing packets. To do this you really only have two options.
Option One: Memory based bots/tools
I have virtually ZERO experience with this but the idea is you create a program and hook it into the conquer process (generally through a dll). Once done you can read memory addresses such as hp/mana and from what I understand you can read/modify the memory addresses for incoming/outgoing packets. This will allow for all sorts of proxy like functionality.
Warning: This is generally done with C++ for injection seeing as afaik it's far easier to do that way vs other languages... you could do something like a loader in C++ and the actual program in C# or w/e... but generally these types of things are done in C++
Option Two: Proxy based bots/tools
The far more common option is creating a proxy in order to intercept, block, modify or create false packets that are being sent to or from the server.
The basic setup for communication is something like
Conquer Client <--> Proxy <--> Conquer servers
You simply modify your client to connect to the proxy ip (local if you are hosting it yourself). The proxy then listens both on auth and game ports. On receiving a connection from the client it then connects to the official tq auth server.
BASIC auth procedure as I remember it (probably flawed)
Client > TQ server (basic connection, no info sent)
TQServer > Client (confirmation of connection, sends basic info... I THINK password seed? I forget)
Client > TQServer: Login information (username, password, server, etc)
Tq server then verifies that information and returns a response
TQServer > Client: Response. If a valid login then it sends the GAME SERVER ip, port and server name.
When using a proxy you will want to modify this packet so that the client is now connecting to the proxy again instead of the tq game server. Once this is done there is a dhkey exchange done to setup the blowfish encryption and packets are sent for the final login procedure and normal game play.
Assuming encryption has been set up and connections are managed correctly. You now have access to ALL information flowing between the client and server in a non encrypted format. These packets can be forwarded on to their destination or they can be blocked or modified. You can even create your own packets and send them to their destinations. EG: Send server a jump packet and your character will jump (nothing sent from client so nothing is updated there). If you want the client to update you will then need to send the jump (or other movement packet type) to the client.
Note: Sending invalid packet sizes or types can be an easy way to get botjailed. When testing new packets use a noob.
<edit>
Added link for packet sniffing/analysis.
It explains most things but yah... once you have your packets in a decrypted state then you can begin to look into their structure. The best way I find to do this is look for things you know and go from there.
Common things to look for in packets:
Packet length (always first 2 bytes in conquer... this + 8 should be the number of bytes. The extra 8 is the seal)
Packet type (second 2 bytes for co packets)
Character UID: contained in almost all packets. It's 4 bytes so once you know your character uid it should be easy to find and help you structure your packets alot quicker by blanking out sections of unknown bytes
Seal: All packets are sealed with a text string. The last 8 bytes of any packet! It's either TQServer or TQClient. This is determined by which way the packet is traveling. If you are making your own packet MAKE SURE YOU SEAL IT WITH THE PROPER DIRECTION! (TQServer or TQClient)
Location info Map, X, Y. MANY packets contain this information (2 bytes) so it's best when logging packets to take note of what map and coords you are at so that it's easier to figure out what everything in the packet means. NOTE: some packets *cough* general data *cough* contain 2 sets of coords often... this is generally from/to coords. Make sure you are using them properly or you could run into problems!
Timer: Very useful if you plan to be creating your own packets to send vs just logging them. It's 4 bytes and changes with every packet. It's only contained (afaik) in the general data, walk and attack packets... I could be wrong on that though. NOTE: If you plan to let others use your proxy, make sure you are using THEIR computer time for any proxy generated packets... or simply replace all user timestamps with your own as I do.
Target UID: Mostly for attacking but it's a useful thing to look for. Note: Monsters are range 400,000-500,000. That's an easy way to find it if you are trying to build an attack packet or w/e. Super easy to find.
There are other things that these could be containing, I'd suggest conversion to string as well so that you can read any text information contained in the packet (name of spawned entity, the seal and all sorts of stuff!) It will help you alot when trying to sort out a bunch of jumbled bytes.
Once you have a working proxy you will need to setup your actual functionality/scripts. This could include auto hunting, looting, speed hacking, aimbotting, packet logging... ANYTHING.
The simplest way to do bot scripts is to add some new character variables. What I do is I simply have a bot thread that runs every 100 ms and checks for certain conditions.
Eg:
If(!Char.Botting)
return;
if(DateTime.Now < Char.LastBotTime.AddMilliseconds(Char.BotSpeed))
return;
//bot code
Something very simple like that can be used to control actions. Note: Make sure that if you do something like this you exit the function AS SOON AS POSSIBLE! If conditions are not met, STOP CHECKING FOR MORE! That's a very pointless thing to do and wastes LOTS of computing power. Check the most common conditions first (if the character isn't botting then why check if the time is correct?), then check less common conditions and make sure to write things using multiple functions. It makes tracking problems SO much easier. EG: Check if character is looting, Run a canloot/tryloot function, check if character is aimbotting, run a tryaimbot/canaimbot function, etc. By breaking things into functions you can correct, replace or completely remove sections of code without having to re-write your entire script.
Tips:
-Jumping faster than 700/750 ms will dc you unless you are using a proper speed hack or are in xp mode. DON'T DO IT!
-Sending packets sealed with the wrong thing will get you dc'd. DON'T DO IT!
-Sending packets with invalid size will get you dc'd and possibly bot jailed. DON'T DO IT!
-Sending packets with invalid values does NOT seem to get you in trouble... but still not the best plan. use a noob
J-umping to a target and attacking right away can cause dc's, Not recommended.
-Speeds are not checked when in superman or cyclone. Feel free to jump/attack faster! (note: too fast will still dc, test it out yourself. I haven't had problems with using like 100-200 ms though)
-Jumping and fsing within similar timeframes gets you dc'd. Don't do it! (Note: Fatal strike sends you to target xy... I'd be updating my coords if I were you! No need to jump)
-Updating the client too quickly can crash the client (eg: Sending it 50 jump/correct coord packets within 1 second or w/e... If you are doing a super fast xp mode... maybe only update it every 10 jumps? or use your own system)
Anyways, I have to get to work. I'll try to add in some diagrams and further info later but I just thought that with all the questions people have been asking that it might be wise to pull together some information on the subject.
Some VERY useful links.
Packet wiki (yay korv!)
GREAT link on understanding packets
Advice given to me when I was working on my proxy (long'ish read)
DHKey Exchange!
Diffie?Hellman key exchange - Wikipedia, the free encyclopediaMan-in-the-middle attack - Wikipedia, the free encyclopedia
<summary>
Ok so those links are quite technical and contain far more than you need to know... all you really need to know is that for DHKey exchange... each party uses an algorithm to produce a fairly standard small number. They send that number to the other party which is then run through their lovely algorithm to setup encryption. SUPER basic desc but the actual math behind it doesn't really matter.
What your proxy will be doing is a "man in the middle attack". Seeing as this key is public, all you have to do is put something (your proxy) in the middle. Setup a connection to each party (server and client) and receive the keys that they want to use for encryption. This allows you to understand the encryption that each party is using and to use it to send information in that direction. The fact that the two are not using the same key is meaningless because you are doing all that on your proxy!
Lets use the example of a packet coming from the client.
Client tries to send a packet to the server.
Proxy decrypts this packet using the CLIENT'S encryption key + blowfish and all that good stuff.
Proxy reads/alters the packet
Proxy ENCRYPTS the packet using the SERVER'S encryption key + blowfish and all that good stuff.
Proxy sends the packet to the server.
And just like that, the proxy is able to understand, modify and create packets without issue and neither party knows that their encryption is wrong because the proxy simply is using two different keys. One for the client and one for the server.
If my desc is off... please correct me.. Encryption tends to confuse the hell out of me but this is my basic understanding of how it works.
<OTHER C# RESORCES>
C# for dummies E-book: Very good basic guide to programming
C# Primer E-book
C# Bible E-book
