C++/CLI /clr DLL 和 Assembly.Load() 的加密

发布于 2024-08-16 07:59:41 字数 1027 浏览 6 评论 0 原文

伙计们。我正在为我所属的在线社区开发客户端软件。为了让我为其编写客户端,所有者和网站管理员要求对我的代码进行加密(而不仅仅是混淆)。我的大部分项目都是用 VB.NET (F3.5) 编写的,出于性能原因,其中一些通过 C++/CLI 使用 SQLite 和 libcrypt(因此我无法使用 /clr:safe)。换句话说,如果使用 /clr:safe,那么编写 C++/CLI 代码将毫无意义(我只需在 VB 中编写所有代码,这要容易得多)。

如果这只是 VB 项目,我只需编写一个 C++ 加载程序,将代码从存储解密到内存中,然后使用 Assembly.Load() 通过某些公共方法(例如,主窗体)运行它。然而,一些莫名其妙的策略阻止我使用未经验证的 C++/CLI 代码执行此操作。我很茫然,因为我可以使用正常的 DLL 加载机制而不受限制地使用任何“不安全”的 DLL,但由于某种原因我无法使用 Assembly.Load() 来做到这一点。我不明白为什么这应该更安全(假设其他选项可用)。 Caspol.exe 没有帮助,即使有帮助,我也不能要求社区中的每个人都关闭其计算机中的访问安全性。直接从内存加载 EXE 或 DLL 似乎不太可行(UPX 可以使用常规 DLL,但不包括 .NET DLL)。

所以我问以下问题:

  • 你们能想到我可以用来加密 C++/CLI DLL 的 MISL 部分的任何方法吗? (我认为该代码与常规 x86 机器代码混合在一起)。

  • 有没有办法从字节加载未经验证的 .NET DLL,就像我尝试使用 Assembly.Load 所做的那样?

    有没有办法

或者,由于 CreateProcess() 和 LoadLibrary() 只采用路径,我想我可以编写一个临时 EXE 映像并从存储中运行它。但我需要用户无法访问该图像,因此将其写入磁盘将是愚蠢的;它应该是一些不稳定的东西,比如私有虚拟磁盘或其他东西。有什么想到的吗? (Windows 2000 及更高版本)。

非常感谢,

吉耶

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

失而复得 2024-08-23 07:59:41

You can load an assenbly from a stream, using an AssemblyResolve method. See this answer for details.

远昼 2024-08-23 07:59:41

Assembly.Load(byte[] ...) 明确不允许不可验证的(混合模式)程序集。您可以在 Microsoft Connect

Assembly.Load(byte[] ...) explicitly disallows unverifiable (mixed mode) assemblies. You can check the issue on Microsoft Connect.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文