How can I verify authenticode signatures on managed referenced assemblies before they are loaded?

[glen-nicol]

With the goal of verifying that my managed dependency assemblies haven't been tampered with, I would like to verify they pass authenticode checks with a known certificate before loading them.

With that in mind I would like setup an event handler similar to NativeLibrary.SetDllImportResolver such that I can check for an authenticode signature with a known certificate owner on a managed assembly before its loaded. I have found the AppDomain.AssemblyLoad event but that is executed after the assembly is loaded into the runtime.

I realize for a plugin or dynamic assembly load I could do this check before I call the relevant functions but for statically linked dependency assemblies that load when a type is used there doesn't seem to be a way to hook this behavior.

The only "workaround" I can think of is to verify all managed assemblies in main before any external types are referenced.

I can fully appreciate this use case is fraught with infinite loop pitfalls. For example: How could I ever load the X509Cert type to verify the assembly that contains the X509 types? I guess I am not too worried about the .net system assemblies, just my own assemblies from being changed.

[Clockwork-Muse]

..... If they can change your own assemblies, what's preventing them from changing your loader code? And that's assuming that your dependencies have authenticode configured, which isn't a given.

What is it you're trying to protect against here?

[glen-nicol]

^ Yes I am fully aware of that fact. This is an attempt to satisfy a requirement to use obfuscation and code signature verification where possible. It's about putting up barriers to reverse engineers.

[Clockwork-Muse]

Are the dependencies you're verifying your own libraries, or all dependencies (Eg, open source libraries)? If you're using precompiled dependencies from NuGet, that's going to make an easy point to figure out what you're doing, because that dll won't be obfuscated at all.

Note that replacing signatures is often trivial, because you're (usually - there are ways to break it up) embedding a large string or other contiguous binary blob, which is usually easy to spot. That also makes it relatively easy to find where they're being used, which makes it more likely to be able to turn it off.

I guess I am not too worried about the .net system assemblies, just my own assemblies from being changed.

I might worry about this one more, as potentially this would be the attack avenue (Eg, potentially replacing the hashing code to return a constant value, or not fire the load event you're using to perform the checks, etc).

There are existing obfuscation tools, have you looked into any of them?

[glen-nicol]

Just our own assemblies, gotta draw the line somewhere. I understand your point about runtime assemblies as I understand how this is not a hard thing to get around when the party has full control of the machine and files.

I've used confuserex, ilmerge, and dotfuscator in the past. But haven't really seen one for modern .Net that seems like a clear choice because it seems allof the ones above were for framework and not 5+.

Ideally I could compile our app down into native code for obfuscation but wpf doesn't play well with that it seems.

Given I understand the limitations of the effectiveness of what I'm asking to do, I still need to do it. Do you have any advice on how to do these checks simply?

[Clockwork-Muse]

Sorry, I don't have any specific knowledge that would help you here.

As an aside, I will note that the gaming industry has spent probably on the order of a trillion dollars on this exact problem, and generally failed at solving it. The best attempts have generally kept some/all of the resources on a server to download on demand, but even this only delays things for a while. With the constraints you've mentioned so far, I doubt you would seriously delay any interested party.

[glen-nicol]

^ yeah I've made that same argument about game DRM but the decision is out of my hands.

[blowdart]

This is not .NET's responsibility. Windows already provides this.

If you implemented it, say for a plugin model, then a plugin that has the right signature could disable further checks.

In addition, someone can simply edit your code to always return true regardless of what the result is.

Whereas when Windows does it none of the problems apply, it's outside of your apps control. This is what WDAC is for.

[Clockwork-Muse]

Unfortunately, that likely doesn't apply when the attacker is the actual computer owner, which is the case here (reverse engineering). It also doesn't exist on Linux, if that's a deployment platform.

[blowdart]

And putting any sort of check in your own code doesn't work if the attacker is the computer owner either, so 🤷‍♂️

[BreyerW]

Ideally I could compile our app down into native code for obfuscation but wpf doesn't play well with that it seems.

Maybe have a look at AvaloniaUI then? im no maintanainer, just noting its a framework a la wpf built for modern net and cross platform and supports NAOT avalonia aot

they even have compatibility shim aimed at WPF developers that allows nearly drop in replacement of WPF with Avalonia but is paid and idk if it supports naot

[glen-nicol]

Thanks for the reminder that they support native. I love avalonia and have even contributed a couple prs but it wasn't quite ready enough to make us comfortable when we evaluated it a couple year ago.

I'll have to check back in on it sometime soon.