Anti-Cheat Toolkit: stop cheaters easily!

Very nice and very cheap! I will buy it! I do have a few questions though...

1) Are you planning to keep this on your priority list? I'm asking because your price is actually very low and it made me wonder if you're going to keep supporting this product (from your replies to customers you seem like you will).

2) If you release the full source code won't that make it easier for hackers to cheat your asset?

3) Is there a function like for example ObscuredInt.ConvertToInt(), which returns the ObscuredInt as a regular int? This would be helpfull for sending data to the server that is not Obscured since the server doesn't really need Obscured Variables (server owner won't hack himself).

Thanks for your time,
Darren

 

Hey, Darren!
First of all, thanks for your interest in my plugin!
Here are my answers:
1. Yeah, I'm going to keep supporting it in my spare time.
2. No, actually releasing full sources allows customers to obfuscate whole project which is even better since many public API from ACT can be renamed in such case.
3. You can use ObscuredInt in absolutely usual environment, just like you use usual int variables. Like this:

Code (csharp):

1. // place this line right in the beginning of your .cs file!
2. using CodeStage.AntiCheat.ObscuredTypes;
3.  
4. int totalCoins = 500;
5. ObscuredInt collectedCoins = 100;
6. int coinsLeft = totalCoins - collectedCoins;
7. Debug.Log("Coins collected: " + collectedCoins + ", left: " + coinsLeft);
8. // will print:
9. // Coins collected: 100, left: 400

No need to call any kind of GetValue() method - value will be implicitly converted to regular int and vice versa!

 

hi, Toolkit AntiCheat I used for my project and it is very good, congratulations on your project
I would make the following recommendation to add to your kit:
one might add something like the following in the Start function of each Scene for example, to check if it is running some malware and proceed to close the game

foreach (Process prc in Process.GetProcesses())
{
if (prc.ProcessName.Contains(MyProcessName))
{
//Process is running
//message to the user of malware found
//close game
}
}

Now, do not know if this is for all platforms, but I think it would be interesting to search for network manipulation programs, Cheat Engine, etc

 

Hey, dceevp!

This is already in my todo list for near releases, it won't work in all build targets though (web player and flash player are both sandboxed and won't let us look at processes).
And this method will not work in all cases - cheater may rename process, filename, etc. But it would help in most cases (cheaters rename names in rare cases).
Maybe I'll go further and will compare not only names there, will see

Anyway, thanks for your feedback!

 

Just bought this as a replacement for the unsupported SecuredPlayerPrefs

 

Thanks, Evil-Dog!
Feel free to let me know how it goes for you, especially if something will not work as expected.

 

Hi Dmitriy,

I have a few questions for the mobile platforms Android and iOS:

1. How does LockToDevice work? Do I just set the property PlayerPrefsObscured.LockToDevice = true ? Or Do I need to call ForceLockToDeviceInit?
2. What is your recommendation on how I could identify if the game data is from another device when using LockToDevice?
3. What is your recommendation on how I can detect if the game data has been tampered? One way is by having some value stored in the playerPrefs that I can check, but this value can never change….seems weak

Great library!

Thanks

 

Hey, Moradom!

1. LockToDevice works just like this - you just set it to true or false and any further access to saves (read or write) will be implemented using unique device id or without it.

If you'll set LockToDevice to True, you'll not be able to read any previously saved without LockToDevice data .
And vice versa - if you'll use LockToDevice - you'll not be able to read back this data without LockToDevice, since unique device ID is used in encryption and decryption processes.

ForceLockToDeviceInit is absolutely optional to use. Call it if you wish to init LockToDevice feature on demand (otherwise it will be inited on first set / get call), since it may take noticeable amount of time on some devices to init.

2. In such case these data will just be not readable on your device.

3. Currently there is no such functionality in PlayerPrefsObscured. It is in the middle of my todo list though.
For now you could implement hashing of your sensitive data (that's sort of thing I'm going to add in future).

Thanks for all your questions and interest. Please, let me know if you still have any questions left!

 

Hi Dmitriy,

Thanks for answering my questions, that cleared it up. When do you think you might come out with an update for the functionality you mentioned?

 

Hey again, Moradom!
I'm under heavy load right now, so near update is going to be released at the first half of January or like so, but I'm not sure such functionality will be rolled out with that update. I'll try to!

 

Just bought it -- will toy around with it later, but it sounds like this'll be a huge help for a multiplayer game I'm making for PC

 

Hey, JTown, thanks! Hope it will save you some time!

 

hi why there is no boolean, can't they hack it?

i check by deviceid and ip if person banned by sending www request, and then i set boolean banned to true.

also can they also spoof or block www request and how to protect from that?

 

Hey, friuns3! I did not released ObscuredBoolean yet since it's pretty hard to reveal needed boolean in memory usually - there are lot of them even in empty project. And cheaters usually try to search in memory some visible values like health, speed, scores, etc.. In your case it's almost impossible to find isHackDetected value with memory search tools anyway, since such tools need to make some iterations of searching (to filter other booleans).
And you could use ObscuredUint (to store 0 or 1 there) as boolean replacement if you feel your boolean value is unsecure.

 

Yep, http packets can be sniffed, edited, etc..
You may use ssl (https) to prevent sniffing, and packets editing.

BTW, about one your previous question on encryption key storage - it's much more safier to store it in some exposed to the editor variable. It's easy to find your key in IL bytecode, but it's much harder to find it in some serialized MonoBehavior variable - hacker need to have some advanced knowledge and skills to do that in such case.

 

ObscuredString a = "1";
ObscuredString b = "1";
if( a == b )
Debug.Log("GOOD");
else
Debug.Log("BAD");


I was expecting result is "GOOD"
But the result is "BAD".

I want to compare ObscuredString with each other.

 

Hey, ChoYongGil!
Equality operator fix is in my TODO already. I'm going to implement it in the nearest ACT update.
You could try to cast them to string until fix will be live:

if( (string)a == (string)b )

 

Finally, new 1.2.0 version is out!
Main highlights:
- new ObscuredPrefs class with flexible lock to device feature allowing data recovery in emergency cases and with some other requested features
- fixes for known bugs

Full changes list:
- project updated to Unity 4.2.2
- new ObscuredPrefs introduced instead of old PlayerPrefsObscured
* PlayerPrefsObscured is no more supported, please, make sure to save all your new data using ObscuredPrefs
* all data saved with ObscuredPrefs will not be accessible using deprecated PlayerPrefsObscured!
* all data saved with deprecated PlayerPrefsObscured is accessible with ObscuredPrefs automatically as fallback (will be removed in future)
* new flexible lock data to device feature introduced, read more in api docs and readme
* now saved data may be recovered in emergency cases (like device ID change after updating from iOS 6 to iOS 7)
* attempt to prevent device id change after iOS6 to iOS7 update (works in some cases only)
* key is now encrypted with common encryptionKey (previously default key for ObscuredString was used)
* accessing data saved with regular PlayerPrefs now generates warning with additional information
* saves alteration can be detected now, use ObscuredPrefs.onAlterationDetected (see ObscuredPrefsTest)
* foreign saves usage detection added, use ObscuredPrefs.onPossibleForeignSavesDetected (see ObscuredPrefsTest)
* added example of storing encryption key outside of the IL bytecode (increasing its security level) (see ObscuredPrefsTest)
* added support of these types: long, bool, byte[], Vector3
- ObscuredByte and ObscuredLong added
- equality operations (==, !=, .Equals()) are now supported in all simple Obscured types
- all default arguments were replaced by methods overloading for additional compatibility with UnityScript
- other minor fixes
- few fixes in docs

Also I did research on some requested features.
One of such feature - make cheating tools detection. I did tested Process class available in Mono, but unfortunately it is extremely buggy and its behavior differs on different Windows versions.
So, for me, it worked on Win 7 x86, but only with try-catches. And same code crashed player at all on Windows 8 x64 after trying to request information on any system process. Admin rights were not make any difference.
I decided to avoid Process class in current version of mono (which Unity uses) and make such functionality using native code or / and native dlls. But this is not fitting in my time gap I got for this update so it stays in my TODO with lower priority until next bigger gap.

I also did some other research, but will inform requesters directly, since it is not so interesting and common like cheat tools detection.

Have fun!

 

Hi, I bought from you directly. The link is still 1.1.0u1, can you update.

 

Hey, Robin, sure! Sorry, forgot to update your link. Will email you new link in no time.
Done, sent it both via PM and email.

 

thanks for fast reply!

 

feature request:
can you add hack detection event if somebody trying to hack obscuredInt

for example add unecrypted value to class and when call "implicit operator int(ObscuredInt value)" it compares values if its changes it calls hackDetectedEvent

 

Thanks for your suggestion, friuns3.
Will try to include this feature into the next update!

 

Dmitriy,

My app just got rejected for using AdSupport, and its because Unity was using some deviceIdentifier stuff in their code.

http://forum.unity3d.com/threads/226187-iOS-Advertising-Identifier-rejection-FAQ

However I have been using SecuredPlayerPrefs and looking at the compiled source it seems that it too is using the deviceIdentifier. When it should be using the vendorIdentifier.

Does your tool allow for player prefs saving with encryption and allow for delivery to the App Store and have it not be rejected?

 

Hey, theprojectabot!

I do my best for this: if plugin used on iOS it tries to use vendorIdentifier first and fallbacks to regular deviceUniqueIdentifier if it fails to receive vendorIdentifier.

This is only one workaround I know without writing native plugins, which would raise plugin's price which is not desired at all %)

 

Hello, I implemented ACT without a hitch and it works great. I have one question though…Is it possible to turn it off or to set a flag that allows EncryptedPrefs to write in unencrypted / plain text format? Because sometimes I change what I save in PlayerPrefs and I like to see the plain text just to make sure that what I want to write to PlayerPrefs is actually being wrote, before I obscuring everything again.

 

Hey, Dan!
This is a good question and currently there is no such option unfortunately =(
You may switch back to regular PlayerPrefs for now though. ACT's TODO list updated!

 

Just awesome! Exactly what i was looking for, Thanks =D

 

Thanks for your kind words! =)

 

I have some questions regarding the assemblies, do you have any plans to detect foreign / added assemblies? A lot of people cheat by adding their own assemblies as well as modifying (which I saw you check for).

Also, regarding bypassing this, have you heard of anything about people trying to do that?

 

Hey, Justei!
Assemblies injection detection is already in my todo, with very low priority though, since it may be easily patched as any other code in .NET assemblies.
There is no way to 100% protect code from altering, especially on different platforms.
If cheater able inject own DLL, he most likely will be able to modify assembly and wipe any checks and protection tricks from it as well, so IntergityChecker (it allows to detect assemblies alteration ATM and will detect assemblies injection in some future release) improvements are very-low-priority for me now.

Speaking of real cases of such cheating - I didn't heard someone tried to bypass it yet, but plugin is not so popular and not every customer may detect such cheating and report it to me. I can bypass it myself though. Anyway, plugin's goal - stop most cheaters, not everyone, since it is impossible to stop everyone (nothing can stop me for example =D).

 

That's what I figured . We have most of our stuff server side, however I'm looking everywhere for different solutions people may have, and we will most likely partner with a 3rd party solution anyway. But I like to do research as much as I can anyway.

 

I see. It's sad to admit, but we have same vulnerabilities as any other bytecode-based apps - sources are not protected from bad guys and may be viewed and altered as they wish to (forget about super secure protectors, crypters, etc. - only one operation can't be automatically reversed - names obfuscation, and it's still not enough anyway since names could be guessed by reversed using context). And it requires not so much knowledge from attacker.

Only server side code with additional checks can prevent it. Best we can do on client side - write code in native language and compile it to the binaries. But you loose cross platform code base in such case. You may store some small, but important piece of logic in native code and use it in Unity Pro as dll native plugin for example. It still not 100% secure solution though, but it significantly increases cheater's skills level requirements.
Anyway, this is not a case for the ten bucks plugin

 

Does this plugin affect game performance/speed ?

 

Hey, NightmarexGR!
In most use cases its footprint is tiny enough to be ignored. Just avoid using Obscured variables in deep nested loops and you should be fine.
And I not received any reports about performance so far, which is a good indicator I guess.

 

Hi Dmitriy
bought! ^_^
I'm using it on COLOSSUS ESCAPE and I'm very happy with it! Highfive respect for the plug-in (and tks to Izitmee for telling me about)
...and also for the Well done guide, a plus for me.

Btw I'm using more or less 90 vars (I had more but I'm cutting and mixing stuff) on Android iOS and works fine.

 

Thanks for your kind words, ALberto! I glad to know it handles so much vars on mobile without issues =)
BTW, 2 all - I'll implement smooth migration from PlayerPrefs to the ObscuredPrefs in the next update, thanks to ALberto's feedback!

 

Hell Yeah. ^_^

 

Hey,

I've been searching unity and the only thing I can find here is:

Secured PlayerPrefs, CryptoPlayerPrefs, and your asset.

Can you please let me know if this asset will work for Android and ioS devices... what is the difference between the other 2?

I just need to prevent some valuable info from others.

Thanks

 

Description:

-_^

Btw I'm using it on my app, COLOSSUS ESCAPE, and it works.

 

Hey, zKici!
I see now what you were asked me about through my blog contact form =)
And yeah, as ALberto already wrote (thanks!), plugin works on mobile platforms.

The difference between my plugin and others you counted above - ACT allows you not only encrypt saved data (using ObscuredPrefs), but it also allows you to hide different in-game variables like scores, money, etc. from memory search cheating software, like CheatEngine, GameCIH, etc.
And as bonus, it has some other neat stuff under the hood - you may lock saves to device, you may react on saves altering, you may check if assemblies were altered, etc.
Well, most common features are listen in my first post and in the Asset Store plugin description.
Please, let me know if you have any further questions!

 

I just tried its easy get serialized MonoBehavior variable, just decompile with unity3d decomipler then rename and copy .asset to new unity project and you can browse all prefabs in unity3d editor easily.

Somebody made hack for my game they inject c# code, hack apears as unity gui window. How this possible? I didn't found any tutorial in google how to do that. They inject it at runtime they don't change dlls.

http://www.youtube.com/watch?v=LGqVi5KdfN0#t=17

 

Do not expect any great anti-cheat system for webplayers;
Unity’s privacy policy made very very hard to do anything about it. All you can do is ban cheaters as usual.

 

Huh, that was really easy, didn't knew Unity keeps assets such compatible with editor, really sad. It still not so obvious for most not familiar with Unity cheaters though.

This is possible and some cheaters with advanced skills may implement such stuff. Here is first .NET dll injection article I found on google:
http://www.codeproject.com/Articles/607352/Injecting-Net-Assemblies-Into-Unmanaged-Processes

So this is surely possible.

Unity engine allows such cheating, even not Unity itself, but Mono bytecode nature - any bytecode (running in VM) based solution has general vulnerability - bytecode may be decompiled to almost pure source code and modification is easily possible (obfuscators can't prevent it, all they can do - erase names in code, to make cheater guess what's happening, all other obfuscation techniques are automatically reversible).

All we can do - make such cheating harder, raise the bar of cheater knowledge and skills, leaving most of them away. Most, not everyone. This is a point for me in this plugin ATM - I make it to let developers save lot of time implementing same stuff I already did for them, but I just can't guarantee plugin will stop everyone. If your app is popular it WILL be hacked (especially client-side one).

BTW foreign DLL injection detection is in ACT's TODO already. It may help to detect cheater before he will notice that and ban him before he realize he got caught.

 

Thanks but there title is "Injecting .Net Assemblies Into Unmanaged Processes" you will not have access to managed assemblies that way i think

but how to inject in to mono managed code that is not development build so you can't attach any debugger, this is interesting)

 

Well, any DLL (both .NET and native) may be injected into Unity player process using regular WinAPI at least, but it could be a bit complicated for .NET developer. There are easier ways to do it in .NET. Anyway I'd rather PM you on this topic than posting injection tutorials here =D

 

Why would you inject a dll in a unity game. Whose crazy idea is that?!

 

Nevermind =D
If seriously it allows you to add any extra functionality to the app without altering its bytecode. It would be lot easier to add, well, player character editor for example, using dll injection than bytecode editing. Anyway both dll injection and bytecode alteration require additional skills from cheater - most of them wouldn't ever use these techniques.

 

It would be much easier to deobfuscate and extract the assembly to a project, add in your code and compile it again

Keep in mind this is incredibly easy with .NET assemblies given amazing programs like telerik jd

 

It may work only with not obfuscated code. And it may be complicated since code may require different Unity stuff to compile. I guess writing separate dll and adding it via injection would be easier. And you not need to re-compile stuff after app update (if they did not add protection against injection of course).
Anyway, this thread made a wrong turn in the really separate direction - it deserves separate discussion! =D