Reversing Firmware camara SJ4000

Nucklear

¿De que va este hilo?

A petición de otro user abro este hilo para hacer un seguimiento y ayudarnos en el proceso de destripar el firmware de esta camara.

¿Por que esta cámara y no la GoPro?

Porque es una cámara que ha ganado mucha popularidad y es competidora directa de la GoPro. Ademas la GoPro ya ha sido reverseada hasta la saciedad y no supone un reto.

http://goprouser.freeforums.org/hero3-black-firmware-studies-physical-teardown-photos-t10016.html
http://chdk.setepontos.com/index.php?topic=5890.0
https://www.druid.es/content/gopro-firmware-forensic

Vamos al turron

La imagen sobre la que basaremos el estudio la podeis descargar desde aqui:
http://www.sjcam.com/firmware/SJCAM_SJ4000_WIFI_0918.zip

He elegido la versión wifi porque tiene mas papeletas para encontrar cosas interesantes al añadir comunicación externa.

Herramientas que usaremos

  • Binwalk

  • Hexdump

  • Hexeditor

  • Comandos strings, dd, etc...

  • Debugger radare2, IDA...

  • Librerías de compresión

Nota: Estas son las que yo uso

Datos de la cámara extraidos del firmware:

  • SoC Ambarella A7 (Mismo que GoPro) : http://www.ambarella.com/products/sports-cameras

  • El RTOS que usa la camara es Windows CE y monta cygwin para emular diferentes partes del OS (Confirmado)

  • Las imágenes de actualización son partes del firmware completo (Por confirmar)

Primeros pasos sobre el firmware

Lo primero que he hecho ha sido intentar identificar ante que nos encontramos por lo que he usado el comando file, strings, hecho un volcado hexadecimal del binario y revisado la entropía del archivo.

Estos son los resultados:

root@uservm:~/SJ4000# file FW
FW: data

root@uservm:~/SJ4000# strings -n 9 FW | head -20
NT96655 1000000020100701
0LD:GS650    
$pDRAMINFO @W20140918V02 '^G Section-%.2ld: Range[0x%08X~ ^R*** Math error: type=%d name="%s" arg1=%f HCPU Exception in ISR! caus %, by [%s: ^RAssert:`%s' is failed! (%s:%u) %s(): ^N(_main begin) (reg exp handler kernel init Install code s for mempool POOL_ID_STORAGE_NAND FWS_BUFFER DISP_OSD2 ,GFX_IMAGE DATEIMPRINT ^RFATAL:%s() calling flow (%08x)! root@uservm:~/Desktop/SJ4000# hexdump -C FW | head -10 00000000 42 43 4c 31 4a dd 00 09 00 53 b3 d0 00 2e 91 ec |BCL1J....S......| 00000010 9d 00 04 00 80 00 00 00 00 9d 04 04 9d 08 08 9d |................| 00000020 10 10 9d 20 20 9d 0c 0c 4e 54 39 36 36 35 35 20 |... ...NT96655 | 00000030 31 30 30 30 30 30 30 30 32 30 31 30 30 37 30 31 |1000000020100701| 00000040 d0 b3 53 00 55 aa 7b 2f 9d 10 30 4c 44 3a 47 53 |..S.U.{/..0LD:GS| 00000050 36 35 30 20 20 20 20 9d 04 04 9d 04 14 ff ff ff |650 .........| 00000060 ff 9d 04 04 9d 24 70 44 52 41 4d 49 4e 46 4f 9d |.....$pDRAMINFO.| 00000070 08 40 9d 2c 3c 9d 04 04 53 54 52 47 9d 0c 40 9d |.@.,<...STRG..@.| 00000080 0e 1e 70 00 00 00 50 00 00 9d 05 82 23 f0 00 00 |..p...P.....#...| 00000090 00 10 9d 11 40 57 32 30 31 34 30 39 31 38 56 30 |....@W20140918V0|

De esto se pueden extraer varias cosas interesantes. Al sacarnos texto inteligible sabemos que el archivo no está cifrado pero su baja entropía puede ser un indicativo de que si que está comprimido. Si analizamos las cabeceras del hexadecimal nos encontramos con lo siguiente:

00000000  42 43 4c 31 4a dd 00 09  00 53 b3 d0 00 2e 91 ec  |BCL1J....S......|

Con una rápida busqueda en Google nos encontramos con que BCL1 hace referencia a Basic Compression Library ademas de que los demas bytes hacen referencia al algoritmo de compresión LZ77.

Una vez descargada y compilada la BCL comprimimos un archivo de ejemplo para analizar la cabecera:

00000000  42 43 4c 31 81 66 00 09  00 54 68 e0 00 2f 2b bf  |BCL1.f...Th../+.| < FIRMWARE
00000000  42 43 4c 31 00 00 00 09  00 00 4f 88 99 7f 45 4c  |BCL1......O...EL| < LZ77 Ejemplo

Como se puede ver la estructura de bytes es la misma (HEADER [4Bytes] - 09 [Indica algoritmo]) los últimos 8 bytes indican el tamaño del archivo comprimido y sin comprimir (En Big Endian)

La unica diferencia entre nuestro firmware y el ejemplo son el quinto y sexto byte (81 66) pero despues de darle vueltas llegué a la conclusión de que son bytes basura generados a la hora de comprimir así que con un editor hexadecimal los puse a cero para que el descompresor no se vuelva loco. Dejandolo de la siguiente forma:

00000000  42 43 4c 31 81 66 00 09  00 54 68 e0 00 2f 2b bf  |BCL1.f...Th../+.| < FIRMWARE
00000000  42 43 4c 31 00 00 00 09  00 54 68 e0 00 2f 2b bf  |BCL1.f...Th../+.| < FIRMWARE Modificado

Al probar a descomprimirlo así el descompresor me tiraba un Segmentation Fault:

LZ77 decompress FW to test...
Input file: 3091395 bytes
Output file: 5531872 bytes
Segmentation fault

Lo primero que se me vino a la mente fue " Si la cabecera me dice el tamaño comprimido y descomprimido voy a castear esos bytes para ver cuantos bytes mide el archivo" así pude compararlo con los datos que me da al intentar descomprimir:

root@uservm:~/SJ4000# binwalk -C -o 0x0000008 -l 12 FW

DECIMAL   	HEX       	DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
8         	0x8       	Hex:                 0x005468E0
          	          	Little Endian Quad:  -4671588507655318528
          	          	Big Endian Quad:     23759209328749503
          	          	Little Endian Long:  -530033664
          	          	Big Endian Long:     5531872
          	          	Little Endian Short: 21504
          	          	Big Endian Short:    84
          	          	Little Endian Date:  Mon Mar 16 03:25:36 1953
          	          	Big Endian Date:     Thu Mar  5 19:37:52 1970

12        	0xC       	Hex:                 0x002F2BBF
          	          	Little Endian Quad:  1126568834051840
          	          	Big Endian Quad:     13277425844618240
          	          	Little Endian Long:  -1087688960
          	          	Big Endian Long:     3091391
          	          	Little Endian Short: 12032
          	          	Big Endian Short:    47
          	          	Little Endian Date:  Sun Jul 14 20:10:40 1935
          	          	Big Endian Date:     Thu Feb  5 13:43:11 1970

Y bingo, como vemos Output file es igual a Big Endian Long del primer caso, pero en input file tenemos una diferencia de 4 bytes:

3091395 - 3091391 = 4bytes

Esta diferencia es la que nos estaba causando el Segmentation fault así que para parchearlo rápidamente y poder seguir abrimos el código de BCL (bcl.c) y editamos lo siguiente (Alrededor de la línea 92):

Antes
Despues

Compilamos de nuevo la librería y ya podemos descomprimir el firmware sin problema.

A partir de aqui me he estancado un poco aunque no veo que sea un camino sin salida. Con la nueva imagen descomprimida vuelvo a empezar por el principio (Tiramos file, strings, hexdump, binwalk y reanalizamos la entropia).

  • file no devuelve ningun resultado así que supongo que el firmware consta de varias partes

  • strings nos devuelve mas cosas que antes (Y podemos sacar cadenas interesantes)

  • Binwalk nos devuelve un puñado de falsos positivos

  • El analisis de entropia enseña un gran bloque al final del archivo que aun no he logrado identificar

Echando un ojo al nuevo volcado hexadecimal veo algunas cosas interesantes pero que no logro identificar, como por ejemplo:

00000000  00 04 00 80 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000050  4e 54 39 36 36 35 35 20  31 30 30 30 30 30 30 30  |NT96655 10000000|
00000060  32 30 31 30 30 37 30 31  d0 b3 53 00 55 aa 7b 2f  |20100701..S.U.{/|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  4c 44 3a 47 53 36 35 30  20 20 20 20 20 20 20 20  |LD:GS650        |
00000090  00 00 00 00 ff ff ff ff  ff ff ff ff 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000c0  44 52 41 4d 49 4e 46 4f  20 20 20 20 20 20 20 20  |DRAMINFO        |
000000d0  ff ff ff ff ff ff ff ff  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  53 54 52 47 49 4e 46 4f  20 20 20 20 20 20 20 20  |STRGINFO        |
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 70 00  |..............p.|
00000120  00 00 50 00 00 00 80 00  00 00 f0 00 00 00 10 00  |..P.............|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000140  57 32 30 31 34 30 39 31  38 56 30 32 00 00 00 00  |W20140918V02....|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000180  00 68 1a 40 7f 00 5a 33  10 80 1b 3c 74 b1 7b 27  |[email protected]...<t.{'|
00000190  20 d8 7a 03 00 00 7b 8f  08 00 60 03 00 00 00 00  | .z...{...`.....|
000001a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000240  75 ed 03 08 00 00 00 00  00 00 00 00 00 00 00 00  |u...............|
00000250  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

NT96655 es el modelo de la cámara, 20100701 supongo que la primera versión, W20140918V02 es la versión actual del firmware. Lo interesante es la disposición de los datos con la misma estructura de bytes. Y la cabecera 00 04 00 80 que llama la atención entre tanto cero (Si a alguien le suena de algo que avise :3).

¿Que necesito saber para ayudar?

Si después de lo que has leído aun no te has perdido eres bienvenido a echar una mano.

Notas finales

Abro el hilo para ver si entre todos podemos ir sacando algo en claro y poder darles a los usuarios de esta cámara (yo no lo soy) algún hack interesante. Esto no va a ser un tutorial de reversing así que para cualquier duda (Duda y no curso completo) podéis mandarme un MP.

Seguiré actualizando con los nuevos hallazgos segun vaya sacando algo interesante.

6
Nucklear

Un paso mas. Puedo confirmar que el RTOS que usa la cámara es Windows CE (Si, la SJ4000 tiene las mismas tripas que una Dreamcast) junto con ITRON RTOS, es un hibrido que llamaron "Windows Acelerator Tool" y que teneis especificado aqui:

http://www.ertl.jp/ITRON/DOC/iim99/Elmic.pdf

En concreto esto lo deduzco de las siguientes cadenas:

000941e0  75 69 74 72 6f 6e 2e 63  79 67 77 69 6e 5f 69 6e  |uitron.cygwin_in|
00094290  6e 74 39 36 36 35 30 2e  75 69 74 72 6f 6e 2e 63  |nt96650.uitron.c|
000a0be0  36 35 30 2e 75 69 74 72  6f 6e 2e 63 79 67 77 69  |650.uitron.cygwi|
000a2b50  75 69 74 72 6f 6e 2e 63  79 67 77 69 6e 5f 69 6e  |uitron.cygwin_in|
000a2bf0  6e 74 39 36 36 35 30 2e  75 69 74 72 6f 6e 2e 63  |nt96650.uitron.c|
000a3990  6e 74 39 36 36 35 30 2e  75 69 74 72 6f 6e 2e 63  |nt96650.uitron.c|
000f0e40  75 69 74 72 6f 6e 2f 76  32 5f 30 5f 36 30 2f 73  |uitron/v2_0_60/s|
000f10a0  76 6f 69 64 20 63 79 67  5f 75 69 74 72 6f 6e 5f  |void cyg_uitron_|
000fa720  75 69 74 72 6f 6e 2e 63  79 67 77 69 6e 5f 69 6e  |uitron.cygwin_in|

Aqui podemos ver que existen referencias a ITRON dentro del firmware y una cosa que me mosqueaba mucho era la presencia de cygwin. Esto no tenia ningún sentido sin la presencia de un core Windows. Por lo que me puse a buscar alguna referencia a este, para ello user binwalk para ver que me mostraba de la imagen. Aunque no es fiable el resultado vemos que encuentra algunas cabeceras relacionadas a Windows CE

root@vmuser:~/SJ4000/# binwalk FW 

DECIMAL   	HEX       	DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
[...]
4592396   	0x46130C  	Windows CE RTOS
4592400   	0x461310  	Windows CE RTOS
4592404   	0x461314  	Windows CE RTOS
4592408   	0x461318  	Windows CE RTOS
4592412   	0x46131C  	Windows CE RTOS
4592416   	0x461320  	Windows CE RTOS
[...]

Por último para confirmar que esto es cierto he buscado una lista de sys_call del sistema y he probado a buscar en los strings si hay algo concreto:

000f0c10  63 72 65 5f 74 73 6b 28  29 3a 20 6d 61 6c 6c 6f  |cre_tsk(): mallo|

Y BINGO, esto parece ser una definición de una syscall a la que hace referencia la documentación.

El siguiente paso es encontrar el bloque del RTOS y tratar de extraerlo.

ACTUALIZACION

Buscando documentación sobre los headers de Windows CE me he encontrado con este enlace:
http://forum.xda-developers.com/showthread.php?t=801167

Y acorde a eso el magin number de Windows CE es B0 00 FF lo que me da 3 resultados en nuestro firmware.

Esta es la especificación:

struct BIN_HEADER {
char[7] Signature;      // B000FF\n signature	
DWORD ImageStart;    // Image Start
DWORD ImageLength; // Image Length
};

Y en un vistazo rápido he identificado un posible candidato a esta estructura. Por hoy lo dejo y en otro momento sigo. Si alguien se anima que valide eso :3

2
_rAiDeN_

Muy buen curro enhorabuena!

Siguiendo el tema con lo que tengo ahora mismo en esta maquina instalado y descargando el firm que pones diría que la llamada al main del kernel es esta:

35:%s(): ^N(_main begin)

A seguir mirando...

Kiroushi

¿En qué consiste este "reversing"?

1 respuesta
Corven

ufff, que lio ajajjaa. Pero eso no se supone que es instalar y ya? Que me llega el lunes la mia no me jodais jajaja.

1 respuesta
Nucklear

#4 Desempaquetar el firmware, ver como trabaja internamente, analizar su funcionamiento internamente y en base a lo que se saque desarrollar algun modulo externo que interactue con la camara o añadir funcionalidades.

#5 Esto no tiene nada que ver con el uso normal de la cámara no te preocupes. Para usarla o actualizarla no te tienes que preocupar de nada de esto.

1 respuesta
Corven

#6 osea que me voy al hilo "normal" y con el firm de alli me vale no? sin pajas mentales.

1 respuesta
Nucklear

#7 Exacto, esto no tiene nada que ver con el uso normal de la cámara.

thecodegamer

Me parece un hilo muy interesante, si podemos hacer un firmware customizado alomejor conseguimos sacar funciones que no estan ahora mismo en la camara presentes. Sigo pensando que la camara puede hacer 60fps reales a 720p ya que tanto el chip novatek como el sensor lo tienen en sus paginas tecnicas que pueden hacerlo (el unico cuello de botella que se me ocurre es alomejor la velocidad de escritura en la microSD)

2 respuestas
Nucklear

#9 Estos dias estoy liado con el CTF de la Cybercamp, las clasificatorias acaban el Lunes y a ver si me puedo poner con esto.

Por ahora estoy donde lo dejé, intentando extraer el RTOS como puse en #2, los bytes de la cabecera coinciden, pero no la estructura de los bytes de control, así que no se si estoy tomando una aproximacion incorrecta o me pierdo algo.

kidike

#9 ¿Con las class 10 no llegaría?

2 respuestas
Nucklear

#11 Se refiere a la tasa de transferencia de la propia camara no de la SD.

1 respuesta
thecodegamer

#11 #12 En efecto me refiero a la tasa de escritura que tenga la camara incorporada en su "placa base" ya que por el resto del hardware (sensor y chip) en teoria si puede hacerlo real.
Si no me equivoco creo que aquí tenéis la info de cada uno:
CHIP: https://dashcamtalk.com/cams/mobius/Novatek%20NT96650.pdf
SENSOR(no estoy seguro de que sea este): https://www.aptina.com/assets/downloadDocument.do?id=754
EDIT: Aqui tengo un poco mas de informacion del sensor:
Image Sensor Type: 3:2” CMOS 3.0 MP (Aptina0330)
Effective Pixels: Approx. 3.0Mega Pixels (2048*1536)

B

Cojo sitio que estas cosas interesan, a ver que tal va evolucionando :clint:

B

Mira qué coincidencia, ayer la pillé en Amazon xD

A favoritos.

Nucklear

Bueno ya tengo algo mas de tiempo y hoy ya me he vuelto a poner con esto. He visto un par de secciones interesantes en el firmware que tendré que investigar mas a fondo.

Por si alguien quiere descargarse la imagen ya descomprimida y empezar desde el punto en el que estoy aqui os la dejo: https://www.dropbox.com/s/7oq4m2zryid3ugv/FW_ZERO_DES.bin?dl=0

1
Nucklear

Tengo nuevas actualizaciones y unos cuantos pasos atras. Revisando mas en profundidad y con algo de ayuda externa veo que me equivoqué.

Las referencias a Windows CE eran falsos positivos de binwalk, cosa que estaba empezando a sospechar porque la cabecera a la que hago referencia en #2 no cuadraba de ninguna forma. Y revisando de nuevo los strings se ven recerencias a eCos un RTOS basado en ITRON.

Como bien me dijeron en stack overflow hay que fijarse que los paths con referencias a cygwin y itron son referencias del paquete de desarrollo de eCos así que confirmamos 100% que se trata de eCos y no de Win CE como al principio se pensaba.

Ahora que ya tengo identificada la imagen he ido desensablando algunas secciones:

En el offset 0x180 encontramos lo que parece el gestor de excepciones de eCos:

ROM:80000180                 mfc0    $k0, Cause       # Cause of last exception
ROM:80000184                 andi    $k0, 0x7F
ROM:80000188                 la      $k1, off_800FB174
ROM:80000190                 add     $k1, $k0
ROM:80000194                 lw      $k1, 0($k1)
ROM:80000198                 jr      $k1
ROM:8000019C                 nop

Y bajando a un poco mas en la lectura hexadecimal vemos lo siguiente:

00000350  70 25 1d 80 d8 85 36 00  ff ff ff ff ff ff ff ff  |p%....6.........|
00000360  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000400  00 48 80 40 ff ff 0a 24  00 58 8a 40 00 90 80 40  |.H.@...$.X.@...@|
00000410  00 98 80 40 10 80 09 3c  70 b1 29 25 00 00 25 8d  |...@...<p.)%..%.|
00000420  07 00 a0 14 00 00 00 00  00 b0 0a 3c 00 00 4b 8d  |...........<..K.|
00000430  07 00 6a 31 80 00 0b 24  04 28 4b 01 00 00 25 ad  |..j1...$.(K...%.|
00000440  08 b0 08 3c 00 00 00 ad  20 00 02 24 01 60 82 40  |...<....

Como se puede ver en el offset 0x400 nos encontramos lo que parece el principio de un bloque de instrucciones así que pasamos a analizarlo en un decompilador y extraemos lo siguiente:

ROM:00000480                 li      $t3, 7
ROM:00000484                 nor     $t3, $zero
ROM:00000488                 and     $t2, $t3
ROM:0000048C                 ori     $t2, 3
ROM:00000490                 mtc0    $t2, Config      # Configuration register
ROM:00000494                 mfc0    $t4, Config, 7   # Configuration register
ROM:00000498                 ori     $t4, 0x100
ROM:0000049C                 mtc0    $t4, Config, 7   # Configuration register
ROM:000004A0                 li      $v0, 0x800004B0 <-- Posible direccion de carga en 0x80000000  
ROM:000004A8 jr $v0 ROM:000004AC nop

Al ver la referencia a 0x800004B0 podemos asumir que la dirección base es 0x80000000 así que reabrimos la imagen apuntando a esas direcciones y ya podemos desensamblar todas las instrucciones del binario:

Ya tenemos algo tangible, pero el siguiente paso es buscar una rutina de descompresión o algo similar en caso de haberla.

De todas formas sospecho que este es el final del camino para tener el firmware limpio y a partir de ahora tocará meterse a analizar desensamblado MIPSEL lo cual me da bastante pereza, si alguien se anima que me avise :3

Otra opcion es que algun ente amable me ceda una camara para continuar el análisis sobre un firmware desplegado :)

1
Soltrac

Joder eres una máquina

1 respuesta
Nucklear

#18 Gracias, pero esta es la parte facil jeje

Segun la documentación de eCos al bootear el RTOS monta un sistema de archivos especificado en el File System Table.

Mi idea es encontrar la rutina que monta ese sistema de archivos y buscar las direcciones de memoria de donde carga el sistema de archivos para poder cortarlo del firmware y montarlo en local.

La otra opcion es montar un eCos en local, y ver como trabaja internamente.

Y desde aqui ya podemos rezar, porque he extraido 14000 funciones de la imagen, y no me voy a poner a buscarle las cosquillas a la camara en esa maraña de código xD

AnderVentura

Yo no tengo ni idea de todo esto pero me gustaría preguntar algo. Algunas sj4000 vienen con el firmware N20140809V01 de seria y al actualizar a los nuevos (los que tienen la interfaz renovada) la disposición de los botones cambia. Es un problema conocido y que les pasa a todas las que traen ese firmware. ¿Se podría modificar el último firmware para solucionar este problema? Solo se tendría que volver a asignar bien los botones OK y ABAJO.

1 respuesta
Nucklear

#20 Si, se podria probablemente, pero habria que encontrar como y donde lo hace.

1 respuesta
AnderVentura

#21 Yo no puedo ayudar. Estoy acabando la carrera de ingeniero electrónico, pero no me han formado en esto. Todo me suena a chino. Espero tener tiempo para investigar en un futuro.
A ver si sacáis algo en claro.
Muchas gracias!

8 días después
S

Yo no puedo ayudar. No tengo experiencia con eso. :(

Pero me gustaría saber si hay algun update y se es posible obtener a custom firmware..

muchas gracias mi amigo !!

14 días después
thecodegamer

Yo dispongo de una cámara por si necesitáis probar alguna de las funcionalidades que saquéis adelante.
De la programación, en ese entorno la verdad es que no me he movido mucho, aunque entiendo las diferentes secciones mas o menos, estaría verdaderamente interesante si alguien de alguna web o foro de desarrolladores cogiera una cámara de estas y empezara a haber un ecosistema customizado

spyro512

a qué le llamas entropía exactamente?

2 respuestas
allmy

Sumamente interesante, a ver si mañana o pasado tengo tiempo y me meto de lleno.

thecodegamer

#25 Creo que hace referencia a la complejidad o como de "oculto" esta el código legible en esas lineas de código por así decirlo RAW (sin interpretar)

1 respuesta
MTX_Anubis

#25 Por lo que entiendo, a que está demasiado estructurado y sigue demasiados patrones xD

1 respuesta
spyro512

#27 #28 he dado recientemente bastante artillería sobre la teoría de información y quería saber si iba por esa dirección xD

1 respuesta
Nucklear

#29 Es el nivel de caos que existe, por ejemplo en el caso del firmware estar cifrado el nivel de entropía será bajo ya que la cantidad de patrones que se repiten es bajo o nulo.

Esto sirve para encontrar patrones repetitivos y estructuras de datos.

1 respuesta