Should Unity have an integrity checking system that ensure it's data/apps are secure?

Unity includes a lot of moving parts any of which could be used by a hacker to gain access to a developers system, therefore should Unity include an integrity checking system that helps protect developers?

Something as simple as SHA256 or MD5 file checksums could be used to ensure Unity tools and files are validated every time you use them.

Then Unity installers and the Unity Hub could have a file validation/repair systems added.

Note: Just searched my Unity Editor folder for

• .exe files and found 1,001
• .py files and found 52
• .dll files and found 9,492

At over 17 GB of data and 137,000 files adds up to a lot of vulnerability or opportunity to hackers.

Side note: how hard would it be to write our own validation checker/launcher?

 

No.
1. do not want additional start up time for something unnecessary.
2. "hackers" don't target dev apps like Unity because... why would they? If a "hacker" has comprised your system A) you are a fool, and B) there are substantially more interesting targets.

You don't need to validate Unity, you need to not compromise your system in the first place. Practice smart computing, and use VCS/ Backups.

 

Just wrote a quick sha512 checksum generator that could parse my Unity Editor folder and files and it took over 705 seconds (about 11.75 minutes).

Note this was not using Async or multi-threaded file checking so could be a lot faster.

In addition other potentially faster checksums/hashing functions could be used e.g. sha256, xxHash.

Good point although an on demand checksum or checksum launcher could focus on main exe and dll files and check them adding only a few seconds to launch times.

Then Unity HUB or editor could allow users to run a checksum that validates all files but takes longer.

 

What if they do it via some Unity code or Project?

 

Good point it appears you use SHA1 which is way faster than SHA512 I managed to scan all the Editor files in 160 seconds using SHA1.

Unable to use Async SHA1 code as Unity is only on .Net 3.5/4 and I think the async version require .Net 5/6 but this should make scanning Unity files super fast and only limited by SSD bandwidth and or CPU cores.

 

Find an intrinsics based SHA1 implementation and port it to use burst intrinsics. Pass memory mapped file pointers to jobs, calculate hashes.

=====

But on topic - from the title I thought this would be about integrity checking of a project build released to the public. Not for the editor.

For installer verification you could download the torrent version (at least those are linked in the LTS patch release pages) and use that.

For install verification .. I guess there is a use case? You probably want to rely on (software) RAID and filesystem level things instead though. There's also a variety of backup programs that could find changes and revert them. Would be much more about random bit flips than security though.

 

Not possible unless the user has done something completely stupid, even then it would mostly just break Unity. It is an unrealistic hypothetical. Security is done at the OS level (and like... 99% operator level).

They could also add a HUB feature that checks the lastest on-time status of BART, or the current average price of the highest value beanie-babies. There are all kinds of things they could add. But ideally, they will stick to ones that provide actual use.

 

Well... I recently read a computer security article about someone who did a "Pen Test" by modifying code in public repositories. The repos were referenced by automated build systems, and next time those systems built their apps the tester basically had full access to either the build environment or the app's deploy environment.

We can probably agree that directly referencing fully public repos in your automated builds falls under the "completely stupid" banner. But that was an extreme case used to demonstrate a concept. It's fairly common for projects to include 3rd party stuff via mechanisms such as Unity's Package Manager*, and that certainly broadens your surface area for attacks via your own project's code. Sticking to Unity-hosted packages probably eliminates most of that risk, of course.

On desktop platforms there's still plenty of nasty that user-level code can perform.

Of course the answer to all of that is simply: don't run code from people you don't trust.

* Which is a common thing, plenty of environments have their own equivalents.

 

Yes, running remote code, unknown plugins, etc.. is stupid. And also none of which would be prevented by solved by a hash check or integrity check on the Unity app.

Yes, that is what I meant by "operator"... the user of the computer in question. There is very little damage one can do using Unity by accident (apart from build folder, if that is still a thing). You have to install something, or specifically write something to do local file damage and even then you are going to have to actively bypass local sandbox security settings or write things specifically to get around local permissions settings. Running remote plugins often requires settings in the package manager and even sometimes keys for the server. If this causes problems, it is because of a choice the user made (at some point). No remote "hacker" is going to hack into your computer and make Unity do bad things.

But, again, none of this stuff is impacted in any way by a "integrity check" run by the app or hub. I mean really, if Unity could make a magic tool that could detect if user code is doing something unintended... a better application would be performance or just general terrible code optimization.

 

A checksum validation and update tool could also enable Unity to release patches that update only those files that need to be changed.

Costing a tiny fraction of the download/bandwidth costs of a new gigabytes install each release version.

E.g. how much of Unity actually changes from release to release even in the beta cycle?

They could even copy or move over old Unity files that have not changed to and are checksum validated to a new install folder.

 

Wait wait wait, are you suggesting this is not something we should be pushing for them to add to the hub? What if I want to keep up with beanie-baby prices WHILST developing in unity? Outrageous! /s

In reality though, absolutely agree with @zombiegorilla on all points he has raised. I think overall its just not a sensible suggestion for all the reasons already stated, in addition to the following :

Why out of all the ideas would this make sense to prioritise (or even give thought to) when there are things that can actually benefit majority of users that still need to be worked on, like fixing package manager workflow issues or optimizing the way features are worked on and released to minimise wasted work/features getting killed etc etc. This just does not stack up in the realm of important anythings, to focus on compared to the many things already needing attention in comparison (and rightfully so).

In comparison to complaints about workflow/issues using package manager as example, how many users complain about people hacking into their unity remotely? The answer to that question alone answers why this just wont ever be a sensible time sink (Even if the logic behind why this is something to work on was sound - which it is not for reasons stated by a few users already)

 

Agreed that the Unity Editor is not a worthwhile avenue for compromising a system. However, for compiled IL2CPP games, it would be nice to have a checksum hash for game files such as GameAssembly.dll as a simple first line of defense against hex editing -- for game creators that desire this basic level of security. Does this not exist?

 

How effective is it?

 

Well, Unity forum is somehow a magnet for worthless "solutions" against non-existent problems.

 

why do i think it might come in handy

 

Specific to preventing apps and games from being locally modified — it is quite effective. The apple store, google play and windows store use cryptographic hashes and signing to validate integrity of shipped binaries. There is no such thing as absolute security but it would likely foil the negative commenters in this thread. Useful for released games, not the editor.

 

This depends entirely on your purpose and how much someone wants to defeat your protection. Even when big publishers shell out millions on this kind of stuff it's just a temporary measure.

A couple of things to note there.

First is that the emphasis is on shipped binaries. They're making sure that things stay unmodified until they reach your device.

Second is that the effectiveness of that is highly dependent on both how open the platform is, and how much people want to mess with your stuff anyway. On a Windows PC if your game gets popular someone will just crack whatever protection you try to put in there.

 

This too, is pointless.
There’s no need to complicate things. Many(most?) of us have multiple installs. A patcher would have to compare an diff many, many versions, it would be a complex mess that would likely have problems and would have to be maintained. Or… you could just download a complete archive of the version you need. Simple and easy. Bandwidth and storage a cheap.

 

Shouldn't the cpu/OS/AV security prevent in-memory modification from other processes/threads?

 

Re: protecting IL2CPP output executables from third-party modification. I get it. I don't necessarily disagree with the wisdom of the crowd here. But I'm determined and sometimes that's a strength. For my scenario, I think it might work --I appreciate having technical holes poked in it. Background: My multiplayer game is server-side authoritative but if I allow modification of the client bad actors will find exploits. So how might I make it work?

1) During auth/login process with existing remote game server, the server generates a unique per-session signing key with list of files for the client to hash and sign with unique key. (i.e. GameAssembly.dll).
2) Game client iterates through said list and generates hashes and signs each with key, and returns result to game server. The server knows the expected result.
3) Game server either accepts or rejects signed hash result, and if rejection occurs, the user cannot auth/login to play the game.

This is specific to tampering local files (not addressing in-memory modification). I'm trying to evaluate if this works. It isn't much programming, as I already have a game server.

Issues?
- Files could be modified after the game starts. i.e. asset bundles.
- A sophisticated hacker would inject a new method that calculates hashes of files copied to a backup location, and use this to generate and sign a hash returned to the server. They would need to be able to rewrite or inject a new method.

 

I'm interested in understanding the answer to this question, too. When I tried writing a program in C++ to scan the bounds of memory in other applications I always got seg faults. How do they do it?

 

Fantastic! Thank you!

 

"The handle must have PROCESS_VM_WRITE and PROCESS_VM_OPERATION access to the process."

So there is OS account level security applied, just not APP/Process level security.

 

Most gamers have local admin -- especially any with intent to crack software. I haven't tried this, but I read that not even local admin is required for this call to work (i.e. read access).

 

OK reading a processes memory with Admin privileges but surely writing to a processes memory or DLL injection why should that be allowed so easily?

 

So if we can read a processes memory there is a way to run a checksum on in memory DLLs?

Although it's kind of chicken and egg at this point without some level of authentication within the system isn't that the point of Windows 11 needing TMP2 a hardware/BIOS level security system?

 

Yeah, but take a look at Riot's "Vanguard" anti-cheat system and the perfectly justified outcry when it was included in Valorant. That's the kind of level you need to go to if you want something like this to work. And even then, I suspect someone will crack Vanguard if they haven't already, because it's still running on an open system.

The issue is that for anything you lock which runs on a user's hardware you must also, by fundamental necessity, build the keys right into your application. Otherwise the user can't use it. So all a cracker has to do is find and use the keys. In many cases that isn't even a metaphor.

And as discussed earlier, the ways to prevent that aren't with software so much as they are with safe user behaviour. I can have the best security software ever, and it's defeated the instant I give permission to the wrong bit of code to run. And in the case of users modding my game, I don't control the permissions at all. They do. Which brings me to my next examples: iOS and consoles.

Locked down systems are (mostly) safe from this stuff precisely because users don't get to give permission for code to run. It's all done via the vendors with certificates. Unless Apple says so, a piece of native code can not run on my iProduct. Unless Sony says so, a piece of native code can not run on my Playstation. That's how far you need to lock down a system to solve "PEBKAC"* security risks.

* "Problem Exists Between Keyboard And Chair". Note that this is NOT to say that the problem is your users' fault. They can't know everything, and we need to do our best to account for that.

 

I think your 'blaming' users when there are so many potential flaw points in our Apps, OS, Drivers, BIOS, Hardware, Internet for instance any single Zero day flaw could be a security flaw to hackers.

My Windows system has over 9,000 exe files and over 70,000 dll files that's a lot of potential for zero day flaws and dll injection. And I don't have a lot of apps on my PC.

And my two Unity installs add about 20% to exe and 28% to dll files to my PC's vulnerability surface.

Maybe Windows 11 TMP 2.0 security will improve things?

 

Just checked the 2021.2.0b 13 vs 14 and 79,153 files checksum SHA1 match between both installs.

Between 2021.2.0b14 and 2020.3.19f1 a surprising 10,835 files checksum SHA1 match.

 

So low level BIOS/Boot security and encryption that can be used to secure higher level systems/data or a more secure foundation to build upon.

 

Hold off a hacker for 30 minutes...

https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-network-intrusion-in-30-minutes/

 

Not in any relevantly meaningful way.

If you re going to worry about this stuff then learn about it properly, rather than extrapolating from a few random snippets. Learn what a "threat vector" is and which ones are relevant to you.

Even if you believe that people have the means and the opportunity, what motive might someone have to attack you via Unity DLL modification?

And if you come up with something (I'm sure you will), the next question is whether or not it would be an effective way to carry out the attack.

 

Closing because it really didn't have any practicality in the first place, not really unity related (any more), and now it ventured into some weird "explain basic security to me but rather than asking I will post a series of increasingly nonsensical statements and everyone can explain why they are wrong".

Solution: research computer/systems/information security, there is a LOT of information available.