Защищать .NET-код от обратного инжиниринга?

Question

Обфускация - это один из способов, но он не может защитить от нарушения безопасности приложения. Как убедиться в том, что приложение не подделано, и как убедиться, что механизм регистрации не может быть восстановлен?

Также возможно преобразовать приложение C # в собственный код, и Xenocode слишком дорогой.

C # предоставляет множество функций и является идеальным языком для моего кода, поэтому о повторной записи всей базы кода в C ++ не может быть и речи.

Безопасные сертификаты можно легко удалить из подписанных сборок в .NET.

Answer 1

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

Некоторые коммерческие DRM-решения довольно приличны, но они взламывают каждую тройную игру AAA с помощью пользовательских DRM-решений все время в течение часов (или дней). Только внедрение совершенно нового решения DRM - иногда - задерживает неизбежное, возможно, на пару недель.

Получение максимальной отдачи от DRM стоит больших затрат времени и денег и может легко нанести ущерб производительности, надежности, совместимости / мобильности и отношениям с клиентами в целом. Либо придерживайтесь приличного коммерческого DRM, не пытаясь быть слишком умным, и нести свои (меньшие) убытки, либо просто полностью об этом забыть ...

Один пример решения DRM, которое вырыло собственную (коммерческую) могилу: http://en.wikipedia.org/wiki/StarForce

Answer 2

Я также высказал некоторые соображения относительно безопасности взлома в своем дизайне и хочу добавить их, так как некоторые из них, кажется, не упомянуты:

У меня в приложении есть скрипт-интерфейс. Чтобы убедиться, что сценарии могут вызывать только те методы, которые предназначены для вызова (python) -скриптами, у меня есть атрибут scriptvisibilityattribute и System.Dynamic.DynamicMetaObjectProvider, который распознает эти атрибуты.

Лицензии используют открытый / закрытый ключ.

ViewModels необходимо разблокировать, предоставив пароль для функции разблокировки.

CoreRoutines могут быть реализованы на ключе. (Есть ключи, которые поддерживают это)

Большое решение, как обертки, не планировалось.

Конечно, это приложение для работы со сценариями / viewModel не делает невозможным разблокирование и вызов невидимых сценарием функций из кода, но делает его немного более сложным, как, например, со всеми, что связано с усилиями по предотвращению взлома.

Answer 3

Да, .NET двоичные файлы (EXE и DLL) могут быть легко декомпилированы почти до исходного кода. Проверьте инструмент .NET Reflector . Просто попробуйте против любого двоичного файла .NET. Наилучшим вариантом является обфускация файлов, они все еще могут быть декомпилированы .NET Reflector, но они создают нечитаемый беспорядок. Я не думаю, что хорошие обфускаторы будут бесплатными или дешевыми. Одним из них является Dotfuscator Community Edition, который поставляется с Visual Studio.

Answer 4

Согласно приведенному ниже вопросу в блоге Microsoft:

https://blogs.msdn.microsoft.com/amb/2011/05/27/how-to-prevent-ildasm-from-disassembling-my-net-code/

Как я могу предотвратить разборку сборки ILDASM?

.NET имеет атрибут с именем SuppressIldasmAttribute, который предотвращает разборку кода. Например, рассмотрим следующий код:

using System;
using System.Text;
using System.Runtime.CompilerServices;
[assembly: SuppressIldasmAttribute()]

namespace HelloWorld
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello world...");
        }
    }
}

Как видите, есть только два отличия:

1. Мы добавили System.Runtime.CompilerServices замедление пространства имен.

2. Мы добавили атрибут [assembly: SuppressIldasmAttribute()].

После сборки приложения в Visual Studio, когда мы пытаемся открыть полученный EXE-файл в ILDASM, теперь мы получаем следующее сообщение: