6 formas de ocultar datos en una aplicación de Android

Hola, querido lector, llevo bastante tiempo estudiando aplicaciones móviles. La mayoría de las aplicaciones no intentan ocultarme de alguna manera su funcionalidad "secreta". Y estoy feliz en este momento, porque no tengo que estudiar el código ofuscado de alguien.

En este artículo, me gustaría compartir mi visión de ofuscación, así como hablar sobre un método interesante para ocultar la lógica de negocios en aplicaciones con NDK, que encontré hace relativamente poco. Entonces, si está interesado en ejemplos en vivo de código ofuscado en Android, le pido gato.

Bajo la ofuscación en el marco de este artículo, entendemos la reducción del código ejecutable de una aplicación de Android a un formulario que es difícil de analizar. Hay varias razones para dificultar el análisis de código:

1. Ningún negocio quiere ser hurgado en su "interior".
2. Incluso si tiene una aplicación ficticia, siempre puede encontrar cosas interesantes allí (un ejemplo con instagram ).

Muchos desarrolladores resuelven el problema simplemente bifurcando la configuración de ProGuard. Esta no es la mejor manera de proteger los datos (si es la primera vez que escucha esto, consulte la wiki ).

Quiero exponer un caso, por qué la supuesta "protección" con ProGuard no funciona. Tome cualquier ejemplo simple de Google Samples.

Después de haber conectado ProGuard con una configuración estándar, obtenemos un código descompilado:

"Ohhh, nada está claro", decimos y nos calmamos. Pero después de un par de minutos de cambiar entre archivos, encontramos piezas de código similares:

En este ejemplo, el código de la aplicación parece bastante débil (registro de datos, creación de captura de video), por lo que algunos de los métodos utilizados en el código original se entienden fácilmente incluso después de procesar con la configuración ProGuard.

Además, eche un vistazo a las clases de datos en Kotlin. La clase de datos predeterminada crea el método "toString", que contiene los nombres de las variables de instancia y el nombre de la propia clase.

Clase de datos de origen:

Puede convertirse en un tidbit para un reverso:

(autogeneración del método toString en Kotlin)

Resulta que ProGuard se esconde lejos de todo el código fuente del proyecto.

Si todavía no te he convencido de la falta de eficacia para proteger el código de esta manera, entonces intentemos dejar el atributo ".source" en nuestro proyecto.

-keepattributes SourceFile 

Esta línea está en muchos proyectos de código abierto. Le permite ver StackTrace cuando la aplicación falla. Sin embargo, al extraer ".source" del código smali, obtenemos toda la jerarquía del proyecto con los nombres completos de las clases.

Por definición, la ofuscación es "llevar el código fuente a una forma ilegible para contrarrestar los diferentes tipos de recepción". Sin embargo, ProGuard (cuando se usa con una configuración estándar) no hace que el código sea ilegible: funciona como un minificador, comprimiendo nombres y eliminando clases adicionales del proyecto.

Tal uso de ProGuard es una solución fácil, pero no del todo adecuada para una buena ofuscación. Un buen desarrollador necesita hacer que el revendedor (o el atacante) tenga miedo de los "caracteres chinos", que son difíciles de desofuscar.

Si está interesado en aprender más sobre ProGuard, le propongo el siguiente artículo informativo .

Que estamos escondiendo

Ahora veamos qué suele estar oculto en las aplicaciones.

• Claves de cifrado:

• Lógica de aplicación específica:

Algo más inesperado a menudo se puede ocultar en el código (observaciones de la experiencia personal), por ejemplo:

• Nombres de desarrolladores de proyectos
• Camino completo al proyecto
• Client_secret para el protocolo Oauth2
• Libro en PDF "Cómo desarrollar para Android" (probablemente siempre a mano)

Ahora sabemos lo que se puede ocultar en las aplicaciones de Android y podemos pasar a lo principal, es decir, a las formas de ocultar estos datos.

Formas de ocultar datos

Opción 1: no escondas nada, deja todo a la vista

En este caso, solo te muestro esta foto :)

"Ayuda a Dasha a encontrar la lógica de negocios"

Esta solución rentable y completamente gratuita es adecuada para:

• Aplicaciones simples que no interactúan con la red y no almacenan información confidencial del usuario;
• Aplicaciones que usan solo la API pública.

Opción 2: use ProGuard con la configuración correcta

Esta decisión todavía tiene derecho a la vida, porque, antes que nada, es simple y gratuita. A pesar de las desventajas mencionadas anteriormente, tiene una ventaja importante: si las reglas de ProGuard están configuradas correctamente, la aplicación realmente puede ofuscarse.

Sin embargo, debe comprender que dicha solución después de cada ensamblaje requiere que el desarrollador descompile y verifique si todo está bien. Después de pasar varios minutos estudiando el archivo APK, el desarrollador (y su compañía) pueden confiar más en la seguridad de su producto.

Esta solución es adecuada para:

• Aplicaciones de juguetes, aplicaciones de tiendas en línea, etc.
• Aplicaciones que son clientes realmente delgados, y todos los datos llegan exclusivamente del lado del servidor;
• Aplicaciones que no escriben en todos sus banners "Aplicación segura No. 1".

Opción 3: usar ofuscador de código abierto

Desafortunadamente, no conozco los ofuscadores gratuitos realmente buenos para aplicaciones móviles. Y los ofuscadores que se pueden encontrar en la red pueden causarle mucho dolor de cabeza, ya que será demasiado difícil armar un proyecto de este tipo para nuevas versiones de la API.

Históricamente, los ofuscadores geniales existentes se hacen bajo código de máquina (para C / C ++). Buenos ejemplos:

• Obfuscator-LLVM, https://github.com/obfuscator-llvm/obfuscator
• Movfuscator, https://github.com/xoreaxeaxeax/movfuscator

Por ejemplo, Movfuscator reemplaza todos los códigos de operación con mov, hace que el código sea lineal y elimina todas las ramas. Sin embargo, no se recomienda utilizar este método de ofuscación en un proyecto de combate, porque el código corre el riesgo de ser muy lento y pesado.

Esta solución es adecuada para aplicaciones donde la parte principal del código es NDK.

Opción 4: usar una solución patentada

Esta es la opción más competente para aplicaciones serias, como software propietario:
a) apoyado;
b) siempre será relevante.

Un ejemplo de código ofuscado al usar tales soluciones:

En este fragmento de código puedes ver:

1. Los nombres de variables más incomprensibles (con la presencia de letras rusas);
2. Caracteres chinos en las líneas que no dejan en claro lo que realmente está sucediendo en el proyecto;
3. Hay muchas trampas agregadas al proyecto ("switch", "goto"), que cambian enormemente el flujo de código de la aplicación.

Esta solución es adecuada para:

• Bancos
• Compañías de seguros;
• Operadores móviles, aplicaciones de almacenamiento de contraseña, etc.

Opción 5: usar React-Native

Decidí resaltar este punto, ya que escribir aplicaciones multiplataforma se ha convertido en una actividad muy popular.

Además de una comunidad muy grande, JS tiene una gran cantidad de ofuscadores abiertos. Por ejemplo, pueden convertir su aplicación en emoticones:

Realmente me gustaría aconsejarle sobre esta solución, pero su proyecto funcionará muy poco más rápido que una tortuga.

Pero al reducir el requisito de ofuscación de código, podemos crear un proyecto realmente bien protegido. Así que google "js obfuscator" y ofusque nuestro archivo de paquete de salida.

Esta solución es adecuada para aquellos que están listos para escribir una aplicación multiplataforma en React Native.

Opción 6: usar NDK

Yo mismo a menudo tenía que usar NDK en mi código. Y sé que algunos desarrolladores creen que usar NDK guarda su aplicación de los inversores. Esto no es del todo cierto. Primero debe comprender cómo funciona la ocultación con el NDK.

Resulta muy simple. Hay alguna convención JNI en el código que cuando llama al código C / C ++ en un proyecto, se convertirá de la siguiente manera.

NativeSummator Native Class:

Implementación del método de suma nativa:

Implementación del método nativo de suma estática:

Queda claro que para llamar al método nativo, utiliza la Java_<package name>_<Static?><class>_<method> en la biblioteca dinámica.

Si observa el código Dalvik / ART, encontraremos las siguientes líneas:

( fuente )

Primero, generaremos la siguiente línea Java_<package name>_<class>_<method> partir del objeto Java, y luego intentaremos resolver el método en la biblioteca dinámica usando la llamada "dlsym", que intentará encontrar la función que necesitamos en el NDK.

Así es como funciona JNI. Su principal problema es que al descompilar la biblioteca dinámica, veremos todos los métodos a la vista:

Por lo tanto, debemos encontrar una solución para que la dirección de la función esté ofuscada.

Al principio intenté escribir datos directamente en nuestra tabla JNI, pero me di cuenta de que los mecanismos ASLR y las diferentes versiones de Android simplemente no me permitían hacer que este método funcionara en todos los dispositivos. Luego decidí averiguar qué métodos proporciona el NDK a los desarrolladores.

Y, he aquí , había un método "RegisterNatives" que hace exactamente lo que necesitamos (llama a la función interna dvmRegisterJNIMethod ).

Definimos una matriz que describe nuestro método nativo:

Y registramos nuestro método declarado en la función JNI_OnLoad (el método se llama después de que se inicializa la biblioteca dinámica, miles ):

Hurra, nosotros mismos escondimos la función "hideFunc". Ahora aplique nuestro ofuscador llvm favorito y disfrute de la seguridad del código en su forma final.

Esta solución es adecuada para aplicaciones que ya usan NDK (la conexión de NDK trae muchas dificultades al proyecto, por lo que esta solución no es tan relevante para las aplicaciones que no son NDK).

Conclusión

De hecho, la aplicación no debería almacenar ningún dato confidencial, o debería ser accesible solo después de la autenticación del usuario. Sin embargo, sucede que la lógica empresarial obliga a los desarrolladores a almacenar tokens, claves y elementos específicos de la lógica del código dentro de la aplicación. Espero que este artículo lo ayude si no desea compartir datos tan sensibles y ser un "libro abierto" para los escribas.

Creo que la ofuscación es una parte estructural importante de cualquier aplicación moderna.

¡Piense cuidadosamente sobre los problemas de ocultación de código y no busque formas fáciles! :)

Por cierto, gracias al usuario miproblema por su ayuda en algunos problemas. Suscríbase a su canal de telegramas, es interesante allí.

Y también muchas gracias a los usuarios de sverkunchik y SCaptainCAP por su ayuda en la edición del artículo.