.Net dll encryption
By nature, .NET assemblies are extremely easy to reverse engineer. Say I want to hide some code by embedding an encrypted .dll into another .dll that is to be decrypted and loaded at runtime:
- compile a .dll with all the code I want to protect.
- encrypt the .dll (with the help of SHA-256 hash algorithm and Microsoft RSACryptoServiceProvider to sign the ciphertext).
- create a second .dll that will have the encrypted .dll embedded as a resource.
- Have that second, outer, .dll ask for a key at runtime (from the resource manifest).
- The outer .dll would then decrypt the encrypted .dll with the key - if signature verification passes.
- Load and use the .dll.
I want to know whether this method could be subject to preimage attacks and collision attacks or similar attacks on the verification? I am quite new to the world of cryptography, so sorry if this is a dumb question.
Laycee last edited by
Since you mentioned
so), then one important thing to note that, Windows10 would kill your program immediately when it detects some module is applying cryptography on code segments. These are known as "polymorphic virus".
This is because many malwares are using cryptography hide their true functionality. And after many years of analysis, researchers have concluded that the merit of banning code segment encryption outweights allowing it.
It is mentioned in the comment that applications can be designed to load executable codes over the network. That can be done legitimately, in several ways:
integrityscript element attribute can be used to hint the browser for authenticity verification.
Booting over network, requires the computer firmware verify the integrity of the initial bootloader fetched over the network. Likewise, installation of operating systems over the network (like what FreeBSD and some other OSes does) also require some public information about the remote payload to be known by the installer.