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, activo o código fuente del APK archivo.

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

He utilizado la herramienta Proguard proporcionada con el SDK de Android. Cuando realizo ingeniería inversa de un archivo APK generado con 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 valores-clave 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 prevenir completamente ¿ingeniería inversa de un APK de Android? es posible?
  2. ¿Cómo puedo proteger todos los recursos, los activos y el código fuente de la aplicación para que los piratas informáticos no puedan piratear el archivo APK de ninguna manera?
  3. ¿Hay alguna manera de hacer que la piratería sea más difícil o incluso imposible? ¿Qué más puedo hacer para proteger el código fuente en mi archivo APK?

preguntado el 13 de diciembre de 12 a las 06:12

Parece que puede estar usando "seguridad por oscuridad" si su esquema de procesamiento de pagos se basa en que la operación del cliente permanezca en secreto. -

¿Ha considerado escribir las partes importantes del código en C/C++ y agregarlas como una biblioteca compilada? Se pueden desensamblar en código ensamblador, pero la ingeniería inversa de una gran biblioteca a partir del ensamblado requiere mucho tiempo. -

Bienvenido a la cuestión fundamental de la creación de cualquier activo digital. Los piratas informáticos pueden llegar al nivel de instrucción de la máquina, por lo que si una computadora puede leer el archivo, entonces se puede piratear para abrirlo o copiarlo, y ninguna ofuscación o DRM puede detener por completo a un pirata informático determinado. Si necesita seguridad, asegúrese de que las claves privadas nunca estén en la fuente y sepa en la etapa de diseño que solo el aislamiento (hardware remoto y/o dedicado) puede protegerlas. -

Tenga en cuenta que, dependiendo de lo que haga su aplicación de procesamiento de pagos, puede haber una política legal y reglamentaria que afecte a su aplicación y podría exponerlo potencialmente a sanciones severas: consulte Cumplimiento de PCI, comenzando con pcicomplianceguide.org/pcifaqs.php#11. -

30 Respuestas

 1. ¿Cómo puedo evitar por completo la ingeniería inversa de un 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 forma que considere factible.. Básicamente, no puede proteger su aplicación para que no se modifique. Y cualquier protección que coloque allí puede desactivarse/eliminarse.

 2. ¿Cómo puedo proteger todos los recursos, los activos y el código fuente de la aplicación para que los piratas informáticos no puedan piratear el archivo APK de ninguna manera?

Sin embargo, puedes hacer diferentes trucos para dificultar la piratería. 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 la piratería 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 sepas, no hay seguridad al 100%. Pero el lugar para comenzar con Android, que Google ha incorporado, es ProGuard. Si tienes 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, puede usarla según la sugerencia a continuación.

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

<project>/libs/armeabi/libstuff.so

Respondido 18 Feb 13, 20:02

Para la transacción de pago, he usado el estándar ISO 8585, en este momento el esquema para este estándar está en un par clave-valor usando la colección HashMap de Java y cuando hago ingeniería inversa en apk obtendré todo el esquema. ¿Es posible evitar la obtención del esquema? expuesto a través de la ingeniería inversa.? ¿Su última sugerencia de compartir bibliotecas puede ser útil en este caso? ¿Tiene algún enlace para que pueda exponerme a las bibliotecas compartidas en Android? - sachin003

¿Qué hay de cifrar sus cadenas en el código y descifrarlas en tiempo de ejecución? Si realiza el descifrado en un servidor remoto, como sugirieron otras personas, no tendrá el problema de que la clave de descifrado está en las fuentes. - kutschkem

sí, el cifrado es una forma, pero no es seguro que no sea pirateado. Si estoy cifrando cadenas para descifrarlas, necesito una identificación única en el código. y si alguien puede descompilarlo, será muy fácil obtener la identificación única. - Bhavesh Patadiya

por qué agregaste Editado ¿cosas? es todo regular. - Mohamed Azharuddin Shaikh

@hotveryspicy: sí, ahora eliminé la marca "editado" de la respuesta. Edité mi respuesta porque quería saber más sobre cómo las bibliotecas compartidas son útiles en este caso. - Bhavesh Patadiya

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. Utilice herramientas como ProGuard. Estos ofuscarán su código y harán que sea más difícil de leer cuando se descompile, si no imposible.
  2. Saque las partes más críticas del servicio de la aplicación y colóquelas en un servicio web, oculto detrás de un lenguaje del lado del servidor como PHP. Por ejemplo, si tiene un algoritmo que le ha costado un millón de dólares 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 tienen muchas menos probabilidades de descompilarse que los apk. No creo que exista un descompilador para archivos .so a partir de ahora (e incluso si existiera, no sería tan bueno como los descompiladores de Java). Además, como mencionó @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 de moneda del juego que el usuario tiene en SharedPreferences. Supongamos que es 10000 monedas en lugar de ahorrar 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á que trabajar para llegar a una ecuación que no pierda vigencia debido a errores de redondeo, etc.
  4. Puede hacer algo similar para las tareas del lado del servidor. Ahora, como ejemplo, tomemos 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 al servidor, envía una serie de valores más pequeños y predefinidos que suman $200. Por ejemplo, tenga un archivo o tabla en su servidor que equipare palabras con valores. Así que digamos que Charlie corresponde a $47 y John a $3. Así que en lugar de enviar $200, puedes enviar Charlie cuatro veces y John cuatro veces. En el servidor, interpreta lo que significan y súmalo. Esto evita que un pirata informático envíe valores arbitrarios a su servidor, ya que no saben qué palabra corresponde a qué valor. Como medida adicional de seguridad, podría tener una ecuación similar al punto 3 para esto también, y cambiar las palabras clave cada n número de días.
  5. Finalmente, puede insertar código fuente aleatorio e inútil en su aplicación, de modo que el hacker esté buscando una aguja en un pajar. Inserte clases aleatorias que contengan fragmentos de Internet, o simplemente funciones para calcular cosas aleatorias como la secuencia de Fibonacci. Asegúrese de que estas clases se compilen, pero que la funcionalidad real de la aplicación no las use. Agregue suficientes de estas clases falsas y el pirata informático tendrá dificultades para encontrar su código real.

Con todo, 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 descubrir sus palabras clave al monitorear múltiples montos de transacciones y las palabras clave que envía para ello, el pirata informático podría revisar minuciosamente la fuente y descubrir qué código es ficticio.

Solo puedes contraatacar, pero nunca ganar.

Respondido el 13 de diciembre de 12 a las 07:12

En lugar de hacer trucos con los valores que envía a su servidor, use SSL y valide correctamente el certificado del servidor. La seguridad por oscuridad es generalmente una mala idea. - Nikolái Elenkov

puede insertar código fuente aleatorio e inútil en su aplicación. Esto tampoco puede ayudar. Esto solo inflará su aplicación, mientras que también hará que sea más difícil de mantener. - Anirudh Ramanathan

¿más difícil? Sí. Pero no te dan nada más que una falsa sensación de seguridad. No es tan difícil eliminar el código que nunca se ejecuta, entonces, ¿por qué molestarse en hacerlo? - Anirudh Ramanathan

Si su algoritmo vale un millón de dólares, simplemente porque no hay un descompilador para .so files no significa que no pueda leer el ensamblaje :) La mayoría de estos caen en la misma trampa, solo ofuscan en lugar de protegerse adecuadamente. La ofuscación solo funciona si no vale la pena el tiempo de un atacante para seguir adelante, por lo que si crea algo sobre estas técnicas, es mejor que espere que no se vuelvan populares, de lo contrario, está jodido porque, de repente, su base de código no se puede mantener y necesita grandes cambios. - Foshi

No entiendo por qué esta respuesta tiene una puntuación tan alta. 3. y 4. para uno son simplemente tontos y no equivaldrán a ninguna seguridad en absoluto. - Matti Virkkunen

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 funcional a su atacante. Además, lo más probable es que nunca será posible.

Con eso entendido, hay una solución obvia: no le des tus secretos a tu atacante. Si bien no puedes proteger el contenido de tu APK, lo que puede proteger es cualquier cosa que no distribuyas. Por lo general, este es un software del lado del servidor que se usa para cosas como la activación, los pagos, la aplicación de reglas y otros fragmentos de código jugosos. Puede proteger activos valiosos al no distribuyéndolos en tu APK. En su lugar, configure un servidor que responda a las solicitudes de su aplicación, "utilice" 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, es posible que desee repensar su estrategia.

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

Respondido el 13 de diciembre de 12 a las 08:12

El primer párrafo es la mejor respuesta. Si su atacante controla el hardware, siempre podrá derrotar su software de alguna manera. Cualquier cosa que realmente necesite protección debe permanecer en el hardware que usted controla, es tan simple como eso. Y el párrafo final, sobre el ROI, también es acertado. - daniel priden

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 se encuentre realmente o cuánto pagó por ella.

Segunda regla de seguridad de la aplicación: Cualquier software que deje los límites físicos dentro de los cuales un atacante no puede penetrar ahora pertenece a su atacante, independientemente de 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 pertenece a su atacante, sin importar cuán valiosa sea para usted.

Los cimientos de la seguridad de las tecnologías 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 raíz de confianza (frente a una gran cantidad de testigos con cámaras que graban cada centímetro de la habitación en la que se encuentran).

Ahora, la mayoría de las computadoras no se utilizan en este tipo de entornos; están físicamente al aire libre, 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 como para causar daños (al menos no daños permanentes fuera de los límites de esa única máquina). ).

Ya sabías todo esto; es por eso que está tratando de proteger el código de su aplicación. Pero, ahí radica el primer problema; las herramientas de ofuscación pueden hacer que el código sea un lío para que un humano intente descifrarlo, pero el programa aún 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. Con un poco de tenacidad, un atacante puede simplemente desenmascarar el código, y eso ni siquiera es necesario en ciertos casos en los que lo que está mirando no puede ser otra cosa que lo que está buscando.

En su lugar, debe intentar asegurarse de que un atacante no pueda hacer nada con su código, sin importar cuán fácil sea para él obtener una copia clara del mismo. Eso significa que no hay secretos codificados, porque esos secretos no son secretos tan pronto como el código sale del edificio en el que lo desarrolló.

Estos valores-clave que tiene codificados 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; permanentemente en el clúster de servidores, al que controlas el acceso con mano de hierro; o en un segundo almacén de datos no relacionado con su dispositivo o servidores, como una tarjeta física o en las memorias de sus usuarios (lo que significa que eventualmente estará en una memoria volátil, pero no tiene por qué ser por mucho tiempo).

Considere el siguiente esquema. El usuario ingresa sus credenciales para la aplicación desde la memoria en el dispositivo. Desafortunadamente, debe confiar en que el dispositivo del usuario no está ya comprometido por un registrador de teclas o un troyano; lo mejor que puede hacer en este sentido 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 por 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 sin formato se descartan; han cumplido su propósito. Las credenciales ofuscadas se envían a través de un canal seguro al servidor autenticado por certificado, que las procesa. de nuevo para producir los datos utilizados para verificar la validez del inicio de sesión. De esta manera, el cliente nunca sabe qué se compara realmente con el valor de la base de datos, el servidor de aplicaciones nunca conoce las credenciales de texto sin formato detrás de lo que recibe para la validación, el servidor de datos nunca sabe cómo se producen los datos 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 por el canal. El token solo es útil dentro de la sesión segura, se compone de ruido aleatorio o de una copia cifrada (y, por lo tanto, verificable) de los identificadores de sesión, y la aplicación cliente debe enviar este token por el mismo canal al servidor como parte de cualquier solicitud. hacer algo. La aplicación cliente hará esto muchas veces, porque 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 pedirle al servidor que realice esta tarea. La aplicación cliente nunca escribirá información confidencial en la memoria persistente del propio dispositivo, al menos no en texto sin formato; el cliente puede solicitar al servidor a través del canal seguro una clave simétrica para cifrar cualquier dato local, que el servidor recordará; en una sesión posterior, el cliente puede solicitar al servidor la misma clave para descifrar los datos para su uso 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 adecuada y autenticación por parte del servidor. No es diferente a Facebook, de verdad.

Ahora, la computadora que el atacante quiere es su servidor, porque es y no la aplicación/dispositivo del cliente lo que puede hacerle ganar dinero o causar dolor a otras personas para su disfrute. Está bien; obtiene mucho más por su dinero gastando dinero y esfuerzo para proteger el servidor que tratando de proteger a todos los clientes. El servidor puede estar detrás de todo tipo de cortafuegos y otra seguridad electrónica y, además, puede protegerse físicamente detrás de acero, hormigón, acceso con tarjeta/pin y videovigilancia las 24 horas. Su atacante tendría que ser muy sofisticado para obtener cualquier tipo de acceso directo al servidor, y usted (debería) saberlo 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. En caso de que esto suceda, al igual que la pérdida de una tarjeta de crédito, se debe indicar al usuario legítimo que llame a un número 800 (preferiblemente fácil de recordar y que no esté en el reverso de una tarjeta que llevaría en su cartera, billetera 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 con su servicio de atención al cliente. Afirman que su teléfono fue robado, proporcionan un identificador único básico y la cuenta está bloqueada, cualquier transacción que el atacante haya podido procesar se revierte y el atacante vuelve al punto de partida.

Respondido el 20 de junio de 20 a las 10:06

Respuesta perfecta !! Me encantó tu forma de obtener datos del servidor con algún token encriptado, creo que es casi imposible de decodificar después de eso. - Dharam

Sé que esto es un poco tarde, pero ¿qué pasa con el acceso a la parte del servidor? Los servicios como Microsoft azure le brindan algo como esto para acceder a su servidor: MobileServiceClient mClient = new MobileServiceClient ("MobileServiceUrl", // Reemplace con la URL del sitio anterior "AppKey", // reemplace con la clave de la aplicación this) y prácticamente cualquier persona que tiene acceso a eso puede acceder a su servidor y editarlo - edwinj

@edwinj: no hay problema en informática que no se pueda resolver con otra capa de direccionamiento indirecto. Su fragmento da la idea básica para acceder a un servicio de cliente móvil de Azure; proporciona un nivel básico de seguridad contra "drive-bys" de la puerta principal de Microsoft. A su vez, puede agregar capas adicionales, como solicitar una clave de sesión (básicamente, el token cifrado) en cualquier llamada de servicio, y para obtener esa clave, primero deben autenticarse con una combinación de conocimiento de las credenciales y el esquema de cifrado. - keiths

Una de las mejores respuestas. - debo.stackoverflow

 1. ¿Cómo puedo evitar por completo la ingeniería inversa de un APK de Android? es posible?

Esto no es posible

 2. ¿Cómo puedo proteger todos los recursos, los activos y el código fuente de la aplicación para que los piratas informáticos no puedan piratear el archivo APK de ninguna manera?

Cuando alguien cambia una extensión .apk a .zip, luego de descomprimir, alguien puede obtener fácilmente todos los recursos (excepto Manifiesto.xml), pero con APK herramienta también se puede obtener el contenido real del archivo de manifiesto. De nuevo, un no.

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

De nuevo, no, pero puedes prevenir hasta cierto nivel, es decir,

  • Descargar un recurso de la Web y realizar algún proceso de encriptación
  • Utilice una biblioteca nativa precompilada (C, C++, JNI, NDK)
  • Siempre realice algo de hashing (MD5/SHA llaves o cualquier otra lógica)

Incluso con Smali, la gente puede jugar con tu código. En definitiva, NO ES POSIBLE.

Respondido el 04 de junio de 14 a las 16:06

@TrevorBoydSmith: el cifrado no ayuda mucho cuando el sistema operativo es de código abierto y se puede rootear. El sistema necesita una clave para descifrar el APK y ejecutar cosas. Y si el sistema tiene una clave, y tengo acceso sin restricciones al sistema, entonces sé dónde encontrar la clave y puedo acceder a ella. Sentido yo tambien tengo la llave ahora. - chao

@TrevorBoydSmith: Sin embargo, es la parte de "cómo hacer" lo que acaba con la idea. Simplemente no hay forma de ejecutar código encriptado directamente; en algún momento, el código descifrado tiene que estar disponible. Lo que significa que (1) debe haber una clave (a la que yo, como root, probablemente tenga acceso), y (2) incluso podría encontrar la copia clara en la RAM y no preocuparme por el cifrado de todos modos. - chao

@TrevorBoydSmith: El problema es que, en este caso, simplemente no puede aumentar el costo lo suficiente como para que no valga la pena. No estamos hablando de claves de fuerza bruta aquí; estamos hablando acerca de ya teniendo ellos: el sistema operativo debe tener claves, y nosotros tenemos el sistema operativo. La única forma de solucionarlo sería hacer que el sistema operativo no se pueda rootear. Buena suerte con eso; incluso Apple no puede manejarlo. :) - chao

@TrevorBoydSmith: No creo que aumente el costo en general es imposible. Pienso (y digo), en particular, que su sugerencia es imposible -- porque es. MATLAB no es Android y tiene ciertas libertades que Android no tiene. En particular, tiene ofuscación de su lado; es mucho más difícil ocultar una clave de cifrado. Android no puede hacer eso. Cualquiera que tenga el código fuente sabría dónde se esconden las claves y tendría una herramienta para recuperarlas dentro de los 10 minutos posteriores al anuncio de la función. No solo es posible hacer eso; es francamente trivial. - chao

@TrevorBoydSmith: No he insistido en nada por el estilo. Lo que estoy insistiendo es que estático, cambiante, en movimiento, etc. No importa. En un sistema operativo de código abierto, el cifrado por sí solo no puede proteger el código de nadie que pueda realizar ingeniería inversa. Debido a que puedo leer el código que haría el descifrado, independientemente de cómo se adquiera, use o almacene la clave, puedo ver cómo lo hizo y replicarlo, incluso más fácilmente de lo que podría revertir un supersecreto. código de aplicación - chao

No es posible evitar al 100 % la ingeniería inversa del APK de Android, pero puede usar estas formas de evitar extraer 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. Utiliza la NDK usar C y C ++ para poner el núcleo de su aplicación y asegurar la parte 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 iniciar la aplicación por primera vez.

Respondido 17 Feb 13, 19:02

El tercero realmente facilita el trabajo de los atacantes. Oler la comunicación de la red es más fácil que la ingeniería inversa. - Totten

Para resolver el problema del tercero, se podría encriptar el contenido descargado y/o usar una conexión encriptada (por ejemplo, SSL/TLS) - usuario925861

Cifrar la conexión protege contra personas que husmean o modifican el tráfico. En el caso de que el propio usuario sea malicioso (es decir, tiene su apk y está tratando de piratearlo), aún obtendrá el contenido utilizando su aplicación, extrayendo recursos como usuario raíz; pero sí, ayuda contra los ataques de olfateo simples. - Kevin Lee

Agregando a eso: 4) use dexguard para una mayor ofuscación pero se paga 5) use el archivo OBB para descargar activos al momento de descargar la aplicación, también ayudará a reducir el tamaño de la aplicación - Ashok Kumar

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

  • la forma más básica es usar herramientas como ProGuard para ofuscar 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 hablar de una herramienta MangueraDex2Jar. Para Dex2Jar insertando código inofensivo en un APK de Android que confunde y deshabilita Dex2Jar y protege el código de la descompilación. De alguna manera, podría evitar que los piratas informáticos descompilen 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 necesario. Podría ayudar a prevenir los datos importantes.

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

Respondido el 15 de diciembre de 12 a las 05:12

HoseDex2Jar es casi inútil. Solo 'confunde' a dex2jar y puede bloquearse fácilmente. smali/apktool, etc. funcionan bien con APK 'manguerados'. - Nikolái Elenkov

@NikolayElenkov ¿Sabes cómo funciona HoseDex2Jar? Lo han usado para evitar o confundir a dex2jar. Porque no puedo subir mi archivo apk a la web para usar HoseDex2Jar. Si puedo hacer algo como HoseDex2Jar para confundir a dex2jar, será difícil piratearlo con la herramienta dex2jar. - sachin003

Tal vez no entendiste mi punto: lo que hace HoseDex2Jar es reempaquetar tu APK para que la popular herramienta dex2jar no pueda (de fábrica) revertirlo. Sin embargo, otras herramientas pueden hacerlo, y generalmente es muy fácil vencerlo. No tiene sentido usarlo. Nadie mencionó Dexguard I cosa (por el autor de ProGuard; no es gratis), pero es trabajo mirar. Hace algunas cosas más que la ofuscación 'regular'. - Nikolái Elenkov

¿C++ nunca se puede revertir? es difícil pero posible. y hay herramientas para ayudarte con eso como hex-rays.com/products/decompiler/index.shtml (sí, tienen la versión ARM. No, no es TAN fácil de conseguir). - dkzm

sí, @VikartiAnatra: también mencioné De alguna manera, podrías hacerlo difícil. - Sahil Mahajan Mj

Aquí hay algunos métodos que puede probar:

  1. Utiliza la ofuscación y herramientas como ProGuard.
  2. Cifre una parte del código fuente y los datos.
  3. Use una suma de verificación incorporada patentada en la aplicación para detectar la manipulación.
  4. Introduzca el código para evitar la carga en un depurador, es decir, permita que la aplicación tenga la capacidad de detectar el depurador y salir/eliminar el depurador.
  5. Separe la autenticación como un servicio en línea.
  6. Utiliza la diversidad de aplicaciones
  7. Utilice la técnica de huellas dactilares, por ejemplo, firmas de hardware de los dispositivos de diferentes subsistemas antes de autenticar el dispositivo.

Respondido 22 Jul 21, 21:07

 1. ¿Cómo puedo evitar por completo la ingeniería inversa de un APK de Android? es posible?

Imposible

 2. ¿Cómo puedo proteger todos los recursos, los activos y el código fuente de la aplicación para que los piratas informáticos no puedan piratear el archivo APK de ninguna manera?

Imposible

 3. ¿Hay alguna manera de hacer que la piratería 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: es posible, pero de hecho será más difícil principalmente para el usuario promedio, que solo busca en Google guías de piratería. Si alguien realmente quiere piratear su aplicación, será pirateada, tarde o temprano.

Respondido 18 Feb 13, 21:02

 1. ¿Cómo puedo evitar por completo la ingeniería inversa de un APK de Android? es posible?

Eso es imposible

 2. ¿Cómo puedo proteger todos los recursos, los activos y el código fuente de la aplicación para que los piratas informáticos no puedan piratear el archivo APK de ninguna manera?

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

Es una herramienta realmente excelente y puede aumentar la dificultad de 'revertir' su código mientras reduce la huella de su código.

Soporte integrado de ProGuard: ProGuard ahora está empaquetado con SDK Tools. 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 la piratería 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, me enteré de MangueraDex2Jar. Esta herramienta protegerá su código de la descompilación, pero parece que no es posible proteger su código por completo.

Algunos de los enlaces útiles, puede consultarlos.

contestado el 23 de mayo de 17 a las 12:05

La pregunta principal aquí es si se pueden descompilar los archivos dex y la respuesta es que pueden ser "más o menos". Hay desensambladores como dedexador y smali.

ProGuard, correctamente configurado, ofuscará su código. DexGuard, que es una versión extendida comercial de ProGuard, puede ayudar un poco más. Sin embargo, su código aún se puede convertir a smali y los desarrolladores con experiencia en ingeniería inversa podrán descubrir qué está haciendo desde smali.

Tal vez elegir una buena licencia y hacerla cumplir por ley de la mejor manera posible.

Respondido 22 Jul 21, 22:07

Como nota al margen (descargo de responsabilidad: IANAL): la licencia no protegerá la aplicación en todas las jurisdicciones en todas las circunstancias (por ejemplo, en algunos países de Europa se permite el desmontaje para aumentar la compatibilidad). - Maciej Piechotka

El segundo enlace está medio roto. - Pedro Mortensen

Su cliente debe contratar a alguien que sepa lo que está haciendo, que pueda tomar las decisiones correctas y pueda ser su mentor.

Hablar arriba sobre que tiene alguna capacidad para cambiar el sistema de procesamiento de transacciones en el backend es absurdo: no se le debe permitir realizar tales cambios en la arquitectura, así que no espere poder hacerlo.

Mi justificación en esto:

Dado que su dominio es procesamiento de pagos, es seguro asumir que PCI DSS y/o PA DSS (y posibles leyes estatales/federales) serán importantes para su empresa; para cumplir con las normas, debe demostrar que está seguro. Para ser inseguro, descubra (a través de pruebas) que no está seguro, luego corrija, vuelva a probar, etcétera hasta que la seguridad pueda verificarse en un nivel adecuado = forma costosa, lenta y de alto riesgo para el éxito. Para hacer lo correcto, piense bien desde el principio, comprometa el talento experimentado para el trabajo, desarrolle de manera segura, luego pruebe, repare (menos), etcétera (menos) hasta que la seguridad pueda verificarse a un nivel adecuado = económico, rápido, camino de bajo riesgo hacia el éxito.

Respondido el 13 de diciembre de 12 a las 16:12

Como alguien que trabajó mucho en plataformas de pago, incluida una aplicación de pagos móviles (MyCheck), diría que debe delegar este comportamiento al servidor. Ningún nombre de usuario o contraseña para el procesador de pagos (cualquiera que sea) debe almacenarse o codificarse en la aplicación móvil. Eso es lo último que desea, porque la fuente se puede entender incluso si ofusca el código.

Además, no debe almacenar tarjetas de crédito o tokens de pago en la aplicación. Todo debe ser, de nuevo, delegado a un servicio que hayas creado. También le permitirá, más adelante, ser compatible con PCI más fácilmente, y las compañías de tarjetas de crédito no le quitarán el aliento (como lo hicieron con nosotros).

Respondido 22 Jul 21, 22:07

Si queremos hacer (casi) imposible la ingeniería inversa, podemos poner la aplicación en un chip altamente resistente a la manipulación, que ejecuta todas las cosas sensibles internamente y se comunica con algún protocolo para hacer posible el control de la GUI en el host. Incluso los chips resistentes a manipulaciones no son 100% a prueba de grietas; simplemente ponen el listón mucho más alto que los métodos de software. Por supuesto, esto es un inconveniente: la aplicación requiere una pequeña verruga USB que sostiene el chip para insertarlo en el dispositivo.

La pregunta no revela la motivación para querer proteger esta aplicación con tanto celo.

Si el objetivo es mejorar la seguridad del medio de pago ocultando los fallos de seguridad (conocidos o no) que pueda tener la aplicación, está completamente equivocado. De hecho, los bits sensibles a la seguridad deberían ser de código abierto, si eso es factible. Debe hacer que sea lo más fácil posible para cualquier investigador de seguridad que revise su aplicación para encontrar esos bits y examinar su funcionamiento, y ponerse en contacto con usted. Las aplicaciones de pago no deben contener ningún certificado incrustado. Es decir, no debe haber ninguna aplicación de servidor que confíe en un dispositivo simplemente porque tiene un certificado fijo de fábrica. Una transacción de pago debe realizarse solo con las credenciales del usuario, utilizando un protocolo de autenticación de extremo a extremo correctamente diseñado que impida confiar en la aplicación, la plataforma, la red, etc.

Si el objetivo es evitar la clonación, aparte de ese chip a prueba de manipulaciones, no hay nada que pueda hacer para proteger el programa de la ingeniería inversa y la copia, de modo que alguien incorpore un método de pago compatible en su propia aplicación, dando lugar a "clientes no autorizados". Hay formas de dificultar el desarrollo de clientes no autorizados. Una sería crear sumas de verificación basadas en instantáneas del estado completo del programa: todas las variables de estado, para todo. GUI, lógica, lo que sea. Un programa de clonación no tendrá exactamente el mismo estado interno. Claro, es una máquina de estado que tiene transiciones de estado visibles externamente similares (como se puede observar en las entradas y salidas), pero difícilmente el mismo estado interno. Una aplicación de servidor puede interrogar al programa: ¿cuál es su estado detallado? (es decir, dame una suma de verificación sobre todas tus variables de estado internas). Esto se puede comparar con el código de cliente ficticio que se ejecuta en el servidor en paralelo, pasando por las transiciones de estado genuinas. Un clon de terceros tendrá que replicar todos los cambios de estado relevantes del programa original para dar las respuestas correctas, lo que dificultará su desarrollo.

respondido 16 nov., 21:17

Las otras respuestas votadas aquí son correctas. Solo quiero ofrecer otra opción.

Para ciertas funciones que considere importantes, puede alojar el WebView control en su aplicación. La funcionalidad se implementaría entonces en su servidor web. Parecerá que se está ejecutando en su aplicación.

Respondido el 13 de diciembre de 12 a las 19:12

@Sarel Botha sí, para las pantallas IMP, ya usé webview y sí, esta también es una forma de mantener la seguridad, acepto su respuesta. - sachin003

Acabo de pensar en WebView LMAO. - Persona ejemplo

De acuerdo con @Muhammad Saqib aquí: https://stackoverflow.com/a/46183706/2496464

Y @Mumair da buenos pasos iniciales: https://stackoverflow.com/a/35411378/474330

Siempre es seguro asumir que todo lo que distribuye al dispositivo de su usuario pertenece al usuario. Llano y simple. Es posible que pueda utilizar las últimas herramientas y procedimientos para cifrar su propiedad intelectual, pero no hay forma de evitar que una determinada persona "estudie" su sistema. E incluso si la tecnología actual puede dificultarles obtener acceso no deseado, podría haber una manera fácil mañana, ¡o incluso dentro de una hora!

Por lo tanto, aquí viene la ecuación:

Cuando se trata de dinero, siempre asumimos que el cliente no es de confianza.

Incluso en una economía tan simple como dentro del juego. (¡Especialmente en los juegos! Hay más usuarios 'sofisticados' allí y las lagunas se propagan en segundos!)

¿Cómo nos mantenemos a salvo?

La mayoría, si no todos, de nuestros sistemas de procesamiento de claves (y la base de datos, por supuesto) se encuentran en el lado del servidor. Y entre el cliente y el servidor, se encuentran las comunicaciones encriptadas, las validaciones, etc. Esa es la idea de un cliente ligero.

Respondido 22 Jul 21, 21:07

Te sugiero que mires Proteja las aplicaciones de software de los ataques. Es un servicio comercial, pero la compañía de mi amigo lo usó y están felices de usarlo.

Respondido 17 Feb 13, 19:02

No hay forma de evitar por completo la ingeniería inversa de un archivo APK. Para proteger los activos de la aplicación, los recursos, puede usar el cifrado.

  • El cifrado hará que sea más difícil usarlo sin descifrarlo. Elegir un algoritmo de encriptación fuerte hará que el descifrado sea más difícil.
  • Agregar un código falso a su lógica principal para que sea más difícil de descifrar.
  • Si puede escribir su lógica crítica en cualquier idioma nativo y eso seguramente hará que sea más difícil descompilar.
  • Usar marcos de seguridad de terceros, como Quixxi

Respondido 22 Jul 21, 21:07

Re "escribe tu lógica crítica en cualquier idioma nativo": ¿No sería más fácil ofuscar el código antes de la compilación? - Pedro Mortensen

Esquema de firma APK v2 en Android 7.0 (Turrón)

La clase PackageManager ahora admite la verificación de aplicaciones mediante el esquema de firma APK v2. El esquema de firma APK v2 es un esquema de firma de archivo completo que mejora significativamente la velocidad de verificación y fortalece las garantías de integridad al detectar cualquier cambio no autorizado en los archivos APK.

Para mantener la compatibilidad con versiones anteriores, un APK debe estar firmado con el esquema de firma v1 (esquema de firma JAR) antes de firmarse con el esquema de firma v2. Con el esquema de firma v2, la verificación falla si firma el APK con un certificado adicional después de firmar con el esquema v2.

La compatibilidad con el esquema de firma de APK v2 estará disponible más adelante en N Developer Preview.

http://developer.android.com/preview/api-overview.html#apk_signature_v2

Respondido 22 Jul 21, 21:07

Apk signature v2 solo evita que se manipulen los recursos, pero no dificulta la ingeniería inversa... - Luis CAD

Además, puede eliminar la firma y volver a firmarla. La firma v2 es solo un bloque de datos en el archivo APK. - Robert

Básicamente no es posible. Nunca será posible. Sin embargo, hay esperanza. Puedes usar un ofuscador para que algunos ataques comunes sean mucho más difíciles de llevar a cabo, incluyendo cosas como:

  1. Cambiar el nombre de métodos/clases (por lo que en el descompilador obtienes tipos como a.a)
  2. Flujo de control ofuscado (por lo que en el descompilador el código es muy difícil de leer)
  3. Cifrado de cadenas y posiblemente recursos

Seguro que hay otros, pero esos son los principales. Trabajo para una empresa llamada PreEmptive Solutions en un .NET ofuscador También tienen un ofuscador de Java que también funciona para Android, uno llamado DashO.

Sin embargo, la ofuscación siempre tiene un precio. En particular, el rendimiento suele ser peor y, por lo general, requiere algo de tiempo adicional en torno a los lanzamientos. Sin embargo, si su propiedad intelectual es extremadamente importante para usted, generalmente vale la pena.

De lo contrario, su única opción es hacer que su aplicación de Android solo pase a un servidor que aloje toda la lógica real de su aplicación. Esto tiene sus propios problemas, porque significa que los usuarios deben estar conectados a Internet para usar su aplicación.

Además, no es solo Android el que tiene este problema. Es un problema en todas las tiendas de aplicaciones. Es solo una cuestión de cuán difícil es llegar al archivo del paquete (por ejemplo, no creo que sea muy fácil en iPhones, pero aún es posible).

Respondido 18 Feb 13, 21:02

Desafortunadamente, si uno piratea el cliente (la aplicación), podría ver el formato de comunicación y crear su propio servidor :( - Jocky Doe

La seguridad del 100 % del código fuente y los recursos no es posible en Android. Pero, puede hacer que sea un poco difícil para la ingeniería inversa. Puede encontrar más detalles sobre esto en los siguientes enlaces:

Visite Guardar valores constantes de forma segura y Mejores prácticas de seguridad de aplicaciones móviles para desarrolladores de aplicaciones.

Respondido 22 Jul 21, 21:07

Si su aplicación es tan sensible, debe considerar la parte de procesamiento de pagos en el lado del servidor. Intente cambiar sus algoritmos de procesamiento de pagos. Use una aplicación de Android solo para recopilar y mostrar información del usuario (es decir, el saldo de la cuenta) y, en lugar de procesar pagos dentro del código Java, envíe esta tarea a su servidor mediante un protocolo SSL seguro con parámetros cifrados. Cree una API totalmente cifrada y segura para comunicarse con su servidor.

Por supuesto, también puede ser pirateado y no tiene nada que ver con la protección del código fuente, pero considérelo como otra capa de seguridad para que sea más difícil para los piratas informáticos engañar a su aplicación.

Respondido 22 Jul 21, 21:07

No es posible evitar por completo la ingeniería inversa, pero al hacerlas más complejas internamente, podría dificultar que los atacantes vean el funcionamiento claro de la aplicación, lo que puede reducir la cantidad de vectores de ataque.

Si la aplicación maneja datos altamente confidenciales, diversos existen técnicas que pueden aumentar la complejidad de la ingeniería inversa de su código. Una técnica es usar C/C++ para limitar la fácil manipulación del tiempo de ejecución por parte del atacante. Hay amplias bibliotecas de C y C++ que son muy maduras y fáciles de integrar y ofrece Android JNI.

Un atacante primero debe eludir las restricciones de depuración para atacar la aplicación en un nivel bajo. Esto añade más complejidad a un ataque. Las aplicaciones de Android deben tener android:debuggable=”false” establecido en el manifiesto de la aplicación para evitar que un atacante o malware manipulen fácilmente el tiempo de ejecución.

Comprobación de seguimiento – Una aplicación puede determinar si un depurador u otra herramienta de depuración la está rastreando o no. Si se rastrea, la aplicación puede realizar cualquier cantidad de posibles acciones de respuesta al ataque, como descartar claves de cifrado para proteger los datos del usuario, notificar al administrador del servidor u otro tipo de respuestas similares en un intento de defenderse. Esto se puede determinar comprobando los indicadores de estado del proceso o utilizando otras técnicas, como comparar el valor de retorno de ptrace adjuntar, verificar el proceso principal, poner en lista negra a los depuradores en la lista de procesos o comparar marcas de tiempo en diferentes lugares del programa.

Optimizaciones - Para ocultar cálculos matemáticos avanzados y otros tipos de lógica compleja, puede ser útil utilizar optimizaciones del compilador. ofuscar el código objeto para que un atacante no pueda desarmarlo fácilmente, lo que dificulta que un atacante obtenga una comprensión del código en particular. En Android, esto se puede lograr más fácilmente utilizando bibliotecas compiladas de forma nativa con el NDK. Además, utilizando un LLVM Ofuscador o cualquier protector SDK proporcionará una mejor ofuscación de código de máquina.

Eliminación de binarios – La eliminación de archivos binarios nativos es una forma efectiva de aumentar la cantidad de tiempo y el nivel de habilidad que requiere un atacante para ver la composición de las funciones de bajo nivel de su aplicación. Al eliminar un binario, se elimina la tabla de símbolos del binario, de modo que un atacante no pueda depurar o aplicar ingeniería inversa fácilmente a una aplicación. UPX.

Y por último, debe tener en cuenta la ofuscación y herramientas como ProGuard.

Respondido 22 Jul 21, 21:07

¿De dónde plagiaste esto? De la publicación del blog Aumente la complejidad del código y use la ofuscación? - Pedro Mortensen

Sé que algunas aplicaciones bancarias están usando DexGuard que proporciona ofuscación y cifrado de clases, cadenas, activos, archivos de recursos y bibliotecas nativas.

Respondido 22 Jul 21, 20:07

Puedo ver que hay buenas respuestas para esta pregunta. Además de eso, puedes usar Facebook ReDex para optimizar el código. ReDex trabaja en el .dex nivel donde ProGuard trabaja como .class .

Respondido 22 Jul 21, 21:07

Herramienta: Uso ProGuard en su aplicación, se puede restringir a la ingeniería inversa de su aplicación

Respondido 22 Jul 21, 21:07

Siempre uso Proguard y es útil restringir la ingeniería inversa. - Subham Naik

Nada es seguro cuando se pone en manos de los usuarios finales, pero algunas prácticas comunes pueden dificultar que un atacante robe datos.

  • Ponga su lógica principal (algoritmos) en el lado del servidor.
  • Comunicarse con el servidor y el cliente; asegúrese de que la comunicación entre el servidor y el cliente esté protegida mediante SSL o HTTPS; o utilizar otras técnicas para algoritmos de generación de pares de claves (ECC y RSA). Asegúrese de que la información confidencial se mantenga cifrado de extremo a extremo.
  • Use sesiones y caduque después de un intervalo de tiempo específico.
  • Cifre los recursos y obténgalos del servidor a pedido.
  • O puedes hacer un camiones híbridos aplicación que accede al sistema a través de webview proteger recurso + código en el servidor

Múltiples enfoques; esto es obvio hay que sacrificar entre actuación y seguridad.

Respondido 22 Jul 21, 21:07

No son Trusted Platform Module ¿Se supone que los chips (TPM) administran el código protegido por usted?

Se están volviendo comunes en las PC (especialmente las de Apple) y es posible que ya existan en los chips de los teléfonos inteligentes de hoy. Desafortunadamente, todavía no hay ninguna API de sistema operativo para usarla. Con suerte, Android agregará soporte para esto algún día. Esa es también la clave para limpiar contenido DRM (en el que Google está trabajando para WebM).

Respondido 22 Jul 21, 22:07

¿Cómo puedo proteger todos los recursos, los activos y el código fuente de la aplicación para que los piratas informáticos no puedan piratear el archivo APK de ninguna manera?

Un archivo APK está protegido con la SHA-1 algoritmo. Puedes ver algunos archivos en el META-INF carpeta de APK. Si extrae cualquier archivo APK y cambia parte de su contenido y lo vuelve a comprimir y cuando ejecuta ese nuevo archivo APK en una máquina Android, no funcionará, porque los hashes SHA-1 nunca coincidirán.

Respondido 18 Feb 13, 21:02

Esto es cierto; pero es trivial renunciar al APK (con un certificado diferente) y todo volverá a funcionar. Es posible verificar qué firma se ha utilizado para firmar el APK desde la propia aplicación y generar un error si el certificado cambia, pero es solo un poco menos trivial editar este código fuera de la aplicación. - David dado

Esto puede evitar que el dispositivo Android ejecute código modificado, pero aún puede extraer fácilmente el código relevante y escribir código nuevo en una PC que hace lo que desea. - Sarel Botha

cuando tienen la aplicación en su teléfono, tienen acceso completo a la memoria de la misma. entonces, si desea evitar que sea pirateado, puede intentar hacerlo de modo que no pueda obtener la dirección de memoria estática directamente mediante el uso de un depurador. podrían hacer un desbordamiento del búfer de pila si tienen algún lugar para escribir y tienen un límite. así que trate de hacerlo así cuando escriban algo, si tiene que tener un límite, si envían más caracteres que el límite, si (entrada> límite) entonces ignoren, para que no puedan poner el código ensamblador allí.

Respondido el 03 de Septiembre de 15 a las 10:09

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.