guys. I’m developing a client software for an online community I belong to. In order to let me write a client to it, the owners and webmasters demand my code to be encrypted (not just obfuscated). Most of my project is written in VB.NET (F3.5), and some of it is using SQLite and libcrypt via C++/CLI for performance reasons (so I cannot use /clr:safe). In other words, it would be pointless to write C++/CLI code if /clr:safe were to be used (I’d just write all code in VB which is much easier).
If this was only the VB project, I’d just write a C++ loader, decrypt the code from storage into memory and then use Assembly.Load() to get it running via some public method (e.g., the Main Form). However, some inexplicable policy prevents me from doing that with unverified C++/CLI code. I am at loss, because I can use any “unsafe” DLL without limitations using the normal DLL loading mechanism, but for some reason I cannot do that with Assembly.Load(). I fail to see why that is supposed to be more secure (given that the other option is available). Caspol.exe doesn’t help, and even if it do, I couldn’t ask everybody in my community to turn off access security in their machines. Directly loading an EXE or DLL from memory doesn’t seem to be feasable (UPX does that with regular DLLs but not with .NET DLLs).
So I ask the following:
-
Do you guys can think of any method I could use to encrypt the MISL part of the C++/CLI DLL? (I think the code is intermixed with regular x86 machine code).
-
Is there any way of loading an unverified .NET DLL from bytes, as I tried to do with Assembly.Load?
Alternatively, since CreateProcess() and LoadLibrary() only take paths, I though I could write a temporary EXE image and run it from storage. But I need the image to be inaccessible to the user, so writing it to disk would be just stupid; it should be something volatile like a private ramdisk or something. Anything comes to mind? (Windows 2000 and up).
Thanks a lot,
Guille
Assembly.Load(byte[] …) explicitly disallows unverifiable (mixed mode) assemblies. You can check the issue on Microsoft Connect.