 All right, so my name is Matthew Haltershack. Security Technician with Security Innovation. And just as we get started here, you might notice the mouse cursor pop up on the screen. I've got this awesome little presentation remote that likes to do that. It's a nice little feature, but it's probably going to get annoying, and I can't stop it. Sorry. So anyway, I'm a Security Technician with Security Innovation. I've just got to give them a little bit of a shout out, because one, they're paying for me to be out here. And two, they gave me a couple of weeks of work just to spend some time working on this project. So yeah, I basically do pen testing, application stuff. And I am Joseph Tartaro. I'm a Security Consultant with IowActive, and I play Metal Gear Solid. All right, so just as we start again here, this isn't a development talk. I mean, we're not going to be talking about the programming, like client server or anything like that. There are other conferences that you could probably go to if you want something like that. We're also not going to be talking about exploitation. I mean, there are some exploits that we've kind of come across, but that's not what our talk's about. It's just kind of a cool little project, at least to us, that we basically just rebuild the server from the client. We'll go into a little bit more on what that is. And I mean, if you do a law-free reverse engineering, you're probably not going to get a whole lot out of this. We're not getting super technical. It's basically something that we realized that there was nothing really talking about doing, like trying to rebuild these servers. So we wanted to give something back to the community with that. So the basic project, savemgo.com, was back in 2006, I used to play this online game, Metal Gear Online. And I mean, I was a teenager at the time. Just loved playing this game. And it got shut down after only a year of being online. So I'm like, well, that sucks. Now I want to play it again. It took quite a while, but over the last couple years, now we start rebuilding the server. I'm basically just rebuilt the server after it was already taken down. So unlike a lot of private servers, I mean, we didn't have a live server to kind of work with. We were just left with the client, the client binaries, and not a whole lot else to kind of go from. All right, so the initial problems that you're running into when trying to rebuild these servers is the, at least for our case, the real server was offline. We weren't rebuilding like World of Warcraft where we had an active server we can start playing with. We had nothing. We had a minimum packet capture that somebody from the team had from years before. And in this case, the game had no land play. So we were pretty much stuck. We actually brought back two versions of the game. The original version was on the PS2 and the sequel is on the PS3. So for the PS2 version, there was no official debugging interface. Made it kind of difficult, but we were able to do some memory dumps with an emulator that made our lives a little bit easier. And for the PS3, the game was actually removed with an official update. So we had to use an older version of the game and also put custom firmware onto the console so that we could run on sign code and analyze the binaries and play with it from there. So some of the initial high-level overview. We're gonna start by redirecting the traffic to our controlled server so we actually see what is happening, what's going on. We'll go ahead and implement known protocols, HTTP, stuff like that, that we can already just get up and running with and then start to implement unknown protocols once we actually figure out what they are. So traffic redirection, it's pretty simple, nothing special. You can start by patching the binaries. The issue is for something like the PS2, that's not too realistic. You can't really patch a binary, press it to a disk and mail the disk out to your friends or anything. You'll have to find a different way. In our case, we just did it by DNS. For the PS3, it's a little bit different. Since we can just set up a hyperlink and people can download a binary and throw it on their console, you could patch it but DNS is easy. It's simple, it's what we recommend. So the first protocol that we take care of is STUN. It's really a non-issue. You can run around with a simple STUN damon or point it to a public server. I believe we just pointed it to a public server and it took care of it. It's pretty basic stuff, gets you through. Yeah, we sort of just pointed the STUN server off to a public server now. Obviously once we have the servers up, we're running our own. There's plenty of services available for that. Now we've got the next kind of, the first challenge really that we actually came up with or came up against was the dynamic network authentication system. This is what Sony kind of uses to prevent cheating online and piracy. That's where they're going to do the disk section, seeing like, is this a real disk? Should this use a B online? I believe where they do the bands, like where they check if your console's banned from going online, things like that are all in there. So bypassing this, in the case of Melger Online 1, basically we'd get to this point and it would just say, this game's no longer online, get out. It wouldn't give us a chance to prove we're a real disk. It wouldn't give us a chance to get any information. All it did was basically block. So we had to find our way around. We couldn't just use the piracy bypass where you just patch little parts of the disk to return positive information. You're good to go. So the bypass for games no longer online is kind of something new. I worked for quite a while on this. This was kind of the first thing where I'm just kind of heading this wall and having a bunch of issues. I hate to say it. I really never actually managed to do this. I wanted to kind of have a nice pure server where you could just pop the disk in, no extras, just pop your game in, connect, change the DNS and you can play. And try and do that. I mean, we did find some useful resources. Sony SDK is kind of public. There's documentation for this. But ultimately we just weren't successful at all with actually trying to do this and trying to recreate that part of the server. I mean, eventually I plan to come back to this at this point, we haven't done it. But what I did manage to find in the code is this new DNS connect. It's just a little string kind of laying around code. And if you follow it around, look at words of reference from, you end up finding this function that basically it's like, well, what happens if you return zero? Zero being a nice return code to try. What ended up happening was that let us kind of patch out the actual DNS check. You'd get to the DNS check. You'd be like, here's DNS and there it goes. It wouldn't do anything. It basically let's patch it out. But of course the issue is we've already mentioned is you can't distribute this. You can't press your own disks and just kind of pass it out to everybody to play with. But there are these cheat devices. I don't know how many of you have played like, you know, in some of the old consoles like the Game Genie with the NES or Game Sharks. Anything like that. Magic. Yeah. There are these codes you just kind of enter them and if you don't know what they are, they look like they're just magic. If you look at these cheats here, and they're just numbers, I mean, if you don't know what you're looking at, it is pretty much just magic. But what it does is it lets you overwrite, there's a lot of things that you can do with it, but one of the things it lets you is it lets you overwrite the four bytes of memory at the most. I mean, you can do like just one byte if you want to. You can do a bunch of things. So we can use those cheats. I mean, these few cheats here, this is actually setting up a return, or I guess it's setting up, one of the registers is zero, doing a jump back to the return address and then just a no op at the end effect. So basically all these works is you've got, the first character represents what type of cheat you're trying to do, so C is a condition. It's checking if, you know, the value of memory address A is equal to B, run the rest of these codes and then two is telling you to overwrite the four bytes at address A with values of B. So I thought that was kind of cool. It's just, I mean, they were magic to me until I started looking at this. And then going on to the PS3, you're dealing with the PSN network, so no longer DNAS and the PSN network is currently offline, I think, but it's used for account services, profile, friends list, matchmaking on certain games, commerce, the store, all that crap. So looking through the binary, there's this cute little call for start, dialogue, load async and if you look at it, it reads in a struct. So there's two different network types for PS3 games. The type zero would be a network game, so it would, let me go to the next slide, it would initiate your network device, it would check if your ethernet or wifi is connected, obtain an IP and continue execution of the code. But if it was a type one, which is a PSN game, it does the same as net, but then it also checks if you have a PSN account registered on the system. And if you don't, then it forces you to create one, if you do, then it checks to see if you're authenticated. So lucky for us, that was the patch, just changing it to a zero. And then the issue that you run into is all the other network profile calls are not loaded because it never loads up the PSN libraries, so you just have to go through the rest of the binary and pass these out, fulfill them in some way. In our case, it was pretty simple. We had one for obtaining your network ID, we just bypassed it and then the other one was checking for your age restriction for chat and stuff because it's a mature game, so everyone's over 18. Now if you're doing something like call of duty where it actually uses PSN for matchmaking, it would be probably significantly more involved, but we lucked out, so. Like I said, for the PS3, you can actually patch the binary and distribute it. They're elf binaries, they're packed. The only thing is that it requires custom firmware for you to actually run the unsigned code. So if you are running just a standard PS3 with official firmware, you won't be able to run our patch and play the game, but if you do have custom firmware at home, you can go to savemdo.com, download the patch, and start playing. So the next protocol we take care of is HTTP. Pretty simple. For MG01, it didn't basic account, management, registration passwords. For MG02, it was a little bit more. It would check the version of your game to see if you needed an update, and also this reward shop. It was this in-store shop where you can buy hats and shirts and other crap with points that you would get from killing people. So some of the simple guesswork that we did, well guesswork was just useful. So when you're toying with the stuff at home, you can try things like we just give it a hex 30, which is the ASCII zero as a response, and it would continue. Or a null or something or just a one and just kind of toy with it. The other thing is if you have live debugging, which if you have a hacked PS3 console, you can do live debugging and makes your life a little bit easier. You can do things like break on, send request, or receive a response, stuff like that, and then start to step through the functions and see where the compares are. So for example, there's a picture of a graph there, and you can see a large switch case at the bottom. This is where we just kind of broke on URL decode, went next, and then saw the switch case. Those were all authentication errors. So you either authenticated or the password is wrong, the username didn't exist, there's a session already active, all that crap, right? So you can figure that out. But lucky for us, since we are controlling the new server, we don't have to actually reverse the entire logic. We just need to trick it. So an example of the logic, we can receive the request and then we can just validate it on our backend. So when the server gets username A with password B, we can do all that logic and we just send a generic error or generic success code. So you can kind of use these shortcuts to get stuff working without killing yourself over the binary. Next main issue is SSL. Unfortunately, for the PS3, they did SSL sirpinning correctly. So we were just kind of hitting a wall. They somehow did it correctly in the year 2008. No idea how. And so we had to patch it out. Once again, that's actually the main reason you need custom firmware. Some of the other options, if you're doing a different project, could you buy the domain, could you do a self-signed cert, downgrade it, whatever, take over everything? Is that legal? Who knows, right? All right, so most of you are still here. That's kind of the dry stuff. Going through all the no end protocols. Now we're kind of going to get into is the game protocol itself. The custom made, I think some people have quite quite the Konami secure communication protocol. I don't think there is an official name for it, but basically it's their game protocol. It's what they're using. And this has no documentation. Nothing really available, except for looking at what the client actor starts sending out. So of course, if you can have packets, in our case, server's dead. You can't really get packets, but if you have them, everything becomes much easier. You look at the packets going in, see what comes out. It's a matter of figuring out that transformation. It's just coming down to kind of examining and comparing everything. So these are some of the packs that we would get sent out. I'll know how many of you here kind of read Hex fluently and you can just look at this and be like, oh yeah, yeah, I get that. But if you're normal, you kind of have to go, okay, well, there's some numbers. I mean, maybe you recognize, you know, 41, you know, the A. You recognize a few letters in there, some things, but it helps if you just look at the ASCII. So this really doesn't make sense either. But there is the A. I got that one right. But you kind of look that. But if you look at this long enough and you start comparing what's coming on, these are just packets being sent from the client. They're just trying to reach server. We're not replying to it, but it's trying to send these things out. You start noticing some patterns in there. You see the Z, the P, Z, P, and you see that kind of repeating and they're in the same column. You start to know some patterns. That's five, eight, seventy. Well, you look the numbers beside that. You start seeing like 85 comes up next. And you start noticing more and more of the AF, the 85. And if you haven't seen this before, or if you have seen this before, it's really easy to know what's going on. But if you haven't seen this before, you might waste a lot of time trying to see like, okay, you see the pattern. You know there's something, but you're not quite sure what it is. You've got no no bytes in there if you notice. And you've got kind of that repeating four byte set of characters or four bytes. It's XOR. They basically just had a hard coded key in there, which was the five A, seventy, eighty five AF. And they just XORed the packets with that key over and over again. Very, very secure protocol. So you run the XOR. You run that XOR and things start to make sense. This is another packet because the client one doesn't really help too much. But in this case, we did actually get a packet capture at one point after the project had been running for a little while. So it didn't have a whole lot of functionality. Didn't have create game, didn't have join game, didn't have anything you'd want as server. But it was a packet capture that helped us a little bit. This is one of those packets where you can kind of notice some of these letters there. This makes more sense than the other packets. I mean you could see MG3, Snake, Liquid, MGS3 League. Having played the game, I know that those are the lobby names. And you can see IPs in there. Those are fairly clear. I guess I'm getting ahead of myself here. I'll get back to this packet a little bit later when we go into actually reversing this part. But in terms of the protocol itself, this is what's kind of coming out. These are again the packets being stamped by the client. It looks really nice like this. This will have been really easy to look at and try and see things that are popping up, little patterns. Notice you've got a counter there. Two, three, four, five, one. You can kind of make a guess there. That's probably some type of sequence counter. I mean at this point it's just guess work, trying to figure out what's going on there. But it's a reasonable guess. Then you look at this one. It gets bigger as the packet gets larger. Perhaps it's some type of size. These ones took a little bit longer, but they seem to be like a command identifier. Whenever it sends the same command, it'll send out the same first number. Some of these other parts will change, but that first two will stay the same. And then you're left with that larger payload area. At this point I'll get into that content a bit later. And you're left with these things. They're kind of random, kind of like, I have no idea what these numbers are. What I tend to do when I see random numbers, my first thought every time are prime numbers. This is not prime, but that's my thought every time, and it's been right once. So I always think of primes. But the other thing you can kind of look at is just take them out, stop looking at it as I just have, and maybe this looks a bit more familiar to most of you. It's basically an MD5 of the header and that payload area. So it's somewhat random, depending on how you want to count the collisions. But you start kind of figuring out the protocols. You start comparing these packets, start being able to figure things out. You see the header's always eight bytes, the command identifier, the length, the sequence that hash followed by the payload. So now as we start jumping into the actual payloads, if you've got the packet capture, I've already kind of mentioned this. It's really easy to just look at. You can replay the packets, you can send them over and modify little things. You can see what happens. And you're just trying to determine that transformation coming between those packets. So we started looking here. I mean, these are some of the actual packets coming through and you'll see like, the commands always seem to be since 2001. The server reply, this is from our packet capture of the few packets that we had. And the server reply with 02 and 03. It's a pattern that we started noticing in the loft stuff that came up. And then we also noticed the blue numbers there, the sequence kind of adding up in each one had its own sequence. So this is back to that same packet I showed earlier. Looking at a nicer format, you can see the league name, or you can see the lobby names, you can see IPs and CDEF. You can see those things there. If we pull out those numbers, I mean, it's pretty easy to guess the first bit there, the snake, like what those are lobby names. At this point, we had never seen the gate and account, but you can kind of make the guess that those are probably just servers that they use in the backend or communication for authenticating and for kind of logging in. For some of the backend services, the IPs are pretty obvious. Some of these other numbers though, you've got 01, 02, 04, it's kind of the first numbers. Obvious thing is it's probably an ID, just counting up incrementally. These ones were a little bit different though. You've got 01, 222, 222 for all the other leagues going in there. There's actually normally 10 lobbies being sent, cut most of them out. So you can kind of look at that and game-making some reasonable guesses. There are some educate guesses there, 01 referred to that game and account we had never seen these before. We can just replay that every time. And then the two is probably the league or the lobbies that are actually showing the snake, the liquid and all of that. These numbers though, haven't quite figured out exactly why they are, but that seems to be like some type of globally unique identifier. 01, 02 for the account lobbies there, but ABC, you're kind of missing everything before A. My guess is that the Japanese server, which was up before this one, would have had the ID with those numbers and then Euro and the North American servers having their own identifiers. Just a guess, those numbers actually didn't actually have anything or didn't impact the game play itself. So it wasn't too much of an issue that we don't know exactly what's going on. And then the other one, 00, 90, 00. Gain, educate guess from having played, 90 is probably the amount of players in there. So we started modifying some of these and you know, set up my own IP in there, giving the CD, FG and ABCD. One note about the CD, FG. Actually, I don't need to go for that. Basically as we changed all of these things though, we immediately saw it being replayed out there. Lobby A, Lobby B and Lobby C, exactly what we'd expect. We did notice that it didn't care if you had a null byte in there or not, if you notice the A is a little bit longer than the B and C lobby names. Just kind of some places it cared about the null, some places it didn't. It's kind of an interesting thing that we were able to exploit later on. So that was easy. So that was an example of when we actually had packets with the packet capture. A little bit of harder way is when we're just in the blind and we don't have a packet capture. So how can you determine payloads? Are they in any special type of encoding? So, Jason, whatever. Are they encrypted? What's going on? There's a link in there if you download the slides for a nice little write up on crypto stuff. It's all over my head. You can download it if you want. So what do you do? Like there's no known format, but we at least know just from looking at the earlier payloads that the first four bytes are normally some sort of error code. And if they're all zeros, then it's a success. And then the server command is usually plus one of the requests. So that's why you saw the 2002, then 2003, 2004 for the responses. So we just started experimenting. If something came through and we had no idea what it was, give us some zeros and see if it continues, right? If the next command you just added one, if it was correct, it would go on. If it was incorrect, you might get an error displayed back to the user or something like that. So we were able to go ahead and start looping identifiers to see if they were even valid or not, because the gate server would respond with the command that you gave us. So if we gave it 2222 and it would just not respond because it wasn't expecting about 2223, it would come back and say we weren't expecting that. So you know that that's at least a valid command identifier. So it's kind of similar to the HTTP crap. Do some guesswork, blank responses. You can do null, null bytes, hex 30s, fake successes, and just kind of try to continue the game for moving on. This is similar to before where we didn't really kill ourselves trying to reverse every single piece of logic. We just wanted to get it to work to play again. So I already talked about that. Okay, so exploring items. Here's an example of a payload that we didn't really have. You look at it and you have the initial number at the beginning of the 24. We just assumed that that's a number of items that you own. And we knew that just from the account that we had. And then the first byte you can see is starting to ascend. And then the four bytes after that, they seem to be slightly different. They turned out to be color codes for the different items. So we just started playing with that and sending it to the client and seeing what changes were being made. So for example, for the headgear, we just sent that we have zero for the beginning number and nothing showed up. So okay, we have none. But now when we add one, hey, we got a little hat, cool. So then you can just start enumerating through these different values and figuring out what pieces go to where. So three leads to that color, seven leads to that color, and you can start mapping out everything. And then for the shirts, for example, we put zero, but some stock item came up. So what really helped us out is there are different portions in the game like this where if you give it unexpected data, they had a stock response that would just deal with just so the game wouldn't crash and die. So that's what you're seeing there. They'll just give you some sweater. So then when you add one, then you suddenly have a T-shirt and start mapping it out. So this is kind of something funny. Nobody knew about this. We just found it in the files while enumerating. This was like never released at some sort of Japanese like wrestler mask or something. It's kind of cute, I don't know. So what was interesting is as we were going through all these, we realized that there were actual DLC items and DLC game modes that didn't even come out until later versions of the game, which was kind of like a dick move, because you knew that, hey, they had this stuff in 1.0 and you had to pay later to get it. So I thought it was kind of interesting. But as you can see, it's slow and tedious. It's not too difficult. It's just having to map it all out. So what about a little bit more complex payloads? You still don't have a packet, but simple basic guessing might not work, right? So one example is the friends list. We, now the reason we know it's a friends list and other things like the gear is we're watching the packets and as we go through the menu options and hit friends list then we see the command it's setting. So we start sending this simple basic guesses back, the null bytes and a's whatever and nothing's working. We just keep getting this error. So then we went back and started actually looking at all the different types of packets that we're seeing. We're seeing client update packets which are saying, you know, I'm the client and this is whatever's going on and that's it. Client request packets like, hey, I'm the client. What are my settings or what do I have here in the server sending response back? And then list packets which are saying, hey, I'm gonna start sending you a bunch of data and then the next command is sending the data and the command after that is okay, I'm finished. So that's what we went with. We went ahead and took the first command and ran it through with zeros, took the second command after it and just left it an empty payload and then the third command after that as a success. And we have an empty friends list. So then we can start playing from there. What happens when we start going through that middle list data and filling it with stuff? So let's fill it up with a bunch of a's and we have friends, yay. So now we can start mapping it out and we went ahead and as you can see, split up the bytes so we can see where it's going and what data is going where. You can tell it's not starting at a's. It turns out there's a bunch of data in the background that listed where your friend was currently playing, what lobby is in, what room he was in and all that and then the end data was just their player name but that's kind of how we mapped out what was what. So, yay. So yeah, having that output to kind of play around with you can experiment. You can send different data and it becomes easy. You just look at what changes and it works but joining a game. I mean, this is what you want with a game server. You want to be able to join a game, play with other people. And yeah, we could create a game at this point. We could run around in a map on our own but you're not playing with anybody. You're just running around on a map alone, forever alone. So anyway, for joined game, I mean it was a complicated set of packets that actually ended up being several packs that need to be responded to. So there's no packs that we can work from, no packet log. It wasn't something that we could easily guess. There's nothing similar. Just kind of had to start working at it there. So there are several menu items here and these kind of helped us figure out what it was trying to do at certain points. Join game, when you'd first try and join the game, it would actually send the same request as if you had selected the host info button. So you can guess then. Okay, you try and join a game. First thing it does is it tries to get the host info. Makes sense. I mean, and with the host info, we're able to play around with, or we can see that data so we can experiment and we can figure this out. That packet itself was easy to figure out just play around with the data, see what happens. The next step was player stats. Again, if you, inside the player list, you can make the player stats request. So we knew what it was. We didn't know the proper response. And this is actually probably the most difficult pack to figure out and this is another place where we didn't figure it out yet. A request of player stats, right? We know generally what it's trying to send, just not the exact format at this point. So we started looking though, we were looking at doing some static analysis. They're just looking at the elf. This way there's no debugging functionality on the PS2. But what we did have was the emulator for the PS2. Could load that off of my laptop. I can start the game. And if you make a save state, it'll actually save kind of the emulators version of the memory. So somewhat accurate. It will at least let us see kind of the code after it was unpacked in memory. So the next thing then, if you've got the code or the disassembly, not necessarily the code, you can start looking for, trying to find that code path where your interesting code is. So what you can do is you look at nearby strings. In this type of game, you're not really having too many nearby strings, but we did know that the request is at 4103. So that was the number we can look for. Turns out that happened several thousand times in the file and wasn't too helpful. But the XOR code that we mentioned earlier, those four bytes, that only happened a couple of times. So we can actually follow those, the XOR and we can follow it along until we found where that other number came off in this nice little, look like a switch area where it's just branching if the number's equal to, or if the comparison comes out to zero. And you follow that along, you see a function call. So again, we couldn't figure out exactly what was going on there, but what happens again, if we just return zero, so we know that's all it's doing, it's always looking if something's just zero or not equal to zero at points. So you can either follow through and figure out exactly what little check is going wrong, which is the ideal case, or and then determine what data would make it pass. Ultimately, we couldn't figure out what data would actually make this pass. So we did have to patch it, that was just returning zero. We just wanna play, just patch it out and get going. I spent a lot of time trying to do this though, I mean, because I wanted to do this server as pure as possible, just doing everything myself. Made me take a whole lot of extra time. So we ended up patching this in just a little code home. We can't like add a lot of extra functionality, but we can patch a few things here and there. So this is something that we decided to do that for. So now we have a requesting the game information, we have a requesting the players, we have a requesting the player information of the host, which is the pack that we just patched, and now it sends another new packet request or another request coming out, 4320. Of course these identifiers, I mean 43 usually are the first two terms, they're usually kind of correspond to groupings, like authentication was always 20, 43 generally had to do with your game setup. So 4320, it's something about the game, but we don't really know what. That's why I'm trying to use some external resources so we can jump towards googling, getting this being kind of a private protocol, not a whole lot of information, but there was a game that came out shortly after Metal Gear Online 1, which is Pro Evolution Soccer. And this game was like five months after it had a PC, or a PC version. So someone had already kind of figured out some of the protocol on that, a lot of it was different, but there were some similarities. And Metal Gear Online 2 was still online at this time, but I didn't like that game, so I wasn't even trying to build that server. But it had that particular packet, so just using that external resource for a kind of able to figure out what it was, and what it was asking for was basically IP information, the host external and internal IP for connecting to it to actually play the game. So we actually had the client trying to connect to the host, which is exactly what you want, but the host would suddenly just send 4340. It's like, okay, you're connected already, you're talking to each other, why do you need to ask the host for something else? And Metal Gear Online 2 didn't have this, Pro Evolution Soccer didn't have this. I think I looked at a number of other games actually, trying to figure out something that maybe came out at the right time of portable ops, another Metal Gear game, it didn't have this. Nothing had this, it's just this unexpected packet coming in. There's no error message because it's the host asking for this while it's already in the game, so it's not going to display anything, it's just going to ignore the client if it doesn't get the right response. And the payload is just the player's ID. So the kind of obvious guess there is, maybe it's asking, is this player okay to join? So it's ended a success, that didn't work. So we ended up starting to follow it through, looking at the assembly again, just kind of sitting in there, okay we found the 4341, these were all in the same place, by the way, once we found the one area, we could see all of these commands. We see where it branches, we see where it jumps to, and it makes a lot of calls but was never checking the return values of these calls. All we do is it would read four bytes after the initial success error code. So we started looking, and what we ended up realizing was basically that with just loading those four bytes, what it's asking for is basically an echo. Send it back, the player's ID that's trying to join. And that was basically our structure. So from that... It was the only packet that did that, so stupid. Yeah, it took a while there. This was kind of my breakthrough. I mentioned how I had two weeks to work on this server from work, from my employer. This was where I spent most of that time, figuring this out. Took pretty much a week and a half of solid time just to figure that little thing out. So we're jumping through this really quickly, but it took us a lot longer than what you're seeing here. Yeah, so we were successful. We finally had the game connect when we figured out that response, and we were able to actually play a bit. So what we've got is a quick video from the server. I don't know how many of you have actually played the game, but we're just kind of showing how it's working. Yeah, I mean, just most people don't really know the game, so this is what it looked like. You fight after a frog. So, we'll move on for that. All right, so what's next? Like, we got the actual game working, and I actually like MGO2, so I got that up and running because he didn't want to. So what's next from there? As you can see, there's a map file. One of the guys on the team, there's a team of about five of us that worked on this. He started going through the actual game files which had their own sorts of like, encryptions and encodings, and it was a completely different world. You can probably give your own talk on just those files, but I thought it was pretty neat, so I thought I'd mention it. And right there, you can actually see that he pulled out a map and was actually able to make modifications and loaded up a custom map in the game. So, you know, just kind of hacking on everything at that point, we might even have like custom game modes soon. But yeah, it's just kind of, you can just keep running with it. So yeah, I've already kind of touched on this, but for each of the games, Metal Gear Online 1, they talk about 10 months of work, off and on. I mean, this wasn't like eight hour days every day for 10 months, but off and on work for about 10 months, and Metal Gear Online 2 took about the same amount of time. In this little talk here, we've shown about six different commands, whereas in the AFTEL servers, we deal with about 80. So there's a lot of stuff missing here that should just kind of an overview of some things that we found helpful. A lot of headaches, a lot of frustration, and no real existing reference material for us to work from. Nobody really talks about building servers from something that's already down. I mean, you've got some talks on building like private servers for games that are already up, where you can just look at what the server responds, but nothing really about this. And the other thing is people are crazy at times. A lot of trolling, had people, when we were looking for the pack to capture, had a lot of people command saying they had it. Oh, just let me grab it, and then they disappear from IRC for the next year. And just gotta leave us there. And a lot of random people that want to sue you for some reason, they're not even related to a company. There's some dude on IRC who's gonna sue you. I don't know, whatever. We had one guy who spent a lot of time trying to convince me that he was talking to Konami and how they were getting ready to prepare a legal suit against us. And how he wanted me to remove his account because of this. He didn't want to get tied in with it, so I removed his account. He comes back a few days later asking for me to let him back on. So he wasn't really talking with Konami. The other real issue there is copyright, DMCA. Running these servers in the US, we have to deal with kind of DMCA. We have to worry about that. And there is an exception for building things like this as long as you don't violate the terms of service. In our case, since the server was down, it would, when you first connect to the server, it would request a policy.txt file from the server. Doesn't exist. So we were on the server, we control the terms of service that we're agreeing to. So of course that was basically not much of an issue. Where the issue does come up for us was Sony, their DNAS, mentioned that early on. The terms of service for that were still potentially valid, although the terms point to a non-existent URL. So I don't know where that stands. So, well, actually I was gonna say this is fairly recent, but I got in communication with this guy, reached out to me, he was doing a similar project for an old MMO on Commodore 64, bringing that back up. And he reached out to the EFF and they came to us because they saw that we did similar work. And they're trying to actually push through an exception for projects similar to this, where it's software that is no longer managed in the original company just is doing nothing with it, that you can kind of reverse it and run it up there, as long as obviously you're not taking payments or anything for it. But I thought that was kind of cool. So yeah, I mean, there's a lot more to this than just what we've shown here. But it was fun, at least looking back on it was fun, maybe not at the time. So just some credits there, I mean, the two of us here, he was mostly focused on Melgar Online 2. I did the first game, Giga Heard's gangster, Derek. He worked actually on both. He was the only guy working with me at first on the Melgar Online 1 server. The Fog did another PS2 game. They revived that one, Resident Evil L Break. And he helped us out actually really early on with some of the ground breaking with that initial DNAS area, some of the first protocol stuff. He did some of the initial ground breaking there. I mentioned Pro Evolution Software in that server that was done by Halston, which I just kind of randomly contacted him on Twitter. I'm like, hey, you did the server? Is this true about the protocols? Is this true? And I don't know what he was thinking at first, but it took a little while before he finally responded to me and I was able to balance a few questions off of him. And then we've got, what the fuck are you thinking one? He's helped out with some of the PS3 stuff, some Melgar Online 2 stuff. And we're a crazy friend, Jay, who was doing the map work and a lot of the file stuff. And one thing I forgot to mention is the PS3 work. This GitHub right here, there's a lot of great IDA scripts if you're ever analyzing PS3 Elfs or libraries. They'll just map out all the functions for you. It's excellent. So you should go download that if you're ever gonna look into it. And yeah, I guess if anybody has any questions, they could obviously just email us or reach out to us on Twitter or come up in front of everybody and ask it. Yeah. Okay, thank you very much for that applause and thank you very much to our speakers. Any questions? I see microphone four. Hello. So you've spoken a lot about the protocol, joining games and enumerating servers. How more complicated is it once you're actually in the game? What do the clients send to the server? Like how much of the actual game logic is on the server or is that really just passing messages between clients? Please a bit quieter. So the server protocol or the protocol that we reversed was actually the controller, the gate. One had actually got to the gameplay. That was a separate protocol that was all peer to peer. So once the actual consoles communicated, they hosted their own games. We started looking into that a little bit just for shits and giggles to kind of like play around with the game, but to actually get it all up and running, it was the main controller just to get the consoles communicating. These, everything was hosted locally. Oh, cool. Thank you. No problem. Okay. Can you give the askers a bit more quiet, please while it's going out? I see microphone one. Hey, great work you did. Just a pointer if you run into legal troubles. The German National Library is allowed to crack copyright protection on at least on books and music. So I don't know if the same situation applies in the US, but national libraries, museums would definitely be the place to look for because they do have some exceptions. Yeah, one thing with what we've got with the DNS system is you can actually use our bypass to do any piracy. It doesn't actually like you do that, but it is a break of the system. So it is, maybe it's not a gray area, I tend to think of it as one. We've taken a few steps to kind of make it, not necessarily difficult to take any legal action gains but I mean we won't take donations so there's no profit in coming after us besides a negative publicity for taking down the server. Obviously they still can do it, Sony can do what they want. Yeah, the company is well aware of the project. They have not publicly acknowledged it, well actually they did on Twitter last week, but they won't really discuss it actually. I was in Seattle, it was like a year or two ago, and the developers from the team were there for PACSEC and I just like kind of walked into the VIP area and was chilling with them and we went out partying all night and getting drunk and stuff and I kind of kept open communication with them and when I was working on this, we were kind of chit chatting and then I sent like a question about the protocol. I was like, hey, I noticed this, like could you give me some info? And it's just been like radio silence, just like immediately stopped communicating with me. But other than that, the company has been like totally cool about it and the new version of their game is actually coming out soon, they just released a trailer for it so we'll have to revive that one soon, so we'll see. Okay, microphone two. Hi, thank you and I have a question because somebody already mentioned libraries, national libraries and stuff and I actually wonder if there's a place maybe like libraries for Ethernet captures of the games that are basically so that somebody like players can send in their captures such that once a server goes down, it will still be able to reverse engineer something because I imagine that for some games that are down already and where you didn't get to make enough captures, it becomes very, very difficult and I would actually love to see the possibility of many games that I love coming back like there's this German game, I think, Battleforge, which was shut down a year ago or something and I was very sad about it and but I imagine it's very difficult now to somehow bring it back. Yeah, you know, that would actually be really awesome if people were to do that. I'm not aware of any sort of like database of packet captures for games, but it would be awesome because the moment we came out with this and went on Reddit and kind of did like a little write up, he did and that's kind of what sparked the talk because that little Reddit write up got so popular. There were like tons of people like you like, oh, well revive this random game, revive this, revive that and it's like, well, there's only two of us and I've never played that before so I really don't care. But yeah, like it would be cool if we had a bunch of packets like that because for example, we were stuck with no packets and the moment we figured out the structure and the idea, we could have knocked it out in no time if we didn't have to sit there and figure out 80 different commands, right? So it would be really awesome, might be something you should start up, yeah. Yeah, it definitely does not exist right now. It's something I actually thought about a little bit trying to start selling but I haven't gotten around to it. Is it legal to do? Packet captors or shouldn't, I'm not a lawyer so I'll practice it with that. I don't see why not. But packet captors shouldn't have any issue, I mean most places will log their own traffic like companies do that so I can't see the captors being an issue, the servers can be a problem but the captors shouldn't be problematic as far as I know. Yeah, because like for example, for the MG02 stuff, like somebody had a packet capture but they didn't have a packet capture the actual game, they just had a packet capture of the authentication and all the web stuff before but it was all behind SSL so it was pretty much pointless, right? So, but yeah, that would be cool and if people actually got captures of the correct data it would help out a lot and then teams could run with it. So cool, I think that's everything. Okay, the signal that we got for externally signaled questions. Yes, the first one is there was a presentation at the 29C3 or 30C3 with reverse engineering protocols using NETSOP. I never tried it, but I want to know if you have tried it and if yes, if you did find it helpful. I've not tried it. I did not understand what you said. I did not understand what you said. Did you hear? Some of it, we get repeated. Did we try what? Did you try a tool called NETSOP? Oh, Netspark? Netsop, N-E-T-Z-O-B. Oh, is that like a tool for reversing protocols? If it was, no, no, it did not. We just did what we showed you just kind of lining packets up and I guess we did it in old man style, I don't know. I guess if there's cool tools out there you should use them. I'm not aware of any. I should Google more often. Yeah, we learned a lot as we did this. It was a learning experience so I'm sure some of the things we've done are more effectively done by someone with more experience. Yeah, another question is, I noticed earlier that the game used MD5 to protect packed integrity. Why do you think they choose MD5? Would it make more sense to use the smaller CRC32 to save some bytes in the stream? I mean, I guess it would make more sense if you were the person designing it. That's just what the design they went with. The first game was actually the MD5 of the payload plus the header and the second game was an MD5 of the payload header plus an HMAT key, it's like a 16 byte key. But that's just what they ran with. But I guess, yeah, if you could do a simple CRC, check some and it would run with it. I don't see why not. It would be less of a size. Is that everything? Yeah. Another one, would want to know, was there no hardware debugging option, perhaps JTAG? Could you say the last word again? JTAG. JTAG, not on the PS2 for sure. Yeah, for the PS2 there was some homebrew for a debugging interface that some people used. For the PS3, I was actually able with the custom firmware put on the debug firmware, which let me hook a debugger up straight through the port and just debug it with the leaked debugger that I didn't use that's available online if you Google. And that was it, so it was pretty much easy. But for the PS2, but yeah, we didn't do anything hardware-wise for this. We didn't have to use JTAG or tap into the board at all or do any sort of signals. It was installed through your homebrew and through the cheat disk, so. Yeah, he kind of mentioned there. There was a kernel patch on the PS2. Sony used their own kind of debugging interface that I think it was called DCMI or DMCI. And it was basically their own little communication thing going on there. The PS2's officially didn't support it, but some kind of reverse engineered that and added support if you can mod your console and then you can kind of flash some of your own stuff into it. So that was actually used a little bit. It was fairly late in the project. We had figured most of this out. It did help with some of the steps though. So it's not the JTAG, but that was something that was imagined here. Yeah, and the last question, can we imagine, sorry, can we imagine a framework API or tools to help the reverse engineering of a game protocol? An API to help. I couldn't imagine it because each game is going to be completely different. For this case, what we're dealing with is a Konami gate protocol. So maybe we can toss something together and it would help you reverse Konami games that use the same type of gate server. But I would almost put it in the same boat of a web application. You can write a burp extension to do something very specific on something that you're using, but unless somebody has the same exact thing they're doing, it's not going to be useful. I'm assuming people will have to kind of roll with their own. Yeah, I mean, I had plugins there. There's things like that. Wireshark plugins, like I did one while I was working on looking at the protocol. I had a Wireshark extension on there, but. Yeah, it would only be useful for the Konami protocol. So it really depends on what they're trying to reverse. I don't know if all the Call of Duty games use the same type of network code, like maybe you could do something where it helps you reverse all those or other family of games. In this case, it helped us reverse all the Konami type of games, so. But yeah. Okay, all questions done. Then I'd say thank you very much for this exciting talk.