C++/CLI Packet sniffer

Page 1 of 2 1 2
10/04/2014 23:50 donn#1
I've started working on this:

[Only registered and activated users can see links. Click Here To Register...]

As I said, it's made in C++/CLI, it will first be just a packet sniffer, it can turn into anything else later on. It's undetected, since it involves no hooking to Conquer process at all.

For the beginning, I need a few ideas on how to organize the packets output, so it would be easier to read and analyze.

Any further questions or suggestions are welcomed. The only thing that I'm keeping secret for now is the method used for intercepting the packets.
10/05/2014 13:26 Best Coder 2014#2
[Only registered and activated users can see links. Click Here To Register...]

Am I getting warmer or colder?
10/05/2014 17:55 donn#3
Cooler. You know you can't decrypt CO2 packets without injecting your own DH key exchange. So just a sniffer is not enough, you also need to re-write those packets.
10/05/2014 18:33 Best Coder 2014#4
Quote:
Originally Posted by donn View Post
Cooler. You know you can't decrypt CO2 packets without injecting your own DH key exchange. So just a sniffer is not enough, you also need to re-write those packets.
If the client can decrypt the packets, so can a third party program. But okay, is [Only registered and activated users can see links. Click Here To Register...] colder or warmer then? :o
10/05/2014 18:35 donn#5
Warmer. It's WFP indeed.

Quote:
Originally Posted by Best Coder 2014 View Post
If the client can decrypt the packets, so can a third party program.
Still, I need to own the private key if I want to send my own packets.
10/05/2014 19:39 Best Coder 2014#6
Quote:
Originally Posted by donn View Post
Warmer. It's WFP indeed.



Still, I need to own the private key if I want to send my own packets.
[Only registered and activated users can see links. Click Here To Register...]
10/05/2014 21:43 donn#7
And since it's a packet sniffer, does anyone knows what packet is that:

10/06/2014 07:49 schacka2#8
did u decrypth the packets?
10/06/2014 11:31 KraHen#9
This seems really similar to what Fang was working on. Good job nonetheless!
10/06/2014 19:38 donn#10
Well, I had no idea about what Fang was working on.
Thanks for appreciating it.
10/08/2014 14:46 donn#11
Question: is there some public private server source available, working on the last patch, so I can extract some packets info from it? I'm loosing a lot of time trying to find the new offsets for them, maybe there are already out there.

I searched, but failed to find one.

Nevermind, I'm slowly structuring them all.
10/15/2014 08:53 donn#12
If anyone is curios, I reached this point in development:

[Only registered and activated users can see links. Click Here To Register...]

and I decided to dump C++/CLI and go fully native C++ (thanks to CptSky support) so I'm re-coding it entirely.

GUI will be made in Qt (also using signals/slots for events processing).
10/15/2014 11:32 KraHen#13
Great success. :D TBH in your place I`d go with a service-based app for the routing, which would communicate through WebSockets with a web-based GUI application. :D
10/15/2014 12:00 donn#14
There's a slight problem going this way. Since I'm intercepting (in the real sense of the word), the packets sent from client to server or from server to client are actually stopped at the filter level.

At that point I'm decrypting/reading/interpreting/encrypting them and pass them forward.

If those steps are not done in a timely fashion, the packet TTL is exceeded, which in turn would cause the sender (either client or the server) to re-send those packets (it's how TCP works). If I go to a service app based implementation and web-based GUI, I'm afraid doing all those steps in a timely fashion will be close to impossible (or I might not be seeing the things correctly and I might be wrong).
10/15/2014 12:43 KraHen#15
Quote:
Originally Posted by donn View Post
There's a slight problem going this way. Since I'm intercepting (in the real sense of the word), the packets sent from client to server or from server to client are actually stopped at the filter level.

At that point I'm decrypting/reading/interpreting/encrypting them and pass them forward.

If those steps are not done in a timely fashion, the packet TTL is exceeded, which in turn would cause the sender (either client or the server) to re-send those packets (it's how TCP works). If I go to a service app based implementation and web-based GUI, I'm afraid doing all those steps in a timely fashion will be close to impossible (or I might not be seeing the things correctly and I might be wrong).
Maybe remotely, locally with a ping of ~0 there should me minimal to no overhead, maybe 70ms max, although that could be a problem in these circumstances, I haven `t looked into it.
Page 1 of 2 1 2