java - ¿Es realmente imposible proteger las aplicaciones de Android de la ingeniería inversa?
proguard (10)
Cómo bloquear clases compiladas de Java para evitar la descompilación
No puedes. Cualquier plan puede ser derrotado por alguien con suficientes habilidades, tiempo y motivación.
(Por cierto, esto también se aplica al software compilado en binario. La única diferencia está en la cantidad de esfuerzo que implica la descompilación).
Mi pregunta es cómo se podría proteger una aplicación que contiene secretos comerciales algorítmicos de la ingeniería inversa.
Simplemente no instale la aplicación en el teléfono del usuario. O (más útil), ejecute el código que contiene los secretos comerciales en un servidor remoto (adecuadamente protegido).
Como sabemos, las aplicaciones de Android están escritas en Java. En Java, no importa lo que haga , es imposible proteger el código compilado de la descompilación o la ingeniería inversa, como la pregunta de desbordamiento de pila ¿ Cómo bloquear las clases compiladas de Java para evitar la descompilación? sugiere.
¿Cómo se puede proteger una aplicación que contiene secretos comerciales algorítmicos de la ingeniería inversa?
Por "cómo" me refiero no solo a las técnicas de software, sino también a otros enfoques creativos .
Es imposible proteger cualquier código del lado del cliente de ingeniería inversa. Puedes simplemente usar formas más o menos eficientes de ofuscar tu código. Y el ensamblador x86 optimizado resulta ser una ofuscación bastante buena.
Entonces, si tienes secretos algorítmicos ponlos en el lado del servidor.
Haz que sea tan barato molestarte y no construyas tu modelo de negocio sobre los secretos que se ejecutan en el lado del cliente. En otras palabras, no comparta sus secretos.
La primera parada para mí sería optimizar y ofuscar el código con ProGuard que se sabe que funciona con el código de bytes dirigido a Dalvik VM de Android (a través de Dex). Es una herramienta realmente buena y puede aumentar la dificultad de ''revertir'' el código mientras reduce la huella de su código (en algunos casos dramáticamente: un applet reciente mío fue de aproximadamente 600 KB a aproximadamente 50 KB).
Como dicen otros, nunca obtendrá el 100% de seguridad de los detalles de su algoritmo mientras su implementación se distribuye a los clientes. Para eso, necesitaría mantener el código solo en sus servidores. Los intentos de obtener una seguridad cercana al 100% para el código del cliente equivalen efectivamente a DRM y pueden hacer que el código de su cliente sea frágil ante las interrupciones de la red y, en general, frustrar a los usuarios (legítimos).
El blog de desarrolladores de Android tiene algunos articles useful sobre el tema de las aplicaciones de Android ''a prueba de manipulaciones'' (y recomiendan el uso de ProGuard como parte del enfoque general).
Con respecto a los enfoques "creativos": algunos desarrolladores emplean técnicas de detección de depuradores para evitar el análisis en tiempo de ejecución y combinar esto con el cifrado de porciones de código binario (para disuadir el análisis estático), pero para ser honesto, un atacante suficientemente determinado puede circumvent , mientras que puede causar la frustración legítima del usuario como se ilustra en el artículo de Windows KB Juegos: Mensaje de error: se ha detectado un depurador: descargue el depurador y vuelva a intentarlo . El software de DVD ''Learn to drive'' de mi novia no se ejecutará en VirtualBox por este motivo, ¡pero culpa a Linux, por supuesto!
El artículo de OpenRCE y Wikipedia sobre el código ofuscado puede ser un buen punto de partida si desea investigar más sobre esto. Pero tenga cuidado, puede perder más por el uso celoso de estas técnicas frustrando a sus usuarios de lo que lo haría a través de la pérdida de secretos comerciales por ingeniería inversa. Al igual que Anton S dice , tal vez el enfoque más "creativo" radica en ajustar el modelo de negocio en lugar de la tecnología.
La última actualización de Android SDK el 6 de diciembre de 2010 (coincidiendo con Android 2.3 Gingerbread):
Soporte integrado de ProGuard: ProGuard ahora viene con las herramientas de SDK. Los desarrolladores ahora pueden ofuscar su código como una parte integrada de una versión de lanzamiento.
No importa lo que hagas, tal vez al menos puedas hacer que sea muy difícil descompilar, pero: si algo se ejecuta / calcula en un programa, la información sobre el algoritmo debe estar allí, y siempre habrá una posibilidad de averiguarlo cómo conseguir eso (se asumió suficiente habilidad y motivación del lado de tus oponentes). Siempre.
No puede asegurar al 100% su código de Android de ingeniería inversa. Si desea proteger alguna clave, puede tomar la ayuda de un servidor integrador que le proporcione claves cifradas mientras llama al servicio web y usar esa clave en su código.
No puede proteger su aplicación por completo, ya que siempre habrá alguien que la descifrará ...
Sin embargo, podría impedir que lo hagan al hacer que su aplicación sea gratuita, o al menos muy barata, para que no molesten a la gente.
Alternativa, trate de mantener su aplicación de Android "tonta", como mantener toda la lógica de negocios secreta en un servidor de back-end, y simplemente haga que su aplicación muestre datos usando algún tipo de servicio expuesto.
Quieres un enfoque creativo, aquí hay uno.
¿Cuál es el programa principal en teléfonos que no se han descompilado hoy? Firmwares de radio ¿Por qué? No se ejecuta en el chipset ARM del teléfono sino en un Qualcomm Hexagon separado que está cada vez más presente en los teléfonos inteligentes. No es x86, no es ARM, usa una arquitectura e instrucciones propietarias de Qualcomm.
La descompilación de Java es fácil.
La descompilación de ARM es más difícil (las licencias de Decompiler de Hex-Rays comienzan en 1129 USD ... y la mezcla entre el código de pulgar y el código ARM estándar en binarios es difícil) => puedes intentar compilar con el NDK de Android.
¡Actualmente no hay descompiladores Hexagon! Y las especificaciones QDSP no están disponibles públicamente, incluso las versiones pirateadas.
La pregunta es, ¿puede un proveedor de software independiente usar el firmware Hexagon incluido en los teléfonos del mercado masivo? Parece ser la dirección que toma Qualcomm. Consulte su sitio web y los productos de SnapDragon.
NB: No soy pro-Qualcomm ni pro-cerrado-fuente. Pero este hilo atrae a este tipo de solución.
Si es una posibilidad: el procedimiento remoto llama a un servidor bien protegido (el servidor tiene el código que desea proteger).
Tengo mi algoritmo en un servidor e invoco ese servicio desde la aplicación de mi teléfono inteligente. Un perpetrador puede aplicar ingeniería inversa a la aplicación de mi teléfono inteligente para ver mi protocolo con mi servidor. Puedo proteger mi algoritmo pero no puedo protegerme contra el uso no autorizado de mi servicio. Debo aceptar esta realidad sin una solución. Tengo que estar contento de que mientras gane dinero con mi propio servicio, entonces tengo que vivir con el potencial de otros que desvíen mi servicio.