.: NSIS - все вопросы :. часть 2.
-
Serg866
Re: .: NSIS - все вопросы :. часть 2.
Здравствуйте
При установке обновлений для моего приложения, проверяется хеш-сумма файла (использую плагин md5). Возникла необходимость этот файл изменить, но при этом сохранить возможность установки уже выпущенных дополнений. Соответственно нужно изменить проверяющийся файл, сохранив его хеш сумму. По байтам размер останется прежним.
Можно ли реализовать такую задачу и что вообще можно сделать в данной ситуации?
Заранее спасибо!
---
Сохранить хеш-сумму файла, скорее всего, не получится. Может как-то повлиять на проверку хеш-суммы в уже выпущенных инсталляторах, чтобы она в них не срабатывала на этом файле после того как будет установлена новая версия основной программы с обновлённым файлом. То есть в новую версию проги надо что-то включить, что могло бы запретить предыдущим инсталлерам выполнять проверку md5 конкретного файла.
Проверка реализована так: задана хеш-сумма, если файл ей не соответствует, то аборт установки. А теперь, так как этот файл будет обновлен, юзер не сможет установить ранее выпущенные дополнения поверх новой версии основной программы. Вот и думаю, как сохранить хеш, либо что-то внедрить, чтобы проверка хеша не выполнялась (игнорировалась).
Использовался MD5 plugin, код проверки:
md5dll::GetMD5File "$INSTDIR\upd0.vers"
Pop $0
${If} $0 != "B30912CF87B0AC002A350AB8BD2314CE"
MessageBox MB_OK|MB_ICONSTOP "Ошибка!" IDOK
Quit
При установке обновлений для моего приложения, проверяется хеш-сумма файла (использую плагин md5). Возникла необходимость этот файл изменить, но при этом сохранить возможность установки уже выпущенных дополнений. Соответственно нужно изменить проверяющийся файл, сохранив его хеш сумму. По байтам размер останется прежним.
Можно ли реализовать такую задачу и что вообще можно сделать в данной ситуации?
Заранее спасибо!
---
Сохранить хеш-сумму файла, скорее всего, не получится. Может как-то повлиять на проверку хеш-суммы в уже выпущенных инсталляторах, чтобы она в них не срабатывала на этом файле после того как будет установлена новая версия основной программы с обновлённым файлом. То есть в новую версию проги надо что-то включить, что могло бы запретить предыдущим инсталлерам выполнять проверку md5 конкретного файла.
Проверка реализована так: задана хеш-сумма, если файл ей не соответствует, то аборт установки. А теперь, так как этот файл будет обновлен, юзер не сможет установить ранее выпущенные дополнения поверх новой версии основной программы. Вот и думаю, как сохранить хеш, либо что-то внедрить, чтобы проверка хеша не выполнялась (игнорировалась).
Использовался MD5 plugin, код проверки:
md5dll::GetMD5File "$INSTDIR\upd0.vers"
Pop $0
${If} $0 != "B30912CF87B0AC002A350AB8BD2314CE"
MessageBox MB_OK|MB_ICONSTOP "Ошибка!" IDOK
Quit
-
MKN
Re: .: NSIS - все вопросы :. часть 2.
iglezz, благодарю!
1. У 11ки номера сборок: 21996 и 22000. А вдруг билд 10ки 22H1 будет 22100?
2. Просто не хотелось подключать лишние библиотеки. Об этой версии не знал.
ЗЫ: если интересно, исходный код:
1. У 11ки номера сборок: 21996 и 22000. А вдруг билд 10ки 22H1 будет 22100?
2. Просто не хотелось подключать лишние библиотеки. Об этой версии не знал.
ЗЫ: если интересно, исходный код:
https://gist.github.com/S60Team/36a48718640205e14b8a068b2b809c1f
-
MKN
Re: .: NSIS - все вопросы :. часть 2.
MKN, патчи для инсталлов - не вариант. Если я правильно понял функции этих плагинов.
О подделке хеша я читал статьи (на Хабре есть статья 'Забавляемся с хешами'), но в моём случае хеш-сумма задана и надо точно такую же сделать на отредактированном файле (конкретный хеш, а не рандомный). В статьях я ничего не нашёл об этом.
О подделке хеша я читал статьи (на Хабре есть статья 'Забавляемся с хешами'), но в моём случае хеш-сумма задана и надо точно такую же сделать на отредактированном файле (конкретный хеш, а не рандомный). В статьях я ничего не нашёл об этом.
-
MKN
Re: .: NSIS - все вопросы :. часть 2.
динозавра,
Пример почти такой же как и 2.5 года назад -
nsisXML::select с почти идентичным селектором
nsisXML::parentNode вернёт в нужный регистр ссылку на родителя
nsisXML::removeChild удалит найденное в ::select
Пример почти такой же как и 2.5 года назад -
.: NSIS - все вопросы :. часть 2.
nsisXML::select с почти идентичным селектором
nsisXML::parentNode вернёт в нужный регистр ссылку на родителя
nsisXML::removeChild удалит найденное в ::select
-
Kopejkin
Re: .: NSIS - все вопросы :. часть 2.
Непонятна логика обновления. Зачем "обновлять" новую версию старыми обновлениями? Или это не обновления, а какие - то файлы, сопутствующие основному исполняемому файлу?
-
Serg866
Re: .: NSIS - все вопросы :. часть 2.
MKN, Kopejkin, есть основная программа, есть дополнения для неё (и то, и другое сделано мной). В инсталлерах дополнений встроена проверка хеша. Но так как в новой версии основной программы проверочный файл изменится, то ранее выпущенные дополнения не смогут установиться поверх новой версии. А надо сделать так, чтобы устанавливались. При этом нужно обойтись без какой-либо правки инсталлеров дополнений, так как они давно выпущены и скачаны большим количеством пользователей.
-
iglezz
Re: .: NSIS - все вопросы :. часть 2.
Serg866,
Если файл "$INSTDIR\upd0.vers" не сильно большого размера, то можно обойтись костылём в виде сервисной программы типа "Установка дополнений от х.хх на новую версию х.хх", которая подменит новый upd0.vers на старый на время установки дополнений.
Если файл "$INSTDIR\upd0.vers" не сильно большого размера, то можно обойтись костылём в виде сервисной программы типа "Установка дополнений от х.хх на новую версию х.хх", которая подменит новый upd0.vers на старый на время установки дополнений.
-
iglezz
Re: .: NSIS - все вопросы :. часть 2.
iglezz, а как файл после подмены вновь заменится на новый? Это надо пояснять юзерам. С таким костылем может получиться так, что будет старый файл, а версия программы - новая. И наоборот. Тогда программа будет неправильно работать.
-
Begin2Fly
Re: .: NSIS - все вопросы :. часть 2.
Всем доброго вечера. Опять нуждаюсь в помощи. Такая ситуация. На компе две или более учёток. Одна админ, остальные челядь. Установщик работает из под админа и устанавливает много чего в разные папки, реестр, драйвера. Но нужно установить обязательно всем пользователям папки с файлом по такому пути SetShellVarContext current $APPDATA\Папка\файл или $LOCALAPPDATA\Папка\файл. На всех компах учетки с разными именами. Абсолютный путь не катит. При такой прописке переменных, как я показал, кто бы не устанавливал, а достается одному админу. Остальным никак. Как это можно прописать, чтобы и остальным устанавливались папки?
-
Serg866
Re: .: NSIS - все вопросы :. часть 2.
Begin2Fly, не получится, так как старый файл должен быть заменен на новый под тем же именем.
iglezz, у меня инсталлеры программы и дополнений построены таким образом, что исключены варианты, при которых юзер может произвести установку неправильно. В случае с костылем, такие варианты появляются - не нажмет кнопку 'дальше', закроет костыль раньше времени. Пока не вижу таких проверок, которые могли бы исключить ошибку со стороны юзера при взаимодействии с костылем. Но, будем думать)
iglezz, у меня инсталлеры программы и дополнений построены таким образом, что исключены варианты, при которых юзер может произвести установку неправильно. В случае с костылем, такие варианты появляются - не нажмет кнопку 'дальше', закроет костыль раньше времени. Пока не вижу таких проверок, которые могли бы исключить ошибку со стороны юзера при взаимодействии с костылем. Но, будем думать)