How to hack unity games

Hacking into Unity games

With the rising popularity of game streaming platforms like Twitch that allow developers to build extensions to boost fan engagement, knowing how to hack into games to get data to feed those extensions is a skill that many developers want to learn.

In this article I’m going to explain how to hack into the memory space of a Unity game process running under Windows. This memory often contains a lot of interesting and hidden information about that game that could be used, for example, to build a Twitch extension.

You can find the code that goes with this article here: https://github.com/hackf5/unityspy.

The key ideas have been borrowed from HearthMirror, which is part of the excellent Hearthstone Deck Tracker.

The author has no affiliation with HearthSim, HearthMirror or Hearthstone Deck Tracker, but is a fan of their work.

Legal Stuff

HearthMirror is copyright and released open source under a proprietary license. Copyright protects the expression of an idea, not the idea itself. Ideas are protected by patent.

This post has a good description of the protections afforded by copyright. In particular copyright probably makes it illegal to reference the HearthMirror library in your own project, or to copy code from the HearthMirror project. But, as the source is legally available, it is legal to understand the ideas in the source and to replicate them.

What’s Unity?

Unity is the world’s most popular game engine. If you’ve ever tried building a game, the chances are that you tried to build it in Unity. In fact it’s so popular that something like half of all games that are built are built on Unity.

There are many reasons for this popularity, but a significant one is Unity’s outstanding cross platform support. It achieves this on a number of platforms, including Windows, using a library called Mono.

If you want to find out how to get started building games with Unity I can thoroughly recommend Brackeys YouTube channel, which has lots of great Unity tutorials.

What’s Mono?

Mono in Unity

Most of the Unity game engine is written in C++, but game developers write their code in C#. On platforms that are well supported by Mono, such as Windows and Mac, this C# code runs under Mono, on other platforms, such as iOS, Unity uses a transpilation process called IL2CPP (Intermediate Language To C Plus Plus) that converts C# into C++. IL2CPP is more restrictive than Mono, but it has better cross platform support. And where Unity runs under Mono, it in fact uses its own fork.

This post provides an interesting discussion of the internal workings of the Unity game engine and its possible future directions.

With the preamble out of the way it’s time to get into the technical details.

The Goal

The goal is to gain access to and understand the contents of the memory running under Mono in a Unity game on Windows.

Since all of the game logic runs under Mono, then this memory contains everything useful about the game, so this isn’t any real restriction.

You can find the code that goes with this article here: https://github.com/hackf5/unityspy.

The core library must be run from a 32-bit process.

The Plan

To save a few bytes in the cloud I’m going to use the word process to interchangeably mean the Unity game process and the memory that the operating system has allocated to that process.

This approach works because the Types directly reference their static fields, and game state is often held in a statically rooted data model. So by finding the static objects, looking at their fields, then looking at the fields of those fields and so on, it is possible to build up a picture of the current game state.

Reference the Unity game process

The core library takes a process ID. See the ProcessFacade class.

The GUI app gets all running processes, to allow the user to choose the process that they want to inspect. It then passes the ID of this process into the core library. See the MainViewModel class.

Find the root AppDomain

The root AppDomain location

What I want to do is call mono_get_root_domain to find the location of the root AppDomain in the process, but there is no way to call a function inside another process, so normally this wouldn’t be of much use. However, I can try to disassemble the mono.dll library to see what the function looks like.

If you open up Snowman, disassemble Unity’s mono.dll library and look for the mono_get_root_domain function you will see it is defined as

Yuck! But it isn’t actually quite as bad as it first looks. In fact the assembly code is more helpful. What the assembly tells us is that the function call starts at address 10027c32 and at this address is an instruction to move the constant 4 byte value 0x101f62cc onto the EAX register. See the assembly mov instruction for more details.

For a specific mono.dll this value will be constant, but the constant is calculated by the compiler at compile time, so if I hard-coded the value 0x101f62cc from a specific version of the mono.dll, then the core library would only be able to inspect Unity games that referenced that specific version of the mono.dll library. That means I need to find the definition of the mono_get_root_domain function at runtime and read the AppDomain address out of it.

Read the mono.dll from the Unity game process

Having got hold of the mono.dll module, I need to use some native code to dump it into a byte array.

All of the hard work is done by the ReadProcessMemory function that is defined in the Windows operating system library kernel32. The mono.dll Module tells me it starts at monoModule.BaseAddress in the process’ memory and it consists of monoModule.ModuleMemorySize bytes. So all I need to do is use ReadProcessMemory to read that chunk of the Unity game process’ memory into a byte array of the same size as the module.

Now the variable moduleDump contains the contents of the mono.dll module.

Find the mono_get_root_domain function

All Windows DLLs start with a standard header that describes, amongst other things, the location of each function in the DLL. The header conforms to the PE Format specification.

If you’ve worked with raw byte arrays before, then you’ll know what’s coming. If not you might be in for a shock, as it involves navigating to specific locations in the array and interpreting the bytes that you find there as some known type, usually something like an integer or a string.

In this case the PE Format specification describes how to find the location of the mono_get_root_domain function.

Since I only needed a little bit of information from the PE header and the PeNet library needed modifying, I decided that the best way to go was to copy the offsets from the HearthMirror project and to read the data from the module dump directly as they’ve done.

In summary, the code above enumerates the list of functions declared in the module’s PE header and when it finds one called mono_get_root_domain sets rootDomainFunctionAddress to be equal to the address of this function.

So I’ve found the address of the root AppDomain, it’s located at address rootDomainFunctionAddress + 1 in the Unity game process’ memory.

Read the AppDomain

Since the Unity game process is 32-bit, the size of a pointer is the size of a 32-bit integer. There are 8 bits in a byte, so in 32 bits there are 4 bytes, so the size of a pointer is 4.

I’m cheating here though, because I’m just copying someone else’s hard work. So how could the HearthMirror devs have worked out that the offset is 112?

The best candidate for this is in my opinion is the friendly_name field. This field is located two pointers, or 8 bytes, away from our target field. So if I can work out the offset of friendly_name then I can work out the offset of the domain_assemblies field that I’m interested in.

The friendly_name field is a good candidate because it’s a C-style string that probably contains some recognisable value. To find this field I can start at an offset of 92 bytes (two pointers on from the minimum offset of the domain_assemblies field) and try reading the C-style string I find at each position.

There are a number of ways of doing this. I could write a bit of C# code to scan through each candidate in a running Unity game’s memory, or I could use a hex editor capable of reading directly from a process’ memory. I decided to use the excellent and free HxD Hex Editor and do it by hand.

Using this I was able to find that friendly_name has value Unity Root Domain and with it the offset of the friendly_name field from the start of the _MonoDomain object. What I was looking for was a string that wasn’t junk.

With this I’ve legitimately found the offset of the domain_assemblies field and can go on to look for the main Unity game logic Assembly called Assembly-CSharp.

Find the Assembly-CSharp main game logic Assembly

To find this Assembly I need to enumerate over the collection of _MonoAssembly objects contained in the domain_assemblies singly linked list until I find an Assembly called Assembly-CSharp.

This is easier than finding the domain_assemblies offset as the singly linked list can be enumerated by following the pointer at a 4 byte offset from the start of each item in the list. The first 4 bytes of each item is a pointer to the _MonoAssembly referenced by the element.

Find the Types referenced by the main game logic Assembly

I’m going to be completely honest here, I’m not even going to guess how the HearthMirror devs found the offset of the class_cache field.

Another possible alternative is to compile the Mono library from source and then to write a small C program that uses the offsetof macro to calculate the offsets of the fields that you’re interested in. With a little big of messing around this isn’t too difficult to do.

I compiled and ran the following code in Visual Studio.

It would be nice if this worked, but the offset of domain_assemblies field doesn’t match the value I found earlier, so it clearly doesn’t work. There are two problems here:

Different compilers can pack types differently, so even if I had the right source code my compiler could return a different offset. And of course if my source code is different from the DLL that Unity ships I could be comparing oranges with apples. So unless you have the exact compiler and source, this strategy is unlikely to work. The correct class_cache offset is actually 672, which is way off the value that I found using the compiler.

Without a dissasembler you are going to need to do reverse engineer the address from the process’ memory directly.

If I was going to do this then I would start by scanning the whole process memory for class names that I knew were declared in the Assembly-CSharp Assembly. Once I’d found these, then I would assume that they were part of a _MonoClass object and with enough of them I would hope to work my way back to the class_cache by looking for the addresses of those _MonoClass objects. It’s probably doable, but it isn’t straightforward.

Having found the class_cache then extracting the type information is more of the same. Work out which fields you need from the objects you’re interested in, work out their offsets and read them.

See AssemblyImage to see how the Type information is found.

See TypeDefinition to see how the Type information is read.

Again all of the hard work has been done by the HearthMirror devs.

Read the process’ game state

At this stage things get easier because the _MonoClass objects describe their fields along with their offsets, so you can read the offsets of the managed object fields directly, without needing to work them out.

Once you have the Type information it’s simply a matter of finding the static fields that hold useful information and then using the field offsets to read this information.

See TypeDefinition.GetStaticValue(…) to see how object data is read.

Trying it out

You can see this in action for yourself by:

If you do this you’ll be able to browse the Hearthstone game data. For example you’ll be able to get a list of all of the cards that you own.

If you enjoyed this article and want to see more like it please give it a clap and leave a comment.

Практическое руководство по взлому (и защите) игр на Unity

Когда речь идёт о программном обеспечении, термин «взлом» зачастую ассоциируют с пиратством и нарушением авторских прав. Данная статья не об этом; напротив, я решительно не одобряю любые действия, которые прямо или косвенно могут навредить другим разработчикам. Тем не менее, эта статья всё же является практическим руководством по взлому. Используя инструменты и методы о которых далее пойдёт речь, вы сможете проверить защиту собственной Unity игры и узнаете, как обезопасить её от взлома и кражи ресурсов.

Введение

В основе взлома лежит знание: необходимо понимать особенности компиляции Unity-проекта, чтобы его взломать. Прочитав статью, вы узнаете, каким образом Unity компилирует ресурсы игры и как извлечь из них исходные материалы: текстуры, шейдеры, 3D-модели и скрипты. Эти навыки будут полезны не только для анализа безопасности проекта, но также для его продвинутой отладки. В связи с закрытостью исходного кода, Unity часто работает как «черный ящик» и порой единственный способ понять, что именно в нём происходит — это изучение скомпилированной версии скриптов. Кроме прочего, декомпиляция чужой игры может стать серьёзным подспорьем в поиске её секретов и «пасхальных яиц». Например, именно таким образом было найдено решение финальной головоломки в игре FEZ.

Находим ресурсы игры

Рассмотрим для примера игру, собранную под ОС Windows и загруженную через Steam. Чтобы добраться до директории, в которой находятся нужные нам ресурсы, откроем окно свойств игры в библиотеке Steam и в закладке «Local files» нажмём «Browse local files…».

Извлекаем текстуры и шейдеры

Графический интерфейс программы не отличается удобством, а также она страдает от нескольких критических багов. Не взирая на это, программа вполне способна извлечь большинство текстур и шейдеров из игры. Полученные в результате текстуры будут иметь формат DDS, который можно «прочитать» с помощью Windows Texture Viewer.

С шейдерами ситуация обстоит сложнее: они извлекаются в уже скомпилированным виде и, насколько мне известно, решений для их автоматической трансляции в удобочитаемый формат не существует. Тем не менее, это обстоятельство не мешает импортировать и использовать полученные шейдеры в другом Unity-проекте. Не забывайте, однако, что подобная «кража» нарушает авторские права и является актом пиратства.

Извлекаем 3D-модели

Трёхмерные модели в типовой Unity-сборке «разбросаны» по различным ресурсам, а некоторые из них и вовсе могут генерироваться во время игры. Вместо копания в файлах, существует интересная альтернатива — получить данные о геометрии прямиком из памяти графического ускорителя. Когда игра запущена, вся информация о текстурах и моделях, видимых на экране, находится в памяти видеокарты. С помощью утилиты 3D Ripper DX можно извлечь всю эту информацию и сохранить в формате, понятном 3D-редакторам (например, 3D Studio Max). Учтите, что программа не самая простая в обращении — возможно, придётся обратиться к документации.

Взламываем PlayerPrefs

Защищаем PlayerPrefs

Помешать пользователю редактировать значения в системном реестре мы не в силах. А вот проверить, изменялись ли эти значения без нашего ведома — вполне реально. В этом нам помогут хеш-функции: сравнив контрольные суммы хранимых данных, мы сможем убедиться, что никто и ничто, кроме нашего кода эти данные не изменяло.

Приведенный выше класс — упрощенный пример реализации, работающий со строковыми переменными. Для инициализации ему необходимо передать секретный ключ и список PlayerPrefs-ключей, значения которых должны быть защищены:

Затем его можно использовать следующим образом:

Взламываем исходный код

Данных подход особенно эффективен для наших целей: Unity очень скупо оптимизирует исходный код игровых скриптов, практически не изменяя его структуру, а также не скрывает названия переменных. Это позволяет с легкостью читать и понимать декомпилированый материал.

Защищаем исходный код

Раз Unity не заботится о сохранности нашего кода — сделаем это сами. Благо, существует утилита, готовая автоматически зашифровать плоды нашего интеллектуального труда: Unity 3D Obfuscator.

И хотя программа отлично справляется со своими обязанностями, многие классы, адресуемые извне родной библиотеки, всё же не могут быть зашифрованы без риска нарушения связанности — будьте осторожны!

Взламываем память игры

Cheat Engine — широко известная программа для взлома игр. Она находит ту область оперативной памяти, которая принадлежит процессу запущенной игры и позволяет произвольно её изменять.

Эта программа пользуется тем фактом, что разработчики игр очень редко защищают значения переменных. Рассмотрим следующий пример: в некой игре у нас есть 100 патронов; используя Cheat Engine, можно выполнить поиск участков памяти, которые хранят значение «100». Затем мы делаем выстрел — запас патронов составляет 99 единиц. Снова сканируем память, но теперь ищем значение «99». После нескольких подобных итераций можно с легкостью обнаружить расположение большинства переменных игры и произвольно их изменять.

Защищаем память игры

Использовать нашу новую структуру можно следующим образом:

Если вы выводите значения переменных на экран, хакеры всё ещё смогут перехватить и поменять их, но это не повлияет на действительные значения, хранящиеся в памяти и использующиеся в логике игры.

Заключение

К сожалению, существует не так уж много способов защитить игру от взлома. Будучи установленной на пользовательское устройство, она фактически раскрывает все ваши текстуры, модели и исходный код. Если кто-то захочет декомпилировать игру и украсть ресурсы — это лишь вопрос времени.

Невзирая на это, существуют действенные методы, которые позволят серьёзно усложнить жизнь злоумышленникам. Это не значит, что нужно вдаваться в панику, шифровать весь исходный код и защищать каждую переменную, но по крайней мере задумайтесь, какие ресурсы вашего проекта действительно важны и что вы можете сделать для их защиты.

imadr/Unity-game-hacking

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

Unity Game Hacking Guide

This is a small guide for extracting and modifying assets or code from games made with the Unity engine. Feel free to contribute.

Unity game folder structure

With * : The name of the main executable (.exe).

Extracting and editing code

C# and UnityScript files are compiled into the Assembly-CSharp.dll and Assembly-UnityScript.dll DLLs respectively, which can be found inside the Managed folder.

DLLs can be decompiled using ILSpy, dnSpy, DotPeek or JustAssembly which allow modifying and recompiling assembly files.

If DLLs are missing from the managed directory, try dumping them using MegaDumper tool.

Do not use UnityEX, it is most likely a virus.

The DDS files can be opened/converted/edited with the following tools :

Cheat engine have a feature called Dissect mono that can help hacking game’s memory. This video series about using cheat engine is really useful.

morgandusty/Unity-game-hacking-russian-guide

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

Это небольшое руководство по извлечению и изменению ресурсов или кода из игр, созданных с помощью движка Unity. Не стесняйтесь вносить свой вклад.

Структура папок игры Unity

* : имя было выбрано при компиляциии

Извлечение и редактирование кода

Файлы C # и UnityScript компилируются в библиотеки DLL Assembly-CSharp.dll и Assembly-UnityScript.dll соответственно, которые находятся в папке Managed.

DLL можно декомпилировать с помощью ILSpy или dnSpy которые позволяют изменять и перекомпилировать файлы сборки.

Если библиотеки DLL отсутствуют в управляемом каталоге, попробуйте сбросить их с помощью этого инструмента MegaDumper

В DDS файлы могут быть открыты / перекодировано / отредактирован с этим gimp plugin или с этим photoshop plugin.

Другой способ извлечения сеток и текстур :

Используйте 3D Ripper DX (не поддерживает 64-битные двоичные файлы) или Ninja Ripper.

У cheat-engine есть функция Dissect mono которая может помочь взломать память игры. Это видео video series об использовании чит-движка действительно полезно.

G-Bo ッ

Administrator

A new tutorial for you guys.

Today I’ll show you how to hack unity games.

The file you will hack of a unity game is here: apk-assets-bin-Data-Managed-Assembly-CSharp.dll

What do we need?

NOTE: Not any game is a unity game.

You find this file after you did unzip the apk in: assets-bin-Data-Managed-HERE

I always remove all the other files on the left side using the «Delete/Del» button on your keyboard because they’re anoying as f*ck.

Once they’re gone, open the file from the game in the program.

Let’s set up reflixil now. You’ve downloaded the reflexil file, you should’ve unzipped it.

In reflector you see a option called «Tools«, go to it, go to «Add-Ins» and now click on the «+» icon.

Locate to your unzipped folder, and select «Reflexil.Reflector.AIO«. Now go again to «Tools» and select Reflexil v2.0

It will look like this now:

Now click the search button or «f3» button & now you have to turn on «Search Member» CTL + M OR:

Okey, Let’s search for some functions. There are multiply options of coure, but I’ll call some here:

So, Subway Surfers does have allot features which can be hacked.

Let’s hack the coins, keys, boards & characters in this tutorial

coins & keys are int value’s & board & characters are boolean value’s

Let’s search for ‘coins’. I got ALLOT matches so do you, I will not show you a screenshot.

Let’s search for ‘get_coins’. You got only a few matches, normaly when you find this match in a game you will hack it. I did it too, but it didn’t had any effect so I won’t waste your time by doing it.

Let’s search for ‘get_amountof’. We got this:

It seems very intresting to me, why? Well we got matches with keys & coins + the declaring type is ‘PlayerInfo’ in my opinion that’s intresting.

Let’s double click ‘get_amountOfCoins’ we got this:

Well, ALWAYS delete this OpCode ‘Idfld’. You don’t want that one loaded.

Now, change Idarg.0 to ‘idc.i4’ by clicking right mouse button on Idarg.0 and click edit.

It will look like this:

NOTE: Change Operand type to Int32.

Click ‘Update’ and do the same for ‘get_amountOfKeys’

Now let’s unlock the hoverboards.

Search for: isUnlocked, no match you’ll see. Search for isHoverboardUnlocked

You got 2 matches, which one will you take? Well the one with declaring type ‘HoverboardStickerManager’ says this:

See this: ‘It says: return PlayerInfo.Instance.isHoverboardUnlocked(type);’

Double click isHoverboardUnlocked because it says that’s what it returns.

WOW! You got ALLOT bullsh*t around there

What do we want to do with the function? Return it to TRUE ofcourse!

What do we do now? In this menu (see picture) we have to keep only 2 instructions, it doesn’t matter which one. Just delete everything until you keep 2 instructions

After deleting until there are 2 instructions, it will look like this (you may have other instructions):

I got this, you can get totally something else. I’ll explain you what this means anyways because we both need those instructions to hack it

See the OpCode of both

So it says: HoverboardUnlocked = FALSE = TRUE. hmmmm bleghhhh

Change the first instructions (Idc.i4.0) to Idc.i4.1 this means TRUE

IF your second instruction is NOT ‘ret’ then change it to ‘ret’.

What it says now: HoverboardUnlocked = TRUE = TRUE

Let’s do the same for the Characters..

Search for ‘isCharacterUnlocked’ you may get more matches.I do only get one.

It tells me it does return ‘PlayerInfo.Instance.IsCollectionCompelete(type);

Double Click isCollectionComplete.

Delete all instructions until you keep 2 over

Change the first instruction to ‘Idc.i4.1’ and change the second to ‘ret’ (RETURN)

TIP: The Subway Surfers Tutorial is very anoying in my opinion.

Search for: get_IsTutorialCompleted and return it to true like you did with the Hoverboards & Characters!

Okey.. we’re done. Save the Assembly-CSharp.dll

It will ask if you want to overwrite, click yes.

When you found it, click ‘Sign The File’ and wait.

After it’s done signing, locate it in your file manager & install it. Open it when it’s done

NOTE: If you don’t like non serious people, skip the upcomming screenshot and go to one after it lol..