I am new to dummynet/ipfw and I would like to know if I can do a couple of things using this tool.
1 - I need to make an exception in the pipe of a particular IP but that for all the others if the filters are applied. How could I do this?
2- I need to generate corruption, reordering and loss of package. So far I've only seen the option of packet loss and bandwidth limitation. Can you also apply corruption, packet reordering?
Thank you!
Regards!
Related
so I'm trying to deconstruct the messages passed by server-client interaction in a fairly old Halo game through LAN. I've been conducting tests with Wireshark and large packets. Although I am confused as to which type of data I should be analysing. In a chat message packet that was all a characters, I received this:
fe:fe:00:03:3a:00:11:19:39:1a:28:0d:b9:20:9d:7b:b8:59:52:90:e3:3e:93:7b:b8:59:52:90:e3:3e:93:7b:b8:59:52:90:e3:3e:93: [SNIP]
And in a message with all but the first 3 letters being 'a', I received this:
fe:fe:00:21:64:00:68:8f:02:6d:5f:ab:a7:cb:d0:78:0f:e9:6d:55:89:13:72:7b:b8:59:52:90:e3:3e:93:7b:b8:59:52:90:e3:3e:93: [SNIP]
Now, I can see some similarities between the packets at some stages (probably the a's), I've come to the conclusion that this:
7b:b8:59:52:90:e3
Might be an 'a' character. But have no way of proving it. How can I get the above strange string into a readable character, namely, back to 'a'? Is it possible?
Thanks for reviewing this question!
Protocol is UDP.
You just have to attach ollydbg to the process you are trying to understand, and set breakpoints at WSARecv (or recv) http://msdn.microsoft.com/de-de/library/windows/desktop/ms741688(v=vs.85).aspx
The next packet you receive will hit your breakpoint, follow the memory ptr to see it in a separate window and step over the call WSARecv. You should see a filled buffer now, set a memory breakpoint at the top of the new arrived data and if you press play you should get to the crypt function, if its crypted. (Its possible, that you have to reverse a bit more to get to that point) I hope its a starting point for you to get into reverse engineering assembly :)
Maybe my tut will help a bit, its for another game but i think it should show some ideas:
http://blog.praty.net/?p=315
Greetz defragger
Guessing the protocol by looking at network dumps is very inefficient. I recommend decompiling pieces of a game using modern tools such as Hex-Rays Decompiler and then combining knowledge of data structures used in networking modules with debugging live app using OllyDbg.
I am sure lots of you had this debate: What to write or not to the application log file.
I am not talking about the trivial error exception which we surely log inside the catch clauses.
Let's say we have a standart application which is connecting to database doing some selects.
we have a Dao object which each method in it wrapping a select query.
I would like to have your suggesations. Should I log every entrance and exit before I execute any selection? Should I log the result?
what about logging the error stacktrace? I find it very messy and overloading the log file.
could anyone recommend me on a good article in this subject(not necessary about logging database executions but generally)?
Thanks,
ray.
Logging means exacly that: taking notes when something happens. So you need to understand your needs as developer, and the needs of your customers. In both cases, try to figure out what do you need to accomplish your task.
As a developer, you should decide what level of confidence do you have with your software: if it is fully tested and debugged, then you could not log anything at all and just try to trace crashes. If on the other hand you are doing debug, you could need more detail. And in general, you should leave the possibility to turn logging off when confidence increases, and turning it on when thngs start to fail, possibly through a configuration setting. When you need to decide what to log, ask yourself: if it crashed, will this information help me identify the problem or will it be just noise?
For you customers, it depends. On a shared system for example, it's good to know who did what, so it happens to me to log actions that customers do. You should agree that with your customer.
don't log more than necessary.
more detailed explanation here http://www.codinghorror.com/blog/2008/12/the-problem-with-logging.html
cheers
that's why you have various log levels. the purely informational stuff you log at LOG_INFO and the debugging stuff you log at LOG_DEBUG. what actually gets logged is up to the user.
i have always wanted to make a private server but i don't know how i would do this.
i know how a private server works, the game sends data packets to the server. the server will take the data and process it and send data to the other games connected.
my questions are,
how do you edit the game so it will go to your server/change game data.
how do you find what packets do what.
the game will be something like WOW, i have not desided yet.
If you are hoping to embark on creating your own MMORPG then you have a huge task ahead of you, and unfortunately to put it nicely you are probably being too ambitious especially if you are asking these sorts of questions.
You should probably read up on client server architecture.
Also, in answer to your questions about the structure of the data being sent and how it is interpreted, well, that's 100% up to the people that design the system. You will want to simulate the entire game on the server(s) and don't trust the clients at all.
For something as complex as a MMORPG it is really important to create a solid design for the system before anything else, this is very important.
Just to be clear your intent is to create an emulated MMO server to the effect of WOW?
That's not really a trivial task and carries with it its own ethical implications.
Just to get started will require a ton of research, inspection, decoding, an extreme attention to detail.
If you are serious about it, then I would suggest looking up networking tools that can help you inspect traffic across the network and creating a scientific process for operation inspection.
Again, it should be noted this is by no means a trivial task.
This will be fairly difficult as you do not have the communicaton protocol specification for the game's client/server communication.
If you want to start this, then create a server that is simply a pass through. That is, all client requests are forwarded to the particular server. Once you have generated a large enough sample size of packets to study, then you can begin to dissect the meaning of each byte (possibly). Of course, if the packets are encrypted in any way (even a simple XOR encryption) then you will have an even harder time trying to figure out what each byte means. You should capture a sample set using two clients running sniffers so you can see what happens when one client does something and it needs to be sent to all clients.
But if I were you, I would just abandon the idea and work on something else. My two cents..
If you'd like an inside look at how games do networking, there's always Ryzom, which went open-source earlier this year. If you're creating your own MMO you can begin right there, and if you're looking to reverse-engineer one you can practice with your own client and server.
How do I go about reverse engineering a UDP-based custom game protocol with nothing other than Wireshark? I can log a bunch of traffic, but then what? My goal is to write a dissector plugin for Wireshark that will eventually be able to decode the game commands. Does this seem feasible? What challenges might I face? Is it possible the commands are encrypted?
Yeah, it's feasible. But how practical it is will depend on the game in question. Compression will make your job harder, and encryption will make it impossible (at least through Wireshark - you can still get at the data in memory).
Probably the best way to go about this is to do it methodically - don't log 'a bunch of traffic' but instead perform a single action or command within the game and see what data is sent out to communicate that. Then you can look at the packet and try to spot anything of interest. Usually you won't learn much from that, so try another command and compare the new message with the first one. Which parts are in the same place? Which parts have moved? And which parts have changed entirely? Look especially for a value in a fixed position near the start of the packet that could be describing the message type. Generally speaking the start of the packet will be the generic stuff like the header and later parts of the packet will be the message-specifics. Consider that a UDP protocol often has its own hand-rolled ordering or reliability scheme and that you might find sequence numbers in there near the start.
Knowing your data types is handy. Integer values might be stored in big-endian or little-endian format, for example. And many games send data as floating point values, so be on the look-out for 2 or 3 floats in a row that might be describing a position or velocity.
Commercial games expect that people will try to hack the protocol as a means to cheat, so will generally use encryption and probably tamper-detection as well.
Stopping this type of activity is of great concern to game makers because it ruins the experience for the majority of players when a few players have super-tools. For games like online poker the consequences are even more severe.
I'm receiving a recovery feed from an exchange for recovering data missed from their primary feed.
The exchange strongly recommends listening to the recovery feed only when data is needed, and leaving the multicast once I have recovered the data I need.
My question is, if I am using asio, and not reading from the NIC when I don't need it, what is the harm? The messages have sequence numbers, so I can't accidentally process an old message "left" on the card.
Is this really harming my application?
It's likely not harming your application so much as harming your machine - since the nic is still configured into the multicast group, it's still listening to those messages and passing them up, before your software ignores them and they get discarded. That's a lot of extra work that your network stack and kernel are doing, and therefore a lot of extra load on the machine in general, not just your app.
Listening to your recovery feed could also have a potential impact on a network level. As pjz mentioned, your NIC and IP stack will have more frames/packets to process. In addition, more of your available bandwidth is being used up by data that is not being used by your application; this could lead to dropped frames if there is congestion on your link. Whether congestion is likely to occur depends on whether your server is 100Mb or 1Gb attached, how much other traffic your host is sending/receiving, etc.
Another potential concern is the impact on other hosts. If the switch your host is attached to does not have IGMP snooping enabled, then all hosts on the same VLAN will receive the additional multicast traffic, which could lead them to experience the same problems as mentioned above.
If you have a networking team administering your network for you, it may be worth seeking out some recommendations from them? If you feel it is necessary to subscribe to a redundant feed, it would seem prudent to work out what level of redundancy already exists in your network and how likely it is that messages on the primary feed will be lost.
An addition to muz's comment...
It's unlikely that this will make any difference to your system, but it's worth being aware that there is an overhead associated with maintaining a multicast membership (assuming that you're using IGMP - which is probably reasonable given the restriction about "leaving the multicast")
IGMP requires the sending and processing of multicast group memberships at regular intervals. And (as alluded to in muz's comment) if you have any switches or routers between you and the multicast source that are capable of igmp snooping then they are able to disable the multicast for a given network.