есть программа, контролирующая целостность своих файлов некой "подписью". первый кусок ее образования понять смог, но второй не дается. есть несколько источников с описанием похожего метода (врятли этого), но с учетом того, что я вэтом полный ноль - смотрю на все это как баран на новые ворота и ни каких мыслей в голову не идет. судя по темам, народ тут серьезный, но если есть у кого время помочь разобраться с этой ерундой и объяснить как создается эта подпись, был-бы весьма признателен. начну с того что смог понять и сразу с примером (см. вложеннный архив). папка "Blizzard_VehicleUI", в ней файлы Blizzard_VehicleUI.lua BLIZZARD_VEHICLEUI.TOC.SIG (собственно файл подписи) Blizzard_VehicleUI.toc Blizzard_VehicleUI.xml подпись делится на две части. - первая (16 байт) - md5 собранных в один, файлов всей папки. в данном случае, мд5 считается от скленных в таком порядке "Blizzard_VehicleUI.toc+Blizzard_VehicleUI.xml+Blizzard_VehicleUI.lua" (в архиве это файл "spliced_files.md5"). - разделитель "NGIS". - вторая (256 байт) - вот в ней ни как не могу разобраться. дальше только теории. есть програма, которая "как-бы" делает подобные файлы сигнатур, но с учетом того, что изначальное ее предназначение иное и создать сигнатуру к своему списку файлов не получается, использовал ее просто для ознакомления принципа ее работы. то что выудил. не знаю как именно, генерируется два файла (каждый раз разного содержимого. батник для генерирования файлов "\\wowsig\wowpub.bat") "client_addons.pri" и "client_addons.pub" от их содержимого напрямую зависит вторая часть подписи. после создания этих файлов, файлом "\\wowsig\wowsig.bat" генерируется сам файл подписи "\\wowsig\Interface\Addons\CloseUp\closeup.TOC.SIG" для файла"\\wowsig\Interface\Addons\CloseUp\closeup.toc" при изменении имени файла (имя папки должно ему соответствовать), изменяется и вторая часть подписи, но регистр букв, значения не имеет (т.е. при различном регистре букв, файлы подписей идентичны). соответсвует генерируемый файл сигнатуры этой программой, проверить не могу, но с учетом, опять-таки того, что программа изначально предназначена не для этих целей - неизвестно. +проверить это судя по всему невозможно. нашел две статьи с описанием "чего-то похожего", но в связи с полным отсутствием знаний в данной области - ни чего не понял, но думаю связь с данным "случаем" если и не прямая, то как минимум нечто похожее http://wiki.devklog.net/index.php?title=The_MoPaQ_Archive_Format#Strong_Digital_Signature_-_Generics http://www.skullsecurity.org/wiki/index.php/Warden_Modules в общем вся суть вопроса, как из \\Blizzard_VehicleUI\Blizzard_VehicleUI.lua \\Blizzard_VehicleUI\Blizzard_VehicleUI.toc \\Blizzard_VehicleUI\Blizzard_VehicleUI.xml получить вторую часть подписи (после "NGIS") из файла \\Blizzard_VehicleUI\BLIZZARD_VEHICLEUI.TOC.SIG вроде написал все что знал, надеюсь на вашу снисходительность и помощь.
С высокой вероятностью здесь следующая схема : Компания-разработчик генерирует на этапе создания софта пару асимметричных ключей : закрытый (.pri) и открытый (.pub), (они всегда создаются парой, а если совсем точно, то сначала создается закрытый, а потом по нему вычисляется открытый, и в обратную сторону этот процесс "повернуть" нельзя). http://ru.wikipedia.org/wiki/%D0%AD%D0%A6%D0%9F#.D0.90.D1.81.D0.B8.D0.BC.D0.BC.D0.B5.D1.82.D1.80.D0.B8.D1.87.D0.BD.D0.B0.D1.8F_.D1.81.D1.85.D0.B5.D0.BC.D0.B0 Необходимые к защите файлы подписываются ЭЦП с помощью закрытого ключа, который никогда не покидает стен офиса компании. Сама ЭЦП (сигнатура) и есть те самые 256 байт после разделителя NGIS-SIGN. В дистрибутивы кладется вместе с сигнатурой только открытая часть ключа компании-разработчика - её достаточно для проверки подписи, но не для генерации новой для измененных файлов. По известному открытому ключу восстановить закрытый нельзя - это одно из основных правил асимметричной криптографии. Остается единственное незащищенное место - возможность замены открытого ключа компании, идущего в дистрибутиве, своим собственным, для которого уже есть сгенерированный .pri-файл и возможно создание подписей. Чтобы такого вида атаки не проходили по правилам положено открытый ключ распространять не просто так, а в виде, подписанном другой ЭЦП, например, Майкрософта или Верисайна - это так называемый "сертификат ключа подписи". Если всё сделано по правилам теории асимметричной криптографии твоя задача неразрешима.
Если tmz решил присвоить себе авторство, то тогда наверное неразрешимо, но если прога не требует постоянной связи с инетом, то что мешает пропатчить сигнатуру и открытый ключ одновременно? Ничего не мешает, как было сделано для WinRAR например. Против подмены ключа ЭльГамаль и RSA бессильны.
Вопщем рассуждая крайне абстрактно, тебе нужно 1) пропатчить файлы как тебе надо 2) пересчитать MD5 3) сгенерить пару своих ключей 4) закрыть MD5 приватным ключом 5) новую MD5 и открытую экспоненту(ключ?) сунуть в прогу заместо оригинальных. Вобщем, это только теория, с практикой тебе другие помогут. А ключ Мелкософт может защитить от натариуса, но не от этой процедуры ИМХО
авторские права меня абсолютно не заботят, все намного банальней и проще)) кнопки в игрушке стационарные, а я хочу сделать мерцающими, а скриптовые файлы отвечающие за вид и действие кнопок подписаны)) собственно весь сырбор из-за этого (wow - world of warcraft). по сети ходила програмулина отключающая проверку подписи, но она для каждой версии разная +ее нужно запускать после запуска игры, что оч. неудобно. +сама игра обновляется относительно часто, а прога отключающая проверку подписи ходит "по рукам", откуда берется, кто ее делает и когда ему это надоест неизвестно. т.е. возможность научиться делать такую подпись на порядок привлекательней. пересчитать мд5 не проблема, мне главное понять, сам принцип создания этой второй части подписи. что именно используется при проверке и как именно проверяется, тогда возможно смогу придумать как рассчитать новую "подпись". хм... как-бы сказать-то... в общем в голове такие мысли: для проверки "подписи", сама игра что-то делает именно с содержимым файлов. складывает, перемножает, делит, ксорит, не важно. главное, что на выходе после этих преобразований получается какой-то "кусок" для сравнения с этими 256 байтами после "NGIS" (назовем их "эталоном"). т.е. если иметь функцию проверки, то можно знать, что именно программа будет сравнивать с эталоном. соответственно можно будет подогнать ей эталон созданный по ее-же принципам рассчета. ммм... дико извиняюсь, за возможно непонятно выражаемые мысли, просто с терминологией не знаком и толком не знаю что именно как называется... попробую схематично --------------------------- исходные [файлы данных], [файл подписи] [файл подписи] в свою очередь условно состоит из [[мд5]["NGIS"][эталон]] действия программы собираем [файлы данных] последовательно в один файл и рассчитываем от него мд5, сравниваем с [мд5] из [файла подписи] каким-то образом (назовем его [функцией]) обрабатываем [файлы данных] и получаем [последовательность] байт и сравниваем ее с [эталоном] --------------------------- вот если знать эту самую [функцию], то можно будет рассчитывать и сами [эталоны] для подписей. или я все-таки что-то недопонял? з.ы. я понимаю, что абсолютно некомпетентен в этом вопросе, по этому прошу простить за свои посты, возможно кажущиеся вам абсолютно ламерскими, просто приперло и вот пытаюсь хоть как-то разобраться((
Пропатчить открытый ключ обычно "мешает" подписание (сертификат) этого ключа ЭЦП, например, ключом Майкрософта, который прошит в операционке и который в свою очередь пропатчить ОЧЕНЬ проблематично.
спасибо за попытки помощи, но я не понимаю о каких открытых/закрытых ключах вы говорите, в файлах игры я ни чего подобного даже близко не видел (ну что закрытого там и быть не должно я понял), а программа приложенная в архиве сделана сторонним программером и для других целей и с самой игрой использовался условно отдельно, т.е. игра файлы этих сигнатур ни как не проверяла. просто генерируемый ей файл сигнатуры показался мне оч. похожим на интересующие меня. не думаю что в игру будут пихать сильно навороченные проверки, т.к. файлов там на 17 гигов, если проверять их сложными методами, то это должно занимать оч. много времени. для примера один из проверяемых файлов сигнатур, подписывает 28200 файлов, общим объемом более 5 гигабайт. имхо должно быть что-то простое и быстрое в рассчетах.
OLS для этого разработчик должен отдать свои драйвера или программы на подписание прямо в Мелкософт, а оно всем такую честь оказывает? И потом, неужели секретный ключ открытый аналог которого есть в ОС нигде не всплывает? Это начиная с Висты или где?
persicum При чем здесь подписание кода ? Прочитайте в конце концов теорию про сертификаты ключа подписи, а потом зайдите Выполнить / certmgr.msc / Доверенные корневые центры сертификации / Сертификаты у меня в системе (WinXP SP2) их около 200 стоит. Любой из них может подписать открытый ключ например того же Blizzard после чего никакая подмена ключей Вам не удастся, если только в самом коде Вы не найдете точку проверки сертификаты средствами CryptoAPI.
OLS чесслово хотел почитать, но кроме сертификации молодых ИТ специалистов ничего не нашел =((( непонятно ничего... Закрытых ключей в ОСи не содержится? Для подписания нужна связь по Инету с Мелкософт? Почему автор темы не может подписать свой вновь сгенерированный ключ, если автор игрушки смог? Заранее извиняюсь за скудоумие...
Закрытых ключей в ОСи не содержится, только открытые. Сценарий: Фирма А хочет сделать так, чтобы ее конфигурационные файлы не изменялись во время распространения какого-либо программного продукта или, например, годового финансового отчета или данных о котировках, поступающих с биржи. Решение: 1) Фирма генерирует пару асимметричных ключей - закрытый dA и открытый eA. 2) Фирма отправляет свой открытый ключ на подписание ЭЦП любому широко известному провайдеру сертификатов С (удостоверяющему центру), наиболее крупные - VeriSign и Thawte. При этом желательно выбирать такой УЦ, чтобы его открытый ключ eC уже шел предустановленным в операционную систему (УЦ платят за это денежки Майкрософту), по ссылке выше Вы можете посмотреть сколько открытых ключей (т.н. самоподписанных сертификатов) установлено у Вас в ОС в хранилище "Доверенные центры корневых сертификатов" 3) УЦ за вполне разумные деньги (например Thawte за 550$ на 2 года : http://www.thawte.com/code-signing/index.html выпускает фирме А сертификат, который представляет собой не что иное, как открытый ключ eA, подписанный ЭЦП на основе закрытого ключа dC : "SIGN((eA);dC)" 4) Фирма распространяя данные, которым хочет обеспечить целостность, подписывает их (сколько угодно раз - хоть каждую минуту) своим закрытым ключом : "SIGN((DATA);dA)", естественно у себя на территории и дальше пускает их по всему миру, дополнительно снабжая сертификатом "SIGN((eA);dC)". 5) Пользователю приходит : "DATA" "SIGN((DATA);dA)" eA "SIGN((eA);dC)" при этом eC, который нужен для проверки последней записи в этой цепочке, уже установлен в операционной системе. Для того, чтобы как-то повлиять на ход проверки цепочки, Вам нужно либо полностью "перестроить" операционную систему, либо вклиниться в инициацию процесса проверки прикладной программой - пожалуйсамой.
если честно, для игры это все слишком мудрено. по-моему, смысл так заморачиваться ради проверки целостности файлов клиента весьма сомнителен... ну допустим. один фиг, функция проверки заложена в самом клиенте, как ее оттуда достать "для изучения"?
поковырял екзюк (тупо визуально, знаю что смешно, но порой даже смешные вещи помогают докопаться до сути). огрызки из файла вам полюбому о чем-то должны сказать, у меня только догадки Код (Text): BLIZZARDKEY E:\build\buildWoW\Storm\Source\SFile.cpp AUEVENTREC AUREQUEST AUARCHIVEREC@SFile@Storm@@ #256 Blizzard_Storm Microsoft Base Cryptographic Provider v1.0 CryptVerifySignatureA CryptSignHashA CryptReleaseContext CryptImportKey CryptHashData CryptDestroyKey CryptDestroyHash CryptCreateHash CryptAcquireContextA advapi32.dll (signature) ARCHIVE AUAUDIOSTREAM@SFile@Storm@@ HSARCHIVE HSFILE AUDIOSTREAM \\ :\ (block table) (hash table) (attributes) AUFILEREC@SFile@Storm@@ %s(%u) : CDebugLock:%08x: entry has bad next %u E:\build\buildWoW\Storm\Source\W32\SLock.cpp %s(%u) : CDebugLock:%08x: tid:%03x %c %c t:%u вот тут как раз что-то про "ARCHIVE" http://wiki.devklog.net/index.php?title=The_MoPaQ_Archive_Format#Strong_Digital_Signature_-_Specifics самой библиотеки "шторм" в клиенте вова нет, но она есть в других играх близзарда, достать могу. вобщем, я думал раньше, что шторм использовался только для работы с MPQ архивами, возможно еще и для проверки. возможно часть этой библиотеки просто сразу вшита в сам исполняемый вова. если чем-то поможет, вот список функций клиента для работы с advapi32.dll Код (Text): AddAccessAllowedAce AddAccessDeniedAce AllocateAndInitializeSid FreeSid GetTokenInformation GetUserNameA InitializeAcl OpenProcessToken RegCloseKey RegCreateKeyExA RegDeleteKeyA RegDeleteValueA RegEnumKeyExA RegFlushKey RegOpenKeyA RegOpenKeyExA RegQueryInfoKeyA RegQueryValueExA RegSetValueExA SetSecurityInfo в целом могу сам исполняемый бросить (5 метров (2 в зипе)). просто надо хотя-бы знать точно, в какую сторону рыть((
всем спасибо, вырезал проверку в самом екзюке. не совсем то что хотелось, но по крайней мере работает.
