Запутывая ASP.Net DLL ломает веб-приложение - PullRequest
2 голосов
/ 31 марта 2010

Обычно я бы не стал запутывать DLL веб-приложения, но сейчас мне нужно поделиться некоторым серверным пространством с кем-то, у кого может быть конфликт интересов, и может возникнуть соблазн украсть сделку и декомпилировать ее. Не идеальное решение, которое я знаю, но эй.

Итак, я использую VS 2005, проект веб-развертывания (который компилируется в одну DLL) и редакцию сообщества Dotfuscator. Когда я запутываю DLL, веб-приложение разрывается, и я получаю сообщение вроде

Could not load type 'Browse' from assembly MyAssembly

Так что я искал вокруг и обнаружил, что если я отключу переименование, то это должно исправить Который это делает. Но теперь, когда я смотрю на DLL с помощью рефлектора .Net, я снова вижу все. Так что это кажется бессмысленным.

Есть ли способ заставить это работать? Есть ли лучший способ защитить мою DLL от кого-то, с кем я должен делиться сервером?

UPDATE:

Я понял мою проблему. Все имена классов изменились, но теперь все мои

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

неверно, потому что mycode больше не существует. Это сейчас AEF или что-то. Есть ли какой-нибудь инструмент, который также изменит имена тегов Codefile и Inherits?

Ответы [ 4 ]

1 голос
/ 31 марта 2010

Вы близки к решению. В вашей ситуации я не знаю, в каком контексте используется «Обзор», но вы ссылаетесь на него как на строку?

Есть некоторые вещи, которые просто невозможно скрыть, когда вы используете их определенным образом.

Например, если у вас есть пользовательские объекты, связанные с элементом управления. Те свойства, которые вы указали в качестве отображаемого элемента valuemember, не могут быть скрыты. Это потому, что свойства определены как строка. Таким образом, во время разработки нет связи между элементом управления и фактическим свойством, но во время выполнения есть. Я не знаю, как объяснить это лучше; но вот код:

// 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;

Надеюсь, это решит вашу проблему. Если нет, дайте мне знать.

0 голосов
/ 09 апреля 2010

Нам нужно было что-то подобное, и мы попробовали bitHelmet . Он предоставляет предопределенные исключения для определенных объектов, которые, как известно, доступны по имени для платформы, например, Web.UI.Page Потомки. Отлично работает с веб-приложениями.

0 голосов
/ 01 апреля 2010

Для asp.net я не знаю быстрого выхода. Самый быстрый способ, который я нашел, это функция защиты кода Secure Team. Он покидает интерфейс, но зашифровывает все иль и затрудняет кому-то обратное.

Asp.net сложен из-за всех динамических разрешений и отражений, используемых после того, как вы начинаете изменять названия вещей, он становится хрупким и нуждается в еще одном раунде тестирования, чтобы убедиться, что все загружается и ничего не ломается.

0 голосов
/ 31 марта 2010

Я никогда не использовал версию сообщества Dotfuscator, но попробую посмотреть, можно ли переименовать только закрытые типы, переменные. Это должно сделать это труднее увидеть. IMO, большинство Обфускаторов имеют проблемы, и когда вы обнаружите ошибку, они хотят, чтобы вы отправили свой код, чтобы они могли решить проблему. Я обнаружил проблемы с большинством коммерческих версий, но, возможно, они стали лучше за последние пару лет ...

...