Я должен быть взволнован по поводу запутывания моего кода.NET? [закрытый]
Предполагая, что он встроен Tomcat,
. В вашем pom.xml
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-jasper</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
</dependency>
встроенном ядре Tomcat необходимо иметь поддержку JSP-рендеринга.
10 ответов
Я бы не слишком волновался об этом. Я бы предпочел сосредоточиться на выпуске отличного продукта, создании хорошей базы пользователей и правильном обращении с вашими клиентами, чем беспокоиться о минимальном проценте пользователей, заинтересованных в краже вашего кода или просмотре исходного кода.
Помните, путаница не является шифрованием. По моему скромному мнению, если кто-то будет чувствовать значение в инженерном анализе Вашего кода, они сделают это. Это правда для управляемого кода или собственного кода, запутываемого или нет. Несомненно, путаница удерживает случайного наблюдателя, но Вашему бизнесу на самом деле угрожают такие люди? Каждый метод путаницы.NET, который я видел, делает Вашу жизнь как разработчика тяжелее.
существуют сервисы, которые предлагают истинное шифрование, такое как SLPS от Microsoft. См. http://www.microsoft.com/slps/default.aspx
В настоящее время мы скрываем всю нашу продукцию, даже несмотря на то, что мы небольшая компания, которая продает специализированное программное обеспечение небольшому количеству клиентов.
Мы приняли это решение по одной простой причине - мы обнаружили, что недовольный бывший сотрудник активно обращался к нашим клиентам, запрашивая двоичные файлы, - было некоторое беспокойство, что он намеревался перепроектировать новые функции, чтобы предложить конкурирующую функциональность.
Конечно, он все еще может сделать это, если он использует программное обеспечение, но нет никаких причин, чтобы сделать его легким для него.
Никакая новая путаница, но много приемов компилятора с тех пор 1.1
, Например, каждый раз, когда Вы используете анонимный тип, Вы получаете IL, который компилирует назад с довольно неясным именем. Каждый раз, когда Вы используете урожай, Вы получаете совершенно новый класс, который реализует и IEnumerable и IEnumerator (умная оптимизация, нечитабельный код). Каждый раз, когда Вы используете анонимного делегата, Вы получаете новый метод с именем, это недопустимо на каждом.Net языке, о котором я знаю, но это прекрасно в IL.
@Rob Cooper
, имевший некоторые обсуждения с моим менеджером на работе, он сказал, что не запутывает, но делает NGEN на установке, по-видимому, которого должно быть достаточно для остановки Отражателя, работающего над блоками, но я понятия не имею, верно ли это и до какой степени, поэтому не берите его в качестве евангелия:)
Это не предлагает вида защиты от дизассемблирования. Сначала я предполагаю, что его довольно возможное извлекает необработанные файлы из любого пакета установки как MSI или файл CAB.
, Но что еще более важно, Ngen работает на клиентской машине после того, как блок был установлен. Ngen просто вынуждает блок скомпилировать теперь вместо более позднего использования JIT. Исходный блок остается и не изменяется, и это должно остаться, потому что Ngen не мог бы быть в состоянии скомпилировать весь блок.
Ngen для производительности, не безопасности, и не делает ничего, чтобы предотвратить дизассемблирование или сделать его даже немного более трудным.
легкий для меня - если необходимо защитить интеллектуальную собственность - obfuicate - если не не делают.
Легкий сделать с правильными инструментами.
Я думаю, что в какой-то степени мы ВСЕ должны беспокоиться о нашей ИС:)
Хороший вопрос, хотя я хочу узнать о нем больше (сейчас я делаю , а не запутываю) .
Проведя некоторые обсуждения с моим менеджером на работе, он сказал, что не запутывает, а выполняет NGEN при установке, очевидно, этого должно быть достаточно, чтобы Reflector не работал на ваших сборках, но я понятия не имею, верно ли это и до какой степени, поэтому, пожалуйста, не принимайте это как Евангелие:)
Хороший вопрос :) +1
Мы не используем путаницу для "не общедоступные" приложения, но мы используем ее для общедоступных доступных приложений. Запутываемое приложение содержит много очень сложного кода, который занял нам непомерное количество времени для записи, и это - причина, которые позволяют мне думать, что путаница - необходимость - по крайней мере, в этом случае.
Obsfucation ограничен в своей эффективности, он может держать случайного парня подальше. Самым эффективным омрачением является предоставление пользователю наименьшего количества кода. Если можете, сделайте так, чтобы ваше приложение сильно зависело от толстого сервера.
Согласен, большинство людей, которые знают, как кодировать даже немного, не нужно украсть ваш код!