2 puntos por GN⁺ 2024-05-26 | 1 comentarios | Compartir por WhatsApp
  • La Samsung WB850F fue el primer modelo en usar en conjunto el SoC DRIMeIII y Wi‑Fi, y gracias a partialImage.o.map incluido en el ZIP del firmware fue posible analizar el firmware del SoC principal y evadir la detección de hotspot
  • WB850F_FW_210086.zip incluye WB850-FW-SR-210086.bin con 6 particiones y un volcado del enlazador de más de 300 mil líneas, lo que permitió confirmar que Main_Image era el firmware ARM real
  • En el análisis con Ghidra, la clave fue encontrar la dirección base 0xc0004000 de Main_Image usando la diferencia entre direcciones de cadenas, y convertir los nombres de funciones de .text para importarlos como símbolos
  • La función de detección de hotspot DevHTTPResponseStart determina si el AP está autenticado usando cookies de dominio Yahoo en respuestas HTTP 200 o la cadena yahoo. al inicio de URLs de redirección 301/302/307
  • Cuando Yahoo empezó a redirigir a HTTPS, la posición de yahoo. quedó fuera del rango permitido por el código, y tras el parche de samsung-nx-emailservice la WB850F logró subir fotos con éxito

Estructura del ZIP de firmware de la WB850F

  • La Samsung WB850F es uno de los pocos modelos en los que Samsung todavía publica firmware y archivos de soporte, incluso después de la descontinuación de la aplicación iLauncher
  • WB850F_FW_210086.zip contiene los siguientes archivos
    • GPS_FW/BASEBAND_FW_Flash.mbin
    • GPS_FW/BASEBAND_FW_Ram.mbin
    • GPS_FW/Config.BIN
    • GPS_FW/flashBurner.mbin
    • FWUP
    • partialImage.o.map
    • WB850-FW-SR-210086.bin
    • wb850f_adj.txt
  • FWUP solo contiene la cadena upgrade all, y parece ser un script para un módulo de pruebas/automatización de firmware
  • wb850f_adj.txt es un script más complejo que actualiza el firmware GPS y elimina archivos relacionados
  • Los scripts relacionados con GPS y la carpeta GPS_FW quedan fuera de este análisis

partialImage.o.map: un mapa en forma de volcado del enlazador

  • partialImage.o.map es un archivo de texto de más de 300 mil líneas que contiene la salida del enlazador para partialImage.o y el mapa completo de memoria de los archivos vinculados
  • La sección .text incluye nombres de funciones como sysInit, archPwrDown, DevHTTPResponseStart, DevHTTPResponseData y DevHTTPResponseEnd
  • La sección .data incluye símbolos de datos como sysBus, sysCpu y sysBootLine
  • Este archivo se usó como un mapa de símbolos para emparejar código y nombres de funciones dentro del firmware

Encabezado y tabla de particiones de WB850-FW-SR-210086.bin

  • Al inspeccionar WB850-FW-SR-210086.bin con binwalk, aparecen encabezados HTML, PNG, JPEG, encabezados VxWorks y varias rutas Unix, pero no se revela claramente ninguna partición ni sistema de archivos
  • Un volcado hexadecimal del primer 1 KB muestra la versión de firmware 210086, seguida por 0x00 0x06, y después nombres de archivo como FW_UP/ONBL1.bin
  • Cada registro parece tener una estructura de 60 bytes, compuesta por una cadena con padding de ceros de 32 bytes, dos enteros little-endian y un nombre de partición de 20 bytes con padding de ceros
  • Los dos enteros se interpretan respectivamente como longitud y offset dentro del archivo
  • Como hay un total de 6 registros, 0x00 0x06 se interpreta como el final de la cadena de versión del firmware o bytes de padding, más un conteo de particiones de 1 byte
  • Particiones reconstruidas

    • FW_UP/ONBL1.bin
      • Tamaño: 196 bytes, offset: 0x0000800, nombre de partición: ONBL1
    • FW_UP/ONBL2.bin
      • Tamaño: 46 KB, offset: 0x00008c4, nombre de partición: ONBL2
    • [WB850]DSC_5KEY_WB850
      • Tamaño: 30 MB, offset: 0x000bef4, nombre de partición: Main_Image
    • RomFS/SPID.Rom
      • Tamaño: 48 MB, offset: 0x1d2b32c, nombre de partición: Resource
    • FW_UP/WB850.HEX
      • Tamaño: 19 KB, offset: 0x4c75f2c, nombre de partición: OIS
    • FW_UP/skin.bin
      • Tamaño: 36 MB, offset: 0x4c7acb2, nombre de partición: SKIN
    • Para extraer las particiones se creó y usó la herramienta de extracción de particiones de firmware DRIMeIII

Diferenciar particiones de código y de datos

  • La herramienta de extracción saca archivos según el nombre de la partición y les agrega .bin
  • Con solo el resultado de file, la utilidad es limitada; por ejemplo, Main_Image.bin se identifica erróneamente como una OpenPGP Secret Key
  • ONBL1 y ONBL2 se infieren como el bootloader de primera y segunda etapa a partir de la cadena "BootLoader(ONBL1, ONBL2) Update Done" dentro de Main_Image
  • Main_Image es el firmware real, y binwalk -A reporta en este archivo múltiples prólogos de funciones ARM
  • Resource y SKIN son contenedores grandes, posiblemente configuraciones provistas por el fabricante del SoC relacionadas con la skin de la UI de la cámara
  • OIS, pese a su nombre de archivo, no es realmente un HEX y podría ser firmware para un dispositivo dedicado de estabilización óptica de imagen
  • El foco principal del análisis es Main_Image

Mapear Main_Image en Ghidra

  • Las tres particiones ONBL1, ONBL2 y Main_Image contienen código ARM real
  • El firmware ARM típico pone una tabla de vectores de reset en la dirección 0x0000000, pero los tres binarios empiezan con código lineal, así que hubo que remapearlos a una dirección todavía desconocida
  • Para analizar la falsa detección del hotspot, fue necesario hacer lo siguiente
    • encontrar la dirección de memoria correcta donde mapear Main_Image
    • cargar en Ghidra los nombres de símbolos de partialImage.o.map
    • analizar la función que dispara erróneamente la detección de login del hotspot
  • Al buscar "yahoo" en la pestaña Defined Strings de Ghidra, aparecieron entradas que parecen cadenas de depuración de DevHTTPResponseStart()
    • DevHTTPResponseStart: url=%s, handle=%x, status=%d
    • DevHTTPResponseStart: This is YAHOO check !!!
    • DevHTTPResponseStart: THIS IS GOOGLE/YAHOO/SAMSUNG PAGE!!!! 111
    • 301/302/307! cannot find yahoo!
  • En partialImage.o.map, DevHTTPResponseStart está en 0x321a84, y Ghidra también encuentra la función en ese mismo offset
  • La diferencia entre los valores de punteros a cadenas de depuración y el offset real de las cadenas coincidía con 0xc0004000, por lo que se concluyó que la dirección base de Main_Image era 0xc0004000
  • Como en Ghidra no se puede cambiar la dirección base después, hubo que eliminar el binario del proyecto y volver a importarlo configurando esa base

Importación de nombres de funciones y análisis de DevHTTPResponseStart

  • El ImportSymbolScript.py de Ghidra puede importar símbolos en masa desde una tabla de texto
  • El script espera en cada línea un nombre de símbolo, una dirección hexadecimal y f para indicar función o l para indicar etiqueta
  • En partialImage.o.map, como solo hacían falta las funciones de la sección .text, hubo que excluir los siguientes elementos
    • líneas vacías
    • offsets de archivos objeto
    • etiquetas de sección como .text
    • etiquetas con prefijo L$_
    • símbolos locales con prefijo $
  • A las direcciones se les sumó 0xc0004000 para alinearlas con la dirección base en Ghidra
  • El resultado convertido se generó en formato como sysInit c0004000 f, archPwrDown c0004094 f, y se cargó desde el Script Manager de Ghidra
  • Una vez cargados los nombres de funciones, se marcaron varios campos DAT_ como punteros y se renombraron parámetros según las cadenas de depuración para poder leer el decompilado de DevHTTPResponseStart

Condiciones de detección de hotspot

  • DevHTTPResponseStart determina si el AP Wi‑Fi está autenticado revisando el estado de la respuesta HTTP, la URL y los encabezados
  • En respuestas HTTP 200 OK, se considera autenticación exitosa solo si los encabezados de respuesta contienen una cookie de dominio Yahoo
    • Se revisan domain=.yahoo, Domain=.yahoo, domain=kr.yahoo y Domain=kr.yahoo
    • Si se cumple la condición, p_request_ongoing se cambia a 0 y, si el navegador no estaba autenticado, se llama a safnotify_auth_ap(0)
  • En redirecciones HTTP 301/302/307, se revisa la cadena yahoo. dentro de la URL
    • Si yahoo. no existe o está después de url + 11, se trata como si no se hubiera encontrado Yahoo
    • Si el framebuffer del navegador no está activo y tampoco hay autenticación, se llama a safnotify_auth_ap(1)
    • Si yahoo. aparece al inicio, se considera autenticación exitosa con safnotify_auth_ap(0)
  • Los estados negativos devuelven false, como si la solicitud se hubiera abortado
  • En estados positivos que no son ni 200 ni redirección, el resultado cambia según el estado del framebuffer del navegador

La verificación de Yahoo rota tras TLS y la evasión

  • La URL que consulta la cámara es http://www.yahoo.co.kr/
  • Si se hace la solicitud directamente, el servidor responde con HTTP/1.1 301 Moved Permanently junto con Location: https://www.yahoo.com/
  • En https://www.yahoo.com/, la subcadena yahoo. queda en la posición 12
  • El código exige que yahoo. esté en una de las primeras 11 posiciones, por lo que esta verificación quedó rota tras el cambio a HTTPS
  • Para pasar la comprobación del hotspot, hay que hacer que el registro DNS apunte a otro servidor y que ese servidor redirija por HTTP a un nombre que se parezca más a Yahoo, o bien configure una cookie de dominio Yahoo
  • Tras el parche de samsung-nx-emailservice, la cámara efectivamente logra conectarse y subir fotos

Otras cámaras con la misma evasión aplicada

  • Este análisis logró entender y evadir la detección de hotspot de la cámara Wi‑Fi Samsung WB850F basándose en una sola función sometida a ingeniería inversa
  • El parche final fue pequeño, pero por la forma en que un ingeniero de Samsung implementó la detección, habría sido difícil adivinar la evasión correcta solo siguiendo paquetes
  • Una vez claro qué había que buscar, la misma evasión se aplicó también a cámaras que consultan MSN.com
  • Como resultado, EX2F, ST200F, WB3xF y WB1100F se agregaron a la lista de cámaras compatibles
  • Main_Image contiene más de 77 mil funciones, así que todavía queda mucho por analizar para entender mejor el funcionamiento de estas cámaras digitales

1 comentarios

 
GN⁺ 2024-05-26
Opiniones en Hacker News
  • Me gustó más https://op-co.de/blog/posts/samsung_nx_cryptofail/#index3h3
    Es un caso realmente sorprendente de fallo de cifrado de firmware

  • Gran trabajo. Me pregunto si has pensado en convertir el método de ingeniería inversa en un tutorial

    • En realidad esperaba que este artículo aportara suficiente información como para servir de tutorial
      Solo omití las partes fáciles de buscar en Google
  • Lo único que quiero es tomar fotos dSLR con el botón de la cámara y que, poco después, esa imagen esté en Apple Photos

    • Antes existían tarjetas SD con Wi-Fi integrado que podían sincronizar fotos automáticamente, pero Eye-Fi, que era uno de los principales actores de ese sector, cerró, y no parece que nadie haya creado un producto nuevo que funcione con servicios modernos en la nube
      Parece que no hay suficiente demanda porque los smartphones prácticamente eliminaron el mercado de cámaras de consumo. Como idea de proyecto, sería encontrar la forma de meter un ESP32 dentro de una tarjeta SD
    • Una dSLR Canon con Wi-Fi probablemente pueda usar FTP
      También se puede conectar a un teléfono, tablet o sitio web, pero requiere una app o servicio. Documentación para enviar por FTP directamente desde la cámara: https://gdlp01.c-wss.com/gds/5/0300024975/01/eos5d-mk4-wff-i... página 113. El enlace es al manual de instrucciones de la función Wi-Fi (comunicación inalámbrica) de la EOS 5D Mark IV (WG)
    • Las Samsung NX1 y NX500 con Linux se pueden programar con bastante facilidad para subir JPEG o RAW a cualquier servicio en línea, siempre que haya una red Wi-Fi
      Lamentablemente son modelos de hace 10 años y también son raros en el mercado de segunda mano
    • La serie Nikon Z con SnapBridge es casi la mejor opción para eso
      Se empareja por Wi-Fi o Bluetooth y, si quieres, puedes controlar la cámara de forma remota desde un iPad y ver la pantalla
    • Ya es posible para Google Photos, así que esto también debería ser posible: https://www.stg-uploader.xyz/