Расковырял linux-прошивку видео-регистратора ARSEC SAFARI SVR-016

Расковырял linux-прошивку видео-регистратора ARSEC SAFARI SVR-016.


Предисловие:

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

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

В процессе копания поняли что эти железяки нам вообще не подходят (процессор тянет только 4ре канала из 16ти в разрешении D1, остальные в CIF) и решили сменить всю платформу.
Но на всякий выкладываю инфу по данной железке - вдруг кому пригодиться!
:)

Железо ARSEC SAFARI SVR-016:

  1. SOC (System on Chip) - Hisilicon Hi3520
  2. Память - Samsung K4T1G1640F-BCE7 (три чипа)
  3. Флешка - SPANSION - S29GL256P10TFI010
  4. Видеокодеры - Techwell TW2668 MCLA2-GR (четыре чипа)
  5. SATA-контролер - SiliconImage SIL3114CTU (распаяно 2 SATA-порта из 4х)
  6. Деинтерлейсинг - iMARV mdin 241H

 

Прошивка ARSEC SAFARI SVR-016 (взята с сайта ARSEC SAFARI версия от 15.08.12):

  1. Загрузчик - uboot
    • Аргументы загрузки ядра linux:
      bootargs=mem=72M console=ttyAMA0,115200 root=1f05 rootfstype=jffs2 mtdparts=physmap-flash.0:768K(mboot+env+2logo),1536K(mkernel),128K(sboot),1M(skernel),3M(srootfs),7M(mrootfs),8M(app),512K(para) pcimod=host pciclksel=1
    • Параметры по-умолчанию:
      bootcmd=bootm 0x800c0000
      bootdelay=1
      baudrate=115200
      ethaddr=00:35:20:35:20:00
      ipaddr=192.168.2.52
      serverip=192.168.2.56
      netmask=255.255.255.0
      bootfile="uImage"
  2. Ядро - Linux-2.6.24-rt1-hi3520v100
    • initrd (слеплен с ядром) (cramfs) - в прошивке по адресу: 0x6858F4
  3. Образы разделов в прошивке:
    1. rootfs (jffs2) - в прошивке по адресу: 0x2B5F2C
    2. app (cramfs) - в прошивке по адресу: 0x8A7BF4

 

Как происходило расковыривание.

  1. Натравил на образ hex-редактор hexcurses в поисках чего-нибудь внятного и знакомого.
    Нашлась информация о том, что rootfs в формате jffs2, что есть разделы в cramfs.
    Тоже самое можно проделать с помощю програмки strings.
  2. Т.к. заголовков файла ни у cramfs, ни у jffs2 я на память не помню, то создал парочку файлов с такими ФС (файловых систем)
    mkfs.cramfs и mkfs.jffs2.
  3. Выяснив, у созданных файлов, какие заголовки у cramfs (0x45 3D CD 28 00) и у jffs2 (0x85 19 03 20 0C 00), нашел где начинаются данные ФС.
    Примечание: у jffs2 может быть второй заголовок (0x85 19 01 E0 2C 00) - зависит от ключиков, с которыми создавалась ФС.
    Адреса найденных ФС см. выше.
  4. Примонтировал cramfs:
    mount -o loop,offset=9074932 RM8516-00000000-12-00-0000-120411-02 /mnt/
    ,здесь 9074932 - это адрес 0x8A78F4 переведенный в 10ричную форму. Аналогично со вторым образом в cramfs.
  5. Примонтировал jffs:
    modprobe mtdram total_size=131072 erase_size=128 modprobe mtdblock dd if=RM8516-00000000-12-00-0000-120411-02 of=/dev/mtdblock0 bs=1 skip=2842412 mount -t jffs2 /dev/mtdblock0 /mnt

После монтирования каждой ФС, я рассовал все данные из этих ФС в нужные мне папочки.
Там можно увидеть что и откуда запускается, что и куда монтируется и тд и тп.
Все как обычно.

Послесловие:

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

Теги: