Привет, @command_tab, пожалуйста, напиши шаги, которые нужно выполнить, чтобы запустить decrypt.sh. Я застрял на этом месте.

Я уверен, что ты можешь обратить тот openssl-команду, которая выполняет дешифрование. Посмотри на её параметры и просто сделай всё в обратном порядке.

Кстати, это отлично работает и с файлом поддержки:  
Если на Linux, пропускайте инструкции для Windows и сразу переходите к первой команде.  
Если на Windows 10, установите Windows Subsystem for Linux.  
https://docs.microsoft.com/en-us/windows/wsl/install-win10  
Я выбрал Ubuntu 18 — наверно, это не так уж важно. А если вы на Linux, просто продолжайте дальше.  

Использовал скрипт отсюда как вдохновение: https://github.com/zhangyoufu/unifi-backup-decrypt/blob/master/decrypt.sh  
Скрипт не сработал, и вместо того чтобы его отлаживать, я просто выполнил две команды вручную.  

Сначала расшифруйте файл:  
eric@DESKTOP:/mnt/c/users/erice/Documents$ openssl enc -d -in "unifi-20190707-2225.supp" -out "unifi-20190707-2225.supp.tmp" -aes-128-cbc -K 626379616e676b6c756f686d617273 -iv 75626e74656e74657270726973656170 -nosalt -nopad  

Потом распакуйте его:  
eric@DESKTOP:/mnt/c/users/erice/Documents$ zip -FF "unifi-20190707-2225.supp.tmp" --out supp  

Fix archive (-FF) - сохраняем, что можно  
zip warning: End record (EOCDR) only 16 bytes - assume truncated  
Это архив на одном диске?  
(y/n): y  

Предполагается архив на одном диске  
Сканируем записи...  
копируем: system.properties (643 байта)  
копируем: devices/ (2 байта)  
копируем: devices/uap/ (2 байта)  
копируем: devices/uap/04-18-d6-a0-aa-d3/ (2 байта)  
копируем: devices/uap/04-18-d6-a0-aa-d3/last.inform (13304 байт)  
копируем: devices/uap/04-18-d6-a0-aa-d3/last.inform_connected (13304 байт)  
копируем: devices/uap/f0-9f-c2-c8-aa-43/ (2 байта)  
копируем: devices/uap/f0-9f-c2-c8-aa-43/last.inform (11810 байт)  
копируем: devices/uap/f0-9f-c2-c8-aa-43/last.inform_connected (11810 байт)  
копируем: devices/usw/ (2 байта)  
копируем: devices/usw/f0-9f-c2-62-aa-f7/ (2 байта)  
копируем: devices/usw/f0-9f-c2-62-aa-f7/last.inform (12379 байт)  
копируем: devices/usw/f0-9f-c2-62-aa-f7/last.inform_connected (12379 байт)  
копируем: devices.json (10412 байт)  
копируем: support_info.json (45009 байт)  
копируем: logs/ (2 байта)  
копируем: logs/server.log.1 (680407 байт)  
копируем: logs/server.log.2 (671128 байт)  
копируем: logs/server.log.3 (671200 байт)  
копируем: logs/server.log (630151 байт)  
копируем: logs/mongod.log (521032 байт)  
копируем: logs/remote/ (2 байта)  
Центральный каталог найден...  
EOCDR найден ( 1 3308092)...  

Вот и всё — создаётся восстановленный zip-файл с именем supp.zip (если вы используете имя output файла supp, как я). Теперь его можно спокойно изучать.

Я просто хочу заглянуть в проклятый .UNF файл, чтобы достать этот бессмысленный оригинальный guest background.png, а ни один из вариантов не работает. .sh файл выдает ошибку сразу после быстрой декодировки: zip error: Invalid command arguments (no such option: -). Красиво и загадочно. Psm1 файл просто висит, пока не съедает 32 ГБ оперативки, а потом выдает безумно длинную ошибку. Невероятно, что у нас нет никакого ПРОСТОГО способа ДОСТУПА К ЭТИМ ДАННЫМ! Спустя час я ни на шаг не приблизился!

Ок, спустя несколько часов, всё, что мне нужно было сделать — это удалить cygwin, потому что это была сплошная трата времени, установить VMWare для запуска Ubuntu 16.04, настроить его часа целого, и ТОЛЬКО ПОТОМ decrypt.sh наконец-то создал zip-файл. Легкотня... 😐

Привет. Кажется, я что-то не понимаю... Может, ты подскажешь, как правильно сделать. Я пытался так:

Использую Windows 10 Pro 64bit, обновлён до 1803, старый железный Pentium G630, 8GB RAM (именно на нём у меня работает Hyper-V для unifi-Controller). Нажал клавишу Windows, написал powershell, нашёл WindowsPowerShell ISE, кликнул правой кнопкой и запустил от имени администратора.

Потом вводил: CD (потом путь, в котором хотел работать).

Затем написал: Set-ExecutionPolicy Unrestricted.

Скачал файл бэкапа unifi с контроллера в ту папку, куда переходил.

Открыл блокнот, скопировал туда код отсюда: https://github.com/justingist/POSH-Ubiquiti/blob/master/Posh-UBNT.psm1 и сохранил файл в нужной директории под именем Posh-UBNT.psm1.

После этого ввёл: import-module .\Posh-UBNT.psm1 — получил вот такое предупреждение:  
WARNUNG: Die Namen einiger importierter Befehle auf Modul "Posh-UBNT" enthalten nicht genehmigte Verben, sodass deren Auffindbarkeit erschwert werden kann. Wenn Sie die Befehle mit nicht genehmigten Verben finden möchten, führen Sie den Import-Module-Befehl erneut mit dem Verbose-Parameter aus.......  

Поскольку я не понял, что здесь подразумевают под «глаголами» (verbs) в этом контексте, решил пропустить это.

Дальше ввёл: Decrypt-UBNTBKP -ubntbkp .\pathtomy.unf — выполнение около 10 секунд — после этого получил очень длинное сообщение об ошибке с такими словами:  
- ObjectNotFound  
- InvalidOperation  
- RuntimeException  
- NULL  

Думаю, это из-за предупреждения при импорте .psm1 модуля.

Что я сделал не так? Как правильно запускать этот скрипт?

Все довольно просто, какая часть у тебя вызывает вопросы? Думаю, я смогу прояснить! Возможно, я забыл упомянуть, что предполагал, что люди знают, как загружать код как модуль. Если ты в директории, куда скачал файл, можешь запустить: import-module .\Posh-UBNT.psm1 После этого следуй инструкциям по команде, подставляя путь к своему .unf файлу. Там есть полезные советы о том, как базу данных преобразовать с помощью других инструментов после расшифровки, но я этого не тестировал. Если тебе нужен просто пароль, его можно достать через текстовый редактор, если не планируешь делать с данными ничего сложного.

Окей, ребята, я не совсем понял, как запускать всю эту связку bash + java, поэтому посмотрел, что там происходит, и переписал это на PowerShell. Похоже, работает отлично, на выходе получается файл tar.gz:  
Использование: Decrypt-UBNTBKP -ubntbkp .\pathtomy.unf  
Выходной файл — tar.gz в той же папке, где находился исходный файл. Для открытия используйте любимую программу для архивов, например 7-zip.  
https://github.com/justingist/POSH-Ubiquiti/blob/master/Posh-UBNT.psm1

Это сработало у меня: https://github.com/zhangyoufu/unifi-backup-decrypt Похоже, что файл .unf — это зашифрованный zip-архив, и (я так полагаю) автор этого репозитория на GitHub извлек ключи из Cloud Key или программного обеспечения Controller. Я просто запустил нужные shell-команды из .sh файла в репозитории и смог распаковать содержимое очень свежего .unf-бэкапа. Распакованный архив включает версию контроллера, с которой сделан бэкап, отметку времени бэкапа, базу данных статистики, конфигурационную базу данных, созданные мной изображения карты сайта и прочее. Всё, что обычно ожидаешь увидеть в резервной копии! Статистические и конфигурационные базы данных в формате BSON (Binary JSON). В MongoDB есть инструмент `bsondump`, который может конвертировать их в обычный JSON, выполнив `bsondump db > db.json`. После этого я смог обработать эти базы любым JSON-инструментом или скриптом. Надеюсь, это поможет!

Хотя большинство моих облачных контроллеров без проблем восстанавливаются после отключения питания, по неизвестным мне причинам некоторые из них просто не запускаются правильно (или вообще не запускаются) после любого перерыва в питании. Связано это или нет, но эти же несколько устройств, у которых возникает такая проблема, практически всегда повреждают все файлы на локальной карте памяти. В итоге каждый раз, когда случается сбой питания, вернуть всё в рабочее состояние — настоящее мучение.

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

Обновление прошивки на проблемных Cloud Key не помогло, а хоть они и недорогие, сейчас у меня слишком много других расходов, чтобы менять эти устройства, особенно когда в остальное время они работают нормально. Кстати, проблемы с Cloud Key не связаны с плохим питанием — я заменил недорогие блоки питания, которые изначально их обслуживали, на более качественные, а потом просто подключил их к PoE-коммутаторам, которые питают точки доступа (а они уже запитаны через ИБП).

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