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

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 tomar para proteger su código fuente, o al menos lo que hace si no todo.

1. Utilice herramientas como ProGuard. Esto ofuscará su código y hará que sea más difícil de leer cuando se descompila, si no imposible.
2. Mueva las partes más críticas del servicio fuera de la aplicación y hacia un servicio web, oculto detrás de un lado del servidor lenguaje como PHP. Por ejemplo, si tienes un algoritmo que te 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 son mucho menos propensos a ser descompilados que los apks. No creo que un descompilador para. so archivos incluso existe a partir de ahora (e incluso si lo hiciera, no sería tan bueno como los descompiladores Java). Además, como @nikolay mencionó en los comentarios, debe usar SSL cuando interactúe entre el servidor y el dispositivo.
3. Cuando almacene valores en el dispositivo, no los almacene en un formato raw. Por ejemplo, si tiene un juego y está almacenando la cantidad de moneda del juego que el usuario tiene en SharedPreferences. Supongamos que son monedas 10000. En lugar de guardar 10000 directamente, guárdelo usando un algoritmo como ((currency*2)+1)/13. Así que en lugar de 10000, guardas 1538.53846154 en el Preferencias compartidas. Sin embargo, el ejemplo anterior no es perfecto, y tendrás que trabajar para llegar a una ecuación que no pierda moneda por errores de redondeo, etc.
4. Puede hacer algo similar para las tareas del lado del servidor. Ahora, por 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 valor sin procesar $200 al servidor, envíe una serie de valores predefinidos más pequeños que sumen $200. Por ejemplo, tener un archivo o una tabla en su servidor que equipara 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, interprete lo que significan y sume. Esto evita que un hacker envíe valores arbitrarios a su servidor, ya que no saben 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 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 compilan, pero no son utilizadas por la funcionalidad real de la aplicación. Agregue suficientes de estas clases falsas, y el hacker tendría dificultades para encontrar su verdadero codificar.

Con todo, no hay manera de proteger su aplicación al 100%. Puedes hacerlo más difícil, pero no imposible. Su servidor web podría verse comprometido, el hacker podría averiguar sus palabras clave mediante el monitoreo de múltiples cantidades de transacciones y las palabras clave que envía para ello, el hacker podría ir minuciosamente a través de la fuente y averiguar qué código es un maniquí.

Solo puedes luchar, pero nunca ganar.

En ningún momento de la historia de la computación ha sido posible evitar la ingeniería inversa del software cuando se le da una copia de trabajo a su atacante. Además, con toda probabilidad, nunca será posible.

Con eso entendido, hay una solución obvia: no le des tus secretos a tu atacante. Aunque no puedes proteger el contenido de tu APK, lo que puedes proteger es cualquier cosa que no distribuyas. Por lo general, esto es del lado del servidor software utilizado para cosas como activación, pagos, cumplimiento de reglas y otros fragmentos jugosos de código. Puedes 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 es posible que desee volver a pensar su estrategia.

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

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

Segunda regla de la 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: Cualquiera la información que deja esos mismos límites físicos que un atacante no puede penetrar ahora pertenece a su atacante, sin importar lo valiosa 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 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 el claves privadas para 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 bajo este tipo de entornos; están físicamente a la intemperie, conectadas 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 se puede confiar en ellos. Hay ciertas cosas que las computadoras y su software deben saber o hacer con el fin de ser útil, pero se debe tener cuidado para asegurarse de que nunca pueden saber o hacer lo suficiente para causar daños (al menos no daño permanente fuera de los límites de esa máquina única).

Ya sabías todo esto; es por eso que estás tratando de 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 excavar, pero el programa aún tiene que ejecutarse; eso significa el flujo lógico real de la aplicación y los datos sus usos no se ven afectados por la ofuscación. Dado un poco de tenacidad, un atacante puede simplemente des-ofuscar el código, y eso ni siquiera es necesario en ciertos casos donde lo que está mirando no puede ser otra cosa que lo que está buscando.

En su lugar, deberías intentar asegurarte de que un atacante no pueda hacer nada con tu código, no importa lo fácil que 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 se va el edificio en el que lo desarrollaste.

Estos valores clave que tiene codificados deben eliminarse por completo del código fuente de la aplicación. En su lugar, deben estar en uno de los tres lugares; memoria volátil en el dispositivo, que es más difícil (pero no imposible) para un atacante obtener una copia sin conexión; permanentemente en el clúster de servidores, 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, los recuerdos del usuario (lo que significa que eventualmente estará en la memoria volátil, pero no tiene que ser por mucho tiempo).

Considere el siguiente esquema. El usuario introduce 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 keylogger o un troyano; lo mejor que puede hacer en este sentido es implementar una 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 proporcionar al menos un canal adicional por el cual se puede verificar un intento de inicio de sesión en un dispositivo desconocido.

Las credenciales, una vez ingresadas, son ofuscadas por el software cliente (usando un hash seguro), y las credenciales de texto plano descartadas; han servido a su propósito. Las credenciales ofuscadas se envían a través de un canal seguro al servidor autenticado con certificado, que las hashea nuevamente para producir los datos utilizados para verificar la validez del inicio de sesión. De esta manera, el cliente nunca sabe lo que realmente se compara con el valor de la base de datos, el servidor de aplicaciones nunca conoce las credenciales de texto plano 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 de vuelta un token a través del canal. El token solo es útil dentro de la sesión segura, se compone de cualquiera ruido aleatorio o una copia cifrada (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 para 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 dañarse por sí misma; en su lugar, debe pedirle al servidor que haga esta tarea. La aplicación cliente nunca escribirá ninguna información confidencial en persistente memoria en el propio dispositivo, al menos no en texto plano; el cliente puede pedir 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 pedir al servidor la misma clave para descifrar los datos para usarlos en memoria volátil. Esos datos tampoco serán la única copia; cualquier cosa que el cliente almacene también debe transmitirse de alguna forma al servidor.

Obviamente, esto hace que su aplicación dependa en gran medida de 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 es diferente a Facebook, en realidad.

Ahora, el equipo que el atacante quiere es su servidor, porque él y no la aplicación/dispositivo cliente es lo que puede hacer que el dinero o causar dolor a otras personas para su disfrute. Eso está bien; obtienes mucho más por tu dinero gastando dinero y esfuerzo para asegurar el servidor que en tratar de asegurar todo el cliente. El servidor puede estar detrás de todo tipo de firewalls y otra seguridad electrónica, y además se puede asegurar físicamente detrás de acero, concreto, acceso a tarjetas de acceso/pines y videovigilancia las 24 horas. Su atacante tendría que ser muy sofisticado de hecho para obtener cualquier tipo de acceso al servidor directamente, y usted (debería) saber sobre él inmediatamente.

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 de cliente. En caso de que esto suceda, al igual que la pérdida de una tarjeta de crédito, el usuario legítimo debe ser instruido para llamar a un número 800 (preferiblemente fácil de recordar, y no en la parte posterior de una tarjeta que llevarían en su bolso, cartera o maletín que podría ser robado junto con el dispositivo móvil) desde cualquier teléfono al que puedan acceder que los conecta directamente a su servicio de atención al cliente. Afirman que su teléfono fue robado, proporcionan algún identificador único básico, y la cuenta está bloqueada, cualquier transacción el atacante puede haber sido capaz de procesar se revierten, y el atacante está de vuelta al punto de partida.

1. ¿Cómo puedo evitar completamente la ingeniería inversa de un APK Android? Es esto posible?

Esto no es posible

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

Cuando alguien cambia a .extensión apk a .zip, luego después de descomprimir, alguien puede obtener fácilmente todos los recursos (excepto Manifest.xml), pero con APKtool uno puede conseguir el contenido real del archivo de manifiesto también. De nuevo, un no.

3. ¿Hay alguna manera de hacer que el hackeo 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 se puede prevenir hasta cierto nivel, es decir,

• Descargar un recurso de la Web y hacer algún proceso de cifrado
• Use una biblioteca nativa precompilada (C, C++, JNI, NDK)
• Siempre realiza algún hashing ( MD5/SHA claves o cualquier otra lógica)

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

No es posible evitar al 100% la ingeniería inversa del APK de Android, pero puedes usar estas formas para evitar extraer más datos, como el código fuente, los activos de tu APK y los recursos:

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

2. Use NDK usando C y C++ para poner el núcleo de su aplicación y proteger parte del código en .so archivos

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

Los desarrolladores pueden tomar los siguientes pasos para evitar que un APK robe 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 completamente que alguien descompile una aplicación.

• También he oído hablar de una herramienta HoseDex2Jar. Detiene Dex2Jar insertando código inofensivo en un APK de Android que confunde y desactiva Dex2Jar y protege el código de la descompilación. Podría de alguna manera evitar que los hackers descompilen un APK en código java legible.

• Utilice 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 se puede proteger completamente su código de los hackers potenciales. 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 almacenar es como bibliotecas compiladas.

1. ¿Cómo puedo evitar completamente la ingeniería inversa de un APK Android? Es esto posible?

Eso es imposible

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

Los desarrolladores pueden tomar medidas como el uso de herramientas como ProGuard para ofuscar su código, pero hasta ahora, ha sido bastante difícil evitar por completo que alguien descompile un app.

Es una gran herramienta 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 las herramientas del SDK. Los desarrolladores ahora pueden ofuscar su código como parte integrada de una compilación de lanzamiento.

3. ¿Hay alguna manera de hacer que el hackeo 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, vine para saber sobre HoseDex2Jar . Esta herramienta protegerá su código de descompilación, pero parece que no es posible proteger su código por completo.

Algunos de los enlaces útiles, puede referirse a ellos.

• Proguard, Android y el servidor de licencias
• Protección de aplicaciones Android LVL
• Pregunta de desbordamiento de pila ¿Es realmente imposible proteger las aplicaciones de Android de la ingeniería inversa?
• Pila Pregunta de desbordamiento Cómo evitar la ingeniería inversa de un archivo APK Android para asegurar el código?

1. ¿Cómo puedo evitar completamente la ingeniería inversa de un APK Android? Es esto posible?

Imposible

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

Imposible

3. ¿Hay alguna manera de hacer que el hackeo 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 está buscando en Google guías de hacking. Si alguien realmente quiere hackear su aplicación - que será hackeado, tarde o temprano.

Aquí hay algunos métodos que puedes probar:

1. Utilizar ofuscación y herramientas como ProGuard.
2. Cifrar alguna parte de la fuente y los datos.
3. Utilice una suma de comprobación incorporada propietaria en la aplicación para detectar la manipulación.
4. Introduzca código para evitar cargar en un depurador, es decir, deje que la aplicación tenga la capacidad de detectar el depurador y salir / matar al depurador.
5. Separe la autenticación como un servicio en línea.
6. Use diversidad de aplicaciones
7. Utilice la técnica de impresión digital para, por ejemplo, firmas de hardware de los dispositivos de diferentes subsistemas antes de autenticar el dispositivo.

La pregunta principal aquí es que se pueden descompilar los archivos dex y la respuesta es que pueden ser "algo así". Hay desensambladores como dedexer y smali.

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

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

Tu cliente debe contratar a alguien que sepa lo que está haciendo, que pueda tomar las decisiones correctas y pueda asesorarte.

Hablar anteriormente de que tiene alguna capacidad para cambiar el sistema de procesamiento de transacciones en el backend es absurdo - no se le debe permitir hacer tales cambios arquitectónicos, así que no espere poder hacerlo.

Mi razonamiento sobre esto:

Dado que su dominio está procesando pagos, es seguro asumir que PCI DSS y / o PA DSS (y potencial estado / federal ley) será importante para su negocio - para ser compatible debe demostrar que está seguro. Para ser inseguro, averigüe (a través de pruebas) que no está seguro, luego corrija, vuelva a probar, etc. hasta que la seguridad se pueda verificar a un nivel adecuado = camino costoso, lento y de alto riesgo hacia el éxito. Para hacer lo correcto, piense bien por adelantado, comprometa talento experimentado al trabajo, desarrolle de manera segura, luego pruebe, arregle (menos), etc. hasta que la seguridad se pueda verificar en un nivel adecuado = forma económica, rápida y de bajo riesgo hacia el éxito.

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

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

Si queremos hacer la ingeniería inversa (casi) imposible, podemos poner la aplicación en un chip altamente resistente a manipulaciones, 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 la manipulación no son 100% a prueba de grietas; simplemente establecen el listón mucho más alto que los métodos de software. Por supuesto, esto es un inconveniente: la aplicación requiere un poco de verruga USB que sostiene el chip para ser insertado en el dispositivo.

La pregunta no revela la motivación para querer proteger esta aplicación tan celosamente.

Si el objetivo es mejorar la seguridad del método de pago ocultando cualquier falla de seguridad que la aplicación pueda tener (conocida o no), es completamente equivocado. De hecho, los tbi 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 aquellos bits y examinar su operación, y para ponerse en contacto con usted. Las solicitudes de pago no deben contener certificados incrustados. 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, o la plataforma, o la red, etc.

Si el objetivo es para evitar la clonación, a excepción de ese chip a prueba de manipulaciones, no hay nada que pueda hacer para proteger el programa de ingeniería inversa y copia, de modo que alguien incorpore un método de pago compatible en su propia aplicación, dando lugar a "clientes no autorizados". Hay maneras de dificultar el desarrollo de clientes no autorizados. Una sería crear sumas de comprobación basadas en instantáneas del estado completo del programa: todas las variables de estado, para todo. GUI, lógica, lo que sea. Clon programa no tendrá exactamente el mismo estado interno. Claro, es una máquina de estados que tiene transiciones de estado visibles externamente similares (como se puede observar por 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 el estado genuino transiciones. Un clon de terceros tendrá que replicar todos los cambios de estado relevantes del programa genuino para dar las respuestas correctas, lo que obstaculizará su desarrollo.

Como alguien que trabajó extensamente en plataformas de pago, incluida una aplicación de pagos móviles (MyCheck), diría que necesita 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 cuando se ofusca el código.

Además, no debe almacenar tarjetas de crédito o tokens de pago en el aplicación, todo debe ser, una vez más, delegado a un servicio que construyó, 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 respirará en su cuello (como lo hicieron para nosotros).

Le sugiero que mire Proteja las Aplicaciones de Software de los Ataques. Es un servicio comercial, pero la compañía de mi amigo usó esto y están contentos de usarlo.

Esquema de firma APK v2 en Android N

La clase PackageManager ahora admite la verificación de aplicaciones mediante el esquema de firma APK v2. El APK signature scheme v2 es un esquema de firma de archivos completos que mejora significativamente la velocidad de verificación y refuerza 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 firmarlo 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.

El soporte para APK signature scheme v2 estará disponible más adelante en la vista previa del desarrollador N.

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

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 los métodos / clases (por lo que en el decompiler se obtienen tipos como a.a)
2. Ofuscar el flujo de control (por lo que en el decompiler el código es muy difícil de leer)
3. Cifrar cadenas y posiblemente recursos

Estoy seguro de que hay otros, pero esa es la los principales. Trabajo para una empresa llamada Soluciones preventivas en un ofuscador . NET. También tienen un ofuscador Java que funciona para Android, así como uno llamado DashO.

Ofuscación siempre viene con un precio, sin embargo. Notablemente, el rendimiento suele ser peor, y requiere algo de tiempo extra alrededor de las versiones por lo general. Sin embargo, si su propiedad intelectual es extremadamente importante para usted, entonces generalmente vale la pena.

De lo contrario, su única opción es hacerlo de manera que su aplicación Android simplemente pasa a través de un servidor que aloja toda la lógica real de su aplicación. Esto tiene su propia cuota de problemas, porque significa que los usuarios deben estar conectados a Internet para usar su aplicación.

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

No es posible evitar completamente el RE, pero al hacerlos más complejos internamente, se pone más difícil para los atacantes ver el funcionamiento claro de la aplicación, lo que puede reducir el número de vectores de ataque.

Si la aplicación maneja datos altamente confidenciales, existen varias 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 manipulación fácil del tiempo de ejecución por parte del atacante. Hay amplias bibliotecas de C y C++ que son muy maduros y fáciles de integrar con Android ofrece 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 Android deben tener android:debuggable="false" establecido en el manifiesto de la aplicación para evitar la manipulación fácil del tiempo de ejecución por un atacante o malware.

Trace Checking - Una aplicación puede determinar si actualmente está siendo rastreada por un depurador u otra herramienta de depuración. Si se rastrea, la aplicación puede realizar cualquier número de posibles acciones de respuesta de ataque, como descartar claves de cifrado para proteger los datos del usuario, notificar a un administrador del servidor u otro tipo de respuestas en un intento de defenderse. Esto se puede determinar verificando los indicadores de estado del proceso o utilizando otras técnicas como comparar el valor devuelto de ptrace attach, verificar el proceso padre, los depuradores de la lista negra 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, la utilización de optimizaciones de compiladores puede ayudar a ofuscar el código objeto para que no pueda ser fácilmente desensamblado por un atacante, lo que hace más difícil para un atacante obtener una comprensión del código en particular. En Android esto se puede lograr más fácilmente mediante la utilización de bibliotecas compiladas de forma nativa con el NDK. Además, el uso de un obfuscador LLVM o cualquier SDK protector proporcionará una mejor ofuscación de código de máquina.

Stripping binarios – Stripping binarios nativos es una manera efectiva de aumentar la cantidad de tiempo y el nivel de habilidad requerido de un atacante con el fin de ver la composición de las funciones de bajo nivel de su aplicación. Al eliminar un binario, la tabla de símbolos del binario se elimina, de modo que un atacante no puede depurar o aplicar ingeniería inversa fácilmente a una aplicación.Puede referirse a las técnicas utilizadas en Sistemas GNU / Linux como sstriping o usando UPX.

Y por fin debes ser consciente de la ofuscación y de herramientas como ProGuard.

No hay manera de evitar completamente la ingeniería inversa de un APK. Para proteger recursos y activos de aplicaciones, puede usar cifrado.

• El cifrado hará más difícil usarlo sin descifrar.elegir un algoritmo de cifrado fuerte hará que el cracking sea más difícil.
• Añadiendo algún código falso a tu lógica principal para hacer más difícil el cracking.
• Si usted puede escribir su lógica crítica en cualquier lengua materna y que seguramente hacen más difícil para descompilación.
• Utilizando cualquier marco de seguridad de terceros como Quixxi

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

Y @Mumair dar un buen inicio pasos: https://stackoverflow.com/a/35411378/474330

Siempre es seguro asumir que todo lo que distribuye al dispositivo de su usuario, pertenece al usuario. Simple y llanamente. Es posible que pueda usar las últimas herramientas y procedimientos para cifrar sus propiedades intelectuales, pero no hay manera de evitar que una persona determinada 'estudie' su propiedad intelectual. sistema. E incluso si la tecnología actual puede hacer que sea difícil para ellos obtener acceso no deseado, puede haber alguna manera fácil mañana, o incluso solo en la próxima hora!

Así, aquí viene la ecuación:

When it comes to money, we always assume that client is untrusted.

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

¿Cómo nos mantenemos seguros?

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

¿No se supone que los chips TPM (Trusted Platform Module) administran el código protegido por usted ? Se están volviendo comunes en las PC (especialmente las de Apple) y pueden existir ya en los chips de teléfonos inteligentes de hoy. Desafortunadamente no hay ninguna API del sistema operativo para hacer uso de ella todavía. Esperemos que Android agregará soporte para esto algún día. Esa es también la clave para limpiar el contenido DRM (en el que Google está trabajando para WebM).

Nada es seguro cuando se pone en manos de los usuarios finales, pero algunas prácticas comunes pueden hacer que sea más difícil para el atacante robar datos.

• Ponga su lógica principal (algoritmos) en el lado del servidor.
• Comuníquese con el servidor y el cliente; asegúrese de que la comunicación b/n del servidor y el cliente esté protegida a través de SSL o HTTPS; o use otras técnicas algoritmos de generación de pares de claves (ECC, RSA). Asegúrese de que la información confidencial se mantenga cifrada de extremo a extremo.
• Use sesiones y expire después de un intervalo de tiempo específico.
• Cifrar los recursos y recuperarlos del servidor bajo demanda.
• O puede hacer una aplicación híbrida que acceda al sistema a través de webview proteger recursos + código en el servidor

Múltiples enfoques; esto es obvio que tienen que sacrificar entre rendimiento y de seguridad

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

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

Si bien estoy de acuerdo en que no hay una solución al 100% que proteja su código, la v3 de HoseDex2Jar ahora está disponible si desea probarlo.

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. Utilice la aplicación Android solo para recopilar y mostrar información del usuario (es decir, el saldo de la cuenta) y en lugar de procesar pagos dentro de códigos java, envíe esta tarea a su servidor utilizando un protocolo SSL seguro con parámetros cifrados. Cree una API totalmente encriptada y segura para comunicarse con su servidor.

Por supuesto, también puede ser hackeado también y no tiene nada que ver con la protección de códigos fuente, pero considéralo otra capa de seguridad para que sea más difícil para los hackers engañar a su aplicación.

Cuando tienen la aplicación en su teléfono, tienen acceso completo a la memoria de la misma. así que si u quiere evitar que sea hackeado, usted podría tratar de hacerlo de modo que u no puede obtener la dirección de memoria estática directamente mediante el uso de un depurador. podrían hacer un desbordamiento de búfer de pila si tienen un lugar para escribir y tienen un límite. así que trate de hacerlo así cuando escriben algo, si u tiene que tener un límite, si envían más caracteres que límite, si (entrada > límite) entonces ignorar, por lo que no pueden poner código de montaje allí.

Herramienta: El uso de Proguard en su aplicación se puede restringir a la ingeniería inversa de su aplicación

Puedo ver esa buena respuesta en este hilo . Además de que puede utilizar facebook redex para optimizar el código. Redex funciona en el nivel .dex donde proguard funciona como nivel .class.

Solo una adición a las ya buenas respuestas anteriores.

Otro truco que sé es almacenar códigos valiosos como Biblioteca Java. Luego configura esa biblioteca para que sea tu proyecto de Android. Sería bueno como C. tan archivo, pero Android Lib haría.

De esta manera, estos valiosos códigos almacenados en la biblioteca de Android no serán visibles después de descompilarse.