Собственно интересует вопрос реальной защиты от взлома.NET приложений. Ваше мнение. Стал вопрос защиты и случайно наткнулся на вот такую вот статью.
Получается что.NET программы взломать проще некуда. И хваленные обфускаторы в большинстве случаев не помогают, хотя стоят не дешево. Может кто-то знает действенные способы защиты или эффективные обфускторы?
Интересует также мнение по поводу обфускатора Dotfuscator. Насколько он хорош в защите?
Коментар порушує правила спільноти і видалений модераторами.
ILProtector protects your .NET code against reverse engineering, decompiling and modifying. ILProtector transforms Intermediate Language (MSIL) code into a Virtual Machine (“VM”) specific form that is not recognized by disassemblers and decompilers such as IL DASM or .NET Reflector.
Взламати теж можна, але не так прямолінійно як з без захисту.
Ну, я такого не стверджував.Зламати можна усе що завгодно.Як на мене, це не найгірший quick and dirty спосіб.Якщо, наприклад, купити дорогий комерційний обфускатор накладно по, скажімо, фінансовим причинам, то такий прийом підійде.З допомогою того ж Managed C++ не буде особливих проблем із використанням такої native dll.Ну я в целом согласен, использование нативной ДЛЛ как одна из мер комплексного подхода не есть плохо, даже хорошо
Просто по моему мнению, обфускация (желательно хорошый, без меток всяких), упаковщик, шифрование, генерация лицензионного или ключа продукта на основе алгоритмов с открытым ключем, проверка StrongName (PublicToken) не только встроенная, но и вручную в обфусцированом коде + если приложение клиент/серверное и сервер где-то в интернете проверка StrongName (PublicToken) сборок с его стороны, возможно использование блоее продвинутых мер в проверке целостности сборок, — является более эффективным или достаточно эффективным подходом без привлечения нативной сборки. А вот если на нативную сборку наворотить какую нибудь защиту с использованием драйвера или чего-то еще, тогда это совершенно другой разговор
Но у меня вопрос почему Вы думете что найти место в ассемблерном коде сложнее и заменить один опкод проверки на другой в ассемблерном коде сложнее чем в MSIL после обфускации
Ну, я такого не стверджував.Зламати можна усе що завгодно.Як на мене, це не найгірший quick and dirty спосіб.Якщо, наприклад, купити дорогий комерційний обфускатор накладно по, скажімо, фінансовим причинам, то такий прийом підійде.З допомогою того ж Managed C++ не буде особливих проблем із використанням такої native dll.
Якщо питання захисту стоїть критично, то чому б не написати алгоритм у native dll, і потім успішно викликати її функції з.NET ассемблі через P/Invoke?Можно, сделать это не сложно. Но у меня вопрос почему Вы думете что найти место в ассемблерном коде сложнее и заменить один опкод проверки на другой в ассемблерном коде сложнее чем в MSIL после обфускации. Методы практически те же. Там в статье в начале поста это можно увидеть. По моему мнению использовать нативную ДЛЛ неэфективно, так как это требует большых затрат времени и единственное что приэтом мы получаем это возможность запретить открывать код защиты через рефлектор. Правда возможно для нативных executables есть более продвинутые способы или утилиты для защиты, например что-то на уровне драйвера.
Есть определенный список мер для.NET при применение которых в комплесе можно получить приемлимую защиту. Вот только все самому не сделать придется использовать утилиты от 3х сторон. И нужно быть увереным что достаточно дорогие утилиты себя оправдывают
Якщо питання захисту стоїть критично, то чому б не написати алгоритм у native dll, і потім успішно викликати її функції з.NET ассемблі через P/Invoke?
Спасибо за ссылку.
P.S. У нас этот топик немного обсуждался.
Видимо тут у нас взгляд на.НЕТ глазами шароварщика. Мелкие поделки, работающие 15 дней, а потом просящие денег за продолжение. Напишешь такую на C#, а ее за 15 минут пересоберут уже без траел-периода.
А що ви «шифруєте» в «десктопах»? Геніальні алгоритми, контроли?)
.NET — это вклад Microsoft в сообщество opensource:). Взломать можно как нативную программу так и net-сборку, но вот изучить работу алгоритмов net-сборок намного проще и с этим ничего не поделаешь. Хочется писать тормознутые некроссплатформенные плохонезащищённые решения — тогда твой выбор net. Это нормально для серверов, но совершенно недопустимо для десктопов. Вот почему net-приложения на десктопах не приживаются.
2Native: Каждый кулик хвалит свое..., но даже с учетом этого вы не в теме.НЕТ раз такое утверждаете (на всяк случай — 8 лет на плюсах+3 на.НЕТ). Спор бессмысленен.
Я смотрю ещё «эксперты» подтянулись.
Вот уважаемый эксперт native тогда лучше расскажите нам наконец по теме по поводу защиты сборок. Ведь какая разница где будет приложение на сервере у пользователя или декстопоное. Все равно ведь нужно чтобы его купили, если оно на freeware
Круче выражения «C# для серверов, C++ для UI» будет только «VBA для трехмерных игр»
Я смотрю ещё «эксперты» подтянулись. Уж лучше разводить холивар, чем писать про ngen ничего в нём не понимая. Холивар хоть заставляет задуматься, а всё ли человек делает правильно. У каждого языка и технологии есть своя область применения. Если это понимать тогда не возникнет странных вопросов как же защитить программу на C# или Python. Используя.NET и WPF AutoCad ограничивает себя только Windows и теряет пользователей Linux и Mac OS X. Много ли компаний могут пойти на такой бездумный шаг?
Более бредовой мысли я не слышал еще...Действительно глупости. Вы видимо просто не работали с WPF/WinForms или пытаетесь таким офтопиком развести тут холивар. Давайте заведем отдельную тему для этого.
Вы хотите сказать, что WPF придуман тоже только для серверной стороны? или может быть WinForms тоже используют только на серверах?Если бы Вы включили мозг, то возможно моя мысль не показалась Вам столь бредовой. WPF, WinForms, Swing и ещё можно перечислить десяток мёртворождённых технологий, процент проектов на которых ничтожно мал и можно сказать что их НЕ ИСПОЛЬЗУЮТ на десктопах. C# и Java это языки именно для серверной стороны и в ближайшие годы ничего не изменится
Более того наведу пример — это AutoCad 2009. То что технология молодая и возможно стоит дождаться WPF4 не говорит о том что на ней не пишут десктоп приложений
native эпическая по глупости мысль. вин формс не используется? впф нет? знанете ли, сильверлайт — кусок впф, и код не на сервере ни разу. Вы бы думали вначале, чем говорить
Более бредовой мысли я не слышал еще...Вы хотите сказать, что WPF придуман тоже только для серверной стороны? или может быть WinForms тоже используют только на серверах?
Если бы Вы включили мозг, то возможно моя мысль не показалась Вам столь бредовой. WPF, WinForms, Swing и ещё можно перечислить десяток мёртворождённых технологий, процент проектов на которых ничтожно мал и можно сказать что их НЕ ИСПОЛЬЗУЮТ на десктопах. C# и Java это языки именно для серверной стороны и в ближайшие годы ничего не изменится.
Да ngen вообще не используется для защиты, просто народ заблуждался, нужно было описать.Regfor ngen не спасение. сборка все равно нужна будет — отсюда вывод — ниче не секьюрно в этом мире:)
Кстати кто что думает по поводу упаквщиков для.NET? Говорят например Themida неплохая.
Regfor ngen не спасение. сборка все равно нужна будет — отсюда вывод — ниче не секьюрно в этом мире:)
Машинний код потребує метаданих, CLR?
P.S. офтопік
Угум и еще как. Читай Рихтера. Зачем? для целей рефлексии и сериализации, возможно еще для каких то. В любом случае сборки после ngen попадают в C: \Windows\NativeImages_... И запустить их напрямую не получится. Поэтому при нген нужно чтобы была на компе у пользователя IL сборка, если есть ngen сборка то это ускоряет запуск приложения так как JIT компиляция не происходит.
По поводу ngen. Насколько я знаю он компилирует IL в машинный код, но проблема в том что во время выполнения CLR нужен доступ к метаданным, и не важно с ngen-сборкой или нет, а значить сборки должны быть на машине. т.е. на машине имеем нгенг сборку и нормальну IL сборку. Так что нгенгом как и sn.exe и прочими фишками дотНет собрки не защитить
Более бредовой мысли я не слышал еще....net используется для серваков (код которых не видно), а desktop-приложения лучше писать на C++ и не будет таких проблем с защитой.
Топикстартеру — существует тул, который называется ngen. Он должен компилировать в нативный код машины, на которой запущен. Сам им никогда не пользовался и сказать что-либо конкретное не могу, но думаю это может быть решением проблемы секурности.
Рефлектор не пройдет, другой дизасм прокатит. Система ж должна ИЛ считать и перевести в понятный для компьютера код. Так почему не пользоваться её методами? Так что, код все равно не заныкаеш:) разве что исковеркаеш.
.net используется для серваков (код которых не видно), а desktop-приложения лучше писать на C++ и не будет таких проблем с защитой.
Дак рефлектор в любом случае обойдет защиту
В.NET можно открыть любую библиотеку используя рефлектор — причем вы получите абсолютно весь код из библиотеки.Ну это не совсем так, продвинутые обфускаторы или в сочетании с упаковщиками (и я не говорю про Dotfuscator Community Edition) позволяют сделать так что сборка рефлектором не откроется. Но это не проблема для взлома. Смотрите статью что я указал. Скорее то что сборка не откроется рефлектором просто отсечет часть людей которые хотят туда посмотреть.
Естественно все можно взломать и обфускацию с запутыванием логики и шифрование. Но важен более или менее эффективный способ защиты. Тем более защитить все абсолютно невозможно. Но если взлом стоит 1, 5$, а лицензия 1$ тогда нет смысла ломать (но я не про то какой нужно ставить цену на лицензию)
Примерение dotfuscator — спасает косвенно, все что он делает — меняет название переменных, классов и т.д. на рандомные значения, но библиотеку в конечном итоге можно также открыть как и раньше, разве что код будет не читабельный для человека.
Дак рефлектор в любом случае обойдет защиту, ибо ИЛ. Дотфускатор просто поможет тебе сделать код более сложным для понимания. + обфускацию нельзя использовать с интерфейсами...
Рома Фиалковский
Bogdan Verbenets
Ivan Voyager
Regfor
Олександр Краковецький
Sergii Voloshyn
Ruslan Mogilevskiy
Andy Warhol
35 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів