понедельник, 4 февраля 2013 г.

Прошивка DVR Asenware DN8004 (HI3515 based)

Эта история началась с того, что данный девайс Asenware DN8004 был куплен в Китае, через AliExpress. Его функционал соответственно, был довольно тривиален, и аналогичен многим подобным устройствам, но, для дома он подходил вполне неплохо. Единственное, что меня не совсем устраивало — передача видео-потока по сети осуществлялась в 2-х вариантах. Первый — через порт 2200, без шифрования, в собственную проприетарную утилиту под Windows, второй — через ActiveX-компонент в IE. Оба эти варианта подходили для Windows, но не подходили для Linux, на котором я работаю. В принципе, утилита для просмотра, после установки VC++ 6 в wine запускалась, и даже более-менее работала, но результат меня не удовлетворил. Было принято решение добраться до внутренностей девайса, чтобы понять, как можно исправить дискриминацию по ОС.
Сканирование портов выявило наличие telnetd-сервиса в устройстве, но, вход, как и следовало ожидать, оказался запаролен. Традиционные варианты не подошли, и стало ясно, что без дистрибутива самой прошивки дело не пойдет.


Поиски начались с внутренней страницы устройства. Примечательно, что при отсутствии установленного ActiveX-компонента, или просто при заходе с любого браузера, мы видим строчку:





Ссылка ведет на http://dy.vip620.com/network/dfcb/Install.exe
При попытке зайти напрямую на http://dy.vip620.com/ меня ждало разочарование — появляется страница входа с капчей. Эксперименты с подбором логина не дали результатов, поэтому мне пришла в голову мысль зайти с другого конца, и, как оказалось не зря. Ссылка http://dy.vip620.com/firmware/ привела меня именно туда, куда нужно.
Была скачена прошивка http://dy.vip620.com/firmware/upgrade/commonnew/dn8004_v0401.rar
На устройстве, на тот момент, была установлена версия 0302.
Далее дело было за малым. Распаковать и посмотреть что к чему.

Распакованный архив состоял из 3-х файлов — app_dn8004_v0401, kernel_dn8004_sdkv051_v0002 и rootfs_dn8004_v0401

Выводы binwalk дали понять с чем я имел дело:


Меня, главным образом интересовали rootfs и app, поэтому дальнейшую работу я продолжил с ними.
app_dn8004_v0401 можно было примонтировать без особых проблем через:

mount -t cramfs -o loop ./app_dn8004_v0401 /mnt/temp_app

В данном файле содержалась вся программная оболочка, которую использовал DVR. Также в нем находились модули ядра и библиотеки для ввода видео.
Корневая ФС монтировалась более сложно (спасибо http://bitjuggling.blogspot.ru/2008/08/jffs2-to-targz.html):

modprobe mtdram total_size=131072 erase_size=128

modprobe mtdblock

dd if=rootfs_dn8004_v0401 of=/dev/mtdblock0

mount -t jffs2 /dev/mtdblock0 /mnt /temp_rootfs

После монтирования, я увидел, именно то, что хотел — файловую структуру emb linux.
Беглый просмотр дал понять, что система довольно урезана (что, вобщем, не удивительно). Почти все возможные команды были симлинками на busybox. Раздел /etc содержал самые основные конфиги системы:





Поскольку первоначальная задача была в том, чтобы зайти на работающее устройство, я решил попробовать расшифровать хеши рута и пользователя «ken».
Для их расшифровки использовался небезызвестный John The Ripper и несколько словарей с просторов интернета. Результата не было, ровно как и после 5 дней брутфорса. Стало ясно, что решить проблему можно только модификацией прошивки.

Для модификации была выбрана rootfs (как оказалось в последствии - зря).
Журналируемая файловая система JFFS2 довольно часто встречается на различного рода мобильных устройствах, планшетах, роутерах, etc, но с ней лично, я сталкивался впервые.
Для того, чтобы получить нужные мне хеши для замены их в КФС прошивки, а также для того, чтобы посмотреть версию и команды встроенного busybox, я поднял виртуальную ОС ARM-архитектуры. Помог мне в этом эмулятор QEMU и образ установленного ARM Debian Lenny. После копирования библиотек КФС прошивки, я смог запустить busybox. Вывод команды:

 
Хеши рута и пользователя я взял из этой же системы.
После этого требовалось только запаковать нашу ФС и залить ее на DVR. Я понимал, что попытка у меня будет только 1-а, поскольку заливка производилась через оболочку девайса.
ФС была запакована командой:

mkfs.jffs2 -p -d /mnt/temp_rootfs -e 128KiB -o rootfs_dn8004_v0401

Меня смущал только размер Erase Block микросхемы памяти (WINBOND W29GL064CB7S). В Datasheet на данный чип подобной информации не указывалось.
Продолжительные поиски в сети, так же не дали ничего конкретного, поэтому пришлось собирать так. Сравнение файлов в hexedit говорило о том, что исходный и полученный файл по своей структуре похожи, за вычетом сделанных изменений.
Но, ошибка все же где-то была. То ли надо было собирать с ключом 64KiB, то ли была еще какая-то причина, которую я упустил. Прошивка прошла успешно, но после перезагрузки устройство более не выходило в готовность.

Поскольку я ранее имел дело с различного рода устройствами и их прошивками, а также заливками оных через самособранный программатор (или несколькими проводками и LPT-разъемом :)) то, разумеется, первая мысль, пришедшая мне в голову была именно ручная перепрошивка flash с выпаиванием детали.
Но тут были проблемы — во-первых отсутствие здесь фена в наличии, а также отсутствие возможности прошивки «простым» способом. Проконсультировавшись с ребятами с ROM.by, я понял, что ручная перепрошика Parallel Flash, коим являлся W29GL064CB7S, будет очень непростой, как и сборка программатора под него. Оставив этот вариант на крайний случай, я стал изучать плату на предмет возможного решения:




И оно нашлось в виде UART-выхода на плате. Поскольку я был не совсем уверен в то, что это UART (rx\tx конечно говорят об этом, но мне не очень верилось, что китайцы стали бы заморачиваться с выходом), я воспользовался осциллографом для подтверждения. Это, без сомнения был он.
Далее, найдя в запасах старый кабель для телефона на PL-2303, я подключился к несчастному через minicom (аргументы запуска minicom -l -8 -c on -s, аппаратное управление потоком отключить), и увидел именно то, что хотел.



 
Многое стало ясно:
В роли загрузчика 2-ого уровня использовался U-Boot, который управлял загрузкой ядра, которая в свою очередь подгружала КФС и Cramfs.
По логу видно, что ядро не может подгрузить залитую КФС и падает в Kernel Panic.
По нажатию Ctrl+C при запуске девайса можно было выйти в командную строку U-Boot. Оттуда я выставил Environment для загрузки образа КФС по сети, приведя его к следующему виду:
bootcmd=bootm 0x80080000

bootdelay=1

baudrate=115200

ethaddr=00:11:00:34:76:21

bootfile="uImage"

filesize=14BCD8

fileaddr=80200000

netmask=255.255.255.0

bootargs=mem=48M console=ttyAMA0,115200 root=1f02 rootfstype=jffs2 mtdparts=physmap-flash.0:512K(boot),1536K(kernel),2M(rootfs),4M(app),8M@0(flash) pcimod=host pciclksel=1

gatewayip=10.10.0.1

serverip=10.10.0.254

ipaddr=10.10.0.180

stdin=serial

stdout=serial

stderr=serial

verify=n

ver=U-Boot 2008.10 (Aug 3 2011 — 05:16:21)
Попытки просмотреть ФС через ls или fsinfo приводили к зависанию устройства. Команда mtest также, либо выводила Fatal Error, либо вешала систему.
Вывод flinfo показывал:
Bank # 1: CFI conformant FLASH (8 x 8) Size: 8 MB in 135 Sectors

AMD Standard command set, Manufacturer ID: 0x15, Device ID: 0x00

Erase timeout: 2048 ms, write timeout: 1 ms

Buffer write timeout: 1 ms, buffer size: 32 bytes
Аргументы ядра при загрузке:
Kernel command line: mem=48M console=ttyAMA0,115200 root=1f02 rootfstype=jffs2 mtdparts=physmap-flash.0:512K(boot),1536K(kernel),2M(rootfs),4M(app),8M@0(flash)1
Лог загрузки также давал представление о том, как данные расположены в памяти:
Creating 5 MTD partitions on "physmap-flash.0":

0x00000000-0x00080000 : "boot"

0x00080000-0x00200000 : "kernel"

0x00200000-0x00400000 : "rootfs"

0x00400000-0x00800000 : "app"

0x00000000-0x00800000 : "flash"
Далее нужно было только залить оригинальную прошивку rootfs во временную память и записать ее туда, где она должна быть.
Фактическое расположение разделов в памяти было по адресу 0x80000000, на выяснение чего ушло несколько часов просматривания листинга дампа памяти вручную через команду md (нет бы сразу обратить внимание на вывод Environment).
Установленная версия U-Boot была несколько урезана, поэтому многих команд просто не было в наличии (например работа с USB носителем), поэтому я остановился на варианте заливки через tftp.
Заливка производилась следующим образом:
xsjlinux # tftp 0xc0000000 rootfs_dn8004_v0401

Hisilicon ETH net controler

MAC: 00-11-00-34-76-21

UP_PORT : phy status change : LINK=UP : DUPLEX=FULL : SPEED=100M

TFTP from server 10.10.0.254; our IP address is 10.10.0.180

Download Filename 'rootfs_dn8004_v0401'.

Download to address: 0xc0000000

Downloading: %# [ Connected ]

################################ [ 1.000 MB]

#########

1.307 MB download ok.


done

Bytes transferred = 1363752 (14cf28 hex)
Далее очистка памяти перед заливкой:
erase 0x80200000 +0x14cf28
Далее заливка КФС на место:
cp.b 0xc0000000 0x80200000 0x14cf28
После всех действий система была перезапущена, но на этом все не кончилось. Теперь загрузка ядра и КФС проходило успешно, но не могла подмонтировать cramfs-раздел.
Я предположил, что прошивкой через софт я сместил размещение cramfs-раздела, по причине чего, теперь подгружаться он не хотел.
По аналогии с КФС был залит cramfs (начало его размещения соотв 0x80400000). Ошибок при записи не возникло, но теперь ситуация имела другой вид — загрузка ядра и КФС проходила, cramfs раздел монтировался, но далее выводил:
cramfs: bad compressed blocksize 4292875699

cramfs: bad compressed blocksize 4291992747
Софт DVR-а по прежнему не запускался.
Проверив файл прошивки с помощью fsck, стало ясно, что проблема, вероятно, в появившихся bad-блоках, а это не сулило ничего хорошего. В случае с NAND, была команда, которая делала «ремап», но тут ее не было. Единственное решение, которое пришло в голову, это урезать размер прошивки, и надеяться, что она не попадет на бэды.
Из прошивки был удален совершенно ненужный cab для ActiveX просмотра через IE, коим я никогда не пользовался, после чего ФС была вновь собрана на место и прошита.
Девайс вновь ожил, и на экране я увидел привычную картинку поделенного на 4 части экрана. А в терминале minicom я увидел не очень приятную картнку, в виде запроса логина. Это было печально, поскольку я рассчитывал на то, что терминальный выход не запаролен.
Сдаваться не хотелось, поэтому я вновь взялся за детальный осмотр прошивки, но теперь особое внимание уделил именно файлу с cramfs, и, как оказалось, не зря.
В недрах ФС был найден скрипт загрузки модулей ядра, вероятно, отвечающих за видеоввод. Поскольку модули может подгружать только root, решение было очевидным.
Измененный ранее файл shadow был положен корень ФС cramfs, а в скрипте была добавлена очень простая строчка:
mv ./shadow /etc/shadow
ФС была вновь запакована и прошита. Перезагрузка, логин, и мы наконец попадаем в систему.


В дальнейшем нужно будет понять, как можно организовать видео-вывод потоков в сеть, но основная часть работы все же пройдена.
Читать дальше...
Автор: Az на 02:24
Ярлыки: , , , , , , , , ,

7 комментариев:

  1. alemv24 мая 2013 г. в 11:03

    Восстановить можно с помощью файла restore.img
    Инструкция (правда на английском) следующая:

    The way of restore DVR is similar with the way of reinstall the system of computer.There are two USB ports in the back of DVR. When restore the DVR, you should use the above port to connect USB flash memory and not connect other USB devices with the DVR.

    Copy “restore.img” to the root of USB flash memory.(the name of restore file should be “restore.img”. if not, please rename them.
    Turn off the DVR, connect the USB flash memory, then turn on the DVR.
    Wait for a while(about 3-5 minutes)，turn off DVR till you hear buzz,then take off the USB flash memory.
    Restart DVR.

    Note: Please remove “restore.img” from the USB flash memory after successful restore, or it will restore the DVR again.

    ОтветитьУдалить
  2. Unknown19 сентября 2013 г. в 17:23

    Здравствуйте,

    Мой DVR CTR HD0824 (made in Corea):

    http://imageshack.us/a/img545/1322/cfuc.jpg
    http://imageshack.us/a/img545/1322/cfuc.jpg
    http://imageshack.us/a/img694/7341/4et9.jpg
    http://imageshack.us/a/img34/3149/38n.JPG
    http://imageshack.us/a/img30/5760/ct9.JPG

    Прошил его программой CMS по сети прошивкой:

    http://secutroncctv.com/secutron/?mid=support&category=265&document_srl=4569&listStyle=&cpage=

    После перезагрузки показывает это сообщение и дальше не грузиться:

    http://imageshack.us/a/img855/3347/k7to.jpg

    Подключиться к нему не могу ни по сети ни по USB.

    Посоветуйте пожалуйста, можно ли его восстановить или перепрошить
    через UART?
    Смущает файл прошивки без расширения. Из неё можно извлечь
    BIN файл?
    Где может быть UART на плате?

    Спасибо.

    ОтветитьУдалить
    Ответы
    1. Unknown9 ноября 2013 г. в 01:21

      Нашел производителя (TOPNOS CO LTD) на сайте :
      http://kr106265596.trustpass.alibaba.com/
      Перепрошили бесплатно.

      Всем спасибо!

      Удалить
  3. Unknown22 октября 2013 г. в 07:25

    Здравствуйте!
    С DVR на чипе HI3515 возникла проблема. После неудачной прошивки слетел даже UBoot. Он вроде как выводит строку приветствия но ни одна комманда не работает, говорит нет такой. Моё подозрение, что и UBoot затерся с флеш памяти. Есть ли способ его залить по UART? Т.е., проще говоря, можно ли вывести процессор в режим приема прошивки по UART при старте (как, например, микроконтроллер), чтобы он залил её на фоешку?

    ОтветитьУдалить
  4. Unknown4 ноября 2013 г. в 00:09

    Рутовый пароль на большинство DVR на Hi3515 - xc3511

    ОтветитьУдалить
  5. Unknown27 мая 2014 г. в 19:04

    Можно Вас попросить более подробно описать процесс прошивки?
    Должна ли быть подключена сеть во время процесса прошивки?
    Не нашёл в даташите к W29GL064CB7S выводов Rx и Tx. Куда же Вы подключали программатор?

    ОтветитьУдалить

Подписаться на: Комментарии к сообщению (Atom)