[00:58.110 --> 00:59.270]  All right.
[00:59.270 --> 01:00.510]  How's everyone doing tonight?
[01:00.510 --> 01:01.250]  Today?
[01:01.930 --> 01:02.470]  All right.
[01:02.470 --> 01:03.050]  Cool.
[01:03.050 --> 01:05.650]  Thank you for joining me for the first talk after the keynote.
[01:05.650 --> 01:07.090]  I really appreciate it.
[01:07.530 --> 01:07.890]  All right.
[01:07.890 --> 01:10.130]  We'll just dive directly in now.
[01:10.130 --> 01:11.310]  No need to wait.
[01:11.310 --> 01:16.930]  So first, before we really get into the knee deep thick of it, we'll go a little bit about myself.
[01:16.930 --> 01:18.250]  I'm Connor Kastner.
[01:18.250 --> 01:25.490]  My four little acronyms that I got right now are GPEN and GSOC for Penetration Tester and Security Operations Center through SANS.
[01:25.610 --> 01:31.410]  My day job, I'm a SOC analyst over at American Transmission Company working on protecting critical infrastructure.
[01:31.570 --> 01:38.630]  And the main reason why I'm writing this talk and what I did in my childhood is I've always been a big fan of anything involving screens.
[01:39.290 --> 01:41.010]  I grew up modding consoles.
[01:41.010 --> 01:53.350]  I grew up plugging in USBs, downloading random apps for Minecraft or God mode for Black Ops or tricking my friends in middle school to hop in a private lobby where I hit a lag switch and pissed them off every single time.
[01:53.350 --> 01:56.190]  Don't know how they kept falling for it, but here we go.
[01:56.190 --> 01:57.590]  I had a good time with that.
[01:58.010 --> 02:02.370]  So we'll treat this section as an overview, kind of introduce what we're talking about today.
[02:02.390 --> 02:07.430]  First, we'll go over what an anti-cheat actually is, its purpose and what it hopes to accomplish.
[02:07.430 --> 02:12.050]  We'll talk a little bit about how anti-cheat has developed over the past 25 years or so.
[02:12.050 --> 02:19.070]  We'll go a little bit into what direct memory access is and how it acts as a bridge to hardware, to cheating software.
[02:19.190 --> 02:26.490]  And then we'll build up that bridge and really get it some good integrity with firmware so that anti-cheat doesn't detect us when we start doing our dirty work.
[02:26.570 --> 02:35.070]  And then we'll take a brief look at cheat development and how DMA library can help transmute gathered information for what our purpose is.
[02:35.130 --> 02:40.950]  And then towards the end of this talk, we'll go a little bit about anti-cheat's methodology for detecting direct memory access.
[02:44.500 --> 02:45.740]  Get started.
[02:45.820 --> 02:48.260]  What even is an anti-cheat?
[02:48.260 --> 02:55.700]  Anti-cheat's core functionality is about detecting and preventing software and hardware that seeks to give an unfair advantage to other players.
[02:55.800 --> 03:02.140]  So we'll only be talking today about cheats and anti-cheats from a competitive multiplayer standpoint.
[03:02.860 --> 03:09.600]  And the prime motivation for why companies even put any care into anti-cheat development is to maintain their consistent player base.
[03:09.700 --> 03:13.280]  Players constantly encountering cheaters in a game decreases enjoyment.
[03:13.280 --> 03:20.340]  If you log on to a Counter-Strike match and every single time you just get burned by a cheater that you can't see, you don't want to play anymore.
[03:20.340 --> 03:21.940]  You don't care about that game.
[03:21.940 --> 03:26.100]  And a decrease in profit correlates directly to a decrease in players.
[03:26.280 --> 03:29.140]  Or a decrease in players correlates to a decrease in profit.
[03:29.140 --> 03:35.200]  That takes a hit from a reputational and financial standpoint of the company since games are a business at the end of the day.
[03:35.680 --> 03:39.040]  So there's three different types of detection methods that anti-cheats use.
[03:39.040 --> 03:42.720]  There's signature, heuristic, and reputational based detection.
[03:42.960 --> 03:44.860]  Signature is exactly what it sounds like.
[03:44.860 --> 03:47.640]  It blocks known bad binaries or hardware.
[03:47.940 --> 03:54.280]  If an actor posts a cheat to a form that they've developed, a bunch of people start downloading it and wreaking havoc within a game.
[03:54.320 --> 04:03.980]  Anti-cheat developers can come in, look at everybody who's been cheating, start developing some signatures on what programs they were using, and put in a block for like that file hash, for example.
[04:04.500 --> 04:07.020]  This is the exact same thing as like virus total.
[04:07.040 --> 04:18.460]  If someone uploads something that's known bad and it gets analyzed and a bunch of anti-cheats are now aware of it, whenever you go online and download a random file that's bad, it immediately gets blocked by that anti-virus.
[04:19.280 --> 04:30.460]  Now heuristic based detection identifies cheats through behaviors and the execution of software or even hardware and seeks to prevent weird anomalies or known vectors that cheats commonly use.
[04:30.460 --> 04:34.260]  This usually begins by scanning whenever the game process itself starts.
[04:34.260 --> 04:43.040]  It looks for a couple different things, such as process injections, suspicious memory modifications, API hooks, unusual system calls, and a lot more.
[04:43.040 --> 04:45.140]  The list constantly goes on.
[04:45.580 --> 05:00.100]  Going back to that anti-virus comparison, if we download a program and our AV watches it as it starts to add registry keys, scanning through every file in the system, changing extensions, the anti-virus should know that something very bad is happening and we need to cut that off.
[05:00.100 --> 05:03.000]  Same thing goes on with an anti-cheat in that perspective.
[05:03.580 --> 05:08.660]  Now we won't go over it too much today, but I still think it's important to touch on reputational based.
[05:08.760 --> 05:12.380]  Reputational based is about accounts that are connected to the game itself.
[05:12.400 --> 05:26.320]  That looks at a couple different factors, like account age, hours played versus standard skill progression, performance history, like did this person start performing incredibly well out of nowhere, if they've ever bought anything in the past, because that usually likes to increase trust,
[05:26.320 --> 05:30.380]  anomalies in their accuracy with how they're hitting shots, ban history, blah, blah, blah.
[05:30.380 --> 05:32.880]  There's so much that reputational looks at.
[05:33.380 --> 05:41.780]  So now, with all of these three, let's take a look at a little historical overview of how anti-cheat has changed over the past 25 years or so.
[05:42.560 --> 05:48.020]  So we started off with Punkbuster, which is usually the first big anti-cheat that came onto the market.
[05:48.060 --> 05:49.780]  It started off in 2000.
[05:49.780 --> 05:52.280]  As of 2015, it's kind of defunct.
[05:52.380 --> 05:55.860]  I think the last game to use it was some Battlefield PC clone.
[05:55.860 --> 05:56.720]  I don't know.
[05:56.860 --> 06:01.460]  It was really simple, relied on signature based detection and only reputational based detection.
[06:01.460 --> 06:07.100]  It didn't have a lot of heuristic capabilities that we come to know from some of the newer anti-cheats.
[06:07.420 --> 06:10.880]  Then there's also VAC, which is Valve Anti-Cheat.
[06:11.460 --> 06:16.340]  That's been on the market since 2002, and it primarily targets games that are using Steam's source engine.
[06:16.340 --> 06:21.140]  So think Counter-Strike, Team Fortress 2, anything that is developed by Valve themselves.
[06:21.560 --> 06:36.180]  They started off really simple back in 2002 with just signature based detection, but as time has grown on, it's really evolved to use more of a machine learning approach and what they call their Overwatch system, which flags people who have really bad reputation or have a risky history,
[06:36.180 --> 06:40.540]  and they have trusted players come in, review gameplay, and if necessary, ban them.
[06:41.140 --> 06:44.940]  Now, both of these anti-cheats live in what's called the user-land of the system.
[06:44.940 --> 06:55.160]  User-land means restricted access to system resources, they can't really detect sophisticated memory modifications, and they're vulnerable to user-land API hooking and a lot more.
[06:55.620 --> 07:04.400]  Especially with what we're talking about today too, cheats that are living in the kernel, whether that be drivers or hardware, are really difficult for these two anti-cheats to detect.
[07:09.560 --> 07:15.060]  So now we'll move on to Easy Anti-Cheat and BattleEye, which we'll call the mid-tier anti-cheats of today.
[07:15.260 --> 07:19.300]  Both of these were released in 2006 in our system , and they're still present in today's market.
[07:19.680 --> 07:25.580]  Some of the big games that are using these nowadays are still Fortnite, Rainbow Six Siege, PUBG, GTA, you name it.
[07:25.580 --> 07:33.860]  The player counts in these games peak as high as 3 to 5 million per day, so these anti-cheats need to be in pretty good shape to support a player base that big.
[07:34.400 --> 07:39.540]  Now, these are both kernel-level anti-cheats with signature and heuristic-based detection.
[07:39.640 --> 07:44.400]  Living in the kernel means they have a lot more control and visibility over the whole system overall.
[07:44.420 --> 07:52.840]  This allows for monitoring and blocking unauthorized drivers, detecting modification in the game's memory regions, rogue system call analysis, and a lot more.
[07:52.840 --> 07:58.300]  And with what we're talking about today, it allows us to access and analyze hardware interfaces directly.
[07:58.920 --> 08:06.500]  Even with all that, with all I mentioned, these anti-cheats still are not that good with detecting direct memory access and preventing those kind of hardware attacks.
[08:06.500 --> 08:13.340]  While they're in the kernel, their methods of hardware spoofing detection are still really bad, and they're behind other kernel-level anti-cheats.
[08:13.500 --> 08:16.480]  Similar to... Vanguard.
[08:16.600 --> 08:17.240]  VGK.
[08:17.240 --> 08:21.020]  If you play Valorant League of Legends, you know what VGK is.
[08:21.020 --> 08:25.740]  This was developed in 2020 alongside Valorant, which was their flagship game at the time.
[08:25.740 --> 08:29.620]  It's a kernel-level anti-cheat with advanced signature and heuristic-based detection.
[08:29.620 --> 08:32.700]  Its main appeal is being one of the strongest anti-cheats on the market.
[08:33.060 --> 08:39.860]  What separates this two is that they enforce a lot of strict requirements on your system, like TPM 2.0 and Secure Boot.
[08:39.860 --> 08:53.040]  Some of their methods are employing aggressive memory scanning techniques, encryption of what's called the Control Register 3 and PML 4 memory table, strict integrity checks on devices all connected to the motherboard, and a lot more.
[08:53.040 --> 08:57.800]  When it comes down to DMA, our firmware must be as robust as possible.
[09:02.360 --> 09:03.340]  Alright.
[09:03.980 --> 09:09.320]  I've thrown around the word DMA a lot, but I haven't actually described what it is.
[09:09.320 --> 09:11.040]  So what is DMA?
[09:11.180 --> 09:15.600]  Direct memory access allows an actor to access memory independently of the CPU.
[09:15.700 --> 09:23.520]  The way a normal computer functions, a process through a system wall will request the CPU to retrieve a value found at a certain memory address.
[09:23.740 --> 09:35.920]  The difference with direct memory access is that we use an external FPGA board like we see on the screen over there to access physical memory, otherwise known as RAM, through the memory controller rather than touching the CPU itself.
[09:36.160 --> 09:45.860]  That allows us to covertly transfer memory from that target computer to the attacker computer, bypassing a lot of virtual memory protections or CPU protections.
[09:45.880 --> 09:50.120]  Using that custom firmware allows us to appear as a legal device.
[09:50.120 --> 09:59.900]  We can bypass some stuff like IOMMU, VTD, read and write directly to physical memory, access memory without triggering CPU event logs, and a lot more.
[09:59.900 --> 10:03.680]  We couldn't move on from the slide without talking about PCI-Leach.
[10:03.760 --> 10:09.340]  PCI-Leach provides a toolkit to actually read and write memory on that target system.
[10:09.540 --> 10:17.340]  PCI-Leach serves as a memory analysis framework and it gives us the ability to do memory pattern scanning, page table manipulation, and a lot more.
[10:17.880 --> 10:26.020]  Now PCI-Leach FPGA is an open source repository on GitHub and that contains the actual hardware designs for the FPGA board itself.
[10:26.020 --> 10:31.320]  And using this we can tweak our firmware with system Verilog and booting up Vivado to appear legal.
[10:31.740 --> 10:33.820]  And I've been working on this talk for six months.
[10:33.820 --> 10:36.920]  If any of you have had to open Vivado, I'm so sorry.
[10:36.920 --> 10:39.720]  It's one of the most ridiculous tools I have ever worked with.
[10:41.060 --> 10:47.020]  So now we'll get into the meat of this talk, which is actually building firmware with PCI-Leach FPGA.
[10:47.120 --> 10:53.440]  The main component of direct memory access in this context is to build out that firmware to appear like a legal card.
[10:53.440 --> 11:01.700]  We need to appear like a real legal card, like a network card or something, to actually bypass the entity by just blending in within our environment.
[11:02.120 --> 11:06.720]  So we first start off by selecting a donor card, which can be whatever you want.
[11:06.840 --> 11:13.920]  And then after that we will create a configuration space to present that card as legal and define who we are, what we do.
[11:14.000 --> 11:18.620]  Then we'll step into the write mask, which defines writable bits within the configuration space.
[11:18.740 --> 11:27.440]  Then we'll move forward to a bar controller, which actually manages the memory and defines register for this behavior, which actually allows us to emulate how we act.
[11:27.440 --> 11:31.660]  Then we'll go over a couple additional implementations to really improve our emulation there.
[11:33.340 --> 11:35.320]  So we'll start with the donor card.
[11:35.320 --> 11:39.820]  To begin this process, you need to just go out and find any PCIe card.
[11:40.520 --> 11:42.380]  Anything is really viable.
[11:42.380 --> 11:52.260]  It's always recommended, if you are interested in this, to start with a Realtek Wi-Fi card for its ease of development, specifically relating to how we act, which is the bar controller, more on that soon.
[11:52.580 --> 12:07.840]  In my experience, when I was working on proof of concept for this talk beginning last October, I just drove down Milwaukee PC, grabbed a random Wi-Fi card off the shelf, which led me down the path of developing what was called an RT-5392 firmware, which is a raw link NIC.
[12:09.240 --> 12:14.940]  So now that we got our donor card, we actually got to start talking about defining who we are to appear as legit.
[12:15.140 --> 12:20.980]  The configuration space at its core just defines who this card is and its purpose.
[12:21.040 --> 12:28.760]  Whenever you plug something into the motherboard, on boot, the device will report out and says, hello, this is who I am and this is my purpose.
[12:28.960 --> 12:35.860]  Any kernel-level anti-cheat worth its salt will scan through PCI devices that are connected to the motherboard to check for suspicious behaviors.
[12:36.160 --> 12:43.020]  If we plug in a real DMA card and we've done nothing to it and it reports the anti-cheat that we're a DMA card, we get blocked.
[12:43.020 --> 12:44.620]  It's a really bad decision.
[12:44.920 --> 12:49.740]  So, in order to evade that, we need to start picking apart what are called donor values.
[12:49.740 --> 12:53.560]  So that can fall under device and vendor ID, revision ID, and bar values.
[12:53.560 --> 12:58.700]  We need to spend time logging this so that we can actually reflect that when we go to build out our firmware.
[12:59.180 --> 13:02.780]  And then we can also touch on shadow configuration space too.
[13:02.840 --> 13:15.440]  This allows us to provide higher resolution dump, which you can think about being stored on top of the configuration space as a mask, really to increase granularity since the main IP core is missing a lot of those extended capabilities.
[13:17.040 --> 13:19.740]  And we can step forward to the write mask.
[13:19.740 --> 13:23.360]  So the write mask allows us to create what's called a permission map.
[13:23.360 --> 13:26.920]  We can define which bits in the configuration space are actually writable.
[13:27.400 --> 13:32.960]  Might sound really weird to say that, but a configuration space does actually more than who I am and what I do.
[13:32.960 --> 13:35.900]  It also houses an area to indicate certain events.
[13:35.900 --> 13:37.560]  Most common being error reporting.
[13:37.560 --> 13:45.220]  If our device on a donor card is having difficulty communicating on the system, we need to throw up that error, and that space needs to be writable.
[13:45.300 --> 13:56.720]  Because if we throw up the error and we're stuck on a read-only bit, we're just constantly throwing up that error, and that's a really good detection method for anti-cheats that we're working with in a legal device that is probably not used for good.
[13:57.660 --> 14:02.140]  PCI Leach FPGA doesn't have a write mask built in since it differs per device.
[14:02.140 --> 14:07.720]  We need to actually spend time digging through and reflecting that behavior that is seen in the donor's configuration space.
[14:08.040 --> 14:13.940]  As I said before, anti-cheats, this is a really easy way to check and see if a device is illegal.
[14:13.940 --> 14:17.660]  We can look at known status registers like the link status register.
[14:17.760 --> 14:25.760]  If that's not correctly marked as RW1C or RW for read-write, that's an incident indicator will probably get blocked like that.
[14:31.890 --> 14:34.030]  Now we can step to a bar controller.
[14:34.330 --> 14:37.910]  This is where you're going to spend a lot of your time banging your head.
[14:38.390 --> 14:44.690]  We've defined who we are, we've defined what we do, now we need to start defining how we act with a base address register.
[14:44.970 --> 14:50.370]  The bar is defined within our configuration space and it lets our operating system know where we're actually mapped to.
[14:50.370 --> 14:56.790]  The bar controller sits in that memory region and this basically says this is where you can find me and interact with what I have to offer.
[14:57.410 --> 15:06.870]  That's really difficult to do without some information, so we need to go into two vectors in our donor card using OS debug logs and driver initialization logs.
[15:06.870 --> 15:16.310]  We can use a tool called MMIO trace which logs device behavior and allows us to see how a real donor card acts that we're trying to emulate.
[15:16.830 --> 15:28.190]  What you go through with this is you just load the driver while you're working with the donor card and review a bunch of read and writes that are going on when it does its initial initialization or connected to a network depending on what you're using at.
[15:28.610 --> 15:30.030]  That's not enough.
[15:30.470 --> 15:40.830]  If you were able to look at this, you would have no idea what's going on, so we need to also point ourselves to what's the Linux driver code that's listed on Torvald's GitHub repo.
[15:41.410 --> 15:48.710]  Within this driver code, we're able to see offsets within the C code that actually contextualizes those read and writes that we just dumped from MMIO trace.
[15:48.710 --> 16:02.410]  Then we can use that paired alongside Windows TLP transactions when we pump up the driver using any debugger of your choice to ensure those consistency between operating systems because the requirements to load a driver on Windows and Linux are a little bit different,
[16:02.410 --> 16:05.150]  so we need to make sure we have that aligned to appear legit.
[16:05.570 --> 16:18.710]  Once you got all that, we can start writing our system Verilogs and have our card respond to the target driver, which is almost a bare necessary thing to do at this point to evade detection on things like easy anti-cheater battle line.
[16:20.050 --> 16:24.450]  Then we can move forward and talk a little bit about additional implementations.
[16:24.450 --> 16:25.670]  So I got two listed here.
[16:25.670 --> 16:29.250]  There are a lot more you can do, but I think these are still important to go over.
[16:29.370 --> 16:31.070]  First, we have interrupt handling.
[16:31.070 --> 16:34.150]  This just lets the CPU know that an event has occurred.
[16:34.230 --> 16:42.550]  Whenever you plug in a card and it initializes, it does a data transfer, it throws up an error, status buffer changes, anything you can think of, it always sends an interrupt.
[16:42.990 --> 16:51.070]  Implementing this without this kind of handling higher tier anti-cheats like Vanguard, for example, will pick up that you're suspiciously quiet and just block you.
[16:51.070 --> 16:58.190]  So if a device is not functioning normally, even if it is a completely legit card, it's not sending interrupts, it's not needed, and it just gets blocked.
[16:58.190 --> 17:00.270]  So we really need to emulate that behavior.
[17:00.970 --> 17:08.090]  One of the final stages of true emulation is called link state emulation, specifically relating to, like, network cards, for example.
[17:08.470 --> 17:12.610]  Implementing a link state allows us to actually simulate an active network connection.
[17:12.750 --> 17:25.690]  On higher tier anti-cheats like Vanguard, again, even if we're fully undetectable, if we don't have that net connection, we'll quietly be blocked, because there's no reason to have a Wi-Fi card active and running while you're playing a game if you're not even connected to Wi-Fi for it.
[17:27.170 --> 17:32.910]  So with this, we've talked a lot about firmware, but what actually goes on to the cheating side of things?
[17:33.390 --> 17:39.370]  I think it would first be beneficial if we talk a little bit and give an introduction about what a cheat actually is.
[17:39.630 --> 17:43.970]  So we'll only be talking about external cheats today, because that's more related to DMA.
[17:44.050 --> 17:49.810]  An external cheat refers to a separate executable which operates independently of the game process itself.
[17:49.810 --> 17:56.190]  Doesn't modify any game code directly, it reads and writes memory externally, and it communicates through that memory manipulation.
[17:56.710 --> 18:03.150]  What's nice is DMA lets us bypass a lot of those traditional memory protections through that direct level hardware access.
[18:03.490 --> 18:07.130]  But all of this is a lot tougher without DMA library.
[18:07.250 --> 18:14.710]  This is a publicly available C++ repository that actually unlocks our card's functionality by reading and processing memory from the game.
[18:14.790 --> 18:25.150]  Utilizes a lot of those same components that we see in PCI leach, and it provides a lot of memory read and write operations, pattern scanning, region mapping, page table manipulation and more.
[18:25.370 --> 18:33.890]  Those are a lot of complex operations when it comes down to DMA and that really helps us manage that device communication between the target and attacker computer.
[18:33.890 --> 18:37.770]  And it fully solidifies that gap between hardware and software.
[18:39.670 --> 18:44.030]  So we'll move forward onto what actually goes into developing a cheat.
[18:44.030 --> 18:47.670]  What you're seeing right here, this is not an all-inclusive list by any means.
[18:47.670 --> 18:56.610]  Attack paths will be different per game, but a lot of older games will go over this common attack path, which begins starting by finding the module base address.
[18:56.610 --> 19:09.010]  This is the entry point into the game, where similar to like the bar region where we sit in that region, games also have that memory area that we need to find, so that's a module base address.
[19:09.010 --> 19:12.170]  And once we're in that region, we need to start finding offsets.
[19:12.270 --> 19:23.930]  Games are constantly shifting depending on what a user is doing or when they launch it or what's going on in the system, so we can't actually hard code any memory addresses, that's really bad practice, so we need to do what are called offsets.
[19:24.630 --> 19:31.150]  And alongside of this, games also use what are called pointer chains to keep track of important objects.
[19:31.390 --> 19:38.970]  Games use these pointer networks and mainly house information like player positions, weapon data, and a lot more.
[19:39.010 --> 19:45.870]  When it comes down to newer games like Valorant, we actually need to write logic to bypass pointer encryption, but we'll touch more on that in a little bit.
[19:47.110 --> 19:50.070]  So let's take a look at DMA library itself.
[19:50.070 --> 20:00.010]  The way DMA library starts is by loading those DLLs from PCI leach to actually initialize and manage the card and provide that foundation for what we're working with.
[20:00.090 --> 20:08.130]  Then afterwards, we got to create a device handle to establish communication with the hardware, setting up those command channels and initializing those pathways.
[20:08.350 --> 20:18.110]  Afterwards, we got to do some cleanup and configure registers, which act as control points to managing that DMA transfer parameter and actually initialize the full process to map memory.
[20:18.550 --> 20:24.610]  Now we got all that done, we're ready to actually communicate with our DMA card, we can circle back to pointer encryption.
[20:25.190 --> 20:39.270]  Now Valorant specifically uses a sophisticated encryption to protect some of those critical pointers, such as UWorld, which is the base pointer for Unreal Engine games that we can think about it like that, ActorHealth, where other players are, and a lot more.
[20:39.270 --> 20:47.970]  Encryption is done primarily to restrict that user land and kernel level access to sensitive information by guarding the process's memory table.
[20:48.350 --> 20:57.410]  Again, as earlier, DMA bypasses a lot of those virtual protections, but the issue is it's still encrypted and we can't read anything through this.
[20:57.750 --> 21:01.310]  But we can reverse engineer the Valorant binary itself.
[21:01.310 --> 21:09.670]  We can extract and implement that decompiled decryption algorithm and apply that same logic that Valorant uses to actually decrypt those core pointers.
[21:09.790 --> 21:18.070]  Once we got those target values, we can import and implement that functionality to draw boxes on the screen relative to where other actors are.
[21:18.530 --> 21:24.850]  World of Screen function, you kind of can't see at the bottom there, but it's the mathematical heart of ESP.
[21:24.850 --> 21:28.170]  ESP just means being able to see through walls and things like that.
[21:28.170 --> 21:31.650]  And we can convert that 3D coordinates to 2D positions.
[21:31.650 --> 21:38.290]  That uses the camera's position, player's location, field of view, and a couple different factors to actually get that to render on the screen.
[21:38.990 --> 21:44.150]  Fully using all this, we gain our unfair advantage of actually being able to see through walls.
[21:45.290 --> 21:52.250]  I've been rattling off a lot about firmware and cheat development, and it's a lot, but what does this actually look like in practice?
[21:52.810 --> 22:04.510]  So I'll explain this a little more in a second, but we have our attacker computer right here, and we're connecting to our DMA through a cable, turning the screen through our cloud.
[22:04.510 --> 22:14.530]  Usually you would not be able to see through that, but since we're running our cheat on that attacker computer and transferring that data over from the DMA card to that, we can actually manipulate and modify it there.
[22:16.250 --> 22:19.670]  That's a lot there, and that's really confusing just to look at.
[22:19.810 --> 22:34.450]  So the way this cheat works, we have the DMA card plugged into the target PC itself, it's pulling those key values from there, bringing it over to the attacker laptop where our cheat is actually running, and then we're using that decompiled algorithm to actually display everything,
[22:34.450 --> 22:44.390]  and then we render those boxes on the screen, and then we use what's called a fuser, which actually overlays HDMI onto the main target PC monitor that we see there.
[22:47.000 --> 22:50.660]  We've talked a lot, how do you even detect any of this?
[22:50.680 --> 22:54.000]  Method is through errors we've made along the way.
[22:54.200 --> 23:03.960]  Any good anti-cheat will scan through the device's configuration space, it'll look through its behaviors and cross-reference between known devices to ensure that everything is legal.
[23:04.200 --> 23:07.720]  From a firmware view, human error is what will trip us up the most.
[23:07.720 --> 23:21.080]  Incorrect configuration space values, improper bar implementations, suspicious memory scanning or pattern accesses will cause signature and heuristic based detection to flag us as illegal and block us rendering DMA defunct in that case.
[23:21.340 --> 23:33.480]  From a software angle, we still need to make sure we're not doing any sort of unusual read and write frequencies, non-standard access sequences, any large scale memory scanning operations that will immediately trip you in detection.
[23:33.740 --> 23:39.640]  The true goal of evasion when it comes down to direct memory access is to blend in as much as possible.
[23:39.660 --> 23:44.120]  We need to have our hardware in a good state with emulation and our software needs to blend in.
[23:45.540 --> 23:47.200]  Thank you guys so much.
[23:47.200 --> 23:48.760]  I appreciate it.
[23:57.110 --> 23:59.390]  I've got a couple minutes for questions.
[24:16.880 --> 24:18.180]  Yep, exactly that.
[24:18.180 --> 24:20.100]  We're trying to blend into our environment.
[24:43.130 --> 24:45.710]  Sorry for holding my hand up, it's so bright right now.
[24:46.010 --> 24:51.950]  So what you're saying is why don't we just use the donor card itself and then implement DMA functionality?
[25:07.570 --> 25:14.420]  The main reason we use... because we have to use...
[25:14.420 --> 25:29.860]  it has a certain chip, XLinux 7 something, I'm horrible at pronouncing it, we need to have that chip itself and have some of the data and JTAG functionalities on that so we can't actually repurpose the firmware on that because it's not really compatible with that.
[25:29.940 --> 25:35.420]  Plus PCI leash FPGA itself has a lot of the backbone designs that we would actually need.
[25:35.420 --> 25:42.660]  It would require reengineering the whole thing so it's a lot easier to just start out with the original hardware design itself and then just emulate it from there.
[25:44.520 --> 25:45.760]  Yeah, exactly.
[25:57.910 --> 25:59.730]  Possibly I haven't fully looked into it.
[25:59.730 --> 26:04.090]  There might be some sort of incompatibility issues but I could get back to you on that.
[26:19.230 --> 26:29.430]  Do we have to deal with any address space layout randomization ASLR correctly?
[26:30.550 --> 26:32.710]  Not to my knowledge.
[26:32.710 --> 26:33.630]  I could be wrong on that.
[26:33.630 --> 26:36.890]  I've mainly focused on the firmware side of things.
[26:36.890 --> 26:42.230]  I mainly use this as a kind of just example and then running the cheat off there.
[26:42.230 --> 26:46.870]  So some of the more specific aspects of C++ design I'm not too familiar with.
[26:46.930 --> 26:53.290]  At least when it comes down to like... I can still get back to you though.
[26:53.290 --> 26:55.210]  I can do a source code analysis.
[26:59.250 --> 27:00.550]  I did not.
[27:00.550 --> 27:07.630]  I purposely used a completely separate system and didn't log into online games to test any of this because I didn't want to burn myself.
[27:29.020 --> 27:30.280]  You're good.
[27:33.540 --> 27:34.860]  Which slide?
[27:49.510 --> 27:50.930]  Oh, okay.
[27:50.930 --> 27:56.990]  Yeah, again I'm a little lackluster in the C++ cheat development space.
[28:36.840 --> 28:39.580]  Yeah, no, that's completely viable.
[28:39.620 --> 28:48.160]  I know who's credited here, Noah Tonegate is doing research using DMA to bypass like EDR or attack EDR itself.
[28:48.600 --> 28:50.120]  Completely feasible.
[28:50.120 --> 28:57.300]  I haven't fully looked into it too much because I was more focused on a cheating lens because I think it's a better introductory point because it does get a little heavy.
[28:57.680 --> 29:01.700]  I can probably send you a bit more specialized resources on that though if you're curious.
[29:01.820 --> 29:02.260]  Okay.
[29:03.440 --> 29:04.800]  We are at 3.30.
[29:04.800 --> 29:07.200]  I want to be respectful of people's time.
[29:11.280 --> 29:12.420]  That's tough.
[29:12.900 --> 29:16.500]  I'll say Black Ops 1 because I played that a lot as a kid.
[29:16.500 --> 29:17.520]  It was really enjoyable.
[29:18.220 --> 29:18.780]  Okay.
[29:18.780 --> 29:19.920]  Thank you guys so much.
[29:19.920 --> 29:23.180]  If you have any additional questions, please do not hesitate to reach out to me.