Уважаемые, помогите с теорией ну и с практикой если есть у кого... Собственно есть .NET компонент который очень хочется. Регистрация: Файл лицензии подписанный (RSA1024) Как это видится мне: Меняем Public Key с помощью которого производся проверка подписи и собственно все... ну и генерим соответствующий файл лицензии. Возникает вопрос: После патча происходит не соответствие подписи библиотеки (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'а у меня НЕТ'у, примера нету, информацию я ещё не собрал, т.ч. сейчас конкретного ответа дать не могу, жди пока человека с опытом в этом деле
По поводу статьи из поста выше: Все былобы хорошо, только компонент обработан Dotfuscator-ом и дизасемблер валится на нем
jfx Поставил я NET.Framework 2.0 Beta Вот статья, ты видимо её не читал, там достаточно подробно всё расписывается. http://www.rsdn.ru/article/dotnet/assembly2.xml Цитаты : <ul type=disc><li>Маркер открытого ключа является 64 битным (8 байтным) числом, которое является SHA1 хешем (контрольной суммой) открытого ключа. <li>Помимо участия в строгом имени сборки, открытый ключ используется для её подписания. Происходит это так. При создании сборки компилятор рассчитывает контрольные суммы всех файлов входящих в сборку, затем формирует базовый файл сборки, в манифесте которого будут указаны данные значения и полный открытый ключ сборки. Поле чего считает контрольную сумму базового файла итоговой сборки, которую при помощи пары ключей (открытого и закрытого) преобразует в цифровую подпись RSA. Данная подпись помещается в специальную секцию PE файла, не участвующую при подсчёте общей контрольной суммы, что позволяет провести процесс в обратном порядке. То есть подсчитать контрольную сумму сборки, и при помощи сохранённой цифровой подписи и открытого ключа, проверить целостность файла.</ul> <ul type=disc><li>Данный механизм позволяет предотвратить несанкционированное изменение сборки – её кода, или любых входящих в её состав файлов.</ul> Пока я её дочитываю, ты скажи ... маркер publickeytoken ты пересчитал? Т.е. у тебя проблема в том, что ты не знаешь как и от чего посчитать хеш для последующей его подписи, так как делает ilasm.exe? В манифесте твоего компонента есть какие-то хеши от сорцов (как на рисунке)? В статье говорится о GAC'е, может твой компонент после патча ещё надо в нем переинсталить? У меня нету sn.exe, сгенери ним пару ключей и приатач, хочется посотреть на их формат
bogrus Статью не читал, спасибо. По порядку: publickeytoken - насколько я знаю это не CRC от PublicKey а последнии 8 байт этого самого PublickKey. Да, у меня проблема в подсчете хеша, я не знаю по каким блокам его считать. Хэш использует SHA1 алгоритм (.hash algorithm 0x00008004 - это и есть SHA1). По поводу хешей сырцов - их там быть не должно. Там только publickeytoken-ы используемых сборок. Возможна индивидуальная подпись для разных модулей в одной сборке (это наверное имелось ввиду) но у меня одна подпись на весю сборку. В глобальный кеш сборку класть не нужно - она живет в своей папке и используется из нее. Да, кстати, речь идет о Atalasoft.DotImage.SDK.v2.0 http://www.atalasoft.com/ _1764101400__testkey.snk
Да, кстати, по поводу Framework 2.0 beta: Как известно обфускаторы используют ошибки в ildasm для предотвращения дизасемблирования защишенный сборок. Грубо говоря в сборку заносятся ошибочные метаданные которые не влияют на работы программы но дизасемблер валится при их анализе. Я собственно решил попробовать свежую версию ildasm-а котораю идет s .NET Framework SDK 2.0 beta (блин 200 метров пришлось качать...), и он прекрасно дизасемблировал мою сборку обработанную Dotfuscator-ом. ilasm из 2-ого Framework-а прекрасно собрал все назад и размер даже получился байт в байт, НО программы которые используют Framework 1.1 в этой сборке сборку собственно не признают Оно конечно понятно что вроде так быть и дожно... но может кто знает что там изменило глобально? Формат сборки что-то еще, можно как-то заставить ilasm 2 например генерировать сборку для FW1.1 ?
немного не в тему, но вот: http://download.microsoft.com/download/.netframesdk/CLI3/1.0/WXP/EN-US /sscli_20021101.tgz там среди всего прочего есть и ilasm/dasm в исходниках. да и вообще много чего
Мда, что-то я погорячился по поводу последних 8 байт... Хотя это информация из Книги "C# for Professional" (Wrox) правда 2002 года.
