Registros de fallos y ofuscación: Un curso intensivo

Depurar un fallo en tiempo de ejecución puede ser un proceso doloroso. Cuando una aplicación de iOS falla en entornos realesEl dispositivo solo dispone de información sobre las direcciones de memoria y los desplazamientos del proceso en ejecución en el momento del fallo. Esta información se presenta como un seguimiento de pila, una lista de llamadas a métodos en orden cronológico de ejecución que indica dónde se produjo el fallo. Los seguimientos de pila pueden tener distintos niveles de detalle, y existen mecanismos para ayudar a los desarrolladores a sacarles el máximo partido. 

Sin embargo, un error común entre los ingenieros de seguridad es creer que una aplicación reforzada dificulta el uso de herramientas comunes de depuración en campo (como Firebase Crashlytics), lo que complica aún más la comprensión de los fallos de la aplicación. Esto no tiene por qué ser así; una aplicación puede tener una seguridad sólida y, al mismo tiempo, registros de fallos útiles y relevantes. ¿Cómo lo conseguimos? 

Para facilitar la obtención de registros de fallos legibles para las apps de iOS en producción, los desarrolladores pueden utilizar archivos dSYM. Estos archivos contienen información de símbolos para la depuración y Xcode los genera durante el proceso de compilación. Analizaremos el contenido de estos archivos, su utilidad y cómo... Digital.ai Application Security Los productos se integran con este mecanismo para hacer posible la depuración de su aplicación segura. 

Veamos un ejemplo utilizando nuestro software de código abierto. Despachador de trabajos aplicación para iOS  

¿Qué incluye un paquete dSYM? 

Un paquete dSYM (abreviatura de símbolos de depuración) contiene símbolos e información de líneas de código fuente sobre tu aplicación iOS/tvOS/macOS. Xcode los genera cuando el "Formato de información de depuración" está configurado como "DWARF con archivo dSYM" para la configuración de compilación que estés utilizando:

Ahora bien, quizá se pregunten: ¿Por qué querríamos tener todos nuestros símbolos en un archivo aparte en lugar de dentro de la propia aplicación? La razón principal es la portabilidad para la depuración. Se puede compilar una aplicación y depurarla en otra máquina sin necesidad de los archivos objeto utilizados para su compilación. dSYM también permite depurar las versiones de lanzamiento de la aplicación, lo que supone un gran ahorro de tiempo.  

Ahora que hemos presentado qué es dSYM, y un poco por qué es importante, abramos el archivo .xcarchive que acabamos de crear y echemos un vistazo al paquete 'Job Dispatcher.app.dSYM' que aparece a continuación.

Job Dispatcher solo tiene un paquete para la aplicación principal, pero se pueden generar más si su proyecto crea bibliotecas o marcos adicionales durante el proceso de compilación. 

¿Qué contiene realmente el paquete dSYM? Si hacemos clic con el botón derecho en el paquete y seleccionamos «Mostrar contenido del paquete», podemos ver lo siguiente:

Tél 'Archivo Info.plist listo para importar tan solo contiene metdatos sobre el bdesenrollarse y no va muy útil. BambosTrabajos Dispatcher.yml' archivo y el 'Despachador de trabajos Mach–O depuración listo para importar que no contengo símbolo nombres y ubicaciones y son lo que nos importa. Vamos first abrir la 'Trabajos Dispatcher.yml' listo para importar (Imagen recortada por brevedad):

Aquí podemos ver una lista de propiedades para cada símbolo en el binario. Por ejemplo, 'tamaño'. se correlaciona con el tamaño del puntero (todos estos son símbolos de 64 bits), 'nombre del símbolo corresponde al nombre del símbolo, 'symBinAddr' es donde el símbolo existe en el propio sistema binario, y 'symSize' es el tamaño de la función o del objeto de datos. Este archivo se centra en la información de reubicación, que es una parte importante de la arquitectura AArch64, pero no profundizaremos en ello aquí.  

Ahora veamos el archivo 'Job Dispatcher' en la carpeta DWARF. Este archivo binario contiene información de depuración detallada de todos los símbolos de la aplicación que creamos (como puede ver, el nombre del archivo DWARF y de la aplicación coinciden). Podemos ejecutar el comando 'dwarfdump' para obtener un volcado legible de la información que contiene. Veamos... autenticar símbolo:

Un par de propiedades destacables son las Archivo de declaración DW_AT y Línea de declaración DW_AT, lo cual nos dice que el autenticar La función se definió en el archivo 'LoginFunc.m' en la línea 13. Otra propiedad es la Tipo DW_ATEsto nos indica el tipo de la función (que en este caso es un valor booleano). Cada símbolo tiene una sección similar en el archivo DWARF con información que explica qué es y dónde se definió, entre otras cosas. 

Aunque el contenido del paquete dSYM puede resultar bastante complejo de analizar, no es necesario que todo el mundo lo sepa para utilizarlo. A continuación, veremos qué hace dSYM realmente al intentar depurar un fallo en tiempo real. 

dSYM en acción 

Veamos el poder de dSYM en acción forzando un fallo en Job Dispatcher. Podemos hacerlo asignando un valor a un puntero nulo en las líneas 14 y 15 del archivo. autenticar función:

Cuando Ejecutamos la aplicación confuera un aasociado dSYMLa aplicación falla, y Obtenemos un seguimiento de pila como este:

Ahora, Es Sin duda es posible depurar una aplicación. utilizando esta información. Cada El marco de pila contiene información sobre la dirección del fallo. y los desplazamientos del menú (bastante inútil) Nombre del símbolo donde se produce el fallo. Sin embargoParaComprender este seguimiento de pila requieres análisis profundo del binario en sí y proporciona casi nada penetración cobren ¿Qué parte del código fuente está causando el problema?. Compare este resultado con un registro de fallos con dSYM Avisos estará disponible:

Cada marco de pila aún contiene la dirección donde falló la aplicación, pero la información de símbolos es mucho más completa. Podemos ver que el fallo ocurrió en el _autenticar La función en la línea 15 de 'LoginFunc.m' (justo donde provocamos el fallo en nuestro código fuente) falla. Recrear este seguimiento de pila legible es el objetivo de todas las herramientas de informes de fallos (Firebase Crashlytics, BugSnag, Instabug, etc.), y por eso estas herramientas requieren que subas un paquete dSYM para lograrlo. 

¿Dónde encaja la seguridad de las aplicaciones en todo esto? 

Todo lo que hemos comentado sobre dSYM hasta ahora se ha basado en que la aplicación que creamos con Xcode no ha sufrido ninguna modificación. ¿Qué ocurre si queremos proteger nuestra aplicación de posibles ciberdelincuentes antes de publicarla en la App Store? 

Durante la protección, el binario se reorganiza, de modo que las ubicaciones de los símbolos ofuscados ya no coinciden con la información del paquete dSYM. Si intentamos simbolizar un fallo en nuestra aplicación protegida con el paquete dSYM de la aplicación no protegida, los resultados serán incoherentes. ¿Hay alguna solución para esto? 

Protecciones posteriores a la construcción frente a protecciones durante la construcción 

Nuestros Protección de aplicaciones para móviles: ARM El producto es una solución de protección posterior a la compilación que se puede usar sin configuración alguna. Esto facilita la protección de una aplicación contra ciberdelincuentes y permite a los desarrolladores obtener una mejor retroalimentación al probar su aplicación protegida, ya que solo necesita compilarse una vez. Sin embargo, como se mencionó anteriormente, esto implica que el paquete dSYM original es incompatible con la aplicación protegida. Los desarrolladores deben volver a crear los archivos dSYM después de la protección para tener en cuenta los cambios en el código y simbolizar posibles fallos. 

Por otro lado, podemos proteger una aplicación sin necesidad de volver a crear los archivos dSYM que genera Xcode. Nuestro producto App Protection for Apple Native ofrece esta capacidad, ya que es una solución de protección integrada. La aplicación se compila y enlaza con diversas funciones de seguridad habilitadas junto con el código fuente original. Esto permite la simbolización de una aplicación protegida, puesto que los archivos dSYM generados están estructurados para contemplar todo lo especificado en la compilación. La desventaja es que las protecciones en tiempo de compilación requieren una mayor configuración por parte del desarrollador, lo que puede resultar más complejo a medida que la aplicación crece y se vuelve más compleja. 

Envolviendo cosas 

Con suerte, esto habrá dado una idea de la importancia de los paquetes dSYM, qué contienen, cómo se utilizan y las soluciones que existen para garantizar que los ingenieros centrados en la seguridad no tengan que hacer ningún sacrificio para utilizar herramientas que faciliten la depuración de aplicaciones iOS.