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?
do not want additional start up time for something unnecessary.
“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.
We already sign the binaries that we ship on both Windows and MacOS using standard cryptographic codesigning approaches, and I know that the Hub already does some signature validation (though I think not every time you launch the Editor).
As @zombiegorilla says though, it’s a bit of a losing game - if someone has managed to access your machine then there are much easier attack vectors than “modify the Unity binaries.”
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.
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?
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.
That wouldn’t help you, because you can still hex edit the check out. If every Unity game started doing it, I bet somebody would release a tool does that automatically. That also doesn’t help for in-memory modifications which is actually what most cheats are doing.