Linux hisilicon: Releases · hisilicon/linux-hisi · GitHub

Запуск Buildroot и OpenWrt на устройствах с SoC Hisilicon

Введение

Материал в стадии оформления. Последнее обновление – 2018.04.13

Используя данный Сайт, Вы выражаете свое согласие с «Отказом от ответственности» и принимаете всю ответственность за выполняемые действия с оборудованием и программным обеспечением на себя !

Просьба – при использовании материалов с сайта в своих проектах, указывать первоисточник. Спасибо!

Доступ в группу для различных обсуждений по IPCam и NVR возможен через WebIRC = Slack = Telegram

Эксперименты Buildroot & OpenWrt

Данные прошивки предназначены исключительно для экспериментов и опытных пользователей, умеющих работать с UART консолью, TFTP сервером и командами U-boot.

В текущих тестовых прошивках пока нет поддержки Video, запись на FLASH не производится, старт системы происходит из памяти (INITRAMFS). Сейчас проверяется возможность загрузки ядра Linux на разных процессорах Hisilicon, корректность работы интерфейсов Ethernet и USB, поддержка минимальной файловой системы, автоматическое определение сенсоров.

Теперь все компоненты (утилиты и библиотеки) в проекте XM IPCam modding собираются при помощи нашего OpenWrt toolchain размещённого на GitHub обсуждение которых происходит в группе Telegram

Начат сбор информации в OpenWrt Wiki и открыта дискуссия на китайском форуме OpenIPCam

Старт OpenWrt на модуле XM IPCam с SoC HI3518Ev1

Архив прошивок

Внимание! Если у вас камера не XM производителя и имеет на плате внешний Ethernet PHY (RTL8201 или IP101) – пробуйте использовать в первую очередь прошивки с именами -UD (unknown device).

Исходники прошивок и программ на GitHub: Buildroot | OpenWrt | Glutinium

Все пакеты программ, библиотек и модулей ядра для OpenWrt доступны (в формате .ipk) по ссылке

Тестирование выполнено успешно на IPCam:

• XM 02532 (HI3516Cv1) ; XM ? (HI3516Cv1 + LAN8710A)
• XM 06510 (HI3518Ev1)
• XM 18510 (HI3518Ev2) ; XM 18520 (HI3518Ev2)
• NVSIP unknown (HI3518Ev1 + RTL8201 PHY)

Тестирование выполнено успешно на NVR:

Просьба: присылайте ID проверенных устройств и не стесняйтесь задавать вопросы группе Telegram

Загрузка прошивок в устройство

Скачайте тестовую прошивку Buildroot или OpenWrt под ваше устройство (см. таблицу выше).

Настройте любой TFTP сервер и положите на него скачанный фаил, переименовав его в uImage.

Выполните команды в UART консоли, нажав Ctrl+C для остановки загрузки ядра после подачи питания на модуль:

#
setenv serverip 192.168.1.254                  // Установка адреса TFTP сервера
setenv bootargs mem=XXM console=ttyAMA0,115200 // Установка переменных для передачи ядру
tftp 0x82000000 uImage                         // Загрузка в память экспериментальной системы
bootm 0x82000000                               // Старт системы из памяти

Где XX это количество выделяемой памяти. Для SoC v1 должно быть 43M, а для v2 – 64M

Или, если сервер указан правильно, те-же операции но одной строкой:

setenv bootargs mem=43M console=ttyAMA0,115200 ; tftp 0x82000000 uImage ; bootm 0x82000000

setenv bootargs mem=64M console=ttyAMA0,115200 ; tftp 0x82000000 uImage ; bootm 0x82000000

Теперь после загрузки устройство с прошивками Buildroot и OpenWrt имеет одинаковый адрес – 192.168.1.10.

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

Подготовка, установка и обновление кода проекта

Подготовка в Debian/Ubuntu

sudo apt-get install --no-install-recommends build-essential gawk git libncurses-dev python \
    subversion unzip zlib1g-dev

Первичная установка

git clone https://github.com/ZigFisher/chaos_calmer.git
cd chaos_calmer
cp ./feeds.conf.default ./feeds.conf
./scripts/feeds update -a
./scripts/feeds install -a

Добавление некоторых программ из Glutinium

cd chaos_calmer
echo "src-git glutinium https://github.com/ZigFisher/Glutinium.git" >>./feeds.conf
./scripts/feeds update glutinium
./scripts/feeds list -r glutinium    # вывод списка доступных пакетов
./scripts/feeds install empty etherdump homes-smart httping i2c-telemetry i2c-tools \
    littlewire micronucleus mercury236 microbe mini_snmpd remserial rs485conf tg-bot1 \
    vtun-lite

Обновление кода желательно делать еженедельно

cd chaos_calmer && git pull

Для сборки прошивки выполните скрипт ./ZFT_Lab.sh находящийся в корне системы

WEB-интерфейс OpenWrt на модуле XM IPCam

Список поддерживаемых сенсоров

#
  ar0130     [1280x720@30]   : libsns_ar0130.so
  ar0230     [1920x1080@30]  : libsns_ar0230.so 
  ar0330     [1920x1080@30]  : libsns_ar0330_1080p.so
  ar0331     [1920x1080@30]  : libsns_ar0331_1080p.so
  gc1004     [1280x720@30]   : libsns_gc1004.so
  gc1014     [1280x720@30]   : libsns_gc1014.so
  himax1375  [1280x720@30]   : libsns_himax1375.so
  icx692     [1280x720@30]   : libsns_icx692.so
  imx104     [1280x720@30]   : libsns_imx104.so
  imx122     [1920x1080@30]  : libsns_imx122.so
  imx138     [1280x720@30]   : libsns_imx138.so
  imx222     [1920x1080@30]  : libsns_imx222.so
  imx236     [1920x1080@30]  : libsns_imx236.so
  mn34222    [1920x1080@30]  : libsns_mn34222.so
  mt9m034    [1280x720@30]   : libsns_9m034.so
  mt9p006    [1920x1080@30]  : libsns_mt9p006.so
  ov9712     [1280x720@30]   : libsns_ov9712.so
  ov2718     [1920x1080@25]  : libsns_ov2718.so
  ov9732     [1280x720@30]   : libsns_ov9732.so
  ov9750     [1280x720@30]   : libsns_ov9750.so 
  ov9752     [1280x720@30]   : libsns_ov9752.so
  po3100k    [1280x720@30]   : libsns_po3100k.so
  sc1135     [1280x720@30]   : libsns_sc1135.so
  sc2135     [1920x1080@30]  : libsns_sc2135.so
  soih32     [1280x720@30]   : libsns_soih32.so

• Выбирайте imx122 для (вместо) imx322, если он отсутствует в списке сенсоров при команде video

Работа с GPIO

Для тестирования и управления используйте утилиту gpio.

Другие заметки – пока только для прошивок на базе Buildroot !

Загрузка модулей ядра и инициализация сенсора

video ov9712

Запуск RTSP стримера

live-streamer -S ov9712

RTSP поток доступен по адресу rtsp://192.168.1.15:554/0

Получение снапшотов с камеры

snapshotd -p /tmp/ -f snap.jpg rtsp://127.0.0.1:554/0

Получение снимков происходит при отправке сигнала SIGUSR1 демону snapshotd

kill -s SIGUSR1 `pidof snapshotd`

Альтернативный вариант для получения снапшотов и роликов – использовать утилиту sample_venc

Внутренние ссылки

Внешние ссылки

Klondike of Chinese software solutions hosted by the GitHub

HiSilicon — CNXSoft- новости Android-приставок и встраиваемых систем

VIA Technologies выпустила датчик зрения VIA Pixetto, предназначенный для обучения искусственному интеллекту (AI) и машинному обучению (ML) учащихся в возрасте от двенадцати лет и старше.

Читать далее «Плата VIA Pixetto, оснащенная видеопроцессоро м Hi3518E V300 HD, предназначена для обучения искусственному интеллекту и машинному обучению»

Беспроводные протоколы LPWAN, такие как LoRaWAN, Sigfox и NB-IoT, обеспечивают передачу небольших объемов данных на большие расстояния при очень низком энергопотреблении и продлевая срок службы батареи до 10 лет. Но, время от времени, по-прежнему необходимо заменять батарею, что увеличивает расходы на техническое обслуживание.

HiSilicon и Nowi сотрудничают в разработке и запуске платформы Energy Autonomous NB-IoT V2 — концентратор датчиков, который может передавать данные через NB-IoT без необходимости замены или перезарядки батарей вручную благодаря своим возможностям сбора энергии.

Читать далее «Сбор энергии позволяет снизить расходы на техническое обслуживание платформы Energy Autonomous NB-IoT V2»

HiSilicon Hi3559A — это процессор с пятью ядрами Cortex-A73/A53, разработан для AI-камер 8Kp30 или 4Kp120, благодаря ядрам DSP и одно- или двухъядерному AI-ускорителю NNIE (Neural Network Inference Engine). Первое наше знакомство с процессором было в составе дорогой платы для разработки, интегрированной в AI-камеру «Auto-Director» OBSBOT Tail 4Kp60 и экшн-камеру 4Kp120.

AAEON выпустила BOXER-8410AI AI Edge — безвентиляторный встраиваемый компьютер в корпусе на базе процессора Hi3559A V100ES — альтернативное решение аналогичным устройствам от Intel и NVIDIA.

Читать далее «Безвентиляторный встраиваемый компьютер в корпусе на базе процессора HiSilicon HI3559A с пятью ядрами, разработан для AI-камер 8K»

Недавно был написал обзор о “

Как мы научились подключать китайские камеры за 1000р к облаку. Без регистраторов и SMS (и сэкономили миллионы долларов) / Хабр

Всем привет!

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

Облачные системы видеонаблюдения решают эту задачу — предоставляя клиентам уже существующую инфраструктуру хранения и обработки видео. Клиенту облачного видеонаблюдения достаточно просто подключить камеру к интернету и привязать к своему аккаунту в облаке.

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

Для этого необходимо, чтобы на камере был установлен модуль ПО работающий с облаком. Однако, если говорить про дешевые камеры, то у них очень ограничены аппаратные ресурсы, которые почти на 100% занимает родная прошивка вендора камеры, а ресурсов необходимых для облачного плагина — нет. Этой проблеме разработчики из ivideon посвятили статью, в которой говорится почему они не могут установить плагин на дешевые камеры. Как итог, минимальная цена камеры — 5000р ($80 долларов) и миллионы потраченных денег на оборудование.

Мы эту проблему успешно решили. Если интересно как — велком под кат

В 2016 году мы стартовали разработку платформы облачного видеонаблюдения для Ростелекома.

В части ПО камер на первом этапе пошли «стандартным» для таких задач путем: разработали свой плагин, который устанавливается в штатную прошивку камеры вендора и работает с нашим облаком. Однако, стоит отметить, что при проектировании мы использовали наиболее легковесные и эффективные решения (например, plain C реализацию protobuf, libev, mbedtls и полностью отказались от удобных, но тяжелых библиотек типа boost)

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

Это означает, что для каждого вендора камер необходимо индивидуально разрабатывать объемный слой интеграционного ПО. И на момент старта разработки целесообразно работать только с 1-ним вендором, что бы сосредоточить усилия команды на разработке логики работы с облаком.

Первым вендором был выбран Hikvision — один из мировых лидеров на рынке камер, предоставляющий хорошо документированное API и грамотную инженерную техническую поддержку.

На камерах Hikvision мы и запустили наш первый пилотный проект облачное видеонаблюдение Видеокомфорт.

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

Вариант с реализацией слоя интеграции под каждого вендора я отбросил практически сразу — как плохо масштабируемый и предъявляющий к железу камеры серьезные технические требования. Стоимость камеры, удовлетворяющий таким требованиям на входе: ~60-70$

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

И что важно, при работе с камерой на низком уровне есть возможность использовать аппаратный AES, который шифрует данные, не создавая дополнительной нагрузки на маломощный CPU.

В тот момент у нас не было вообще ничего. Вообще ничего.

Практически все вендоры не были готовы работать с нами на таком низком уровне. Информации о схемотехнике и компонентах — нет, официальных SDK чипсетов и документации сенсоров — нет.

Технической поддержки так же нет.

Ответы на все вопросы приходилось получать реверс инжинирингом — методом проб и ошибок. Но мы справились.

Первыми моделями камер, на которых мы набивали шишки стали камеры Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link и несколько сверх дешевых безымянных китайских камер.

Камеры на чипсете Hisilicon 3518E. Аппаратные характеристики камер такие:

С них мы начинали.

Сейчас поддерживаем чипсеты Hisilicon 3516/3518, а так же Ambarella S2L/S2LM. Количество моделей камер — десятки.

uboot

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

Скрипт загрузки камеры достаточно тривиален:

bootargs=mem=38M console=ttyAMA0,115200 rootfstype=ramfs mtdparts=hi_sfc:256K(boot),64K(tech),4096K(kernel),8192K(app),-(config) hw_type=101
bootcmd=sf probe 0; sf read 0x82000000 0x50000 0x400000; bootm 0x82000000; setenv bootargs $(bootargs) bkp=1; sf read 0x82000000 0x450000 0x400000; bootm 0x82000000

Из особенностей — два раза вызывается bootm, подробнее об этом чуть позже, когда дойдем до подсистемы обновления.

Обратите внимание на строчку mem=38M. Да, да, это не опечатка — ядру Linux и всем-всем-всем приложениям доступно всего лишь 38 мегабайт оперативной памяти.

Так же рядом с uboot находится специальный блок, называемый reg_info, в котором находится низкоуровневый скрипт инициализации DDR и ряда системных регистров SoC. Содержимое reg_info зависит от модели камеры, и если оно будет не корректным, то камера даже не сможет загрузить uboot, а зависнет на самом раннем этапе загрузки.

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

Ядро linux и rootfs

На камерах используется ядро Linux, входящее в состав SDK чипа, обычно это не самые свежие ядра из ветки 3.x, поэтому часто приходится сталкиваться с тем, что драйвера дополнительного оборудования не совместимы с используемым ядром, и нам приходится их бэк-портировать под ядро камеры.

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

Rootfs — это базовая файловая система. В нее включены busybox, драйвера wifi модуля, набор стандартных системных библиотек, типа libld и libc, а так же ПО нашей разработки, отвечающее за логику управления светодиодами, управление сетевыми подключениями и за обновление прошивки.

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

Video application

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

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

В традиционных решениях ‘прошивка вендора + облачный плагин’, которые не могут работать на дешевом железе, видео внутри камеры передается по протоколу RTSP — а это огромный оверхед: копирование и передача данных через socket, лишние syscall-ы.

Мы в этом месте используем механизм shared memory — видео не копируется и не пересылается через socket между компонентами ПО камеры, тем самым оптимально и бережно используя скромные аппаратные возможности камеры.

Подсистема обновления

Предмет отдельной гордости — подсистема fault-tolerant онлайн обновления прошивки.

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

Мы справились и с этой проблемой. Даже если камеру выключить в момент обновления, она автоматически и без участия пользователя скачает прошивку из облака и восстановит работу.

Разберем технику подробнее:

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

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

Годное решение — однако, ядро с rootfs занимает около 3.5MB и для постоянной резервной копии нужно выделить 3.5MB. На самых дешевых камерах просто нет столько свободного места под backup ядра.

Поэтому для backup ядра во время обновления прошивки используем application партицию.

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

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

CI/CD система сборки и деплоя прошивок

Для сборки прошивок мы используем gitlab CI, в котором автоматически собираются прошивки под все поддерживаемые модели камер, после сборки прошивки автоматически деплоятся на сервис обновления ПО камер.

Из сервиса обновления ПО прошивки доставляются на тестовые камеры наших QA, а по завершению всех этапов тестирования и на камеры пользователей.

Информационная безопасность

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

Поэтому, весь не используемый функционал в нашей прошивке отключен, все tcp/udp порты закрыты и при обновлении прошивки проверяется цифровая подпись ПО.

И кроме этого, прошивка проходит регулярное тестирование в лаборатории информационной безопасности.

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

В проекте было задействовано более 70 тысяч камер с нашей прошивкой, которые были установлены по избирательным участкам нашей страны.

Решив ряд сложных, а местами, даже на тот момент практически невозможных задач, мы, конечно, получили огромное удовлетворение как инженеры, но кроме этого, и сэкономили миллионы долларов на закупке камер. И в данном случае, экономия — это не только слова и теоретические расчёты, а результаты уже случившегося тендера на закупку оборудования. Соответственно, если говорить про облачное видеонаблюдение: есть два подхода — стратегически заложиться на низкоуровневую экспертизу и разработку, получив на выходе огромную экономию на оборудовании или использовать дорогое оборудование, которое, если смотреть именно на потребительские характеристики, практически ничем не отличается от аналогичного дешевого.

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

Трюки и хаки при экспериментах с IPCam от Xiong Mai

Введение

Материал в стадии оформления. Последнее обновление – 2018.04.13

Используя данный Сайт, Вы выражаете свое согласие с «Отказом от ответственности» и принимаете всю ответственность за выполняемые действия с оборудованием и программным обеспечением на себя !

Просьба – при использовании материалов с сайта в своих проектах, указывать первоисточник. Спасибо!

Доступ в группу для различных обсуждений по IPCam и NVR возможен через WebIRC = Slack = Telegram

Благодарности

Данная информация является результатом совместной работы дружной компании:

• ESonya – Игорь, г.Сергиев Посад
• FlyRouter – Игорь, г.Симферополь
• max380 – Максим, г.Екатеринбург
• Oleg34 – Олег, г.Волгоград
• и много других товарищей…

Создание полного дампа с Flash устройства (ff, fullflash)

СТРОГО РЕКОМЕНДУЕТСЯ СДЕЛАТЬ ДАННУЮ МАНИПУЛЯЦИЮ ПЕРЕД ЛЮБЫМИ ЭКСПЕРИМЕНТАМИ !

Настройте TFTP сервер и проверьте доступ к нему

Выполните в консоли, нажав Ctrl+C для остановки загрузки ядра после подачи питания на модуль

Пример создания дампа для 8Mb Flash

#
set serverip 192.168.1.254                     // Установка адреса TFTP сервера
sf probe 0                                     // Разрешение доступа к флешке
mw.b 0x82000000 ff 1000000                     // Очистка памяти
sf read 0x82000000 0x0 0x800000                // Чтение всей флешки в память
tftp 0x82000000 ff.img 0x800000                // Выгрузка дампа (fullflash) на TFTP сервер

Пример создания дампа для 16Mb Flash

#
set serverip 192.168.1.254                     // Установка адреса TFTP сервера
sf probe 0                                     // Разрешение доступа к флешке
mw.b 0x82000000 ff 1000000                     // Очистка памяти
sf read 0x82000000 0x0 0x1000000               // Чтение всей флешки в память
tftp 0x82000000 ff.img 0x1000000               // Выгрузка дампа (fullflash) на TFTP сервер

Пример создания дампа для 16 Mb Flash на USB флешку (если есть USB порт и метод поддерживается загрузчиком)

#
usb start                                      // Инициализация USB
sf probe 0                                     // Разрешение доступа к флешке
mw.b 0x82000000 ff 1000000                     // Очистка памяти
sf read 0x82000000 0x0 0x1000000               // Чтение всей флешки в память
fatwrite usb 0:1 0x82000000 ff.img             // Выгрузка дампа (fullflash) на USB Flash

Откат на стоковую заводскую прошивку

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

Как правило, в программах CMS или Upgrade Tool такие камеры содержат перед Hardware ID цифры, вместо нулей. Например, обычная камера имеет HW ID 00022520, а вот заблокированная или заточенная под какой-то сервис будет выглядеть как 3422520.

Для решения данной проблемы, подберите свежую стоковую прошивку для вашего типа камеры, распакуйте её в каталог TFTP сервера, подключите UART консоль, войдите в загрузчик и выполните команды, приведенные ниже.

setenv serverip 192.168.1.254; sf probe 0; sf lock 0; run dc; run dr; run du; run dw; reset

После прошивки, камера перезагрузится и будет доступна уже с пустым префиксом (нули) перед HW ID. Так как в целях защиты от “дурака” консольной командой выше загрузчик НЕ обновляется, то для его замены желательно повторно обновить прошивку уже стандартными средствами.

Обновление из полного дампа устройства (ff, fullflash) через консоль

Настройте TFTP сервер и положите на него фаил дампа ff.img

Важно ! В результате вы получите полный дубликат устройства с которого сняли дамп !

Выполните в консоли, нажав Ctrl+C для остановки загрузки ядра после подачи питания на модуль

Ниже приведен пример обновление из полного дампа для 8Mb Flash

#
set serverip 192.168.1.254                     // Устанавка адреса TFTP сервера
sf probe 0                                     // Разрешение доступа к флешке
mw.b 0x82000000 ff 1000000                     // Очистка памяти
tftp 0x82000000 ff.img                         // Загрузка в память дампа (fullflash)
sf erase 0x000000000000 0x800000               // Очистка всей флешки под запись
sf write 0x82000000 0x000000000000 0x800000    // Запись дампа (fullflash) из памяти на флешку
reset                                          // Рестарт устройства

Ниже приведен пример обновление из полного дампа для 16Mb Flash

#
set serverip 192.168.1.254                     // Устанавка адреса TFTP сервера
sf probe 0                                     // Разрешение доступа к флешке
mw.b 0x82000000 ff 1000000                     // Очистка памяти
tftp 0x82000000 ff.img                         // Загрузка в память дампа (fullflash)
sf erase 0x000000000000 0x1000000              // Очистка всей флешки под запись
sf write 0x82000000 0x000000000000 0x1000000   // Запись дампа (fullflash) из памяти на флешку
reset                                          // Рестарт устройства

Обновление загрузчика (u-boot bootloader) через консоль

Настройте TFTP сервер и положите на него фаил u-boot.bin

Важно ! Всегда проверяйте первый байт загрузчика что-бы не получить “кирпич” !

Важно ! Крипто-раздел, прикреплённый к загрузчику в данном примере будет уничтожен !

Выполните в консоли, нажав Ctrl+C для остановки загрузки ядра после подачи питания на модуль

#
mw.b 0x82000000 0xFF 0x40000                   // Очистка памяти под запись
set serverip 192.168.1.254                     // Устанавка адреса TFTP сервера
mw.b 0x82000000 ff 1000000                     // Очистка памяти
tftp 0x82000000 u-boot.bin                     // Загрузка в память загрузчика
sf probe 0                                     // Разрешение доступа к флешке
sf erase 0 0x40000                             // Очистка части флешки под запись
sf write 0x82000000 0 0x40000                  // Запись загрузчика из памяти на флешку
reset                                          // Рестарт устройства

Пример прошивки устройств с USB флешки

#
usb start
mw.b 0x82000000 ff 1000000
fatload usb 0:1 0x82000000 dump.bin
sf probe 0
sf lock 0
sf erase 0 0x1000000
sf write 0x82000000 0 0x1000000

Включение отображения процесса загрузки ядра Linux

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

Включение режима возможно в самом Linux, если зайти на устройство по Telnet.

#
armbenv -s xmuart 0                            // Включение отображения загрузки ядра Linux
reboot                                         // Рестарт устройства

Изменение некоторых системных параметров

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

Все переменные можно изменять как непосредственно в Linux, так и в самом загрузчике.

Так, например, выполнение appauto 0 позволяет отключить проверку работы и наличия Sofia в системе.

А выполнение setenv telnetctrl 1; saveenv попытается включить Telnet сервер.

Список переменных можно запросить командой armbenv -r. Ниже представлен пример выполнения команды.

#
bootdelay = 1
baudrate = 115200
serverip = 192.168.1.1
ipaddr = 192.168.1.10
netmask = 255.255.255.0
ethaddr = 00:12:21:10:a3:d5
xmuart = 0
xmauto = 0                                     // Watchdog для перезагрузки камеры
telnetctrl = 1
NID = 0x0003

Очистка MTD раздела на Flash камеры (сброс настроек)

ВЫ ДОЛЖНЫ ОТДАВАТЬ СЕБЕ ОТЧЁТ О ПРОДЕЛЫВАЕМЫХ ОПЕРАЦИЯХ !

Для вычисления адреса и размера стираемого раздела необходимо смотреть MTD partitions.

Выполните в консоли, нажав Ctrl+C для остановки загрузки ядра после подачи питания на модуль.

Получение базовой информации по плате XM

Для получения базовой информации по плате XM выполните команду dvrbox в консоли

# dvrbox
LibCrypto : g_cryptotype = 1
00:12:16:d8:6f:89
*************************************************
|                      SYSTEM INFO
|                 ID:           8043421804748432
|       product type:           53h23
|            product:           HI3518E_53h23_S39
|      video channel:           1
|      audio channel:           1
|           alarm in:           1
|          alarm out:           1
| forward video chip:           AR0130
|           DSP chip:           HI3518E
|  analog audio mode:           voice codec
|           talkback:           voice codec
|    back video chip:           no chip
|    store interface:           SDIO
|    matrix surpport:           No
| wireless interface:           USB
|    hardware encode:           encode chip
|   hardware version:           1
|    video_interface:           BNC
|      net_interface:           Ethernet
|  hardware info len:           8
*************************************************
LIBDVR: Complied at Sep 12 2016 10:37:43 SVN:1579

Типовые полезные команды

Сканирование локальной сети для поиска видеокамер

clear; nmap -p 23,80,554 192.168.1.1-254

Запуск Telnet сервера на камере без авторизации

telnetd -F -p 4321 -l /bin/ash

Внутренние ссылки

Внешние ссылки

Хакинг IP-камер на базе SoC HI3518

Введение

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

Все имеющиеся в наличии WEB-камеры попадают в категорию 720p (по железу), однако, перечисленные ниже наработки подойдут и к большинству аналогичного оборудования, произведенного в Китае.

Самое важное и интересное – ссылки внизу по этому SoC !!!

Типы камер и их WEB-интерфейсы

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

Несмотря на одинаковую электронную “начинку”, камеры весьма значительно отличаются WEB-интерфейсом, прошивками и функционалом.

Камера #1

Отличительные особенности:

• множество настроек на камере можно сделать непосредственно из браузера
• поддерживаются любые браузеры
• медиапорт 34567 для CMS данной камерой НЕ поддерживается

Заводские настройки:

Открытые TCP порты:

# pscan 192.168.1.10
Scanning  192.168.1.10
 Port   Proto   State   Service
   80   tcp     open    www
  554   tcp     open    rtsp
 8080   tcp     open    onvif

Получение снапшотов:

• http://login:[email protected]/tmpfs/auto.jpg
• http://login:[email protected]/tmpfs/snap.jpg

Утилита управления (смена IP, сброс на заводские настройки):

Камера #2

Hardware

# dvrHelper
****************************************************
|                      SYSTEM INFO
|                 ID:           8043420004048425
|            product:           HI3518E_50h20L_S39
| forward video chip:           OV9712
| wireless interface:           USB
|   hardware version:           1
|      net_interface:           Ethernet
****************************************************

Отличительные особенности:

• интерфейс достаточно аскетичен
• поддерживается только IE браузер с плагином QuickTime (или хаки)
• поддерживается медиапорт 34567 для CMS

Заводские настройки:

Открытые TCP порты:

# pscan 192.168.1.10
Scanning  192.168.1.10
 Port   Proto   State   Service
   80   tcp     open    www
  554   tcp     open    rtsp
 8899   tcp     open    onvif
 9527   tcp     open    unknown
 9530   tcp     open    unknown
34567   tcp     open    for_cms

Получение снапшотов:

• http://192.168.1.10/webcapture.jpg?command=snap&channel=1

Утилита управления (смена IP, сброс на заводские настройки, обновление прошивки):

• General_DeviceManage_V2.5.2.1.T.20150820.exe

Структурные схемы

В процессе описания..

Image Sensor:1/4" Progressive Scan CMOS OV9712
Effective Pixels: 1280(H)x720(V)
Min. Illumination:Color: 0. 1Lux, B/W: 0.01Lux ; 0Lux(IR on)
Max. IR LEDs Length:Φ5 36pcs IR Led , IR Range 15m
Day/Night:Auto(ICR) / Color / B/W
White Balance:Auto
Gain Control:Auto/Manual
Focal Length:6mm
Max Aperture:F1.6
Angle of View:39.8
Mount Type:MTV mount (Interchangeable Lens)
Compression:H.264
Main Stream:HD 720P (1280*720) 25fps
Sub Stream:VGA 640*360 25FPS

Получение изображений

Пример получения маленького изображения

http://login:password@webcam_ip_address/tmpfs/auto.jpg

Пример получения изображения в формате HD

http://login:password@webcam_ip_address/tmpfs/snap.jpg

Справочник

rtsp://192.168.1.15/user=admin_password=mypass_channel=1_stream=0.sdp?real_stream

rtsp://192.168.1.15:554/user=admin&password=mypass&channel=0&stream=0.sdp?real_stream--rtp-caching=100

rtsp://<ip address>:554/11 -> 720P resolution or "MainFlow"
rtsp://<ip address>:554/12 -> VGA or "MinorFlow"
rtsp://<ip address>:554/13 -> the lowest "mobile phone" QVGA resolution

Очистка настроек – (cd /mnt/mtd ; rm -rf *)

Поддерживает вайфайные свистки на чипсете rt3070sta

Прошивка поддерживает три чипсета WiFi: MT7601U, RT5370 и RT2870

1. Захотим в загрузчик. (Включили питание и в течении 1 сек нужно нажать любую кавишу)
2. Добавляем к командной строке ядра опцию init и загружаемся.
hisilicon # setenv bootargs mem=43M console=ttyAMA0,115200 root=/dev/mtdblock2 rootfstype=jffs2 mtdparts=hi_sfc:512K(boot),2560K(kernel),13M(rootfs) init=/bin/sh
hisilicon # sf probe 0
16384 KiB hi_sfc at 0:0 is now current device
hisilicon # sf read 0x82000000 0x80000 0x280000
hisilicon # bootm 0x82000000
# cat /etc/shadow
# echo "root:\$1\$tiaLlxGM\$dYNMJJQRKN2buGE0u/R88/:16199:0:99999:7:::" > /etc/shadow
# echo "admin:\$1\$tiaLlxGM\$uIJ4ahSynKJuzEzWdw7sp/:16199:0:99999:7:::" >> /etc/shadow
# sync
Парезагружаем, всё! Теперь у камеры пароль для root стал root и для admin стал admin.

Список открытых портов

# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address   State
tcp        0      0 0.0.0.0:34599   0.0.0.0:*         LISTEN
tcp        0      0 0.0.0.0:34567   0.0.0.0:*         LISTEN
tcp        0      0 0.0.0.0:34561   0.0.0.0:*         LISTEN   <= CMS
tcp        0      0 0.0.0.0:9527    0.0.0.0:*         LISTEN
tcp        0      0 0.0.0.0:8899    0.0.0.0:*         LISTEN   <= ONVIF
tcp        0      0 0.0.0.0:554     0.0.0.0:*         LISTEN   <= RTSP
tcp        0      0 0.0.0.0:80      0.0.0.0:*         LISTEN   <= HTTP
tcp        0      0 0.0.0.0:23      0.0.0.0:*         LISTEN   <= TELNET

Монтирование каталогов

# mount
rootfs on / type rootfs (rw)
/dev/root on / type cramfs (ro,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
/dev/mtdblock2 on /usr type squashfs (ro,relatime)
/dev/mtdblock3 on /mnt/web type squashfs (ro,relatime)
/dev/mtdblock4 on /mnt/custom type cramfs (ro,relatime)
/dev/mtdblock5 on /mnt/mtd type jffs2 (rw,relatime)
/dev/mem on /var type ramfs (rw,relatime)
/dev/mem2 on /utils type ramfs (rw,relatime)
usbfs on /proc/bus/usb type usbfs (rw,relatime)

Заметки

Получение информации о процессоре камеры

cat /mnt/custom/ProductDefinition | grep -e "Hardware"
"Hardware" : "HI3518E_50h20L_S39",

Раздел mtd4 монтируется в системе в папку /mnt/custom

mount -t squashfs /dev/mtdblock4 /mnt/custom

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

/mnt/custom/extapp.sh

Для того, что-бы получить shell на консоли, можно выполнить команду, зайдя по Telnet

/sbin/getty -L ttyS000 115200 vt100 -n root -I "Auto login as root ..."

Настройки сети находятся тут /mnt/mtd/Config/network и их можно изменить командами

echo "HOSTIP = 172.17.32.101" >/mnt/mtd/Config/network
echo "SUBMASK = 255.255.255.0" >>/mnt/mtd/Config/network
echo "GATEWAYIP = 172.17.32.1" >>/mnt/mtd/Config/network

Таблица устройств [DeviceType C6F0SeZ3N0P0L0]

Внутренние ссылки

Внешние ссылки

• MySku: Самая дешевая HD IP-камера
• MySku: Настройка фокуса камеры на бесконечность
• Geektimes: Из аналога в цифру, или IP-камера своими руками
• Форум: Как прошить камеру через загрузчик U-Boot по Telnet
• Форум: Обсуждение камер 1мп на процессоре Hi3518C
• Иследование китайской IP камеры
• Китайская NoName IP-видеокамера на основе чипа HI3518E_50h20L_S39
• Видеонаблюдение на основе IP-камер и Xeoma
• Разбираемся с настройками камеры с медиапортом 34567
• Конфигурация и прошивки Китайских IP-камер
• Прошивки для регистраторов и камер от XM [порт 34567]
• —
• IP Camera CGI Application Guide [pdf]
• Hacking Cheap eBay IP Camera [Best]
• IPCAM review – IPR1631, Hi3516 [SDK, Toolchain]
• Part 1: Hacking HI3518 based IP camera
• Hacking a cheap Chinese IP Camera HRX-I5024
• Super Mini 720P HD IP-Cam
• XMeye Hi3518E-based camera module
• China IP camera configuration & firmware
• IP camera SoC – HI3518E vs HI3518C
• —
• GitHub: HI35XX buildroot [!]
• GitHub: HI3518E camera
• GitHub: HI3518E buildroot
• GitHub: HI3518E osdrv
• —
• Linux boot log from a cheap Hi3518 chinese IP Camera
• I got new Hi3518 IP Camera modules
• Open IP Camera Forum
• Cheap ONVIF Chinese Camera – quickie review UPDATED
• —
• Hi3518E 720p IP-Cam SOC – pdf document
• Hi3518E buildroot
• —
• $15 RobinCore WiFi IoT модуль работает под управлением OpenWrt, поддерживает 720p видео кодирование
• $15 RobinCore WiFi IoT Module Runs OpenWrt, Supports 720p Video Encoding
• RobinCore home page
• —
• Habrahabr: Burn-in рутовый шелл в IP-камерах Vesta и не только
• Исправляем ошибки своими руками, или баг, который «никого не колышет»
• Что нам стоит пофиксить баг, которого «нет»
• Распаковка, редактирование и упаковка прошивок видеорегистраторов и IP камер из Китая
• Распаковка, редактирование и упаковка прошивок видеорегистраторов и IP камер из Китая
• Распаковка, редактирование и упаковка прошивок видеорегистраторов и IP камер из Китая
• —
• Hot firmware for HI3518E based devices !
• Best software archive
• Firmware for IPC18E_50h20L_S38 V4.0.R12.00006510.1
• Обновляемые прошивки на IP-камеры и мини-NVR

Уязвимость

0day (бэкдор) в прошивке для видеорегистраторов, сетевых видеорегистраторов и IP-камер на базе Xiaongmai / Хабр

Это полное раскрытие недавнего бэкдора, интегрированного в устройства DVR / NVR, построенные на базе HiSilicon SoC с прошивкой Xiaongmai. Описанная уязвимость позволяет злоумышленнику получить доступ к корневой оболочке и полный контроль над устройством. Формат полного раскрытия информации для этого отчета был выбран из-за отсутствия доверия к поставщику. Доказательство концептуального кода представлено ниже.

Предыдущая работа и исторический контекст

В самых ранних известных версиях был включен доступ по telnet со статическим паролем root, который можно было восстановить из образа прошивки с (относительно) небольшими вычислительными затратами.Об этой уязвимости говорилось в предыдущей авторской статье в 2013 году. В 2017 году Иштван Тот провел наиболее полный анализ прошивки цифрового видеорегистратора. Он также обнаружил уязвимость удаленного выполнения кода на встроенном веб-сервере и многие другие уязвимости. Стоит отметить, что производитель проигнорировал раскрытие информации.

В более поздних версиях прошивки по умолчанию отключены доступ через Telnet и порт отладки (9527 / tcp). Вместо этого у них был открытый порт 9530 / tcp, который использовался для приема специальной команды для запуска демона telnet и включения доступа к оболочке со статическим паролем, который одинаков для всех устройств.Такой случай освещен в этих статьях:

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

Технические характеристики

Обсуждаемые уязвимые устройства DVR / NVR / IP-камеры работают под управлением Linux с минимальным набором утилит, предоставляемым busybox, основным видеоприложением Sofia и небольшим набором специальных дополнительных утилит, отвечающих за поддержку работы устройства.Оборудование имеет процессор на базе ARM от десятков до сотен мегабайт оперативной памяти. Устройство

с уязвимой прошивкой имеет процесс macGuarder или dvrHelper , работающий и принимающий соединения через TCP-порт 9530. Код и строки журнала предполагают, что macGuarder раньше был отдельным процессом, но позже его функции были объединены в процесс dvrHelper как отдельный поток.

Стоит отметить, что в более ранних версиях прошивки процесс dvrHelper был скомпилирован в busybox как дополнительный апплет.Принимая во внимание, что busybox имеет лицензию GNU GPL, возможно, что нарушение лицензии имеет место из-за того, что программное обеспечение dvrHelper распространялось без исходного кода.

Успешный процесс активации бэкдора выглядит следующим образом:

1. Клиент открывает соединение с портом TCP-порт 9530 устройства и отправляет строку OpenTelnet: OpenOnce с добавлением байта, указывающего общую длину сообщения. Этот шаг является последним для предыдущих версий бэкдора. Если после этого шага ответа нет, возможно, telnetd уже был запущен.
2. Сервер (устройство) отвечает строкой randNum: XXXXXXXX , где XXXXXXXX — 8-значное случайное десятичное число.
3. Клиент использует свой предварительный общий ключ и создает ключ шифрования как объединение полученного случайного числа и PSK.
4. Клиент шифрует случайное число с помощью ключа шифрования и отправляет его после строки randNum: . Ко всему сообщению добавляется байт, указывающий общую длину сообщения.
5. Сервер загружает тот же общий ключ из файла / mnt / custom / TelnetOEMPasswd или использует ключ по умолчанию 2wj9fsa2 , если файл отсутствует.
6. Сервер выполняет шифрование случайного числа и проверяет, что результат идентичен строке от клиента. В случае успеха сервер отправляет строку verify: OK или verify: ERROR в противном случае.
7. Клиент шифрует строку Telnet: OpenOnce , добавляет к ней байты общей длины, CMD: строку и отправляет на сервер.
8. Сервер извлекает и дешифрует полученную команду. Если результат дешифрования равен строке Telnet: OpenOnce , он отвечает Open: OK , включает порт отладки 9527 и запускает демон telnet.

Весь процесс аутентификации может напоминать некую разновидность аутентификации запрос-ответ HMAC, за исключением того, что он использует симметричный шифр вместо хэша. Этот конкретный симметричный шифр напоминает некоторый вариант 3DES-EDE2 для ключей длиной более 8 байтов и похож на простой DES для более коротких ключей.

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

• Ghidra 9.1.1 от NSA (https://ghidra-sre.org/) — набор для проверки исполняемого двоичного кода.
• QEMU (точнее qemu-user в Debian chroot — https://www.qemu.org/) — программное обеспечение, которое позволяет прозрачно выполнять исполняемые файлы сторонней архитектуры (ARM) на хосте.
• Общие утилиты и набор инструментов GNU.

После активации демон telnet очень вероятно, что он примет одну из следующих пар логин / пароль:

Эти пароли можно восстановить как из прошивки, так и путем перебора хешей в файле / etc / passwd . Современный GPGPU потребительского уровня с hashcat способен находить предварительный образ для хеширования за считанные часы.

Порт отладки 9527 принимает тот же логин / пароль, что и веб-интерфейс, а также предоставляет доступ к оболочке и функции для управления устройством. Говоря об учетных записях веб-интерфейса, злоумышленник может сбросить пароль или получить хэши паролей из файлов / mnt / mtd / Config / Account * .Хеш-функция была описана в предыдущем исследовании Иштвана Тота.

Затронутые устройства

Предыдущее исследование показало хорошую коллекцию затронутых брендов: https://github.com/tothi/pwn-hisilicon-dvr#summary. Существуют десятки марок и сотни моделей.

Автор этого отчета, основываясь на опросе случайных IP-адресов, оценивает общее количество уязвимых устройств, доступных через Интернет, где-то между сотнями тысяч и миллионами.

Наверное, самый простой способ проверить, уязвимо ли ваше устройство, — это PoC-код, указанный ниже.

Тестирование уязвимости

PoC-код: https://github.com/Snawoot/hisilicon-dvr-telnet.

Построение программы PoC из исходного кода: запустите make в исходном каталоге.

Использование: ./hs-dvr-telnet HOST PSK

Самый распространенный PSK по умолчанию: 2wj9fsa2 .

Пример сеанса:

$ telnet 198.51.100.23
Пробуем 198.51.100.23 ...
telnet: невозможно подключиться к удаленному хосту: в соединении отказано
$ ./hs-dvr-telnet 198.51.100.] '.
Логин LocalHost: root
Пароль:
 

IP-адрес в приведенном выше примере — это IP-адрес из блока адресов, зарезервированный для документации RFC5737.

Устройство следует считать уязвимым, если:

• Telnet-порт открывается после запуска hs-dvr-telnet .
• Устройство отвечает запросом на запрос hs-dvr-telnet . Даже если проверка не удалась из-за неправильного PSK, существует правильный PSK, извлекаемый из прошивки.
• hs-dvr-telnet зависает в ожидании ответа, но порт telnet открывается (это произойдет со старыми версиями прошивки, для которых требуется только команда OpenTelnet: OpenOnce ).

Смягчение

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

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

Объекты, не включенные в данное исследование

Анализ кода показал, что процедура аутентификации на порту 9530 расшифровывает полезную нагрузку «CMD» произвольного размера (до размера буфера, считываемого сразу из сокета) в буфер на стеке с фиксированным размером 32 байта. Целенаправленное использование этого переполнения требует знания PSK, поэтому для получения доступа более практично действовать обычным способом. С другой стороны, мусор, отправленный с командой CMD, может вызвать повреждение стека и сбой демона dvrHelper.Возможные последствия этого (потенциального) сбоя не изучались, потому что бэкдор macGuarder / dvrHelper выглядит строго превосходным и прямым подходом.

ОБНОВЛЕНИЕ (2020-02-05 02: 10 + 00: 00): Иштван Тот, автор предыдущих исследований по этой теме, представил свою собственную реализацию программы PoC: https://github.com/tothi/hs- dvr-telnet Данная реализация написана на чистом коде Python и реализует симметричный шифр более понятным образом. Также в нем описаны различия между вариантом шифра 3DES, используемым Xiongmai для аутентификации бэкдора, и оригинальным шифром 3DES.Эти различия можно выразить с помощью этого коммита git: https://github.com/tothi/pyDes/commit/7a26fe09dc5b57b175c6439fbbf496414598a7a2.

ОБНОВЛЕНИЕ (2020-02-05 17: 28 + 00: 00): Другие исследователи и пользователи Хабра отметили, что такая уязвимость ограничена устройствами на базе программного обеспечения Xiongmai (Hangzhou Xiongmai Technology Co, XMtech), включая продукты другие поставщики, которые поставляют продукты на основе такого программного обеспечения. На данный момент HiSilicon не может нести ответственность за бэкдор в двоичном файле dvrHelper / macGuarder.

ОБНОВЛЕНИЕ (2020-02-21 10: 30 + 00: 00): Xiaongmai признал уязвимость и выпустил рекомендации по безопасности: ссылка, архив 1, архив 2. Тело фактической статьи было обновлено соответствующим образом, чтобы отразить происхождение. уязвимости должным образом.

.

Обзор компании | HiSilicon

Обзор компании

HiSilicon — мировой лидер в области разработки полупроводников и интегральных схем без фабрик, специализирующийся на предоставлении комплексных решений для подключения и мультимедийных чипсетов. Как видный лидер отрасли HiSilicon прокладывает путь инновациям в области глобальной связи и сквозных видеотехнологий Ultra-HD.

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

 Для беспроводной связи технологическое лидерство является огромным достижением, и ему в основном способствует стремление компании к инновациям.Это включает в себя успешный запуск модемов Balong с LTE Cat.4, Cat.6, Cat.12/13, Cat.18, Cat.19, Cat.21, двумя SIM-картами и двумя LTE (с VoLTE) и псевдобазой. -технологии защиты станций опережают других поставщиков. HiSilicon первым начал коммерциализацию беспроводных чипсетов 5G, чтобы способствовать развитию отрасли 5G.

 Для интеллектуальных устройств SoC HiSilicon Kirin обеспечивают высокопроизводительные, энергоэффективные и сверхинтеллектуальные мобильные ИИ-решения для обеспечения максимального удобства пользователей.

 Для центров обработки данных HiSilicon разрабатывает серверные процессоры ЦП серии Kunpeng на основе архитектуры ARM. Обладая выдающейся производительностью, пропускной способностью, интеграцией и энергоэффективностью, процессоры серии Kunpeng применяются в широком диапазоне сценариев, таких как большие данные, распределенное хранилище, собственное приложение ARM, отвечая разнообразным вычислительным требованиям центров обработки данных.

 Для приложений искусственного интеллекта HiSilicon предлагает универсальный набор микросхем AI на базе SoC серии Ascend для распространения ИИ от центра обработки данных до периферии и устройства, предлагая вычислительную мощность искусственного интеллекта для центров обработки данных, периферии, потребительских устройств и сценариев Интернета вещей, а также предлагает совершенно новые решения для инновационных сценариев использования, таких как безопасный город, самоуправление, облачные услуги, ИТ-интеллект, интеллектуальное производство и роботы, чтобы ускорить внедрение ИИ в каждой области.

 Для видеоприложений HiSilicon выпустила ведущие в мире микросхемы для интеллектуальных IP-камер, интеллектуальных STB и интеллектуальных телевизоров, предоставляя комплексные продукты и решения с разрешением 4K, ориентированные на запись, декодирование и отображение изображений.

 Для приложений Интернета вещей HiSilicon выпустила продукты PLC / G.hn / Connectivity / NB-IoT для создания сети надежных и безопасных каналов, которые служат для подключения цифровых устройств в каждом доме и в различных отраслях промышленности.

Компания HiSilicon со штаб-квартирой в Шэньчжэне, Китай, имеет более 7000 сотрудников в офисах и исследовательских центрах в Пекине, Шанхае, Чэнду, Ухане, Сингапуре, Южной Корее, Японии, Европе и других регионах мира.После 20 лет исследований и разработок HiSilicon создала сильное портфолио технологий проектирования и проверки ИС, разработала передовую платформу проектирования EDA и отвечает за создание нескольких процессов и правил разработки. За прошедшие годы HiSilicon успешно разработала более 200 моделей с собственными правами интеллектуальной собственности и зарегистрировала более 8000 патентов. HiSilicon также установил стратегические партнерские отношения с мировыми лидерами экосистемы, в частности, в области проектирования (производство пластин), упаковки и тестирования в надежной цепочке поставок.

Миссия HiSilicon — предоставлять решения и услуги высочайшего качества с быстрым ответом на запросы клиентов. HiSilicon ориентирован на клиента и стремится к созданию ценности для клиентов.

.

c ++ — SDK пользовательского интерфейса для процессора HiSilicon

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

.Приставка

| HiSilicon

Телеприставки

Обзор рынка

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

Более десяти лет HiSilicon играет значительную роль в ускорении инноваций в видеоиндустрии. Мы посвящаем себя предоставлению ориентированных на клиента решений с оптимальным качеством изображения, используя наш обширный опыт обработки изображений. HiSilicon прокладывает путь от Ultra HD 4K до 8K и даже больше в будущем.

Наборы микросхем и решения

HiSilicon продаются ряду ведущих производителей телевизионных приставок, которые поддерживают операторов во внедрении множества дополнительных услуг и услуг, таких как вещание, VOD, PVR, распространение нескольких видео, видеотелефон, VR ( виртуальная реальность) / AR (дополненная реальность) / панорамное видео на 360 градусов, визуальный контроль входа, домашнее наблюдение и т. д.Весь спектр продуктов и решений включает оптический доступ, подключение к домашней сети, домашний шлюз, телевизионную приставку, ключ и т. Д. Мы поддерживаем различное промежуточное программное обеспечение, усовершенствованные CAS (системы условного доступа), DRMS ​​(системы управления цифровыми правами) и Операционные системы Linux, Android и TVOS.

HiSilicon является основным членом организаций по стандартизации MPEG, ITU, IEEE, HEVC, TVOS, AVS, China-DRM и уже внесла массу положительных вкладов в развитие видеоиндустрии.

Посмотреть больше продуктов

.