-
A little deeper investigation
It is observed that when we strong name the DLLs in Visual Studio, the reference to these DLLs in the Entry EXE adds a public key token value with it. This is making the exception at Entry app when the DLLs are strong named out of Visual Studio. So, we need to modify the Entry App exe also to add these public key token value for new Strong name key.
(Fig: Entry App exe's IL code showing reference to backend DLLs. Left side: Strong Named in VS, Right side: Strong named out of VS)
-
Decompiling the Entry app EXE.
-
Modify publickeytoken value in assembly reference.
Modify the existing publickeytoken value with the public key token for new strong name key.
-
Reassemble the IL code back to Exe
Recompile the modified IL code to new exe and replace old exe with the new exe in the application folder.
-
Application started!
Now, application booted up. But, App got halted due to the expected Authenticode signature verification fail.
Wait a minute! This does not satisfy our initial target.
We didn't target to modify the Entry Exe app in the attack scenario. Attacker can change the validation logic if he has privilege to modify the Entry Exe. So I have decided to check a bit about this behaviour. I have come to know that this is a feature in .Net Framework called strict loading. .Net CLR will not bind references if there is any mismatch in the StrongName details added during build.
-
Changing the UI application to .Net Core
So, I have quickly created a Console UI in .Net Core. And, added reference to the MathLib Dll for performing the calculator operations.
-
Moved the new UI exe to the DLL modification workspace and started.
There is no problem now as it faced in the case of .Net Framework UI. StrongName validation was successful and the UI app throws error for Authenticode signature failure.
-
Signed with attacker's Authenticode cert!
-
Run the application again!
Again we get the "Signature verification failed" error. We can now the reason of exception is because of "Untrusted Certificate", if we debug the application with the modified DLL. This means attacker's certificate is not in the Trusted root store of the production machine. So attacker cannot achieve bypassing Authenticode signing.
-
A final confirmation!
To just start the App and show the effect of modified DLL, we can sign the DLL with old original certificate. Application started-up and given the modified Dll output.
This step proves that we can strong name the DLL with a different strong name key. But, Authenticode signing will fail if it is not signed with a certificate which is not in trusted root store.
(Note: Alternatively, we can add the Fake certificate to Trusted root store to start the application. But, it is DANGEROUS to add random certificates to Trusted root store!!)