Ez hardware hacking: IPCam china

Antes de empezar, decir que de hardware hacking sé lo justo, ojalá saber más. Bueno ojalá tampoco, poco a poco, que es algo que si quiero aprender más. Lo poco que sé es por tener conocimientos de electrónica digital y un poquitín de base teórica de sistemas operativos.

Me han dejado una cámara IP vieja, de estas de los chinos, bueno no sé si dejado o dado, igualmente puede ser expropiada en nombre del sindigato. La cosa es que en la caja trae un enlace a una aplicación propietaria, en formato QR, y ese enlace no funcionaba:

Entonces, surgió la duda: ¿hay algo que se pueda hacer para volver a usarla? ¿realmente funciona?

1. Respuesta rápida (y aburrida)

No os voy a mentir, es lo primero que debería haber hecho y es lo último que hice porque soy un poco impulsivo y un poco tonto. Podría decir que es porque quería entrar en las tripas, que también, pero es que me cegué con eso y fui directamente al meollo jaja

El problema básicamente es que debería apuntar a lo que parece una nueva url: eye4.app

La cosa es que si buscas 4 segundos en Google llegas a la aplicación que te sirve:

La he probado y efectivamente sirve, te hace escanear un QR en la base y directamente se víncula a la aplicación:

El QR realmente contiene la misma info que el UID escrito.

¿Recordáis el router del post de openwrt? Luego iremos a lo de por qué mierdas aparece en la foto. Está por una cosa :p

Ah sí, el cable ese a modo de coleta cámara chepuda también está por cosas.

2. Echando un ojo al hardware

Todo lo que voy a describir en este bloque se basa básicamente en ojear y buscar la info por internet, luego en otras secciones empezarán las pruebas, pero es importante primero ver de qué se compone el sistema.

Bueno, cómo he dicho, antes de empezar por lo más lógico lo que hice fue desmontar el cacharro. Me gusta demasiado destripar cosas.

Ahora que he desmontado la cámara entera puedo decir que el sistema lo componen dos PCBs. En la base tiene una pcb sencilla, que voy a enseñar por los dos lados. He puesto numeritos para explicar cosas.

Primero la parte de abajo de la placa, la que vemos nada más desmontar la tapa de abajo:

Y por el otro lado tenemos esto:

Habéis visto que dominio del dibujo, apreciad que lo he hecho con la derecha. Explico cada punto:

1. Esto aunque no lo parezca de primeras es una tarjeta wifi que realmente funciona por USB. Que a ver, no he probado a desoldarla y pincharla a un pc, pero veréis luego por qué lo digo.
2. Este cable flex sube para arriba a la segunda placa, que realmente sería la primera porque es básicamente la principal. Pero bueno, lleva la alimentación y la comunicación con la placa de abajo (ethernet, wifi, motor, etc..).
3. Este conector lleva cables al servomotor de la base, un servo de 5 hilos.
4. Esto lo marco porque me pareció curioso, un conector de altavoz sin conectar, pero lo más curioso es que, en la placa de arriba si hay un altavoz conectado.
5. El circuito de alimentación para todo el sistema.
6. Este es un microcontrolador que me da mucha rabia, porque no hay manera de encontrar el datasheet en google. De hecho la placa de arriba tiene otro exactamente igual, y parece evidente que su función es controlar el servomotor. Lo que no sé es el protocolo que usará para comunicarse con la CPU/SoC principal, sería cuestión de pincharle un analizador lógico o algo así…
7. El circuito para el conector ethernet.

Ahora pasamos a la PCB de arriba. Las fotos van a ser lamentables pero bueno, creo que se puede ver más o menos, ahora no me apetece desmontar la cámara de nuevo.

La parte frontal (esta pcb se coloca en vertical):

La parte trasera:

Creo que no hace falta decir y señalar cuál es el módulo de cámara. Veamos:

1. La parte más importante de todo, el SoC que contiene la CPU. He encontrado el pdf, y de hecho, lo subo aquí por si desaparece en un futuro. Luego entramos en esto.
2. Es un conector que se autodescribe en la PCB, va conectado al/los led/s de la cámara. Tiene un led rojo y también leds infrarrojos (IR), lo típico para tener visión nocturna barata. No sé si va también a eso, porque en la pcb hay otro conector que pone “IR-CUT” y va al módulo de cam, igual desde esta se encienden o apagan, no sé.
3. El botón de reset típico que tienes que meter un palillo. Reinicia el cacharro, no sé si borra cosas, supongo que sí, porque guarda las cosas como el culo. Eso luego lo veremos.
4. Slot para tarjetas microSD, sirve para guardar grabaciones y fotos. De hecho se pueden programar horarios para ello, eso mola.
5. En la foto no se ve pero, pone que es otro conector para el motor, en este caso maneja el motor del eje Y. El que mueve de arriba a abajo vaya.
6. Otra vez el maldito microcontrolador del que no hay datasheet abierto, justo al lado del conector de motor también, como en la otra placa. Por lo que se confirma que este se usa para controlar el motor.
7. Conector de altavoz, este si que tenía un altavoz conectado jaja
8. El conector que hay al otro extremo del cable flex, este conecta las dos placas.
9. Otra pieza importante, una eeprom SPI, que contiene el firmware de la cámara. También encontré el datasheet y lo voy a guardar aquí.
10. No se ve un cagao pero son unos pads soldables en los que pone en orden: GND, TX, RX, 3v. De hecho en la foto del frontal son los 4 agujeritos que están al lado del SoC. Vamos, que es un puerto UART y han sido tan majos hasta de marcar en la pcb qué cable conectar a cada pad. Esto va a ser lo más importante de este post.
11. Otros dos pads que pone TX1 y RX1, estos no los he probado, intuyo que es otro puerto UART para otra cosa. Ya investigaré si es necesario.

En el pdf encontramos esto, no sé si es 100% aplicable al SoC concreto, un diagrama de bloques lógicos del SoC viene en el pdf:

ℹ️ Para quién no sepa que es SoC (system on chip): se dice así porque es un encapsulado que no contiene solo la CPU, sino que contiene otros subsistemas que técnicamente son periféricos de la CPU. Es hacer un sistema entero para un propósito específico. En este caso,como es un chip que se va a usar para montar cámaras IP, viene todo encasquetado y se reduce la complejidad a la hora de diseñar la placa. Por ejemplo: podemos ver, entre otros, como contiene un subsistema para el procesado de video y otro de imagen.

También viene un diagrama de bloques lógicos de cómo se suele implementar una cámara IP completa con este SoC:

De este bloque se pude suponer que aquello era una tarjeta wifi usb. Además, tiene sentido, la tarjeta tiene 4 pines, y en los extremos ponía vcc y gnd. Luego en las pruebas creo que se puede verificar del todo, iremos a ello si no me olvido jaja

3. La experimentación

3.1. Pinchando el UART y obteniendo info

Aquí he de reconocer que tuve que tirar un poco de ayuda de ChatGPT para ayudarme a según qué cosas, ya que que buscar cosas tan concretas en Google es más complicado. Me ayudó especialmente para usar el menú de U-Boot y volcar el firmware, pero bueno, eso ahora lo explicaré.

Vais a ver capturas con fechas y horas random porque no lo he hecho del tirón, y puede que algunas cosas las haya tenido que repetir a posteriori para este post, no me lo tengáis en cuenta :P.

Lo primero que hice como se ve en la primera foto fue lobotomizarlo soldar unos cables a los pads de UART para poder conectarme y ver si tenía suerte. Y así fue, lanzas el picocom y te empieza a escupir toda la info como si le estuvieses sometiendo al tercer grado. Voy a diseccionar lo que vea interesante en capturas.

Primero, el arranque de U-Boot:

De momento ya nos dice el chip de EEPROM usado y el tamaño que tiene, que ya sabíamos, pero nunca está de más una doble verificación. Ahora el arranque de linux:

Se puede ver entre otros datos:

• la versión del kernel de linux, que es bastante vieja
• la cpu y el nombre del chip/SoC, que ya sabíamos
• la cantidad de memoria RAM disponible

Y un trozo más abajo viene una de las cosas más importantes:

Eso nos muestra la información de cómo están guardadas las particiones dentro de la eeprom. Y con ayuda de ChatGPT he entendido para qué servían, que no tengo experiencia en esto en concreto, especialmente para saber la diferencia entre las dos últimas particiones. Entonces, el mapa de memoria de la eeprom se resume en:

Seguímos bajando en el log y vemos como inicia ya el sistema con sus demonios (y quién soy yo para juzgar, quién no tiene los suyos internos):

Ahí, a parte del ascii art cutre que se agradece, vemos unas credenciales, hago spoiler: son las de la web, pero esto aún no lo sabemos. Además, coincidía con la contraseña escrita en la base de la cámara antes de cambiarlaa (contraseña a la que, en un ataque de originalidad y porque me obligó la app al instalarla, le añadí más 8s).

Y nos topamos más abajo con la información del puerto e IP, que se usa para la web, en caso de estar conectada a alguna red:

Aquí he hecho trampa porque está conectada a través de ethernet, con el router mencionado arriba. Los motivos tienen que ver con el siguiente apartado. Pero respecto a la captura, creo que se lee bastante bien lo que significa.

ℹ️ Dato curioso y que me enfada: no sé por qué, si configuro el puerto web a otro, no se guarda correctamente. Cada vez que reinicias la cámara se cambia el puerto por uno al azar, y es bastante molesto.

De todos modos, ¡no me olvido de la tarjeta wifi eh!, aquí sale la info del chip:

Luego un poco más abajo info sobre drivers: de imagen, de i2c, de motores, etc…

Sale el modelo exacto de módulo de cámara al cargar el driver:

Petición NTP ya que la placa no tiene pila para guardar la hora:

Y luego, entre otras cosas sin importancia, ya empieza a authenticarse contra el servidor chino para establecer el stream, ese que luego puedes ver desde la app:

Usa un protocolo raro p2p para el stream, no sé mucho de eso. Fíjaos en la línea de la petición GET tan rara, eso lo hace para obtener la IP del dominio sin fiarse del DNS que tengamos. De hecho más abajo en el log muestra la respuesta:

Si alguna vez necesitáis resolver IPs por http (no sé en qué escenario podría pasar) esta gente tan maja os lo resuelve, y además correctamente 🤠:

Y aquí manda info de la cámara al servidor en cuestión:

Y abajo manda más datos pero weno, por último voy a poner este log:

Ni sabía que existía este protocolo llamado onvif. He buscado en internet pero no he profundizado en ello. Supongo que con algún programa pueda conectarme, ya probaré.

Y con esto acaba todo lo que se saca por UART de momento, porque al pulsar intro si que deja meter credenciales. Pero no son las mismas del wifi.

3.2. La interfaz web

A la interfaz web se puede acceder con la IP y el puerto descubierto por UART. Es una interfaz bastante sencilla, para logearte pide credenciales en un formulario propio del navegador, de estos que usan algunos routers cutres, o el típico de htaccess de apache…

Al acceder da una lista de opciones, entras a la de tu navegador y te lleva al stream:

Luego hay opciones de configuración:

¡Y justo ahí es dónde no me hace ni caso al cambiar el puerto!

3.3. Volcado del firmware

Una de las cosas más interesantes suele ser poder extraer todo lo que guarde la memoria eeprom, porque como hemos visto en la consola uart, ahí se guarda la partición de arranque, el kernel de linux compilado y el sistema de ficheros que se monta al ejecutar.

Para ello podría volcar el chip usando la pinza del post de reciclado de componentes. Exacto, hoy tenemos especial recopilatorio de los simpson con referencias a posts del pasado. Bueno a lo que íbamos, podría usar la pinza, pero si me habéis leído por twitter o ese post, sabréis que odio esa pinza con todo mi ser por los disgustos que da y lo mal que agarra.

Además, me sonaba que u-boot a veces permite extraer un dump de la eeprom por uart. Nunca he extraído la eeprom así, una vez intenté lo contrario y brickee un cacharro. Pero bueno, ahora solo voy a leer, no tiene que pasar nada, además la cámara no es mía (que no lo lea la dueña).

Si os habéis fijado en la primera captura de UART, aparecía una frase que decía “pulsar cualquier tecla para parar el autoarranque”. Si pulsas, por ejemplo intro, puedes acceder al menú de uboot:

Y si pedimos las opciones disponibles nos da este listado:

Supongo que la versión de u-boot también debe ser vieja, porque según he visto, en versiones más modernas hay más opciones y más complejas.

Aquí, con algo de ayuda del chattie, vemos que la única opción que parece viable es usar el comando para subir ficheros a un servidor tftp. Para ello hay que settear variables de IP, de modo que pueda conectarse. También, aunque no es necesario, una variable para determinar la dirección de memoria RAM dónde volcaremos la SPI y desde dónde leeremos para subir al tftp. Digo que no es necesario porque puedes escribirla cada vez a mano.

Para declarar las variables hacemos esto:

setenv ipaddr 192.168.1.50       # IP de la cámara
setenv serverip 192.168.1.100    # IP de tu PC con TFTP
setenv loadaddr 0x42000000       # dirección de memoria RAM donde cargar los datos de la eeprom
saveenv                          # guardar valores

Luego con printenv se puede comprobar si se han guardado los valores:

¿Recordáis lo del router? Pues ha llegado el momento de aclarar por qué lo necesito.

Tras varios intentos frustrados de conectar directamente la cámara al pc (por ethernet) no lo conseguí, a pesar de poner misma máscara de red e ips dentro en las variables. Entonces, para descartar, tenía que probar con algo que tuviese dhcp y lo que tenía por ahí tirado era este router. Según chattie podría haber probado con un switch, pero no tenía uno a mano. Aunque yo creo que era tema de dhcp. Al fin y al cabo, si no me equivoco, diría que las tarjetas de red en ordenador modernos hacen automáticamente la conexión cruzada.

Y bueno, dicho lo dicho, al final se arregló con el router con openwrt. Aquí la chatarra electrónica a veces sirve para cosas jaja

Para subir los ficheros, y habiendo seteado las variables de entorno, usamos estos comandos:

sf probe 0   # inicializar SPI NOR

# Volcar bootloader por tftp
sf read ${loadaddr} 0x0 0x100000    # leer a RAM con offset 0x0, leer offset+0x100000 bytes
tftp ${loadaddr} boot.bin 0x100000  # subir por tftp a fichero boot.bin desde RAM los primeros 0x100000

# Volcar partición del kernel (desde 0x100000 a 0x400000 como hemos visto en la imagen)
sf read ${loadaddr} 0x100000 0x300000
tftp ${loadaddr} kernel.bin 0x300000

#Volcar RootFS
sf read ${loadaddr} 0x100000 0x300000
tftp ${loadaddr} kernel.bin 0x300000

#Volcar system
sf read ${loadaddr} 0xb00000 0x500000
tftp ${loadaddr} system.bin 0x500000

Esta parte la he hecho en windows (shame on me) porque era dónde estaba en ese momento. Además me alegra haberlo hecho así, porque el programita que me recomendó chattie era lo que necesitaba, una aplicación muy básica y portable para hacer el apaño (tftpd64):

Ejecutamos el volcado para las cuatro particiones y ya tenemos el backup de toda la memoria eeprom. Se supone que ahora los puedo unir con cat: cat boot.bin, kernel.bin, rootfs.bin, system.bin > full_flash.bin. Pero realmente puedo volver a ejecutarlo especificando toda la memoria y que lo haga de “pe a pa”, al fin y al cabo memoria RAM hay de sobra para copiarlo.

3.4. Examinar los ficheros

Ya tenemos las particiones en ficheros separados, ahora lo lógico sería pasar el binwalk. Que, para quien no lo conozca, es una herramienta capaz de identificar particiones y tipos de sistemas de ficheros en dumps como estos. También suele poder extraer los ficheros.

Podéis ver lo que saca al ejecutarlo sobre todos los volcados:

En esta sección me interesa la parte del rootfs y de system para intentar sacar los ficheros de cada partición.

Para el rootfs nisiquiera hace falta binwalk, el comando file y el propio gestor de ficheros ya reconocen que es una imagen de tipo squashfs. Y con más o menos esfuerzo puedes acabar montándolo y viendo los ficheros:

En mi caso tuve que instalar un plugin para dolphin que lo hacía, pero por ejemplo kali viene preparado y lo monta sin problemas desde el explorador de ficheros.

En esta partición no hay nada muy reseñable, ficheros estándar de busybox. Lo único interesante es esto:

Ahí, aparte del banner ascii cutrón que ya habíamos visto por uart, habla de un supuesto fichero llamado “ipcam.sh” que arranca al iniciar busybox. Al ser un script custom estará en la partición de system.

Ahora viene lo que me ha dado problemas, se ve que extraer un fichero con partición jffs2 (jefferson se llamaba?) no es tan rápido. Pero al final tras probar muchas cosas conseguí montarlo siguiendo estos pasos:

sudo modprobe mtdram total_size=16384 erase_size=64
sudo modprobe mtdblock

sudo dd if=system.bin of=/dev/mtd0

sudo mkdir /mnt/system
sudo mount -t jffs2 /dev/mtdblock0 /mnt/system

Lo que hace, o eso interpreté, es montar en memoria ram una memoria flash simulada. Luego copiamos el contenido del fichero a esta y montamos el “dispositivo” especificando que es jffs2.

Y conseguimos montarlo y acceder:

Y aquí ya tenemos acceso a ese script “ipcam.sh” que ejecuta una serie de binarios:

Voy a enseñar más cosas que he visto interesantes en la partición. Aquí se ve el contenido de una carpeta “param”, que tiene algunas configuraciones en ficheros .ini, como por ejemplo el id de fábrica o el dominio “push.eye4.cn”, pero también un usuario (es una mickey herramienta que servirá para la siguiente sección 🧐):

Una carpeta con los binarios en system/folder, os marco los que por nombre me parecen interesantes:

El fichero brush ese sale en ipcam.sh, pero weno, seguimos. Luego otra carpeta que contiene librerias en system/lib:

Y por último hay una carpeta www que contiene todos los ficheros de la interfaz web y de configuración:

Ahí hay muchas cosas interesantes, los ficheros *-b.ini son como los fichero base que contienen la configuración de fábrica. Y los que están sin -b la configuración guardada actualmente.

Y eso es todo respecto a los ficheros, no hay mucho más.

3.5. Consiguiendo acceso a la consola

Al final de pura suerte conseguí acceder a la terminal. Si recordáis, en la partición system hay un fichero param/passwd que contiene un tal usuario vstarcam2017. Y no sé cómo, si copias y pegas pulsando intro, en algún momento accedes. Entiendo que es porque no tiene contraseña, pero es que si lo haces cómo dicta la razón y la lógica no va, es hacer la del mono con el teclado y entra:

Tampoco ayuda el hecho de estar teniendo que lidiar con un log que no para nunca de sacar líneas y líneas, que en su mayoría no sirven para nada o son redundantes.

Sinceramente, no es que haya hecho gran cosa dentro de la terminal loggeado, aunque me sirvió para conseguír saber cuál era el programa que levantaba el servicio web (y los otros por lo visto). Un tal “encoder”:

3.6. ¿Quién eres encoder?

Es el fichero que abre todos los puertos del servidor, debe ser un tipo importante jaja

De todos modos primero buscamos, usando nuestro vecino y amigo grep, sus usos dentro todos los ficheros de la partición, ya que en el arranque no estaba:

Y parece que quién lo usa es el “wifidaemon”, que está en el script de ipcam.sh. Vamos a tirar mano de otro viejo amigo (radare2).

Y voy a hacer uno de mis diagramillas con los pasos que he hecho para sacar info del binario:

No se ve nah, abrid la imagen en otra pestaña si eso, tengo que ver cómo implementar en el blog que salga un popup ampliando la imagen al pulsar encima. Me falta frontend.

La explicación: busco strings dentro del binario donde ponga “encoder” y, sabiendo las direcciones de memoria, busco referencias a ella en métodos dentro del binario. Con esto se puede ver que se llama desde el método principal main y que simplemente hace una llamada a sistema system() para ejecutar el binario. Y que tiene un killall para cuando actualiza el firmware (supongo).

Por cierto, está compilado con flags de debugger, por eso muestra todo el código al lado, una práctica poco habitual en un producto comercial. A mi me viene de lujo que hayan sido tan cutres, así puedo leer el código fácil.

Ahora a ver si consigo sacar algo de encoder.

Sabes que la cosa va a estar jodida cuando ves esto a pesar de tener también símbolos de debug:

Es decir, hay cómo 4000 funciones definidas y muchas de ellas con nombres fcn.AbunchOfNumbers…

Es un fichero al que habría que echar muchas horas, es demasiado grande, tiene partes en las que carga módulos, en las que abre ficheros, procesa peticiones http… supongo que es el compilado resultado de algún proyecto hecho para hacer de servidor.

Aquí podemos ver referencias a ficheros en la carpeta www:

Usos de módulos:

Y una cosa curiosa es que muchos métodos importados tienen de nombre HI_MPI_loquesea:

Eso suele ser indicativo de que se está usando un sdk o algo similar. He buscado en Google y parece que existe un supuesto sdk llamado coloquialmente “Haisi” para los chips Hi35xx, pero no se chino, mirad esto y esto otro y sacad conclusiones.

Ahí pone que hay un pdf con más info, listo para descargar, pero creo que hay que poner perras, paso. Bueno más que pasar que no tengo monedas raras desas. En un futuro si me aburro intentaré sacarle jugo al bin.

Bonus hack: ¿Se nos está yendo de las manos esto de los CVE?

Me he enterado por el incibe que hay vulnerabilidades para cámaras como esta. A ver, tampoco es que me sorprenda, es lo habitual.

Leyendo he encontrado esta web en la que hay un listado con vulnerabilidades que afectan a cámaras del mismo rollo, esta es un rebranding de la que sale en la imagen de la web. Pero es que algunas supuestas vulnerabilidades son un poco ridículas, sobretodo las que pone que para explotarlas tienes que estar preautenticado como admin, pues a ver…

Por ejemplo, nos dice que sabiendo las credenciales podemos obtener el fichero de configuración ejecutando esto:

Pero es que yo que sé, es cómo decir que es vulnerable porque saco las credenciales así:

PERO SI YA TE SABES LAS CREDENCIALES PARA ENTRAR. A ver, hago un pequeño inciso dándole la razón, y es que si hubiera más de un usuario quizás sería un vector de ataque para sacar las credenciales del admin y escalar privilegios. Y que no debería poder acceder a ese fichero desde la web pero meh.

Por cierto, debería tapar la contraseña en la captura, pero cómo se me va a olvidar cuál era a la hora de redactar el siguiente post, usaré este post de gestor de contraseñas. El keepass es para cobardes.

De todos modos, ¡el sistema no permite tener más de un usuario! Y ese fichero aparte de las credenciales tiene poco de interesante.

La web mola, eso sí, porque tiene los PoC detallados, y eso siempre es bien.

4. Próximos pasos

Aquí la antesala al siguiente post, si es que al final lo hago, pero se queda en el tintero todo esto. Que encima es la parte que molaría conseguir.

4.1. Reemplazar el firmware por otro

He encontrado un firmware de código abierto que puede que sirva para la cámara, y me gustaría probarlo para librar a la pobre cámara de las cadenas del firmware chino, con lo que ello implica: mandar cosas a servidores chungos… El firmware se llama OpenIPC y en esta web se puede descargar el binario ya compilado para meterlo en la eeprom y probar.

También está el Github de OpenIPC para cotillear y/o compilarlo desde el código fuente. De momento cosas de las que no me fio pero hasta que no lo pruebe no puedo saber:

• creo que viene por defecto activada una opción para mandar el stream a sus servidores. Se supone que se puede desactivar, pero claro, si se te olvida te pueden ver en pelotas en la sección “open wall”. Igual me equivoco eh.
• no tiene pinta de que, de base, los motores vayan a funcionar en cuanto meta el firmware dentro de la eeprom, ojalá, pero 0 fe. Tendría que investigar más eso, e intentar sacar los drivers o la lógica del firmware chino pero claro, kernel 3.x….

Pero weno, eso es harina de otro costal.

4.2. Modificar sistema de ficheros y sobreescribir la eeprom

En el punto anterior, dentro de la web de OpenIPC nos dice incluso como sobreescribir la memoria eeprom, pero en resumen es hacer la inversa a lo que ya hemos hecho con el tftpd para obtener el dump. Si editas los ficheros puedes cargar la partición que te interese a memoria, en las mismas direcciones que se encontraba la original.

Aquí el único problema que he visto es que reempaquetar el sistema jffs2 igual no es algo que consiga a la primera. Ya que ha dado problemas para montar. Realmente esa partición, que es la de system, es la que nos interesaría modificar. Y la de rootfs quizás para cambiar qué cosas ejecuta al arrancar y poco más.

4.3. Reemplazar el kernel por una versión más moderna

Por último, también molaría poder reemplazar el kernel por uno que sea un poco más moderno, eso abriría posibilidades (supongo) para instalar utilidades y librerías más modernas.

Aquí hay un post que explica como compilar un kernel para un SoC cómo este (diferente versión) y subirlo. No he conseguido compilar ninguno de los dos repositorios que enlaza en el post, creo que es porque es código demasiado viejo, pero volveré a intentarlo.

¿FIN?

Y esto es un hasta pronto, porque cómo he dicho, espero ampliar en una segunda parte. Antes de irme, decir que la dueña legítima del cacharro ha decidido que tengo que insertar esta imagen en el post para dar el visto bueno:

Semper fidelis, reanimando cámaras IP. ¡Nos vemos! <3

Enlaces de interés

Esta sección suelo ponerla, básicamente voy apilando urls que he ido mirando y podrían volver a serme útiles a mi o a otra persona.

• Datasheet del SoC Hi3518 - Gracias Hackaday, nunca decepcionas <3
• Datasheet de la EEPROM
• App Eye4 en Google Play
• Incibe hablando de nuestra amiga
• Listado de vulnerabilidades
• Post hablando de cambiar el firmware
• Obtenr referencias dentro de binarios con radare2
• Github de OpenIPC
• Web instalación OpenIPC para nuestro SoC
• TFTP portable para windows - tftpd64
• Página man de system()
• uClib - librería estándar que han usado para compilar binarios