Как найти uart на ip камере

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

Сначала опишу, как я дошёл до жизни такой, но, если это не очень интересно, то переходите сразу к пункту об изготовлении переходника – дальше только по делу и никакой лирики.

Предыстория

Не так давно выполняли монтаж по чужому проекту, где было использовано оборудование RVi – регистратор, PoE-коммутаторы и IP-видеокамеры. Если бы проект делал я, то никогда бы не выбрал такой вариант, ибо дорого и глючно.

Запуск системы

Запуск системы в работу прошёл без проблем. За исключением того, что на мониторе, подключенном к самому регистратору, нельзя было настроить те режимы экрана, которые хотел заказчик. Самое смешное, что выбор режимов есть, но вот камеры в них расположены по-порядку. Этот порядок можно менять, но он один для всех режимов. Сложно это описать словами, но, поверьте, что это бред. На компьютере, в ПО удалённого рабочего места, режимы экрана можно сделать любые, но родное ПО RVi Оператор 2, глючное и ресурсоёмкое. Пришлось ставить ПО от Dahua – SmartPSS, поскольку регистратор и камеры, на самом деле, производства этой компании. Со SmartPSS позже вылезла странная проблема, которую пока не победили. Периодически, со слов заказчика – после каждого обновления Windows, эта софтина перестаёт запускаться. Никаких ошибок не выдаёт ни на экран ни в лог, просто не запускается. Если снести и установить заново, продолжает работать до следующего раза. Скорее всего, это проблема конкретного компьютера – будем разбираться.

Зависания

Через некоторое время эксплуатации выяснилось, что камеры периодически зависают. Снова возвращаются к работе только после сброса питания. Коммутаторы в проекте были самые дешёвые, соответственно, ни о каком автоматическом или удалённом перезапуске речи нет. Надо было что-то делать. Первое, что приходит в голову – обновить прошивку! Тем более, что однажды, после обновления прошивки на другой камере их же производства, заметил новую опцию: Автоперезагрузка, что во-первых, наводит на мысль, что подобная проблема разработчику известна, а во-вторых, даёт надежду на решение имеющейся проблемы. Костыль конечно, но раз такая возможность предусмотрена самим разработчиком, грех не воспользоваться.

Новая прошивка

Полез на сайт производителя, нашёл страницу своей камеры и увидел, что предлагается две версии прошивки.

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

Получилось следующее – камеры пошли прошиваться, но обратно не вернулись. Пропали с радаров и ушли в циклическую перезагрузку, а заодно стали вешать все камеры с коммутаторов, к которым были подключены. Что-то они такое выдавали в сеть, что видеопоток с других камер жутко тормозил и прерывался. Пришлось проблемные камеры отключить, а потом и снять для опытов в лабораторных условиях.

Поддержка RVi

Написал письмо в поддержку с объяснением ситуации. Ответа не получил. Позвонил по телефону, пообщался, но ничего полезного для себя не почерпнул. Только общие фразы и стандартные советы. Потом воспользовался возможностью открыть обращение в поддержку на сайте. Вот тут всё получилось – обстоятельно пообщался с одним из сотрудников, который выслал мне прошивку для восстановления через UART и инструкцию. Хотя присланная прошивка оказалась не та, а инструкция устаревшая, но порадовало то, что сотрудники поддержки RVi верят в людей и не предлагают сразу отправить нерабочую камеру к ним, а помогают восстановить её своими силами. Возможно, с их помощью, я потратил бы меньше времени на самостоятельные изыскания, но взялся я за это дело в воскресенье, когда поддержка была на выходном.

Проблема с подключением

Возникла новая проблема – на плате не распаяно гнездо UART и в местных магазинах радиотоваров подходящего я не нашёл. Пробовал колхозить, но не очень получалось и было не очень понятно – то ли что-то с контактом, то ли с софтом. Заказал разъём с Али. Точнее сразу десяток, потому что продавались только десятками и хотел впаивать в гнездо плату камеры, а камер несколько. Вариантов у поставщика много, но к этой камере подходит 4Pin JST 1.25mm.

Изготовление переходника

После получения посылки с комплектами разъёмов изготовил переходник для USB-TTL адаптера, припаяв к одним проводкам другие проводки тех же цветов и завернув всё это в термоусадку. Красный провод +5В нам не понадобится, поэтому его просто засунул под термоусадку, чтобы не болтался.

Сначала я использовал другой адаптер CH340G. Мне он больше нравится, т.к. компактнее. Но с ним не получалось остановить загрузку камеры. Благо был ещё и универсальный CH341A, который брал для заливки дампов, но тут он пришёлся, как нельзя кстати и спас ситуацию. Стоит помнить, что не все адаптеры одинаково полезны.

Распиновка контактов UART на плате камеры отличается от распиновки контактов USB-TTL адаптера, а именно: RX и TX поменяны местами. Поэтому при подключении последовательность проводов будет одинаковой – чёрный, жёлтый зелёный. Главное правильно определить контакт GND на плате. Если подключить разъём зеркально, то на контакт TX адаптера придёт +5В и адаптер выйдет из строя.

Гнездо на плату можно припаять, тогда контакт заведомо будет отличным. Если, как и мне, не хочется, то ножки гнезда нужно вставить в отверстия так, чтобы кабель был немного внатяг и ножки плотно прилегали к краям.

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

Прошивка

Прошивка представляет собой один файл с расширением .BIN, но, по факту, это ZIP-архив с изменённым заголовком: с PK на DH. это можно увидеть и исправить, открыв этот файл в HEX-редакторе. С другой стороны, архиватор 7-Zip открывает и распаковывает такой файл и с неправильным заголовком. По этому пути и пойдём.

Инструменты

1. 7-Zip – архиватор для распаковки прошивки;
2. Cisco TFTP-сервер – TFTP-сервер для передачи файлов;
3. NCOM – программа для работы через UART;
4. ConfigTool – поисковая утилита для камер Dahua.

Полезные ссылки

1. RVi_IPC_V2.680.00 – проверенная прошивка;
2. RVi_IPC_V2.680.00_unpacked – уже распакованная прошивка;
3. Dahua IPC unbricking / recovery over serial UART and TFTP – топик на буржуйском форуме, который очень помог в понимании, что и как делать.
4. Краткая пользовательская инструкция по быстрому и легкому восстановлению прошивок IP-камер Dahua / восстановление по TFTP – это описание способа восстановления без использования UART. У меня камера была на руках, как и USB-TTL адаптер, поэтому сделал по своему, хотя в поле более подходит другой вариант. Если доберусь, то переработаю и опишу своими словами.

Подготовка к прошивке

1. Скачать и установить 7-Zip;
2. Скачать и распаковать Cisco TFTP-сервер;
3. Скачать и распаковать NCOM;
4. Скачать и распаковать ConfigTool;
5. Скачать и распаковать RVi_IPC_V2.680.00;
6. Щёлкнуть правой кнопкой по файлу RVi_IPC_V2.680.00.bin и выбрать из контекстного меню 7-Zip->Распаковать в “RVi_IPC_V2.680.00/”;
7. Подключить камеру к сетевому адаптеру компьютера или коммутатору;
8. Подключить USB-TTL адаптерк камере и компьютеру и через диспетчер устройств посмотреть какой виртуальный COM-порт он занимает;
9. Запустить Cisco TFTP-сервер и открыть окно параметров через меню View->Options, в поле ввода TFTP server root directory выбрать папку, в которой лежат файлы распакованной прошивки;
10. Запустить NCOM и открыть окно параметров COM-порта через меню Options->Com, выбрать COM-порт, к которому подключен USB-TTL адаптер и задать скорость 115200;

Алгоритм прошивки

1. Подать питание на камеру и одновременно с этим быстро нажимать клавишу * для остановки загрузки;
2. В консоли вбить команду print и посмотреть параметры autolip (адрес камеры, обычно 192.168.1.251) и serverip (адрес TFTP-сервера, обычно 192.168.254.254)
3. В консоли выполнить команду setenv serverip 192.168.1.128, где 192.168.1.128 – это адрес компьютера, на котором запущен TFTP-сервер;
4. Выполнить команду save для сохранения внесённых изменений в постоянной памяти;
5. Выше в выдаче команды print есть список макросов для прошивки, а среди файлов распакованной прошивки есть файл в названием Install и если открыть его блокнотом, то можно увидеть список и порядок запуска этих макросов;
6. Выполнить команду run da;
7. Выполнить команду run dp;
8. Выполнить команду run dk;
9. Выполнить команду run dw;
10. Выполнить команду run du;
11. Выполнить команду run dd;
12. Выполнить команду reset;
13. Запустить ConfigTool и ждать появления камеры в списке, периодически нажимая на кнопку обновления.
14. Прошивка не сбрасывает камеру на заводские настройки, но сделать это рекомендуется – замыканием контактов RESET в течение 10 секунд.

Резюме

Камера восстановлена! А самое полезное во всей этой истории то, что получен бесценный опыт, который лишним не бывает.

Процедура обновления

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

Обновление устройства можно произвести двумя способами: устройство самостоятельно скачивает прошивку и обновляется, или пользователь находит свежую версию, загружает через Web-интерфейс или CMS, и далее обновление идёт по тому же сценарию.
Для минимизации проблем, в прошивке содержится специальный файл-описатель InstallDesc в котором содержится идентификатор платформы «Hardware», по которому устройство проверяет, подходит ли ему загружаемая прошивка, сравнивая его содержимое с файлом ProductDefinition внутри прошивки.
Также есть отдельное поле «Vendor», которое обычно содержит «General».
Поле «Vendor» введено для производителей оборудования, которые помимо собственно сборки, добавляют также дополнительные функции, особые параметры работы или просто меняют заводское распределение памяти. Таким образом, осуществляется простейшая защита копирайта, а также от заливки несовместимой прошивки.
Если совпали оба этих поля, запускается процедура обновления, в противном случае выдаётся сообщение об ошибке.
Прошивка представляет из себя переименованный .zip архив, который содержит несколько .img файлов — разделов дампа со специальным заголовком в 64 байта, а также уже упоминаемый файл-описатель InstallDesc. Пример типового содержимого прошивки:
InstallDesc
u-boot.bin.img
u-boot.env.img
romfs-x.cramfs.img
user-x.cramfs.img
web-x.cramfs.img
custom-x.cramfs.img
У регистраторов ещё есть раздел с логотипом logo-x.cramfs.img
Обновление осуществляется по разделам, поэтому в случае прерывания процедуры обновления, повреждённым оказывается лишь один раздел.
u-boot.bin — это сам загрузчик u-boot, прошивается первым и почти всегда остаётся целым благодаря малым размерам. Помимо процедуры запуска, u-boot содержит также процедуры вывода на экран логотипа (у регистраторов), а также — самое важное — скрипты восстановления модулей прошивки.
Именно поэтому мы и видим на экране сбойного устройства «матрас» или логотип производителя.
Если логотип не пропадает, а устройство не переходит в рабочий режим, значит повреждён один из блоков прошивки, но сам загрузчик цел, и устройство можно относительно просто и недорого восстановить.

При повреждённом загрузчике мы получаем полный «кирпич», описываемый здесь метод уже не применим, восстанавливать придётся на программаторе, в данной статье его рассматривать не будем.

Общение с загрузчиком производится из консоли командами, которые подаются через специальный отладочный интерфейс — UART. В качестве консоли (терминала) удобнее использовать Putty (Kitty), хотя сгодится даже встроенный в Windows гипертерминал.
Чтобы иметь возможность слать команды из терминала, нам понадобится USB-UART преобразователь.
Самый распространённый — это преобразователь на базе микросхемы Prolific PL-2303HX. Для восстановления одного устройства его будет достаточно, но если вы профессионально занимаетесь ремонтом, лучше приобрести преобразователь на базе микросхемы FTDI FT232R, он более надёжный и не так подвержен помехам в линии.

Подключив UART преобразователь, получим в системе дополнительный последовательный COM порт, номер которого нужно узнать в диспетчере устройств. Этот номер указываем в программе-терминале, а также задаём другие параметры порта: скорость 115200, чётность нет, стоп. бит 1.

Для подключения соединяем минусовой («земляной») провод устройства с общим (GND) проводом преобразователя, RX устройства соединяем с TX преобразователя, а RX, соответственно, с TX.

Включаем устройство и наблюдаем такую картинку:

Это лог загрузки. На короткое мгновение на экране мелькнёт приглашение Press Ctrl+C to stop autoboot. Нужно поймать этот момент и нажать комбинацию клавиш Ctrl+C, после чего мы попадаем в командный интерфейс загрузчика.
Даём команду printenv, это выведет на экран переменные окружения загрузчика и сообщит нам дополнительную информацию о подопытном.

Нас пока интересуют два параметра:
ipaddr=192.168.1.10 — IP адрес устройства
serverip=192.168.1.107 — IP адрес нашего компьютера
их можно изменить командой setenv или подставить компьютеру IP адрес из serverip на время восстановления.

TFTP сервер

Поиграв с командами, вероятно, вы захотите пойти дальше и восстановить устройство.
Для этого нам понадобится ещё одна программа — TFTP сервер, я рекомендую tftpd32.

Устанавливаете его и настраиваете согласно картинке.

Бэкап — наше всё

Теперь подключаем нашу многострадальную камеру/регистратор сетевым кабелем к той же сети, что и компьютер с программой терминала и TFTP сервером, запускаем tftp сервер

Перед экспериментами обязательно нужно сделать резервную копию (дамп). Для этого нужно узнать размер flash памяти устройства. В этом нам поможет команда sf probe 0.

xmtech # sf probe 0
8192 KiB hi_fmc at 0:0 is now current device

Отсюда видно, что размер флеши — 8192кб, что составляет 0x800000h в шестнадцатеричной системе. (Для флеши 16384кб это число будет 0x1000000h).

Ещё понадобится узнать адрес доступной оперативной памяти, чтобы скопировать дамп в память или загрузить туда блоки. Дайте команду printenv и посмотрите переменную bootcmd=. В самом конце всегда присутствует команда bootm и адрес памяти. В нашем случае bootm 0x82000000 (бывают также 0x42000000)

Тогда команды для резервной копии будут такими:

После чего в папке tftp сервера появится файл dump.bin, содержащий полную резервную копию.

Восстановление

Теперь понадобится файл прошивки под наше устройство. Надеюсь, вы записали номер устройства из окошка Info, когда устройство ещё работало? Если нет, подобрать подходящую прошивку можно по фото устройства, написав комментарий к статье или написав в наш канал в Telegrem.
Скачиваем прошивку, открываем архиватором и извлекаем все файлы в папку tftp сервера (у меня r:tftp).

Теперь осталось немного, даём в консоли следующие команды:
run dc
run du
run dr
run dw
После чего перезагружаем командой reset.

Обычно это позволяет восстановить работоспособность в случае порчи одного из модулей. Также может понадобится стереть все настройки (см. следующий абзац)
Если файлы не грузятся с tftp сервера (в консоли циклические попытки), то скорее всего мешает брандмауэр Windows — отключите его или добавьте tftpd32 в исключения.

Сброс пароля

Бывают ситуации, когда пароль администратора утерян, но нужно получить доступ к устройству с целью изменения его настроек. В этой ситуации тоже поможет преобразователь USB-UART, с той лишь разницей, что в этом случае не требуется tftp сервер.
Повторяем те же действия из раздела «Подключаем UART», включая команду printenv.
Внимательно изучаем её вывод, обратив внимание на содержимое переменной bootargs
В нашем примере это будет вывод от камеры 00018510
bootargs=mem=39M console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=cramfs mtdparts=hi_sfc:320K(boot),3520K(romfs),2560K(user),1152K(web),320K(custom),320K(mtd)
320K(boot),3520K(romfs),2560K(user),1152K(web),320K(custom),320K(mtd)
Запускаем калькулятор Windows, переводим его в режим программиста и начинаем подсчёт. Для этого переключаем калькулятор в режим dec, переводим мегабайты и килобайты в байты (килобайты умножаем на 1024, а мегабайты — на 1048576), складываем полученные значение и переключаем калькулятор в режим hex.
Получаем следующие таблички:

Размеры mtd разделов
320K(boot) 327680 50000h
3520K(romfs) 3604480 370000h
2560K(user) 2621440 280000h
1152K(web) 1179648 120000h
320K(custom) 327680 50000h
320K(mtd) 327680 50000h

Адреса mtd разделов
0x000000-0x050000 : "boot"
0x050000-0x3c0000 : "romfs"
0x3c0000-0x640000 : "user"
0x640000-0x760000 : "web"
0x760000-0x7b0000 : "custom"
0x7b0000-0x800000 : "mtd"

Из таблицы нас интересует последний раздел — mtd. Как видно из bootargs, его размер 320кб, что составляет 50000h в шестнадцатеричной системе, а начальный адрес — 0x7b0000.
Здесь хранятся настройки устройства, и, самое важное, пароли пользователей. Если его стереть, то система пересоздаст этот раздел заново с настройками по умолчанию, и, соответственно, с пустыми паролями.

даём следующие команды:
sf probe 0
sf erase 0x7b0000 0x50000
reset

В новых прошивках появилась защита флешки от записи, поэтому сразу после sf probe 0 нужно давать ещё команду sf lock 0, чтобы снять защиту.

Внимательный читатель может обратить внимание, что раздел mtd последний, и для его вычисления достаточно вычесть размер mtd 0x50000 из размера флешки 0x800000, получим те же 0x7b0000. Так даже проще, если нас интересует только один раздел.

Хочу ещё раз напомнить, что это только пример, у вас будут другие цифры. Использование неправильных значений обязательно приведёт к порче устройства!

Слишком сложно!

Не каждый пользователь осилит установку и настройку tftp сервера, не говоря уж про вычисления размеров и смещений для сброса настроек, поэтому мы разработали удобную программу с дружественным интерфейсом, упрощающую действия пользователя. Программа позволяет производить четыре основных операции:
1. Создание резервной копии (дампа) устройства
2. Восстановление камеры/регистратора из созданного дампа
3. Восстановление устройства с помощью файла прошивки
4. Стирание настроек/сброс пароля
Эти возможности предоставляются бесплатно. К пользователю есть лишь одна просьба — для новых устройств по возможности сделать фото устройства и прислать их вместе со слитым дампом по одному из контактов сайта. Пожертвования автору программы приветствуются.

Программу XMDeviceExplorer можно скачать тут.

Дополнительные видео по ремонту на Youtube.

В статье я хочу рассказать о способе программного ремонта или восстановления прошивки IP-видеокамеры Dahua DH-IPC-HDW4421E (Рисунок 1). В общем случае эта инструкция подходит для всех IP-видеокамер Dahua серии IPC-HX4X2X и используется в том случае, если камера не запускается, у нее недоступен веб-интерфейс и не запускается процесс обновления прошивки в автоматическом режиме через TFTP сервер. В статье мы рассмотрим именно программный сбой и способ его устранения, ведь причина, по которой камера не работает, может быть и аппаратная, например, неисправность встроенного модуля PoE или цепей питания процессора и периферии.

Рисунок 1.	IP-видеокамера Dahua серии DH-IPC-HDW4421E.

Проверить, что у IP-камеры Dahua программный сбой,  можно с помощью отладочного UART-интерфейса (его же будем использовать для устранения неполадок в прошивке), сигналы которого доступны на контактных площадках процессорной платы. Кроме того, неисправная IP-видеокамера Dahua не определяется в программе ConfigTool (программное обеспечение от производителя), и веб-интерфейс камеры по установленному ранее IP-адресу недоступен. Для доступа к отладочному интерфейсу IP-камеру требуется разобрать, извлечь процессорную плату и снять радиаторы охлаждения (Рисунки 2, 3).

Рисунок 2.	IP-видеокамера Dahua DH-IPC-HDW4421E со снятой крышкой корпуса.

Рисунок 3.	Вид процессорной платы IP-видеокамеры Dahua DH-IPC-HDW4421E со стороны объектива.

На Рисунке 2 корпус IP-камеры вскрыт, на переднем плане виден модуль PoE (Power over Ethernet, питание камеры по сетевому интерфейсу). Под радиатором видна часть процессорной платы и микросхема Flash-памяти в корпусе SO-8. Демонтируем модуль PoE (я не отключал его от процессорной платы), откручиваем винты крепления процессорной платы к корпусу камеры и затем снимаем радиатор охлаждения.

Сняв радиатор, мы получаем доступ к контактам отладочного интерфейса, а также к контактам кнопки сброса (Рисунок 4). На этой стороне процессорной платы также имеется наклейка с серийным номером  (ID, идентификатором) камеры, этот номер также прописан в прошивке.

Рисунок 4.	Расположение контактных площадок на процессорной плате IP-видеокамеры Dahua DH-IPC-HDW4421E: 1 — отладочный UART интерфейс, 2 — кнопка сброса.

Расположение сигналов отладочного UART-интерфейса +3.3 В, GND, Rx, Tx изображено на Рисунке 4. Для подключения отладочного интерфейса к терминальной программе на ПК я использовал адаптер USB-UART на микросхеме PL2303. В других IP-камерах этой серии расположение контактных площадок и сигналов может отличаться, поэтому если вы не увидите вывод отладочной информации в терминальной программе при подаче питания на IP-камеру, то просто поменяйте сигналы Rx и Tx местами (Рисунок 5).

Рисунок 5.	Подключение адаптера USB-UART к контактам отладочного интерфейса IP-видеокамеры.

Подключаем USB-UART адаптер к компьютеру. Далее скачиваем и устанавливаем терминальную программу; я использую PuTTY. В настройках программы выбираем последовательный порт (Serial), указываем номер порта (Serial Line), соответствующий адаптеру USB-UART, указываем скорость обмена (Speed) 115200 и нажимаем кнопку «Открыть» (Open).

После открытия окна терминальной программы подаем питание на камеру (внешний блок питания 12 В или через PoE, при наличии PoE инжектора) и, если все сделано правильно и процессор исправен, то в окне мы увидим вывод отладочной информации о ходе загрузки (Рисунок 6). В противном случае необходимо проверить параметры порта и подключение сигнальных линий Rx/Tx адаптера USB-UART к отладочному интерфейсу (поменять их местами).

Рисунок 6.	Процесс загрузки операционной системы IP-видеокамеры Dahua DH-IPC-HDW4421E.

Отладочная информация выводится до запуска ядра (после зауска ядра могут выводиться сообщения только о критических ошибках). Тем не менее, даже этой информации было достаточно, чтобы увидеть программные неполадки. Кроме того, IP-камера через несколько минут после старта перезагружается, повторяется процесс загрузки (снова отрабатывает загрузчик U-Boot).

На скриншоте лога загрузки операционной системы можно выделить несколько основных моментов:

• сообщение «* * *  Warning — bad CRC, using default environment» говорит о ошибке контрольной суммы (CRC);
• при инициализации сетевого интерфейса IP-камеры сообщается MAC-адрес Ethernet: Net:   Detected MACID:00:12:34:56:78:9a. Такое значение MAC-адреса (последовательность 0-А) является некорректным, не говоря о соответствии данной IP-камере;
• сообщение «unknown core, use back» после запуска ядра свидетельствует о программной проблеме.

Чтобы проверить остальные параметры камеры (правильнее будет – параметры среды загрузчика), требуется остановить выполнение загрузчика U-Boot и проверить параметры и их текущие значения.

Для остановки загрузки U-Boot необходимо сразу после подачи питания на IP-камеру в терминальной программе отправить символ «*» (или их последовательность), пока не появится надпись «Hit any key to stop autoboot», после этого нажимаем любую кнопку на клавиатуре – появится приглашение к работе «>».

В командной строке вводим команду printenv, наблюдаем список параметров и значений (Рисунок 7). В списке параметров отображаются параметры сетевого интерфейса (MAC, текущий IP камеры, адрес TFTP сервера для обновления прошивки, адрес основного шлюза, маска подсети), команды обновления разделов прошивки с адресами областей Flash-памяти, параметры отладочного UART-интерфейса, уровень отладки и др. Снова в списке видим некорректное значение MAC адреса сетевого интерфейса (параметр ethaddr), некорректный идентификатор (серийный номер) ID, в занчении которого все 0 (данный идентификатор используется при работе IP-камеры с облачными сервисами).

Также в этом списке по какой-то причине отсутствует один важный параметр с именем HWID, который определяет аппаратную платформу IP-видеокамеры. Другими словами – явно программный сбой, причина которого неизвестна (возможно, после неудачного обновления).

Кроме того, отсутствует параметр BSN, который, судя по всему, является идентификатором (серийным номером) процессорной платы IP-камеры, и параметр devalias. Этикетка с идентификатором BSN наклеена на процессорную плату. Как я убедился, наличие или отсутствие параметров BSN и devalias на работу камеры не влияет.

Рисунок 7.	Результат выполнения команды «printenv»: список параметров среды в загрузчике U-Boot.

В общем случае, список параметров у исправной IP-камеры данной серии должен быть вида, как указан на Рисунке 8.

Рисунок 8.	Список параметров среды (printenv) у исправной IP-камеры серии DH-IPC-HDW4421E.

Серийный номер (ID) IP-камеры обычно находится на наклейке на корпусе камеры (длина 15 символов), возможно, он также будет на упаковке или в гарантийном талоне. Идентификатор аппаратной платформы (HWID) можно взять от идентичной камеры (для этого тоже потребуется подключение к отладочному интерфейсу) или найти по модели камеры в файле check.img, который входит в состав программного пакета для обновления прошивки данной серии IP-видеокамер. Для этого необходимо скачать официальную прошивку для данной модели, распаковать ее и найти файл check.img; файл открыть в режиме текстового просмотра и по модели камеры найти значение параметра HWID, которое должно иметь вид: IPC-HDW4421E-AS:01:02:05:23:19:00:01:0E:01:00:04:258:00:00:00:00:00:00:00:00:100

С MAC-адресом сложнее, предположительно, он тоже может быть указан на упаковке или гарантийном талоне; обычно на корпусе IP-камеры имется наклейка с указанием MAC и ID. В моем случае я не смог найти MAC-адрес этой камеры, поэтому пришлось подобрать по аналогии с другой камерой идентичной модели. Здесь следует обратить внимание, что в случае сложных систем видеонаблюдения администраторы сетей требуют уникальность MAC-адресов сетевых устройств.

Забегая вперед, скажу, что подключившись к отладочному интерфейсу, можно на этом этапе обновить прошивку IP-камеры из командной строки, однако из-за некорректных значений указанных выше идентификаторов камера не запустится. В частности, из-за отсутствия идентификатора HWID после перепрошивки мы снова получим сообщение об ошибке «unknown core, use back». Поэтому сначала восстановим значения этих параметров.

Для установки MAC адреса сетевого интерфейса IP-камеры необходимо в командной строке выполнить команду вида:

setenv ethaddr XX:XX:XX:XX:XX

где XX:XX:XX:XX:XX – MAC-адрес IP-камеры (сетевого интерфейса).

Далее, пропишем идентификатор ID с помощью команды:

setenv ID XXXXXXXXXXXXXXX

где XXXXXXXXXXXXXXX – серийный номер IP-камеры.

Теперь укажем идентификатор аппаратной платформы IP-камеры (для данной модели):

setenv HWID IPC-HDW4421E-AS:01:02:05:23:19:00:01:0E:01:00:04:258:00:00:00:00:00:00:00:00:100

Для сохранения введенных параметров в Flash-памяти в командной строке вводим команду:

saveenv

Для того чтобы убедиться, что данные введены правильно, можно выполнить команду printenv. Параметры и значения, которые мы изменили и сохранили, будут в конце списка (Рисунок 9).

Рисунок 9.	Изменение идентификаторов (MAC, ID, HWID) IP-камеры Dahua DH-IPC-HDW4421E в отладочном интерфейсе.

Теперь можно перезапустить камеру командой reset или boot, или аппаратно – отключить и снова включить питание. Практически во всех случаях после корректировки MAC, ID и HWID IP-камеры запускаются с прежними пользовательскими настройками, определяются в программе ConfigTool и стабильно работают. В некоторых случаях было замечено, что пользовательские настройки были сброшены, и необходимо было пройти инициализацию IP-камеры (указать новый пароль администратора, e-mail для восстановления пароля).

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

• текущий IP адрес камеры (ipaddr=192.168.1.108);
• адрес TFTP сервера (serverip=192.168.1.1)
• адрес шлюза (gatewayip=192.168.1.1)

Если камера подключена в локальную сеть через маршрутизатор, то необходимо выполнить соответствующую настройку IP адреса камеры, сервера, шлюза. Я подключаю камеру непосредственно к ПК по Ethernet, поэтому меняю настройки сетевой карты (Рисунок 10), присваивая ПК IP адрес 192.168.1.1 (на этом же ПК будет поднят TFTP сервер с этим же адресом).

Рисунок 10.	Настройка сетевой карты при непосредственном подключении IP-камеры к ПК для обновления прошивки по TFTP.

На ПК запускаем программу TFTPD, выбираем адрес сервера (192.168.1.1) и указываем папку, в которую распакованы файлы прошивки для IP-камеры.

Теперь в командной строке отладочного интерфейса запускаем обновление прошивки командой run up и ждем окончания загрузки файлов и записи Flash-памяти. Можно обновлять в ручном режиме по разделам соответствующими командами. Список команд/скриптов приводится в списке параметров среды загрузчика (Рисунок 11). Например, для обновления раздела веб-интерфейса камеры необходимо выполнить команду run dw.

Рисунок 11.	Список скриптов для обновления прошивки IP-камеры в параметрах среды загрузчика U-Boot.

Командой run up мы обновляем все разделы прошивки в автоматическом режиме (Рисунок 12).

Рисунок 12.	С помощью команды «run up» запускаем обновление  прошивки IP-камеры через TFTP.

После обновления перезапускаем IP-камеру и проверяем работоспособность.

Ссылки:

1. ПО PuTTY
2. ПО TFTPD
3. ПО, утилиты и прошивки к оборудованию Dahua
4. Dahua DH-IPC-HDW4421E

Часто камеры выходят со строя, но лишь часть с них «по настоящему мертва». Такое случается при неправильном обновлении прошивки, перепадах напряжения или еще по каким то причинам. Все это объединяет одно: камера не подает признаков жизни
Можно отправить камеру в сервисный центр для ремонта, но для этого нужно время и камера должна быть куплена официально. При покупке на олх никто гарантии вам не даст
Если же вы решили восстановить ее сами, нужно запастить некоторыми инструментами

Подготовительная часть

• Переходник USB на UART. Я использую на чипе CP2102. Драйвера для этой модели

• Провода для соединения

• Ноутбук или ПК
• TFTP сервер
• PuTTY
• Блок питания 12V
• Lan кабель
• 7zip или winrar

Определение устройства

Разбираем корпус камеры, находим плату. Надеюсь ваш китаец будет такой же добрый как этот, и наклеит стикер с указанием модели платы

Ищем что же это за зверь в Гугле или на сайте XM. Не забудьте переключить сайт https://www.xiongmaitech.com/ на китайскую версию, в английском варианте он ограничен
В поиск вводим 53H20PY-S

Находим плату

Скачиваем файл чтобы определить UART. Сайт кривой у них, получилось скачать только через Firefox

Скачиваем файл прошивки. Но вот незадача, прошивки нет. Ищем на других сайтах https://www.cctvsp.ru/articles/obnovlenie-proshivok-dlya-ip-kamer-ot-xiong-mai

Подключаем UART

Софтовая часть

Добавляем алиас 192.168.1.15 для активной сетевой карты

Разархивируйте прошивку с bin файла с помощью 7zip или winrar

Запустите TFTP сервер
Current Directory папка с распакованной прошивкой
Server interfaces 192.168.1.15

Подключите UART переходник и установите драйвера для него. В результате он станет Com портом с определенным номером. В моем варианте это COM4

Запускаем Putty

Connection type: Serial
Speed: 115200

Жмем кнопку Open

Прошивка устройства

Подключаем к камере Lan кабель
Подключаем питание
В результате в Putty отобразится процесс загрузки камеры. Нужно быстро нажать Ctrl + C на клавиатуре чтобы попасть в меню. Если не успели с первого раза — просто перезагрузите камеру по питанию

Логин: root
Пароль: xmhdipc

Сброс пароля:
rm /mnt/mtd/Config/Account*
reboot

Cброс всех настроек
rm -irf /mnt/mtd/*

Автор: Oliver Matula

Встроенные устройства часто служат входной дверью при атаке на частную или корпоративную сеть. Скандально известная атака на компанию HackingTeam была реализована в точности таким же способом. Хотя подобные деяния могут делаться исходя из благих побуждений (см. также еще одну прекрасную статью), сам факт возникновения данных случаев наводит на мысль о необходимости правильной защиты встроенных устройств. В недавней заметке Никлаус рассказал об исследовании безопасности устройства MAX! Cube LAN Gateway. Более того несколько недель назад Брайан опубликовал отчет о безопасности IoT-устройств (и, в частности, об одной из его камер). В данной заметке я хочу рассказать о своем опыте анализа безопасности IP-камеры IC-3116W от компании Edimax.

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

• Как добраться до прошивки и использовать ее для получения информации.
• Как получить доступ к системе.
• Как установить на устройстве gdbserver.

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

Анализ устройства. Пошаговый подход

Далее я покажу различные шаги, позволяющие настроить рабочую среду для тестирования камеры. В моем случае первоначальная стадия ничем не отличается от любой другой процедуры, связанной с пентестом веб-приложения. Вначале собиралась информаций о камере из внешних источников (веб-сайт производителя, поисковая система, … ) или посредством сканирования внешних служб (в частности, административного интерфейса) при помощи сподручных инструментов (Burp Suite, nmap, …). Далее наступала стадия эксплуатации, по результатам которой к устройству получается доступ. Наконец, в последней стадии на камере устанавливаются утилиты для отладки/анализа.

Шаг 1: Сбор информации

При анализе устройства жизненно важно собрать как можно больше информации. В нашем случае задача облегчается за счет того, что компания Edimax предоставляет множество даташитов, мануалов, прошивку и набор утилит toolchain (+ файлы для сборки образа) для камеры (хотя, исходный код к некоторым интересным бинарным файлам был утерян).

Уже при исследовании прошивки можно узнать много интересного о внутреннем устройстве камеры. При помощи bindwalk извлекаем из прошивки структуру файловой системы:

$ binwalk -e IC3116W_v2.10.bin
DECIMAL         HEX             DESCRIPTION
——————————————————————————————————-
605             0x25D           LZMA compressed data, properties: 0x88, dictionary size: 1048576 bytes, uncompressed size: 65535 bytes
10392           0x2898          LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 3735204 bytes
1245312         0x130080        Squashfs filesystem, little endian, version 4.0, compression: lzma, size: 4072088 bytes,  907 inodes, blocksize: 131072 bytes, created: Mon Feb 22 11:50:40 2038

По результатам отработки bindwalk выясняется, что разработчики используют файловую систему SquashFS. Для анализа данной файловой системы я воспользовался утилитой unsquashfs (с поддержкой LZMA):

$ unsquashfs -d filesystem 130080.squashf

На выходе получаем распакованную файловую систему, сохраненную в папке filesystem:

$ ls -a filesystem
.  ..  bin  dev  etc  home  init  lib  mnt  proc  sys  test  tmp  usr  var  web  www

После распаковки файловой системы приступаем к исследованию файлов. Например, нашлись некоторые интересные бинарники: telnetd, wget, ftp и многие другие. В процессе сканирования при помощи nmap (стандартный IP-адрес напечатан на задней стенке устройства) выяснилось, что демон telnet по умолчанию не запущен (но, тем не менее, на будущее следует держать эту информацию в голове).

$ nmap -sS -p0- —reason -v -T3 -Pn 192.168.2.3
[…]
Nmap scan report for 192.168.2.3
Host is up, received arp-response (0.00065s latency).
Not shown: 65534 closed ports
Reason: 65534 resets
PORT     STATE     SERVICE     REASON
80/tcp   open      http        syn-ack
554/tcp  open      rtsp        syn-ack
MAC Address: 74:DA:38:34:AA:75 (Unknown)
[…]

Корневая директория веб-сервера находится в папке www. Исследуя данную папку, находим несколько интересных cgi файлов, доступ к которым доступен всем желающим без авторизации:

• /www/camera-cgi/public/anonymous.cgi
• /www/camera-cgi/public/getSysteminfo.cgi
• /www/camera-cgi/public/supportiPhoneAppVersion.cgi

В частности, при помощи файла anonymous.cgi и getSysteminfo.cgi можно получить множество сведений относительно настроек IP-камеры (внутренние IP-адреса, версию прошивки и т. д.).

Рисунок 1: Информация о камере, полученная после запуска скрипта getSysteminfo.cgi

Следующий шаг – автоматическое сканирование и ручное тестирование запущенных служб для того, чтобы выяснить внутренне устройство камеры. По результатам сканирования при помощи nmap (см. выше) выяснилось, что на порту 80 запущен веб-сервер, используемый для административного интерфейса. Стандартная учетная запись администратора: admin с паролем 1234 (обычно для удобства напечатана на задней стенке камеры).

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

И здесь мы переходим ко второй стадии, связанной с получением доступа к системе.

Шаг 2: Получение доступа к системе

После автоматического сканирования и ручного тестирования веб-интерфейса выяснилось, что Системный Журнал (System Log) дает возможность удаленного выполнения кода. Используя путь к telnetd, можно запустить службу telnet следующим образом:

Рисунок 3: Методика запуска telnetd через SystemLog

Теперь мы можем подключиться к камере через telnet:

$ telnet 192.168.2.3
Trying 192.168.2.3…
Connected to 192.168.2.3.
Escape character is ‘^]’.
IC-34AA75 login: admin
Password:

RLX Linux version 2.0
_           _  _
| |         | ||_|                
_  _ | | _  _    | | _ ____  _   _  _  _
| |/ || | / /   | || |  _ | | | | / /
| |_/ | |/       | || | | | | |_| |/   
|_|   |_|_/_/   |_||_|_| |_|____|_/_/
For further information check:
http://processor.realtek.com/
BusyBox v1.13.4 (2015-02-25 18:14:22 CST) built-in shell (ash)
Enter ‘help’ for a list of built-in commands.
# cat /etc/passwd
admin:$1$yAn92Ld/$u5nHFH9nLds0naDaLuK1d/:0:0:System Administrator,,,:/:/bin/sh

Учетная запись для доступа через telnet та же самая, что и для административного интерфейса (пользователь: admin, пароль: 1234). После анализа файла /etc/passwd выясняется, что в системе только один пользователь: admin (c uid 0 и gid 0).

ледовательно, мы имеем полный доступ к системе.

Следует отметить, что есть возможность получить shell-доступ через UART-порт. Данный порт указан на плате на рисунке ниже (изначально соответствующие пины были удалены и запаяны).

Рисунок 4: Плата IP-камеры с отмеченным UART-портом

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

Шаг 3: Настройка рабочей среды

Существует несколько утилит, помогающих анализировать на камере запущенные процессы. Задача осложняется тем, что на камере отсутствует отладчик и компилятор. Наша задача – запустить на камере gdbserver, а локально – gdb.
Использование gdbserver на камере (вместо gdb) дает несколько преимуществ. Во-первых, размер бинарного файла gdbserver намного меньше, чем gdb. Дисковое пространство на встроенных устройствах часто может быть ограниченно и зачастую gdbserver – единственный выбор. Во-вторых, gdbserver имеет меньше зависимостей, чем gdb, и, следовательно, облегчается кросс-компиляция. Конечно, при использовании gdbserver есть и свои минусы. Например, могут возникнуть сложности в случае, если размеры регистров хоста (где установлен gdb), и целевой системы (где установлен gdbserver) различаются. Именно поэтому я запускаю gdb на машине с архитектурой x86.

Чтобы облегчить установку бинарных файлов на камеру, желательно найти способ быстрой транспортировки туда и обратно. Для закачки файлов на камеру можно использовать утилиту wget (хотя файловая система filesystem работает в режиме «только чтение», флеш-память смонтирована в папку /var, и мы можем записать туда). Чтобы скачать файла с камеры, подойдет утилита lighttpd (веб-сервер камеры). Посредством запуска еще одного экземпляра данного сервера с корневой директорией “/” мы можем скачать с камеры все файлы.

После настройки системы транспортировки файлов между камерой и хостом настало время кросс-компиляции gdbserver’а. Вначале выясним, какой процессор используется на камере:

# cat /proc/cpuinfo
system type             : RTL819xD
processor               : 0
cpu model               : 56322
BogoMIPS                : 658.63
tlb_entries             : 32
mips16 implemented      : yes

Как видно из листинга выше, на камере используется система RTL819xD на базе архитектуры MIPS. Вначале я попробовал использовать стандартный кросс-компилятор под эту архитектуру. На ресурсе Aboriginal Linux, помимо различных кросс-компиляторов, присутствуют shell-скрипты, позволяющие настроить полноценную систему сборки под конкретную архитектуру (на базе эмулятора qemu).

Однако в Realtek CPU используется модифицированный набор инструкций, и лишь малое количество обычных бинарных файлов, скомпилированных для архитектуры MIPS, может запуститься в этой системе. Хотя, как упоминалось ранее, компания Edimax предоставляет набор утилит toolchain, используя которые в операционной системе CentOS 7.3, я смог настроить среду для сборки. Инструкции по настройке данной среды даны в файле pdf, который идет в комплекте с toolchain. Суть настройки сводится к следующим шагам:

• Шаг 1 1: cd TARGET_DIR
• Шаг 2: bzip2 -cd rsdk-{VERSION}-{LIBRARY}-{PLATFORM}.tar.bz2 | tar xvf –
• Шаг 3: ln -s rsdk-{VERSION}/{PLATFORM}/{LIBRARY} rsdk
• Шаг 4: export PATH=TARGET_DIR/rsdk/bin:$PATH

Теперь в системе CentOS я могу скомпилировать бинарные файлы для камеры. Для кросс-компиляции gdbserver используем следующий набор команд:
$ cd gdbserver_src
$ ./configure  —host=mips-linux CC=rsdk-linux-gcc
$ ./make CC=rsdk-linux-gcc AS=rsdk-linux-as LD=rsdk-linux-ld

При помощи переменных окружения CC, AS и LD компилятор, ассемблер и загрузчик могут быть настроены для компиляции и загрузки. В конце концов, мы получаем бинарный файл gdbserver, который подходит для запуска на камере.
Соответствующий бинарный файл gdb можно получить схожим образом. Но здесь задача облегчается тем, что уже есть скомпилированные версия для систем x86 (которые могут взаимодействовать с gdbserver в MIPS-системах). Если же вы хотите скомпилировать бинарный файл с нуля, то можно использовать различные параметры в процессе компиляции.

$ cd gdb_src
$ ./configure  —target=mips-linux
$ ./make

Во время сборки мы должны указать целевую систему (то есть ту систему, где будет запускаться gdbserver). Я протестировал различные версии gdb/gdbserver и выяснил, что в случае с моей камерой работает версия gdb-6.8.

В конце я бы хотел показать, как можно использовать связку gdb/gdbserver для анализа процессов, запущенных на камере. Но вначале скопируем бинарный файл gdbserver на камеру в директорию /var и выставим права на запуск при помощи chmod. Теперь, чтобы подключиться к процессу, используем следующую команду:

# /var/gdbserver ip:port —attach pid

Здесь в качестве IP-адреса выступает адрес хоста, где запущен gdb. Порт, указанный в команде, будет открыт на целевой системе. PID – идентификатор процесса, к которому мы хотим подключиться. Естественно, мы также можем запустить новый процесс на камере (без подключения к существующему) посредством указания пути к исполняемому файлу вместо аргумента –attach.

В качестве примера подцепляемся к запущенному процессу /bin/ipcam:

# /var/gdbserver 192.168.2.10:1234 —attach 9266
Attached; pid = 9266
Listening on port 1234

После запуска команды gdbserver ожидает входящие соединения на определенному порту (в данном случае -1234). На хосте мы запускаем исполняемый файл gdb и подсоединяемся к целевой системе при помощи следующей команды:
$ rsdk-mips-gdb -q
(gdb) target remote 192.168.2.3:1234

Remote debugging using 192.168.2.3:1234
[New Thread 9266]
0x2ab6b89c in ?? ()

(gdb)

Однако, как видно из листинга выше, gdb не находится в контексте функции или, другими словами, «не понимает», где находится. Подобное происходит потому, что gdb должен загрузить таблицу символов для бинарного файла, который будет отлаживаться на целевом сервере. Таким образом, необходимо использовать файловую команду (в gdb) внутри бинарного файла после локальной загрузки таблицы символов. Более того, для отладки библиотечных вызовов должна быть сохранена локальная копия файловой система камеры, и gdb должен запускаться из корневой директории (что гарантирует нахождение библиотек в системе x86).

$ cd cam_root_dir
$ rsdk-mips-gdb -q
(gdb) file cam_root_dir/bin/ipcam
Reading symbols from cam_root_dir/bin/ipcam…(no debugging symbols found)…done.
(gdb) target remote 192.168.2.3:1234
Remote debugging using 192.168.2.3:1234
[New Thread 9266]
0x2aaa8a40 in _start() from cam_root_dir/lib/ld-uClibc.so.0
(gdb)

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

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

Хронология событий:

• 3 мая 2016 года: отправлено сообщение на почту support@edimax-de.eu в целях установление первоначального контакта.
• 4 мая 2016 года: получен ответ от компании Edimax; контактному лицу направлен код, использующий уязвимости.
• 13 июня 2016 года: отправлен запрос на получение информации о текущем состоянии дел касательно исправлений.
• 14 июня 2016 года: получен ответ о текущем статусе исправлений.
• 21 июля 2016 года: отправлен запрос о текущем состоянии дел.
• 22 июля 2016 года: получен ответ с заявлением, что новая прошивка будет выпущена в течение недели.
• 1 августа 2016 года: отправлен запрос о текущем состоянии дел.
• 1 августа 2016 года: получен ответ с заявлением о переносе даты выпуска новой прошивки (новую дату не сообщили).
• 29 августа 2016 года: отправлен запрос о текущем состоянии дел.
• 29 и 30 августа 2016 года: получен ответ с заявлением, что новая прошивка будет выпущена 14 сентября 2016 года.
• 15 сентября 2016 года: отправлен запрос о текущем состоянии дел.
• 20 сентября 2016 года: получен ответ с заявлением о переносе даты выпуска новой прошивки (причины были раскрыты в письме).
• 26 сентября 2016 года: отправлено письмо с сообщением о дате выхода данной статьи.
• 26 сентября 2016 года: получен ответ с заявлением, что о дате релиза новой прошивки будет сообщено позже.

Таким образом, на момент написания статьи (17 октября 2016 года) новая версия прошивки с исправлениями найденных уязвимостей так и не появилась. Соответственно, нужно предпринять другие меры в целях предотвращения потенциальной эксплуатации найденных брешей. Чтобы предотвратить утечку информации через файлы anonymous.cgi, getSysteminfo.cgi и supportiPhoneAppVersion.cgi, необходимо ограничить доступ другими средствами (например, при помощи отдельного фаервола). Конечно, вы также можете получить доступ к системе, как описывалось выше, и переконфигурировать камеру.

Кроме того, необходимо ограничить доступ к той области, откуда запускается удаленный код. Для начала следует изменить стандартную учетную запись камеры (но сменить учетную запись нужно в любом случае). Кроме того, в зависимости от ситуации, в которой используется камера, возможно, следует полностью заблокировать доступ к веб-интерфейсу через интернет.