混淆 ASP.Net dll 破坏 Web 应用程序

发布于 2024-08-28 00:28:59 字数 653 浏览 8 评论 0原文

我通常不会费心去混淆 Web 应用程序 DLL,但现在我必须与可能存在利益冲突并可能试图窃取交易并反编译它的人共享一些服务器空间。我知道这不是一个理想的解决方案,但是嘿。

因此,我使用 VS 2005、一个 Web 部署项目(编译为单个 DLL)和 Dotfuscator 社区版本。当我混淆 DLL 时,Web 应用程序中断,我收到一些消息,例如“

Could not load type 'Browse' from assembly MyAssembly

所以我四处搜索,发现如果我禁用重命名,那么它应该可以修复它”。确实如此。但现在,当我使用 .Net 反射器查看 DLL 时,我可以再次看到一切。所以这似乎毫无意义。

有办法让它发挥作用吗? 有没有更好的方法来保护我的 DLL 免受与我共享服务器的人的侵害?

更新:

我找到了我的问题。所有的类名都已更改,但现在我的所有类

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="mycode.aspx.cs" Inherits="mycode" %>

名都不正确,因为 mycode 不再存在。现在是aef什么的。是否有任何工具也可以更改代码文件和继承标签的名称?

I wouldn't usually bother to obfuscate a web application DLL but right now I have to share some server space with someone who might have a conflict of interest and might be tempted to steal the deal and decompile it. Not an ideal solution I know but hey.

So I am using VS 2005, a web deployment project (which compiles into a single DLL) and Dotfuscator community edition. When I obfuscate the DLL the web application breaks and I get some message like

Could not load type 'Browse' from assembly MyAssembly

So I searched around and found that if I disable renaming then it should fix it. Which it does. But now when I look at the DLL using .Net reflector I can see everything again. So this seems kind of pointless.

Is there a way to get this to work?
Is there a better way to protect my DLL from someone I have to share a server with?

UPDATE:

I figured out my problem. All the classnames have changed but now all my

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="mycode.aspx.cs" Inherits="mycode" %>

is incorrect because mycode no longer exists. It is now aef or something. Is there any tool out there that will also change the names of the Codefile and Inherits tags?

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

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

发布评论

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

评论(4

百善笑为先 2024-09-04 00:28:59

您已经接近解决方案了。
在您的情况下,我不知道在哪个上下文中使用“浏览”,但是您是否在某处将其作为字符串引用?

当您以某种方式使用它时,有些东西是根本无法混淆的。

例如,当您有绑定到控件的自定义对象时。您指定为 valuemember 的 displaymember 的那些属性不能被混淆。
这是因为属性被定义为字符串。因此,在设计时控件和实际属性之间没有联系,但在运行时却存在联系。
我不知道如何更好地解释;但这里有一些代码:

// custom object
Public Class MyObject
{
    string Test() { get; set; }
}

// here the object is bound to a combobox

MyCombo.ValueMember = "Test";  // The Test property cannot be obfuscated because of this 'indirect' reference.
MyCombo.DisplayMember = "Test";
MyCombo.DataSource = lstListOfMyObjects;

希望它能解决您的问题。如果没有,请告诉我。

You're close to the solution.
In your situation I don't know in which context 'Browse' is used, but are you referencing it somewhere as a string?

There are some things which simply can't be obfuscated when you're using it in a certain way.

For example, when you have custom objects which is bound to a control. Those properties which you've specified as a displaymember of valuemember cannot be obfuscated.
This is because the properties are defined as a string. So at designtime there's no connection between the control and the actual property, but at runtime there is.
I don't know how to explain it better; but here's some code:

// custom object
Public Class MyObject
{
    string Test() { get; set; }
}

// here the object is bound to a combobox

MyCombo.ValueMember = "Test";  // The Test property cannot be obfuscated because of this 'indirect' reference.
MyCombo.DisplayMember = "Test";
MyCombo.DataSource = lstListOfMyObjects;

Hopefully it addresses your problem. If not, let me know.

青巷忧颜 2024-09-04 00:28:59

我从未使用过Dotfuscator社区版,但尝试看看是否可以仅重命名Private类型、变量。这应该会让它更难看到。在我看来,大多数混淆器都有问题,当您发现错误时,他们希望您发送代码,以便他们可以解决问题。我发现大多数商业版本都存在问题,但也许在过去几年中它们已经变得更好......

I have never used the Dotfuscator community edition, but try to see if you can rename only the Private types, variables. That should make it more difficult to see. IMO most of the Obfuscators have issues, and when you find a bug they want you to send your code so they can fix the problem. I have found issues with most of commercial versions, but maybe they have gotten better in the last couple of years...

眼泪淡了忧伤 2024-09-04 00:28:59

对于 asp.net 我不知道有什么快速的出路。我发现的最快方法是Secure Team 的代码保护功能。它离开了接口,但加密了所有的信息,使某人很难逆转它。

Asp.net 很棘手,因为一旦开始更改事物的名称,就会使用所有动态解析和反射,它就会变得脆弱,并且需要进行另一轮测试以确保所有内容都加载并且没有任何中断。

For asp.net I don't know of a quick way out. The quickest way I've found is Secure Team's code protection functionality. It leaves the interface but encrypts all the il and makes it hard for someone to reverse it.

Asp.net is tricky due to all the dynamic resolving and reflection used once you start changing the names of things it becomes fragile and in the need of a whole other round of testing to make sure everything loads and nothing breaks.

眼睛会笑 2024-09-04 00:28:59

我们需要类似的东西,并尝试了 bitHelmet。它为框架已知可按名称访问的某些对象提供预定义的排除,例如 Web.UI.Page Descendants。它与网络应用程序完美配合。

We needed something like that and tried bitHelmet. It provides predefined exclusions for certain objects which are known to be accessed by name by the framework, for instance Web.UI.Page Descendants. It works perfectly with web aplications.

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