ссыдка по теме: The Secrets of Strong Naming http://www.ondotnet.com/pub/a/dotnet/2003/04/28/strongnaming.html Мысли какиенибудь появились?
.snk это обычный секретный (включающий и открытый) ключ (RSA2), формата PRIVATEKEYBLOB publickeytoken это есть - последние 8 байт хеша SHA1 от всего файла секретного ключа (.snk), т.е. для _1764101400__testkey.snk, publickeytoken=A1423ABC1426E08B Чего-то я не доганяю зачем этот publickeytoken, если его можно сверить только имея весь .snk, а в сборке хранится только публичная часть (RSA1), видимо этот маркер используется просто в качестве имени сборок. Значит надо заострить внимание на подписи. jfx Я тут попытался скомпилить сборку с твоим ключом, вроде даже работает, но в статье на rsdn говорится, что подпись будет в отдельной секции и упоминается манифест, у себя не нахожу ни того ни другого, видимо из-за отсутствия sn.exe, al.exe, ildasm.exe и др. файлов, я не могу правильно скомпилить или хоть проверить ... Вот strong.cs Код (Text): using System; using System.Reflection; class Application { static void Main() { Console.WriteLine("Hello World"); } } А это compile.bat Код (Text): C:\WINNT\Microsoft.NET\Framework\v2.0.40607\csc /t:exe strong.cs /keyfile:testkey.snk Глянь strong.exe, нормальная она? _1462184173__strong.zip
Я пошел другим путем Просто отключил проверку SN. Как переподписать это еще подумать нужно, а для отключения проверки достаточно обнулить Strong Name Signature в CLR Header. Нарушения работы компонента после этого вроде не замечено. При sn -v la-la-la.dll говорит следующее: la-la-la.dll does not represent a strongly named assembly ну и как следствие на исправления в теле dll не ругается.
Вот кстати еще одна очень полезная статья (как часть ответа на мой вопрос что считать): Физическая организация метаданных в исполняемых файлах .NET http://www.rsdn.ru/article/dotnet/phmetadata.xml
Хе-хе... Все получилось: с пропатченым Public Key и сгенегированной с новым ключом лицензией все работает
Поднятый вопрос в начеле ветки "как переподписать пропатченную сборку без перекомпиляции" все еще не решон. Но появилась новая информация (вернее была найдена мной). Если кто имеет интерес к этой теме рекомендую почитать: _http://blogs.msdn.com/shawnfa/archive/2005/02/28/382027.aspx и вообще весь этот блог - крайне познавательно!!! В аттаче файл упоминаемый в статье strongname.cpp
с visual studio идет sn.exe - Microsoft (R) .NET Framework Strong Name Utility Version 1.0.3705.0 Copyright (C) Microsoft Corporation 1998-2001. All rights reserved. посмотри ее <added/> что-то я лажаю в последнее время. про sn.exe ты сам выше писал </added>
ssx А какой её размер, в аттач влезет? Там я выше архив цеплял (1462184173__strong.zip), и хотел использовать strong.exe в качестве подопытного образца (чтобы его пропатчить), так было бы гораздо проще и понятней, но подойдет ли этот strong.exe я не знаю, хотелось бы его проверить этой Strong Name Utility на нормальность (на наличие защиты, т.е. подписи)
Хе-хе. Еслиб все было так просто... Суть проблемы в двух словах: Есть сборка подписанная Strong Name (Если не вкурсе это типа такой способ зашиты от изменений файла. При компиляции создается хеш сборки (SHA1), затем подписывается с помощью RSA и токен от полученного помещается в сборку. При запуске системой снова считается хеш и сравнивается с тем что в сборке). Вот, можно отключить проверку SN (с этим уже разобрались, но это скорее всего баг системы и последующих версиях он скорее всего будет исправлен), но сборки не подписанные SN не могут жить в GAC (Глобальный кеш сборок), а некторые компоненты очень любят хранить свои сборки именно там. Сборку нужно пропатчить, чтоб работала лучьше и вновь подписвть с новым ключом (со старым было бы лучьше но RSA штука серьезная). Есть простой вариант - дизасемблировать сборку с помощью ILDasm, подправить, убрать Public Key и вновь скомпилировать - получится не подписанная сборка и ее уже с помощью sn.exe подписать новым ключом. Вариант отличный но есть одно НО - не все сборки можно безболезненно дизасемблировать (опять баги, на этот раз ILDasm... во 2-ом фреймворке такая защита уже не катит ), обработанные обфускаторами (не всеми) сборки не могут быть корректно дизасемблированн. Поэтому-то и встает проблема переподписания ВРУЧНУЮ. Я долго не мог найти инфу как считается хеш от сборки и вот нашел, даже есть исходники на C++. Ништяк, жизнь налаживается.
sn.exe -e strong.exe strong.txt Public key is 0024000004800000940000000602000000240000525341310004000001000100f50473 6dd2241a 707e20c1d51d16c5d663bb7c8c9194955e7c79582802686d668a5e6988650388ebda8a 128f4a53 d122259923092603c8c24f80e36d3bd2239fb76ea1315a087d8aac9fb22b7cc2d0a9d0 e386d34e 6c355000a8d2cbfe947f54852c64e7c173b90741247f31071dbfae8151ba30612a1b69 8c3dded7 1a9dd0c2 (это публичный ключ RSA1, зашит в проге, его размер 160 байт) sn.exe -T strong.exe strong.txt Public key token is 4f14cbc2225e8310 (это последние 8 байт хеша SHA1 от этого ключа) sn.exe -v strong.exe Assembly 'strong.exe' is valid Т.е. екзешник у меня тогда получился нормальный (нашел там ещё сигнатуру кроме публичного ключа), теперь правлю в нем 1 байт: sn.exe -v strong.exe Failed to verify assembly -- Unable to format error message 8013141A Что делаю дальше: - Меняю в проге публичный ключ на любой другой (например из пары, которая лежит в файле key.snk) - запускаю sn.exe -R strong.exe key.snk - потом sn.exe -v strong.exe Результат: Assembly 'strong.exe' is valid, теперь я не понимаю, в чем была проблема ...
Вручную тоже не проблема, в импорте sn.exe есть ф-ция mscoree.StrongNameSignatureGeneration, тут самое нужное это поставить бряк на ADVAPI32.CryptHashData и в отладчике ты увидишь что и как хешируется, хеш собирается не от целого модуля, а кусочками, сначала MZ, PE, потом отдельно каждая секция, думаю повторить тоже самое не проблема, затем получить сигнатуру (ADVAPI32.CryptSignHashA) от собранного хеш-объекта и вписать её в модуль
Выше говарили про ключ 64 бита, вроде бы это не устойчивый ключ. Вобщем вопрос прост можно ли по имеющимся Public key, восстановить файл который генерит SN.??
Просто некоторым (это те которые легальные пользователи ПО)(http://www.gotdotnet.ru/Forums/Common/136480.aspx), хочеться надрать нос...
История пока не знает прициндентов востановления private key для RSA1024, по крайней мере в открытом доступе этой информации нет. Есть прицендент востановления ключа RSA2048 8-O но там были известны алгоритмы формирования первичного ключа (и функции rnd) и атака велась не брутфорсом а на строго ограниченном (и не таком уж большом) диапазоне чисел. В приведенной тобой выше теме я ответил как можно обойти SN без замены ключа...
Если ты про то что можно срезать ключ, так мне про это известно стало еще наверно года два назад. Просто я как то этот топик пропустил, иначе бы все вопросы кончились бы еще в самом начале)) Собственно ты говариш про то что ildasm вылетает, но против этого есть контр мера, вобще береш Spices .Net и делае Deobusificate Stack Trace, и все ок, не каких приколов с дезасемблингом не будет. Мне интересно другое.. Поскольку я не спец по крипто анализу вот и спрашиваю. Много раз читал что одна из распространненых атак на ключ шифрования, это атака по открытому тексту, т.е. когда у нас есть пара исходник и продукт шифрования. Вот я и хочу узнать в чем проблема в данном случае?
