Как известно трудоемкость вскрытия откомпилированного в машинные коды exeшника несопоставима и с получением исходных кодов NET-сборки. Необязательно восстанавливать сборку до исходных кодов. MSIL достаточно высокоуровневый язык по сравнению с ассемблером.
Нечасто, но иногда в программах требуется обеспечтить секретность небольшого количества данных или кода. Типичные примеры:
1)Shareware;
2)Клиент для БД, в котором нельзя использовать Windows-аутенификацию, а требуется подключиться к БД под своей учетной записью;
3)Trial-ограниченное по времени или другим способом ПО;
Может я ошибаюсь, но в NET изменить кусочек кода и откомпилировать программу несравнимо проще чем в трдиционных программах. Как с этим бороться?
Мне как-то предлагали использовать шифрование например того же пароля, но вызывать функцию шифрования код должен с какими-то параметрами, а в Anakrino это все как на ладони. Можно ли использовать контейнеры Crypto API так, чтобы обеспечить хоть какую-то зашиту?
Дают ли программы-обфускаторы какую-то гаранитию защиты?
И вообще, чем по возможностям отличаетесь вы как программист, написавший программу, от человака вскрывшего ваш код?
Тем не менее начинают выпускаться и компоненты под NET от того же ComponentOne и Infragistics. Как интересно там обеспечивается триальность сборок ?
Заранее благодарен.

VM>Дают ли программы-обфускаторы какую-то гаранитию защиты?

Я читал описание одной такой программы. Её урезанную версию обещают вставить в VS2003. У них остроумный подход: переименовать как можно большее количество свойств, типов, методов и др. метаданных в однобуквенные. Причем, желательно все одной и той же буквой. Сам можешь представить, какой это подлом

Кроме того, можно запрашивать пароль для расшифровки основной программы непосредственно у пользователя.

Здравствуйте, VinMike, Вы писали:

VM>Нечасто, но иногда в программах требуется обеспечтить секретность небольшого количества данных или кода.
Вообще-то часто, ибо любой алгоритм может быть Intellectual Property. Так что задача вполне хорошая.
Давайте порешаем. Задачи:
1. Не допустить изменения кода Assembly (например, проверки на истечение Trial period)
2. Не допустить или усложнить получения исходного кода Assembly

Первая задача в первом приближении решается просто — подписываем Assembly и тогда мы сможем лишь дизассемблировать и собрать её обратно, но подписать не сможем (нам неизвестен private key). Поскольку для подписанной assembly мы можем получить public key, то осталось лишь использовать public key исполняемой assembly для расшифровки важных данных. Сломать это можно, но уже сложнее, нужно запомнить где-то предыдущий public key, подписать своим ключом и подменить код, который получает public key для дешифрации. Распространять такое чудо в составе вашего продукта вы уже не можете (подпись не та, поэтому легко понять, что вы его сломали), но использовать in-house все еще можно. Для разарботчиков компонент этого вполне достаточно.

Чтобы избавиться от анакрины и других аналогичных инструментов, нужно изменить IL код, чтобы он не подходил под шаблоны, генерируемые csc. Все эти "дизшарперы" работают именно так — они берут IL-код и пытаются по шаблону найти код на С# который сгенерил такой IL. Если хотя бы перемешать инструкции (сохранив смысл, конечно), то дизшарпер уже не сможет выполнить свою задачу и вы оставите крэкера один на один с IL-кодом. Что уже неплохо. Собственно, это одно из действий, которые выполнять обфускаторы. Кроме того они могут менять private и internal идентификаторы на, например, GUID или плясать еще и с другими бубнами, но перемешивание IL-кода всё-таки основное.

Еще возможность — выносить критические вещи в unmanaged код. Это чревато разными боками, но ставит нас на одну ступеньку по защищенности кода с не-.NET разработчиками. Чего хотите, того и вертите. Помните только, что кто-нибудь может подменить вашу DLL, поэтому стоит проверять who-is-who с обоих сторон. Вобщем, понятно, что сломать можно почти всё, важно лишь сделать это довольно сложным.

Здравствуйте, mihailik, Вы писали:

M>Я читал описание одной такой программы. Её урезанную версию обещают вставить в VS2003. У них остроумный подход: переименовать как можно большее количество свойств, типов, методов и др. метаданных в однобуквенные. Причем, желательно все одной и той же буквой. Сам можешь представить, какой это подлом
Если методы а1,а2,а3, то никакой это не подлом, если покопаться то наверняка можно даже будет спокойно откомпилировать такую сборку вскрыа ее и изменив.

M>Кроме того, можно запрашивать пароль для расшифровки основной программы непосредственно у пользователя.
Каждый раз при запуске . Не смахивает ли это на serial.txt?

Здравствуйте, orangy

Спасибо за столь развернутый ответ.
Интересно в Яве такие же методы борьбы с декомпиляцией?

PS. первый раз вижу, чтоб за вопрос ставили очки

Здравствуйте, orangy, Вы писали:

O>Первая задача в первом приближении решается просто — подписываем Assembly и тогда мы сможем лишь дизассемблировать и собрать её обратно, но подписать не сможем (нам неизвестен private key). Поскольку для подписанной assembly мы можем получить public key, то осталось лишь использовать public key исполняемой assembly для расшифровки важных данных. Сломать это можно, но уже сложнее, нужно запомнить где-то предыдущий public key, подписать своим ключом и подменить код, который получает public key для дешифрации. Распространять такое чудо в составе вашего продукта вы уже не можете (подпись не та, поэтому легко понять, что вы его сломали), но использовать in-house все еще можно. Для разарботчиков компонент этого вполне достаточно.

Берем у сборки public ключ и дешифруем. А где в дальнейшем используется private ключ, кроме начальной шифрации?

Можно ли сделать так? Данные записать каким то алгоритмом, а расшифровку дать клиенту, но уже в native коде (написанном например на сях).

Здравствуйте, MikaRSDN Soukhov, Вы писали:


MS>Можно ли сделать так? Данные записать каким то алгоритмом, а расшифровку дать клиенту, но уже в native коде (написанном например на сях).

Да... Что то я не подумал... Так же можно и в целях злонаправленных взять этот же самый дешифратор и использовать его.

Ммм... Интересно, а можно ли сделать как в старых добрых С :
1) вставить посередине кода много NOP
2) в это место загружать код (который сам по себе закодирован) и прыгать в него
3) подвергать кросс-проверке файл с куском закодированного кода из основной проги и из этого раскодированного кода проверять целостность основного файла. Проверять можно по CRC например.

Кто-нибудь пробовал такое делать, ну или что-то подобное ?

Здравствуйте, VinMike, Вы писали:

[snip]

Я еще не знаю ни NET ни C#, только вот книжку читаю.
Идею одну, наверняка глупую, выскажу. Ногами не бейте.

Прочитал о динамическом создании сборок, если так, то
можно динамически генерировать сборку с некоторыми классами
из файла данных в котором зашифрованы IL коды этих
классов и доп.информация для воссоздания.
Расшифровывается в процессе работы на основе рег.кода
(или lic файла или это и есть lic файл).
Важно, чтобы классы из динамически сгенерированной сборки
реально участововали в коде потом, а не просто — да/нет
о зарегистрированности.
По крайней мере вскрыть не имея хоть одного "реального" рег.
кода почти нереально. Дизассемблирование тоже не даст полной
картины.

Ладно все,все, я уже вижу как все ржут

Олег

Здравствуйте, OlegSv2, Вы писали:

OS>Ладно все,все, я уже вижу как все ржут

Да нет, почему? Нормальная идея.

Здравствуйте, OlegSv2, Вы писали:

[snip]

OS>Прочитал о динамическом создании сборок, если так, то
OS>можно динамически генерировать сборку с некоторыми классами
OS>из файла данных в котором зашифрованы IL коды этих
OS>классов и доп.информация для воссоздания.
OS>Расшифровывается в процессе работы на основе рег.кода
OS>(или lic файла или это и есть lic файл).
OS>Важно, чтобы классы из динамически сгенерированной сборки
OS>реально участововали в коде потом, а не просто — да/нет
OS>о зарегистрированности.
OS>По крайней мере вскрыть не имея хоть одного "реального" рег.
OS>кода почти нереально. Дизассемблирование тоже не даст полной
OS>картины.

Не обязательно конструировать сборки runtime.
Достаточно сборки загружать из потока, а в поток загружать, дешифрируя из файла.

При отсутствии открытого ключа, даже при известном алгоритме — ничего не получиться.

M>>Я читал описание одной такой программы. Её урезанную версию обещают вставить в VS2003. У них остроумный подход: переименовать как можно большее количество свойств, типов, методов и др. метаданных в однобуквенные. Причем, желательно все одной и той же буквой. Сам можешь представить, какой это подлом
VM>Если методы а1,а2,а3, то никакой это не подлом, если покопаться то наверняка можно даже будет спокойно откомпилировать такую сборку вскрыа ее и изменив.

Во-первых, в C# и в ILASM разные ограничения на пространства имён. Например, в ILASM можно объявить и метод, и поле с названием "a". Во-вторых, ILASM разрешает существование двух методов, отличающихся только типом результата, а в C# перегрузка может быть только по параметрам.

Так что перекомпилировать через anakrino/C# не получится. Через ILDASM/ILASM, конечно, получится.

Во-вторых, представь себе такой код:

class a
{
    b a(c a)
    {
        if( a.a(12) )
            return null;
        else
            return new b(a.a);
    }   
}

Разве не приятно будет в таком покопаться?
По статистике тех ребят, у них в среднем 70% идентификаторов преобразовываются в "a".

M>>Кроме того, можно запрашивать пароль для расшифровки основной программы непосредственно у пользователя.
VM>Каждый раз при запуске . Не смахивает ли это на serial.txt?

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

Если ещё вступительный расшифровывающий код реализовать через native, и ключ перед использованием как-нибудь трансформировать там, будет прилично напрягать хакеров.

Здравствуйте, VinMike, Вы писали:
VM>И вообще, чем по возможностям отличаетесь вы как программист, написавший программу, от человака вскрывшего ваш код?

Да ничем одни хакеры(в правельном понимании) другие крекеры...