Yearly IL2CPP on Standalone Thread

Scripting
1

So I noticed it’s been about a year since the last thread about IL2CPP support for Standalone builds, so I figured what with it being nearly Christmas it’d be a great time to bring it up again.

Only thing is, it’s precisely on the roadmap where it was last year: Nowhere.
It’s the third most voted for Platforms suggestion on the Unity Feedback page, yet it’s nowhere to be seen on the roadmap, whilst platform features that almost nobody voted for are in the roadmap for release in 2017.3 and have been released in 2017.2 (cough Mixed Reality #spon)

What’s going on? Why is it harder for standalone than it is for, say, Android or WebGL?

It’s something that’s really holding Unity back; that developers can’t release apps to the most basic, original platforms without their code being prone to being stolen or modified.
Is IL2CPP, or something which provides equivalent source removal qualities, ever coming to standalone?

4 Likes
2

It has probably been deemed not worth the effort.

What actual advantages do unity users have from IL2CPP? None.

I hope I can calm your worries with this analysis:
Even if you feel like that your code will be stolen (which, even if that were the case, would not really matter*), it’s not actually holding you back. In fact, there are many devs releasing games despite this perceived issue.

*) Lets assume you wrote some awesome code and release it? Even though I have the technical means to “steal” your code, would I really bother? Do I even want the hot mess of a codebase? (which real games usually are because of intense time and money constraints)
Let’s even go as far to assume that your code is actually well done and modular, will that give me a full game?

No, of course it won’t, my only options would be:

a) to either copy your game 1:1 (which makes no sense because even if I’d manage to publish it and not get sued or get my app removed from the stores, you’re there earlier so people already buy the game from you instead of me…),

or

b) Make my own game. But then again why did I even bother going through the trouble of “stealing” your code anyway? If I did it because I’m too incompetent to write my own game code, then my project will be dead as soon as I hit the first roadblock, bug or limitation that I can’t fix myself.

So in any case, people don’t even want your code, because without documentation, comments, and most importantly people who can fix/improve/update the code, its basically a very brittle asset that is basically useless for actual game development. And if they want to know how something in your game is done, they are 100x more likely to just record a video, post it in some forum and get some really really smart people to tell them how its done.

Well, it would be nice to have more stuff and features implemented, but Unity is notorious for bad communication :stuck_out_tongue:

1 Like
3

This is not forgotten and top people are looking into it. There is no ETA we can promise but next year is probably the year your wish will come true. Will take a look at the roadmap issue.

1 Like
4

Where does this absurd idea that IL2CPP is a DRM/obfuscation solution come from? I keep seeing it pop up again and again and just… what?

It’s never been advertised as such, there’s no reason to believe it’s anything like that. It’s a tool that translates the compiled IL to c++. That c++ can still be decompiled and edited.

@Schubkraft , genuine question: why would I want to use IL2CPP on say Windows 64 bit standalone applications? My experience from using IL2CPP on platforms that demand it is that the only noticeable difference is a longer build time.

5

I’m currently actively working on supporting IL2CPP on Standalone Windows and Mac. It won’t be much longer until you get your hands on it.

IL2CPP does not prevent your code modification. Do not depend on that or you will be disappointed.

You’re right that IL2CPP is not DRM. It does prevent trivial decompilation, though. And IL2CPP builds will always have longer build times.

The main advantages are faster startup time (since there’s no JIT) and faster script execution.

2 Likes
6

Are you working on improving this times by caching? Can assembly definition files help on this? I mean sometimes between two builds you only change a line when you are fixing bugs and having to wait the same time between this previous and the current build doesn’t make sense.

It’s a real problem because IL2CPP it’s going to be on all platforms in the future.

We need fast iteration times.

If now I get a windows build in 30 seconds and with IL2CPP it’s going to be 3 minutes it doesn’t worth it.

7

Caching is already there. There were big improvements on this in 2017.1. If you build to the same folder as you built before, only a few C++ files should be recompiled, which means way quicker iteration times. It doesn’t help the first build, but all subsequent builds should be significantly faster.

We do have plans on improving it further, but we are not working on it right now.

1 Like
8

.Net bytecode can be decompiled by automated tools in such a way that the game can be decompiled, modified and recompiled fully. It’s not even about DRM (for me). It’s also more difficult to detect these modifications because the detection code could also be reversed!

I’m currently having to use a system-level service to ensure against assembly modification.

I’m aware of this [that it’s not DRM, build times and startup times]; and I’m really glad to hear it’s coming to standalone platforms! The reason I’m speaking about it from a perspective of code modification is because of how much easier it is to make really gamechanging modifications in .net, and how much harder it is to make modification detection mechanisms which can’t be bypassed just as easily. I’ve had a look at the intermediate files on IL2CPP builds for other platforms (WebGL) and can say that it’s definitely enough that, when coupled with a thin in-house solution such as Blizzard’s Warden, Valve’s VAC etc it could be effectively tamper-proof.

C++ can be edited, but saying it can be decompiled when .net bytecode is the topic of conversation is almost the overstatement of the century. Speaking from experience, it’s so much harder to make the simplest of edits when it’s C++ compiled to native code than .net bytecode translated JIT to native code.

The two aren’t even comparable. You can see for yourself how much ‘protection’ it provides just by looking at the intermediate files of a WebGL build. I mean, sure, there’s still what amounts to export symbols packaged in there (it’s in the data segment, I imagine this is for Unity’s core use of some reflection features?), but if you wanted to significantly change game logic it just isn’t an option, as it is with .net.

Tasks such as deactivating components (e.g. colliders) will be relatively easy with or without IL2CPP, but still a lot harder with, and a lot harder to maintain the ‘hacks’.

1 Like
9

For people who are actually afraid of someone tempering with their code and “hacking” it, I think you should ask Unity to implement a mechanism actually designed as countermeasure to this, which is Strong Names for assemblies, instead of pushing for IL2CPP, which as indicated by likes of Baste, is not meant as a hack-prevention mechanism.

Also support for a digitally signed exe’s would raise the protection level even more.

1 Like
10

Digital signature enforcement is only as strong as the enforcement code itself. Same applies with strong names. The only way you could truly stop code tampering is by stopping the code from ever being executed or available on the users PC. SN would be nice in addition though - they all make life more difficult, but only cloud gaming (think: NVidia Shield) makes it impossible!

11

Strong names in the context of anti-cheating or DRM is laughable.
Removing a strong name requirement is a trivial thing (assuming you don’t have other protections)

It has its place though, but it aims for something completely different.
See here: Strong-named assemblies - .NET | Microsoft Learn

In some scenarios it can also have the benefit of preventing malicious code from easily replacing a strong named dll to gain elevated permissions.

But since a user has elevated permissions on their computer already, they can just remove the strong name requirement from all the dlls and the game, and patch the code that checks for that (which is not hard).

1 Like
12

That is very true, but for some the task of finding an exploit/hacking/cheating is several orders of magnitude harder for compiled code vs decompiled IL or similar.

Not only that, the pool of people who can understand and meddle with decompiled IL vs object code I’d guess is also orders of magnitude apart.

Anyone with the know how knows it’s not too difficult to modify the object code (just ask fravia) , but reading assembly/object code vs reading decompiled IL is just not in the same league.

IMO having object code vs IL will increase the barriers for some - perhaps so much so they may not bother. It’s about making it difficult enough that the time-benefit is diminished enough to discourage it.

I totally understand there is no security through obscurity, but it makes things harder. There’s no need to hand things over on a silver platter.

1 Like
13

Not to mention how hard it is to identify changes in native code Vs managed IL. You could never get away with mass detection banwaves on a .net game. It’s too easy for malicious developers to spot new potential detection mechanisms and correctly identify them.

It really is just for the sake of making life more difficult for “the bad guys” that I want the feature. Well, the performance boost wouldn’t go unappreciated either.

But currently it’s a case of cat and mouse, and the game devs are the morbidly obese mouse who can’t run, can’t hide and can’t protect themselves. Unity games are literally ‘easy catches’.

1 Like
14

That’s why the SN verification mechanism should be incorporated in Unity launcher exe which starts the Mono, which is a classic machine code exe. It should also be digitally signed.

The launcher would guarantee the SN are kept intact, and you can verify digital signature of a launcher on server side.

This approach would make it orders of magnitude harder to temper with the files. Obviously it wont protect against hacks which overwrites memory.

Ultimately there is no way to prevent all hacks on client machine.

I think the reason it takes so long to get IL2CPP on Windows standalone is because the number of compatibility concerns is way greater than on any other platforms.

15

However, once that is broken once by somebody, now suddenly all Unity games are affected by it. And we’re not ready to play whack-a-mole game with crackers.

Not really, it was just lower priority than other platforms. It was the only platform where not having IL2CPP would prevent Mono upgrade.

2 Likes
16

I’m not arguing for the SN verification mechanism as I’m not familiar with it … but if it is broken wouldn’t the worst case scenario be that a Unity game would be as vulnerable as it is now?

I don’t get how this could be an issue.

17

The issue is that if we start implementing DRM, developers who want to use DRM would use our solution (instead of using something specific for their game), and then it would be our responsibility that this DRM solution keeps working. And as I mentioned before, we are not going to play this patching/fixing game with crackers.

2 Likes
18

When IL2CPP is added to Desktop then Unity will be at least usable again.

Whenever a team wants to build a game on Unity I show them why we shouldn’t do it, show how long it takes to crack a anti-cheat’s function in Unity’s DLLs then recompile: (4 seconds).

(I find pretty funny when developers add anti-cheat functions in their games that are written in C# or UnityJS, really, to say the least)

If you’re checking something online I will just patch your function to return “true” in the client, never calling the real online check, so it doesn’t really matter if your checks are client-side or not.

When machine code is involved however, ain’t all that easy tho, most non-crackers would just leave the game alone drastically reducing scope when you have to identify where a cheat software is coming from and making not that impossible to patch current vulnerabilities in the game code.

2 Likes
19

Exactly. And speaking from experience doing a simple modification such as the one you just suggested in native code, could take hours depending how hard it is to find- another thing which IL doesn’t let you manipulate.

The patch you describe is just a JZ-JNZ or vice versa but they’re really difficult to find sometimes.

20

We don’t want to a unity DRM, Just the ability to add support for it which isn’t then overwhelmingly easy to remove.

For example, DRM provided by a native DLL (say SteamAPI) in unity, at it’s current level, could be bypassed by simply replacing the library calls with static functions which verify it, then recompiling it.

Doing the same with IL2CPP would be much harder.