Показать полную графическую версию : .: NSIS - все вопросы :. часть 2.
Vasyutin
07-02-2021, 10:15
Добрый денечек. Много лет читаю эту замечательную темку. Образования в этом деле не имею. Но с темы по мелочам все понятненько. Несколько раз делал шутки в виде сообщений в несколько ходов с вопросами и подсовывал их жене вместо ее браузера. Во смеху было. А сейчас совсем я в непонятках с этими RequestExecutionLevel. Такой вопросик. Какая получается разница если установщик позначен RequestExecutionLevel highest или RequestExecutionLevel admin. Интересует чтобы мой файлик смог сделать то что делает администратор. Для этого нужно только обязательно RequestExecutionLevel admin? Или подойдет RequestExecutionLevel highest? Как я понял в установщика с RequestExecutionLevel admin самые высокие права. Тогда какие функции теряет установщик с RequestExecutionLevel highest в сравнении с RequestExecutionLevel admin? Совсем не понятно. Если не тяжело, пожалуйста объясните простенько. Спасибочки.
Простая (казалось бы...) задача : Нужно определить наличие ключей в реестре.
ОС Windows 10 (20h2) x64, ключи :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\UI\Visibility
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Spynet
Не тут то было... Права доступа похоже не при чём (да и вроде как не нужны для этого...).
Пример, который нормально работает (проверял в W7) с "крутым" владельцем другого ключа ( с TrustedInstaller) :
!addplugindir .
!include "LogicLib.nsh"
!include "Registry.nsh"
OutFile "IfKeyExists-test.exe"
RequestExecutionLevel admin
Var NameKey
Section
StrCpy $NameKey "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\AGP"
ClearErrors
${registry::KeyExists} "$NameKey" $R0
${If} $R0 = -1
MessageBox MB_OK "NO Key"
${ElseIf} $R0 = 0
MessageBox MB_OK "OK!"
${EndIf}
${registry::unload}
SectionEnd
Этот же пример (и с EnumRegKey тоже) не работает в W10 с вышеназванными ключами...
В чём дело ? Кто "охраняет" конкретно эти ключи ? У кого какие соображения ?
ps к слову сказать, эти ключи не находятся при получении ACL, и при использовании команд PowerShell, и при работе с subinacl.exe...
В чём дело ? »
Элементарно, Ватсон! Ключи эти существуют только для 64бит приложений :)
Примерно таким макросом можно оформить проверку:
# macro + def
!define RegKeyExists '!insertmacro RegKeyExists'
!macro RegKeyExists RETURN ROOTKEY SUBKEY
Push $0
ClearErrors
EnumRegValue $0 ${ROOTKEY} "${SUBKEY}" 0
IfErrors 0 +5
EnumRegKey $0 ${ROOTKEY} "${SUBKEY}" 0
IfErrors 0 +3
StrCpy ${RETURN} 0
Goto +2
StrCpy ${RETURN} 1
Pop $0
!macroend
# Example
${RegKeyExists} $R0 HKLM64 "SOFTWARE\Microsoft\WindowsSelfHost\UI\Visibility"
Ключи эти существуют только для 64бит приложений »
А в 32 битных их разве нет ?
И я вроде как "выудил" эти ключи из реестра, в том же виде, какими они и были в x64... Или в рег-плагине необходимо конкретно указывать на разрядность ОС ? (в доке этого не видел...) Вероятно забыл про SetRegView 64...
и как быть с репликой из ps ?
MKN,
Да, в 32 битных их нет. Это легко увидеть, если открыть 32-битный %WINDIR%\SysWOW64\regedit.exe
Ключей WindowsSelfHost и Windows Defender там не будет.
Что до плагина, то он староват и не в курсе про реестр в x64.
"В крации", реестр в x64 состоит из трёх загончиков (общий, 32бит, 64 бит), и для доступа во чужой загончик надо использовать волшебное слово при использовании функций WinAPI. Плагин таким фокусам не обучен, add: но на него действует SetRegView 64
и как быть с репликой из ps ? »
это про что?
Что до плагина, то он староват и не в курсе про реестр в x64. »
Как же всё-таки определять подобные ключи в x64 ? Что то я туплю под вечер...
это про что? »
Это я про работу subinacl. Собственно от неё у меня всё и пляшет... Но закрадывается смутное сомнение , что и эта утилитка тоже устарела и с x64 ключами не дружит...
Как же всё-таки определять подобные ключи в x64 ? »
Часть ключей задокументирована - Redirected, Shared, and Reflected Keys Under WOW (https://docs.microsoft.com/en-us/windows/win32/winprog64/shared-registry-keys#redirected-shared-and-reflected-keys-under-wow)
Для остального можно дёрнуть ключ отдельно в 32 и 64 бит режиме и сравнить выхлоп. Даже батничком на `reg query %REGPATH% /ve` можно реализовать.
Это я про работу subinacl. »
На замену subinacl вроде должен setacl (https://helgeklein.com/setacl/) подойти.
даже батничком на `reg query %REGPATH% /ve` можно реализовать »
Как то не эстетично для NSIS... А по иному разве нельзя ? (или хотя бы на "командной базе" сделать .nsh, для короткой строки детекта в скрипте... )
На замену subinacl вроде должен setacl подойти. »
Нужно получить данные о правах ключей... setacl не умеет, а subinacl похоже не умеет работать с x64 ключами... Засада...
Хотя AccessControl plug-in с большим трудом всё же упросил доработать, но нужный инфо-вывод в SDDL формате... Надо как то парсить-расшифровывать. Одна морока...
MKN, Вот такой макрос получился
# RETURN value:
# 0 : not exists
# >0 : exists
!define RegKeyExists '!insertmacro RegKeyExists'
!macro RegKeyExists RETURN ROOTKEY SUBKEY
Push $0
Push $1
StrCpy $0 0
SetRegView 32
ClearErrors
EnumRegKey $1 ${ROOTKEY} "${SUBKEY}" 0
IfErrors +2
IntOp $0 $0 + 1
SetRegView lastused
${If} ${RunningX64}
SetRegView 64
ClearErrors
EnumRegKey $1 ${ROOTKEY} "${SUBKEY}" 0
IfErrors +2
IntOp $0 $0 + 1
SetRegView lastused
${EndIf}
Pop $1
Exch $0
Pop ${RETURN}
!macroend
Если есть необходимость знать точно, существует ключ для 32 или 64 бит процесса, то чуть сложнее будет
Внезапно оказалось, что SetRegView 64 благотворно влияет на плагин registry.${registry::KeyExists} "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Scan" $1 возвращает 0, т.е. ключ найден
но нужный инфо-вывод в SDDL формате... Надо как то парсить-расшифровывать. »
С виду парсится должно без хлопот даже в nsis...
Внезапно оказалось, что SetRegView 64 благотворно влияет на плагин registry. »
Я это тоже осознал :).
С виду парсится должно без хлопот »
Не подскажешь соотв. утилитку ком строки (если существует...) ?
ps А что делает SetRegView lastused, если популярно разъяснить ? Возвращает в исходное состояние чтение\запись из\в реестре ? Т.е. всё равно это эквивалентно записи SetRegView32(64) в нужном месте кода ?
Не подскажешь соотв. утилитку ком строки (если существует...) ? »
не встречал, но возможно проще будет парсить выхлоп SetACL, т.к. там есть возможность вывода в виде таблицы с табами в качестве разделителей:для командыsetacl -on "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Scan" -ot reg -actn list -lst "f:tab;w:d;i:y;s:y"
выхлоп:
machine\SOFTWARE\Microsoft\Windows Defender\Scan
DACL(not_protected+auto_inherited):
S-1-15-2-1 read allow inherited
S-1-15-2-1 read allow container_inherit+object_inherit+inherit_only+inherited
S-1-15-3-1024-3153509613-960666767-3724611135-2725662640-12138253-543910227-1950414635-4190290187 read allow inherited
S-1-15-3-1024-3153509613-960666767-3724611135-2725662640-12138253-543910227-1950414635-4190290187 read allow container_inherit+object_inherit+inherit_only+inherited
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 full allow inherited
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 full allow container_inherit+object_inherit+inherit_only+inherited
S-1-5-80-1913148863-3492339771-4165695881-2087618961-4109116736 full allow inherited
S-1-5-80-1913148863-3492339771-4165695881-2087618961-4109116736 full allow container_inherit+object_inherit+inherit_only+inherited
S-1-5-18 full allow inherited
S-1-5-18 full allow container_inherit+object_inherit+inherit_only+inherited
S-1-5-32-544 read+KEY_CREATE_LINK allow inherited
S-1-5-32-544 read+KEY_CREATE_LINK allow container_inherit+object_inherit+inherit_only+inherited
S-1-1-0 read+KEY_CREATE_LINK allow inherited
S-1-1-0 read+KEY_CREATE_LINK allow container_inherit+object_inherit+inherit_only+inherited
По SetRegView:
При выполнении SetRegView 32|64 предыдущее состояние (32/64) сохраняется и с помощью SetRegView lastused его можно восстановить обратно.
Появилась UNICODE версия NSIS Simple Service Plugin
https://nsis.sourceforge.io/mediawiki/images/e/ef/NSIS_Simple_Service_Plugin_Unicode_1.30.zip
Здравствуйте
При установке обновлений для моего приложения, проверяется хеш-сумма файла (использую плагин md5). Возникла необходимость этот файл изменить, но при этом сохранить возможность установки уже выпущенных дополнений. Соответственно нужно изменить проверяющийся файл, сохранив его хеш сумму. По байтам размер останется прежним.
Можно ли реализовать такую задачу и что вообще можно сделать в данной ситуации?
Заранее спасибо!
---
Сохранить хеш-сумму файла, скорее всего, не получится. Может как-то повлиять на проверку хеш-суммы в уже выпущенных инсталляторах, чтобы она в них не срабатывала на этом файле после того как будет установлена новая версия основной программы с обновлённым файлом. То есть в новую версию проги надо что-то включить, что могло бы запретить предыдущим инсталлерам выполнять проверку md5 конкретного файла.
Проверка реализована так: задана хеш-сумма, если файл ей не соответствует, то аборт установки. А теперь, так как этот файл будет обновлен, юзер не сможет установить ранее выпущенные дополнения поверх новой версии основной программы. Вот и думаю, как сохранить хеш, либо что-то внедрить, чтобы проверка хеша не выполнялась (игнорировалась).
Использовался MD5 plugin, код проверки:
md5dll::GetMD5File "$INSTDIR\upd0.vers"
Pop $0
${If} $0 != "B30912CF87B0AC002A350AB8BD2314CE"
MessageBox MB_OK|MB_ICONSTOP "Ошибка!" IDOK
Quit
Serg866,
Почитай про https://nsis.sourceforge.io/Docs/VPatch/Readme.html и https://nsis.sourceforge.io/WPatch_plug-in.
Может подойдёт для твоих целей...
Ну, и теоретически хэш можно изменять...
https://xakep.ru/2012/11/22/light-fake-checksum/#toc05.
MKN, патчи для инсталлов - не вариант. Если я правильно понял функции этих плагинов.
О подделке хеша я читал статьи (на Хабре есть статья 'Забавляемся с хешами'), но в моём случае хеш-сумма задана и надо точно такую же сделать на отредактированном файле (конкретный хеш, а не рандомный). В статьях я ничего не нашёл об этом.
Serg866,
Я предположил, что инсталлятор "базовой" твоей проги тобой и написан. Патч входит в обновление и запускается первым изменняя базовой инсталлятор так, чтобы в нём отключилась проверка хэша. После чего запускается базовая установка и обновление. Или всё не так ? :)
Kopejkin
06-06-2021, 20:30
Непонятна логика обновления. Зачем "обновлять" новую версию старыми обновлениями? Или это не обновления, а какие - то файлы, сопутствующие основному исполняемому файлу?
MKN, Kopejkin, есть основная программа, есть дополнения для неё (и то, и другое сделано мной). В инсталлерах дополнений встроена проверка хеша. Но так как в новой версии основной программы проверочный файл изменится, то ранее выпущенные дополнения не смогут установиться поверх новой версии. А надо сделать так, чтобы устанавливались. При этом нужно обойтись без какой-либо правки инсталлеров дополнений, так как они давно выпущены и скачаны большим количеством пользователей.
Serg866,
Если файл "$INSTDIR\upd0.vers" не сильно большого размера, то можно обойтись костылём в виде сервисной программы типа "Установка дополнений от х.хх на новую версию х.хх", которая подменит новый upd0.vers на старый на время установки дополнений.
iglezz, а как файл после подмены вновь заменится на новый? Это надо пояснять юзерам. С таким костылем может получиться так, что будет старый файл, а версия программы - новая. И наоборот. Тогда программа будет неправильно работать.
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.
Available in ZeroNet 1osznRoVratMCN3bFoFpR2pSV5c9z6sTC