- Textextractor bruteforce
- The ‘universal' unity hook(for astronault's games)
Hi everyone, so i just recently installing this one game from Steam. Its called Battle for Blood - Epic battles within 30 seconds!. Just small 75mb game made with unity engine.So I actually try the usual method of increasing money using cheat engine but i could not. At the heart of hacking, there's knowledge: understanding how Unity3D compiles games is essential if you want to hack them.This post will show how resources are compiled into Unity3D, how they can be extracted and (when possible) repacked.
Unity games/novels have a bad reputation of being unable to hook the game's text and needing hook codes that are sometimes not available. Older versions of Unity still used to work fine with VNR and other text hookers but nowadays they simply won't work anymore.
Textextractor has a ‘brute force' mode when it detects a unity game that can kinda work. But its not very intuitive, gets a lot of garbage text together and can virtually crash you PC for a few seconds if you don't properly configure it. I'll cover that here but the main point of this post will the the ‘universal' unity hook at the end(for astronault's games).
Tl;dr:
Textextractor configure game.
Hook code: /HW-4@xxxx .
Get xxx with cheat engine->activate mono features->
CTRL+G->System:Char:IsHighSurrogate
(Might only work for astronaults games)
Textextractor
When you hook textextractor to a unity game it'll use its 'Mono Dynamic' hook bruteforce and hook to all of its known text thread.
While this way works you might get literally thousands of lines spit out every second and slow down and even freeze your PC for a few seconds until its done.
The reason that happens is because a few of those text threads might be used to read binary data or pre-load and split the entire game script lines in the computer memory. While this is just a split second for the computer to process it takes 1000x more time for it to be print out as text and that's why the PC freezes.
To fix this, textextractor has a 'Configure game' button that will let you choose what to ignore and only keep the ones that displays proper text. Each game is different so you'll need to find out yourself which are the right ones. But even the most ideal ones might have some garbage text so while this works its not ideal.
How To Cheat Engine Unity Games
Textextractor: Configure games
After you hook the game, simply press the 'Configure game' and textextractor will create an 'TextractorConfig.txt' file on the same folder as the game and also open it for you.
There will be a link inside with how to use use. But the link leads to a non-existent page that leads to the issue page that kinda explains how it works on a comment. So I'll briefly explain it here.
Start the game and when you get to the first textbox, only then, hook the game. Wait a while for the textextractor and when you click something in the game textextractor will begin its dynamic hook bruteforce.
Now, go to the next text and you'll note there are dozens of text-threads on textextractor. You'll need to go through each one and find one that best represents the text you are see. But even the best ones still have some garbage text.
Warning: There is a very high change of your PC freezing up for a few seconds at the start of a scene on games that pre-load its script and images. It'll go back to normal after it stops spitting out the text but it's better to avoid that.
After you find the right thread you can get its name and put it inside the 'TextractorConfig.txt' config file.
In case you want to add more then one text thread you can separate them with TABS. A little tip, all the available hooks will be shown on textextractor console(the first text thread) when you first hook the game so you can just copy them from there to avoid typing errors.
e.g: 'Textractor: inserting hook: string:IndexOf (string,System.StringComparison)'
So the configure file would be 'string:IndexOf (string,System.StringComparison) '
After you save the configure file you can close textextractor. The next time you hook the game it'll only load the hook you saved so this process only needs to be done one time.
‘Universal' Unity hook
This is a way a just found out and so far it worked perfectly for any of the games made by astronaults(https://vndb.org/p2692) which are now all made with Unity. It can properly hook all text and even the items/skills descriptions so playing them should be easier.
The big downside is that you need to do this everytime you start the game because the hookcode is dynamic and changes everytime you start the game.
First you'll need to have cheat engine. Any version should work but for reference I've tried with 6.8.3 and 7.0.
Start the game and cheatengine. On cheat engine click File->Open Process (or the button) and then select the game process and open it.
After connecting with the game click on the menu Mono and Activate Mono Features then click on the button 'Memory view' to open a new window.
On this new window press CTRL+G and search for 'System:Char:IsHighSurrogate'
After you press OK it'll lead you to that address. Now press CTRL+G again and copy the number already in the box.
The resulting hook code will be /HW-4@xxxxxxxxxxxxx with 'xxxx' being the number you get in that box. In this case mine was '132C9238'.
So my hookcode was /HW-4@132C9238.
You can now use this hook on textextractor. Just make sure to put some random text on the configure file so textextractor will not bruteforce it anymore.
And it should work perfectly without any garbage for any text displayed.
This needs to be done every time the game is started.
It only takes a few seconds after you memorize it but unfortunately you need to do it every time.
Note: This hookcode will apparently only work on textextractor on older versions of ITH(2.3<). I don't know why or if its true but that's what was written on the original text.
Original japanese comment text for reference:
/HW-4@
※には、以下の手順で得られるアドレスを入力します。 なお、このHコードはTextractorと旧バージョンのITH（ITH 2.3など）のみがを対応しており、AGTH、ITH 3.0以降、ITHVNR及びVNRでは機能しません。また、ゲームが32bit版でなければ、対応できないため、例えば64bit版のアップデートパッチをあてると、アドレスを見つけられません。
①ゲームを起動 ②Cheat Engineで【File】タブ→【Open Process】 ③ゲームを選択し、【Open】を押下。 ④【Mono】タブから【Activate mono features】を選択。 ⑤【Memory viwe】ボタンを押し、「ctrl + G」を押下 ⑥入力欄に「System:Char:IsHighSurrogate」と入力し、【OK】 ⑦再度、「ctrl + G」を押下し、入力欄のアドレスを上記のH-codeの「」部分に入力する。
What you will get from this page: Tips on maintaining a stable and flexible build to save yourself time and money. Get pointers on using version control, utilizing your changelists, clean cheat functionality, bug tracking and more
C# Unity Cheat Sheet
After years of shipping large titles with even larger teams, typical AAA studios know how to keep their productions on track and maintain a clean and stable build. Sascha Gundlach, from MetalPop Games, highlights how independent game developers can adapt the AAA approach to their own production.
With a clean build, it's easy to change or add things, as well as maintain and debug features. Overall, you'll be able to develop your game faster and more efficiently.
Maintain a clean and stable game build and you'll reap the benefits in the long run:
- Release more stable games with fewer bugs.
- Save production time, due to fewer bugs and a cleaner codebase.
- Lower your chance of ‘breaking the build'.
- Create demo versions and special builds easier.
Not all AAA build practices are suitable for indie teams. But there are a lot of things you can do to make sure your build stays clean and stable that are free (or affordable) and can be implemented by teams of any size.
Even if you are a one-person operation, these tips will help you to maintain a better, more healthy build of your game.
How To Use Cheat Engine With Unity Games
Even today, with the availability of free version control systems (VCS), there are still teams out there working with shared folders or dropboxes to collaborate. Developing without version control is a bit like driving without a seat belt. Wearing a seat belt might not always be comfortable and will restrict you a bit, but once you crash full speed into that tree, it will save your life.
You can't afford to lose work no matter the size of your team. A hacked dropbox account or a broken hard disk should not cause you to lose days or weeks of work.
There are plenty of free solutions out there. Perforce, Git and SVN all offer free versions. And, with Unity Teams built into Unity directly, things become even easier.
Utilize your changelists
In addition to the safety a VCS provides, another benefit is that you will get changelists, which will help you to keep an overview of the changes done. The image above is of a Perforce folder history showing all changes.
Although most systems don't force you to submit a description for a change you did, it's good practice to describe the changes clearly.
In addition, creating ‘patch notes' and similar documents becomes easy when you start using prefixes for your changes, such as these:
- !B: A bug fix.
- !V: A visual change or improvement.
- !G: A gameplay change.
- !X: A change that should be ignored in the patch notes.
When you submit changes to your VCS and describe them with leading prefixes, you can run a script later over every entry and sort everything into a nice and clean patch notes document.
A clean submission to your VCS would look like this:
'!V Made explosion particle effect bigger'
'!B Fixed crash when picking up a weapon'
'!G Increased amount of health in med-kits'
If you keep all your check-ins clean and well described, it's easy to compile patch notes documents when you need them. It's a more efficient approach than manually going through your recent changes to identify things that should be listed in your patch-notes.
Practice good hygiene
It's important that everybody on your team is familiar with the basics of good build hygiene. Here are the top five best practices to keep it clean.
- No build-breaking code
Don't check in anything that you know is broken. If the feature you are working on is not finished but you need to check it in, either disable it or shelve your changes so they don't break anything for the rest of the team. The rest of your team should not be blocked by a broken build because you checked in non-working code. - No hard-coded keyboard shortcuts
It's convenient to add custom shortcuts for certain cheat or debugging functionality. 'Just make the the F12 key the money cheat key, no one is going to press that anyway, right?'
But hardcoding functionality like this to a key is dangerous because it's easy to forget. You might end up shipping it accidentally, or your testers might be unintentionally activating it and polluting your bug reports this way. - Mark bad and missing code
Sometimes you have to hack. No matter how much you would like to avoid it, you will at some point have temporary hacks in your code. When you are adding a hack or workaround make sure to mark them in the code with easy to find keywords. Mark a hack with //HACK or missing code with //TODO. This makes it easy later on to search through all your code for those tags and find and replace them. - Log spam
Logging things in your code is useful and can help you track down problems. However, it's important to clean up the log spam now and then so that important warnings and errors don't get buried. Unless you are actively working on a feature, your console should be as clean and empty as possible, so that if something pops up, you see it right away. - File names and naming conventions
The size of your build will eventually grow to hundreds or possibly thousands of files. So it's important to keep a clean naming convention.
When you start a new project take the time to come up with naming conventions that make sense for you, and force yourself to stick to them. Once you have names such as texturetestFinal01.png or backup22.fbx in your build, things will get messy fast.
Do routine checks and clean up any dirty file names which made it into the project.
Here are a few quick tips:
- Use descriptive names
AttackButtonBehavior.cs instead of atkBtn.cs - Use camelCase or PascalCase
notsocleanfilename.cs isn't as readable as MyCleanFilename.cs - Use underscores to make things in filenames more clear.
WoodenHouse_Blue, WoodenHouse_Green, etc.
Keep cheat functionality clean
You will constantly need to debug and cheat when developing your game. You might want to jump to a different level, give yourself extra cash, make yourself invulnerable, spawn extra enemies, etc.
You could add those cheats wherever you need them and disable them after you are done but it's preferable to have a clean way to switch this kind of cheat functionality on and off.
Even for smaller projects, it's worth investing the extra time to build an easy to use debug/cheat menu. Something that can easily be turned on and off by your developers and provides access to all the usual cheat and debug options.
Doing it this way minimizes the risk of accidentally shipping cheats with your game. In addition, having your ‘cheat code' in one central place also makes sure everything works and is easy to extend.
Another benefit of this approach is that dev-cheating becomes much faster, saving you time in everyday production. Just pressing a button in your nice and comfortable debug window is a lot quicker than hard-coding values in your scripts.
Manage and track bugs
Your game will have bugs. Every game has bugs and your game will not be an exception. The question is, how do you deal with bugs.
The workflow to efficiently handle bugs is pretty straight forward: your QA department finds and enters bugs in your bug tracking system. Then they assign the issues to your developers, who in turn fix the issues and mark them as such. Finally your QA team verifies the issues and marks them as closed. An easy three-step process, right?
Wait, what? You don't have a dedicated QA department? Your testers are also your developers?
Don't worry, because you don't need much to stay on top of your bugs.
First of all, track your bugs. This is easy even if you are a one-person team.
Note: This hookcode will apparently only work on textextractor on older versions of ITH(2.3<). I don't know why or if its true but that's what was written on the original text.
Original japanese comment text for reference:
/HW-4@
※には、以下の手順で得られるアドレスを入力します。 なお、このHコードはTextractorと旧バージョンのITH（ITH 2.3など）のみがを対応しており、AGTH、ITH 3.0以降、ITHVNR及びVNRでは機能しません。また、ゲームが32bit版でなければ、対応できないため、例えば64bit版のアップデートパッチをあてると、アドレスを見つけられません。
①ゲームを起動 ②Cheat Engineで【File】タブ→【Open Process】 ③ゲームを選択し、【Open】を押下。 ④【Mono】タブから【Activate mono features】を選択。 ⑤【Memory viwe】ボタンを押し、「ctrl + G」を押下 ⑥入力欄に「System:Char:IsHighSurrogate」と入力し、【OK】 ⑦再度、「ctrl + G」を押下し、入力欄のアドレスを上記のH-codeの「」部分に入力する。
What you will get from this page: Tips on maintaining a stable and flexible build to save yourself time and money. Get pointers on using version control, utilizing your changelists, clean cheat functionality, bug tracking and more
C# Unity Cheat Sheet
After years of shipping large titles with even larger teams, typical AAA studios know how to keep their productions on track and maintain a clean and stable build. Sascha Gundlach, from MetalPop Games, highlights how independent game developers can adapt the AAA approach to their own production.
With a clean build, it's easy to change or add things, as well as maintain and debug features. Overall, you'll be able to develop your game faster and more efficiently.
Maintain a clean and stable game build and you'll reap the benefits in the long run:
- Release more stable games with fewer bugs.
- Save production time, due to fewer bugs and a cleaner codebase.
- Lower your chance of ‘breaking the build'.
- Create demo versions and special builds easier.
Not all AAA build practices are suitable for indie teams. But there are a lot of things you can do to make sure your build stays clean and stable that are free (or affordable) and can be implemented by teams of any size.
Even if you are a one-person operation, these tips will help you to maintain a better, more healthy build of your game.
How To Use Cheat Engine With Unity Games
Even today, with the availability of free version control systems (VCS), there are still teams out there working with shared folders or dropboxes to collaborate. Developing without version control is a bit like driving without a seat belt. Wearing a seat belt might not always be comfortable and will restrict you a bit, but once you crash full speed into that tree, it will save your life.
You can't afford to lose work no matter the size of your team. A hacked dropbox account or a broken hard disk should not cause you to lose days or weeks of work.
There are plenty of free solutions out there. Perforce, Git and SVN all offer free versions. And, with Unity Teams built into Unity directly, things become even easier.
Utilize your changelists
In addition to the safety a VCS provides, another benefit is that you will get changelists, which will help you to keep an overview of the changes done. The image above is of a Perforce folder history showing all changes.
Although most systems don't force you to submit a description for a change you did, it's good practice to describe the changes clearly.
In addition, creating ‘patch notes' and similar documents becomes easy when you start using prefixes for your changes, such as these:
- !B: A bug fix.
- !V: A visual change or improvement.
- !G: A gameplay change.
- !X: A change that should be ignored in the patch notes.
When you submit changes to your VCS and describe them with leading prefixes, you can run a script later over every entry and sort everything into a nice and clean patch notes document.
A clean submission to your VCS would look like this:
'!V Made explosion particle effect bigger'
'!B Fixed crash when picking up a weapon'
'!G Increased amount of health in med-kits'
If you keep all your check-ins clean and well described, it's easy to compile patch notes documents when you need them. It's a more efficient approach than manually going through your recent changes to identify things that should be listed in your patch-notes.
Practice good hygiene
It's important that everybody on your team is familiar with the basics of good build hygiene. Here are the top five best practices to keep it clean.
- No build-breaking code
Don't check in anything that you know is broken. If the feature you are working on is not finished but you need to check it in, either disable it or shelve your changes so they don't break anything for the rest of the team. The rest of your team should not be blocked by a broken build because you checked in non-working code. - No hard-coded keyboard shortcuts
It's convenient to add custom shortcuts for certain cheat or debugging functionality. 'Just make the the F12 key the money cheat key, no one is going to press that anyway, right?'
But hardcoding functionality like this to a key is dangerous because it's easy to forget. You might end up shipping it accidentally, or your testers might be unintentionally activating it and polluting your bug reports this way. - Mark bad and missing code
Sometimes you have to hack. No matter how much you would like to avoid it, you will at some point have temporary hacks in your code. When you are adding a hack or workaround make sure to mark them in the code with easy to find keywords. Mark a hack with //HACK or missing code with //TODO. This makes it easy later on to search through all your code for those tags and find and replace them. - Log spam
Logging things in your code is useful and can help you track down problems. However, it's important to clean up the log spam now and then so that important warnings and errors don't get buried. Unless you are actively working on a feature, your console should be as clean and empty as possible, so that if something pops up, you see it right away. - File names and naming conventions
The size of your build will eventually grow to hundreds or possibly thousands of files. So it's important to keep a clean naming convention.
When you start a new project take the time to come up with naming conventions that make sense for you, and force yourself to stick to them. Once you have names such as texturetestFinal01.png or backup22.fbx in your build, things will get messy fast.
Do routine checks and clean up any dirty file names which made it into the project.
Here are a few quick tips:
- Use descriptive names
AttackButtonBehavior.cs instead of atkBtn.cs - Use camelCase or PascalCase
notsocleanfilename.cs isn't as readable as MyCleanFilename.cs - Use underscores to make things in filenames more clear.
WoodenHouse_Blue, WoodenHouse_Green, etc.
Keep cheat functionality clean
You will constantly need to debug and cheat when developing your game. You might want to jump to a different level, give yourself extra cash, make yourself invulnerable, spawn extra enemies, etc.
You could add those cheats wherever you need them and disable them after you are done but it's preferable to have a clean way to switch this kind of cheat functionality on and off.
Even for smaller projects, it's worth investing the extra time to build an easy to use debug/cheat menu. Something that can easily be turned on and off by your developers and provides access to all the usual cheat and debug options.
Doing it this way minimizes the risk of accidentally shipping cheats with your game. In addition, having your ‘cheat code' in one central place also makes sure everything works and is easy to extend.
Another benefit of this approach is that dev-cheating becomes much faster, saving you time in everyday production. Just pressing a button in your nice and comfortable debug window is a lot quicker than hard-coding values in your scripts.
Manage and track bugs
Your game will have bugs. Every game has bugs and your game will not be an exception. The question is, how do you deal with bugs.
The workflow to efficiently handle bugs is pretty straight forward: your QA department finds and enters bugs in your bug tracking system. Then they assign the issues to your developers, who in turn fix the issues and mark them as such. Finally your QA team verifies the issues and marks them as closed. An easy three-step process, right?
Wait, what? You don't have a dedicated QA department? Your testers are also your developers?
Don't worry, because you don't need much to stay on top of your bugs.
First of all, track your bugs. This is easy even if you are a one-person team.
Pick a bug tracking software (there is a plethora of free and affordable ones out there) and set it up. If this sounds like overkill to you, go ahead and just use Excel or the even the notepad on your desk, it doesn't really matter. What's important, is that you have one central spot to collect and track problems. Once you have a system in place to track your issues, it's all about discipline. A buggy build slows down production speed and can even create more new issues.
Here a few quick tips to stay on top of your bugs:
Bug-Fix-Fridays
Bug-Fix-Fridays are a great way to keep your build bug free. Every Friday, instead of working on new features everybody works on items from the bug list only. This approach ensures you start the new week with a bug-free, stable build.
Don't put it off for too long
If you know your bugs are getting out of hand it might be a good idea to stop working on new features and focus on stabilizing the build until things are back on track.
Don't fight fires all the time
If you have a lot of bugs that reappear, investigate the root cause. Is a certain part of your level building pipeline always causing levels to break? Is the way you parse your gameplay values from your .xml files breaking down every other day?
If you identify a system that is constantly causing problems it might be worth the time to rebuild it instead of repeatedly fixing the issues it causes.
With all these best practices and tips in mind, it all comes down to discipline and how much attention you pay to the state of your build. You can mix and match these suggestions and apply them to your indie production. The time you use on keeping your build in good shape is always worth it.
Unity Cheat Sheet
How To Cheat On Unity Games
