Что такое вставьте реверс камеры

Тема: Камера и как перевернуть изображение.

Обратные ссылки

Опции темы

Камера и как перевернуть изображение.

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

П.С если повернуть камеру,лево-право нормализуется,но верх-низ,становится наоборот

А куда установил-то: на передний, или задний обзор?

Видимо монитор неправильно установлен,а не камера! Версия для установки внутри а\м на крышу? Читайте мануал,там должно быть указано,как перевернуть изображение.

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

сылку с ИБей не могу выложить стоп-спам зашита

на ибейе в поиске забейте

SONY CCD 360° Car Vehicle Front / Side / Rear View Reverse Camera Universal Fit

это она

Добавлено через 1 минуту

оо электрик устанавливающий камеру сказал,что перемычки как раз нету

можно поподробнее про 3д блок) что это,и что будет если удалить

Даже вот такая простецкая камера имеет в описании функцию Image Reverse: Left-right mirror

аааа вот нашел, китайцы просили при заказе указывать опцию, для установки назад нужно было просить у них:
B, Reverse image with guide line, used as rear view camera. (опция Б, зеркалирование изображения с линиями для парковки, для использования как камеры заднего вида). Так что придется Вам подождать 2 месяца или купить где-то в России у перекупщиков

Источник

Pioneer AVH-4600DVD настройка камеры «Надпись про зеркальное изображение»

Опции темы

Поиск по теме

Отображение

Pioneer AVH-4600DVD настройка камеры «Надпись про зеркальное изображение»

Добрый день. Ребята подскажите пожалуйста. Уже голову сломал не могу понять в чем проблема.
Значит у меня магнитола P AVH-4600DVD. Реши поставить камеру заднего вида. Установил, протянул провода. Подключил. Все заработало. Картинку вижу с камеры.
НО у меня такой вопрос. не могу избавиться от надписи и черного экрана «ВНИМАНИЕ ИЗОБРАЖЕНИЕ МОЖЕТ БЫТЬ ЗЕРКАЛЬНЫМ». Это когда камера не работает такая светиться надпись!
Его только можно выключить если в системе отключить «Камера заднего вида ВЫКЛ» Тогда этого малевича не вижу.

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

Еще один момент. Все пишут что подключают проводок «+» который идет вместе с желтым тюльпаном на проводок маннитолы «Reverse» а с другого конца тюльпана красный проводок на + фонаря.

Я Этого из начально не сделал так как видео сразу же увидел на магнитоле. Все конечно уже запаковал )

Заранее всем большое спасибо за помощь.

Если Вы впервые на нашем Форуме:

Re: Pioneer AVH-4600DVD настройка камеры «Надпись про зеркальное изображение»

Там есть функция темного экрана. Читайте мануал, ищите. Кнопка есть

Re: Pioneer AVH-4600DVD настройка камеры «Надпись про зеркальное изображение»

Спасибо большое. Завтра отпишусь. ТАк как уже поздно. Не охота идти проверять.

Там есть функция темного экрана. Читайте мануал, ищите. Кнопка есть

Резет делал несколько раз.
подключал / отключал «+» на провод РЕВЕРС

Изменений ни каких.

Re: Pioneer AVH-4600DVD настройка камеры «Надпись про зеркальное изображение»

Re: Pioneer AVH-4600DVD настройка камеры «Надпись про зеркальное изображение»

Re: Pioneer AVH-4600DVD настройка камеры «Надпись про зеркальное изображение»

на камере никаких проводочков больше не обнаружил. Если только разобрав может там что то есть. Так вот подключал я по разном.
Значит на кнопку РЕВЕРС на магнетолу подавал как «+» так и «-» от фонаря менял полярность по разном в настройках магнитолы.
У меня это черный экран вообще не зависимо камера подключены. или на провод РЕВЕРС что то подано.
как только в настройках включаю полярность. (неважно какая) и саму «камеру заднего вида» сразу высвечивается эта Надпись и Черный экран. прикасаешься она исчезает на секундр 20-30 и опять. При этом музыка играет и все работает.
Не знаю что делать. разочаровался в магнитоле. ) буде ездить наверное без нее.

Re: Pioneer AVH-4600DVD настройка камеры «Надпись про зеркальное изображение»

И еще, вопрос был про «убрать надпись» или то, что камера не показывает?

Re: Pioneer AVH-4600DVD настройка камеры «Надпись про зеркальное изображение»

И еще, вопрос был про «убрать надпись» или то, что камера не показывает?

Хорошо сейчас проверю.
потому как я да включал полярность и включал где иконки ВКЛ камеру.
спасибо

Re: Pioneer AVH-4600DVD настройка камеры «Надпись про зеркальное изображение»

И еще, вопрос был про «убрать надпись» или то, что камера не показывает?

Все ребята заработало. Все отлично!

Вы все сказали правильно!
У себя нашел проблему в том что из начально провода проложил. а потом подключал. Соответственно не хватило дотянуться пришлось нарастить немножко. И вот там отвалился «+» который идет на РЕВЕРС. Сразу даже не подумал потому как замотал и уложил в гофру.

Так что всем большое спасибо. доволен как слон
Все удачи на дорогах!

Источник

Еще одна стажировка, или сказ про реверс IP-камеры

Вступление

Итак, меня взяли на стажировку. Стажировка рассчитана на 2–3 месяца неспешной работы по 20 часов в неделю.

Что обещали научить делать (забегая вперед – обещание выполнили):

анализ открытых источников;

анализ аппаратных интерфейсов устройства;

схемотехнический анализ устройства;

работу с программаторами;

анализ технологических интерфейсов микроконтроллеров;

анализ программного обеспечения (как статический, так и динамический);

поиск недекларированных возможностей;

разработку консольного приложения.

С отдельными пунктами я уже был знаком: кое-что было на занятиях в вузе, что-то попадалось на CTF, про другие я только слышал (например, пайка и прочие «железячные» штуки).

Теперь о задании. Объектом исследования была типичная IP-камера, которая умеет записывать видео на MicroSD и стримить через Интернет на мобильное приложение (настраивается тоже через приложение). Еще камера может обнаруживать движение в кадре и отправлять владельцу фотографию происходящего. Целью исследования было проведение анализа защищенности модифицированной камеры и разработка PoC, позволяющего отключить функционал обнаружения движения в кадре, находясь в одной локальной сети с устройством.

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

Этап 1

Этот этап скорее обзорный, нужно было:

узнать возможности камеры;

найти внешние аппаратные интерфейсы камеры и определить протоколы, которые используются камерой на данных интерфейсах;

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

Интерфейсы у камеры следующие:

слот для MicroSD. Карточка должна быть отформатирована в FAT32, иначе это с ней сделают принудительно при первой попытке использования. Записывается видео в своеобразном формате, подробнее чуть ниже под спойлером;

MicroUSB-порт. Изначально возникли сомнения в том, что он способен передавать данные, в дальнейшем они подтвердились: от разъема к плате идут два провода – только питание.

Для передачи как видео на сервер, так и управляющих команд на камеру используется UDP. Wireshark не распарсил протоколы, скорее всего что-то самописное и/или шифрованное.

При запуске камера шлет информацию о себе широковещательно (сначала четыре пакета подряд, потом еще шесть с интервалом 5 секунд) на 6666-й UDP-порт. Структура пакета:

CRC32 от всех пунктов, приведенных выше;

Бесполезный бонус: как сохраняется видео на microSD

После записи видео на флешке появляются такие файлы:

session.log – в начале короткий заголовок из ASCII-символов, потом много нулей (ровно 16 Мбайт).

С photo.bin то же самое, только еще есть несколько неведомых байтов. Эти файлы фактически пустые, и у них нет времени создания и изменения. По ходу работы камеры они не меняются.

размер точно по 8 Мбайт (01 – предыдущая версия файла 00, при каждом запуске старый 01 заменяется);

первые 112(=16*7) байт заголовок, дальше блоки данных, описывающие avs-файлы:

байт 0B на скрине – скорее всего что-то вроде указателя на следующий файл для записи;

размер блока 452 байта. Судя по размеру, всего возможно 18 558 видеофайлов до конца этого индекса. Блоки данных состоят из 32 байт, разделяемых промежутками по 420 нулей:

− желтое – порядковый номер блока и часть имени avs-файла;
− фиолетовое – было одинаковым в нескольких блоках;
− красное и синее – unixtime начала и конца записи;
− зеленое – размер файла.

Все числа в little endian.

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

20 минут, скорее всего отсечка по размеру (по времени слишком «некрасивые» числа выходят).

При сканировании были найдены открытые TCP-порты:

21 (BusyBox ftpd, якобы D-Link DCS-932L IP-Cam camera);

23 (BusyBox telnetd);

NetBIOS имя камеры – dgiot, что является отсылкой к китайскому производителю облачных сервисов для IoT-устройств (сайт, гитхаб). При попытке подключиться по telnet становится известным имя хоста – anyka, что является названием SoC для IP-камер, на базе которого, как потом выяснилось, устройство и сделано.

На загадочном турецком сайте была найдена прошивка – образ SquashFS (это внушало надежду, что в дальнейшем можно будет увидеть не просто прошивку, но какую-то Unix-систему). Анализировать не стал, т.к. в дальнейшем предполагалось извлечь прошивку из самого устройства.

Этап 2

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

На фотографиях ниже цифрами обозначены элементы, которые мне показались потенциально полезными.

Реально полезными оказались два:

А1 – ANYKA / AK3918EN080 / V200 / CASJ09K17 (SoC для IP-камер);

Б4 – WINBOND / 25Q64JVSIQ / 1920 (флеш-память 8 Mбайт).

Зеленым обведен потенциальный отладочный интерфейс (характерные подписи контактов, см. спойлер «Сторона А»).

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

К слову, найти документацию на конкретно этот SoC так и не удалось, но это не сильно помешало.

На этом этапе я задавал кучу вопросов из разряда «а что это за точки?», на которые руководитель стажировки терпеливо отвечал.

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

Тут я предположил, что прошивка находится во флеш-памяти.

Этап 3

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

Этот этап выполнялся в лаборатории. С использованием программатора ChipProg-48 были успешно считаны все 8192 Кбайт памяти. Тут же я впервые взял в руки паяльник и попытался подпаяться к контактам UART. Что-то даже получилось.

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

Кстати, для новичков с дрожащими руками: закон Мерфи работает. Капля припоя, сорвавшаяся с жала, не могла найти другого места для падения, кроме как сразу на три ножки драйвера мотора, напрочь лишив камеру возможности поворачиваться по одной из осей. Так что будьте внимательнее с тем, где держите паяльник.

При подключении к UART возникает вопрос выбора скорости передачи данных (baudrate). Говорят, ее можно определить с помощью логического анализатора, но быстрее оказалось найти нужное значение методом перебора – 115200.

Об автоматизации перебора

Появлялась мысль автоматизировать процесс программного подбора скорости: простенький скрипт, который пытается получить и вывести в консоль пару сотен символов с serial-порта для всех возможных значений скорости, чтобы потом глазами найти адекватные строки. Для этого устройства идея, в принципе, рабочая, но с другими могут быть проблемы: нет никаких гарантий, что с serial будут прочитаны именно ASCII-строки и что глазами можно будет отличить их от мусора.

Подключившись по UART к уже включенной камере, получили в терминал кучу строк, похожих на логи приложения. Если сначала подключиться к интерфейсу, а потом уже включать устройство, то можно увидеть интересную строку: Hit any key to stop autoboot: и таймер на 3 секунды. Нажатие любой клавиши действительно прерывает автозагрузку, и в результате был получен доступ к оболочке U-Boot.

Как подсказали help и гугл, в оболочке U-Boot есть команда md – memory display, выводящая содержимое ОЗУ. Ее аргументами являются адрес и количество объектов (по умолчанию объект – это dword). Я попробовал найти место, чтобы туда загрузить 8 Мбайт из флеш-памяти, но получал постоянно один и тот же набор байтов при попытках прочитать что-либо:

Это меня отпугнуло, и я не стал дальше копать в данном направлении.

Наличие U-Boot и его переменные среды окончательно подтвердили теорию, что в устройстве есть ОС Linux (характерные параметры загрузки ядра – четвертая строка в выводе ниже).

Вывод env print (еще одна команда U-Boot)

Путем модификации параметров загрузки ОС Linux возможно изменить стандартный порядок загрузки (запуск /sbin/init на запуск /bin/sh), что дает шелл в запущенной Linux-системе (основной функционал камеры в этот момент еще не начал работать). Последовательность команд в оболочке U-Boot, позволяющая сделать это:

В результате ОС запустилась и дала возможность выполнять любые Linux-команды. Путем чтения устройства /dev/mtd0 можно считать содержимое флеш-памяти. Самый простой способ – записать с помощью dd содержимое флеш-памяти на microSD-карточку – почему-то в голову не пришел. Я пытался выводить содержимое ПЗУ в консоль и потом вырезать его из логов PuTTY, который использовал для подключения к serial-порту. Но в этом клиенте есть такая настройка, как Answerback to ^E, содержащая строку, которая будет автоматически отправляться серверу в случае получения от него ^E (что может произойти при выводе бинарного файла в консоль). И ладно бы проблема была только в этом – можно просто задать пустой answerback – еще PuTTY заменяет \n на \r\n, а \r\n оставляет без изменений. В итоге нереально понять, что нужно заменять обратно, а что нет. (Ну или по еще каким-то неведомым причинам размер дампа увеличивался на несколько байт.)

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

Этап 4

На этом этапе нужно было:

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

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

Среди логов, выводящихся во время загрузки ОС, попался такой фрагмент:

Собственно, на прошлом этапе можно было извлекать дамп целиком из /dev/mtd0, а можно уже разбитым на разделы из /dev/mtd6. Оставалось только разобраться, что это за разделы с говорящими и не очень названиями (binwalk с этим отлично справился):

KERNEL – заголовок U-Boot и zImage ядро Linux.

MAC – помимо MAC-адреса в ASCII со странным значением (FF:FF:FF:00:00:00), тут были только 00 и FF в большом количестве.

ENV – переменные окружения для U-Boot.

A – образ SquashFS с более-менее стандартным линуксовым набором директорий и файлов.

B – образ SquashFS, содержащий творчество разработчиков устройства: приложения, библиотеки, модули ядра.

C – образ JFFS2, содержащий в основном конфиги: сетевые настройки (в т.ч. данные для подключения к Wi-Fi-сети), файл passwd.

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

Порядок запуска внутри ОС описан в файле /etc/init.d/rc.local:

Основная жизнедеятельность камеры реализована в приложении dgiot, дальше предстоит работать именно с ним. Это обычный ELF-файл для ARM, никаких проблем с его загрузкой в IDA Pro, как у предыдущего стажера, не возникло.

Этап 5

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

Пробежавшись глазами по строкам из ELF-файла, нашел используемые компиляторы:

GCC: (GNU) 3.3.2 20031005 (Debian prerelease);

GCC: (anyka (gcc-4.8.5 + binutils-2.24 + ulcibc-0.9.33.2)(20170223)) 4.8.5;

GCC: (Hisilicon_v100(gcc4.4-290+uclibc_0.9.32.1+eabi+linuxpthread)) 4.4.1.

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

Anyka SDK (вот тут накладка. Логично, что такое должно быть, но найти в Интернете ничего подобного не удалось).

Чтобы сопоставить найденные библиотеки и имеющееся приложение, мне посоветовали плагин Diaphora для IDA Pro. Из его функционала мне приглянулась возможность найти одинаковые функции в SDK (собранном с отладочными символами) и приложении, после чего автоматически перенести имена функций.

Мне не удалось точно угадать версию TUTK SDK, поэтому здесь Diaphora был очень кстати: ему не нужно полное совпадение функций, он по ряду собственных метрик показывает, насколько функции похожи. А для TUYA IPC SDK удобнее оказалось использовать FLAIR из состава IDA Pro. В этой статье подробно описано, как такое сделать.

Я нашел две разные функции такого вида, но идея одна и та же: n-й аргумент этой функции будет именем внешней функции (той, где вызывается вывод в лог). Переименовав вручную по этому принципу несколько десятков функций, я понял, что надо это как-то автоматизировать – наконец-то настало время попробовать IDAPython. Но мне не первому в голову пришла такая идея, даже есть статья, в разделе 0x04 которой подобный скрипт описан.

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

1. Поток обнаружения движения (md_judge_thread @0x123890):

2. Поток обработки данных, получаемых по сети (lpc_task_cb@0x1E9B4C). Здесь, если пакет валидный, данные передаются в lan_protocol_process@0x2290E8:

Этап 6

На заключительном этапе нужно было выяснить:

какие порты слушает устройство;

каким образом обрабатывает поступающие данные;

какие команды выполняет.

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

В приложении вызывается функция listen для сокетов на следующих портах:

6668 – свой протокол (в коде его называют lpc).

Были надежды, что последние две буквы в названии второго протокола означали procedure call, так что он выглядел более многообещающим, и изучать в первую очередь я стал именно его.

Данные, поступающие на порт 6668, обрабатываются в ранее упомянутой функции lan_protocol_process@0x2290E8. Структура пакета:

Интересно, что контрольная сумма поступающих в приложение пакетов вычисляется, но нигде не проверяется. Хотя в пакетах, получаемых от камеры в ответ, контрольная сумма присутствует и посчитана нормально.

На этом месте я завис, пытаясь разобраться, казалось бы, с небольшим набором команд. Полезной оказалась одна команда – 8 (должна быть в пакете по смещению 0x08) – позволяет записать произвольные 4 байта («v») по произвольному адресу («a»):

А теперь вернемся к функции md_judge_thread @0x123890 (листинг был на скрине на этапе 5). При обнаружении движения в логи пишется строка «…>>>movtion detect!!» (sic!), даже если реально уведомления никуда не отправляются (т.е. выключены пользователем). Цикл, в котором это происходит, выполняется, пока переменная по адресу 0x004975F8 равна нулю, т.е. для остановки цикла и выхода из потока необходимо записать любое отличное от нуля значение по этому адресу. А как записывать что-то в память уже известно.

Для остановки потока обнаружения движения был написан скрипт на python, отправляющий правильный пакет:

После отправки этого набора байтов на порт 6668 камера переставала отправлять владельцу уведомления о появлении движения в кадре.

Отыскать в локальной сети камеру можно с помощью nmap. Необходимо найти устройства с открытым требуемым портом и именем dgiot.

Заключение

На этом стажировку можно было считать оконченной.

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

Подключиться к локальной сети, в которой находится камера.

С помощью nmap просканировать сеть на наличие камеры, получив ее IP-адрес.

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

Для автоматизации этих действий я использовал скрипты на bash и python.

Помимо описанного во вступлении, также я выполнил ряд пунктов из своего собственного чек-листа «когда-нибудь попробовать»:

исследование многопоточного приложения;

поковырять какой-то самописный протокол;

использовать Kaitai Struct;

попробовать написать скрипт на IDAPython.

Еще я убедился, что хочу в дальнейшем связать свою профессиональную деятельность именно с этим направлением ИБ.

Что показалось наиболее сложным:

работа с паяльником (с ним я все еще на «вы»);

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

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

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

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

Raccoon Security – специальная команда экспертов НТЦ «Вулкан» в области практической информационной безопасности, криптографии, схемотехники, обратной разработки и создания низкоуровневого программного обеспечения.

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

Оставить заявку на прохождение стажировки можно тут.

Источник