Dot Net Source Example Multicasting Shared Radar

[joe7314]

Shared Radar is a design concept that will allow people to join a multicast group for a "shared/cooperative" radar on realms. This software automatically detects which realms you are signed into and tunes into the multicasts for that realm. If you are logged into more than one realm you will have more than one "realm listener", hence be "tuned in" to more than one "realms radar". The limit on how many realms you can "tune into" is limited by the hardware resources on your machine. In theory this can be used to share your radar with many, many, many people (all the people signed into the realm in theory) if they all join the same multicast group address. To eliminate conjestion; when you join a multicast group you are joining by ip AND port. In other words you are only joining the (ip/port) for that specific realm and NOT receiving every realm. The port for a realm is currently determined by a crc16 check of it's 4 byte ip (haven't totally tested this for conflicts) but it's not the only thing that needs improving. Anyway in theory/current practice each unique realm has it's own unique port. In other words every realms multicast group is made unique by it's "realm port".

In short: what you will see when you run the software are console messages displaying the realm ip and first 12 bytes of all SMSG_COMPRESSED_UPDATE_OBJECT contents (already uncompressed) from everyone in the multicast group (basically ourselves for now, I'm used to playing by myself I guess; doh!). But hey if you are not like me and you actually have some friends, please see how it works out.

Note: The source is vbnet it can very easily be converted to csharp (events are all you will have to touch up, test them for null and "whatnot"). I can convert the source on request if someone wishes it that badly.

Convert VB.NET to C# - A free code conversion tool

What this software will NOT do:
1) Anything visual, console output is all you will get!
2) Interact with a Wow process in any way shape or form.
3) Use a single thread and suck like crap.

What this software will do:
1) Interact with the OS (autodetecting when a Wow Process opens/closes)
2) Use threads appropriately.
3) Sniffs network traffic
3a) each process will have it's own port it is using
this is also information from the OS. Although
the sofware doesn't make use of it, it "does know"
which process a network packet is associated with
via the port number.
4) Functions with several (as many as your machine can run) Wow processes.
4a) Across Different Realms too. A realm is associated with
it's ip address.
5) Sends and receives multicasts via udp.
5a) The multicast group ip will be a constant you set
However, each realm you may be signed into has its
own listener on it's own port. For example, if you
have three wow processes running. Two of them you
are logged into realm A and one is logged into
realm B. Then you will have joined two multicast
groups. One for realm A and one for realm B.
(same multicast address, unique port for each realm).
If you open another Wow and sign into realm C you
will have joined yet another multicast group/endpoint.


Okay, there are so many implications by the design I'm just going to agree with them as they are pointed out I'm too tired to point them all out ahead of time. This should make a very interesting discussion and maybe spark some ideas for solutions I've been pondering on how to make this thing "useful/arguably usable".

Obviously the largest issue in general are the limitations posed by not decrypting the opcode headers. Right now the software looks for a "compression signature" 00 00 78 01 then verifies it's a valid payload by testing the bytes indicating the expected deflation size and deflating to ensure validity. Compression is not specific to one opcode but it's a start. Any ideas and comments about these limitations if very welcome.

[lanman92]

There is source for some packet decrypting stuff by amadmonk from a while ago. I would say look at it.

http://www.mmowned.com/forums/wow-me...crypt-lib.html

[joe7314]

Yes, very nice stuff I believe it was based off sniffitzt? I too use it to decrypt the opcode headers. That particular option/method reads memory from the wow process (the session key). The "fun" part about implementing it is sychronizing the arc4 iteration to a process that's been running for awhile (or resyncing/keeping in sync). But it's not too difficult. I only recently started writing code for wow so decrypting the stream is as far as I've gone with my source code. I have still to lift a finger actually creating an object manager, I know I will end up rewriting it after I write it the first time which makes me not want to start writing it (foo). I'm mainly still reading up on what everyone has been doing and is doing and why they did it and why they are doing it. I will probably end up following Amadmonk's path I mean I think I'm on the same journey but a few months behind. So I pay close attention to the offsets he's published since then. Since I can't stay passive like I wanted to, I'm sulking (in my own way) for awhile.

Oh yeah, doh! I forgot to mention, the reason I did not include any of that source is because it does open the wow process for reading and depends on one offset location and the software doesn't parse the payload anyway so I thought it would be better to present as a absolute zero risk endeavor for anyone wanting to mess with it and explore the concept in general of a shared radar or explore what is and what is not possible with completely passive packet sniffing.