Samstag, 24. Januar 2009

I had quite a journey today. I wanted to try the official client against my Java 6 based webservice server. I started it and it wouldn't work :-( After going forward and backward through the wireshark logs I found that the server wasn't closing the connection causing the client not to start. I thought: Let's do it in C# again. So I downloaded Visual Studio 2008 Express for C#. This version was not able to build Web Applications/Web Services. So I downloaded the version for Web Developers. After that I had to learn C# and Web Services in .NET. Both was really simple IMO.

Once I got the WSDL to 99% equality to the originial ones (I only have a nillable="true" where it's not in the originial WSDL) I started looking on how to host this. The "web server" coming with Visual Studio was randomly choosing ports when starting and server only one webservice at once. I don't have (and don't want to have) IIS. I tried XSP from the mono project ... but it was unable to host the service giving me a meaningless error code. So I picked apache with mod_aspdotnet. Took me quite some time to configure it but got it running.

Last but not least fiddeled with the client to use my meta server instead of the official one.

To make a long story short: Here are the instructions on getting your own meta server to run.

1.) Download http://www.megaupload.com/de/?d=XRQJJLD0
2.) Exctract it to C:\GLS (so that a directory C:\GLS\GLS.DataCenterServer exists)
3.) Download and install apache 2.2
4.) Download and install .NET 1.1
5.) Download and install mod_aspdotnet
6.) Append the following lines to the httpd.conf file form apache:

#ASP.NET

LoadModule aspdotnet_module modules/mod_aspdotnet.so
AddHandler asp.net asmx

AspNetMount /GLS.AuthServer "C:/GLS/GLS.AuthServer"
Alias /GLS.AuthServer "C:/GLS/GLS.AuthServer"

Options FollowSymlinks Indexes
AspNet files
Order allow,deny
Allow from all
DirectoryIndex default.htm default.aspx


AspNetMount /GLS.DataCenterServer "C:/GLS/GLS.DataCenterServer"
Alias /GLS.DataCenterServer "C:/GLS/GLS.DataCenterServer"

Options FollowSymlinks Indexes
AspNet files
Order allow,deny
Allow from all
DirectoryIndex default.htm default.aspx


7.) Change the section from
Deny from all
to
Allow from all
(Note that this is an insecure hack!)

8.) Download http://www.megaupload.com/de/?d=1D6BISD0 and extract it into the htdocs folder of your apache
9.) Start apache
10.) Add the following line (containing the IP of your server first) to C:\WINDOWS\system32\drivers\etc\hosts

123.456.789.012 lotroeugls.com ddoeugls.com

11.) Optional: Open the firewall port 80 on your server
12.) Start your client
13.) Wait if it will ask you for a username/password
14.) Enter whatever you like as long as it's both longer than 6 chars
15.) See "[XY] My Own"
16.) Be happy

Downsides right now:
- There is no in game! I repeat: NO INGAME.
- Im totally new to C# so the code could be really, really, really bad
- The only server available right now is hardwired to 192.168.1.145. You can change it to whatever you like.
- I haven't tested to get in game, as there is no in game yet.
- It's easy to break things.
- Not shipping a complete htdocs, news for most languages are missing.

Freitag, 23. Januar 2009

Initial steps

The game is at least split up into 2 major parts.

1.) The authentication part
2.) The game itself

Let's look at what each of it is.

The first part is what you see in the launcher. The launcher is written in .NET. It uses web services over HTTPS to authenticate. Let's call this first part meta server, as it provides access to the real servers. To identify the funtionality of the web services I'd like to redirect you to

https://gls.lotro.com/GLS.AuthServer/Service.asmx

and

https://gls.lotro.com/GLS.DataCenterServer/Service.asmx

These contain pretty good definitions of what needs to be done to authenticate. I'll explain to you in a few words what client does.

1.) It starts up and and reads TurbineLauncher.exe.config. This file contains information where the web services are located.
2.) It verifies the client. I'm not exactly sure what happens in this step and I don't think that it's relevant for us.
3.) It asks you for username/password and sends this using HTTPS-POST to the LoginAccount from https://gls.lotro.com/GLS.AuthServer/Service.asmx. This will generate you a 256 byte long ticket. This will be used later. It will also return information about your account (which games do you own, when do you need to pay next time, etc.)
4.) It gets the list of data servers from GetDatacenters from https://gls.lotro.com/GLS.DataCenterServer/Service.asmx This list will be presented in the client.
5.) It updates the status of the servers by querying a xml file for each of these.
6.) You select one server and start the actual game. The job of meta server does not end here, but the client won't talk to it again, but the game server (verifying the ticket). Maybe the client is doing ticket refreshes, but I'm not sure about that.

Reverse engineering this is pretty trivial. Most of my information is based on http://ubuntuforums.org/showpost.php...8&postcount=30 and my personal experiments. You just need to implement a dummy client for them and invoke the webservices to get some details. Then you write your own meta server and use the official client to test it. I did that in about 4 hours using Java 6 and JAX-WS RI. As I said: This part is trivial. You can even use the linux launcher from http://www.lotrolinux.com/ to see how to write a C# client for it.


The interesting part is the actual game. From what I found out so far the following happens:

1.) The client sends encrypted data to "/stateless" using HTTP1.1, port 5015 of the server you are going to connect to. The server replies some encrypted data. This ping pong goes on for quite about half a second. I have no idea what they are doing. From my manual timings this is the actual login. I'm not sure how the data is encrypted. I'm totally unsure what happens there and need to further look at it.

2.) After the login (which I think it is) the client initiates a connection to the chat server, UDP port 2900. From what I understood so far the initial packet contains the ticket you got from the meta server. The following packets don't seem to be encrypted. They seem to contain mostly plain text in UTF-16. For example I could find the name of my character in it, or the name of my guild. Or there was a request from my client containing "Friends" that returned several packets in which I could find the names of my friends. I guess the protocol should be rather simple. It basically looks like they are mimicing something like TCP windows over UDP for data. Simple requests can return many UDP packets. This might be interrupted by the server waiting for a single and simple packet. Which results the server in continuing. The client and the server start to play ping pong after a while which looks like a keep alive to me. The ping pong is sometimes interrupted by chat messages. These messages always have an indicator which channel they belong to, like "Guild" followed by a HEX number after them like 0x0123456789ABCDE to indicate which guild it was (maybe). There are also "welcome" packates indicating a friend of you got online. These packets contain the name of your friend followed by an "[F]" which might indicate the friend status.

3.) The game protocol seems to be encrypted. It does seem to start with valid IP protocol followed by invalid packets (which might be caused by the encryption) which don't contain a correct source or destination IP. I'm not sure if this is the fault of my dump or the dumping tool I used or because of encryption or because of efficient network programming or because of my router or because of whatever. It seems to use a different IP as the chat server and use UDP ports like 9000 or 9004. I really need to find out what is happening there as I don't really have a clue right now.


Anyway I think this information is a good starting point of understanding the fundamental concepts and how the work together. It will hopefully clear some confusion of what is real and what is wrong. Please note: NO, I DON'T HAVE A WORKING LOTRO SERVER.


Note:
But yes, I have a working dummy meta server (that is allowing me to login in using hard coded credentials and displaying my news and showing my server as the only available game server)


Let's look at some concrete info. I used http://www.megaupload.com/?d=JQZQC3ZU and opened it using wireshark. I'll write down my analysis of it here referering the line numbers and what they mean.

1-12: Get list of data centers
13-24: Get the launcher configuration
25-37: Get the news for the client (26 is garbage)
38: garbage
39-156: Get data necessary for displaying in the launcher
157-166: Get the list of necessary apps that need to be installed to run the game
167-361: Just figured out that this is about patching the client! It used the server specified in the GetDatacenters webservice call. The value is the "94.75.194.24:5015". I think we can skip over this as there are few possibilities that we can reverse engineer the patch server.
362-369: Read the server status before connecting to it.
370-386: This must be the HTTPS login to get the ticket.
387-489: Read the status of all the servers
490-502: Register the user in the login queue (look at 495). It uses the info where the queue url is from http://10.64.102.84:7080/LoginQueue;http://10.64.102.85:7080/LoginQueue; from the file /status/cache_SERVERNAME.xml
503-517: Major headache ... what does it do?
518: garbage
519-521: These packets are sent against an IP from "94.75.194.139:9000;94.75.194.140:90 00;" from /status/cache_SERVERNAME.xml. I think it's a kind of handshake.
522-568: These seem to be the login packets. These are the really interesting packets we need to figure out.
569-...: This is starting the communication to the chat server. The IP is taken from "94.75.194.43:2900" of GetDatacenters webservice reply.

All following communication to 94.75.194.43:2900 is the chat. If we can believe what the videos at http://www.wowemu.net/lotro/ it is not necessary to reverse engineer the chat server first. We should focus on packages from/to 94.75.194.140:9000 (and the other packets to bogus IP addresses with port 9000 as source or destination). The relevant packages are marked as protocol "IP" in the log. The chat is marked as "UDP". This helped me finding my way faster through the packets.

I highlighted the sections that we really need to figure out. My current issue is that I'm not sure how the malformed IP packets should be read. From my understanding a packet can only reach my system (especially through a router) if the IP protocol is valid. And it really wonders me how these malformed packets can reach my system.

I think this log ends somewhere in the middle of the game. At least my logs show more packets after the game was shut down from the chat server.

Mittwoch, 21. Januar 2009

What it's all about

Its about reverse engineering lotro. Not the client part, but the server. So this blog is about the attempt to document enough of the internals of the LOTRO (lord of the rings online) server to be able to reverse engineer it. Right now there is no valuable information about the game so I will post it here.