И сбоку батник. Задаем KeePass'у параметры запуска

• Фиксируем рабочий каталог
• Указываем базу
• Задаем конфигурацию
  • Предотвращаем нежелательное сохранение конфигурации
  • Отступление о конфигурациях
  • Используем несколько конфигураций
• Используем переменные среды
  • Ссылаемся на локальные ресурсы
  • Оптимизируем работу с эквивалентными доменами
  • Удаляем переменные среды
• Открываем базу без ввода пароля
  • Используем командную строку
  • Используем стандартный поток ввода
• Управление работающим KeePass'ом

Фиксируем рабочий каталог

Многие программы — и KeePass 2.x тут не исключение — считают рабочим каталогом место, обусловленное способом запуска, а не своим расположением. Из-за этого при обращении к базам и компонентам программы приходится указывать пути полностью.

Чтобы избежать непредсказуемости в положении рабочего каталога, можно условиться всегда запускать KeePass каким-нибудь стартером, который устанавливает рабочим каталогом расположение программы. Простейшим вариантом будет батник Run.bat, лежащий в каталоге программы и состоящий из строки

start "" /d "%~dp0" KeePass.exe

Этот батник можно будет запускать уже произвольным способом, например, ярлыком на рабочем столе (для красоты — с измененным значком и опцией свернутого окна).

Теперь, когда рабочий каталог зафиксирован, во многих строках базы и конфигурации можно будет использовать вместо абсолютных путей относительные. Однако не будем злоупотреблять этой возможностью, а все-таки предпочтем указывать абсолютные пути (с помощью заполнителей {APPDIR}, {DB_DIR}, {ENV_PROGRAMFILES_X86}) и заключать их в кавычки. Место, где действительно пригодятся относительные пути, — конфигурация плагинов, не поддерживающих заполнители.

Указываем базу

В зависимости от настройки, KeePass может сразу при запуске предлагать открытие базы, которая закрывалась последней. Это удобно, когда база одна. Но если баз несколько, то зачастую KeePass будет открывать не то, что требуется.

Решить проблему можно по-разному, например, триггером, открывающим нужную базу по событию «Приложение инициализировано». Другой вариант — создать в каталоге программы файл KeePass.config.enforced.xml и зафиксировать в нем «последнюю» базу.

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<Application>
		<LastUsedFile>
			<Path>DBases\Database.kdbx</Path>
		</LastUsedFile>
	</Application>
</Configuration>

Но пожалуй, самый простой и гибкий способ — добавить путь к базе в командную строку. Поскольку наш батник Run.bat делает каталог программы рабочим, будет достаточно указать путь относительно этого каталога, и код примет такой вид:

start "" /d "%~dp0" KeePass.exe "DBases\Database.kdbx"

На место выделенного фрагмента нужно подставить ваш относительный путь к базе. Вообще, во всех примерах этой статьи предполагается замена выделенного кода вашими данными.

Несколько таких батников могут использоваться для разных баз.

Помимо пути к базе, можно заранее подставить и путь к ключевому файлу (если, конечно его расположение не секретно), тогда в диалоге открытия базы останется лишь ввести пароль. Это делается аргументом командной строки -preselect, батник примет вид

start "" /d "%~dp0" KeePass.exe "DBases\Database.kdbx" -preselect:"K:\Database.key"

Аргумент -preselect предназначен для открытия базы именно вручную: он не задает ключевой файл однозначно, а лишь подставляет путь. Перед вводом пароля этот путь можно будет изменить или вообще отказаться от ключевого файла. Похожий аргумент -keyfile имеет другой смысл: в нем указывается путь к ключевому файлу, только когда в командной строке передаются и все остальные компоненты ключа, чтобы открыть базу без диалога. Кроме того, в аргументе -keyfile можно вместо пути указать содержимое ключевого файла, а в аргументе -preselect только путь.

Расположение открываемой базы может быть и удаленным, причем, если соображения безопасности позволяют, можно добавить в командную строку учетные данные подключения:

start "" /d "%~dp0" KeePass.exe https://webdav.mydrive.ch/Database.kdbx -iousername:"myConnectionLogin" -iopassword:"myConnectionPassword" -ioiscomplete

Задаем конфигурацию

Предотвращаем нежелательное сохранение конфигурации

Предположим, в какой-то ситуации портативный KeePass не сможет сохранить конфигурацию. Например, не окажется доступа на запись в каталог программы. Или вы намеренно присвоите файлу KeePass.config.xml атрибут «Только чтение», чтобы не испортить настройку программы.

Некоторым сюрпризом может оказаться, что в этих случаях конфигурация все-таки сохраняется — в профиль пользователя. Пожалуй, это не совсем то, чего ожидаешь от портативного приложения...

Тем не менее, такое поведение соответствует заявленному в официальном руководстве. А чтобы предотвратить запись в профиль пользователя, нужно указать в командной строке другое расположение пользовательской конфигурации — туда изменения и сохранятся.

Будем считать, что портативному KeePass'у не положено сохранять конфигурацию никуда, кроме файла KeePass.config.xml в своем каталоге, поэтому его же и назначим пользовательской конфигурацией. Наш батник примет такой вид:

start "" /d "%~dp0" KeePass.exe "DBases\Database.kdbx" -cfg-local:KeePass.config.xml

Портативный KeePass, запущенный таким батником, будет работать как обычно, когда файл KeePass.config.xml в каталоге программы доступен для записи. А когда недоступен — не произойдет «странного» сохранения конфигурации в профиль пользователя.

Если вам случается открывать один KeePass из другого внутренней ссылкой вида kdbx://путь к базе, то нужно, чтобы и при таком открытии указывалась конфигурация в командной строке. Для этого можно добавить в переопределение схемы kdbx аргумент  -cfg-local:"{APPDIR}\KeePass.config.xml". Несколько более гибкий вариант этого аргумента будет предложен ниже. А в настройке, которая давалась в предыдущей статье, этот аргумент уже присутствует, причем в еще более универсальном виде.

Отступление о конфигурациях

В качестве отступления стоит отметить, что в KeePass'е предусмотрены разные виды конфигурации, позволяющие администраторам довольно гибко ограничивать права пользователей в части настройки программы. Эти права определяются содержимым конфигурационных файлов, лежащих в каталоге программы, поэтому при администрировании запись туда должна быть запрещена ограниченным пользователям.

• В enforced-конфигурации (файле KeePass.config.enforced.xml) задаются значения какой-либо части параметров, при этом они получают наивысший приоритет, многие из них запрещается менять даже на время работы программы.
• Если enforced-конфигурация не устанавливает значение флага PreferUserConfiguration, то оно определяется global-конфигурацией (файлом KeePass.config.xml).
• Если в результате этот флаг остается незаданным или устанавливается в false, то все остальные параметры берутся из global-конфигурации, их разрешается менять.
• Если же этот флаг устанавливается в true, то все параметры, не заданные в enforced-конфигурации, берутся из local-конфигурации — файла, лежащего в профиле пользователя или заданного аргументом командной строки -cfg-local.

Хотя enforced-конфигурация предназначена, в основном, для администрирования, ей можно найти полезное применение и в использовании портативного KeePass'а.

Используем несколько конфигураций

Бывает удобно одновременно использовать KeePass в разных вариантах настройки. Например, один экземпляр KeePass'а может работать с учетными записями, а другой, настроенный более мягко, с закладками. В предыдущей статье предлагалось для этого поместить копию программы и некоторых плагинов в отдельный каталог. Такое решение кажется избыточным — почему бы просто не добавить дополнительную конфигурацию к той же программе?

С этим связана одна тонкость: если вы хотите запускать один и тот же портативный KeePass с разными конфигурациями, то каждый запуск нужно выполнять с аргументами командной строки. Т.е. при таком использовании невозможна «портативная» конфигурация по умолчанию, которая применялась бы в отсутствие этих аргументов.

Таким образом, для базы закладок был предпочтен вариант с отдельным экземпляром KeePass'а, чтобы не усложнять жизнь пользователя дополнительными стартерами. Однако теперь, когда мы к ним немного привыкли, попробуем все-таки добиться от одного портативного KeePass'а работы с разными конфигурациями.

Чтобы разрешить использование произвольных конфигураций, создадим в каталоге программы специальный файл KeePass.config.enforced.xml.

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<Meta>
		<PreferUserConfiguration>true</PreferUserConfiguration>
	</Meta>
</Configuration>

Теперь при каждом запуске KeePass'а будем задавать желаемую конфигурацию аргументом командной строки -cfg-local. Чтобы использовать обычную конфигурацию KeePass.config.xml, будем запускать KeePass батником, состоящим из строки

start "" /d "%~dp0" KeePass.exe "DBases\Database.kdbx" -cfg-local:KeePass.config.xml

Можно добавить другие конфигурации под произвольными именами и соответствующие батники. Например, конфигурацию KeePass.config.B.xml будет применять батник вида

start "" /d "%~dp0" KeePass.exe "DBases\Bookmarks.kdbx" -cfg-local:"KeePass.config.B.xml"

Настроенный таким образом KeePass никогда не должен запускаться без аргумента -cfg-local — иначе он сохранит конфигурацию в профиль пользователя.

Позаботимся, чтобы этот аргумент подставлялся, когда мы открываем какую-либо базу в новом окне KeePass'а ссылкой вида kdbx://путь к базе. Будем считать, что расположение конфигурации задается полем Cfg текущей записи. Если это поле всегда задано, достаточно просто добавить в переопределение схемы kdbx (Параметры → Интеграция → Переопределение URL) аргумент  -cfg-local:"{S:Cfg}". Но если в каких-то kdbx-записях этого поля может не быть, понадобится более сложная конструкция.

Если вы пользуетесь настройкой из предыдущей статьи, то менять схему kdbx не нужно — в ней уже предусмотрено наличие или отсутствие поля Cfg и многое другое.

Если вы решите использовать таким способом готовую конфигурацию для закладок, предложенную в предыдущей статье, замените в ней все вхождения {T-REPLACE-RX::{APPDIR}:.{10}$::} на {APPDIR} и сохраните ее под именем KeePass.config.B.xml, а в записи, открывающей базу закладок, добавьте поле Cfg со значением {APPDIR}{ENV_DIRSEP}KeePass.config.B.xml и удалите поле AppPath.

Используем переменные среды

Ссылаемся на локальные ресурсы

В базе могут присутствовать различные ссылки на локальные ресурсы, например, пути запускаемых приложений. При этом одна база зачастую используется на нескольких ПК и синхронизируется между ними. Поэтому возникает задача, как сделать базу не зависящей от окружения.

Решение, предложенное в предыдущей статье — ссылаться в базе не на сами программы, а на их ярлыки, расположенные рядом с KeePass'ом. Однако это решение имеет кое-какие ограничения.

Другой подход — использование переменных среды. Эти переменные можно назначать в батнике, запускающем KeePass. Например, добавим в начало этого батника строку

set "KeePass_VeraCrypt=c:\Program Files\VeraCrypt\VeraCrypt.exe"

Теперь в базе или в конфигурации KeePass'а можно будет вместо пути к программе VeraCrypt употреблять код %KeePass_VeraCrypt%. Таким образом, на разных ПК будет достаточно завести разные батники. А там, где используется портативная VeraCrypt, каталог которой расположен рядом с каталогом KeePass'а, подойдет батник, определяющий путь к VeraCrypt, исходя из собственного расположения:

cd /d "%~dp0.."
set "KeePass_VeraCrypt=%cd%\VeraCrypt\VeraCrypt.exe"
start "" /d "%~dp0" KeePass.exe "DBases\Database.kdbx" -cfg-local:KeePass.config.xml

Подобным образом можно определить в батнике несколько переменных среды и использовать их в KeePass'е. Например, зададим расположение открываемых баз (абсолютный путь), место сохранения их резервных копий и количество хранимых версий одной базы:

cd /d "%~dp0"
set "KeePass_DBDir=%cd%\DBases"
set "KeePass_BackupDir=R:\Backup\KeePassDB"
set "KeePass_BackupNumber=100"
start "" /d "%~dp0" KeePass.exe "%KeePass_DBDir%\Database.kdbx" -cfg-local:KeePass.config.xml

Теперь созданные переменные можно будет использовать в триггере резервного копирования. А меняя значения этих переменных, можно будет переносить конфигурацию с этим триггером на разные ПК, в т.ч. с непортативным KeePass'ом, требующим хранить базы отдельно от программы.

Если вы используете настройку, предложенную в предыдущих статьях и желаете варьировать расположение каталога с базой, замените в файлах конфигурации все вхождения {APPDIR}{ENV_DIRSEP}DBases на %KeePass_DBDir%.

Заметим, что для настройки триггеров необязательно прибегать к переменным среды, так как на разных ПК конфигурацию можно сделать разной, в отличие от синхронизируемой базы. Но переменные среды упрощают изменение настройки.

Переменные среды наследуются дочерними процессами, поэтому новое окно KeePass'а, открытое kdbx-ссылкой, будет работать с этими же значениями переменных.

Оптимизируем работу с эквивалентными доменами

Способ использования KeePass'а, предложенный в предыдущих статьях, позволяет учитывать эквивалентные домены при глобальном автонаборе. Например, чтобы на странице https://passport.yandex.ru вводились учетные данные из записи со ссылкой https://mail.yandex.by

Каждый набор эквивалентных доменов задается отдельной записью в группе domains: заголовок записи состоит из доменов, разделенных знаками |, а также начинается и оканчивается этим знаком.

Напомню, как реализована поддержка эквивалентных доменов. У каждой записи в качестве ассоциированного окна и адреса прописан код, который интерпретируется KeePass'ом как регулярное выражение, определяемое URL'ом записи. При этом непосредственно в записях указан не сам код, а ссылка на него. Благодаря этому не требуется обновлять все записи, чтобы менять этот код — достаточно редактировать лишь служебную запись <Associations>. Код хранится в ней в преобразованном виде, с экранированными знаками {; при обращении к нему выполняется обратное преобразование.

Однако многократные обращения к служебной записи и преобразования кода замедляют работу KeePass'а при глобальном автонаборе. Кроме того, можно заметить, что выбор кода зависит от внешней среды: от настройки браузеров, от мощности ПК. Поэтому хранение кода в базе выглядит не лучшей идеей.

Заменим ссылки на служебную запись переменными среды — тогда этот код вынесется за пределы базы и его можно будет сделать разным для разных ПК. Вместе с тем повысится быстродействие, так как из переменых среды будет поступать готовый код, не требующий обратного преобразования.

Итак, URL-ссылку записи <Associations> сохраним в файле TargetUrl.txt в подкаталоге Scripts. Двойным кликом скопируем пароль этой записи и сохраним там же в файле TargetTitle.txt. Затем в обоих файлах заменим все вхождения {{} на {.

В батнике, запускающем KeePass, инициализируем переменные среды содержимым этих файлов:

cd /d "%~dp0"
set /p "KeePass_TargetUrl="<"Scripts\TargetUrl.txt"
if "%KeePass_TargetUrl%"=="" set "KeePass_TargetUrl={C:}"
set /p "KeePass_TargetTitle="<"Scripts\TargetTitle.txt"
if "%KeePass_TargetTitle%"=="" set "KeePass_TargetTitle={C:}"
start "" /d "%~dp0" KeePass.exe "DBases\Database.kdbx" -cfg-local:KeePass.config.xml

Теперь ассоциируем каждую запись с адресом %KeePass_TargetUrl% и заголовком %KeePass_TargetTitle%. Это можно сделать ручным редактированием или разными вариантами XML-замены (Сервис → База данных → XML-замена). Чтобы в дальнейшем новые записи имели готовые ассоциации с адресом и заголовком, будем создавать их по шаблонам.

Удаляем переменные среды

Переменные среды, предназначенные KeePass'у, могут унаследоваться браузерами и другими приложениями, которые он запустит. Можно не считать это проблемой и ничего не предпринимать, если имена и значения переменных не являются секретом.

Впрочем, в случае настройки, предложенной в предыдущей статье, и не наблюдается наследования переменных среды. Дело в том, что при этой настройке браузеры и другие приложения запускаются KeePass'ом, в основном, через проводник. Даже когда запуск приложений выполняется по схеме cmdDirect, без участия проводника, он происходит через скрипт Run.js, который удаляет все переменные, чьи имена начинаются на KeePass_.

Открываем базу без ввода пароля

Используем командную строку

В командной строке можно передать компоненты ключа: аргументом -pw — мастер-пароль, аргументом -keyfile — ключевой файл (путь или содержимое в виде data: URL), аргументом -useraccount сообщить о шифровании учетными данными Windows. Должны быть указаны все компоненты, которыми зашифрована открываемая база.

start "" /d "%~dp0" KeePass.exe "DBases\Database.kdbx" -pw:"myMasterPassword" -keyfile:"K:\Database.key" -cfg-local:KeePass.config.xml

Однако передавать мастер-пароль в явном виде весьма опасно, так как аргументы командной строки легко увидеть, например, в диспетчере задач, и главное, они нередко логируются. (И само собой, недопустимо открыто хранить этот пароль в батнике.)

Относительно защищенный вариант — передавать в командной строке мастер-пароль, зашифрованный данными учетной записи Windows:

start "" /d "%~dp0" KeePass.exe "DBases\Database.kdbx" -pw-enc:"зашифрованный пароль" -keyfile:"K:\Database.key" -cfg-local:KeePass.config.xml

Чтобы получить «зашифрованный пароль», который нужно подставить в эту команду, понадобится создать запись с мастер-паролем базы в качестве пароля и логином {PASSWORD_ENC}, скопировать логин двойным кликом и вставить в батник, а затем удалить запись или просто закрыть базу без сохранения.

Но теперь открытие базы сводится к доступу в учетную запись пользователя: злоумышленнику достаточно завладеть зашифрованным мастер-паролем (например, получив логи запуска программ или тот же батник) и войти в учетную запись, причем сделать это можно в разное время и в разном порядке. В частности, теряет всякий смысл блокировка базы. Кстати, об этом нужно помнить, открывая какую-либо базу в новом окне kdbx-ссылкой: такое открытие ставит ее мастер-пароль под удар. Безопаснее открывать базу в новой вкладке того же окна с помощью триггеров.

Используем стандартный поток ввода

Помимо командной строки, KeePass предоставляет еще один способ передачи мастер-пароля — через стандартный поток ввода. Этот вариант выглядит безопаснее предыдущих. Для его применения KeePass должен запускаться с аргументом -pw-stdin. Такую передачу мастер-пароля способен выполнить батник

cd /d "%~dp0"
echo.myMasterPassword|KeePass.exe "DBases\Database.kdbx" -pw-stdin

Непонятно однако, откуда мастер-пароль возьмется в самом батнике — не хранить же его там в явном виде... Несколько спорное решение — прочитаем пароль из файла на шифрованном диске.

Предположим, перед запуском KeePass'а монтируется VeraCrypt-контейнер, например, зашифрована сама ОС. Разрешим в VeraCrypt кэширование пароля (в случае шифрованной ОС — Настройка → Шифрование системы → Кэшировать пароль дозагрузочной аутентификации). Создадим контейнер VeraCrypt минимального размера, защищенный тем же паролем, и поместим в него файл, содержащий мастер-пароль базы. Теперь будем запускать KeePass батником, который монтирует этот контейнер, считывает мастер-пароль, демонтирует, очищает кэш VeraCrypt и запускает KeePass, передавая ему мастер-пароль через стандартный поток ввода.

@echo off
set "KeePass_VeraCrypt=c:\Program Files\VeraCrypt\VeraCrypt.exe"
cd /d "%~dp0"
start "" /i /wait "%KeePass_VeraCrypt%" /v "DBases\Database.pw" /l P /m ro /m rm /q /s
setlocal enableextensions enabledelayedexpansion
set /p "KeePass_MP="<"P:\Password.txt"
start "" /i "%KeePass_VeraCrypt%" /d P /f /w /q /s
endlocal & echo.%KeePass_MP%|KeePass.exe "DBases\Database.kdbx" -keyfile:"K:\Database.key" -cfg-local:KeePass.config.xml -pw-stdin

Считаем, что база Database.kdbx и криптоконтейнер Database.pw с ее паролем лежат в одном подкаталоге DBases, пароль записан в файле Password.txt в корне виртуального диска, для временного монтирования используется буква «P». Батник Run.bat устроен так, чтобы KeePass и VeraCrypt не унаследовали переменную с мастер-паролем.

Таким образом, вместо двух паролей, от шифрованного диска и от базы, будем вводить один. Если заблокировать базу, то повторно она уже не откроется батником, поскольку будет очищен кэш VeraCrypt. В случае шифрования ОС имеет смысл добавить батник в автозагрузку, чтобы очистка кэша произошла как можно скорее.

Впрочем, батник здесь неудобен, так как при таком запуске KeePass'а интерпретатор не завершается сам и приходится закрывать консольное окно вручную. Воспользуемся вместо него WSH-скриптом. Этот вид скрипта годится и для предыдущих приемов с использованием рабочего каталога, аргументов командной строки и переменных среды — все они присутствуют в коде.

var WshShell = WScript.CreateObject('WScript.Shell');
var ProcEnv = WshShell.Environment('process');
var FSO = WScript.CreateObject('Scripting.FileSystemObject');

/* считаем, что скрипт лежит в каталоге программы */
var keepass_dir = FSO.GetAbsolutePathName(FSO.GetFile(WScript.ScriptFullName).ParentFolder);

/* каталог программы назначается рабочим */
WshShell.CurrentDirectory = keepass_dir;

var veracrypt = 'c:\\Program Files\\VeraCrypt\\VeraCrypt.exe'; // путь к VeraCrypt
var container = 'DBases\\Database.pw'; // путь к контейнеру
var letter = 'P'; // буква для монтирования

/* переменным среды присваиваются явные значения */
ProcEnv('KeePass_DBDir') = keepass_dir + '\\DBases'; // абсолютный путь к каталогу с базами
ProcEnv('KeePass_BackupDir') = 'DBases\\BackUp'; // путь к каталогу с бэкапами
ProcEnv('KeePass_BackupNumber') = '100'; // число бэкапов одной базы
ProcEnv('KeePass_VeraCrypt') = veracrypt;

/* переменным среды присваивается содержимое файлов */
setEnvVarFromFile('KeePass_TargetUrl', 'Scripts\\TargetUrl.txt');
setEnvVarFromFile('KeePass_TargetTitle', 'Scripts\\TargetTitle.txt');

try {
	WshShell.Run('"' + veracrypt + '" /v "' + container + '" /l ' + letter
		+ ' /m ro /m rm /q /s', 1, true);
	var pw = readFile(letter + ':\\Password.txt');
} finally {
	WshShell.Run('"' + veracrypt + '" /d ' + letter + ' /f /w /q /s');
}

WshShell.Exec('KeePass.exe'
	+ ' "DBases\\Database.kdbx"' // открываемая база
	+ ' -keyfile:"K:\\Database.key"' // ключевой файл (опциональная строка)
	+ ' -cfg-local:"KeePass.config.xml"' // конфигурация (опциональная строка)
	+ ' -minimize' // свернуть KeePass (опциональная строка)
	+ ' -pw-stdin'
).StdIn.WriteLine(pw);

function readFile(path) {
	try {
		var textStream = FSO.OpenTextFile(path, 1, false, 0);
		return textStream.readAll();
	} catch (e) {
		return "";
	} finally {
		textStream && textStream.close();
	}
}

function setEnvVarFromFile(var_name, path) {
	var env_val = readFile(path);
	ProcEnv(var_name) = env_val ? env_val : '{C:}';
}

Предупрежу, что каким бы способом вместо обычного набора мастер-пароль ни передавался KeePass'у, снятие дампа памяти грозит утечкой этого пароля, причем даже после блокировки базы.

Управление работающим KeePass'ом

Хотя статья посвящена параметрам запуска, в дополнение перечислим аргументы командной строки, которыми можно управлять уже запущенной программой:

• автонабор для выбранной записи: -auto-type-selected
  (но если работает несколько KeePass'ов, набираемые данные могут непредсказуемо перемешаться);
• глобальный автонабор для всех работающих KeePass'ов: -auto-type
  (избежать смешения данных поможет опция Всегда показывать окно выбора записи для глобального автонабора);
• глобальный автонабор пароля для всех работающих KeePass'ов: -auto-type-password
• открытие ссылки для записи с заданным идентификатором: -entry-url-open -uuid:идентификатор
  (например, в случае kdbx-ссылки эта команда откроет какую-либо базу в новом окне KeePass'а);
• закрытие всех KeePass'ов (не принудительное): -exit-all
• блокировка всех KeePass'ов: -lock-all
• разблокировка всех KeePass'ов: -unlock-all
• отмена открытия/сохранения базы во всех KeePass'ах (например, при зависании): -cancel
• отправка произвольного сообщения плагинам всех KeePass'ов: -e:сообщение
  (как и на какие сообщения реагировать, определяется плагинами);
• отправка произвольного сообщения плагинам одного KeePass'а: -e1:сообщение
  (если работает несколько KeePass'ов, то не определено, который из них получит сообщение).