Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Game Engines are the base software that video games are based upon. If you are not a huge gaming studio, you are likely going to use an off-the-shelf game engine, such as Unity or Unreal Engine 4 (open source).

In the multiplayer gaming world, we are trying to increase the performance and move most information to the client side, in order to prevent hacking, such as speed hacks and things. Most of the multiplayer gaming systems having RPC (remote procedure calls) to call functionality on owned objects and are very distributed.

Most multiplayer protocol run over UDP because of performance issues of TCP.

Bug #1 (Unreal): In Unreal, there is a custom URL scheme that is used for accessing specific resources. However, it can be abused to access any local file on the system (but you cannot see it).

By using a UNC Universal Naming Conventions in the URL, it can be used to access a remote SMB share. This typically tends authentication information and can be used to start other attacks.

Bug #2 (Unet Unity): RPC calls have a length and a payload. The length is blindly trusted, allowing for EXTRA memory to be accessed on the server. In order to exfiltrate the memory (heartbleed style), you can use RPC types such as messages, player locations and object spawning to see the data.

Bug #3 (Universal UE4 Speed Hack): UE4 calculates the speed by checking the current timestamp to the previous timestamp to calculate the location, as well as the direction vector (speed). Additionally, this has several validations to ensure that now speed hacks are occurring.

NaN stands for Not A Number. Any math being done with NaN also will output NaN. NaN with all booleans will always output False. The bug occurs in a validation function of the timestamp that will only exit if something returns true. By setting a value to NaN, all operations will return False, resulting in the check to pass!

However, it is not this simple... there is an affirmative action that MUST be true in order to work. So, we must continue on the bug hunt. This NaN value (timestamp) corrupts several values, eventually removing all speed limit hacks in the game! To exploit this bug, send a small timestamp then an extremely large timestamp.

Bug #4: UNET is over UDP, meaning that lots of built-in security mechanisms have to be manually added. Connections have two important fields: Host ID, Packet ID and Session ID. The Host ID is not meant to secret and is sequential. The Session ID is a 16 bit integer (65535) but is always odd, taking down the amount of possible values to 32768 possible IDs with no punishment of brute forcing.

Now, we can brute force the session ID and act as another user! With this, we can trivially end a users session. The next thing we need to do is figure out a valid Packet ID. The documentation says that a too new or too old packet will be discarded, giving you a 7% chance. However, in practice, all old packets are valid (well, there's a rolling packet count though). So, there is a 50% chance that you would be able to hijack somebody's session.

What can we learn from this?

1. NaN bugs are a security thing!
2. Documentation constantly lies to us; do not trust it, try it out yourself.
3. Small amount of possible ID's + no brute force protections = pwn
4. There are a lot of simple bugs out there; all you have to do is look hard :)