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

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

AFAIK, no hay ningún truco para la completa evitación de la ingeniería inversa.

Y también muy bien dicho por @inazaruk: Hagas lo que hagas a tu código, un atacante potencial es capaz de cambiarlo de cualquier manera que él o ella lo encuentra factible . Usted básicamente no puede proteger su aplicación de ser modificado. Y cualquier protección que usted pone allí se puede inhabilitar / quitar.

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?

Usted puede hacer trucos diferentes para hacer hacking más difícil sin embargo. Por ejemplo, use ofuscación (si es código Java). Esto normalmente ralentiza significativamente la ingeniería inversa.

3. ¿Hay una 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?

Como todo el mundo dice, y como usted probablemente sabe, no hay seguridad al 100%. Pero el lugar para comenzar para Android, que Google ha construido, 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 biblioteca de APK en cada compilación, puede utilizarla Por la siguiente sugerencia.

Coloque la biblioteca en la ruta de la biblioteca nativa que tiene por defecto "libs" en su carpeta de proyecto. Si ha creado el código nativo para el objetivo 'armeabi' , póngalo en libs / armeabi . Si fue construido con armeabi-v7a, luego lo puso bajo libs / armeabi-v7a.

<project>/libs/armeabi/libstuff.so 

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 lo hará más difícil de leer cuando esté descompilado, si no imposible.
2. Mover las partes más críticas del servicio de la aplicación, y en un servicio web, escondido detrás de un lenguaje de servidor como PHP. Por ejemplo, si usted tiene un algoritmo que le ha tomado un millón de dólares para escribir. Es obvio que no quieres que la gente lo saque de tu aplicación. Mueva el algoritmo y pídale que procese los datos en un servidor remoto y utilice la aplicación simplemente para proporcionarle los datos. O utilice 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 de archivos .so existe incluso a partir de ahora (e incluso si lo hiciera, no sería tan bueno como el decompilers de Java). Además, como @nikolay mencionado en los comentarios, debe utilizar SSL al interactuar entre el servidor y el dispositivo.
3. Cuando almacene 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 tiene el usuario en SharedPreferences. Supongamos que son 10000 monedas. En lugar de guardar 10000 directamente, guárdelo usando un algoritmo como ((currency*2)+1)/13 . Así que en lugar de 10000 , se guarda 1538.53846154 en SharedPreferences. Sin embargo, el ejemplo anterior no es perfecto, y usted tendrá que trabajar para llegar a una ecuación que no perderá moneda a errores de redondeo, etc
4. Puede hacer algo similar para las tareas del lado del servidor. Ahora, por ejemplo, vamos a tomar su aplicación de procesamiento de pagos. Digamos que el usuario tiene que hacer un pago de $200 . En lugar de enviar un valor bruto de $200 al servidor, envíe una serie de valores más pequeños, predefinidos, que suman hasta $200 . Por ejemplo, tenga un archivo o una tabla en su servidor que asimile palabras con valores. Así que digamos que Charlie corresponde a $47 , y John a $3 . Así que en lugar de enviar $200 , puede enviar a Charlie cuatro veces y John cuatro veces. En el servidor, interpretar lo que significan y agregarlo. 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, podría tener una ecuación similar al punto 3 para esto también, y cambiar las palabras clave cada número de días.
5. Por último, puede insertar código fuente aleatorio inútil en su aplicación, por lo que el hacker está buscando una aguja en un pajar. Insertar clases aleatorias que contienen fragmentos de Internet, o simplemente funciones para calcular cosas aleatorias como la secuencia de Fibonacci. Asegúrese de que estas clases se compile, pero no se utilicen por la funcionalidad real de la aplicación. Añadir suficiente de estas clases falsas, y el hacker tendría un momento difícil encontrar su código real.

En general, 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 seguimiento de múltiples cantidades de transacción y las palabras clave que envía para él, el hacker podría minuciosamente ir a través de la fuente y averiguar qué código es un maniquí.

Sólo 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 mayor probabilidad, nunca será posible .

Con esto entendido, hay una solución obvia: no dé sus secretos a su atacante. Aunque no puede proteger el contenido de su APK, lo que puede proteger es algo que no distribuye. Normalmente, este es el software del lado del servidor utilizado para cosas como activación, pagos, aplicación de normas y otros bits jugosos de código. Puede proteger activos valiosos al no distribuirlos en su APK. En su lugar, configure un servidor que responda a las solicitudes de su aplicación, "utilice" los activos (lo que sea que signifique) y, a continuación, envía 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.

Además, si su objetivo principal es evitar la piratería de aplicaciones : ni siquiera se molestan. Usted ya ha quemado más tiempo y dinero en este problema de lo que cualquier medida anti-piratería posiblemente podría esperar para ahorrar. El retorno de la inversión para resolver este problema es tan bajo que no tiene sentido ni siquiera pensar en ello.

1. ¿Cómo puedo evitar completamente la ingeniería inversa de un APK de Android? es 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 una extensión .apk a .zip, después de descomprimir, alguien puede obtener fácilmente todos los recursos (excepto Manifest.xml ), pero con APKtool uno puede obtener el contenido real del archivo de manifiesto también. Una vez más, un no.

3. ¿Hay una 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?

Una vez más, no, pero se puede prevenir hasta cierto nivel, es decir,

• Descargue un recurso de la Web y realice algún proceso de cifrado
• Utilizar una biblioteca nativa pre-compilada (C, C ++, JNI, NDK)
• Realice siempre un poco de hash (llaves MD5 / SHA o cualquier otra lógica)

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

Primera regla de la seguridad de la aplicación: Cualquier máquina a la que un atacante gana acceso físico o electrónico sin restricciones ahora pertenece a tu atacante, independientemente de dónde se encuentre o de lo que hayas pagado por él.

Segunda regla de seguridad de la aplicación: Cualquier software que deja los límites físicos dentro de los cuales un atacante no puede penetrar ahora pertenece a tu atacante, independientemente de cuánto tiempo pasaste codificándolo.

Tercera regla: Cualquier información que deja esos mismos límites físicos que un atacante no puede penetrar ahora pertenece a tu atacante, no importa cuán valioso sea para ti.

Los fundamentos de la seguridad de la tecnología de la información se basan en estos tres principios fundamentales; La única computadora realmente 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 de servicio 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 (delante de una multitud de testigos con cámaras que registran cada centímetro de la habitación en la que se encuentran).

Ahora, la mayoría de las computadoras no se utilizan bajo estos tipos 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 se puede confiar en ellos. 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 pueden saber o hacer lo suficiente para causar daño (por lo menos no daño permanente fuera de los límites de esa única máquina ).

Ya sabías todo esto; Por eso estás intentando proteger el código de tu aplicación. Pero, ahí radica el primer problema; Las herramientas de obfuscation pueden hacer el código un lío para que un humano intente cavar a través, pero el programa todavía tiene que funcionar; Esto 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 los que lo que está viendo no puede ser otra cosa que lo que está buscando.

En su lugar, debe estar tratando de garantizar que un atacante no puede hacer nada con su código, no importa lo fácil que es para él obtener una copia clara de la misma. 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 desarrollaste.

Estos valores-clave que ha codificado correctamente deben eliminarse completamente del código fuente de la aplicación. En cambio, deberían estar en uno de los tres lugares; Memoria volátil en el dispositivo, que es más difícil (pero aún no imposible) para un atacante para obtener una copia sin conexión de; Permanentemente en el clúster de servidores, al que controlas 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 las memorias 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 introduce sus credenciales para la aplicación desde la memoria en el dispositivo. Por desgracia, debes confiar en que el dispositivo del usuario no esté comprometido por un keylogger o un troyano; Lo mejor que puede hacer en este sentido es implementar la seguridad multi-factor, 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 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 cliente (utilizando 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 los vuelve a producir 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 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 centro ve sólo charlatanes incluso si el canal seguro estaba comprometido.

Una vez verificado, el servidor transmite de vuelta un token sobre el canal. El token sólo es útil dentro de la sesión segura, está compuesto de 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 al mismo canal al servidor como parte de cualquier petición hacer algo. La aplicación cliente lo hará muchas veces, porque no puede hacer nada que implique dinero, datos sensibles o cualquier otra cosa que pueda ser perjudicial por sí misma; En su lugar, debe pedir al servidor que realice esta tarea. La aplicación cliente nunca escribirá ninguna información sensible a la memoria persistente 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 su uso en memoria volátil. Esos datos no serán la única copia, tampoco; Cualquier cosa que los almacenes del cliente también se deben transmitir de una cierta 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 conexión adecuada y autenticación por parte del servidor. No es diferente de Facebook, en realidad.

Ahora, el equipo que el atacante quiere es su servidor, porque él y no la aplicación cliente / dispositivo es lo que puede hacerle dinero o causar dolor a otras personas para su disfrute. Está bien; Obtienes mucho más dinero para 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 otros dispositivos de seguridad electrónicos, además de estar físicamente protegidos detrás del acero, el concreto, el acceso de tarjeta / pin y la vigilancia por vídeo las 24 horas. Su atacante necesitaría ser muy sofisticado de hecho para ganar cualquier tipo de acceso al servidor directamente, y usted (debe) saber sobre él inmediatamente.

Lo mejor que un atacante puede hacer 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, 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 llevan en su cartera, cartera o maletín que podría ser Robados junto al dispositivo móvil) desde cualquier teléfono al que puedan acceder y que los conecte directamente a su servicio al cliente. Afirman que su teléfono fue robado, proporcionan algún identificador único básico, y la cuenta está bloqueada, cualquier transacción que el atacante pudo haber sido capaz de procesar se deshace, y el atacante está de vuelta a la casilla uno.

El 100% de evitar la ingeniería inversa del APK de Android no es posible, pero puede utilizar estas formas para evitar extraer más datos, como el código fuente, los recursos de su APK y los recursos:

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

2. Utilice NDK con C y C ++ para poner su núcleo de aplicación y asegurar parte del código en archivos .so

3. Para asegurar 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.

Los desarrolladores pueden tomar las siguientes medidas para evitar un APK de robo de alguna manera,

• La forma más básica es usar herramientas como ProGuard para ofuscar su código, pero hasta ahora, ha sido muy difícil impedir completamente que alguien descompilar una aplicación.

• También he oído hablar de una herramienta HoseDex2Jar . Detiene el 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 piratas informáticos descompilen un APK en código java legible.

• Utilice alguna aplicación del lado del servidor para comunicarse con la aplicación sólo cuando sea necesario. Podría ayudar a prevenir los datos importantes.

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

1. ¿Cómo puedo evitar completamente la ingeniería inversa de un APK de Android? es 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 muy difícil impedir completamente que alguien descompilar una aplicación.

Es una gran herramienta y puede aumentar la dificultad de "revertir" el código mientras reduce la huella de su código.

Compatibilidad con ProGuard integrada: ProGuard ahora está empaquetado con las herramientas de SDK. Los desarrolladores ahora pueden ofuscar su código como parte integrada de una versión de lanzamiento.

3. ¿Hay una 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, llegué a conocer HoseDex2Jar . Esta herramienta protegerá su código de la descompilación, pero parece que no es posible proteger su código completamente.

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

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

La pregunta principal aquí es que los archivos dex pueden ser descompilados y la respuesta es que pueden ser "tipo de". 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 ingeniería inversa experiencia será capaz de averiguar lo que está haciendo desde el smali.

Tal vez elija una buena licencia y hacer cumplir la ley de la mejor manera posible.

1. ¿Cómo puedo evitar completamente la ingeniería inversa de un APK de Android? es 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 una 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 duro sobre todo para el usuario medio, que es googling para guías de hacking. Si alguien realmente quiere hackear su aplicación, será hackeada, tarde o temprano.

Aquí hay algunos métodos que puede probar:

1. Utilice obfuscation y herramientas como ProGuard .
2. Cifrar parte de la fuente y los datos.
3. Utilice una suma de comprobación inherente incorporada en la aplicación para detectar alteraciones.
4. Introducir código para evitar cargar en un depurador, es decir, dejar que la aplicación tenga la capacidad de detectar el depurador y salir / matar al depurador.
5. Separar la autenticación como un servicio en línea.
6. Utilizar la 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.

Su cliente debe contratar a alguien que sabe lo que están haciendo, que puede tomar las decisiones correctas y puede mentor.

Hablar por encima de usted tener alguna capacidad para cambiar el sistema de procesamiento de transacciones en el backend es absurdo – no se debe permitir hacer tales cambios arquitectónicos, así que no esperes poder hacerlo.

Mi razonamiento sobre esto:

Dado que su dominio es procesamiento de pagos, es seguro asumir que PCI DSS y / o PA DSS (y la posible ley estatal / federal) será importante para su negocio – para ser compatible debe demostrar que está seguro. Para ser inseguro luego averiguar (a través de la prueba) que no son seguros, a continuación, la fijación, reevaluación, etcétera hasta que la seguridad se puede verificar a un nivel adecuado = costoso, lento, de alto riesgo para el éxito. Para hacer lo correcto, piense bien por adelantado, comprometa a talento experimentado en el trabajo, desarrolle de una manera segura, luego pruebe, fije (menos), etcétera (menos) hasta que la seguridad pueda ser verificada a un nivel adecuado = barato, Bajo riesgo al éxito.

Si queremos hacer la ingeniería inversa (casi) imposible, 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 GUI controlable posible en el host. Incluso los chips resistentes a la manipulación no son 100% a prueba de grietas; Apenas fijan la barra mucho más arriba que los métodos del software. Por supuesto, esto es 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 solicitud tan celosamente.

Si el objetivo es mejorar la seguridad del método de pago ocultando las fallas de seguridad que la aplicación pueda tener (conocidas o no), es completamente errónea. De hecho, los bits sensibles a la seguridad deben ser de código abierto, si es posible. Usted debe hacer lo más fácil posible para cualquier investigador de seguridad que revise su aplicación para encontrar esos bits y escudriñar su operación, y para contactar con usted. Las aplicaciones de pago no deben contener ningún certificado incrustado. Es decir, no debe haber appliaction servidor que confía en un dispositivo simplemente porque tiene un certificado fijo de la fábrica. Una transacción de pago debe realizarse únicamente en las credenciales del usuario, utilizando un protocolo de autenticación de extremo a extremo correctamente diseñado que impida confiar en la aplicación, en la plataforma o en la red, etc.

Si el objetivo es evitar la clonación, a falta de ese chip a prueba de manipulaciones, no hay nada que usted pueda hacer para proteger el programa de ser invertido y copiado, por lo que alguien incorpora un método de pago compatible en su propia aplicación, dando "Clientes no autorizados". Hay maneras de dificultar el desarrollo de clientes no autorizados. Uno 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. Un programa clon no tendrá exactamente el mismo estado interno. Por supuesto, es una máquina de estado que tiene transiciones similares de estado visible externamente (como puede observarse por entradas y salidas), pero difícilmente el mismo estado interno. Una aplicación de servidor puede interrogar el programa: ¿cuál es su estado detallado? (Es decir, darme una suma de comprobación sobre todas sus variables de estado interno). 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 genuino. Un clon de un tercero tendrá que replicar todos los cambios de estado relevantes del programa genuino con el fin de dar las respuestas correctas, lo que dificultará su desarrollo.

Como alguien que trabajó extensivamente en plataformas de pago, incluyendo una aplicación de pagos móviles (MyCheck), yo diría que necesita delegar este comportamiento en el servidor, no se debe almacenar ningún nombre de usuario ni contraseña para el procesador de pagos (lo que sea) Codificado en la aplicación móvil, eso es lo último que se quiere, porque la fuente puede entenderse incluso cuando se obfusca el código.

Además, no debe almacenar tarjetas de crédito o fichas de pago en la aplicación, todo debería ser, de nuevo, 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 ganado 'T respira por tu cuello (como lo hicieron por nosotros).

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

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

I suggest you to look at Protect Software Applications from Attacks . It's a commercial service, but my friend's company used this and they are glad to use it.

Basically it's not possible. It will never be possible. However, there is hope. You can use an obfuscator to make it so some common attacks are a lot harder to carry out including things like:

1. Renaming methods/classes (so in the decompiler you get types like aa )
2. Obfuscating control flow (so in the decompiler the code is very hard to read)
3. Encrypting strings and possibly resources

I'm sure there are others, but that's the main ones. I work for a company called PreEmptive Solutions on a .NET obfuscator. They also have a Java obfuscator that works for Android as well one called DashO .

Obfuscation always comes with a price, though. Notably, performance is usually worse, and it requires some extra time around releases usually. However, if your intellectual property is extremely important to you, then it's usually worth it.

Otherwise, your only choice is to make it so that your Android application just passes through to a server that hosts all of the real logic of your application. This has its own share of problems, because it means users must be connected to the Internet to use your app.

Also, it's not just Android that has this problem. It's a problem on every app store. It's just a matter of how difficult it is to get to the package file (for example, I don't believe it's very easy on iPhones, but it's still possible).

Its not possible to completely avoid RE but By making them more complex internally, you put make it more difficult for attackers to see the clear operation of the app, which may reduce the number of attack vectors.

If the application handles highly sensitive data, Various techniques exist which can increase the complexity of reverse engineering your code. One technique is to use C/C++ to limit easy runtime manipulation by the attacker. There are ample C and C++ libraries that are very mature and easy to integrate with Android offers JNI. An attacker must first circumvent the debugging restrictions in order to attack the application on a low level. This adds further complexity to an attack. Android applications should have android:debuggable=”false” set in the application manifest to prevent easy run time manipulation by an attacker or malware.

Trace Checking – An application can determine whether or not it is currently being traced by a debugger or other debugging tool. If being traced, the application can perform any number of possible attack response actions, such as discarding encryption keys to protect user data, notifying a server administrator, or other such type responses in an attempt to defend itself. This can be determined by checking the process status flags or using other techniques like comparing the return value of ptrace attach, checking parent process, blacklist debuggers in the process list or comparing timestamps on different places of the program.

Optimizations – To hide advanced mathematical computations and other types of complex logic, utilizing compiler optimizations can help obfuscate the object code so that it cannot easily be disassembled by an attacker, making it more difficult for an attacker to gain an understanding of the particular code. In Android this can more easily be achieved by utilizing natively compiled libraries with the NDK. In addition, using an LLVM Obfuscator or any protector SDK will provide better machine code obfuscation.

Stripping binaries – Stripping native binaries is an effective way to increase the amount of time and skill level required of an attacker in order to view the makeup of your application's low level functions. By stripping a binary, the symbol table of the binary is stripped, so that an attacker cannot easily debug or reverse engineer an application.You can refer techniques used on GNU/Linux systems like sstriping or using UPX.

And at last you must be aware about obfuscation and tools like ProGuard.

Aren't TPM chips (Trusted Platform Module) supposed to manage protected code for you ? They are becoming common on PCs (especially Apple ones) and they may already exist in today's smartphone chips. Unfortunately there is no OS API to make use of it yet. Hopefully Android will add support for this one day. That's also the key to clean content DRM (which Google is working on for WebM).

Nothing is secure when you put it on end-users hand but some common practice may make this harder for attacker to steal data.

• Put your main logic (algorithms) into server side.
• Communicate with server and client; make sure communication b/w server and client is secured via SSL or HTTPS; or use other techniques key-pair generation algorithms (ECC, RSA). Ensure that sensitive information is remain End-to-End encrypted.
• Use sessions and expire them after specific time interval.
• Encrypt resources and fetch them from server on demand.
• Or you can make Hybrid app which access system via webview protect resource + code on server

Multiple approaches; this is obvious you have to sacrifice among performance and security

APK signature scheme v2 in Android N

The PackageManager class now supports verifying apps using the APK signature scheme v2. The APK signature scheme v2 is a whole-file signature scheme that significantly improves verification speed and strengthens integrity guarantees by detecting any unauthorized changes to APK files.

To maintain backward-compatibility, an APK must be signed with the v1 signature scheme (JAR signature scheme) before being signed with the v2 signature scheme. With the v2 signature scheme, verification fails if you sign the APK with an additional certificate after signing with the v2 scheme.

APK signature scheme v2 support will be available later in the N Developer Preview.

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

There is no way to completely avoid reverse engineering of an APK. To protect application assets, resources, you can use encryption.

• Encryption will make harder to use it without decryption.choosing some strong encryption algorithm will make cracking harder.
• Adding some spoof code into your main logic to make more harder for cracking.
• If you can write your critical logic in any native language and that surely make harder for decompile.
• Using any third party security frameworks like Quixxi

How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?

An APK file is protected with the SHA-1 algorithm. You can see some files in the META-INF folder of APK. If you extract any APK file and change any of its content and zip it again and when you run that new APK file on an Android machine, it will not work, because the SHA-1 hashes will never match.

While I agree there's no 100% solution that's going to protect your code, v3 of HoseDex2Jar is now up if you want to give it a try.

Just an addition to already good answers above.

Another trick I know is to store valuable codes as Java Library. Then set that Library to be your Android Project. Would be good as C .so file but Android Lib would do.

This way these valuable codes stored on Android Library won't be visible after decompiling.

when they have the app on their phone, they have full access to memory of it. so if u want to prevent it from being hacked, you could try to make it so that u cant just get the static memory address directly by using a debugger. they could do a stack buffer overflow if they have somewhere to write and they have a limit. so try to make it so when they write something, if u have to have a limit, if they send in more chars than limit, if (input > limit) then ignore, so they cant put assembly code there.

Basically, there are 5 methods to protect your APK. Isolate Java Program, Encrypt Class Files, Convert to Native Codes, Code Obfuscation and Online Encryption I suggest you use online encryption because it is safe and convenient. You needn't spend to much time to achieve this. Such as APK Protect , it is an online encryption website for APK. It provides Java codes and C++ codes protection to achieve anti-debugging and decompile effects. The operation process is simple and easy.

I am developing a payment processing app

Google have been very successful in avoiding malicious hackers in general by using a simple financial method to "protect" Google Chrome , and I quote:

We have a standing $50,000 reward for participants that can compromise a Chromebook or Chromebox with device persistence in guest mode

Your best bet to actually get closer to 100% "security" is picking the right fight for your money's worth.

Now, that won't protect you from lunatics and lucky pranksters, but… The later group will only enjoy little time in while the system readjusts. While a lunatic is something you only need to worry in case you're big enough to have a nemesis. And that would make a great story! 🙂

Invest in Ai. Identifying patterns in money flow to predict potential risks is much more "secure" than trying to prevent money leakage.

^{I tried writing more about all the above in my "blog" , such as why I'm putting "security" and "protect" in quotes (what do they even really mean?).}

In other words, instead of asking " how to avoid reverse engineering " try asking " how to engineer a bullet proof payment processing app ".

Finally, as a processing app you shouldn't care less for whatever fake security you think you can create in your binary code. Worry about your server instead. Make a strict communication protocol to make monitoring the server easier, for instance. Now that can be reliable!