I have this very old online game client (MMO) that has gone offline, and I want to make a server to this client.
I saw a lot of this kind of servers like World of Warcraft private servers.
I think that is not illegal do this to this with this client because the company is long gone, and I will not distribute...
So, how do I start reversing this client to make a server? Do I need to capture the database requests and build a database based on the requests? I think that probably this go way further. Can you help me?
Can you give some examples?
Thanks everyone.
There was a good post on reverse engineering subreddit about this a little bit ago.
There are a few links with peoples experiences. Effectively you will play the game of trying to make your client happy by "answering" packets with your server if you dont have packet captures to go after. I would first identify packet parsing logic within the client. A good way of doing this is tracing recv() calls backwards and generally you will find a giant function (or a few functions) that contain a switch statement. Hopefully you'll find some useful strings, else you're just going to be playing the "keep the client happy" guessing game.
Related
I just discovered vert.x and played a little with it. I love it, however there is one thing that puzzles me: SQL support. Better said, asynchronous SQL support.
I know there is a postgres mod, and even a mysql one but from what I've read on the github page it is still in an early phase.
Also, one should use the event bus to send the query from the requesting verticle to the working verticle that would do the request and then transfer the results back.
However, this doesn't sound like a good idea to me. The communication would be done in text-mode which would imply a lot of serialization/deserialization. Plus, the results would need to read completely and then sent to the requesting verticle which sometimes can be overkill.
And now for my questions:
What is the best way to use mySQL in a vert.x verticle?
Is using the event-bus ok to transfer this much information in text-mode? (or maybe I'm missing something and there is actually a way to send binary data through the event-bus).
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 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 come from a web background where I only have to deal with HTTP so please excuse my ignorance.
I have an app which where clients listen for changes in a message queue which uses stomp. Previously the client only needed to listen to the relevant channels for messages telling them about changes on the server and update themselves accordingly. Simple stuff.
There is now a requirement for the client to be able to edit data and push those changes back to the server. The data on the server is already exposed via restful resources so my first thought was just to make REST put requests to change the data on the server, but then I started to wonder whether I could find a solution using messaging. I could just open up another channel which the clients could publish changes to and the server could subscribe to that channel and update itself accordingly. Implementing this would obviously be simple but I would love to have some of the potential pitfalls pointed out to me ahead of time.
I am familiar with REST so I want to ask some questions in the context of REST:
Would I map a group of queues to REST/CRUD verbs for each resource i.e. itemPostQueue, itemPutQueue, itemDeleteQueue?
What about GET's how can I request data to read using a queue?
What do I use to replace my status code mechanism to catch problems or do I just fire and forget (gulp) or use error/receipt headers in Stomp somehow?
Any answers and advise will be much appreciated.
Regards,
Chris
While I am not clear on why you must use messaging here, a few thoughts:
You could map to REST on the wire like itemPostQueue, but this would likely feel unnatural to a message-oriented person. If you are using some kind of queue with a guaranteed semantic and deliver-once built in, then go ahead and use that mechanism. For a shopping-cart example, then you could put an AddItem message on the wire, and you trust the infrastructure to deliver it once to the server.
There is no direct GET like concept here in message queuing. You can simulate it with a pair of messages, I send you a request and you send me back a response. This is much like RPC, but even further decoupled. So I send you a PublishCart request and later on, the server sends a CartContents message on a channel that the client is listening to.
Status codes are more complex, and generally fall into two camps. First are the actual queue-library messages - deal with them just as you would any normal system message. Second you may have your own messages you want to put on the wire that signal failure at some place in the chain.
One thing that messaging does do is significantly decouple your app. Unlike HTTP, where you know that something happened, with a queue, you send a letter to somebody. It may get there. The postman might drop it in the snow. The dog might eat it. If you don't get a response in some period of time, you try other means to contact your relatives, or to pull back the analogy, to contact the server. Monitoring of the health of the queue infrastructure and depth of queues and the like take on added importance, as they are the plumbing that you are now depending upon.
Good Luck