Как перепрошить ip камеру под другое приложение

Обновлено: 07.01.2025

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

Компания в качестве доноров использует оборудование различных брендов, наибольшее распространение получили марки Hikvision и Dahua

IP камеры из линейки Hikvision

IP камеры из линейки Dahua

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

Подробнее о прошивке с использованием сервера TFTP можно прочитать в другой нашей статье, Восстановление прошивки Hikvision

Далее рассмотрим как выполнить Восстановление оригинальной прошивки после ростелекома на примере оборудования Hikvision

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

Первые версии программного обеспечения от Ростелекома использовали практически оригинальный загрузчик и дескриптор устройства компании Hikvision с единственным ограничением, длинна файла оригинальной прошивки не позволяла выполнить обновление и процесс прерывался с ошибкой превышения длинны файла digicap.dav.

Файл digicap.dav имеет несколько степеней защиты от редактирования, но сообщество любителей бренда Hikvision располагает утилитами способными обойти эти барьеры.

Предлагаю инструкцию взятую из сети:

Вам понадобится инструменты (скачать и распаковать):

HikTools — утилита для разборки и сборки прошивки.
HikVision TFTP Server — утилита для восстановления прошивок камер HikVision/HiWatch
HyperTerminal — утилита для связи через последовательный порт
NewTuxBoxFlashTools — утилита для правки образов CRAMFS
SADP — утилита для поиска, активации и конфигурирования сетевых параметров камер HikVision/HiWatch.

С FTP-сервера HikVision скачиваем архив с оригинальной прошивкой. Распаковываем. Нас интересует файл digicap.dav .
Копируем файл в папку HikTools и запускаем файл cmd_split.cmd . В папке появляется подраздел dav , в котором лежит содержимое прошивки.
Запускаем утилиту NewTuxBoxFlashTools и открываем в ней файл app.img из подраздела dav . Интерфейс на немецком, но понять где что несложно по иконкам. Ищем в содержимом образа файл WebComponents.exe и удаляем его, сохраняем изменения. При сохранении ругнётся — это нормально.
Запускаем файл cmd_create.cmd и получаем новую прошивку — файл с именем dav.dav .
Удаляем старый файл digicap.dav и переименовываем файл dav.dav в digicap.dav . Получили прошивку меньшего размера.

В камеры HikVision/HiWatch заложен механизм восстановления прошивки при критических сбоях. Каждый раз, при запуске, камера получает фиксированный адрес 192.0.0.64 (или 192.168.1.64 и в течение нескольких секунд ищет TFTP-сервер по адресу 192.0.0.128 или 192.168.1.128, соответственно. Найдя его, скачивает прошивку, и прошивается.

Задаём сетевой карте компьютера адрес 192.0.0.128/255.255.255.0 и дополнительный адрес 192.168.1.128/255.255.255.0, чтобы не проверять из какой партии камера и сделать всё за одну попытку.
Копируем резаную прошивку в папку сервера TFTP и запускаем сервер.
Подключаем камеру к сети и включаем питание. Наблюдаем за логом TFTP-сервера. Как только напишет, что прошивка скачана нужно его закрыть. Иначе, камера прошьётся, перезагрузится, при загрузке начнёт искать TFTP-сервер — найдёт, скачает прошивку, прошьётся, перезагрузится и так по кругу.
Контролируем запуск камеры в рабочее состояние через SADP. Появилась в списке — значит загрузилась. Камера прошита.
Теперь нужно сбросить пароль путём возврата к заводским установкам. Выключаем питание камеры, зажимаем кнопку RESET, подаём питание и держим кнопку нажатой 10-15 секунд. Отпускаем RESET.
Контролируем запуск камеры через SADP. Если сброс произошёл — камера получит адрес по умолчанию — 192.0.0.64 или 192.168..1.64 и перейдёт в неактивное состояние (Inactive). Можно задавать пароль, настраивать и пользоваться. Как говорится — Enjoy!

Заранее подготовленный файл с прошивкой и TFTP сервером можно скачать в нашем файловом архиве

Подробнее о прошивке с использованием сервера TFTP можно прочитать в нашей другой статье, Восстановление прошивки Hikvision

Восстановление оригинальной прошивки после ростелекома камер Ростелеком CS-C2SHW и Ростелеком-DS-2CD-VC1W имеет некоторые нюансы:

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

Для обновления прошивки сначала потребуется узнать её версию и дату:

Для этого с помощью программы CMS подключаетесь к камере/регистратору, открываете свойства и заходите в настройки (Device config):

Там выбираете "Информация" -> "Версия" (Setting->Info->Version). Нас интересует Версия системы (System) - это цифры, обведённые красным. Первые три цифры определяют конкретного сборщика оборудования (Вендора), а оставшиеся пять - это и есть версия прошивки. При скачивании прошивки нужно выбирать файл с теми же цифрами. Дата прошивки (Build Date) означает дату её выпуска, по этим данным можно ориентироваться, на сколько старое ПО установлено в камере.

Для установки скачанной прошивки нужно зайти в пункт "Обновление" (Upgrade)

Выбрать пункт "Директория" (Browse), выбрать файл новой прошивки и нажать кнопку "Обновить" (Upgrade). После чего начнётся сам процесс обновления. Обычно это занимает около минуты, после чего ещё одну минуту камера перезагружается. В конце обновление должна появиться табличка "Обновление успешно". Поздравляю, ваша камера/регистратор теперь имеют свежую программу.

Если появилась табличка "Обновление неудачно", скорее всего вы пытались установить неподходящую прошивку, ещё раз проверьте версию из пункта "Версия" и скачанной прошивки. Ещё такое может произойти, если вы пытаетесь обновить оборудование от другого производителя (первые три цифры отличаются от 000). В некоторых случаях, производители защищают подмену ПО в своих продуктах, указывая в настройках прошивки дополнительный пункт Vendor, тогда обычные версии (General) ПО уже не могут быть установлены без правки InstallDesc. Однако этот вопрос уже выходит за рамки данной статьи. Если вас интересует подобный вопрос, обратитесь в поддержку любым доступным способом.

Привет, меня зовут Олег Герасимов, я директор центра компетенций IT-кластера Ростелекома. Наша команда среди многих задач разрабатывает прошивки камер видеонаблюдения для B2B и B2C-сервисов. В предыдущей статье я рассказывал, как мы научились самостоятельно разрабатывать софт и прошивки для IP-камер, в том числе и недорогих, и подключать их к облаку.

За прошедшее время камеры с нашей прошивкой уже появились на рынке, и, судя по данным Яндекс.Маркета, — на полках магазинов цены на них начинаются от 1500 рублей. И это уже не дешевый «ноунэйм», а качественные камеры ведущих мировых брендов: Hikvision, Dahua и Uniview. На мой взгляд, это отличный результат!

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

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

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

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

Следующий этап разработки прошивок для камер совпал с объявлением тендера на закупку камер. Это уже серьезное событие. Ростелеком закупал сотни тысяч камер на открытом тендере, в который могли войти любые вендоры камер, соответствующих по своим ТТХ продуктовым и техническим требованиям.

Одно из ключевых требований к поставщикам — предоставление технической информации о схемотехнике камер, например, о GPIO-выводах, к которым подключены светодиоды, кнопки, ИК фильтры и т.д. Кроме этой информации, мы просили вендоров предоставить специфичные для оборудования патчи ядра/загрузчика и исходные тексты драйверов устройств, в первую очередь, сенсоров и WI-FI чипов.

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

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

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

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

Техническое решение, с одной стороны, очевидное: сделать SDK для сборки нашей прошивки. Но есть ряд требований:

SDK должен уметь собирать прошивки под все типы поддерживаемых SoC. На сегодня это больше 10 чипсетов от Hisilicon, Ambarella, MStar и Fullhan.
Нельзя передавать компоненты прошивок от одного вендора другим, потому что это интеллектуальная собственность. Мы подписываем NDA, в котором обязуемся не раскрывать передаваемую информацию.
Результаты интеграции, полученные от вендора, нужно уметь замерджить в общее дерево исходников прошивки в нашем Git.
У вендора должна быть возможность вносить патчи и дополнения во все компоненты: ядро, загрузчик, SoC SDK и прочие.
Нужно иметь гибкую структуру настроек, в которой будут учитываться максимальное количество возможных конфигураций оборудования.
Для каждой пары «вендор-SoC» должна собираться универсальная прошивка, поддерживающая все камеры вендора на базе этого процессора.
Сборка должна работать автономно и не требовать доступа в Интернет. Да, большинство разработчиков ПО для камер в Китае не имеют доступа в Интернет на рабочих местах.

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

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

Процессор	Версия Linux	Версия gcc
Hisilicon 3516a/d	3.4.y	gcc 4.9
Hisilicon 3518ev100	3.0.y	gcc 4.4
Hisilicon 3518ev200	3.4.y	gcc 4.9
Hisilicon 3516cv300	3.18.y	gcc 4.9
Hisilicon 3518ev300/3516ev200/ev300	4.9.y	gcc 6.3
Hisilicon 3516cv500/dv300	4.9.y	gcc 6.3
mStar i3	3.18	gcc 4.8
mStar i6	4.9	gcc 8.2
Ambarella s2l	3.10	gcc 4.9
Ambarella s3l	3.10	gcc 5.2
Fullhan fh8632	3.0.y	gcc 4.3

Как видно, разброс огромный: от легаси десятилетней давности до относительно свежих ревизий.

С такими вводными нам предстоял рефакторинг системы сборки прошивок: выделить общие патчи и драйвера, которые будут доступны для всех вендоров, повторить это для 10+ поддерживаемых моделей SoC, полностью переосмыслить систему конфигурации наших компонентов. Заодно выпилить специфичные для камер костыли из init-скриптов, сделав общие и универсальные решения.

В результате мы пришли к структуре, в которой все специфичные для конкретных моделей настройки/конфигурации/makefile/патчи собраны в папках, структурированную по иерархии "Вендор → SoC → Модель камеры". Такая иерархия позволила автоматизировать сборку SDK с разделением сборок по вендорам. Вот пример, драйверы и конфигурации для камер от выдуманного вендора Megatech на чипсете Hisilicon.

Все файлы конфигурации камер перевели в формат YAML, как самый удобный для ручного редактирования, и разделили по компонентам:

Настройки оборудования модели камеры (GPIO, наличие и тип Wi-Fi, сенсора, флаги наличия микрофонов, динамиков, дополнительные скрипты инициализации).

Настройки видеоприложения для конкретной модели (тип сенсора, поддерживаемые разрешения, режимы синхронизации и видеозахвата, подстройки алгоритмов).

Настройки PTZ (тип чипа, тайминги работы шаговых драйверов).

Выбор способа сборки дистрибуции SDK был очевидным. Docker оказался вне конкуренции, с его помощью можно легко передать подготовленную среду.
Мы использовали Docker практически с самого начала разработки, как в CI, так и для локальной отладки на компьютерах разработчиков.

Процесс сборки полностью автоматизирован. Docker-образы с нашим SDK собираются в общем CI под матрицу сочетаний «SoC-вендор».

Исходно у нас было два основных репозитория:

build-tools — в нем хранятся Dockerfile, скрипты установки SoC SDK и скрипты сборки общих библиотек для поддерживаемых аппаратных платформ. В CI этого репозитория собираются Docker-образы со всем необходимым для сборки прошивки и софта под целевую платформу.
vc-firmware — здесь хранится система сборки прошивки и компонент. К этому же репозиторию как git-submodule подключены репозитории с исходниками наших компонентов: видеоприложение, облачный агент, модуль обновления). Результатом работы CI в этом репозитории являются сами прошивки камер.

Для нового SDK добавили еще один репозиторий, vc-sdk, к которому подключили vc-firmware и build-tools как git-submodule. В CI этого репозитория сборка разделена на этапы:

подготовка базового Docker-образа по аналогии с репозиторием build-tools;
сборка пакетов с компонентами (видеоприложение, облачный агент, модуль обновления);
загрузка пакетов с общими компонентами (публичные библиотеки, драйверы Wi-Fi и т.д.)
копирование каталогов с драйверами и патчами, специфичными для вендора

В результате работы CI получается автономный Docker-образ, рассчитанный на сборку прошивок для камер на выбранном чипе вендором. Он загружался
в общий registry образов, из которого вендор может скачать свой образ.

Заключение

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

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

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

Сегодня мы хотим рассказать вам как самостоятельно перепрошить свои камеры видеонаблюдения прошивками от Dahua и добавить в них напрямую функцию P2P (удаленное подключение к камере видеонаблюдения без сложных настроек)!

Перепрошивка позволит Вам на все 100% использовать свою систему видеонаблюдения. Прошивки добавлят новые возможности в функционал камер такие как P2P. Также иногда в следствии непредвиденных факторов камера может начать некорректно работать. В таком случае также может помочь перепрошивка последней актуальной прошивкой.

Итак, перейдем к самому процессу перепрошивки:

Для начала вам понадобится прошивка для вашей модели камеры видеонаблюдения с поддержкой P2P. Ее Вы можете найти и скачать на нашем файловом сервере.

Находим необходимую нам прошивку с поддержкой функции P2P и скачиваем ее.

Дальше переходим в Веб-Интерфейс нашей камер, заходим в настройки, вкладка SYSTEM – UPGRADE, где выбираем файл с прошивкой и нажимаем Upgrade.

После завершения перепрошивки камеры в настройках TCP/IP появится настройка P2P. Ставим галочку напротив данной функции.

Далее запускаем приложение для видеонаблюдения SmartPSS и переходим во вкладку Устройста. Найти SmartPSS можно на файловом сервере.

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

По завершении видим что наша камера подключена без использования IP адреса, при помощи технологии P2P.

Теперь Вы легко можете получить удаленный доступ к своим камерам видеонаблюдения через программу SmartPSS или с вашего мобильного телефона как описанно в данной статье.

Читайте также: