Защита приложения .NET

Здраствуй НАРОД!!!

Возникла проблема по сабжу! Существует ли что-нить для защиты приложения .NET, типа ASPack ??

Цитата Chess64, 04.07.03, 09:18:12

Здраствуй НАРОД!!!
Возникла проблема по сабжу! Существует ли что-нить для защиты приложения .NET, типа ASPack ??

Обфускация. Защита IL-кода от дизассемблирования и взлома

Цитата kl, 04.07.03, 10:59:48

Обфускация. Защита IL-кода от дизассемблирования и взлома

Спасибо kl! Дошел я поисковикам до данной статьи, почитал, зашел на райд нет, скачал триал, а он глюкавый. Скачал Саламандер, он вроде как что-то делает, но на том же сайте существует дизассем (А кто уверн в том что у них нет анти-обфуксатора?). Скачал XeonCode он треба Фреймворк 1.1. Распологаешь ли ты нормальными линками, если "да" - кинь в меня ими "намылеными", PLZ !!!

Возможен ли какой-нить другой путь для решения данной проблемы ??
- вставка кода другого языка ?
- вынос в DLL ?
- Ваши варианты ...

Цитата Chess64, 04.07.03, 11:31:27

Возможен ли какой-нить другой путь для решения данной проблемы ??
- вставка кода другого языка ?
- вынос в DLL ?
- Ваши варианты ...

Самый надежный путь (имхо, т.к. я никогда не защищал свои сборки) - вынос наиболее важных частей в unmanaged dll. А потом интероп в зубы и вперед

Цитата kl, 04.07.03, 11:40:27

Самый надежный путь (имхо, т.к. я никогда не защищал свои сборки) - вынос наиболее важных частей в unmanaged dll. А потом интероп в зубы и вперед

Но ведь тот-же самый Reflect вскрывает эти-же dll-ки как семечки !?! Как быть в таком случае ?

В MSVS.net 2003 есть dotFuscator (пробная версия)

Всем здрасте!
Полазил по Нету и нашел кучу ссылок на обфускаторы. Вот лишь некотрые из них:
- .NET Reflector
- Salamander
- DotFuscator
- Anakrino
- XenoCode
На этой страничке <a href="http://www.wasm.ru/toollist.php?list=19"> можно найти и другие </a>

Но вопрос - НЕУЖЕЛИ  РАЗРАБОТЧИКИ НЕ СДЕЛАЛИ АНТИ ОБФУКСАТОРОВ ??

Цитата Chess64, 04.07.03, 15:26:08

Но ведь тот-же самый Reflect вскрывает эти-же dll-ки как семечки !?! Как быть в таком случае ?

Чего?? Ну открой мне kernel32.dll

Я имел в виду NET-ские DLL! Разве я не прав ?

Цитата Chess64, 07.07.03, 08:41:38

Я имел в виду NET-ские DLL! Разве я не прав ?

Я-то понял что ты имел ввиду, а вот ты нет. Я же ясно написал unmanaged dll! В них вообще нет il-кода и кроме как обычными средствами вроде IDA их не возьмешь. За безопасность заплатишь кроссплатформенностью и еще кучей всего.

Тогда можно вернуться к старому доброму МФЦ+ВижуалЦ++.
Если продукт стоящий, то его купят. Тут проблема больше в том, что могут просто стыбздить прогу. Юзаем обфускаторы, хотя кому надо всеравно все разберут по полочкам. Interop Win функций в .НЕТе юзают только в крайних случаях. РАскидываться им направо и налево имхо не стОит.

Цитата Technos, 07.07.03, 11:24:17

Тогда можно вернуться к старому доброму МФЦ+ВижуалЦ++.
Если продукт стоящий, то его купят. Тут проблема больше в том, что могут просто стыбздить прогу. Юзаем обфускаторы, хотя кому надо всеравно все разберут по полочкам. Interop Win функций в .НЕТе юзают только в крайних случаях. РАскидываться им направо и налево имхо не стОит.

Конечно не стоит. Я на самом деле имел ввиду ситуации когда реализуется алгоритм имеющий реальную интеллектуальную ценность. Иногда его имеет смысл вынести в отдельную dll. Кстати так часто поступают и из соображений производительности.

Насчет производилельности, можно пример или цифры? Насколько это выгодно?

Цитата Technos, 07.07.03, 11:44:53

Насчет производилельности, можно пример или цифры? Насколько это выгодно?

Знаешь, вопрос на самом деле открытый. Основной проигрыш в скорости наблюдается из-за боксинга и постоянной рантаймной полиморфности, т.к. отсутствуют шаблоны. Также не все ОК с исключениями и совсем уж плохо дело обстоит с GDI+. Но с полиморфностью всроде станет получше, т.к. шаблоны нам обещают, правда реализовывать их надо-то на уровне Il, а как это делать слегка неясно (хотя может я уже отстал от жизни).
В то же время, вполне логичными звучат доводы в пользу того, что потенциально managed code может быть быстрее unmamanaged на конкретной платформе. Почему? Дело в том, что грамотно реализованный jit-компилятор в принципе может перекомпилировать отдельные участки кода во время работы программы на основании накопленной статистики. Например определить что у нас PIV и использовать какие-нибудь SSE2. Но реально я таких примеров не встречал пока. К тому же не стоит забывать что есть еще путь Sun с их процессором Magic, ктр имеет аппаратную поддержку byte-code. Это тоже довод. Так что вопрос "кто сегодня самый шустрый" не столь прост как кажется. К сожалению сейчас не могу привести реальные ссылки на тесты, если найду - напишу.
P.S. Просьба ко всем. Если тема производительности заинтересовала НЕ ПРОДОЛЖАЙТЕ этот топик, заведите новый! Свой пост я перемещу туда.