Packets Reading..

[metallica556]

I'm new to this , i've searched some info on the forum , but all of it looks outdated .... so How can i detect the packets?

[sokpuppet]

[metallica556]

uhh... i asked it the wrong way ... How do i intercept conquer's client packets . Also your link is helpful ,il take a look there.

[JaniQ]

You can either redirect the client connection or hook the client send/recv functions.

[Spirited]

It largely depends on the version of Conquer Online. Specific patches have varying protocols and ciphers. For example, patch 5018 introduced Blowfish and a custom protocol wrapper for the DH Key Exchange. This changed how we processed packets from the client. So, what exactly is your goal and starting point here? Are you starting with decrypted packets, or are you expecting to handle cryptography on your own? Is this a "starting from scratch" question or just a general "how to" for packet decoding (rather than decrypting and client reversing)?

[metallica556]

I think my goal here is trying to understand how to manage those things ... because as you expected I'm new to this. I haven't thought about cryptography yet , I think my question was a basic "how to" intercept the packets from the client .. as from there I wish I could handle the things my self

I am trying to learn step by step

[Spirited]

Originally Posted by metallica556

I think my goal here is trying to understand how to manage those things ... because as you expected I'm new to this. I haven't thought about cryptography yet , I think my question was a basic "how to" intercept the packets from the client .. as from there I wish I could handle the things my self

I am trying to learn step by step

Well, there are multiple reasons for processing packets from the client, each with various technical requirements and techniques. For the "from scratch" question, packet logging required reversing the client for hooking plaintext. Once packets were logged, their usage could then be reversed by following trends and procedures defined by the client.

For the Conquer Online private server and botting community, the cryptography was also reversed such to obtain ciphertext via proxy. This also allowed for simpler private servers that handled game cryptography rather than pattern matching or address matching the client's plaintext send and receive functions, or detouring them. From there, it was up to decoding the plaintext packet logs from binary hex dumps to packet structures. That's an analysis task of either trail and error or client reversal.

[metallica556]

Wow .. it seems like alot of work , and as I go trough your comment I slowly realise that this might not be for me , as I'm a beginner and I am not fully familiar with all the terms and procedures that may require. I'll do more research on this subject and I may come back with another thread in the future when I will be more educated in the terms and procedures. They seem pretty complicated for me right now...

[Spirited]

Originally Posted by metallica556

Wow .. it seems like alot of work , and as I go trough your comment I slowly realise that this might not be for me , as I'm a beginner and I am not fully familiar with all the terms and procedures that may require. I'll do more research on this subject and I may come back with another thread in the future when I will be more educated in the terms and procedures. They seem pretty complicated for me right now...

Well, that's starting from scratch. One scenario is private server development. Packets are mostly documented and cryptography is mostly known and implemented. Unknown packets are as easy as dumping to screen and decoding by hand, or just sending bytes to the client to see what happens. A more complicated, but avoidable, technique is reversing the client and reading assembly. Again, you don't need assembly knowledge to program a private server. We've done most of that work for you on . Bots are a lot more complicated and have a higher entrance level. I don't recommend bot development.

[metallica556]

Originally Posted by Spirited

Well, that's starting from scratch. One scenario is private server development. Packets are mostly documented and cryptography is mostly known and implemented. Unknown packets are as easy as dumping to screen and decoding by hand, or just sending bytes to the client to see what happens. A more complicated, but avoidable, technique is reversing the client and reading assembly. Again, you don't need assembly knowledge to program a private server. We've done most of that work for you on . Bots are a lot more complicated and have a higher entrance level. I don't recommend bot development.

Yea that was one of my ideas , bot development , but it seems waaaay more work than I've imagined and I don't see a good potential of profit . The other idea was to create a private server but as I see there are alot of them . I think I'm gonna learn these things in a general way , who knows they might help some time as I'm in a collage witha programming and software profile and I am atracted to these kind of things.

[Spirited]

Originally Posted by metallica556

Yea that was one of my ideas , bot development , but it seems waaaay more work than I've imagined and I don't see a good potential of profit . The other idea was to create a private server but as I see there are alot of them . I think I'm gonna learn these things in a general way , who knows they might help some time as I'm in a collage witha programming and software profile and I am atracted to these kind of things.

Bot development is rough water. If networking and game development attracts you, then Conquer Online private server development is definitely rewarding up to a certain point. You can better find another game or game idea to put time into, but I can't say I didn't gain a lot from this section and CO2 private servers. Hell, my current job and academic admission to undergraduate CS was based on work I did here. If you have interest in private servers, do it. College level programming is definitely enough to start. If you end up not liking it, it's not really wasted time.