Investigación digital 24 (2018) S60 e S67

Listas de contenido disponibles en ScienceDirect

Investigación digital

journalhomepage: www. elsevier. com / localizar / diin

DFRWS 2018 Europe d Actas de la quinta edición anual del DFRWS Europe

Adquisición forense d Análisis y elusión del modo de criterios

comunes forzado de inicio seguro de Samsung
Gunnar Alendal a , * , Geir Olav Dyrkolbotn a , c , Stefan Axelsson a , b
a Departamento de Seguridad de la Información y Tecnología de la Comunicación, NTNU, Gjøvik, Noruega
b Universidad de Halmstad, Suecia
c Academia Cibernética de Defensa de Noruega (NDCA), Jørstadmoen, Noruega

resumen

Palabras clave: La adquisición de datos de teléfonos móviles ha sido un pilar de la ciencia forense digital criminal
Criterios comunes durante varios años. Sin embargo, esta adquisición forense se está volviendo más y más dif fi culto
Modo CC con el creciente nivel de seguridad y la complejidad de los teléfonos móviles (y otros dispositivos
Seguridad
integrados). Además, a menudo es dif fi culto o imposibles de conseguir el acceso a diseñar especí fi
móvil
caciones , documentación y código fuente. Como resultado, los métodos de adquisición forense
Gestión de dispositivos
móviles Adquisición también están aumentando en complejidad, lo que requiere una comprensión cada vez más
forense Teléfono profunda de la tecnología subyacente y sus mecanismos de seguridad. Las técnicas de adquisición
inteligente forense están recurriendo a soluciones más ofensivas para eludir los mecanismos de seguridad, a
Arranque seguro de Samsung través de vulnerabilidades de seguridad.

Modo de Criterios Comunes es una característica de seguridad que aumenta el nivel de seguridad
de los dispositivos de Samsung, y así hacer la adquisición forense más dif fi culto para hacer
cumplir la ley.
Sin acceso a documentos de diseño o código fuente, hemos realizado ingeniería inversa de cómo
el modo Common Criteria está realmente implementado y protegido por el cargador de arranque
seguro de Samsung. Presentamos cómo se aplica este modo de seguridad, las vulnerabilidades de
seguridad en el mismo y cómo las vulnerabilidades de seguridad descubiertas se pueden utilizar
para eludir el modo de Criterios Comunes para una mayor adquisición forense.
© 2018 El autor (es). Publicado por Elsevier Ltd en nombre de DFRWS. Este Es Un Artículo de
acceso abierto Bajo la CC BY-NC-ND licencia
( http://creativecommons.org/licenses/by-nc-nd/4.0/ ).

Introducción El cifrado actual, a menudo obligatorio, de los datos del usuario

en dispositivos móviles invalida dichos métodos. La capacidad
La ciencia forense digital es la recuperación e investigación de leer datos almacenados en el almacenamiento del
de datos encontrados en dispositivos digitales ( Carrier, 2002 ). dispositivo simplemente no es suficiente. La lectura de datos
Gar fi nkel (2010) discute las dif fi cultades que le espera a la cifrados tiene poco valor sin las claves de cifrado
ciencia forense digital, ¿qué retos existentes en las correspondientes. La adición de funciones de seguridad como
herramientas de hoy en día, la investigación y el conocimiento claves de cifrado vinculadas a dispositivos , compatibles con
y la forma digital de la investigación forense deben moverse hardware y una TrustZone, hace que sea aún más difícil
hacia adelante para mantener la ciencia forense digital un obtener acceso a dichas claves de cifrado. Esto podría requerir
método válido para los próximos años. La predicción es que que la policía encienda el dispositivo para intentar extraer
tanto la recuperación como la adquisición forense y la claves o datos descifrados la interacción con los mecanismos de
investigación serán cada vez más difíciles a medida que la seguridad del usuario que protegen los datos del usuario. Este
complejidad y los mecanismos de seguridad, como el cifrado, tipo de interacción a menudo significa instalar o modificar el
aumenten su uso. Frente a esta seguridad cada vez mayor de código en el dispositivo. Aunque las fuerzas del orden tienen
los productos comerciales de estantería (COTS), la aplicación de una causa legítima para su " piratería " , esta es una actividad
la ley se enfrenta a un desafío cada vez mayor en lo que respeta que en otros contextos se consideraría maliciosa e ilegal,
la capacidad de realizar adquisiciones forenses. Donde antes la también conocida como ataque. Por lo tanto, para proteger
aplicación de la ley podía eludir los mecanismos de seguridad, contra este tipo de ataques, la mayoría de dispositivos móviles
por ejemplo, accediendo a los datos en un nivel inferior, como proveedores de código de protección que se ejecutan en los
la desoldadura forense (chip-off), para leer el contenido del dispositivos, desde el fi código de primera ejecutada en el
almacenamiento de datos directamente, encendido y todo el camino a través de un sistema operativo
completo, al igual que Android, está en funcionamiento. Esto a
menudo se conoce como arranque seguro y se refiere a la
confianza en el código ejecutado en el dispositivo. Este código
* Autor para correspondencia.
sólo debe ser certi fi cados y de fi código oficial, hecha por el
Direcciones de correo electrónico: gunnaale@stud.ntnu.no (G. Alendal), vendedor, y debidamente firmado para probar la autenticidad.
geir.dyrkolbotn@ntnu.no
(VAYA Dyrkolbotn), stefan.axelsson@ntnu.no (S. Axelsson).

https://doi.org/10.1016/j.diin.2018.01.008
1742-2876 / © 2018 El autor (es). Publicado por Elsevier Ltd en nombre de DFRWS. Este es un artículo de acceso abierto bajo la licencia CC BY-NC-ND (
http://creativecommons.org/ license / by-nc-nd / 4.0 / ).

G. Alendal y col. / Investigación digital 24 (2018) S60 e S67 S61

La policía siempre se esfuerza por adquirir la mayor acceso. Estos diferentes métodos tienen diferentes requisitos y
cantidad de datos posibles para respaldar cualquier debilidades. El chip-off requiere acceso físico a los medios de
investigación en curso. Por lo tanto, eludir esquemas de almacenamiento subyacentes y no puede hacer frente al uso
seguridad tan complejos, si es posible, obliga a las fuerzas del cada vez mayor del cifrado en los dispositivos de
orden a invertir en un conocimiento más profundo y en almacenamiento. JTAG es una interfaz que se utiliza a menudo
equipos costosos para realizar adquisiciones forenses durante el desarrollo y la prueba de un dispositivo, y se puede
avanzadas, utilizando tales ataques. 1 Las fuerzas del orden utilizar para comunicarse directamente con los medios de
están invirtiendo en el descubrimiento y uso de almacenamiento subyacentes. Sin embargo, las clavijas de
vulnerabilidades de seguridad, para eludir los mecanismos de prueba JTAG puede ser difícil de encontrar y el acceso en
seguridad y adquirir evidencia digital. diferentes dispositivos, y también puede ser protegido contra el
acceso no autorizado, y también desactivado por el vendedor
Por otro lado, visto desde la perspectiva del usuario y de la antes de enviar. ADB es una potente interfaz de depuración
empresa, con el uso creciente de estos dispositivos, tanto los compatible con Android, pero no está habilitada de forma
usuarios finales como las empresas están exigiendo dispositivos predeterminada en la mayoría de los dispositivos Android, ni
más seguros para ayudar a proteger los datos confidenciales. La proporciona acceso de root. Por último, las aplicaciones de
necesidad de proteger los dispositivos móviles, especialmente copia de seguridad rara vez son accesibles para usuarios no
en un contexto empresarial, es importante, ya que los autenticados y, a menudo, tienen un uso limitado para análisis
dispositivos que entran y salen de la red empresarial, sin forense.
respuesta, introducen vectores de ataque atractivos para los
ciberdelincuentes y el ciberespionaje. Seung Jei Yang y col. (2015) demostraron un enfoque:
Las soluciones de administración de dispositivos móviles haciendo adquisición forense de medios de almacenamiento a
(MDM) pueden permitir el control centralizado de los través del mal uso de los dispositivos fi protocolos de
dispositivos que se utilizan en la empresa. Las empresas actualización rmware. Esto le dará acceso al almacenamiento
pueden entonces monitorear, controlar y administrar subyacente y la capacidad de volcar su contenido. Método:
dispositivos de manera sistemática, a través de proveedores de Desafortunadamente Este también Será insu fi ciente si los
dispositivos y proveedores de servicios. Samsung admite este Datos almacenados se cifran.
tipo de soluciones al ofrecer una función a la que se refiere
como modo Common Criteria o simplemente modo CC ( Seung Jei Yang y col. (2017) ha demostrado recientemente un
Samsung, 2017a ). El modo CC es una función de seguridad uso diferente para el dispositivo fi protocolos de actualización
diseñada para aumentar la protección del dispositivo contra el rmware. En lugar de adquirir almacenamiento, han
acceso no autorizado y, por lo tanto, puede representar un demostrado cómo adquirir RAM a través de este protocolo de
desafío adicional para las fuerzas del orden que intentan actualización. Esto se puede usar nuevamente para adquirir
adquirir datos de dispositivos con el modo CC habilitado. Un claves de cifrado que se utilizan para cifrar el almacenamiento,
gran desafío es que además de guardar los datos del usuario que residen en la RAM
CC modo niega el acceso al dispositivo fi mecanismo de en el momento de la adquisición de RAM.
actualización rmware, un método común utilizado por la Guido y col. (2016) demostraron Hawkeye, un agente para
policía para obtener acceso a los datos. realizar adquisiciones rápidas de dispositivos Android. Aunque
Este documento presenta los resultados de la ingeniería su objetivo es reducir la cantidad de datos necesarios para
inversa del modo CC y cómo las vulnerabilidades de seguridad transferir durante el proceso de adquisición, este es un ejemplo
descubiertas se pueden utilizar para eludir el modo CC para de un agente forense que debe inyectarse en el dispositivo para
una mayor adquisición forense. que funcione como se esperaba. Esto se hace instalando una
El resto del documento está organizado de la siguiente imagen de arranque personalizada en el dispositivo para
manera: La sección “ Trabajo relacionado y contribuciones ” facilitar la inyección de ojo de halcón. La instalación de esta
analiza el trabajo relacionado y cómo se relaciona nuestra imagen personalizada se realiza a través del dispositivo fi
contribución. La sección “ Modelo de arranque seguro de protocolo de actualización de rmware y el acceso a fi rmware
Samsung ” presenta el modelo de arranque seguro de Samsung. actualizar mecanismo es un requisito.
La sección “ Modo CC de Samsung y SBOOT ” describe las partes
relacionadas con el modo CC del arranque seguro de Samsung Como podemos ver, el acceso a un dispositivo de fi protocolo
y cómo esto se relaciona con el entorno de ejecución segura, de actualización rmware puede ser vital para la adquisición
TrustZone. La sección “ Desactivación no autorizada del modelo forense éxito. Por lo tanto, cualquier función que niegue este
CC ” trata sobre los ataques al modo CC. En la sección “ acceso limita las posibilidades de que las fuerzas del orden
Conclusión ” se discuten las implicaciones de nuestros fi adquieran datos de un dispositivo determinado. Modo CC es
hallazgos y ofrecemos nuestras conclusiones. pre-aplicación de la ley de acceso a la ventilación fi modo de
actualización de rmware en los dispositivos de Samsung.
Nuestra contribución es analizar y modo de eludir CC para
Trabajos y contribuciones relacionadas obtener acceso a la fi modo de actualización de rmware. Para
Ness COMPLETE-, también hemos incluido la discusión de un
La recuperación de datos de dispositivos móviles se puede ajuste de MDM, afectando también el acceso a la fi modo de
lograr leyendo datos del almacenamiento o de la memoria actualización de rmware.
volátil (RAM). Las dos fuentes de datos difieren tanto en cómo Nuestra ingeniería inversa del modo CC revela
se almacenan los datos como en cómo se pueden recuperar. Los vulnerabilidades de seguridad en el diseño y la implementación
datos en el almacenamiento a largo plazo a menudo se de estos mecanismos de seguridad, y demuestra cómo dichas
almacenan bien estructurados en sistemas de archivos , ya que vulnerabilidades de seguridad se pueden descubrir y utilizar en
deben poder ser leídos por diferentes sistemas operativos y adquisiciones forenses digitales.
otras herramientas. Las estructuras de datos en la RAM a Nuestros muestra la contribución que la policía tratando de
menudo están menos documentadas y los formatos son más adquirir datos de un dispositivo puede desactivar el modo CC y
volátiles, ya que solo necesita sobrevivir hasta el próximo obtener acceso a fi modo de actualización rmware, eliminando
reinicio del dispositivo. La RAM se vuelve a llenar cada vez que así la capa adicional de seguridad impuesta por
se reinicia el dispositivo. Modo CC . Deshabilitar el modo CC puede habilitar los métodos
existentes, pero también aumenta la superficie de ataque en
Nathan Scrivens y col. ( Scrivens y Lin, 2017 ) resumieron general, aumenta la posibilidad de descubrir nuevas
muchas de las opciones actuales para la adquisición forense de vulnerabilidades y métodos.
almacenamiento en dispositivos móviles Android. Según
Scrivens et al., Los principales op- ciones son de chip-off, Modalidad y metodología CC
 de-soldadura de almacenamiento para off-dispositivo de El modo CC está construido sobre el modelo de seguridad y
lectura, JTAG (Joint Prueba Action Group) de interfaz para el hardware de Android del teléfono, para aumentar la
en el circuito de lectura de almacenamiento, el enraizamiento y seguridad empresarial. Samsung ha puesto a disposición varios
soluciones de explotación para la recuperación de datos documentos de orientación para la evaluación de Criterios
rompiendo la seguridad del dispositivo, Android Debug Bridge Comunes para muchos de sus diferentes modelos de teléfonos (
(ADB) al utilizar las capacidades de depuración del dispositivo Samsung, 2017c ).
para la adquisición forense y , finalmente, las soluciones de Samsung proporciona una amplia gama de API de
respaldo recuperan datos a través de un usuario normal o administración para controlar un dispositivo Samsung (
rooteado Samsung, 2017b ). Estas API se pueden utilizar en soluciones
MDM de terceros. Para promover aún más el uso del modo CC
en soluciones MDM, Samsung ha puesto a disposición un APK
1 Con la palabra " ataques " , en el contexto de este artículo, nos referimos del modo Common Criteria ( Samsung, 2017a ). Este paquete de
a: explotar vulnerabilidades con fines de adquisición de datos forenses por aplicaciones de Android
parte de las del orden.

S62 G. Alendal y col. / Investigación digital 24 (2018) S60 e S67

(APK) se instala en el dispositivo y establece una serie de lenguaje de scripting, con la ayuda del marco del ensamblador
políticas y configuraciones de seguridad predeterminadas. Este de Keystone ( equipo de Keystone, 2017 ) para crear código ARM
APK está destinado a evaluadores y administradores de TI, para binario para ser ejecutado como parte de la explotación.
probar las funciones del modo CC de Samsung. Samsung ofrece Nuestro objetivo era poder evadir o desactivar el modo CC para
una larga lista de teléfonos compatibles, por ejemplo, el acceder al modo ODIN.
Samsung Galaxy S6, con el nombre de modelo SM-G920F y el
Samsung Galaxy S7 Edge, con el nombre de modelo Modelo de arranque seguro de Samsung
SM-G935F . Se desconoce a los autores Qué requisitos son
necesarios para un modelo particular para ser compatibles, El código que se ejecuta el modo de ODIN, y por lo tanto fl
pero para bloquear el acceso al fi modo de actualización incineración fi rmware en los dispositivos de Samsung, se
rmware, el gestor de arranque de modelos compatibles debe encuentra en el gestor de arranque de los dispositivos de
tener código para manejar este bloqueo. Es el gestor de Samsung. Por tanto, el cargador de arranque debe ser capaz de
arranque que implementa el fi modo de actualización de desactivar el acceso al de ODIN cuando el modo de CC está
rmware. activado en el dispositivo, con el fin para el modo de CC Para
desactivar fi actualizaciones modo rmware, por ejemplo,
La política y la configuración establecida por el APK del diseñado para el control de paso lateral centralizado. Para
modo CC son la base para las pruebas realizadas en este comprender mejor cómo funciona este mecanismo, a
documento. Cuando nos referimos al modo CC, nos referimos a continuación se presentan algunos antecedentes sobre el
la configuración establecida por el APK del modo CC. Nuestro modelo de arranque seguro de Samsung, aplicable a
dispositivo de prueba principal fue un Samsung Galaxy S7 Edge dispositivos que utilizan Exynos SoC.
(SM-G935F) con la versión de firmware Para mantener la seguridad y la confianza en el código que
G935FXXS1DQGA_G935FNEE1DQF3_NEE . 2 se ejecuta en los dispositivos, Samsung utiliza un modelo de
Una característica crucial del modo CC es la capacidad de arranque seguro ( Samsung, 2017d ), en el que se firma todo el
permitir que sólo Firmware Over The Air (FOTA) fi rmware código que se ejecuta desde el encendido hasta que se ejecuta
actualizaciones. Esto es para proteger contra un atacante con un sistema Android completo. Esto incluye la integridad del
acceso físico al dispositivo, se intenta instalar no autorizada fi TrustZone y el procesador de banda base, que maneja la
rmware en el dispositivo. La actualización de fi rmware de esta mayoría de las funciones de radio. Por tanto, la seguridad de los
forma en dispositivos Samsung se realiza mediante lo que se cargadores de arranque es fundamental para la integridad del
denomina modo ODIN. El modo de CC tanto en modo ODIN dispositivo. Nilo Redini y col. (2017) exploró las
bloque y cualquier intento de iniciar el unof fi imagen de vulnerabilidades tanto en el diseño como en la implementación
arranque cial ya almacenada en el dispositivo. de cargadores de arranque para una variedad de dispositivos, y
Otras características del modo Samsung CC y Common enfatizó la importancia de un arranque seguro al demostrar
Criteria en general no se discutirán más, ya que estas varios ataques. A simpli fi modelo de Arranque ed utilizado por
características no in fl uyen en el bloqueo del modo ODIN. los Dispositivos Samsung Exynos es Espectáculo en la Fig. 1 .
Dispositivos de Samsung VIENEN EN DIFERENTES Esto muestra cómo se inicia la ejecución en BootROM y
Estafadores hardware fi Configuraciones, Donde continúa a través del proceso de arranque hasta el kernel de
sistema-en-un-chip de (SoC) implementaciones de Qualcomm Android.
(POR EJEMPLO Snapdragon) y Samsung (Exynos) hijo los mas
comunes. Aunque los modelos de teléfono comparten el mismo Samsung proporciona una descripción genérica de la
nombre, como Samsung Galaxy S7, son muy diferentes, por seguridad de su plataforma ( Samsung, 2017d ). Esto describe
ejemplo, en componentes de hardware y código de cargador de que la cadena de firmas se basa en la clave de inicio seguro de
arranque. En este documento solo nos centramos en los Samsung, SSBK, que se utiliza para firmar componentes de
dispositivos Samsung basados en las variantes Exynos SoC. inicio ejecutables aprobados por Samsung. La parte pública de
Ejemplos de dispositivos con SoC Exynos son Samsung Galaxy esta clave se almacena en el hardware del teléfono en el
S6 (modelos SM-G920F / SM-G925F ) y Samsung Galaxy S7 momento de la fabricación y no cambiará durante la vida útil
(modelos SM-G930F / SM-G935F ). del dispositivo. BootROM lo utiliza cuando se enciende el
El cargador de arranque de Samsung aplica el acceso al dispositivo. Como se ve en la Fig. 1 , BootROM se asegura de que
modo ODIN. El cargador de arranque es parte del inicio seguro todo el código ejecutable obtenido del almacenamiento durante
del dispositivo y es el código nativo responsable de iniciar el el arranque esté firmado por Samsung. El arranque de un
dispositivo. En los modelos estudiados con Exynos SoC, el gestor dispositivo con este modelo comienza con el cargador de
de arranque responsable del modo ODIN a menudo se arranque principal, cargado desde la memoria de sólo lectura
denomina SBOOT. SBOOT se crea a partir del código de (ROM). Este cargador de arranque primario carga los siguientes
propiedad de Samsung, y la documentación y el código fuente cargadores de arranque, el cargador de arranque 1 (BL1) y el
no están disponibles públicamente. Hemos analizado cómo el cargador de arranque 2 (BL2) desde el almacenamiento, por
gestor de arranque seguro sabe que el modo CC está habilitado ejemplo, fl ash, a la RAM, verifica la firma y avanza la ejecución
y cómo se utiliza para limitar el acceso a determinadas un BL1. BL1 llevará a cabo sus tareas, a menudo relacionadas
funciones. También hemos analizado la seguridad del con la inicialización del hardware, y avanzará
almacenamiento de este modo CC con fi guración, así como la
forma SBOOT puede cambiar la con fi guración o el modo de CC
sólo tiene que desactivar. Este SBOOT hojas no sólo es
responsable de hacer cumplir la con fi guración, sino también
de cambiar el ajuste.
 Los detalles de diseño e implementación de muchas
características de seguridad generalmente no están disponibles
y, por lo tanto, la comunidad de investigadores puede dejar sin
explorar muchas de esas características. Para poder analizar la
aplicación del modo CC y cómo se bloquea el modo ODIN,
aplicamos ingeniería inversa a SBOOT con técnicas de análisis
tanto estáticas como dinámicas. Con acceso al fi rmware para
nuestro dispositivo de prueba, realizamos ingeniería inversa
del código binario SBOOT. La mayor parte del esfuerzo de
ingeniería inversa estática se realizó con la herramienta IDA
Pro de Hex-Rays ( Ilfak Guilfanov, 2017 ). También
desarrollamos nuestro propio exploit basado en la
vulnerabilidad SBOOT revelada en un blog de seguridad de
Nitay Artenstein (2017) . Utilizamos esta vulnerabilidad como
una herramienta para llevar a cabo un cabo análisis más
dinámico de cómo se aplica y se utiliza para proteger contra el
modo CC no autorizadas fi actualizaciones rmware. Nuestro
exploit está completamente desarrollado usando Python

2 G935FXXS1DQGA_G935FNEE1DQF3_NEE.zip SHA-1: 67CA63BCAF53C9D48-Fig. 1. Descripción general del modelo de arranque seguro de Samsung desde BootROM

A5D5DF43A8F5E56544081AC. núcleo.

G. Alendal y col. / Investigación digital 24 (2018) S60 e S67 S63

ejecución a BL2. BL2 es un gestor de arranque más complejo, la configuración de prueba , el modo CC debe estar habilitado
con una base de código más grande, que a su vez carga y en el teléfono. Este modo, una vez habilitado, aplicará el cifrado
verifica la firma del kernel de Android antes de avanzar en la validado por FIPS , deshabilitará la conectividad USB en el
ejecución. Como fi etapa final, el kernel de Android y carga el modo de recuperación y solo actualizaciones de firmware por
sistema operativo completo que permite a todas las funciones aire (FOTA) en el sistema. El APK del modo de criterios comunes
que tiene. de Samsung ( Samsung, 2017a ) habilitará el modo CC en
Si todas estas etapas del cargador de arranque mantienen la cualquier modelo compatible, con fines de prueba. Solo nos
integridad firmada de la clave SSBK, Samsung se refiere a esto centraremos en las partes del modo CC que opinan a SBOOT. El
como arranque seguro. Tenga en cuenta que Samsung ajuste del modo CC que afecta a SBOOT está activado o
distingue de arranque de confianza, que también incluye la desactivado.
protección Rollback (RP), la prevención de la " degradación " de Después de instalar el APK y habilitar el modo CC, podemos
cualquier código ejecutable para de fi cial, pero vulnerable, las comenzar a investigar cómo esto afecta a SBOOT y cómo SBOOT
versiones anteriores de los gestores de arranque o el sistema impone el bloqueo del modo ODIN. Hay dos formas de
operativo Android. actualizar el fi cerámica RM- en nuestros dispositivos de
Tenga en cuenta que Samsung no prohíbe la instalación de prueba; por aire a través de FOTA o con acceso físico a través de
kernels de Android no oficiales , no firmados por Samsung. Sin ODIN. Bloquear el modo ODIN es una parte crucial del modo
embargo, esto se considera una manipulación indebida del CC, ya que más adelante veremos que si se nos da acceso al
dispositivo y, en consecuencia , se configurará un fusible de modo ODIN, simplemente podemos desactivar el modo CC por
manipulación programable (eFuse) de una sola vez . Este completo. Se espera que sea más dif fi culto para un atacante
fusible no se puede desarmar y el dispositivo se marca de aquí para instalar no autorizadas fi actualizaciones rmware a través
en adelante como " Garantía nula " . Este fusible a menudo se de la FOTA, ya que esta es una característica en línea con la
denomina Bit de garantía KNOX ( Kanonov y Wool, 2016 ) y es comunicación segura a Samsung fi servidores rmware.
una forma patentada de Samsung de marcar el dispositivo Con una combinación de ingeniería inversa estática de
como manipulado. Samsung puede evitar la instalación de tales SBOOT e ingeniería inversa dinámica utilizando un exploit
kernels de Android no oficiales si la Protección de SBOOT, hemos analizado cómo se ve afectado SBOOT al
restablecimiento de fábrica (FRP) está configurada en el habilitar el modo CC, cómo se almacena esta configuración y
dispositivo. FRP es una configuración que se habilita, por cómo atacarla para deshabilitar el modo CC. Nuestro análisis
ejemplo, si el usuario agrega una cuenta de Google al sistema. muestra que la configuración del modo CC se almacena en fl
FRP evitará la instalacion de unof fi cial fi rmware ash, en una partición de datos llamada PARAM.
Actualizaciones, Pero No negara el acceso al Modo ODIN.

En este artículo nos referiremos a BL1 y BL2 como SBOOT.

SBOOT Es La fi código Cargado from primera grabable De La partición PARAM
Almacenamiento Y Por Lo Tanto Puede Ser actualizado Como
parte de Lo que sé refiere el menudo una de Como fi rmware El almacenamiento de un dispositivo Android se divide en
Actualizaciones. Las actualizaciones de firmware para varias particiones lógicas, donde los datos del sistema y del
dispositivos Samsung suelen ser archivos grandes que pueden usuario son los más importantes. La fi contiene en primer lugar
actualizar diferentes partes del entorno de código de Samsung, los archivos de Android (OS) del sistema operativo y el segundo
como el sistema operativo Android, el procesador de banda contiene la mayor parte de los datos del usuario. Otra partición,
base o los cargadores de arranque SBOOT. Cualquier la partición PARAM, es una partición lógica bastante pequeña
actualización del SBOOT se incluirá en un archivo llamado que contiene algunas imágenes JPG utilizadas por SBOOT, por
sboot.bin, por lo que para analizar el código ejecutable que ejemplo, el logotipo de inicio de Samsung Galaxy que se
pertenece a SBOOT, necesitamos analizar el archivo sboot.bin . muestra cuando el dispositivo está encendido. Además, hay un
Como se ve en la Fig. 1 , SBOOT es una parte crucial del modelo archivo , adv-env.img (Ver Tabla 1 ), que también contiene
Samsung Secure Boot. parámetros enviados al kernel de Android cuando SBOOT pasa
Kanonov y col. ( Kanonov y Wool, 2016 ) analizaron y la ejecución al kernel de Android después de que SBOOT ha
encontraron debilidades en la seguridad de los contenedores cargado y verificado la firma del kernel de Android. . La
seguros Samsung KNOX, y también describieron el proceso de partición PARAM se actualiza mediante actualizaciones de
arranque seguro, relacionado con la seguridad de los firmware, con actualizaciones en el archivo param.bin, que
contenedores KNOX. También analizan otras características de forma parte de los archivos de firmware.
seguridad importantes, como las protecciones en tiempo de
ejecución, llamadas TIMA, y por ejemplo, su uso en la Sin embargo, PARAM también es un almacenamiento para
certificación de un dispositivo. La certificación del dispositivo algunos otros ajustes importantes. Nuestro análisis muestra que
 tiene como objetivo probar la autenticidad e integridad de las en los últimos bloques de 512 bytes de la partición PARAM,
medidas y políticas de seguridad. Samsung almacena valores importantes como el modo CC,
SBOOT es responsable de una variedad de tareas antes de
cargar y ejecutar el kernel de Android. Estas tareas son parte
tabla 1
del arranque seguro / confiable e incluyen la carga de
Variables de entorno SBOOT, almacenadas en adv-env.img.
aplicaciones dedicadas de TrustZone, también conocidas como
trustlets. Un trustlet es un pequeño y dedicado aplicación Índice Nombre Configuración de ejemplo
creada para resolver un especi fi c, tarea a menudo sensibles, 0 REBOOT_MODE 0
1 SWITCH_SEL 3
como la gestión de derechos digitales (DRM). Los Trustlets se
2 NIVEL DE DEPURACIÓN 18505
ejecutan en TrustZone. 3 SUD_MODE 0
TrustZone es un entorno de ejecución independiente, 4 DN_ERROR 0
compatible con el hardware, que divide cada núcleo de 5 CHECKSUM 3
procesador en dos " mundos " separados . A menudo nos 6 ODIN_DOWNLOAD 1
7 CÓDIGO DE VENTA 0
referimos a estos diferentes entornos de ejecución como el 8 MODO DE SEGURIDAD 1526595585
mundo normal y el mundo seguro; TrustZone. SBOOT no forma 9 NORMAL_BOOT 0
parte de TrustZone y se ejecuta en un mundo normal. Cuando 10 CP_DEBUG_LEVEL 22015
SBOOT termine de ejecutar sus rutinas de arranque necesario, 11 USERBOOT_MODE 0
12 DIAG_MODE 0
cargará y ejecutará el kernel de Android. El kernel de Android
13 CHARGING_MODE 48
también se ejecuta en el mismo mundo normal. El TrustZone 14 INT_RSVD14 0
no lo hace en fl uencia la entrada en vigencia de modo CC 15 LCD_RES 1
durante el arranque y por lo tanto se quedan fuera de dieciséis CMDLINE consola ¼ ram loglevel ¼ 4
ulteriores discusiones en este documento. 17 BARCODE_INFO (nulo)
18 KEEP_LOG (nulo)
     
Mirando en las diferentes etapas realizadas por SBOOT,
podemos analizar la interacción con el modo CC con fi guración
y cómo esto se aplica. Esto se explicará en la siguiente sección.

Modo Samsung CC y SBOOT

La Guía del administrador de criterios comunes de

Samsung, sección 4.3.2.2 ( Samsung, 2017 ), establece que para
colocar el dispositivo en la

S64 G. Alendal y col. / Investigación digital 24 (2018) S60 e S67

Configuración de MDM, el estado actual del sistema ( “ Samsung

De fi cial ” o “ Custom ” ) y fl ags nombrados AFW y UCS. La
forma en que SBOOT aborda estas configuraciones es contar
hacia atrás en el número de 512 bloques desde el final de la
partición PARAM. Vea la figura 2 .
Para acceder a la configuración del modo CC en nuestro
dispositivo de prueba principal, SBOOT hace referencia al
bloque PARTITIONSIZEinBLOCKs (PARAM) ␣ - ␣ 4 en la partición
PARAM. Este es un desplazamiento estático en el código SBOOT,
pero puede cambiar con diferentes versiones del binario
SBOOT. El modo de CC con fi guración es de 64 bytes de datos
cifrados almacenados en el inicio del bloque de referencia.
Estos 64 bytes se leen y descifran con una función que
llamamos S_CC_decrypt . 3 Como la función S_CC_decrypt solo
toma dos argumentos; el búfer de entrada con el 64 cifrado
Bytes del modo CC y un búfer de salida inicializado en cero
para recibir el contenido descifrado, asumimos que el material
clave necesario para el descifrado está contenido en, o
recuperado por, la función misma. Mirando más de cerca el
S_CC_decrypt , podemos ver que usa un cifrado AES de caja
blanca, donde la clave AES no está expuesta durante el cifrado
o descifrado ( Chow et al., 2003 ). Esto significa que la función
S_CC_decrypt puede descifrar los datos del modo CC sin exponer
la clave en código estático o análisis dinámico en tiempo de
ejecución. La función es un oráculo de descifrado. SBOOT
también contiene el correspondiente S_CC_encrypt , aunque
nuestro análisis no hace fi nd esta función para ser llamado por
el binario SBOOT. Resulta que un Android nativo
library, /system/lib64/libSecurityManagerNative.so coinciden con
los dos oráculos de cifrado / descifrado WAES, descubierto
también por Andre ??? Moulu (2016) . Dado Que No SBOOT
Parece Llamar S_CC_encrypt , ESTO nos Lleva un Pensar Que El
Modo CC con fi gu- ración es Única Escrita por el entorno
Android y no por el Gestor de Arranque SBOOT. SBOOT
simplemente consulta la con fi guración. Teniendo en cuenta
estos oráculos WAES, podemos leer y escribir libremente la CC
con fi g tanto de la SBOOT y el medio ambiente de Android, si Fig. 2. Partición PARAM.
controlamos la ejecución. Este también será el caso si tenemos
otros medios de acceso de escritura a la partición PARAM.
Entonces, si la variable MDM global en SBOOT se establece
Los datos del modo CC descifrados contienen los caracteres en 1 o 2 , el modo MDM se considera habilitado y esto también
mágicos timg en los bytes 0e3 y los caracteres NOCC ( CCON lee afectará la forma en que SBOOT permite el acceso al modo
little-endian) o FFOC ( COFF lee little-endian) en los bytes 4e7 , lo ODIN.
que indica que el modo CC está activado o desactivado SBOOT aplicando el modo CC
respectivamente.
El ajuste del modo de CC se lee al principio de la ejecución S_CC_MODE_isSet se llama en tres ubicaciones diferentes en
de SBOOT y una variable mundial fl de AG se establece para SBOOT; cuando el teléfono intenta ingresar al modo ODIN,
indicar el modo CC con fi guración. Esta fl ag se puede consultar cuando el teléfono intenta arrancar un kernel sin firma o sin
a través de una función que llamamos S_CC_MODE_isSet , que firma, y cuando el SBOOT envía variables de estado a
devuelve verdadero si el modo CC está activado. TrustZone. Es la fi primero de estos tres, que es crucial para
Otra configuración que se supone que es importante para los denegar el acceso al modo de ODIN.
dispositivos administrados por MDM es la configuración de MDM La decisión de cuándo durante el proceso de arranque
. Este ajuste no lo establece Samsung verificar el modo CC es crucial para el éxito de denegar el
Modo CC APK. Sin embargo, suponemos que las soluciones acceso al modo ODIN. Dado que el gestor de arranque es
MDM utilizan esta configuración de forma activa y, por lo tanto, responsable de inicializar el dispositivo y de las actualizaciones
incluye esta configuración y su efecto en el modo CC en nuestro de firmware del sistema, también debe comprobar si hay
análisis. La configuración de MDM se almacena en bloque errores potenciales. Estas comprobaciones de errores se
PARTITIONSIZEinBLOCKs (PARAM) ␣ - ␣ 3 en la partición PARAM. entremezclan con comprobaciones relacionadas con la
Es un entorno sin cifrar en la fi RST 32 bytes en el bloque seguridad, como la comprobación del modo CC. Esto hace que
correspondiente. Estos bytes se leen durante el arranque, como se entremezclan los controles de seguridad vulnerables a los
en el modo CC, y una variable global correspondiente a la cambios en la ruta de ejecución causados por errores, como
configuración de MDM en PARAM. La variable global MDM especí fi c errores pueden hacer el cambio de ruta de ejecución,
puede tener tres valores diferentes, donde 1 y 2 parecen de manera que ciertos controles de seguridad nunca se lleva a
significar que MDM está en uso. cabo. Nuestro análisis muestra que esta situación puede surgir
El siguiente pseudocódigo describe los diferentes valores de para el modo CC. La figura 3 muestra el pseudocódigo de la
bytes en el bloque MDM y la configuración de MDM función responsable de habilitar el modo ODIN,
correspondiente: S_boot_enter_download_mode . La función
La configuración de MDM se establece en 1 si el bloque [30] ¼ ¼ 2 S_boot_enter_download_mode se llama desde varias ubicaciones
&& block en el proceso de arranque SBOOT. Verificará si debe ir al modo
[31] ¼ ¼ 6 && bloque [3] ¼ ¼ 8 && bloque [7] ¼ ¼ 8. ODIN. Si es así, llamará a una función, S_USB_mode_enter , que
La configuración de MDM se establece en 2 si el bloque [30] ¼ ¼ 2
&& block
[31] ¼ ¼ 6 && bloque [3]! ¼ 8 && bloque [7] ¼ ¼ 8.
La configuración de MDM se establece en 3 si bloque [30] ¼ ¼
2 && bloque [31] ¼ ¼ 6 && bloque [3] ¼ ¼ 8 && bloque [7]! ¼ 8.

3 Todas las funciones mencionadas por los autores son pre fi jos con S_ .
Los nombres de las funciones provienen de suposiciones fundamentadas
realizadas a partir de cadenas de mensajes de error a las que se hace
referencia dentro de las funciones.

G. Alendal y col. / Investigación digital 24 (2018) S60 e S67 S65

S boot entra en modo de descarga ( razón int ) { Tabla 2

1
si (motivo == 1) { Valores de las variables REBOOT_MODE.
2
3 S dibujar imagen ("advertencia L. Jpg"); Nombre Valor
4 si (S usuario cancelar ()) { REBOOT_MODE_NONE 0
5 S reiniciar dispositivo (); REBOOT_MODE_DOWNLOAD 1
6 } REBOOT_MODE_UPLOAD 2
REBOOT_MODE_CHARGING 3
7 más {
REBOOT_MODE_RECOVERY 4
8 S dibujar imagen ("descargar L. Jpg"); REBOOT_MODE_FOTA 5
9 } REBOOT_MODE_FOTA_BL 6
10 } REBOOT_MODE_SECURE 7
11 más { REBOOT_MODE_FWUP 9
12 si (razón == 6) { REBOOT_MODE_EM_FUSE 10
   
13 S dibujar imagen ("error de descarga L. Jpg");
14 S modo USB ingrese (0);
15 } Durante el arranque normal, SBOOT llama una función
16 S dibujar imagen ("descargar L. Jpg"); bastante compleja, llamamos S_boot_set_boot_mode , que decide
17 si (razón == 3) { qué modo de arranque elegir para el dispositivo. Esto se basa
18 // Modo SUD. . en numerosas comprobaciones de hardware, estado de la
19 } batería, variables de entorno, etc. Durante estas pruebas hay
20 si (razón! = 4) { una llamada a una función, S_s5p_check_download , que
21 goto error ();
devolverá un valor diferente de 0 si debería ir al modo ODIN /
22 }
descarga y devolverá 0 si no debería ir al modo de descarga.
23 }
Tomando la ruta en la que S_boot_set_boot_mode devuelve 0 ,
24 //. . .
25 si (S CC MODE isSet ()) { sin modo de descarga / ODIN, nos lleva a una llamada a una
S screenp ri nt ( función que llamamos S_env_get , llamada con el valor entero
26
27 ”LA DESCARGA ESTÁ BLOQUEADA POR EL MODO de DN_ERROR de la Tabla 1 . Esta llamada devuelve el valor
CC”); entero de la variable de entorno DN_ERROR . Si está establecido,
28 S dormir (1 0 0 0); hay una llamada a la función ya discutida
S po we ro ff de vice (); S_boot_enter_download_mode , con el valor de parámetro de 6 .
29
30 } Como ya analizamos S_boot_- enter_download_mode y
31 S modo USB ingrese (0); localizamos un bypass de la verificación del modo CC si el
32 } parámetro de entrada es igual a 6 , ahora tenemos una manera
de omitir la verificación del modo CC. Simplemente podemos
Fig. 3. Simpli fi ed seudo código de S_boot_enter_download_mode. establecer el valor de entorno DN_ERROR en un valor
distinto de cero y reiniciar el dispositivo. El dispositivo entrará
aplicar la con fi guración en el dispositivo y cambiar al modo de en modo ODIN, incluso si el modo CC está habilitado. Esto nos
ODIN. S_USB_mode_enter se puede llamar con un parámetro, parece como un modo de ODIN de emergencia, en el que el
donde 0 significa ODIN / modo de descarga. gestor de arranque está requiriendo una fi actualización
 El propio S_boot_enter_download_mode recibe un parámetro, rmware como el resultado de un fallido fi actualización rmware
razón ( Fig. 3 , línea 1), que indica la razón para ingresar al . La Fig. 4 muestra la pantalla que se muestra en un Galaxy S7
modo ODIN. La función actúa en consecuencia según el valor Edge ( SM-G935F ) cuando está en este modo.
de este parámetro. El pseudocódigo muestra que
S_USB_mode_enter se llama desde dos ubicaciones diferentes.
La llamada en la línea 31 solo se alcanza si la llamada a la
función S_CC_MODE_isSet en la línea 25 devuelve falso . Si Modo MDM
S_CC_MODE_isSet devuelve verdadero , SBOOT imprimirá “ LA
DESCARGA ESTÁ BLOQUEADA POR EL MODO CC ” en la Incluimos una discusión sobre el modo MDM para
pantalla del dispositivo y finalmente apagará el dispositivo. La completar, ya que se espera que esta configuración sea
otra llamada a S_USB_mo- de_enter se encuentra en la línea 14 , utilizada por algunas soluciones MDM que admiten dispositivos
y esta llamada no está precedida por una llamada a Samsung Exynos. El modo MDM también afecta la forma en
S_CC_MODE_isSet , lo que significa que esta llamada parece que SBOOT evita el acceso al modo ODIN. SBOOT accede a esta
ignorar si se establece algún modo CC. Entonces, si se llama a configuración a través de una función que llamamos
S_boot_enter_download_mode con el parámetro 6, el dispositivo S_MDM_MODE_isSet . Esta función devolverá verdadero ( 1 ) si
ingresará al modo ODIN, incluso si el modo CC está la variable MDM global es 1 o 2 . No parece hacer una
configurado. Dar marcha atrás a las personas que llaman distinción entre los dos. SBOOT llama a esta función desde tres
S_boot_enter_download_mode identi fi ca la situación en donde funciones diferentes; cuando en modo ODIN, cuando
esto sucede.
SBOOT tiene una tabla de variables de entorno,
almacenadas en el archivo adv - env.img de la partición
PARAM. Estos valores se enumeran en la Tabla 1 . Estos valores
son formas de en fl uyen en la ejecución de SBOOT y ya que se
almacenan en PARAM, sobreviven un reinicio del dispositivo.
Como ya se mencionó, algunos de estos también se transmiten
como parámetros al kernel de Android, pero la discusión de
estos está fuera del alcance de este artículo.
Un ejemplo es REBOOT_MODE , que indica a SBOOT qué
modo de arranque utilizar, donde el arranque normal ( 0 ), el
modo ODIN / descarga ( 1 ), el modo de carga ( 2 ) y el modo de
recuperación ( 4 ) son configuraciones de ejemplo. Consulte la
Tabla 2 para obtener una lista completa de los valores de
REBOOT_MODE .
Muchas de estas variables de entorno se comprueban
durante el arranque y una de ellas es interesante con respecto Fig. 4. Modo de descarga / ODIN de emergencia.
al modo CC; DN_ERROR .

S66 G. Alendal y col. / Investigación digital 24 (2018) S60 e S67

el arranque y para proporcionar la configuración de MDM a S_boot_enter_download_mode con el parametro 6 Y LUEGO

TrustZone. En el modo ODIN, SBOOT comprueba el modo MDM sobrescribir la partición PARAM de la Misma Manera Que se
y evitará la actualización del firmware a cualquier partición detalla en la Sección “ Modificación de la partición PARAM ”
que no sea SBOOT ( “ BOOT-LOADER ” ), si el modo MDM está Otra forma Podria ser parchear la Función S_CC_MODE_isSet
configurado. Entonces, podemos ver que mientras que el modo párr Que Siempre devuelva falso ya parcheando mar el Código
CC impide el acceso al modo ODIN, el modo MDM también se de Retorno a 0 o cambiando la variable global hace referencia a
verificará en el modo ODIN. 0 . Of this Manera Se Puede Pasar por alto el bloqueo de
SBOOT también comprueba el modo MDM durante el Arranque unof fi cial Y Granos sin sacrificar las exigencias, y el
arranque. Estas verificaciones se realizan antes de la Modo CC habilitadas fit no se INFORMO un TrustZone los antes
verificación del modo CC realizada en S_boot_- de arrancar el núcleo, en efecto Desactivar el Modo de CC en El
enter_download_mode , ya discutido en la Sección “ Samsung Sistema Android Arrancado.
Modo CC y SBOOT ”Las comprobaciones se realizan dentro de
la función llamada s5p_check_download , donde el SBOOT Si el modo MDM también está activado, esto también se
decide si debe llamar puede omitir simplemente estableciendo la configuración
S_boot_enter_download_mode . Tenga en cuenta que la llamada a global del modo SBOOT MDM en 0, lo que da como resultado
s5p_check_download se realiza antes de realizar la verificación que la función S_MDM_MODE_isSet siempre devuelva falso. Se
de la variable de entorno DN_ERROR , que solo se verifica si espera, como todos los cambios arbitrarios en el código SBOOT
s5p_check_download devuelve un valor distinto de cero , lo que y ejecución fl ujo dejará a todos los controles de seguridad
significa que no hay modo ODIN. Ya hemos visto en la sección “ realizados por ineficaces SBOOT.
Modo Samsung CC y SBOOT ” que establece la variable de
entorno DN_ERROR en un valor distinto de cero pondrá el
dispositivo en un modo ODIN de emergencia. Esta será la Configuración de DN_ERROR
misma situación incluso si se establece el modo MDM. Una
Diferencia Importante Es Que el Modo de Odin con Juego de Hemos visto el efecto de establecer la variable de entorno
Modo MDM Sólo permitira fi rmware Actualizaciones de la DN_ERROR en un valor distinto de cero en la sección " SBOOT.
partición SBOOT. Forzar el modo CC ". Esto ha sido probado a través de una
Como el modo MDM es una configuración no cifrada interfaz de consola proporcionada por SBOOT. Se puede
almacenada en la partición PARAM, cualquier borrado o acceder a esta consola con la ayuda de un conector USB
sobrescritura del bloque de configuración MDM restablecerá y personalizado y un convertidor simple serie RS232 a USB (
deshabilitará la configuración MDM en el dispositivo y, por lo Nitay Artenstein, 2017 ). Después de ingresar a la consola
tanto, ya no impedirá el acceso al modo ODIN. SBOOT, simplemente se puede escribir set env DN_ERROR 2
seguido de guardar env y reiniciar . Esto intentará reiniciar el
Deshabilitación no autorizada del modo CC dispositivo con un inicio normal, pero la variable de entorno
DN_ERROR distinta de cero forzará al dispositivo a un modo de
Según nuestro análisis de SBOOT, y la forma en que el descarga / ODIN de emergencia. Desde aquí podemos modificar
cargador de arranque aplica el modo CC para evitar el modo la partición PARAM como en el apartado “ Modificar la
ODIN / descarga, hemos encontrado tres ataques diferentes partición PARAM ” .
para desactivar el modo CC. 4 Todos los ataques han sido Veri fi
cado a través de pruebas de éxito en nuestro dispositivo de Si el modo MDM también está activo, el dispositivo seguirá
prueba. También discutiremos el efecto de una configuración ingresando al modo ODIN. Sin embargo, ya que el modo de
opcional de MDM, aunque esto no fue habilitado por el APK del MDM también se comprueba mediante el modo de ODIN
modo CC de Samsung. cuando fl incineración fi rmware, únicos cambios en el gestor
de arranque, SBOOT, están permitidas. Esto evitará este ataque.
Modificar la partición PARAM
Conclusión
Como se discutió en la sección “ La partición PARAM ” ,
podemos modificar la configuración del modo CC si tenemos En este artículo hemos demostrado con éxito cómo
acceso de escritura a la partición PARAM. Esto puede ser ya sea desactivar el modo de Criterios Comunes (CC) en dispositivos
por el acceso físico a la fl subyacente de almacenamiento de Samsung seleccionados. El efecto de deshabilitar el modo CC
cenizas, oa través de ODIN / modo de descarga. Dado el acceso aumenta la superficie de ataque del dispositivo y puede utilizar
de escritura PARAM, simplemente podemos cambiar la más en la adquisición forense. Esto abrirá el dispositivo por el
configuración del modo CC y cifrar la configuración con los mal uso de la fi protocolo de actualización rmware para el
oráculos de cifrado WAES desde SBOOT o / system / lib64 / almacenamiento o la adquisición directa de RAM, además de
libSecurityManagerNative.so . También podemos simplemente ambos con y sin signo fi actualizaciones rmware a través del
sobrescribir los bytes de datos del modo CC con cero bytes, con modo ODIN / descarga, dependiendo de la fábrica Restablecer
el mismo efecto. Así que simplemente fl reducción a cenizas los ajustes de protección y protección de Restitución en el
una acción param.bin a partir del correspondiente fi rmware dispositivo. Si uno usa el ataque de explotación SBOOT de la
actualizar modo de desactivación de CC archivará. sección " Explotación de SBOOT " , también podemos evitar
Si el modo de MDM también está presente, fl ADO DE PARAM fácilmente ambas defensas. Esto se debe a que el gestor de
acciones a través de ODIN modo denegado. Este no es el caso arranque SBOOT también aplica estas configuraciones de
con el acceso físico a la subyacente fl de almacenamiento de seguridad y, por lo tanto, se pueden cambiar / deshabilitar
cenizas, como sobrescribir el bloque de configuración MDM fácilmente.
MDM modo de desactivar.
Hemos encontrado y probado el efecto de varias debilidades
Explotación SBOOT en la aplicación del modo CC en nuestro dispositivo probado. El
uso de exploits para atacar SBOOT romperá la
Desde el gestor de arranque se encarga de leer y hacer cadena de confianza anclada en el proceso de arranque. Esto
cumplir el ajuste del modo de CC en la partición PARAM, romperá la confianza en todo el código que se ejecuta en el
cualquier ataque a la ejecución de fl ujo de SBOOT tendrá el mismo mundo normal en el procesador de aplicaciones de este
potencial de modo CC by-pass y habilitar el modo de descarga dispositivo. Con un ataque tan poderoso podemos reemplazar o
ODIN / . Basado en una vulnerabilidad descubierta por Nitay adaptar la mayoría de las funciones de seguridad de SBOOT.
Artenstein (2017) , hemos desarrollado un exploit Esto no es inesperado, pero enfatiza la necesidad de un gestor
completamente funcional para hacer que SBOOT ignore la de arranque seguro y una cadena de confianza.
configuración del modo CC. Una forma de hacer esto es que Como trabajo futuro, sugerimos probar estos ataques en
parchear el código de fl ujo de SBOOT a la llamada soluciones MDM reales utilizando la función de modo Samsung
CC y / o la configuración de MDM. El efecto en una solución
MDM después de deshabilitar el modo CC al cambiar o borrar la
4
No hemos considerado si alguna herramienta forense comercial admite la configuración del modo CC y / o la configuración de MDM en la
omisión del modo CC ni de qué manera. partición PARAM no se ha probado y podría dar lugar a otros
escenarios de ataque de interés forense.

G. Alendal y col. / Investigación digital 24 (2018) S60 e S67 S67

Nitay Artenstein, 2017. Explotación de S-boot de Android : Obtención de

Agradecimientos
código exec arbitrario en el cargador de arranque de Samsung (1/2).
http://hexdetective.blogspot.no/2017/02/
La investigación que condujo a estos resultados ha recibido exploiting-android-s-boot-Getting.html . (Consultado el 27 de julio de
financiación del programa IKTPLUSS del Consejo de 2017).
Redini, N., Machiry, A., Das, D., Fratantonio, Y., Bianchi, A., Gustafson, E.,
Investigación de Noruega, en el marco del proyecto de I + D Ars Shoshitaishvili, Y., Kruegel, C., Vigna, G., 2017. Bootstomp: on la seguridad
Forensica subvención 248094 / O70. de los cargadores de arranque en dispositivos móviles. En: 26º Simposio
de seguridad de USENIX (USENIX Security 17). Asociación USENIX,
Vancouver, BC, págs. 781 y 798. https: // www.
Referencias usenix.org/conference/usenixsecurity17/technical-sessions/presentation/redini .
Samsung, 2017. Documentación de orientación de Samsung Android 7 en
Andre ??? Moulu, 2016. Cómo bloquear el modo de descarga de Samsung
dispositivos Galaxy.
mediante una función no documentada de Aboot.
https://docs.samsungknox.com/CCMode/Adminguidev3_0.pdf . (Consultado
https://ge0n0sis.github.io/posts/2016/05/how-
el 7 de septiembre de 2017).
to-lock-the-samsung // download-mode-using-an-indocumented-feature-of-
aboot / . (Consultado el 30 de julio de 2017). Samsung, 2017a. Modo de criterios comunes Apk.
https://www.samsungknox.com/en/
Portadora, B., 2002. De fi nir digitales instrumentos de examen y análisis
article / common-criteria-mode . (Consultado el 28 de julio de 2017).
forenses. En t. J. Digit. Evid. 1 de 2003 .
Samsung, 2017b. Descripción general de las herramientas para
Chow, S., Eisen, PA, Johnson, H., Oorschot, PCV, 2003. Criptografía de
desarrolladores. https://seap.samsung.com/sdk . (Consultado el 27 de julio
caja blanca y una implementación aes. En: Artículos revisados del 9º
de 2017).
Taller internacional anual sobre áreas seleccionadas en criptografía.
Samsung, 2017c. Documentos de orientación para la evaluación de criterios comunes.
Springer-Verlag, Londres, Reino Unido, Reino Unido, págs. 250 y 270.
https: //
http://dl.acm.org/citation.cfm?id ¼ 646558.694920 .
support.samsungknox.com/hc/en-us/articles/115015114407 . (Consultado
Gar fi nkel, SL, 2010. forense digital de investigación: los próximos 10 años.
el 5 de enero de 2018).
Dígito. Investig. 7, S64 y S73. https://doi.org/10.1016/j.diin.2010.05.009 .
Samsung, 2017d. Seguridad de la plataforma.
https://doi.org/10.1016/j. diin.2010.05.009 .
http://developer.samsung.com/tech-insights/ knox / platform-security . (Consultado
Guido, M., Buttner, J., Grover, J., 2016. Imagen forense diferencial rápida de el 28 de julio de 2017).
dispositivos móviles. Dígito. Invertir. 18, S46 y S54. Scrivens, N., Lin, X., 2017. Análisis forense digital de Android: datos,
https://doi.org/10.1016/j.diin.2016.04.012 . extracción y análisis. En: Actas de la 50ª Conferencia de celebración de
http://www.sciencedirect.com/science/article/pii/S1742287616300457 . ACM Turing -China. ACM, Nueva York, NY, EE. UU. UU., Pág. 26.
Ilfak Guilfanov, 2017. Ida-Disassembler & Decompiler. https://doi.org/10.1145/3063955.3063981 , 1 e 26:10. http: //
https://hex-rays.com/ . (Consultado el 27 de julio de 2017). doi.acm.org/10.1145/3063955.3063981 .
Kanonov, U., Wool, A., 2016. Contenedores seguros en Android: el caso de Yang, SJ, Choi, JH, Kim, KB, Chang, T., 2015. Nuevo método de adquisición
estudio de Samsung Knox. En: Actas del 6º Taller sobre Seguridad y basado en fi protocolos de actualización de rmware para teléfonos
Privacidad en Teléfonos Inteligentes y Dispositivos Móviles. ACM, Nueva inteligentes Android. Dígito. Invertir. 14, S68 y S76.
York, NY, EE. UU. UU., Págs. 3 y 12. https://doi.org/ 10.1145 / https://doi.org/10.1016/j.diin.2015.05.008 .
2994459.2994470 . http://doi.acm.org/10.1145/2994459.2994470 . http://www.sciencedirect.com/science/ article / pii / S1742287615000535 .
Equipo de Keystone, 2017. Keystone: el ensamblador definitivo. http: las Actas de la Decimoquinta Conferencia Anual DFRWS.
//www.keystone- engine.org/ . (Consultado el 28 de septiembre de 2017). Yang, SJ, Choi, JH, Kim, KB, Bhatia, R., Saltaformaggio, B., Xu, D., 2017.
Adquisición en vivo de los datos de la memoria principal de teléfonos
inteligentes y relojes inteligentes Android. Dígito. Invertir. 23, 50 y 62.
https://doi.org/10.1016/j.diin.2017.09.003 .