 Hi. How's it going? I'm Mon, and this is Ha here, and we're here to give you guys a talk about malware migrating to gaming consoles. Okay, so the title pretty much says it all, but this talk is going to be about how malware can be infected into gaming consoles, and the consequences that can follow, and some possible defenses that can be taken. And also as a side quest, we're also going to see how gaming devices can be used as attacking tools. So to give you guys a picture of what's going on, this talk is going to be about embedded systems, and how attackers can use the hardware of these devices to their advantage. And embedded devices have been around for years, so the security of these devices was only recently recognized by the general public. So you can say it's kind of old, but new on the security side. So there's lots of new things still waiting to be discovered on the security side. The thing is, not so many people are fully aware of these issues, so these devices can make a good target for attackers, and cause a lot of these devices, particularly smartphones, carry a lot of important personal information. And we're going to discuss about these issues with a couple of real world examples. Actually, a lot of real world examples, so we can make this talk a little bit more interesting. This is how the presentation is going to be laid out. The second part is actually going to be divided into two other sections. The first part being how to abuse embedded devices as an attacker. And the second part is malware on gaming console systems, and we're going to start out with a little background knowledge and then move on to the more interesting part of how attackers would use these systems to accomplish their goals. And finally, some possible defensive measures we can take to ruin the attacker's plans. And here comes the obvious part, background knowledge. The pirate scene of gaming console and smartphones. Now, everyone here should know what piracy is. It's like common knowledge. Illegally downloading and installing paid software either by hardware or software modifications. And a couple examples are shown on the screen, like a hardware modification on the gaming console, on the left side, and then on the bottom the Nintendo R4 to play free games on the Nintendo DS. And everybody's favorite, iPhone, jailbreak. Okay, as soon as someone finds a way to bypass the security on a device and make piracy possible, a massive amount of users dump and crack their games and software and distribute it using either Torrents, P2P, or web storage like RapidShare. And then the download link or Torrent is freely distributed to the public, so all the general users can download them. And this is also how malware is going to be distributed, which I'll discuss about in a moment. And, okay, we know that there already is embedded device malware running in the wild for quite a while. But just to give an example of a couple of these, we had on gaming consoles a malware that looks like a homebrew. And it actually does have useful features to make people install these homebrew malware, I mean these homebrew. But the attacker made it so that it had a separate thread running in the background doing lots of other sneaky stuff. And all this is possible because the author of the homebrew application is the author of the malware itself. And he can choose to add whatever functionality he wants in his own source code. Of course, he would have to release a clean version of the homebrew to the public, but the executable file will have the malware contained inside. And nobody will really recognize unless someone is monitoring the network or attempts to reverse engineer the binary, which not so many people do. The second case is a cracking tool that advertises itself as breaking the security of a device, somewhat like jail breaking, and makes the users run it on their system, but then eventually it just wrecks the machine and breaks the system or something like that. And these are the two kinds of malware on gaming systems that were publicly discovered so far. And on the other hand, there were quite a few malware on smartphones. A couple of them are presented here. But I'm sure that there's a lot more that anti-virus companies obtained secretly, but they didn't release to the public. And these are the more popular ones that were made public on the web. And the iPhone malware targeting default passwords and Windows Mobile, Symbian, and Blackberry malware. And there was even a toaster root kit that Matt Tesano showcased a few years ago. Some people might know. And there's, of course, the Android root kit that was discussed here at DEF CON a couple of hours ago. And now let's see what the general public thinks about this situation. And the thing is generally users don't even think or want to think that malware runs on these devices because that sort of stuff gives them a headache. And they just think that the application they're installing right now is completely safe or somewhat safe. And they usually only see that the application is running properly with no error or crashes. And personally I don't think any normal person not related to security in any way will think that malware is running on their device until a big black screen pops up saying that your device has been hacked, rolled on floor or something like that. But anyone who has common sense will try to make a malware as stealthy as possible. So that's one thing that brings a false sense of security to the general users. And however, these devices have all the necessary hardware to run malware. So even recent gaming consoles are becoming so much like a computer that it's becoming questionable whether it's impossible to run malware on these systems. Now the question is how would an attacker use these systems to their advantage? We'll start off by showing gaming consoles as an attacking tool because the method of generating attacking tools is the base concept of generating malware on gaming consoles. So we're going to start with that. And we already know that gaming consoles have high quality hardware and a lot of people contribute to the gaming console hacking scene eventually bringing it to the level where homebrew applications for that particular system is possible, generating homebrew applications. So having a complete development environment for homebrew applications an attacker can effectively create tools that run on the target gaming console system. And the advantage of running these tools on a gaming console is that bringing a gaming console in a corporate or company will make people less cautious than bringing a laptop or a computer because generally people don't think that gaming consoles can be used as an attacking tool. So this is how the scenario, attack scenario goes. The attacker connects to an internal network in a company and performs any kind of attack possible within the internal network. And essentially the concept is pretty much the same as attacking an internal network with a smartphone but a Nintendo DS is used in its place. And now we're going to show a couple examples of what kind of attacks can be performed using these concepts and the first demo is using Nintendo DS to attack a remote host using a known exploit and compromising the host. So we'll put the camera on screen right now and this is a Nintendo DS that has all the tools needed for attacking and it's going to attach to the network with wireless. And as you can see the DS is running games with R4 and we're going to run our homebrew MetaDsploit which is already running already. It was inspired from Metasploit so the name might be a little queer but anyway. We're going to search for a usable access point right now and there's one called IP time. If you see an access point with the name IP time it means nothing's been touched since the router was purchased. So it most likely uses a default password so we're going to use that one. And successfully connected. And now actually there seems to be a problem. Okay, trying again. Okay, there seems to be some wireless issues here. But this is embarrassing. We kind of predicted this would happen and we... Hold on a sec. Okay, we're just going to skip this demo then and go on to the next one. Okay. This one is a video to show you a live demo. I mean we can't show you a live demo because live demos take a little long. So a lot of these demos we prepare for videos. And one of these...this is one of the videos. Just a sec. Okay. This is an attack using ARP spoofing. And we assume that this is either a home network or an internal network in a company. And the bottom screen is... Oops. Bottom screen is there to remotely access the two computers on top screen. And on the bottom screen... Okay, I'm sorry. Let's try this again. And on the bottom screen is used to remotely access the two computers on top. And checking that the internet works by ping Google. And we're going to constantly ping Google to see that network is up and running. And same goes with the second laptop. Yeah. And the network appears to be running on both computers. And Wireshark will be running to monitor the packets. And now we're going to run the ARP spoofing DS homebrew. So connecting to an access point right now. Starting the attack. And as you can see on both computers the ping is timing out. Meaning the network has gone down. And Wireshark is showing that somebody is tearing down the network with ARP spoofing. And then finally, yeah, Google cannot be accessed anymore. And that's it for the second demo. And we're going to go back to the first demo because our guy seems to have fixed the wireless issues. So this is a Nintendo DS. And we're going to run the MetaDsploit. D standing for the DS. And searching for the IP time router. And connecting. Hope it works this time. No? Come on. Okay. We'll just move on to the third demo. Because the wireless seems to be used by so many people in this room that it's not quite working. As it's supposed to. So. Haha. Okay. This time we're going to show malicious code injecting into network packets using ARP spoofing. So you see a typical computer? What the? Okay, I'm really sorry about this. Okay. And you see a typical computer connected to a home network. And we're connecting to Google to see that there is nothing wrong with the network. And the Google page doesn't look like that. However, it's a custom page we created for testing purposes. Finally. And this is a custom Google page that we created. And opening up Wireshark now to monitor the packets. Now we're going to run the inject frame homebrew. What it does is insert an iframe and a page by modifying the packets. So. Connecting to an access point now. And we're going to set the IP of the DS manually. Because there is a glitch in the homebrew that we didn't manage to fix. But it's just a little extra work. So writing down the subnet mask and gateway and connected. And it seems like the attack just started. And looking at the packets, we can see that tons of ARP packets are being sent by the homebrew. And these packets make the host think that the DS is a gateway. And make all the traffic go through the DS. And the DS modifies these packets and resends it to the host. So when you look at the Google source code again. Nothing's changed because of the DNS cache. So we're going to refresh it now to reflect the changes. And then we see that a new iframe code is injected in the page. The iframe page will consequently load a malicious page created by the malware author. And that's about it for the Nintendo DS. And then now that's it for the Nintendo DS. And now we'll talk about malware on gaming consoles. And we particularly targeted the system, Nintendo Wii. And the reason is that as you can see on the picture on the left side. Wii is marked as the second most pirated system among all gaming consoles. And also according to a survey, a lot of companies put Nintendo Wii in their break room to increase morale. And I don't exactly know why Nintendo Wii would increase morale more than Xbox or PS3. But I've seen a lot of Nintendo Wii's myself at a couple of companies. I visited. So we decided to give it a shot. And now that we have the target system. We should know how games work on the Wii. And all games contain a single file with a .dol extension. Which you can think of as a main executable file. And this .dol file contains all the code needed to run the game. And according to the file format, it's essentially a stripped down version of an ELF file. With the non important data such as debugging data and compiler specific data all stripped out. So when you actually play the game the execution goes from the system menu. And the system menu being the first screen where you see a lot of selection boxes. And to the app loader which does all the initialization stuff. And finally to the actual game. And like I said the .dol file contains all the code needed for the game to run. So that file must be the most interesting one for our purposes. So how exactly would malware be injected? Since we know that a .dol file is basically an ELF file. It seems that the techniques used in ELF malware can be used. But the thing is calling the internal Wii functions is not as simple as using a couple system calls. And there really isn't such thing as imported functions in Wii executables. They're pretty much just statically linked into the binary. So we decided to use a different kind of approach. What we did was statically compile all the library code in our homebrew application. Which is done by default anyway. And fix the image base to some place in the game memory that's not occupied. And after that attach our homebrew application to the game executable. And fix the header in the game .dol file to reflect the changes. And the entry point will be changed to the entry point of the homebrew. And after the homebrew finishes running the execution will be transferred to the game. Which requires a small jump patch in the executable code. And there's also a place in the homebrew that causes problems. So after making those last fixes all you have to do is pack it back neatly into a game ISO file. And distribute it to the public using torrents or POP or whatever you like. And there's a small tool I made that semi-automates the injection process. And I'm not trying to give you like a full walkthrough of how to create Wii malware. But just to give you guys an idea of how it works I'll show you a little demo. First you have to extract all the files out of the game ISO file. Which I won't show you because it takes more than 5 or 10 minutes. And my favorite tool for that purpose is WIT. And this is the extracted game image. Which is Okami extracted. We use Okami here for the example. And normally the main Dole file is at the sys folder. So finding that main Dole and copying to the Injector2 directory right now. And you can see that main.dole file right there. And that has all the game code in it so we're going to copy it. Well it's already copied to the Injector directory. So moving on to the Injector. The Injector needs 3 files and 3 addresses to work correctly. And these addresses can be found in IDA. So we fire up IDA and load up the homebrew. And this is the assembly code of the executable code of the homebrew file. And I'm going to skip all the analyzing part. And this address right at this part this is a branch instruction. And that branch is the last branch taken before the system completely shuts down. So we're going to use that branch as a trampoline to the actual game.dole file. So that's going to be the first address. And then this part of the code writes to some place outside the game address space. So it's writing to an invalid memory. I don't know why it's doing that. But I tried noping, I mean like removing that whole part out. And then there was no problem running the homebrew. So I just like remove, nope that whole part out. And the starting address of that code section is going to be the second address. And the third address is going to be the image space of the game.dole file. So we're going to open the game.dole file in the hex editor. And the entry point is at a fixed location in the dole file. And the dole file format is pretty much publicly released. So that fixed location is E0, which contains the D word, A-0-0-0-4-0-3-C. And that's going to be our third address. And so yeah, you first write the file that's going to be injected to the resulting file. I mean the homebrew application. And then you write down a resulting file that has the injected data in it. And then you write down the three addresses that we just found before. And I don't quite remember the addresses, so I can't quite write it down here. But that's how this injector works. And after you execute it, you have a main dole file that has the injected code in it. And all you have to do is put that resulting main dole file in its original place in the game image. And then you repack it into an ISO. And then all you have to do is distribute it to forums or torrents and places like that. And people will download it. And hopefully, not hopefully, but they will accidentally have malware running on their gaming systems. So that's it for the demo. And this is how the attack scenario is going to look. The scenario is pretty much the same as the Nintendo DS. A NAV user brings a hacked Wii device inside a company connecting to the internal network and plays one of the games he downloaded off the web. Actually, it doesn't always have to be a USB hard drive connected to the Wii. The user could just download the game and then he could burn it on the disk and that would create the same effect. And that game, in fact, contains malware. So all the attacks presented in the Nintendo DS section can be performed on the Wii, including some new ones which will be shown next. The first demo is about malware attacking remote hosts on the same network. And the Wii is assumed to be already connected to the network. And it's also connected to an external hard drive, which contains a game that the user downloaded off the web. So the attacker has a remote access to running in the background to use after the attack has succeeded. And now we're going to launch the game to see if the malware runs. Okay. Unfortunately, the wireless, too many people are accessing the wireless right now and we can't do a live demo in this kind of environment. So we'll just have to go with the video. So yeah, that's the game list screen. And the user is running the game now, which is Mario. And what the malware does is it attacks hosts on the network using non-vulnerabilities or zero days and installs a backdoor on the compromised hosts. So like after the game starts, a new user is shown on the pro-ac console. And you can do lots of things on the target computer like taking screenshots and accessing file system and all that stuff the backdoors can do. So that's it for the first demo. And the second demo is the malware bringing down the network by accessing the router with a weak or default password. And the Wii should be connected to an internal network which we see and we see that the internet is accessible and we have ping running in the background to check the network's condition. The router IP shows 9.49.9.2 right there on the right. And we're about to run the game now. The malware in this one uses a default password to access the router and kind of plays around with the settings in the router. And the game is loading up, taking a while. Okay, the game is playing and ping is starting to fail and Google is not accessible anymore. Let's skip this part. And the router IP is changed to a bogus IP including the DNS and the gateway address. And that's it for the second demo. And the third demo is kind of long, but we're going to kind of skip a lot through it because we don't have enough time. And the third demo is to show a malware redirecting the user's request to the attacker server using DNS farming. So the attacker created a fake DEF CON page to collect the ID and password. And to make the user access the fake page, we run a custom DNS server and monitor the ID and pass info with tail. And we're running a botnet IRC server in the background. So we're pinging DEF CON now, which shows IP address of 173.14. whatever. And now we're going to run the infected game. And the game is running. And the Google and DEF CON sites show the IP, the same IP as the DNS server. So you can see that the user's requests to both pages are being redirected. And the fake page logs the ID and password to the attacker server, which is shown on the screen right now. And when the user access to Google, then Google loads a malicious page. This page is also created by the attacker. And the malicious page in turn downloads a backdoor, actually a botnet client. And in just a second, the client should join, the zombie should join the botnet server, which you can see on the screen right now. So these are the kind of things you can do with malware injected in console games. And this concludes the section on gaming consoles. And next, I wanted to talk a little bit more about malware on smartphones, but due to the time constraints, I guess I'll have to kind of fly through the slides. What I want to demonstrate is that the same malware injection techniques presented in the previous slides can also be implemented in smartphone applications. So we'll first start with iPhone. And basically an iPhone application package is a zip file, and after unpacking it, you can find the main executable inside, which is a Mac O binary. And since malware injection techniques for Mac OS X existed for several years, and all iPhone and Mac executables are in Mac O format, all the malware techniques for Mac can be used for iPhone binaries. The only difference is that after the injection is done, the binary has to be signed and repackaged into an IPA file and finally added to the HECULUS database so the general users can download it. And I was supposed to show a little demo for a proof of concept, but since time is short, we'll have to skip that. And the same thing can be done with Android applications. There's already various tools out there that can modify the APK files and recover the Java source code and other tools that can modify the binary and intermediate code level. And with these tools, the attacker can add custom code into the existing application, either in source code or intermediate code level. So the same malware techniques, injection techniques can be performed on smartphones. And that's all for the attacking part. And the defenses. This part is supposed to be like three minutes, but time, we kind of ran out of time. So if anyone has questions about how to defend from these malware attacks, then you can come to me personally and I'll answer your questions. And so, yeah, that's pretty much it. And this whole presentation was to show you that malware can run on these devices and all the stuff we showed earlier can happen in the near future or it could already be happening right now. So to sum it up all in one sentence, yeah, download games at your own risk or more like download games but play them at your own risk. And this concludes our presentation. And thank you for listening.