Pregunta ¿Cómo evitar la ingeniería inversa de un archivo APK?


Estoy desarrollando un aplicación de procesamiento de pagos para Android, y quiero evitar que un pirata informático acceda a cualquier recurso, recurso o código fuente del APK archivo.

Si alguien cambia la extensión .apk a .zip, puede descomprimirla y acceder fácilmente a todos los recursos y activos de la aplicación, y usar dex2jar y un decompilador de Java, también pueden acceder al código fuente. Es muy fácil realizar una ingeniería inversa de un archivo APK de Android. Para obtener más detalles, consulte la pregunta sobre el desbordamiento de pila. Ingeniería inversa desde un archivo APK a un proyecto.

He utilizado la herramienta Proguard proporcionada con Android SDK. Cuando realizo la ingeniería inversa de un archivo APK generado utilizando un almacén de claves firmado y Proguard, obtengo un código ofuscado. Sin embargo, los nombres de los componentes de Android permanecen sin cambios y algunos códigos, como los pares clave-valor utilizados en la aplicación, permanecen sin cambios. Según la documentación de Proguard, la herramienta no puede ofuscar los componentes mencionados en el archivo Manifest.

Ahora mis preguntas son:

  1. Cómo puedo evitar completamente ingeniería inversa de una APK de Android? es posible?
  2. ¿Cómo puedo proteger todos los recursos, recursos y código fuente de la aplicación para que los hackers no puedan hackear el archivo APK de ninguna manera?
  3. ¿Hay alguna manera de hacer que el pirateo sea más difícil o incluso imposible? ¿Qué más puedo hacer para proteger el código fuente en mi archivo APK?

643
2017-12-13 06:42


origen


Respuestas:


1. ¿Cómo puedo evitar completamente la ingeniería inversa de una APK de Android? es posible?

AFAIK, no hay ningún truco para evitar por completo la ingeniería inversa.

Y también muy bien dicho por @inazaruk: Hagas lo que hagas con tu código, un atacante potencial puede cambiarlo de cualquier manera que él o ella lo encuentre factible. Básicamente no puedes proteger tu aplicación de ser modificada. Y cualquier protección que coloque allí puede ser desactivada / eliminada.

2. ¿Cómo puedo proteger todos los recursos de la aplicación, los recursos y el código fuente para que los hackers no puedan hackear el archivo APK de ninguna manera?

Sin embargo, puedes hacer diferentes trucos para hacer el hackeo más difícil. Por ejemplo, use ofuscación (si es código Java). Esto generalmente ralentiza significativamente la ingeniería inversa.

3. ¿Hay alguna manera de hacer que el pirateo sea más difícil o incluso imposible? ¿Qué más puedo hacer para proteger el código fuente en mi archivo APK?

Como todo el mundo dice, y como probablemente sepa, no existe una seguridad del 100%. Pero el lugar para comenzar para Android, que Google ha incorporado, es ProGuard. Si tiene la opción de incluir bibliotecas compartidas, puede incluir el código necesario en C ++ para verificar el tamaño de los archivos, la integración, etc. Si necesita agregar una biblioteca nativa externa a la carpeta de la biblioteca de su APK en cada compilación, entonces puedes usarlo por la sugerencia a continuación.

Coloque la biblioteca en la ruta de la biblioteca nativa que por defecto es "libs" en la carpeta de tu proyecto Si construiste el código nativo para el 'armeabi' objetivo, entonces ponlo debajo libs / armeabi. Si fue construido con armeabi-v7a luego ponlo debajo libs / armeabi-v7a.

<project>/libs/armeabi/libstuff.so

323
2017-12-13 07:03



AFAIK, no puede proteger los archivos en el directorio / res más de lo que están protegidos en este momento.

Sin embargo, hay pasos que puede seguir para proteger su código fuente, o al menos lo que hace si no todo.

  1. Use herramientas como ProGuard. Esto ofuscará su código y dificultará la lectura cuando se descompile, si no es que imposible.
  2. Mueva las partes más críticas del servicio fuera de la aplicación y dentro de un servicio web, oculto detrás de un lenguaje del lado del servidor como PHP. Por ejemplo, si tiene un algoritmo que le ha tomado un millón de dólares para escribir. Obviamente no quieres que la gente lo robe de tu aplicación. Mueva el algoritmo y haga que procese los datos en un servidor remoto, y use la aplicación para simplemente proporcionarle los datos. O use el NDK para escribirlos de forma nativa en archivos .so, que es mucho menos probable que se descompilen que los apk. No creo que haya un descompilador para archivos .so a partir de ahora (e incluso si lo hiciera, no sería tan bueno como los decompiladores de Java). Además, como se mencionó en @nikolay en los comentarios, debe usar SSL al interactuar entre el servidor y el dispositivo.
  3. Al almacenar valores en el dispositivo, no los almacene en un formato sin formato. Por ejemplo, si tiene un juego, y está almacenando la cantidad en moneda del juego que el usuario tiene en SharedPreferences. Supongamos que es 10000 monedas En lugar de guardar 10000 directamente, guárdelo usando un algoritmo como ((currency*2)+1)/13. Entonces, en lugar de 10000, ahorras 1538.53846154 en las Preferencias Compartidas. Sin embargo, el ejemplo anterior no es perfecto, y tendrás que trabajar para encontrar una ecuación que no pierda vigencia a los errores de redondeo, etc.
  4. Puede hacer algo similar para las tareas del lado del servidor. Ahora, para un ejemplo, tomemos realmente su aplicación de procesamiento de pagos. Digamos que el usuario tiene que hacer un pago de $200. En lugar de enviar un raw $200 valor para el servidor, envíe una serie de valores más pequeños, predefinidos, que se suman a $200. Por ejemplo, tenga un archivo o tabla en su servidor que iguale palabras con valores. Entonces digamos que Charlie corresponde a $47y John a $3. Entonces, en lugar de enviar $200, puedes enviar Charlie cuatro veces y John cuatro veces. En el servidor, interprete lo que significan y agréguela. Esto evita que un pirata informático envíe valores arbitrarios a su servidor, ya que no sabe qué palabra corresponde a qué valor. Como medida adicional de seguridad, también podría tener una ecuación similar al punto 3 para esto y cambiar las palabras clave cada n número de días.
  5. Finalmente, puede insertar código fuente aleatorio inútil en su aplicación, de modo que el pirata informático esté buscando una aguja en un pajar. Inserte clases aleatorias que contengan fragmentos de Internet, o simplemente funciones para calcular elementos aleatorios como la secuencia de Fibonacci. Asegúrese de que estas clases se compilan, pero no son utilizadas por la funcionalidad real de la aplicación. Agregue suficientes de estas clases falsas, y el hacker tendrá dificultades para encontrar su código real.

En general, no hay forma de proteger su aplicación al 100%. Puedes hacerlo más difícil, pero no imposible. Su servidor web podría verse comprometido, el pirata informático podría descifrar sus palabras clave monitoreando múltiples cantidades de transacciones y las palabras clave que envía, el pirata informático podría analizar cuidadosamente la fuente y averiguar qué código es falso.

Solo puedes luchar, pero nunca ganar.


117
2017-12-13 07:07



En ningún momento de la historia de la informática, ha sido posible evitar la ingeniería inversa del software cuando le entrega una copia de trabajo a su atacante. Además, con la mayor probabilidad, nunca será posible.

Con eso entendido, hay una solución obvia: no le des tus secretos a tu atacante. Si bien no puede proteger el contenido de su APK, lo que poder proteger es cualquier cosa que no distribuyas. Por lo general, este es un software del lado del servidor utilizado para cosas como la activación, los pagos, el cumplimiento de las reglas y otros bits de código jugosos. Puede proteger activos valiosos mediante no distribuyéndolos en tu APK. En su lugar, configure un servidor que responda a las solicitudes de su aplicación, "use" los activos (lo que sea que eso signifique) y luego envíe el resultado a la aplicación. Si este modelo no funciona para los activos que tiene en mente, entonces quizás quiera volver a pensar su estrategia.

También, si tu objetivo principal es evitar la piratería de aplicaciones: ni siquiera te molestes Ya ha gastado más tiempo y dinero en este problema que cualquier medida de lucha contra la piratería que pueda salvarlo. El retorno de la inversión para resolver este problema es tan bajo que no tiene sentido ni siquiera pensar en ello.


103
2017-12-13 08:28



Primera regla de seguridad de la aplicación: Cualquier máquina a la que un atacante obtenga acceso físico o electrónico sin restricciones ahora pertenece a su atacante, independientemente de dónde esté o de lo que pagó.

Segunda regla de seguridad de la aplicación: Cualquier software que deje los límites físicos dentro del cual un atacante no puede penetrar ahora le pertenece a su atacante, sin importar cuánto tiempo haya dedicado a codificarlo.

Tercera regla: Cualquier información que deje esos mismos límites físicos que un atacante no puede penetrar ahora le pertenece a su atacante, sin importar lo valioso que sea para usted.

Los fundamentos de la seguridad de la tecnología de la información se basan en estos tres principios fundamentales; la única computadora verdaderamente segura es la que está encerrada en una caja fuerte, dentro de una jaula de Farraday, dentro de una jaula de acero. Hay computadoras que pasan la mayor parte de su vida útil en este estado; una vez al año (o menos), generan las claves privadas para las autoridades de certificación de raíz de confianza (frente a una serie de testigos con cámaras que registran cada centímetro de la sala en la que se encuentran).

Ahora, la mayoría de las computadoras no se utilizan en este tipo de entornos; están físicamente a la intemperie, conectados a Internet a través de un canal de radio inalámbrico. En resumen, son vulnerables, al igual que su software. Por lo tanto, no son de fiar. Hay ciertas cosas que las computadoras y su software deben saber o hacer para ser útiles, pero se debe tener cuidado para asegurarse de que nunca puedan saber o hacer lo suficiente para causar daño (al menos no daño permanente fuera de los límites de esa máquina) )

Usted ya sabía todo esto; Es por eso que intentas proteger el código de tu aplicación. Pero, ahí radica el primer problema; las herramientas de ofuscación pueden hacer que el código sea un desastre para que un humano intente investigar, pero el programa todavía tiene que ejecutarse; eso significa que el flujo lógico real de la aplicación y los datos que utiliza no se ven afectados por la ofuscación. Dado un poco de tenacidad, un atacante puede simplemente no ofuscar el código, y eso ni siquiera es necesario en ciertos casos en que lo que está mirando no puede ser otra cosa que lo que está buscando.

En su lugar, deberías tratar de asegurarte de que un atacante no pueda hacer nada con tu código, sin importar cuán fácil sea para él obtener una copia clara de él. Eso significa que no hay secretos codificados, porque esos secretos no son secretos tan pronto como el código abandona el edificio en el que lo desarrollaste.

Estos pares clave-valor que ha codificado deben eliminarse por completo del código fuente de la aplicación. En cambio, deberían estar en uno de tres lugares; memoria volátil en el dispositivo, que es más difícil (pero no imposible) para que un atacante obtenga una copia fuera de línea; de forma permanente en el clúster del servidor, al que controla el acceso con un puño de hierro; o en un segundo almacén de datos no relacionado con su dispositivo o servidores, como una tarjeta física o en los recuerdos de su usuario (lo que significa que eventualmente estará en memoria volátil, pero no tiene que ser por mucho tiempo).

Considere el siguiente esquema. El usuario ingresa sus credenciales para la aplicación de la memoria en el dispositivo. Desafortunadamente, debe confiar en que el dispositivo del usuario ya no está comprometido por un keylogger o troyano; lo mejor que puede hacer a este respecto es implementar seguridad multifactor, recordando información de identificación difícil de falsificar sobre los dispositivos que el usuario ha utilizado (MAC / IP, IMEI, etc.) y proporcionando al menos un canal adicional mediante que se puede verificar un intento de inicio de sesión en un dispositivo desconocido.

Las credenciales, una vez ingresadas, son ofuscadas por el software del cliente (usando un hash seguro) y las credenciales de texto plano son descartadas; ellos han cumplido su propósito. Las credenciales ofuscadas se envían a través de un canal seguro al servidor autenticado por el certificado, que las haste de nuevo para producir los datos utilizados para verificar la validez del inicio de sesión. De esta forma, el cliente nunca sabe qué se compara con el valor de la base de datos, el servidor de aplicaciones nunca conoce las credenciales de texto claro que recibe para la validación, el servidor de datos nunca sabe cómo se produce la información que almacena para la validación, y un hombre en el medio solo ve galimatías incluso si el canal seguro se vio comprometido.

Una vez verificado, el servidor transmite un token sobre el canal. El token solo es útil dentro de la sesión segura, está compuesto por ruido aleatorio o una copia encriptada (y por lo tanto verificable) de los identificadores de sesión, y la aplicación cliente debe enviar este token en el mismo canal al servidor como parte de cualquier solicitud hacer algo. La aplicación del cliente hará esto muchas veces, ya que no puede hacer nada que involucre dinero, datos confidenciales o cualquier otra cosa que pueda ser dañina por sí misma; en su lugar, debe solicitarle al servidor que realice esta tarea. La aplicación cliente nunca escribirá ninguna información sensible a la memoria persistente en el dispositivo, al menos no en texto plano; el cliente puede solicitar al servidor a través del canal seguro una clave simétrica para encriptar cualquier información local, que el servidor recordará; en una sesión posterior, el cliente puede solicitar al servidor la misma clave para descifrar los datos y utilizarlos en la memoria volátil. Esa información tampoco será la única copia; cualquier cosa que almacene el cliente también debe transmitirse de alguna forma al servidor.

Obviamente, esto hace que su aplicación dependa en gran medida del acceso a Internet; el dispositivo cliente no puede realizar ninguna de sus funciones básicas sin una conexión y autenticación adecuadas por parte del servidor. No diferente a Facebook, realmente.

Ahora, la computadora que el atacante quiere es su servidor, porque eso y no la aplicación / dispositivo cliente es lo que le puede hacer ganar dinero o causar dolor a otras personas para su disfrute. Está bien; obtienes mucho más por tu dinero gastando dinero y esfuerzo para asegurar el servidor que tratando de asegurar a todos los clientes. El servidor puede estar detrás de todo tipo de firewalls y otras medidas de seguridad electrónica, y además puede estar físicamente asegurado detrás de acero, concreto, acceso con tarjeta / PIN y videovigilancia las 24 horas. Su atacante tendría que ser muy sofisticado para obtener cualquier tipo de acceso al servidor directamente, y usted (debería) conocerlo de inmediato.

Lo mejor que puede hacer un atacante es robar el teléfono y las credenciales de un usuario e iniciar sesión en el servidor con los derechos limitados del cliente. Si esto sucede, al igual que perder una tarjeta de crédito, el usuario legítimo debe recibir instrucciones para llamar a un número 800 (preferiblemente fácil de recordar, y no en el reverso de una tarjeta que llevaría en su cartera, cartera o maletín que podría ser robado junto con el dispositivo móvil) desde cualquier teléfono al que puedan acceder y que los conecte directamente a su servicio al cliente. Indican que su teléfono fue robado, proporcionan algún identificador único básico, y la cuenta está bloqueada, todas las transacciones que el atacante pudo haber podido procesar se revierten, y el atacante vuelve al punto de partida.


76
2017-12-13 19:39



1. ¿Cómo puedo evitar completamente la ingeniería inversa de una APK de Android? es posible?

Esto no es posible

2. ¿Cómo puedo proteger todos los recursos de la aplicación, los recursos y el código fuente para que los hackers no puedan hackear el archivo APK de ninguna manera?

Cuando alguien cambia una extensión .apk a .zip, luego de descomprimir, alguien puede obtener todos los recursos (excepto Manifest.xml), pero con APKtool uno puede obtener el contenido real del archivo manifiesto también. Nuevamente, un no.

3. ¿Hay alguna manera de hacer que el pirateo sea más difícil o incluso imposible? ¿Qué más puedo hacer para proteger el código fuente en mi archivo APK?

Nuevamente, no, pero puedes prevenir hasta cierto nivel, es decir,

  • Descargue un recurso de la Web y realice un proceso de cifrado
  • Utilice una biblioteca nativa pre compilada (C, C ++, JNI, NDK)
  • Siempre realice algo de hash (MD5/SHA teclas o cualquier otra lógica)

Incluso con Smali, la gente puede jugar con tu código. En general, no es POSIBLE.


65
2017-12-13 07:11



No es posible evitar el 100% de la ingeniería inversa de la APK de Android, pero puede usar estas formas para evitar la extracción de más datos, como el código fuente, los activos de su APK y los recursos:

  1. Use ProGuard para ofuscar el código de la aplicación

  2. Utilizar NDK utilizando C y C ++ para poner la parte central y segura de la aplicación del código en .so archivos

  3. Para proteger los recursos, no incluya todos los recursos importantes en la carpeta de activos con APK. Descargue estos recursos en el momento de la primera puesta en marcha de la aplicación.


35
2017-12-13 07:07



Los desarrolladores pueden tomar los siguientes pasos para evitar que un APK sea robado,

  • la forma más básica es usar herramientas como ProGuardofuscar su código, pero hasta ahora, ha sido bastante difícil evitar por completo que alguien descompile una aplicación.

  • También he oído sobre una herramienta HoseDex2Jar. Para Dex2Jar insertando código inofensivo en una APK de Android que confunde e inhabilita Dex2Jar y protege el código de la descompilación. De alguna manera podría evitar que los piratas informáticos decompilaran un APK en un código java legible.

  • Use alguna aplicación del lado del servidor para comunicarse con la aplicación solo cuando sea necesaria. Podría ayudar a prevenir los datos importantes.

En absoluto, no puedes proteger completamente tu código de los posibles hackers. De alguna manera, podrías hacer que sea una tarea difícil y un poco frustrante para ellos descompilar tu código. Una de las maneras más eficientes es escribir en código nativo (C / C ++) y almacenarlo como bibliotecas compiladas.


33
2017-12-13 06:55



1. ¿Cómo puedo evitar completamente la ingeniería inversa de una APK de Android? es posible?

Eso es imposible

2. ¿Cómo puedo proteger todos los recursos de la aplicación, los recursos y el código fuente para que los hackers no puedan hackear el archivo APK de ninguna manera?

Los desarrolladores pueden tomar medidas como usar herramientas como ProGuard para ocultar su código, pero hasta ahora, ha sido bastante difícil evitar por completo que alguien descompile una aplicación.

Es una herramienta realmente genial y puede aumentar la dificultad de "revertir" el código al mismo tiempo que reduce la huella de su código.

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.

3. ¿Hay alguna manera de hacer que el pirateo sea más difícil o incluso imposible? ¿Qué más puedo hacer para proteger el código fuente en mi archivo APK?

Mientras investigaba, llegué a saber acerca de HoseDex2Jar. Esta herramienta protegerá su código de descompilación, pero parece que no es posible proteger su código por completo.

Algunos enlaces útiles pueden referirse a ellos.


22
2017-12-14 05:11



1. ¿Cómo puedo evitar completamente la ingeniería inversa de una APK de Android? es posible?

Imposible

2. ¿Cómo puedo proteger todos los recursos de la aplicación, los recursos y el código fuente para que los hackers no puedan hackear el archivo APK de ninguna manera?

Imposible

3. ¿Hay alguna manera de hacer que el pirateo sea más difícil o incluso imposible? ¿Qué más puedo hacer para proteger el código fuente en mi archivo APK?

Más difícil, posible, pero de hecho será más difícil sobre todo para el usuario promedio, que solo busca las guías de piratería. Si alguien realmente quiere piratear tu aplicación, será pirateada, tarde o temprano.


21
2017-12-13 07:04