[00:05.050 --> 00:08.910] It's like somebody else already has control over the stream. [00:09.990 --> 00:14.530] Oh, there it went. Now it's still doing the thing. [00:17.860 --> 00:19.360] And there we are. [00:19.360 --> 00:21.520] And there we are. All right. [00:21.520 --> 00:24.720] Welcome back. So we have another session. [00:24.720 --> 00:28.700] This time is going to be with our friend here, Jack Baker. [00:28.700 --> 00:29.400] Welcome, Jack. [00:30.080 --> 00:31.960] Thank you. Glad to be here. [00:31.980 --> 00:34.980] All right. And also we've got Fallible here as well. Hey, Fallible. [00:35.140 --> 00:36.000] Hello. [00:36.000 --> 00:40.800] So Jack was going to tell us a little bit, [00:40.800 --> 00:42.720] at least he did tell us a little bit in his presentation, [00:42.720 --> 00:46.100] about how he kind of attacked game servers. [00:46.420 --> 00:49.200] Jack, do you want to kind of give a little bit of an introduction of yourself [00:49.200 --> 00:51.520] and just kind of a super brief overview of your talk [00:51.520 --> 00:55.500] so that other people might get more interested in it as well, [00:55.500 --> 00:58.060] on top of some of the other questions that we're already seeing [00:58.060 --> 01:00.260] in the TrackOne Live QA channel? [01:01.060 --> 01:02.360] Yeah, for sure. [01:02.360 --> 01:04.660] So my name is Jack Baker. [01:04.660 --> 01:07.960] I don't have much of a background to talk about. [01:08.220 --> 01:10.760] This is my second time speaking at DEF CON. [01:10.760 --> 01:13.560] Both times have been about hacking video games. [01:14.120 --> 01:16.740] And for my talk this year, [01:16.740 --> 01:20.380] it was basically about finding bugs in game engines. [01:20.380 --> 01:22.760] So basically looking at the core software [01:22.760 --> 01:24.860] that you build video games on [01:24.860 --> 01:27.240] with the hope that finding bugs in the engine [01:27.240 --> 01:29.760] means finding bugs in a thousand different games, [01:29.760 --> 01:32.780] basically amplifying that effort. [01:32.780 --> 01:36.340] So I had a reasonable amount of luck [01:36.340 --> 01:40.300] looking at Unreal Engine 4 from Epic Games [01:40.300 --> 01:44.900] and UNet, the core networking protocol of Unity. [01:45.200 --> 01:48.020] And I talk about four of those bugs. [01:48.920 --> 01:54.460] And I give some POCs, typical DEF CON stuff, I guess. [01:54.460 --> 01:57.140] Yeah, it was all pretty awesome stuff in there. [01:57.140 --> 02:00.840] Falvo, do we have any questions coming in yet for Jack? [02:00.840 --> 02:03.240] We have a very first question over here. [02:03.240 --> 02:05.760] I like this one. This is from Hawkeye Dank. [02:06.480 --> 02:09.660] Do you believe that most game servers slash developers [02:09.660 --> 02:13.420] are heading towards a zero-trust architecture for newer games [02:13.420 --> 02:16.940] in order to better protect the game servers? [02:17.960 --> 02:19.660] That is a good question. [02:19.660 --> 02:21.660] So I would actually argue that to some extent [02:21.660 --> 02:23.180] that has already been done. [02:23.180 --> 02:26.480] If I were to go back a bunch to when I was a teenager [02:26.480 --> 02:28.560] trying to learn to hack video games, [02:28.560 --> 02:30.980] I remember that there was sort of this philosophy [02:30.980 --> 02:34.820] that the only online game you really couldn't hack [02:34.820 --> 02:36.640] was RuneScape. [02:36.640 --> 02:39.680] And the reason for that is RuneScape is about as close [02:39.680 --> 02:42.400] as you'll get to just a pure thin client [02:43.560 --> 02:45.640] in a big video game. [02:45.640 --> 02:48.660] And so you couldn't really manipulate the client [02:48.660 --> 02:50.820] to do things like teleport or whatever [02:50.820 --> 02:54.740] because it was just basically just button presses. [02:54.740 --> 02:59.160] In that case, though, people still managed to [02:59.160 --> 03:01.040] quote-unquote hack RuneScape, [03:01.040 --> 03:03.000] but it was in the form of logical bugs. [03:03.000 --> 03:06.860] It wasn't trust being placed on the client. [03:06.920 --> 03:09.320] So to answer that question, [03:09.320 --> 03:12.640] I think that you absolutely can make a zero-trust [03:13.520 --> 03:14.920] game engine as is, [03:14.920 --> 03:19.120] but you're balancing performance and security. [03:19.120 --> 03:21.200] And if you go too far on the security side, [03:21.200 --> 03:23.120] you end up with a game like RuneScape, [03:23.120 --> 03:27.860] which is very low, very slow, [03:27.860 --> 03:30.280] with not a whole lot going on. [03:30.280 --> 03:32.940] It's very difficult to apply that to something like, [03:32.940 --> 03:36.300] I don't know, Fortnite, where you've got a thousand, [03:36.300 --> 03:39.120] no, I guess a hundred people shooting guns. [03:39.120 --> 03:40.860] You've got all this math going on. [03:40.860 --> 03:43.520] It's just a different scale of a problem. [03:43.520 --> 03:47.120] But we're getting much better at it. [03:47.120 --> 03:49.480] Game engines have gotten significantly better [03:49.480 --> 03:51.640] at taking that trust away. [03:51.640 --> 03:54.960] So yeah, I think that's where things are going to keep moving, [03:54.960 --> 03:58.980] is taking that trust away and finding clever ways [03:58.980 --> 04:04.100] to make servers that can still handle a first-person shooter, [04:04.100 --> 04:05.620] still handle Fortnite, [04:05.620 --> 04:09.660] but don't have to put trust on the client to do that. [04:09.660 --> 04:12.720] And from the perspective of game hackers, [04:12.720 --> 04:17.200] hacking will just become more of a process [04:17.200 --> 04:18.680] of finding logical bugs, [04:18.680 --> 04:21.420] rather than doing what we typically do now, [04:21.420 --> 04:24.020] which is exploiting those trust relationships. [04:24.360 --> 04:26.220] Well, that's interesting. [04:26.220 --> 04:29.240] So a slightly different angle of a question [04:29.240 --> 04:31.760] coming from Blackfoot over here. [04:32.040 --> 04:35.100] Why do you think there is so little security knowledge share [04:35.100 --> 04:36.600] between game companies? [04:36.600 --> 04:38.480] Example, little documentation [04:38.480 --> 04:42.420] and hardening of UE4 dedicated servers. [04:44.540 --> 04:46.140] That's a pretty good question. [04:46.140 --> 04:48.160] If I had to guess, it would just be because [04:48.160 --> 04:52.440] game engines are such big pieces of software [04:52.440 --> 04:55.780] that when you develop your own game engine, [04:55.780 --> 04:58.500] you're sort of going to try to hold it close to your chest. [04:58.500 --> 05:01.580] You don't really want to give your competitors [05:02.520 --> 05:08.120] a competing game engine the keys to the kingdom, so to speak. [05:08.120 --> 05:10.540] So architecturally, most game engines are built [05:10.540 --> 05:11.860] from the ground up. [05:11.860 --> 05:13.680] There's not a lot of shared code, [05:13.680 --> 05:18.140] and that's just because it's a big investment [05:18.620 --> 05:20.860] and no one wants to share that. [05:20.880 --> 05:23.480] It's sort of a boring business answer, I think, [05:23.480 --> 05:26.740] but it's really just Unreal and Unity [05:26.740 --> 05:30.720] and whoever else don't want to share their work with each other. [05:31.200 --> 05:33.700] So in your presentation, [05:33.700 --> 05:35.760] one of the things that you were showing [05:35.760 --> 05:38.740] was kind of like the teleporting and the fast running. [05:38.800 --> 05:40.380] I remember at one point in there, [05:40.380 --> 05:42.600] you're just kind of showing somebody running at the normal speed [05:42.600 --> 05:46.660] and then the exploit that you were able to find [05:46.660 --> 05:48.840] where somebody's zipping across the screen. [05:48.980 --> 05:50.800] In addition to running, [05:50.800 --> 05:52.200] do you think there are other things [05:52.200 --> 05:54.520] that people could use that kind of thing for? [05:54.520 --> 05:57.500] Maybe be able to shoot faster, shoot more? [05:57.800 --> 05:59.780] Maybe what other kind of things have you thought of [05:59.780 --> 06:03.080] that somebody could use that type of exploit for in their games? [06:03.660 --> 06:04.780] Yeah, absolutely. [06:04.780 --> 06:06.880] So with that particular bug, [06:06.880 --> 06:10.440] I found what I think is really interesting. [06:10.440 --> 06:13.940] It's basically a bug where you can use the unique properties [06:13.940 --> 06:17.940] of some special floating point values [06:17.940 --> 06:22.100] to basically confuse the server into doing something it shouldn't. [06:22.100 --> 06:25.400] And so I have actually tried basically that exact technique [06:25.400 --> 06:29.660] on other games, other commands and stuff like that. [06:29.660 --> 06:34.020] And you can usually get something unpredictable to happen. [06:34.020 --> 06:35.260] I think I mentioned in my talk, [06:35.340 --> 06:37.440] a lot of times it's not a good thing. [06:37.440 --> 06:40.020] A lot of times you're just harming yourself, [06:40.020 --> 06:43.120] but you can usually cause the game to do something it shouldn't. [06:43.300 --> 06:48.580] And so, yeah, I think these logical bugs, [06:48.580 --> 06:51.600] especially like mathematical bugs, if you can find those, [06:51.600 --> 06:56.460] are a really good way to exploit games [06:56.460 --> 06:59.720] because while the bugs aren't the most common, [06:59.720 --> 07:01.440] they are very predictable. [07:01.440 --> 07:03.720] They're not a memory corruption bug [07:03.720 --> 07:05.980] where you have to worry about layout of the memory [07:05.980 --> 07:07.920] and all those complicated things. [07:07.920 --> 07:13.140] And they tend to, I guess, [07:13.140 --> 07:16.800] slip by the architectural protection. [07:16.800 --> 07:19.860] So in that case, like the bug you talked about, [07:19.860 --> 07:23.580] Unreal Engine has a pretty robust way to prevent speed hacking. [07:24.100 --> 07:28.120] And using just a couple quirks of, [07:28.960 --> 07:32.480] basically, quirks of decimal numbers, [07:32.480 --> 07:34.500] you can cause it to do something it shouldn't. [07:34.500 --> 07:36.780] And that is super useful. [07:36.780 --> 07:39.960] So that particular kind of bug, I'd say, yes, [07:39.960 --> 07:42.340] definitely applies in other places. [07:42.460 --> 07:45.840] It's just a matter of looking for it. [07:45.860 --> 07:49.180] And I guess that's it. [07:49.180 --> 07:51.200] I don't know how I was going to end that sentence. [07:51.240 --> 07:53.360] No, I really liked what you showed there, [07:53.360 --> 07:57.780] especially the things that we find in other places [07:57.780 --> 08:00.360] across security and other types of hacking. [08:00.360 --> 08:03.100] You go, well, okay, let's divide by zero. [08:03.100 --> 08:04.520] Let's use not a number. [08:04.520 --> 08:08.200] Let's use these things that are the outsides [08:08.200 --> 08:10.840] of this language that's being used [08:11.360 --> 08:15.420] and see what happens when you throw it at the system. [08:15.420 --> 08:17.580] And it's just nice to see, [08:18.280 --> 08:21.480] in the niche that you found yourself in, [08:21.660 --> 08:23.520] a lot of the same techniques work. [08:24.280 --> 08:27.580] Yeah, I guess one other thing I like about that bug [08:27.580 --> 08:30.800] is that it's not something that's fixed by, say, [08:30.800 --> 08:32.540] oh, we're going to stop writing things in C [08:32.540 --> 08:36.020] and start writing them in Go or Rust or something. [08:36.020 --> 08:39.940] These are bugs that still exist even in, [08:39.940 --> 08:42.480] quote-unquote, safe languages. [08:42.500 --> 08:46.280] And I think in more than just video games, [08:46.280 --> 08:49.340] that's where this sort of exploitation is going. [08:49.340 --> 08:51.980] And that's why I like that bug so much. [08:53.140 --> 08:56.560] All right, so Hawkeye has another question for you. [08:56.560 --> 08:59.780] He asks, have you noticed any new trends [08:59.780 --> 09:03.620] of input validation in high-user games like Fortnite? [09:04.460 --> 09:08.540] Yeah, I mean, I keep going back to the same example, [09:08.540 --> 09:11.540] but Unreal Engine 4 uses a really, [09:12.760 --> 09:16.560] really robust system for validating user input [09:16.560 --> 09:18.640] and specifically user movement [09:19.480 --> 09:22.820] in a way that scales really well, [09:22.820 --> 09:25.480] but also basically eliminates your ability [09:25.480 --> 09:30.340] to manipulate your movement in any significant way. [09:30.340 --> 09:35.340] And so essentially the broad strokes are basically [09:35.340 --> 09:41.380] taking authority over your character's location, [09:41.380 --> 09:42.760] putting it on the server, [09:42.760 --> 09:46.300] and giving the client the possibility to call functions [09:46.300 --> 09:49.360] in order to request that you move. [09:49.360 --> 09:52.780] And that way, the server has the context to say, [09:52.780 --> 09:54.680] well, you're trying to move too fast. [09:55.760 --> 09:57.400] I'm not going to allow that. [09:57.400 --> 10:01.200] I'm going to limit movement to a specific range. [10:01.200 --> 10:05.780] And so really, I think the entirety of evolutions [10:05.780 --> 10:09.540] in the security of game engines recently [10:09.540 --> 10:13.140] has just been on giving more context to the server [10:13.140 --> 10:15.320] so we can say, well, that's not right. [10:15.320 --> 10:17.560] I'm going to stop that from happening [10:17.560 --> 10:19.980] and ensuring that the client doesn't have the trust [10:19.980 --> 10:22.000] to just overrule the server. [10:22.000 --> 10:25.020] I can't remember whether you said in your presentation [10:25.020 --> 10:30.180] if you've talked to the engine companies [10:30.180 --> 10:33.140] about these vulnerabilities and if they have fixed [10:33.140 --> 10:35.820] the exploits that you found. [10:35.820 --> 10:38.440] But if they do see somebody trying to send [10:38.440 --> 10:42.240] like your NAN, not a number, at the server, [10:42.240 --> 10:44.260] what types of things would you think [10:44.260 --> 10:46.860] that they should do to that? [10:46.860 --> 10:49.300] Should they kind of just adjust or ban? [10:49.300 --> 10:52.420] What are your thoughts for how people could... [10:52.420 --> 10:53.880] what should happen to them? [10:54.300 --> 10:59.380] Yeah, so three of the four bugs I talk about are fixed. [11:00.540 --> 11:06.000] And the speed hack one, the NAN one, was one of those. [11:06.000 --> 11:07.580] It was actually a pretty easy fix. [11:07.580 --> 11:09.800] They just put a tiny little check in there that says [11:09.800 --> 11:12.520] if this is NAN, just abort, get out of there. [11:12.640 --> 11:15.060] But in general, I would say [11:17.220 --> 11:19.060] what they should... [11:20.040 --> 11:24.660] I would recommend possibly that if you're a game engine developer [11:24.660 --> 11:27.000] or you're working on Unreal and you think, [11:27.000 --> 11:31.400] oh, this could be a problem, it's not unreasonable to just say [11:31.400 --> 11:34.980] you shouldn't be able to use NAN in any argument. [11:34.980 --> 11:38.040] That's not going to happen under normal circumstances. [11:38.280 --> 11:41.320] And just essentially eliminate that from the serialization [11:41.900 --> 11:44.260] and deserialization process. [11:44.260 --> 11:47.220] Unreal doesn't do that because it wants to consider itself [11:47.220 --> 11:48.780] sort of impartial to that. [11:48.780 --> 11:53.640] Whatever goes in one end is deserialized on the other end. [11:54.000 --> 12:00.780] But I think it would be a pretty reasonable assumption to say [12:00.780 --> 12:04.040] if you're getting certain types of, say, floating point numbers, [12:04.040 --> 12:06.280] this is blatantly invalid. [12:06.280 --> 12:07.700] And we can probably just toss it out [12:07.700 --> 12:10.080] before we even consider anything else. [12:11.320 --> 12:15.780] Just a general input validation on what's coming in. [12:15.880 --> 12:17.720] Typical boring stuff. [12:18.560 --> 12:20.480] Isn't it that way? [12:20.540 --> 12:24.460] Well, so I don't really want to give away the punchline [12:24.460 --> 12:27.020] to your presentation because it fits so well, [12:27.020 --> 12:30.020] but we'll just kind of hand wave that and say, [12:30.020 --> 12:35.800] so when you've been doing this, how often do you get booted [12:35.800 --> 12:39.060] from whatever game you're playing? [12:39.060 --> 12:42.760] Or how many times have you had your accounts banned? [12:43.920 --> 12:46.040] When you're building your own stuff, [12:46.040 --> 12:48.820] you get banned less than you might expect. [12:48.820 --> 12:53.260] I did a talk last year on hacking, basically, browser games. [12:53.300 --> 12:58.440] And for one of the demonstrations, I took a game. [12:58.440 --> 13:01.260] I don't want to say its name. I've done enough to them. [13:01.560 --> 13:05.160] But I took this game and it has a global scoreboard [13:05.160 --> 13:10.700] and I just set my score to 1, 3, 3, 3, 3, 3, 3, 3, something, 7, [13:10.700 --> 13:12.780] and username to HiDefCon. [13:12.780 --> 13:14.600] And they banned me pretty quickly. [13:14.600 --> 13:16.760] I think that was pretty obvious. [13:16.840 --> 13:20.620] But in general, if you're building your own game hacks, [13:20.620 --> 13:23.240] there is a pretty good chance you're going to get away with it. [13:23.240 --> 13:25.520] So I get banned pretty rarely. [13:28.100 --> 13:30.620] So congratulations or I'm sorry. [13:30.940 --> 13:32.940] However you feel about that. [13:33.160 --> 13:34.540] It's a mixed bag. [13:35.560 --> 13:40.720] Where do you also often kind of see the line here along the same, [13:40.720 --> 13:43.840] I guess similar to what Fallible was just talking about, [13:43.840 --> 13:48.280] where the old question about research versus going over the line, [13:48.280 --> 13:52.720] because essentially you are affecting other users, potentially, [13:53.260 --> 13:54.960] as well as that game engine. [13:54.960 --> 13:59.300] So where is kind of your line on how far you'll go with your research? [13:59.360 --> 14:03.620] Or is it because it's in the name of research, you'll just go all the way with it? [14:03.620 --> 14:07.020] I mean, I won't do anything that's, I think, [14:07.020 --> 14:12.540] directly affecting someone spending money or someone or anything like that. [14:12.540 --> 14:15.860] I'm not stealing items from people in online games. [14:15.860 --> 14:17.660] That certainly crosses the line. [14:17.660 --> 14:20.600] But, you know, if someone's in a lobby of a first person shooter [14:20.600 --> 14:25.440] and someone wall hacks through and, you know, no scopes them in the head, [14:25.440 --> 14:28.720] I don't think they've been significantly harmed in any way. [14:28.720 --> 14:34.980] So I think that is within moral bounds for me. [14:34.980 --> 14:36.000] Excellent. [14:38.200 --> 14:42.420] Can you explain some of the technical setup that you have [14:42.420 --> 14:46.360] in order to capture the data that you're sending across? [14:46.360 --> 14:50.440] And what tools are you using? What's your lab look like? [14:50.440 --> 14:55.020] Yeah, so working with Unreal Engine especially, [14:55.020 --> 14:58.500] I needed to actually buy a new desktop to do [14:58.500 --> 15:02.020] because on the laptop I was working on, [15:02.020 --> 15:05.920] it took most of the day to compile Unreal from source. [15:05.920 --> 15:09.660] And I was doing that several times a day. [15:09.660 --> 15:13.660] So that was not good math working out there. [15:13.660 --> 15:18.320] So essentially, I do all of my Unreal development on Linux, [15:18.320 --> 15:22.780] which is a little less supported, but it's just more comfortable for me. [15:22.780 --> 15:28.940] And the other, I guess the other thing that's really a challenge [15:28.940 --> 15:32.960] is the specifically Unreal source is so big [15:32.960 --> 15:39.340] that trying to open it in most like project editors is, it does not work. [15:39.340 --> 15:44.440] VS code gets by just a little bit, but even then it gets tripped up [15:44.440 --> 15:48.240] when you try to go to this function or something like that, [15:48.240 --> 15:52.360] it'll end up, it'll spin its wheels for five minutes and say, [15:52.360 --> 15:55.520] yeah, couldn't find it, even though you know it exists. [15:55.520 --> 15:58.700] So I wish I had a better setup. [15:58.700 --> 16:01.180] I'm sure people who do actual video game development [16:01.180 --> 16:05.060] have better experiences with building Unreal from source. [16:05.060 --> 16:11.520] But I guess my lab is just, it's a system 76 desktop [16:11.520 --> 16:16.200] with the highest boxes checked on everything, [16:16.200 --> 16:19.580] just so that I can compile Unreal as many times as I want [16:19.580 --> 16:21.160] and it doesn't take me all day. [16:22.600 --> 16:26.600] So in that way, you're looking at the guts of the code, [16:26.600 --> 16:28.960] you're really building it each time. [16:28.960 --> 16:32.800] It's not a situation of you're just capturing everything in Wireshark [16:32.800 --> 16:35.840] and modifying it somehow. [16:36.400 --> 16:39.440] No, I wish it was a little easier. [16:39.440 --> 16:45.960] With Unet, you can get away with just looking at the traffic in Wireshark. [16:45.960 --> 16:50.220] Unreal is pretty difficult because everything is like bit aligned, [16:50.220 --> 16:53.260] so you'll have a string that starts four bits in [16:53.260 --> 16:55.080] and just looks like gibberish. [16:55.120 --> 16:57.960] So you really do have to be looking at it at the low level [16:57.960 --> 16:59.840] to really make any sense of it. [17:01.020 --> 17:02.320] That makes sense. [17:02.320 --> 17:05.440] And how does somebody get started with that kind of thing? [17:05.440 --> 17:09.520] Because this sounds extremely technical and you have to know quite a bit. [17:09.560 --> 17:12.240] How does somebody, where would be the entry point [17:12.240 --> 17:14.580] if somebody was interested in this kind of research [17:14.580 --> 17:17.700] in order to start figuring these kinds of things out, [17:17.700 --> 17:21.060] or if they wanted to just even look at how games work? [17:21.640 --> 17:24.840] Yeah, well, I mean, all the code is out there for Unreal Engine, [17:24.840 --> 17:28.740] but I don't think that's something you should just jump straight into, [17:28.740 --> 17:33.380] especially if you're not pretty familiar with C++, [17:33.380 --> 17:36.200] because it is a complicated code base. [17:36.200 --> 17:40.820] I think the best thing you can do to understand hacking video games [17:40.820 --> 17:43.300] is to build them. [17:43.400 --> 17:46.760] It's sort of a, I don't know, cliche answer, [17:46.760 --> 17:49.500] but that is what teaches you, oh, this is how that works. [17:49.500 --> 17:50.740] This is how I'd write it. [17:50.740 --> 17:55.420] This is probably how it looks on the back end. [17:55.540 --> 17:58.860] Also, I would say if you're going to look at games [17:58.860 --> 18:01.860] written in a particular engine, Unity games are pretty good [18:01.860 --> 18:07.100] because they're usually built, well, they're built with C Sharp [18:07.100 --> 18:10.800] and they're typically easy to decompile back to C Sharp [18:10.800 --> 18:14.720] with something like DN Spy, if I'm pronouncing that correctly. [18:14.720 --> 18:16.320] However, that's verbalized. [18:16.320 --> 18:20.000] So you can actually look at the code of the game, modify it, [18:20.000 --> 18:23.220] see what happens, and basically hack games [18:23.220 --> 18:28.480] without too much actual binary reverse engineering [18:28.480 --> 18:30.920] or anything like that. [18:31.620 --> 18:40.200] So we got a question from Jay that I'm going to obscure this a little bit. [18:40.200 --> 18:42.720] The question is way too specific, [18:42.720 --> 18:50.420] so let's go more along the lines of where else would be interesting to look? [18:50.420 --> 18:54.920] If you were done with the research that you've done so far [18:54.920 --> 18:57.700] and you were looking for a new product, [18:57.700 --> 19:02.340] what would be the things that would draw you to a new product? [19:03.900 --> 19:09.800] Yeah, so one thing I would say is that when you look at Unity, [19:09.800 --> 19:14.360] there are a lot of different multiplayer solutions. [19:14.360 --> 19:18.680] So I looked at UNet, which is sort of the... it's provided by Unity, [19:18.680 --> 19:22.460] but there are third-party solutions that are pretty common. [19:22.820 --> 19:25.660] Photon, Mirror, I haven't looked at those at all, [19:25.660 --> 19:28.480] and I think that there's a pretty solid chance [19:28.480 --> 19:31.320] that the same kind of bugs apply there. [19:31.460 --> 19:34.800] And then I think most of the research I did, [19:34.800 --> 19:38.560] obviously I'm just looking at the core engines for games, [19:38.560 --> 19:42.160] but looking at specific games, you can find these exact same bugs. [19:42.160 --> 19:46.880] They just may not apply to other games. [19:46.880 --> 19:49.180] So I think most of this research still applies. [19:49.180 --> 19:52.160] It just needs to be targeted either at different games [19:52.160 --> 19:55.980] or different multiplayer protocols, even different game engines. [19:55.980 --> 19:58.380] Game Maker, there are... [19:58.380 --> 20:00.900] Well, I think I've looked at the two more common game engines. [20:00.900 --> 20:02.960] There are other engines out there. [20:04.100 --> 20:07.500] In other words, just find another big target and play, [20:07.500 --> 20:09.780] or just go and learn something. [20:09.780 --> 20:13.240] If you happen to be using a game, then this might be a good opportunity. [20:14.540 --> 20:16.260] Hawkeye Dank asked another question [20:16.260 --> 20:20.220] about the outcome of your work, [20:20.220 --> 20:22.860] and he wants to know if you've managed [20:22.860 --> 20:24.820] to pull any bounties for this. [20:25.720 --> 20:28.540] Yeah, I turned down bounties for a few things [20:28.540 --> 20:30.500] because I wanted to talk about them. [20:30.500 --> 20:33.880] If I was really min-maxing it, I probably would have accepted bounties [20:33.880 --> 20:37.300] for a few more, but you never know. [20:37.760 --> 20:41.380] So yes, Unity and Epic Games [20:41.380 --> 20:43.860] were both really good about this. [20:45.400 --> 20:46.680] Epic has [20:46.680 --> 20:48.640] HackerOne program. [20:48.640 --> 20:51.460] Unity, you want to just go straight to their security [20:51.460 --> 20:55.380] at unity3d... whatever, I don't want to give you the wrong email. [20:55.380 --> 20:57.440] Security at email address. [20:57.440 --> 20:59.800] But both were awesome to work with. [20:59.800 --> 21:03.780] I would highly recommend it, [21:03.780 --> 21:06.380] and yes, there is definitely money to be made. [21:07.120 --> 21:09.060] And you've looked at the Unreal [21:09.060 --> 21:12.380] and Unity engines. Are there any others that you've looked at [21:12.380 --> 21:14.200] or found bugs with? [21:15.660 --> 21:18.180] I have done a fair amount of reverse engineering [21:18.180 --> 21:21.620] on GameMaker, which is one of the [21:21.620 --> 21:24.780] more common engines, certainly less than Unity [21:24.780 --> 21:28.200] or Unreal. Not from a security perspective, [21:28.200 --> 21:31.240] just from a how do I hack this game [21:31.240 --> 21:33.840] or how do I mod this game [21:34.840 --> 21:36.040] aspect. [21:36.400 --> 21:40.060] I guess one of the problems is that some of these [21:40.060 --> 21:43.400] smaller engines don't provide you the same [21:44.140 --> 21:46.100] tools. They may not have an entire [21:46.100 --> 21:49.060] networking solution, so there's less [21:49.060 --> 21:52.180] places for bugs to be hiding. That's why [21:52.180 --> 21:55.680] I think Unity and Unreal were such good targets. [21:55.680 --> 21:58.680] But I do think there is opportunity for bugs [21:58.680 --> 22:01.740] in those other engines. I just really haven't done the work [22:01.740 --> 22:03.100] in that context. [22:03.100 --> 22:06.980] And have you also looked at the individual games itself? [22:06.980 --> 22:09.500] And what's really the difference between trying to find [22:09.500 --> 22:13.540] vulnerabilities in the game engine and a specific game? [22:14.300 --> 22:16.540] I guess usually the difference [22:16.540 --> 22:19.320] is whether or not you're going to have an easily accessible [22:19.320 --> 22:22.300] source. So Unreal Engine games, [22:22.300 --> 22:26.460] like reverse engineering an actual released Unreal Engine game [22:26.460 --> 22:29.200] can be pretty tedious because you're not looking at the source. [22:29.200 --> 22:32.320] You're not typically even looking at something with symbols. [22:32.320 --> 22:34.920] You're just looking at a gigantic blob in [22:34.920 --> 22:38.020] Ida or Ghidra. But I have [22:38.020 --> 22:41.440] had some success there. I don't want to burn bridges, so I'm [22:41.440 --> 22:43.720] just going to leave it at that. [22:44.320 --> 22:47.380] But I guess the main [22:47.380 --> 22:48.960] difference is just how much [22:49.760 --> 22:53.740] effort goes into reverse engineering. [22:56.540 --> 22:57.460] This sounds [22:57.460 --> 23:00.160] like a pretty specific question, but we'll toss it out there. [23:00.160 --> 23:03.080] So thoughts on cheat engine or memory scanners [23:03.080 --> 23:05.560] as a toolkit from beginners? That's from [23:05.560 --> 23:07.080] Ethics. [23:08.460 --> 23:11.620] Cheat engine is awesome. It's how I started learning. [23:11.620 --> 23:14.040] My talk last year was on essentially applying [23:14.880 --> 23:17.780] a lot of the methods and techniques of cheat engine to [23:17.780 --> 23:21.180] WebAssembly, so games in your browser, basically. [23:21.180 --> 23:23.760] So I think cheat engine is great. It is [23:24.080 --> 23:26.080] a problem that as [23:26.660 --> 23:29.840] game engines get more secure, [23:29.840 --> 23:31.800] those techniques don't work as well. [23:31.800 --> 23:35.820] To give a general example, what cheat [23:35.820 --> 23:38.700] engine generally does, what you're usually doing with it, is [23:38.700 --> 23:41.780] you look for something like your health and you say, OK, I'm looking [23:41.780 --> 23:44.600] for something in memory that's 100. [23:44.600 --> 23:47.800] Then I take some damage and say, OK, of all those values that used [23:47.800 --> 23:50.460] to be 100, which one is now 87 [23:50.460 --> 23:53.440] or something like that? And that helps you find [23:53.440 --> 23:56.620] the value in memory that corresponds to your health. [23:56.620 --> 23:58.940] And then you can manipulate that. [23:59.360 --> 24:01.900] Give yourself more health, whatever. [24:02.200 --> 24:05.520] But as games take trust away from the client, [24:05.520 --> 24:08.680] that process doesn't work anymore. You can manipulate your health [24:08.680 --> 24:11.540] client side, but the server still knows you have 87 [24:11.540 --> 24:14.320] health, not 10,000 or whatever. [24:14.400 --> 24:17.660] So, I do think [24:17.660 --> 24:20.640] if you're looking at the right games, that is a great way [24:20.640 --> 24:23.520] to get into game hacking and understand those basic concepts. [24:23.520 --> 24:25.900] But it's not going to work on [24:26.840 --> 24:29.360] PUBG or something where someone has [24:29.360 --> 24:32.240] put a conscious effort into making it secure [24:32.240 --> 24:34.920] and something that's come out in the last [24:35.340 --> 24:38.060] five years, a decade, something like that. [24:38.060 --> 24:41.040] And how much now are the developers trying to go [24:41.040 --> 24:43.400] with more, I don't know if it's the right term for it, [24:43.400 --> 24:47.100] the thin client, so that people can't really [24:47.100 --> 24:49.860] make changes in the client side or [24:49.860 --> 24:53.300] in their mobile device phone and give myself a million lives [24:53.300 --> 24:56.380] or a million gems or coins or anything like that [24:56.380 --> 24:58.940] and trying to keep all of that on the server. How much of [24:58.940 --> 25:02.280] that do you kind of see with the games [25:02.280 --> 25:05.780] and the servers? In my experience, [25:05.780 --> 25:08.660] it's really just whatever the engine does, [25:08.660 --> 25:11.180] the developer will follow. Unreal [25:11.720 --> 25:14.260] sets you up really well to [25:14.780 --> 25:17.680] build an architecture where those game hacks [25:17.680 --> 25:20.740] don't work or are exceptionally difficult. [25:20.740 --> 25:23.960] And so you see developers doing a pretty good job. [25:24.460 --> 25:26.780] Unity does not set you up quite [25:26.780 --> 25:29.600] as well from the start, and so you'll see the majority [25:29.600 --> 25:32.260] of those, I guess we'll call [25:32.260 --> 25:36.060] simple attacks, do often work. [25:36.320 --> 25:38.320] That's not to say that you can't build [25:38.640 --> 25:41.380] a secure architecture on Unity. It just [25:41.380 --> 25:44.140] means that Unity's not doing the work [25:44.140 --> 25:47.540] for you, and like I said, developers [25:47.540 --> 25:50.780] will typically follow what the engine does. [25:50.780 --> 25:53.520] So as the core software, as [25:53.520 --> 25:57.280] the water level rises, developers get better at it as well. [25:57.360 --> 25:59.360] Cool. Is there anything that [25:59.360 --> 26:02.340] you didn't get a chance to put into your presentation that [26:02.340 --> 26:05.320] is additional research that you might have done, or are there any [26:05.320 --> 26:08.360] kind of other areas that you think other people might be able [26:08.360 --> 26:10.800] to add on to the research that you've done? [26:11.320 --> 26:14.480] Yeah, so a couple things come to mind. The first [26:14.480 --> 26:17.600] is the floating point bugs I talked about. [26:17.600 --> 26:19.720] I think that can apply a lot. [26:19.980 --> 26:22.980] I very briefly mentioned this, but [26:22.980 --> 26:26.400] that attack does actually apply to Unity. [26:26.400 --> 26:29.160] The difference is that you don't need to speed [26:29.160 --> 26:31.840] hack Unity. You can just, or at least by [26:32.400 --> 26:35.260] using the core components that are provided for you, you can just [26:35.260 --> 26:38.480] tell it, I'm at x, y, z. And if you tell it [26:38.480 --> 26:41.360] I'm at nan, nan, nan, you get [26:41.360 --> 26:44.240] teleported to this weird dimension where everything is [26:44.240 --> 26:47.680] infinitely small. It's kind of cool. It's not very useful. [26:47.920 --> 26:50.660] So I think that kind of attack applies [26:51.220 --> 26:53.420] to a lot of things, and I'd like to see [26:53.420 --> 26:56.500] where else it goes. Something else that I feel [26:56.500 --> 26:59.640] like I wanted to do, but I didn't quite [26:59.640 --> 27:02.280] find all the pieces, was I found [27:02.520 --> 27:05.440] a number of memory corruption bugs, like buffer [27:05.440 --> 27:08.560] overflow, stuff like that. [27:08.560 --> 27:11.540] And a lot of those seemed like [27:11.540 --> 27:14.300] they would be good for turning something into remote code [27:14.300 --> 27:17.540] execution, but the problem that I was always running into [27:17.540 --> 27:20.420] is I couldn't imagine a situation [27:20.420 --> 27:23.600] where you were looking at a game server and you knew what it [27:23.600 --> 27:26.400] looked like on the back end. So a memory corruption exploit [27:27.160 --> 27:29.160] requires some knowledge of [27:29.160 --> 27:32.060] memory, of the layout of memory, where [27:32.980 --> 27:35.600] code is, gadgets, stuff [27:35.600 --> 27:38.820] like that. And while you may have a copy of the client, you don't have a [27:38.820 --> 27:41.820] copy of the server. And so even if you can bypass [27:41.820 --> 27:45.040] all those difficult protections, ASLR, [27:45.040 --> 27:47.520] stuff like that, I just couldn't imagine [27:47.680 --> 27:50.680] a scenario where I could turn [27:50.680 --> 27:53.520] one of these into an RCE exploit on [27:53.520 --> 27:56.440] an actual server. And so that's why I [27:56.440 --> 27:59.680] felt a little disappointed in myself, because I had what [27:59.680 --> 28:02.800] felt like good bugs, but it didn't [28:02.800 --> 28:04.700] feel practical to turn them into [28:05.500 --> 28:08.540] an exploit that would work in the real world. [28:08.660 --> 28:11.560] So I would love to see someone actually pull that off. [28:12.380 --> 28:14.540] So we are right down [28:14.540 --> 28:17.720] to the bare end of this thing. So two questions. [28:17.720 --> 28:20.500] One is, would you be willing to [28:20.500 --> 28:23.600] post places that people can find you later, whether that [28:23.600 --> 28:26.320] be an email or a website or Twitter? [28:26.340 --> 28:29.780] We can do that in the TrackOne channel at the end of this. [28:29.780 --> 28:32.600] And two, if you were to leave us [28:32.600 --> 28:35.300] with a call to action, something you would like us to [28:36.040 --> 28:38.880] consider as we're moving forward. I've been asking this of everybody. [28:38.880 --> 28:41.640] I kind of like this question. What should we take away from [28:41.640 --> 28:45.040] this and in our own work? And how can we [28:45.040 --> 28:48.660] translate your stuff into ours? What would you want us to do? [28:49.240 --> 28:50.700] Yeah, so absolutely. [28:50.700 --> 28:54.060] I will post my GitHub. It is on the slides [28:54.060 --> 28:57.600] as well, but I'll post it again. My email address is there too. [28:57.600 --> 28:59.780] Hit me up. I've already had a few people. [28:59.780 --> 29:02.480] I've had a couple of really interesting conversations, so I really [29:02.480 --> 29:05.560] appreciate it when people reach out. And [29:05.560 --> 29:08.800] I don't know. If I could ask for anything, [29:08.800 --> 29:11.560] it would be that if you're [29:11.880 --> 29:15.320] a security person, you work pen testing or whatever, [29:15.320 --> 29:17.760] try hacking video games. It's fun. [29:17.760 --> 29:20.680] I know you probably like video games because you're a nerd [29:20.680 --> 29:23.340] and you're at DEF CON. So am I. [29:23.340 --> 29:26.380] Try it. It's rewarding. [29:26.740 --> 29:29.700] It gets your adrenaline pumping. And getting banned [29:29.700 --> 29:32.720] is fun too. So that's my [29:32.720 --> 29:35.720] recommendation. If you haven't ever gotten banned from a [29:35.720 --> 29:38.540] video game, give it a shot. Awesome. [29:38.580 --> 29:41.320] Well, thank you so much for doing this, Jack. Appreciate you [29:41.320 --> 29:44.840] taking the time to be with us and really enjoyed your presentation. [29:44.840 --> 29:47.760] Hopefully everybody else goes and checks that out. [29:47.760 --> 29:51.280] So thank you so much. Yeah, thank you guys. This was fun. [29:51.920 --> 29:53.880] All right. We will be back [29:53.880 --> 29:56.280] in about 30 minutes with another speaker.