# Disconnecting Users from Virtual Worlds with a Single Packet: an Unreal Untold Story

Hugo Bertin, Ilies Benhabbour, Marc Dacier, Yérom-David Bromberg

► To cite this version:

Hugo Bertin, Ilies Benhabbour, Marc Dacier, Yérom-David Bromberg. Disconnecting Users from Virtual Worlds with a Single Packet: an Unreal Untold Story. iMETA 2025 - 3rd International Conference on Intelligent Metaverse Technologies & Applications, Oct 2025, Dubrovnik, Croatia. pp.67-74, 10.1109/iMETA66706.2025.11306743. hal-05202617

HAL Id: hal-05202617

https://hal.science/hal-05202617v1

Submitted on 7 Aug 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Disconnecting Users from Virtual Worlds with a Single Packet: an Unreal Untold Story

Hugo Bertin

Univ Rennes, CNRS, INRIA,
IRISA

Rennes, France

hugo.bertin@irisa.fr

Ilies Benhabbour

KAUST

Thuwal, Saudi Arabia

ilies.benhabbour@kaust.edu.sa

Marc Dacier

KAUST

Thuwal, Saudi Arabia

marc.dacier@kaust.edu.sa

Yérom-David Bromberg

Univ Rennes, CNRS, INRIA,
IRISA

Rennes, France

david.bromberg@irisa.fr

***Abstract***—Online worlds, with online games at the forefront, have become ubiquitous in our lives. In 2024, the gaming industry worldwide revenue was estimated at US$455 billion [1]. Yet, this industry is facing a growing number of cheating actors and techniques.

We introduce new attacks targeting multiplayer games based on Unreal Engine (UE), such as Fortnite, PUBG, and Valorant. These attacks disconnect players from ongoing game sessions against their will. Cheaters can launch them as a Denial-of-Service against opponents with very few packets (sometimes only one) to steal the victory from the target without exposing themselves as fraudsters.

This paper shows how such issues present in a single game engine can spread widely across several games produced by different editors, focusing on Unreal Engine, whose source code is publicly available. UE is also commonly found in digital twins, virtual reality, and other Metaverse solutions. We present our analysis of the design and implementation choices made within Unreal Engine. We cover how to exploit UE networking protocols and discuss how to defeat some common countermeasures used on the Internet against IP spoofing. We propose some mitigation strategies for video game developers.

***Index Terms***—online games, game engine, multiplayer, networking, denial of service, metaverse

# I. INTRODUCTION

With 1.2 billion players worldwide in 2024 [2], gaming is the most democratized form of virtual world. Online games expand their ecosystem to be more immersive, paving the way for tomorrow's virtual worlds and the Metaverse [3], [4]. However, the long-term sustainability of this ecosystem is threatened by cheating actions [5]. Cheaters seek unfair advantages, undermining honest players' quality of experience as well as the fairness in E-Sports, motivated by the importance of the rewards [6].

From a technical point of view, virtual worlds, such as online games and the metaverse [3], are shaped with game engines [7]. They are software frameworks providing libraries implementing features commonly required by games, such as graphics rendering, physics simulation, or networking.

In this paper, we present novel attacks targeting Unreal Engine, one of the most famous game engine. We show that we can disconnect any user from an ongoing virtual session with a single packet. This can be done on the Internet as soon as an attacker obtains the victim's IP address or in a LAN (e-sport competition settings) without prior knowledge. Firewalls

do not prevent these attacks, as this would require knowledge on the structure of the application protocol semantics. Source Address Validation, which aims to prevent IP spoofing on the Internet, can be easily bypassed. Malicious actors can leverage these attacks to perform DoS attacks against virtual worlds, for instance, to cheat in video games.

We present the approach we followed to investigate the security issues in the networking protocols used by Unreal Engine. It combines dynamic experimentation and a systematic static code analysis approach to understand the design choices realized in the networking components regarding what behavior can be triggered by data embedded in a packet and determine the comprehensive set of packets that can be exploited to disconnect a user. It is important to understand that these attacks do not exist because of a vulnerability or an implementation error. They are conscious design choices.

These attacks could be prevented by following different user-authentication and encryption strategies in Unreal Engine. As the source code is publicly available, virtual worlds developers could directly implement these mitigations to counter the presented attacks and enhance the robustness of their systems.

This paper solely focuses on Unreal Engine, whose source code is available publicly. However, it is quite likely that other game engines, such as Unity, are not immune to these issues. More generally, this knowledge can benefit software developers to integrate security considerations in the design of other networked systems.

All the novel content regarding security issues presented in this paper was first responsibly disclosed to the parties concerned.

Section II presents the background regarding virtual worlds, such as games, and their inherent problems with cheating. Section III introduces and explains the new DoS attacks that exploit unreal engine networking components. Section IV covers the practical exploitability of the vulnerability in real-world environments. Section V discusses the possible mitigation strategies to enhance the robustness of virtual worlds. Section VI discusses the ethical considerations. Section VII concludes the paper.
## II. BACKGROUND

Online games are virtual worlds that interconnect players from distributed locations around the globe. As other distributed systems deployed on the Internet, they are facing security threats.

### A. Cheating in online games

Cheating is an important problem in the video game industry [5]. Different forms of cheating exist, exploiting different attack vectors. In the academic context, the research focuses on client-level cheats. These cheats are executed on the client's system. They are malicious programs that tamper with the game executable to modify legitimate game behavior [8]–[10]. Such examples are bots [11]–[13], or Information Exposure cheats [13], [14].

Cheaters can also tamper with the game system at the network level, where game state updates are exchanged to keep the game synchronized across all nodes. Network cheats can be divided between network-flow disruption [13], [15]–[17] and packet tampering [18], [19]. The first one manipulates the flow of transmitted packets to disrupt the synchronization mechanisms of the game systems [20]. Existing works investigate network flow disruption cheats, seeking for detection techniques [21], [22]. With the latter, cheaters may directly exploit the content of the data embedded within network packets to tamper with online game network protocols.

### B. Game Engines

Virtual worlds are implemented using game engines. They are software providing a collection of tools and libraries to help in game developments. This includes editing tools facilitating the implementation logic behind games and virtual worlds as well as a collection of libraries implementing core components to render a virtual world. This can be the physics engine of a virtual world, the graphics rendering or also the different operations related to system resources management, network communications, and state synchronization. Game engines' usage is not limited to video games and the metaverse but is also leveraged in other industries such as automotive Human-Machine Interface or the movie industries. This leads to a wide set of different systems sharing the same game engine and thus sharing pieces of software. From a security point of view, this is a double-edged sword as vulnerabilities spread wider, but, on the other hand, directly strengthening the game engine enhances the robustness of all the systems leveraging it.

### C. Unreal Engine networking architecture

Unreal Engine is a popular game engine used to power some of the most famous names of the game industry, such as Fortnite, PUBG, Rocket League, Valorant, The Finals, or Sea of Thieves. This paper focuses on Unreal Engine as its source code is publicly available. Unreal Engine multiplayer networking architecture follows a client-server model. UE's communications are based on an application-layer protocol on

<figure><img src="image_2.png" /><figcaption>Fig. 1: Structure of a payload in Unreal Engine's game packets. Header defines the type of packet. Packed Header Bunches contains information about the sequence of bunches received. Bunches contain the game objects' state updates. Encryption is not applied to the header.</figcaption></figure>

top of UDP for the communications between the clients and the server.

UE maintains an application-layer connection between each client and the server. These connections are established through a handshake of UDP packets initiated by the client. The game client already knows the IP address and listening port number of the game server with whom it wants to communicate. In practice, this information can be retrieved from the game provider through a first communication channel that authenticates the players and manages matchmaking services. During this handshake, a cookie based on a server-generated secret is exchanged. After receiving the cookie, the client is simply sending it back without any modifications. The aim is to verify that the client sending the join request owns the IP claimed. As the cookie depends on non-deterministic data only known by the server, it cannot be forged by adversaries. However, it is important to note that anyone seeing the cookie transmitted on the network could resend it. When the server receives-back the cookie from the client, it creates a connection for game communications in which the cookie is not used anymore. The server identifies each valid connection only thanks to the client's IP address and port.

During the game session, all the packets received from a client are attributed to the related connection based on the IP address and port. To communicate information relative to the game session and the progress of the game state, UE uses packets containing data structured as presented in Figure 1. The packet payload starts with a header containing bits defining the type of packet. Examples of such bits specify if the packet is a handshake or game packet (bits 5-6). The following parts of the payload contain data relative to the game state updates. It starts with a second header (Packed Header Bunches), including information about the sequence of updates received. A sequence number is specified to protect from replay attacks and detect out-of-order packets. Only payloads with a sequence number greater than the last payload received are accepted. Additionally, the sender acknowledges the last sequence number received in the field Acked Sequence Number. The information relative to the game state updates is organized in so-called bunches. Each bunch contains an update about a single object in the game.

Different encryption modules are implemented in UE to protect the confidentiality of the game information embedded
in the packets' data. The different encryption algorithms that
developers can optionally add to their game are the following
[23]: AES-ECB [24], AES-GCM [24]. They can also leverage
the DTLS protocol [25], [26] (set up with AES-GCM).

It is important to note that the modules handling packet
encryption in Unreal Engine only encrypt the bits after the
header, as described in Figure 1. Hence, the header is left
unencrypted when using UE's network encryption modules.

### III. NEW ATTACKS EXPLOITING UNREAL ENGINE SECURITY FEATURES

The general idea of the attack is to disconnect users in
a virtual world session by sending a specific packet. This
behavior exists in Unreal Engine versions 4 and 5, the latest
version at the time of this writing. We did not test on older
versions as their source code is not available. The attack
exists under several flavors, with different packets, for different
reasons. Videos demonstrating the attack on real games are
available in the linked dropbox folder [27].

#### A. Identifying the root causes behind these vulnerabilities

This subsection details the approach conducted to un-
derstand the design choices associated with the networking
primitives in UE and how they can be exploited to carry out
a DoS attack against a user.

1) **Dynamic Experimentation:** To obtain a first assessment and insights about UE networking design, we developed a sample game on top of the engine. In this game, we reproduced simple gameplay logic that can be found in real shooting game, such as shooting and character movement. The aim was to leverage the access to the engine source code to dynamically log and trace the functions called when data is received by the engine. This phase enabled us to identify two important functions. The first one is `UNetConnection::ReceivedRawPacket` [28]. This function processes the payload of a received packet. The second one is `UNetConnection::Close` [29]. This method is invoked to disconnect players.

2) **Static code analysis:** We have carried out a static analysis of UE source code to understand how the data embedded in a received packet is handled by the various engine modules and if potential vulnerabilities could be identified. For this purpose, we leveraged a tool for automated documentation generation: Doxygen [30]. This tool provides automated diagram generation, such as collaboration, inheritance diagrams, and call graphs. To understand the process flow behind the reception of a packet in UE, we traced the graphs of the methods that can be called after `UNetConnection::ReceivedRawPacket`.

The call graph presented in Figure 2a represents the
different paths leading to the `UNetConnection::Close`
method. We can also identify the function
`UNetConnection::ReceivedRawPacket` on this
diagram. This enables us to delimit how the data embedded
in a received network packet propagates in the engine and
how it can trigger specific reactions.

This graph includes several methods that
cannot be reached by a path starting from the
`UNetConnection::ReceivedRawPacket`, i.e., that
cannot be triggered by a payload received. Therefore, these
functions are out of interest in our analysis. Figure 2b
represents the same graph as in Figure 2a, simplified to only
keep the possible paths starting from a packet's reception
(`UNetConnection::ReceivedRawPacket`) and
leading to a disconnection (`UNetConnection::Close`).
This second graph presents a limited number of functions
(14) that can be read and analyzed manually to understand
their behavior and to identify the parameters that lead to the
disconnection of a player.

#### B. The root causes

Leveraging the static code analysis method, presented in §III-A2, we analyzed UE's packets reception flow. We identified different payloads propagating in UE source code to disconnect a player related to the connection attributed to the received packet. The idea behind this behavior is illustrated in Figure 3. After receiving a packet (in (1)), the engine performs several sanity checks (2) to verify that specific fields of the data contained in the packet comply with the defined network protocols. When the checks are successful, the data is processed further to extract embedded game actions (3). On the other hand, when a check fails, the engine disconnects the player from the game (4) by calling `UNetConnection::Close` [29]. This code runs either at the client or the server. When executed, it notifies the other endpoint of the reason for the disconnection before terminating the connection. Disconnected players can no longer send or receive game-related information. To communicate again with the game server, they must repeat the connection process described before.

These checks are likely to have been initially designed for
security purposes to disconnect suspicious clients trying to
send unexpected packets to the server. However, a malicious
player A spoofing player B's IP address can exploit this feature
by sending a single faulty packet to the game server. This
disconnects B from the game, hence performing a Denial-of-
Service attack against B. It is worth noting that it also works in
the other way, spoofing the server's IP address and sending a
packet to B can disconnect B. This doubles the attack surface
and the number of attack scenarios. When the client receives a
faulty packet, it only notifies the server running the game that
an error occurred in the packet handler before disconnecting,
without providing any further details. Thus, the server cannot
distinguish between an error that occurred during the transport
of a legitimate packet it sent and a faulty packet sent by a
malicious actor.

In this case, the use of UDP, chosen to tolerate packet loss
without degrading the user experience, leads to vulnerabilities
that can be exploited.

It is worth mentioning that other verifications are performed
by UE while processing a payload. However, those checks are
<figure><img src="image_3.png" /><figcaption>Fig. 2: `UNetConnection::Close`'s caller graph (top) and its simplified version (bottom), only showing the paths starting from packets' reception to disconnection.</figcaption></figure>
<figure><img src="image_4.png" /><figcaption>Fig. 3: Packets reception process flow in Unreal Engine. When the sanity checks fail, UE disconnects the player owning the sender's IP address.</figcaption></figure>

<table><caption>TABLE I: List of the types of payloads disconnecting a player when received by UE.</caption><thead><tr><td>Method</td><td>Disconnection reason</td><td>Exploit</td></tr></thead><tbody><tr><td>UNetConnection:: ReceivedRawPacket</td><td>Error when processing a connection packet</td><td>Handshake bit: 1 + Garbage Data</td></tr><tr><td>UNetConnection:: ReceivedRawPacket</td><td>Error when decrypting an incoming packet</td><td>Garbage Data (requirement: using UE encryption modules)</td></tr><tr><td>UNetConnection:: ReceivedPacket</td><td>Unexpected Acked Sequence Number</td><td>Max SeqNumber + Data != Last Notified PacketId for the AckSequenceNumber in the Packed Header Bunch</td></tr><tr><td>UNetConnection:: DispatchPacket</td><td>Bad Channel Index</td><td>Max SeqNumber + Garbage Data in the channel index in a Bunch</td></tr></tbody></table>

not considered as critical as the previous sanity checks and do not disconnect the player. An example is the check made on the sequence number to verify that the packet received is not replayed or out-of-order. When this check fails, the packet is discarded without disconnecting the player.

### C. Identified payloads

We identified four types of payloads failing the sanity checks, detailed in Table I. The column *Method* refers to the method in UE source code triggering the disconnection. *Disconnection reason* refers to the reason to invalidate the packet. *Exploit* refers to the specific fields in the payload that could be exploited to trigger a disconnection.

The engine performs the sanity checks concerning the two last payloads shown in Table I after verifying the sequence number, which discards any out-of-order or replayed sequence. This verification only checks if values are less than or equal to the last one received. However, packets with abnormally greater sequence numbers are not discarded. Hence, this check can be bypassed by setting the sequence number field in the payload to its maximum value (16383). It is important to note that the two last payloads will not disconnect the player if the last sequence number received by the engine is the maximum value, a situation that occurs once every 16,384 times.

None of the packets listed in Table I require knowledge about a previous packet. In other words, attackers can craft such packets even if they are incapable of seeing the packets sent to/from the victim. Attackers can be anywhere in the world.

UE encryption modules are not a solution to prevent such attacks. Once again, it is due to design choices deliberately made within the engine. As presented in §II-C, the encryption

is applied to the payload's fields following the header. However, as shown in Table I, corrupting the header fields suffices to succeed. Furthermore, even if the header fields' integrity is preserved, an error in decryption leads to a disconnection (Table I).

## IV. PRACTICAL EXPLOITABILITY OF THE ATTACK

This section drills down into the details that must be considered when launching these attacks in a real-life gaming context. We distinguish two different types of gaming environments:

* LAN setup, which can be used in some e-sport competition.

* Online setup, where players communicate with the game server over the Internet.

### A. LAN setup

A malicious player can directly send packets to all other players within the same LAN using a broadcast address at the MAC layer (`ff:ff:ff:ff:ff:ff`) and at the IP layer (`255.255.255.255`). To see the victims' clients accepting the packets, the source `IP:Port` should align with the server's, which is the same for all the players. Hence, it is known by the attacker if the attacker takes part in the game. The only missing information for the attacker is the destination port number used by the targeted UE clients. This port is a number selected within the dynamic port range (49152-65535), representing 16384 possibilities. Packets of 52 bytes on wire (layer 1) are enough to embed a payload (2 bytes) that definitely disconnects a player upon reception. At 30 Mbit/s, it takes less than 0.25s to bruteforce this range of ports and, thus, disconnect all players in the LAN. To avoid detection, the attacker can spoof a MAC source address different than its own. Additionally, attackers can target themselves, which can be beneficial if they are about to lose the game. The result is a DoS attack that disconnects all players from the game, including the attacker. A video demonstration, recorded on Valorant, can be found in the linked Dropbox folder [27].

### B. Online setup

In this subsection, we detail the procedure to disconnect a player on the Internet. Figure 4 illustrates the scenario described throughout the subsection.

Unreal Engine identifies users with the IP address and port number specified in the packets received. As players are usually behind a firewall, the tuple of address and port seen by the server contains the firewall's IP address and a port dynamically attributed by the firewall to this communication. Hence, two tuples of IP addresses and ports are required to craft a faulty packet that is associated with an existing connection by the engine to disconnect the related user:

(i) The game server `IP:Port`, which is the same for all the players, thus known by attackers as long as they take part in the same game session.

(ii) The targeted player's firewall IP address and the port number attributed.
<figure><img src="image_5.png" /><figcaption>Fig. 4: Diagram illustrating a possible attack scenario on the Internet. Clients A and B are playing in the game session hosted by a game server S accessible through the Internet. As B is continuously sending packets to S, B's firewall accepts packets coming from S to the destination of B. Attacker A crafts a faulty packet impersonating S and sends it to B, disconnecting B from the game.</figcaption></figure>

As explained in §III-B, a player gets disconnected when a faulty packet is either received by the server or the client. Then, both (i) and (ii) can either be used as source or destination tuples.

1) *Spoofing an IP address on the Internet:* Attackers must craft and send a packet with a source IP address that they do not own: the targeted player or the game server IP address. Modifying the source IP address of a packet to impersonate someone else and hide the sender's identity is called IP spoofing [31]. In theory, Autonomous Systems (ASes) on the Internet are expected to enforce Source Address Validation (SAV) [32] to counter IP spoofing. This prevention technique consists of filtering packets at the edge of the ASes by verifying that the packet's source address belongs to an AS connected to that verifying AS or to an AS whose traffic is routed through it. This filtering should be realized for inbound packets (ingress filtering). However, in practice, SAV is not well enforced on the Internet. Dai and Shulman showed in 2021 that 68,9% of the Autonomous Systems on the Internet are not enforcing ingress filtering [33].

This issue has been assessed by the Spoofer project [34]. Spoofer is an open-source tool and measurement project pinpointing the different ASes on the Internet to determine their vulnerability with respect to source address spoofing.

Attackers wanting to launch an attack presented in this paper only need to rent a server located within an AS not enforcing SAV, as reported by the Spoofer project.

2) *Finding the firewall's port:* The attacker does not know which port number the firewall has assigned to the communication between the victim and the game server. As firewalls may implement port randomization, the port number seen by the player can be any of the existing ports (0-65535). Assuming an attacker knows the victim's IP address, it takes them less than 1 second at 30 Mbit/s to bruteforce the whole range of possible ports, sending packets representing 52 bytes on wire

(2 bytes of payload).

3) *Finding an IP address on the Internet:* The last unknown information for an attacker at this point is the targeted player's firewall IP address. IP addresses are public information on the Internet and can be found employing different techniques.

One example of such techniques is demonstrated in the dropbox folder [27]. In this example, we leverage the PlayStation Network (PSN), which is a social network interconnecting all the PlayStation devices and providing them voice chats. The voice communication channels are implemented thanks to a Peer-to-Peer (P2P) architecture. Thus, establishing a communication channel with a player (who can be identified by his display name) is enough to obtain his IP address. In other words, if a player answers a P2P PSN call, the caller (the attacker) can observe the player's IP address.

There are other ways to find someone's IP, but discussing them here would only benefit malicious actors which, for ethical reasons, we have to refrain ourselves from doing.

4) *Summary of the attack, highlighting the different network devices:* The summary of the steps required to launch the attack on the Internet is presented in Figure 4. Players are behind firewalls. The IP address exposed to the game server is the one of the firewall protecting the victim. As they continuously communicate with the game server, any packet with the right source and destination tuples is accepted by the firewall and forwarded to the user.

The attacker (Client A) is targeting a player (Client B) sharing the same game session. Thus, A knows the IP address and port number of the game server S. A has access to a server located within an AS that does not prevent IP spoofing. When launching the attack, the attacker crafts a packet spoofing the game server's IP and port number as source, with the targeted victim's firewall IP address and port number as destination. This packet contains one of the faulty payloads, identified in Table 1. When the packet arrives at the targeted player's
firewall, it is identified as a packet coming from the game server S (source tuple) and going to the port attributed to Client B. As this is an existing communication from the firewall perspective, the packet is accepted and routed to the player's client. After receiving the packet, UE client informs the server that the sanity checks failed when parsing the payload, resulting in the server closing the connection with client B. The player experiences a disconnection from the ongoing game session.

An example of this attack, reproduced on Fortnite, can be found in the dropbox folder [27].

## V. DISCUSSIONS ABOUT THE MITIGATIONS STRATEGIES

This section discusses the mitigations strategies that could be followed by developers to implement a virtual world resilient to the attacks presented in this paper, as well as their limitations.

The design choice of disconnecting players when receiving malformed payloads is likely to have been defined to protect Unreal Engine from malicious actors trying to forge packets, which is good from a security point of view. However, the possibility of IP spoofing has been ignored in this design. Thus, we argue that the game engine should be tolerant against IP spoofing and protect against forged malicious packets at the same time.

The first strategy possible is to authenticate and verify the integrity of the packets by adding a Message Authentication Code (MAC) [35] to the payload. The sender computes the MAC with the payload's data and a secret key shared with the receiver. The receiver can recompute the MAC at reception to verify its similarity with the version received to verify the packet's authenticity. A packet detected as forged should not disconnect the player related to the connection. The MAC embedded in a packet adds an overhead to the size of packets exchanged, depending on the cryptographic algorithm used.

It is worth noting that another workaround to counter those attacks could be to modify UE's networking design to discard packets detected as non-compliant to the game protocols (failing the sanity checks) without disconnecting players. This should be done besides encrypting those packets. Unreal Engine's encryption design choices to only encrypt the payload's fields following the header should be reviewed to include the header and protect its exploitation. The problem is thus not the choice of the encryption algorithms but the way it is implemented and the content to which it is applied.

As UE source code is publicly available and can be easily modified by any developers, we strongly encourage them to fix the code as explained.

## VI. ETHICAL CONSIDERATIONS

Before publishing any information related to the attacks described in this paper, we have responsibly disclosed them to the concerned parties. We reached out to five video game editors selling products we had experimentally verified that they were vulnerable to these attacks, including Epic Games, the developer of Unreal Engine. We provided them a detailed

explanation of the vulnerability, video demonstrations, and a server already set up to reproduce the attacks without requiring any development work.

The answers from the security teams mentioned the vulnerability was "informative". They refuse to consider these vulnerabilities as severe ones because of the claimed (according to them) difficulty of identifying and spoofing an IP address on the Internet. For reasons explained in Section IV, we did strongly disagree with this assessment. However, at the time of this writing, we did not observe any fix; the attack is still working on every game identified (and probably many others).

## VII. CONCLUSION

While making the task easier for game developers, game engines also constitute a single point of failure for all the systems leveraging them. Consequently, achieving security at the engine level is primordial to strengthening the overall game industry.

This paper disclosed and explained new powerful DoS attacks exploiting the design choices of the networking layer of Unreal Engine. We also focused on the usage of different mechanisms that are used for security on the Internet, such as firewalls and IP address spoofing prevention. It is our hope that this work will be an eye-opener for the community on exploits that impact big names in the video games industry and can potentially propagate to more important failures in tomorrow's virtual worlds if they are not fixed.

## REFERENCES

[1] J. Clement, "Global video game industry revenue 2029," Sep 2024, [Accessed 12-03-2025]. [Online]. Available: https://www.statista.com/forecasts/1344668/revenue-video-game-worldwide

[2] N. Kumar, "23 esports viewership statistics of 2025 (audience growth data)," Nov 2024, [Accessed 12-03-2025]. [Online]. Available: https://www.demandsage.com/esports-statistics/

[3] A. Kane, "What game engine to use in 2024: Tools for building the metaverse," medium, [Accessed 31-03-2025]. [Online]. Available: https://medium.com/@aka.andrew.kane/what-game-engine-to-use-in-2024-tools-for-building-the-metaverse-fb8ba1d10735

[4] T. Zenou, "A novel predicted the metaverse (and hyperinflation) 30 years ago," June 2 2022, [Accessed 12-03-2025]. [Online]. Available: https://www.washingtonpost.com/history/2022/06/30/snow-crash-neal-stephenson-metaverse/

[5] N. Granados, "Report: Cheating is becoming a big problem in online gaming," Apr 2018, [Accessed 12-03-2025]. [Online]. Available: https://www.forbes.com/sites/nelsongranados/2018/04/30/report-cheating-is-becoming-a-big-problem-in-online-gaming/

[6] J. Weatherbed, "Apex Legends devs confirm esports hacking incident, respond with 'layered' updates," News article. URL https://www.theverge.com/2024/3/18/24104666/apex-legends-postpones-alg-s-competition-hack-concerns, Mar 2024, [Accessed 2024-10-16].

[7] Phil, "What is a game engine: An essential overview for beginners - draw & code," Jan 2024, [Accessed 12-03-2025]. [Online]. Available: https://drawandcode.com/learning-zone/what-is-a-game-engine/

[8] M. S. Anwar, C. Zuo, C. Yagemann, and Z. Lin, "Extracting Threat Intelligence From Cheat Binaries For Anti-Cheating," in 26th International Symposium on Research in Attacks, Intrusions and Defenses, ser. RAID '23. ACM, 2023, p. 17-31.

[9] E. Kaiser, W.-c. Feng, and T. Schluessler, "Fides: remote anomaly-based cheat detection using client emulation," in 16th ACM Conference on Computer and Communications Security, ser. CCS '09. ACM, 2009, p. 269-279.
[10] P. Karkallis, J. Blasco, G. Suarez-Tangil, and S. Pastrana, "Detecting video-game injectors exchanged in game cheating communities," in *26th European Symposium on Research in Computer Security (ESORICS)*. Springer, Oct 2021, pp. 305-324.

[11] M. Choi, G. Ko, and S. K. Cha, "BotScreen: Trust Everybody, but Cut the Aimbots Yourself," in *32nd USENIX Security Symposium (USENIX Security 23)*, 2023, pp. 481-498.

[12] M. L. Han, J. K. Park, and H. K. Kim, "Online game bot detection in fps game," in *Proceedings of the 18th Asia Pacific Symposium on Intelligent and Evolutionary Systems-Volume 2*. Springer, 2015, pp. 479-491.

[13] S. D. Webb and S. Soh, "Cheating in networked computer games: a review," in *2nd International Conference on Digital Interactive Media in Entertainment and Arts*, 2007, p. 105-112.

[14] J. Hao and W. Cai, "Measuring information exposure attacks on interest management," in *2012 ACM/IEEE/SCS 26th Workshop on Principles of Advanced and Distributed Simulation*. IEEE, 2012, pp. 133-144.

[15] I. Benhabbour, Y.-D. Bromberg, M. Dacier, S. Dietrich, R. M. Rodrigues, and P. Esteves-Verissimo, "Attacks on tomorrow's virtual world," in *2023 53rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks - Supplemental Volume (DSN-S)*, 2023, pp. 105-110.

[16] C. GauthierDickey, D. Zappala, V. Lo, and J. Marr, "Low latency and cheat-proof event ordering for peer-to-peer games," in *Proceedings of the 14th international workshop on Network and operating systems support for digital audio and video*, 2004, pp. 134-139.

[17] A. Maario, V. K. Shukla, A. Ambikapathy, and P. Sharma, "Redefining the risks of kernel-level anti-cheat in online gaming," in *2021 8th International Conference on Signal Processing and Integrated Networks (SPIN)*. IEEE, 2021, pp. 676-680.

[18] P. Laurens, R. F. Paige, P. J. Brooke, and H. Chivers, "A novel approach to the detection of cheating in multiplayer online games," in *12th IEEE International Conference on Engineering Complex Computer Systems (ICECCS 2007)*. IEEE, 2007, pp. 97-106.

[19] J. Smed, T. Kaukoranta, and H. Hakonen, "Aspects of networking in multiplayer computer games," *The Electronic Library*, vol. 20, no. 2, pp. 87-97, 2002.

[20] S. Liu, X. Xu, and M. Claypool, "A survey and taxonomy of latency compensation techniques for network computer games," *ACM Computing Surveys (CSUR)*, vol. 54, no. 11s, pp. 1-34, 2022.

[21] S. Shaikh, H. Bertin, M. Dacier, and Y.-D. Bromberg, "A framework to enable cheating detection in multiplayer online games," in *Cybersecurity*. Cham: Springer Nature Switzerland, 2025, pp. 166-181.

[22] V. Tandon and J. Devore, "Detecting lag switch cheating in game," May 2 2017, uS Patent 9,636,589.

[23] A. Koumandarakis, "Global video game industry revenue 2029," Mar 2024, epic Games Dev Community, [Accessed 31-03-2025]. [Online]. Available: https://dev.epicgames.com/community/learning/knowledge-base/6PBP/unreal-engine-how-to-enable-encryption-using-packet-handler-components?locale=de-de

[24] F. Maino, U. Blumenthal, and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model," RFC 3826, Jun. 2004. [Online]. Available: https://www.rfc-editor.org/info/rfc3826

[25] E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3," RFC 8446, Aug. 2018.

[26] N. Erinola, M. Maehren, R. Merget, J. Somorovsky, and J. Schwenk, "Exploring the Unknown DTLS Universe: Analysis of the DTLS Server Ecosystem on the Internet," in *32nd USENIX Security Symposium (USENIX Security 23)*, 2023, pp. 4859-4876.

[27] H. Bertin, "Dos attack demonstration," https://www.dropbox.com/scl/f0/rs8nxb04gpqtz3rfo6buq/AJu5psVpEgoa_eFaIJEY8?rlkey=hmdgfluoyqex2l3oojsqojbc0&st=714bqhvh&dl=0, 2024, dropbox folder, [Accessed 07-04-2025].

[28] E. Games, "Unetconnection::receivedrawpacket," epic Games Dev Community, [Accessed 31-03-2025]. [Online]. Available: https://dev.epicgames.com/documentation/en-us/unreal-engine/API Runtime/Engine/Engine/UNetConnection/ReceivedRawPacket

[29] ——, "Unetconnection::close," epic Games Dev Community, [Accessed 31-03-2025]. [Online]. Available: https://dev.epicgames.com/documentation/en-us/unreal-engine/API Runtime/Engine/Engine/UNetConnection/Close/3

[30] doxygen, "Doxygen," tool homepage, [Accessed 31-03-2025]. [Online]. Available: https://www.doxygen.nl/

[31] F. Ali, "Ip spoofing," *The Internet Protocol Journal*, vol. 10, no. 4, pp. 1-9, 2007.

[32] J. Wu, J. Bi, M. Bagnulo, F. Baker, and C. Vogt, "Source Address Validation Improvement (SAVI) Framework," RFC 7039, Oct. 2013. [Online]. Available: https://www.rfc-editor.org/info/rfc7039

[33] T. Dai and H. Shulman, "Smap: Internet-wide scanning for spoofing," in *Proceedings of the 37th Annual Computer Security Applications Conference*, 2021, pp. 1039-1050.

[34] R. Beverly and S. Bauer, "The spoofer project: inferring the extent of source address filtering on the internet," in *Proceedings of the Steps to Reducing Unwanted Traffic on the Internet on Steps to Reducing Unwanted Traffic on the Internet Workshop*, ser. SRUTI'05. USA: USENIX Association, 2005, p. 8.

[35] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC 2104, Feb. 1997. [Online]. Available: https://www.rfc-editor.org/info/rfc2104