Backup

Resident Evil Outbreak server emulation
by d
I thought about this some time ago and started a discussion on forum. This are the archived posts:

can REO servers be emulated?

 I used a european REO#2 on a PS/2 with a linux box for dumping the network traffic between the DSL router and the PS/2.
First of all the game connects to SONY's DNAS service via https-connection. I guess this is the point where backups are sorted out ;-)
Next step is a DNS-lookup for "app01.reo.capcom.sf.yav4.com" which is resolved by my provider to one of his own IPs. This is because the capcom server does not exist anymore and my provider wants to place some commercial !?! Anyway, the PS/2 is happy with the IP adress and tries three times to connect to it on Port 10127. This is where the game stops with error 904: server communication.

Next step for me is to write a small network listener for port 10127 on my linux box. This way the PS/2 thinks it connects to the original server :-D

Now it gets difficult. Without the dumps of a game session it is very hard to write a server for this game. Any volunteers ?

--- SNIP ---

The DNAS code is sent back to PS/2, but verification is done by some SONY server. The missing Capcom server is called after verification.

Mhm, I think Linux is not really needed for help. All I need are dumps from the network traffic between the game and a still alive game server. Important is also to write down the steps in detail so I am able to point out which network packets belong to which action. (e.g.: Starting game in multiplayer mode, using last connection, dnas verification screen shows up, connection error 904 appears, ..., ...)

There are several possibilities to get the dumps:
- pc with 2 network cards with linux as gateway (e.g. slax booted from USB)
- pc with 2 network cards with windows as gateway
- pc with linux and pcsx2
- pc with windows and pcsx2

The dumps can be done with wireshark (www.wireshark.org). But I guess we need someone with an active account for the japanese servers and a japanese version of the game.

For the first few steps we can try out without an active account. I cannot say how far we get but every little information can be helpful also a "DENIED" screen as long anything happens after the DNAS verification ;-)

Another thing hits me. I read that Capcom had problems with people cheating in the game. Probably we can get some information about the inner workings of the game from cheat codes, programs etc. So if anybody has information and websources, please post...

--- SNIP ---

I coded a fake DNS server and the listener I talked about. The results are as exspected: PS/2 connects to my linux box and accepts the data packet I am sending ("Hello World!") ;-) and then closes the connection. So without a real game server session one would have to reverse engineer the game. Not what I had in mind :-D

=====

Digging around in the captures
by d
I got a huge amount of packet captures from Chris and poked into some of them to get a feeling how the used protocol works.

First of all I see earlier findings confirmed:

- DNAS is https secured
- KDDI login is https secured
- game communication seems to be fully routed through KDDI, but this maybe a fallback solution incase clients cannot connect to you but it would explain why players have a lag.

Luckily game communication does not seem to be encrypted as you can see on one "Message of the day" packet. I cut off what I think are session data and show you a hexdump of the remaining 198 bytes:

00000000  c5 3c 42 4f 44 59 3e 3c  42 52 3e 3c 42 4f 44 59  |.<BODY><BR><BODY|
00000010  3e 81 79 8f 64 97 76 82  c8 82 a8 92 6d 82 e7 82  |>.y.d.v.....m...|
00000020  b9 81 7a 3c 4c 46 3d 32  3e 3c 42 4f 44 59 3e 83  |..z<LF=2><BODY>.|
00000030  8d 83 4f 83 43 83 93 83  79 81 5b 83 57 82 c9 8f  |..O.C...y.[.W...|
00000040  64 97 76 82 c8 82 a8 92  6d 82 e7 82 b9 82 aa 3c  |d.v.....m......<|
00000050  42 52 3e 3c 42 4f 44 59  3e 82 a0 82 e8 82 dc 82  |BR><BODY>.......|
00000060  b7 81 42 3c 4c 46 3d 32  3e 3c 42 4f 44 59 3e 82  |..B<LF=2><BODY>.|
00000070  b2 97 97 92 b8 82 af 82  dc 82 b7 82 e6 82 a4 82  |................|
00000080  a8 8a e8 82 a2 82 a2 82  bd 82 b5 82 dc 82 b7 81  |................|
00000090  42 3c 4c 46 3d 32 3e 3c  42 4f 44 59 3e 81 40 81  |B<LF=2><BODY>.@.|
000000a0  40 81 40 81 40 81 40 81  40 81 40 81 40 81 40 81  |@.@.@.@.@.@.@.@.|
000000b0  40 81 40 81 40 4b 44 44  49 8a 94 8e ae 89 ef 8e  |@.@.@KDDI.......|
000000c0  d0 3c 45 4e 44 3e                                 |.<END>|
000000c6

You can see the first byte 0xc5 = 197 contains the length. This really looks like XML and if you try to open this with your browser (JIS activated) you see that there's japanese text in it. Translate it with your favourite online service and see what there is written:

[important news]
There is important news on the login page.
I ask so that you can see it.
KDDI Corporation

Beside the fact that online translations are a bit rough we have a simple proof that at least some of the server communication is not encrypted!

So what comes next? DNAS is done by some SONY server (gate1.jp.dnas.playstation.org) and independant from the game server itself. So there is no need to work around that at the moment. The next logical step is to figure out how the login process is done.

=====

Janushead and login procedure
by d
How do you get plain unencrypted HTML from a website using the https protocol? Act like a janushead with two faces and write a logfile. Simple as that... So why not using this technnique on a gateway between PS2 and the internet? Chris again did the job and was so kind to give me the captures. This is what we found out so far.

After DNAS check KDDI page for login is loaded. This is a screenshot from my PC not from PS2!

[Insert image that didn't make the deletion]

Not very interesting? Believe me, it is. After the login with username and password is done and you chose to connect to the game the server sends back the gameservers name, the port to connect to and most important a session id which is used to identify the user on the gameserver. There are some more information I cannot use at the moment but the first small steps are done. We should now be able to create a login system and do a very important step in server emulation.

Looks like I have some work to do now. This will take some days, stay tuned!

=====

Surprise surprise ...
by d
Based on the findings I wrote about in the last post I hacked some things together. First of all I installed some packages on my Linux netbook: Apache2, DNSmasq, PHP (just in case) and built up a network environment where the netbook works as a gateway for the PS2. I used iptables for this task. I also created a self signed certificate Apache webserver and changed the configuration to support SSL. Then I changed /etc/hosts to redirect queries from the PS2 to my netbook instead of the KDDI login server. PS2 networking had to be adjusted to use my netbook as gateway and dns-server. Then I created a small webpage as a proof of concept and voila, I did it:

[Insert video that didn't make the deletion.
If memory serves, it was simply the connection through DNAS and the frontpage.]

So what happens here? PS2 sends a DNS request to the netbook which looks up the IP and sends it back to PS2. DNAS communication is done with Sony's servers routed through the gateway. Then another DNS query for the KDDI server is sent by the PS2. But this time the netbook sends back the IP from /etc/hosts and the PS2 connects via https to our Apache instance.

What you can also see in the video is a link to a page "testserver". This is a special page which when loaded lets the PS2 connect to the gameserver. I don't know japanese so unfortunately I cannot say what is written on the screen. Does anybody know? Important is the fact, that at this point PS2 talks with the capcom gameserver!

By changing the startserver-page we can easily tell the PS2 to use our own gameserver. This is where the real work has to be done and hopefully this story continues...

=====

The server's answer to my direct connection
by d
I wondered what the server's message was in my video demonstration. Fortunately I had a wireshark session running and it was easy to find the matching packet. It had a strong similarity with the MOTD packet which is easy to decipher:

[Insert image that didn't make the deletion]

Well, one could have guessed that but I really wanted to be sure :-)

=====

Basic infrastructure and first packet analysis
by d
After spending some time with reading the captures and trying out some things I come to the conclusion that the private server for Resident Evil / Biohazard Outbreak File #2 will not be a single program running on some PC in the LAN. What we need for a working server is

- a DNS service (DNSmasq for example) for redirecting the PS/2 to our own system without modifications of the PS2 or the gamedisc
- a webserver (Apache for example) for serving the login pages
- the gameserver itself
- a possibility to connect to the internet for DNAS checking

What I want to create is a small Linux Live distribution containing all the neccesary tools and programs that fits on a USB stick so everyone can put up a REO-server on LAN by simply booting with that stick.

After working through some full game captures I am quite sure that the online game communication is NOT peer-to-peer based. Instead there are three(!) services to emulate. First of all the already known KDDI login webservice. This is no big deal, have a look at my earlier posted video. Then the lobby and matching system has to be done, this is what I am working at atm. And I found out that the ingame communication is based on a separate server/port/protocol I will have to look at later...

For everyone who also wants to dig into the captures, I wrote down how the data in the packets (at least for the lobby and matching system) can be read. My example is the "Message of the day" data packet. See what the client(PS2) sends and what he gets from the server in return (use the option "Follow tcp stream" from the context menu in wireshark):

    000000DA  81 01 61 4c 00 00 00 d7  00 ff ff ff             ..aL.... ....

server:
    000000C9  18 02 61 4c 00 c8 00 d7  00 ff ff ff 01 00 c5 3c ..aL.... .......<
    000000D9  42 4f 44 59 3e 3c 42 52  3e 3c 42 4f 44 59 3e 81 BODY><BR ><BODY>.
    000000E9  79 8f 64 97 76 82 c8 82  a8 92 6d 82 e7 82 b9 81 y.d.v... ..m.....
    000000F9  7a 3c 4c 46 3d 32 3e 3c  42 4f 44 59 3e 83 8d 83 z<LF=2>< BODY>...
    00000109  4f 83 43 83 93 83 79 81  5b 83 57 82 c9 8f 64 97 O.C...y. [.W...d.
    00000119  76 82 c8 82 a8 92 6d 82  e7 82 b9 82 aa 3c 42 52 v.....m. .....<BR
    00000129  3e 3c 42 4f 44 59 3e 82  a0 82 e8 82 dc 82 b7 81 ><BODY>. ........
    00000139  42 3c 4c 46 3d 32 3e 3c  42 4f 44 59 3e 82 b2 97 B<LF=2>< BODY>...
    00000149  97 92 b8 82 af 82 dc 82  b7 82 e6 82 a4 82 a8 8a ........ ........
    00000159  e8 82 a2 82 a2 82 bd 82  b5 82 dc 82 b7 81 42 3c ........ ......B<
    00000169  4c 46 3d 32 3e 3c 42 4f  44 59 3e 81 40 81 40 81 LF=2><BO DY>.@.@.
    00000179  40 81 40 81 40 81 40 81  40 81 40 81 40 81 40 81 @.@.@.@. @.@.@.@.
    00000189  40 81 40 4b 44 44 49 8a  94 8e ae 89 ef 8e d0 3c @.@KDDI. .......<
    00000199  45 4e 44 3e                                      END>

How do we have to read these packages?

Every packet has a header and a variable length for the payload. The header is exactly 12 bytes long and consists of the information if the server or the client is sending (18/81) and if it's a query or an answer (01/02). Then follows the command (614c for Message of the day) and the length of the added payload. Before the marker (00ffffff) is set, the packet gets a packetid (here 00d7). Then comes the individual payload, in this case one message with 00c5 bytes of content. Obviously a html/xml-like file which is then displayed by the PS2. Hard to read? Yes, it is, so I rearranged the bytes for your convenience:

[Unfortunately, this image didn't make it.]

What I am doing next is an indepth analysis of the different commands and the implementation into some C-code I already wrote for testing. Let's see what comes next. If you are digging into the packets, too and want to tell your findings, don't hesitate to contact me. Let's make this private server thing happen!

=====

First steps in gameserver development
by d
This is just a quick update for all the interested readers.

I am writing on a selectserver for the Resident Evil / Biohazard Outbreak series. So far around 400 lines of code are written for the basic functionality like listening on socket, receiving packets and sending packets. When this is working stable I will implement the commands of the protocol used in the game. This takes some time but I am quite sure it will work! But at this state it is impossible to say how long this project will take.

=====

Running my own server
by d
Well, this is quite limited atm, but it works and it's a good basis for further development. I put together some frames from the video I sent to Chris. I didn't want to publish it here 'cause his KDDI-ID is viewable on the video.

[Insert image that didn't make the deletion.]

What you can see here is a real PS/2 logging into my REOAS (Resident Evil Outbreak Alternate Server), asking for the User-ID and then sending the message of the day. This is running completely independant from the kddi/capcom servers. Some of the packets are not deciphered yet but by sending them back to PS/2 it'll continue to talk with the server. I think it's just a matter of time until everything is getting clearer...

This example shows that the server recreation can be done! The next steps in programming the server and developing its infrastructure will take me some time because the lobby system itself needs to be done and a real login systems is needed (you don't want to enter the REOAS with Chris' ID, do you ?)

=====

REOAS and the PAL version of Outbreak
by d
I just thought it might be worth a try to use the actual state of the server and connect with the european version of Outbreak. So I redirected the missing app01.reo.capcom.yav4.com to my server. This time it's listening on port 10127. The game connects, the server sends its packets but unfortunately the game won't get over 8% on the loading screen. The game doesn't send any packets to the server, maybe the first packet from server is wrong :-/ This is disappointing and it means we won't have an alternate server for the PAL version unless

- someone has old packet captures for it
OR
- someone reverses the main elf file and figures out how the packet structure is working

For the moment I don't see any chance for either option. So I am really happy I can concentrate on the network packets of the japanese File#2. After analysing the packets for the area selection screen I will add the neccessary code to the server. Be asured that I am wondering how long it'll take until the 2nd stage of the server for ingame communication can be done...

=====

Debugging the code / area selection screen
by d
What happens in C when you are traversing your linked list and one of the functions deletes an element between? Mhmm, depends on the program you are writing and in my case the server dropped an important packet and therefore functioned bad for the area selection screen. But once debugged something amazing appeared ;-)

[Insert video. I don't remember which it was.
None of them can be accessed now, since they've been deleted. :\]

Perhaps you recognize that all the areas have the same name, the same description and the same amount of users. That's because I am mostly playing around with the packets and the real server functionalities for userlists, area settings and so on have to be built later. One step after the other :-)

The bad news are that I think my aged PS/2 is dying. Loading times are increasing constantly.

=====

Small delay
by d
I know you people are waiting for some astonishing news ;-)

Fact is that I am structuring the code and doing some serious amount of real functionality. Nothing I can actually show in a video or screenshot. So please be patient, this takes time.

Meanwhile I also solved the problem with my PS2. Undusted my old fat PS2, bought a network adapter and added a harddisk. This way I can continue development without bying a new slim and without handling any laser issues...

=====

Gameslots, memberlist and game rules
by d
After a hard time getting my PS2 back to full functionality (thanks to Chris for the help!) I spent again some hours to enhance the REOAS. This time the gameslots from the selected free area are requested by the PS2 and sent back by the server. The database is not set up yet so I just populated the list with a dummy gameslot taken from a real game session. Selection of a slot and viewing its members and rules is also possible:

[Insert 6 images that didn't survive the deletion.]

Remember that this is all running independantly from any KDDI or Capcom servers. Just a simple Linux box with a small but growing server for Resident Evil Outbreak ;-)

Next logigal step is to create a database for users, rooms, gameslots, gamedescriptions etc. and to analyse how the gamecreation is done.