Уважаемые, помогите с теорией ну и с практикой если есть у кого...
Собственно есть .NET компонент который очень хочется.
Регистрация: Файл лицензии подписанный (RSA1024)

Как это видится мне: Меняем Public Key с помощью которого производся проверка подписи и собственно все... ну и генерим соответствующий файл лицензии.

Возникает вопрос: После патча происходит не соответствие подписи библиотеки (strong name).

Вопрос: Возможноли переподписать библиотеку чтобы все работало (естественно с перекомпиляцией программы которая ее использует)? Если да то как? И чем?

„И чем?“

Секретным ключом Microsoft :) (если библиотека ихняя)

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

„После патча происходит не соответствие подписи библиотеки (strong name).“

Подпись библиотеки проверяется самим компонентом разработчика или это у .NET такая фича появилась (типа authenticode)?

Собственно это было частью вопроса :)
Насколько я знаю при использовании Strong Name (SN) создается хеш сборки, подписывается секретным ключом и результат вместе с публичным ключом помещается в сборку.
Далее при инициализации библиотеки все это проверяется (средствами .NET, не сборки) и если не совпадает то сборка считается поддельной и ее использование запрещается.
В чем-то могу ошибаться - поправьте.

О, нашел... фича видимо появилась
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgui de/html/cpconAssigningAssemblyStrongName.asp

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

Да ключто лежит на видном месте... вопрос в том можноли переподписать и если да то как это отразится на работе компонента... Хотя нужно сам компонент покопать на предпет проверки подписи сборки...

Неужели никто никогда не патцил сборки? .NET-то уже давно появилась... опыт народ должен был уже подсобрать... У кого есть опыт? Отзовитесь!!!

Вопрос в догонку: Если принять метод подмены подписи сборки, то как считается хеш сборки? По откомпилированной сборки или по всем файлам участвующим в сборке до копмиляции или как-то еще? Я не нашел информации на эту тему...
Хотя... я тут подумал наверное по готовой сборке, иначе как Framework ее проверяет.

„то как считается хеш сборки?“

Скорее всего считается хеш от файла (возможно SHA1), потом подписывается секретным ключом (RSA) , подпись вшивается в библиотеку. Для проверки расшифровывается (публичным ключом) подпись, потом берется хеш от файла и эти два хеша сверяются. Теоретически пропатчить файл, взять хеш, потом переподписать своим секретным ключом, впихнуть новую подпись, потом публичный ключ заменить на свой, это все просто. Но так ли это происходит в случае NET Strong Name надо ещё выяснить, инфа в инете есть, будет время почитаю

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

„не сам же файл... туда ведь потом еще ключь и подпись засовывается...“

Ну и что, криптопровайдеры тоже подписываются (cspsign.exe), а подпись потом ложится в русурсы файла, видимо этот ресурс просто не учитывается при хешировании и проверке. А NET'а у меня НЕТ'у, примера нету, информацию я ещё не собрал, т.ч. сейчас конкретного ответа дать не могу, жди пока человека с опытом в этом деле

Кое что об удалении подписи.
http://www.codeproject.com/dotnet/NeCoder03.asp

По поводу статьи из поста выше:
Все былобы хорошо, только компонент обработан Dotfuscator-ом и дизасемблер валится на нем :(

jfx Поставил я NET.Framework 2.0 Beta

Вот статья, ты видимо её не читал, там достаточно подробно всё расписывается.
http://www.rsdn.ru/article/dotnet/assembly2.xml

Цитаты :

• Маркер открытого ключа является 64 битным (8 байтным) числом, которое является SHA1 хешем (контрольной суммой) открытого ключа.
  
• Помимо участия в строгом имени сборки, открытый ключ используется для её подписания. Происходит это так. При создании сборки компилятор рассчитывает контрольные суммы всех файлов входящих в сборку, затем формирует базовый файл сборки, в манифесте которого будут указаны данные значения и полный открытый ключ сборки. Поле чего считает контрольную сумму базового файла итоговой сборки, которую при помощи пары ключей (открытого и закрытого) преобразует в цифровую подпись RSA. Данная подпись помещается в специальную секцию PE файла, не участвующую при подсчёте общей контрольной суммы, что позволяет провести процесс в обратном порядке. То есть подсчитать контрольную сумму сборки, и при помощи сохранённой цифровой подписи и открытого ключа, проверить целостность файла.

• Данный механизм позволяет предотвратить несанкционированное изменение сборки – её кода, или любых входящих в её состав файлов.

Пока я её дочитываю, ты скажи ... маркер publickeytoken ты пересчитал? Т.е. у тебя проблема в том, что ты не знаешь как и от чего посчитать хеш для последующей его подписи, так как делает ilasm.exe? В манифесте твоего компонента есть какие-то хеши от сорцов (как на рисунке)?
В статье говорится о GAC'е, может твой компонент после патча ещё надо в нем переинсталить? У меня нету sn.exe, сгенери ним пару ключей и приатач, хочется посотреть на их формат