Представьте себе ситуацию, когда на камере наблюдения испортилась флэшка с прошивкой, и камера нуждается в ремонте. Берём копеечную флэшку и меняем, а прошивку скопируем с точно такой же камеры. Пять минут рекламы, и теперь камера работает и показывает видеопоток вновь. Но есть нюанс. Дело в том, что она теперь является полной копией камеры-донора прошивки. Это и ежу понятно, они же и были одинаковыми — возразите вы. Были одинаковыми всем, кроме таких настроек, как MAC-адрес и идентификатор в облаке, куда камера сливает свой видеопоток. А теперь они совсем близнецы.

Когда распространились камеры с облачным доступом, массово решились такие проблемы, как доступ к камере без внешнего IP-адреса или с динамическим адресом. Теперь стало ненужным использовать проброс портов на роутере, VPN, динамический DNS, требующие целой инфраструктуры для доступа к камере. Запускай себе приложение, и оно получит доступ к видеопотоку или к архиву через облако. Производители камер в то время пробовали различные варианты, которые часто заканчивались печальными результатами, как с камерами Foscam, связанные с тем, что производитель выбрал путь простоты и дешевизны, а пользователи за него проголосовали рублём. Камеры становились легкодоступными, дешёвыми и, в конце концов, собой просто заполонили весь мир, проникнув в магазины, детские сады, зоопарки, аэропорты, бары, подъезды, офисы, входы, выходы, проходы, пароходы и даже в спальни с туалетами. В крупнейшем каталоге камер insecam.org тогда были сотни тысяч камер со всего мира.

Так у производителей возникла проблема ограничения доступа к облаку. Камера должна была иметь крипто-ключ доступа. Такие производители, как Dahua и Hikvision, на многих своих камерах хранили этот ключ в отдельной микросхеме серии 24CXX. Но в массы пошёл вариант от вендора XiongMai (XM), платы которого использовались практически во всех китайских камерах, которые завалили нас в то время.

Все знают классический дизайн веб-интерфейса XiongMai, который назывался «китайские камеры» и никак иначе.

Веб-интерфейс камер и регистраторов XiongMai

На платах XiongMai преобладает вариант записи ключа прямо на микросхему с прошивкой, которая, как правило, хранится на флэшках SPI серии 25Q. С ростом популярности NAND-памяти для хранения прошивки устройства такой подход не изменился. Поскольку информация, которая отвечает за доступ к облаку и за такие индивидуальные реквизиты камеры, как MAC-адрес, зашифрована, то называют её криптоблок. В народе среди ремонтников прижилось название «крипта», которое в данном контексте не имеет к Биткойнам никакого отношения. Имейте это в виду, если увидите плачущего ремонтника, который безвозвратно потерял блок крипты.

▍ Как найти криптоблок в прошивке

Теперь покажу на практике, где «крипта» сохранена. Допустим, нам удалось слить прошивку с флэшки программатором или подключившись к консоли через USB UART-адаптер из меню U-Boot. Рабочая прошивка или нет, нас сейчас не интересует. Мы можем взять стандартную прошивку для конкретной камеры с сайта производителя, чтобы влить на новую рабочую флэшку, или перепрошить старую. Но к ней для нормальной работы нужен криптоблок, который сделает нашу камеру уникальной. Попробуем найти «крипту» в старой прошивке. Для начала заглянем внутрь и найдём регион, где записаны настройки загрузчика U-Boot.

0001D4A8 02 02 02 62 │ 6F 6F 74 61 │ 72 67 73 3D │ 6D 65 6D 3D │ 33 35 4D 20 │ 63 6F 6E 73  ...bootargs=mem=35M cons
0001D4C0 6F 6C 65 3D │ 74 74 79 41 │ 4D 41 30 2C │ 31 31 35 32 │ 30 30 20 72 │ 6F 6F 74 3D  ole=ttyAMA0,115200 root=
0001D4D8 2F 64 65 76 │ 2F 6D 74 64 │ 62 6C 6F 63 │ 6B 32 20 72 │ 6F 6F 74 66 │ 73 74 79 70  /dev/mtdblock2 rootfstyp
0001D4F0 65 3D 63 72 │ 61 6D 66 73 │ 20 6D 74 64 │ 70 61 72 74 │ 73 3D 78 6D │ 5F 73 66 63  e=cramfs mtdparts=xm_sfc
0001D508 3A 32 35 36 │ 4B 28 62 6F │ 6F 74 29 2C │ 31 35 33 36 │ 4B 28 6B 65 │ 72 6E 65 6C  :256K(boot),1536K(kernel
0001D520 29 2C 31 32 │ 38 30 4B 28 │ 72 6F 6D 66 │ 73 29 2C 34 │ 35 34 34 4B │ 28 75 73 65  ),1280K(romfs),4544K(use
0001D538 72 29 2C 32 │ 35 36 4B 28 │ 63 75 73 74 │ 6F 6D 29 2C │ 33 32 30 4B │ 28 6D 74 64  r),256K(custom),320K(mtd
0001D550 29 00 62 6F │ 6F 74 63 6D │ 64 3D 62 6F │ 6F 74 6D 20 │ 30 78 36 30 │ 30 34 30 30  ).bootcmd=bootm 0x600400
0001D568 30 30 00 62 │ 6F 6F 74 64 │ 65 6C 61 79 │ 3D 31 00 62 │ 61 75 64 72 │ 61 74 65 3D  00.bootdelay=1.baudrate=
0001D580 31 31 35 32 │ 30 30 00 65 │ 74 68 61 64 │ 64 72 3D 30 │ 30 3A 30 31 │ 3A 30 32 3A  115200.ethaddr=00:01:02:
0001D598 30 33 3A 30 │ 34 3A 30 30 │ 00 69 70 61 │ 64 64 72 3D │ 31 39 32 2E │ 31 36 38 2E  03:04:00.ipaddr=192.168.
0001D5B0 31 2E 31 00 │ 6E 65 74 6D │ 61 73 6B 3D │ 32 35 35 2E │ 32 35 35 2E │ 32 35 35 2E  1.1.netmask=255.255.255.
0001D5C8 30 00 63 72 │ 61 6D 66 73 │ 61 64 64 72 │ 3D 30 78 36 │ 30 30 34 30 │ 30 30 30 00  0.cramfsaddr=0x60040000.
0001D5E0 64 61 3D 74 │ 66 74 70 20 │ 30 78 38 31 │ 30 30 30 30 │ 30 30 20 75 │ 2D 62 6F 6F  da=tftp 0x81000000 u-boo
0001D5F8 74 2E 62 69 │ 6E 2E 69 6D │ 67 3B 73 66 │ 20 70 72 6F │ 62 65 20 30 │ 3B 66 6C 77  t.bin.img;sf probe 0;flw
0001D610 72 69 74 65 │ 00 64 75 3D │ 74 66 74 70 │ 20 30 78 38 │ 31 30 30 30 │ 30 30 30 20  rite.du=tftp 0x81000000
0001D628 75 73 65 72 │ 2D 78 2E 63 │ 72 61 6D 66 │ 73 2E 69 6D │ 67 3B 73 66 │ 20 70 72 6F  user-x.cramfs.img;sf pro
0001D640 62 65 20 30 │ 3B 66 6C 77 │ 72 69 74 65 │ 00 64 72 3D │ 74 66 74 70 │ 20 30 78 38  be 0;flwrite.dr=tftp 0x8
0001D658 31 30 30 30 │ 30 30 30 20 │ 72 6F 6D 66 │ 73 2D 78 2E │ 63 72 61 6D │ 66 73 2E 69  1000000 romfs-x.cramfs.i
0001D670 6D 67 3B 73 │ 66 20 70 72 │ 6F 62 65 20 │ 30 3B 66 6C │ 77 72 69 74 │ 65 00 64 77  mg;sf probe 0;flwrite.dw

Нас интересует строка, которая передаётся ядру и говорит о том, как разбита флэшка. MTD-разделы флэшки на встраиваемых системах — это аналог партиций жёсткого диска. Но вместо сохранения информации о разбиении в начале жёсткого диска в MBR, формат тут простой как три копейки — в переменной mtdparts ядру Linux в текстовом виде перечислены размеры каждого раздела и его метка в скобках:

mtdparts=xm_sfc:256K(boot),1536K(kernel),1280K(romfs),4544K(user),256K(custom),320K(mtd)

Отсюда мы видим, что первый же раздел boot занимает 256 килобайт. Именно в нём хранится «крипта». Но этот MTD-раздел тоже разбит на регионы с различным назначением. Последние 64кб. из них — env — регион с настройками, куда U-Boot пишет свои переменные по команде saveenv, их можно вывести командой printenv. Я говорю сейчас не о командах Linux, а именно о командах U-Boot, в командную строку которого можно попасть при некотором везении, если в консоли UART нажать Ctrl+C для прерывания загрузки Linux (об этом есть огромное количество информации). Первые 191кб — это код U-Boot, следующий за ними килобайт — искомый нами регион с зашифрованной индивидуальной информацией (сто девяносто второй килобайт). Если опустить всю вышесказанную лирику, то для этой камеры «крипта» находится по шестнадцатеричному адресу 0x2FC00 и занимает 1 килобайт (0x400 байт в HEX).

А знаете ли вы, что настройки камеры хранятся в последнем разделе с меткой 'mtd'. Если этот раздел затереть через команду U-Boot 'sf erase <offset>|<partition> <len>', то все настройки камеры, включая пользовательский пароль, будут сброшены к первоначальному виду, как у новой камеры. А если ошибиться с адресами, то можно остаться без прошивки.

Чтобы убедиться, что найденный блок — это именно криптоблок, нужно проверить первые два символа. Заголовок крипты в HEX всегда D2 D4.

Если смущает командная строка, то наверняка у вас найдётся HEX-редактор, который позволит по адресам выделить и скопировать нужные нам 1024 байта зашифрованной информации. Но мне удобнее и быстрее запустить команду, которая сохранит криптоблок в отдельный файл:

dd if=BLK530WX1-0235-V1.02-fulldump-XM25QH64A.bin of=cryptoblock.bin bs=1 skip=191k count=1024

В этой команде я указываю опции:

• if — input file;
• of — output file;
• bs — block size (считать в следующих опциях в единицах по одному байту, чтобы было понятней);
• skip — пропустить до чтения 191 * 1024 * blocksize;
• count — количество байт для записи в файл назначения 1024 * blocksize.

Если нужно в шестнадцатеричной системе исчисления, то с помощью калькулятора вы можете перевести десятичные цифры DEC в HEX и получить, что регион прошивки с «криптой» на платах XM, как правило, 0x2FC00 — 0x30000. Иногда на более старых камерах встречается диапазон 0x1FC00 — 0x20000.

В результате мы получим файл cryptoblock.bin размером 1024 байта. Это и есть сохранённая «крипта», которую нужно будет вставить в новую прошивку камеры на своё место, чтобы камера обрела свой старый заводской законный MAC-адрес и CloudID.

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

▍ Будет ли работать камера без криптоблока

У врача пациент спрашивает после сложной и тяжёлой операции:
— Доктор, скажите, я жить буду?
— Ну-у-у… Возможно. Но я бы не советовал, не советовал…

Без криптоблока камера работать будет, но без облака, с нюансами. MAC-адрес такой камеры становится 00:00:23:34:45:66. Работать камера с таким адресом будет ровно до того момента, пока в сети не появится ещё одна такая же камера. К той поре уже все забудут про то, что камера перешивалась, и через много дней ковыряния в глюках сети, когда всем коллективом поймут, кто виновен в этом, уже накопится достаточно злости, чтобы бить виновного коллективно и организованно.

▍ Что делать, если криптоблок утерян

Если лень восстанавливать криптоблок, и вам не нужен доступ к облаку, а достаточно стандартных протоколов камеры, то ставьте прошивку OpenIPC. В ней не используется криптоблок, а любой MAC-адрес можно задать следующей командой:

fw_setenv ethaddr  XX:XX:XX:XX:XX:XX

Рекомендуется использовать старый MAC, если он у вас сохранился, хотя бы чтобы производитель камеры корректно определялся при сканировании в nmap:


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

А знаете ли вы, что вендор определяется по первым трём байтам MAC-адреса? Вот по этому списку можно самостоятельно определить вендора.

Второй вариант — создать клон камеры товарища с такой же камерой с пониманием всех последствий как для вас, так и для всех пользователей камеры — донора прошивки.

Но есть ещё один вариант, который можно рассмотреть, если у вас прямо совсем много времени и умений: сгенерировать новый криптоблок.

▍ Генератор крипты

Пользователь github под ником nikitos1550 создал репу с генератором «крипты» для камер XM.

Никитос — красавчик, решил пойти простым путём, не исследуя дизассемблером и не взламывая криптоалгоритмы, чем занялся бы достаточно умный, но недостаточно хитрый хакер. Он взял библиотеки, такие как libcrypto.so из прошивки, в них нашёл нужные функции для кодирования и декодирования и написал программы, которые используют библиотеки производителя для шифрования или дешифрования криптоблока.

Запустить на своём домашнем линуксе генератор не получится. Так как библиотеки были выковыряны из оборудования XM на ARM-платформе, то запустить эти программы можно тоже только на аналогичном оборудовании в системе с полным комплектом библиотек. Для этого нужно прошить подготовленную скриптом часть прошивки на камеру или регистратор, загрузиться и в ней сгенерировать «крипту». После чего вернуть родную прошивку.

Я уже рассказывал про то, как можно использовать камеры со сгоревшим сенсором в качестве одноплатного компьютера. Так, из ненужной камеры можно подготовить отдельную железку для генерирования криптоблока и открыть на базаре ларёк, чтобы вытеснить конкуренцией даже бананы. Уверен, будет очередь. Шучу, конечно. Не бананы!

▍ Онлайн-сервисы генерирования криптоблока

Чтобы не заморачиваться с установкой прошивки для генерирования криптоблока, можно воспользоваться онлайн-сервисом cgistart.com.

Для этого вам нужно иметь файл с дампом прошивки камеры. Тут всё просто:

1. Вводим необходимый MAC и адрес криптоблока в прошивке в шестнадцатеричном виде без префикса «0x».
2. Выбираем файл прошивки и отправляем файл на сервер.
3. Скачиваем обратно переделанную прошивку и зашиваем её назад в камеру.

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

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

▍ Резюме

Теперь вы понимаете, насколько безопасны облака популярных камер. Конечно, это уже не так доступно, как в своё время «облако» Foscam, когда любая домохозяйка, помешивая борщ, могла запустить второй рукой сканер и полистать тысячи камер, установленных в спальнях, и в лучшем случае сравнить, как спят чужие дети. Подбор Cloud ID прямым перебором имеет мало смысла, так как количество комбинаций слишком огромно. Но подмена криптоблока позволяет не только увидеть Cloud ID, но и лить своё видео в это облако.

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

Скидки, итоги розыгрышей и новости о спутнике RUVDS — в нашем Telegram-канале ????