САБЖ.
Собственно я слышал что есть какие то утилиты которые защищают IL от чужих глаз, но не видел ... кто чего знает по этому поводу ? Пожелания, предложения ?

Мне кажется эта тема актуальной, и относится не только к клиентским приложениям, но и WEB Server - Side ...

Могу только сказать, что с точки зрения таких приложений как TestComplete и им подобных (имеются в виду программы для тестирования) приложение на .NET являются open project (то есть можно получить доступ ко всем методам и интерфейсам, не говоря уж о контролах).

_______________________
http://tester.com.ua - Сервер тестировщиков.

Цитата

приложение на .NET являются open project

Во, во ! Именно об этом я и говорил ... неужели нет ни чего чем можно от халявщиков защититься ? Взяли ILDasm ... и весь IL у тебя ... Правда еще IL надо изучить Хотя говорят, что чтобы использовать все прелести .NET надо программить на чистом IL ... это для любителей гимора ...

Значит так, есть шанс что Мелкософтовцы прольют свет на это дело, наше издательство выпустило книгу "Защищенный КОД", сейчас буду смотреть что в ней есть, если чего интересного найду, сообщу.

Для тех кто хотел бы купить, сообщаю что, книга появится в продаже в начале ноября.

"Защищенный КОД" это наверно Safe Code и ни чего общего с Software Protection не имеет, хотя как знать...

Спасибо мастерам, что откликнулись на существующий вопрос. А возник он совершено случайно. Создается проект на C# .NET - программисты довольны и уже готовы его сдать... тут одному из них попадается один из дизасмов для .NET (в данном случае .NET Reflector) и начался геморой. Всевозможные ухищерения спрятать нужную часть кода не удавались. А специальные дотфускаторы стоят от1000 $.
Вот поетому я спросил у народа, КАК защитить код .NET.

Кстати что за "Защищенный КОД" - о чем ? Возможно куплю.

( Проект так и не увидел свет!

Цитата

А специальные дотфускаторы стоят от1000 $.

скажи, плиз, какие? ни одного не видел.

>> cully
к примеру ThInstall его стоимость насколько я знаю составляет
лицензия на 1 юзверя = 749 $
лицензия на 2-х юзверей = 1199 $
лицензия на 5 юзверей = 2499 $
В оплату входит год суппорта и апргрейда.
Пойдет пример. Самое прикольное что буквально рядом продается антифускатор (правда цена вроде повыше)
Есть еще DotFuscator Standart and Professional (395 $ и 1495 $ соответственно).

Короче, книга как оказалось офигенная, просто обо всем (Это я про "Защищенный код") ...
На ней так же присутствует такая реккомендация:
"Обязательное чтение для сотрудников Microsoft"
И подпись - Билл Гейтс

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

Есть хороший нетфускатор от Remotesoft (http://www.remotesoft.com/) и совершенно бесплатный!

Что качается антифускаторов, ИМХО, такого невозможно сделать. Буду очень признателен, если Вы, уважаемый Chess64, расскажите мне принцип его работы.

NetSharp, интересно ...

Цитата

http://www.remotesoft.com/

... а он действительно защитит на 100% ?

На 100% ни что не может защитить. Но всё же защищает он хорошо.

NetSharp, а что именно делает анитфуксатор? Где об этом можно почитать поподробнее?

Не знаю. На мой взгляд антифускаторов вообще неаозможно сделать. Ведь принцип работы обычных обфускаторов заключается в том, что он меняет названия всех методов, переменных, пространств имен на другие произвольные имена (например на a, b, c, d,... или 1a, 2b, 3c,... или же на FDRTBHH, KIUYTDCF и т.д.). Следовательно, как программа сможет поменять эти имена на первоночальные, если первичные имена нигде не сохранились?

NetSharp, бред какой то ...

Почему бред? Все понятно.. Кстати я нашел еще один дотфускатор в перенговой сети Torrent. Бесплатный и с исходниками. Весит он 200 с небольшим метров. Когда скачаю - скажу что там.

NetSharp, ок.
На счет "бред", я просто этих технологий не знаю, по этому не буду корчить умника, лучше скажи где почитать об этом можно

Iz@top, важно только понимать, что в .NET сборке PE структура не в native коде, а в IL (managed) коде. И только при выполнении IL код компилируется уже в машинный. Такая структура PE очень удобна, но IL выше assembler кода, что делает дизассемблирование очень простым.

Статьи про обфускацию можно почитать здесь:
- Защита .Net продуктов от подглядывания
- Обфускация – есть такое слово
- Обзор 9Rays.Net Obfuscator
- Обфускация в .NET. Том I

Кстати, обфускатор от Remotesoft можете скачать здесь.

NetSharp, спасибо за информацию.

На сколько мне известно есть ILDASM именно для дизассемблирования .нет программ, и поставляется он с .нет фреймворк помоему, причем он разбирает код вплось до такого какие классы определены в программе, методы доступа к ним, сингнатуры методов, и так далее

Кстати Iz@top если у тебя есть доступ к книжкам прочти 1-ю главу книги "Программирование для .NET" Джеф Просиз - помоему, там про все это написано подробнее

MicroSoft ксати советует защищать исходный код с помощью утилит третьих фирм

Цитата

На сколько мне известно есть ILDASM именно для дизассемблирования .нет программ, и поставляется он с .нет фреймворк помоему, причем он разбирает код вплось до такого какие классы определены в программе, методы доступа к ним, сингнатуры методов, и так далее

Верно. Но это возможности только дизассемблера. Также в природе существуют декомпиляторы, которые managed код позволяют перевести в практически идентичный высокоуровневый код.

Цитата

Кстати Iz@top если у тебя есть доступ к книжкам прочти 1-ю главу книги "Программирование для .NET" Джеф Просиз - помоему, там про все это написано подробнее

А по моему нет точнее там как раз и сказано про третьих лиц, но ни чего про реализацию

А если посмотреть на всю эту .Net с другой стороны то получается что Микрософт сможет слёгкостью использовать разрабротки всё техже третьих фирм для своих целей! Ведь ЗАЩИТУ КОДА они так и не предоставили!

[offtop]
Sniper, скорее некие четвертые лица будут использовать наши разработки
[/offtop]

а если серьезно, то наша компания именно по этим причинам отказалась от использования .net жаль

Люди имеющие опыт применения обфускаторов на практике, пожалуйста, поделитесь впечатлениями. Какие грабли есть, где обфускация применима а где даёт\даст сбой?

Цитата

А если посмотреть на всю эту .Net с другой стороны то получается что Микрософт сможет слёгкостью использовать разрабротки всё техже третьих фирм для своих целей! Ведь ЗАЩИТУ КОДА они так и не предоставили!

Ни в коем случае. У Microsoft совершенно другая политика. Кроме того, Microsoft же выпустила книгу "Защищенный код" (Writing Secure Code).

Цитата

"Защищенный код" (Writing Secure Code).

А наше издательство перевело и с успехом продает эту книгу! Среди специалистов считается очень хорошей литературой. На обложке подпись Билла - "Обязательна для чтения сотрудникам Microsoft"

и когда же она появится в продаже?

Finkel
Вообщем-то эта книга продается уже с ноября 2003 года. Смотри в магазинах своего города. А так же www.ozon.ru & www.bolero.ru.

я тут случайно в темку заглянул.... дык dotfuscator в MS VC 2003 входит вроде ????

Микрософт теперь поддерживает Open Source

а есть холявная версия?(e-book)

Цитата(zeus @ 11.6.2004, 23:07)

dotfuscator в MS VC 2003 входит вроде

Входит, но есть на него многочисленные жалобы.

Можно подписывать бинарники. Матушка-криптография никогда не устареет.

Цитата

Можно подписывать бинарники

И что это даст?

Цитата(jfx @ 20.4.2005, 12:28)

Цитата Можно подписывать бинарники И что это даст?

Это защитит от сборку от возможности исправлять код в ней. В большинстве случаев этого достаточно.

Цитата

Это защитит сборку

"Это" не защитит сборку. Есть как минимум три способа обойти проверку StrongName:

1. В заголовке сборки обнулить длину PublicKey - это приведет просто к отключению проверкии вообще. sn -v assm.dll выдаст "assm.dll does not represent a strongly named assembly".
2. Разобрать сборку с помощью ildasm, в исходниках убрать секцию с PublicKey и собрать сборку вновь. Результат тот же что и в первом варианте.
3. Просто переподписать исправленную сборку новым ключом, предварительно заменив в сборке PublicKey на тот для которого известен PrivateKey.

Таким образом защита с помощью StrongName приравнивается к нулю. Ваши коментарии?

Цитата(jfx @ 21.4.2005, 10:28)

Таким образом защита с помощью StrongName приравнивается к нулю. Ваши коментарии?

No comments...

я и не говорил о 100% защите. Потому как предложенный тобой способ обхода знают многие, но не все. И плюс ко всему, этот вариант взлома тоже не 100%.

Цитата

тоже не 100%

да ну...

Еще есть XenoCode http://www.xenocode.com/setup.msi

Как пример, листинг исходника и декомпилированного кода: http://www.xenocode.com/Articles-Sample.aspx

Ужасьнах... чего он с кодом сделал!
Ну ничего... и его поломают.

смех и грех.. если прога ченить стоит, то $1000 на защиту это копейки, а иначе болтовня одна и защищать нечего...

Всё это похоже на триаду:
- новый розвод на деньги от Мелкософт собственной персоной
- возможность мелкософтовцам цапать проекты третьих сторон
- ну или новая работа для создателей протекторов и обфускаторов.

Погодите, люди. Если я не ошибаюсь, то ИЛДасм.єхє сможет показать код только public классов. А всё, что нужно спрятать, можно прятать в private... Или не так?

Цитата(Budda @ 23.10.2005, 05:24)

Или не так?

не так

mr.DUDAпроверил, точно private - не прячет код... хм, странно, а зачем сие сделано? В чём смысл? Я ещё понимаю, открывать код public-методов, или protected, но вот private... ?

По большому счету, обыный бинарник, сделанный любым компилятором, можно перевести в исфодный код (в автомате на Asm ), просто для .Net гораздо проще написать не просто дисасемблер, а именно декомпилятор
так что прятать код както специально, или коробить его, я особого смысла не вижу (тем более платить за енто огромные деньги). Исли комуто понравиться какаято часть твоего кода (имеется в виду, какаято функция, или метод ее реализации), то всеравно он сможет ее вытянуть

private нужен не для сокрытия кода, а для сокрытия реализации. а то зачем нужен ООП? ведь в этом и смысл - инкапсуляция..

Run-time error, да, понимаю. А то что код можно легко смотреть, то это и есть косвенное следствие наличия манифестов в сборках, верно?

Если есть возможность, запусти, плиз, аську. Я там к тебе постучался... хочу спросить кое-чего...

Люди, нет лучшей обфускации, чем ручная обфускация критических участков кода.
.NET позволяет динамически генерировать код, загружать сборки непосредственно с памяти, использовать вместо стандартных вызовов функции CreateInstance, InvokeMethod и т.д. и т.п.

Обфускация в .NET. Том I
Обфускация Том II

Цитата

.NET позволяет динамически генерировать код

Это как?

Цитата(VisualProgrammerNET @ 21.12.2005, 12:38)

Это как?

неймспейс System.Reflection.Emit
а также Microsoft.CSharp

Цитата(mr @ 21.12.2005, 16:05)

неймспейс System.Reflection.Emit а также Microsoft.CSharp

А также System.CodeDom

Теперь есть возможность использования Unicode-символов в именах переменных, методов и функций. Это может затруднить задачу деобфускации сборок.

Цитата(Lord @ 21.12.2005, 20:30)

Теперь есть возможность использования Unicode-символов в именах переменных, методов и функций.

Поправьте меня, если я не прав: разве до сих пор нельзя было использовать юникод в вышеперечисленных ситуациях? Например, я могу создать класс с именем Класс1 в студии 2003.
Добавлено @ 21:39
З.Ы. а чем метод отличается от функции ?

Угу.

Код

class ПодиДогадайсяЧтоЯЗаКласс{ private ЕщеФигЗнаетЧтоЗаКласс СуперСекретноеПоле; void БлаБлаБла(int ?, int $){ while(true) int ¤ = ?* $; //ненужный метод для ухудшения понимания кода  } }

Это сообщение отредактировал(а) Run-time error - 21.12.2005, 21:47

mr.DUDA
Конечно, можно было;)
Просто именно сейчас на эту возможность обратила внимание общественность
Да и я честно говоря до появления VS 2005 этим не пользовался.

Процедуры и функции связываются с классом, они обеспечивают функциональность данных класса и называются методами класса. Главную роль в программной системе играют данные, а функции лишь служат данным.

Вот так;)

но как етим можно зашитить код от чужых глаз? не понемаю.
может кто обяснит.

У нас в конторе довольно долго обсуждались варианты защиты программного кода и в итоге был написан фрэймворк делающий примерно следующее:

1. После компиляции все модули системы пропускаются через encryptor, который читает сборки, получает тела функций, криптует их одним из алгоритмов шифрования и пишет обратно в сборку.
2. При запуске программы используем .NET Profiling Api позволяющий перед вызовом функции JIT компайлером получить тело метода, дешифровать его и "подсунуть" оригинальное тело метода.

Таким образом прочтение кода становится весьма сложной задачей т.к. дешифрованные данные доступны только в runtime, хотя имена классов и функций остаются видны.

Предвосхищая вопросы перфоманса могу сказать что он сильно зависит от алгоритмов шифрования, но практика показала что использование симметричных алгоритмов даёт приемлимый (для нашей системы) результат.

Хм, интересный способ, похоже на загрузчики Java. В Java это реализуется почти стандартно, а вот в .NET как? Исли можно пример или ссылки по теме.
Спасибо.

Почитать можно например здесь.

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

Вряд ли CLR позволит удалить из сборки таблицу метаданных  

Это был чисто теоретический вопрос    

это был чисто теоретический ответ   

Кто знает может это всё к лучшему...

сорсы дороже стоят, но в таком случае всем придется делать open-source проекты. 

Поднимаю тему опять


jfx, ты извини, но ты совсем не в курсе вопроса   
Сборку защищают для того, чтобы ее нельзя было подменить на другую  
Проверкой ключей и строгих имен заниматся прога (сборка) использующая защищенную сборку.
Если мы удалим publicKey из сборки, то прога будет ругаться на попытку подсунуть ей другую сборку вместо необходимой (защищенной ключем).
P.S. Повторяю еще раз: StrongName сборки нужно для защиты ее от подмены 
Если сделать хоть какое изменение в сборке мы теряем ее Строгое Имя. После этого все программы, которые используют защищенную сборку будут ругаться на измененную. 
P.P.S. Механизм подписывания сборок используется так же механизме предоставления прав сборке.
Например можно запретить неподписанным (ключем которомы мы доверям) сборкам доступ к реестру, диску С:  (можно вообще много чего запретить).
После этого если злоумышленник изменит код сборки, то он потеряет ее подпись, а следовательно и возможность навредить 

Почитал я 3-х летнюю дискусию, и возник вопрос рас уж так исторически вышло что всё можно дизасемблировать, а .нет можно ещё и декомпелировать, тогда КАК ЖЕ НАМ ПРОГРАМЕРАМ ПРИВЯЗЫВАТЬ НАШ ПРОДУКТ К ЖЕЛЕЗУ?

Ведь вся наша проверка видна декомпилятором и легко можно написать кейген используя наш код!!!

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

А что с етим в мире .нет?

Не забуддте про вопрос который набран ЗАГЛАВНЫМИ БУКВАМИ.

Rapalex, всё решается на самом деле очень просто. Есть такое слово: обфускация. И никакая декомпиляция не поможет 

Я когда-то устанавливал 9-Rays Obfuscator. Короче там была какая-то примочка, которая помимо обфускации что-то еще делала с бинарником, в результате чего сборку вообще нельзя было загрузить в любой декомпилятор. Они просто выпадают с ошибкой. Не только ILDasm, но и Reflector. Кстати сам 9-Rays Obfuscator именно этой фичей и защищен. 

А если хакер именно эту прогу и поломает? 
Может скомпилированную (и обфусцированную) прогу на .NET сжать каким-нибудь упаковщиком и обработать DotFix FakeSigner?
Да, и еще. Ведь при запуске проги на .NET управление получает вначале загрузчик, который уже потом запускает mscoree.dll. Можно ли сделать свой загрузчик, который вначале расшифрует код IL, а уже потом отправит его на выполнение?
Кстати если бы обфускаторы давали классам имена в юникоде из символов какой-нибудь "левой" кодовой страницы ИМХО было бы весело 

Они и так достаточно "левые", поди разбери что имеется ввиду в коде типа "a._b.c()._d(_e.a);" 

Теоретически, должно измениться ее строгое имя  

И где это будет проверено?

"Quis custodiet ipsos custodes" - Кто будет сторожить сторожей?(лат) 

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

Зато сейчас полностью исключены случаи подмены библиотек (думаю не ошибусь, если скажу, что 70-80% действительно вредоносных вирусов этим промышляют), что уже, ИМХО, проело плешь всему Майкрософту вместе взятому. Не зря же они придумали систему проверки целосности/оригинальности системных библиотек.

P.S. $tatic, извини, не врубился (точнее невчитался) в твой вопрос, вот и ответил невпопад  

Ну я предполагал такую ситуацию: в программе есть защита (допустим она шароварная). Код программы находится в дллке (подписанной) и загружается загрузчиком, который проверяет ее подлинность. Если хакер взламывает дллку для сброса защиты, то подпись файла меняется и загрузчик сильно ругается . Так вот я имел в виду, что загрузчик тоже теоретически можно подменить, даже если и он был подписан. Тут все дело в том, что если пользователь использует кряк, то он знает, что ему придется отключать систему безопасности фреймворка.
Аналогичный случай наблюдался при взломе Windows XP SP1 крякером Reset5, когда недобросовестный  пользователь должен был загрузить систему в безопасном режиме, чтобы ему не мешала система проверки целостности библиотек SFC.
Конечно анализ обфусцированной программы выполнить очень сложно. Но хакеру надо найти именно тот участок, который ответственнен за защиту программы. Ему же не надо полный reverse engineering делать. Естетственно эту проверку можно спрятать среди кучи левых методов, но хакер ведь может получить полный исходник в виде проекта для студии (это может плагин FileDisassembler для Reflector), загрузить его в студию и запустить в режиме отладки. Ведь этот метод фактически недоступен при анализе программ в машинном коде.
А вот над измененным загрузчиком IL-кода стоит подумать.
ЗЫ. Хакеры давно уже научились обходить проверку подлинности библиотек. Читайте Криса Касперски.

Нормальный обфускатор не позволит дизассемблировать программу в высокоуровневый язык (будут кидаться ошибки), и всё что останется - декомпилировать и отлаживать IL-код, что практически равносильно анализу программ в машинном коде. Кстати, хороший пример защиты исходного кода - как скрыты исходники самого Reflector-а  .

Скажите кто каким обфускатором пользуется?

Пока серьёзным не приходилось пользоваться, DotFuscator community edition юзал.

Чё меня бесит, так это то, что если допустим в программе есть закрытая переменная с паролем, например

то этот пароль можно просто и без проблем выдрать из программы. Кто-нибудь пробовал открывать экзешник или дллку в блокноте? Даже слепой не сможет не заметить среди тучи слов вполне логичные password2server = 1234567890. Мне не понятен принцип работы обфускатора. Что изменится с исполнительными файлами и библиотеками программы? Будет ли виден пресловутый пароль через блокнот?  

Никто никогда не хранит такие данные в открытом виде. Чаще используют хеши (для сравнения) либо зашифрованные строки.