Cómo prevenir ingeniería inversa presentar una APK?

Cuestiones de seguridad en el desarrollo de software, entorno de desarrollo, normas, técnicas y herramientas disponibles.
BB96
Posts: 18
Joined: 09 Dec 2014 12:45

Cómo prevenir ingeniería inversa presentar una APK?

Post by BB96 » 10 Dec 2014 11:17

Estoy desarrollando una aplicación de procesamiento de pagos para Android, y quiero evitar que un hacker acceda a cualquier código de los recursos, los bienes o el origen del archivo APK. Si alguien cambia la extensión .apk a .zip entonces pueden descomprimirlo y acceder fácilmente a todas las funciones de la aplicación y de los activos, y el uso de dex2jar y un descompilador de Java, también pueden acceder al código fuente. Es muy fácil de aplicar ingeniería inversa a un archivo APK de Android - Para más detalles ver Safeval.Guru pregunta ingeniería inversa un archivo APK a un proyecto. He estado usando la herramienta Proguard proporcionado con el SDK de Android. Cuando ingeniería inversa un archivo APK generada utilizando un almacenamiento firmado y teclas Proguard, obtener el código ofuscado. Sin embargo, los nombres de los componentes de Android no han cambiado y algo de código como valores clave que se utilizan en la aplicación, se mantiene sin cambios. Como instrumento de documentación Proguard no puede eclipsar los componentes mencionados en el archivo de manifiesto. Ahora mis preguntas son: ¿Cómo puedo evitar completamente la ingeniería inversa de un Android APK? ¿Es esto posible? ¿Cómo puedo proteger a todos los recursos de la aplicación, los activos y código fuente para que los hackers no pueden cortar el archivo APK de alguna manera? ¿Hay una manera de hacer que la piratería más difícil o incluso imposible? ¿Qué puedo hacer para proteger el código fuente en mi archivo APK?

Alexandre Medeiros
Posts: 27
Joined: 02 Dec 2014 17:38

Re: Cómo prevenir ingeniería inversa presentar una APK?

Post by Alexandre Medeiros » 10 Dec 2014 11:17

& Amp; Nbsp; 1. ¿Cómo puedo evitar completamente la ingeniería inversa de un Android APK? ¿Es esto posible? Que yo sepa, no hay ningún truco para evitar la ingeniería inversa completa. Y también es muy bien dicho porinazaruk: Hagas lo que hagas en tu código, un potencial atacante es capaz de cambiar de ninguna manera que él o ella cree viable. Es, básicamente, no puede proteger su aplicación a modificar. Y ningún tipo de protección que puso se puede desactivar / eliminado. & Amp; Nbsp; 2. ¿Cómo puedo proteger a todos los recursos de la aplicación, los activos y código fuente para que los piratas informáticos no pueden cortar el archivo APK de alguna manera? Usted puede hacer muchos trucos para hacer que sea más difícil de cortar. Por ejemplo, usando la ofuscación (si el código Java). Esto generalmente disminuye significativamente la ingeniería inversa. & Amp; Nbsp; 3. ¿Hay una manera de hacer que la piratería más difícil o incluso imposible? ¿Qué 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 100%. Pero el punto de partida para Android, que Google ha construido, es ProGuard. Si usted tiene la opción de incluir las bibliotecas compartidas, puede incluir el código requerido en C ++ para comprobar tamaño de los archivos, integración, etc. Si es necesario agregar una biblioteca nativa externo la carpeta Librería de su APK en cada generación, para que puedas utilizarlo para la sugerencia a continuación. Coloque la biblioteca en el camino biblioteca nativa que por defecto es & quot; libs & quot; en la carpeta del proyecto. Si ha creado el código nativo para el objetivo de armeabi & # 39;, luego lo puso bajo libs / armeabi. Si se construye con armeabi-v7a luego ponerlo bajo libs / armeabi-v7a. & Amp; Lt; Diseño & amp; gt; /libs/armeabi/libstuff.so

Ethan Morton
Posts: 28
Joined: 09 Dec 2014 12:21

Re: Cómo prevenir ingeniería inversa presentar una APK?

Post by Ethan Morton » 10 Dec 2014 11:17

Regla de seguridad Primera aplicación: Máquina que un atacante obtiene acceso físico o electrónico sin restricciones ahora pertenece a su atacante, sin importar donde lo que realmente es o lo que pagó por ella. Segunda regla de seguridad de aplicación: Cualquier software que deja los límites físicos en el que un atacante no puede penetrar ahora pertenece a su agresor, independientemente de la cantidad de tiempo que pasó codificarlo. Tercera regla: Cualquier información que hace que estos mismos límites físicos que un atacante no puede penetrar ahora pertenece a su agresor, no importa lo valioso que es para usted. La base de la seguridad de tecnología de la información se basa en los tres principios fundamentales; el equipo sólo realmente segura es uno encerrado en una caja de seguridad, dentro de una jaula de Faraday, dentro de una jaula de acero. Hay equipos que pasan la mayor parte de sus vidas en servicio sólo en este estado; una vez al año (o menos), generan las claves privadas a Entidades de certificación raíz de confianza (en frente de una multitud de testigos con cámaras de grabación de cada centímetro de la habitación en la que se encuentran). Ahora, la mayoría de los ordenadores no se utilizan en estos tipos de entornos; están físicamente en el abierto, conectado a Internet a través de un canal de radio inalámbrica. En resumen, son vulnerables, como es su software. Por tanto, no son fiables. Hay ciertas cosas que las computadoras y su software deben saber o hacer para ser útil, pero se debe tener cuidado para asegurarse de que nunca pueden saber o hacer lo suficiente para causar daño (al menos no un daño permanente fuera de los límites de que sola máquina). Ya sabiendo todo esto; es por eso que estamos tratando de proteger su código de aplicación. Pero ahí está el primer problema; herramientas de ofuscación puede hacer que el código de un lío para un ser humano para tratar de excavar a través de, pero el programa todavía tiene que correr; esto significa que el flujo de la lógica real de la aplicación y los datos que utiliza no están afectadas por el deslumbramiento. Dada una tenacidad poco, un atacante puede simplemente un-ofuscar el código, y que ni siquiera es necesario en ciertos casos en los que está mirando no puede ser otra cosa que lo que él está buscando. En su lugar, usted debe tratar de asegurarse de que un atacante no puede hacer nada con su código, no importa lo fácil que es para que él consiga una copia clara. Esto significa que sin secretos codificados, porque estos secretos no son secretos, por lo que el código sale del edificio en el que ha desarrollado. Estos valores clave que usted tiene que codificado deben retirarse a partir del código fuente de la aplicación en su totalidad. En cambio, deben estar en uno de tres lugares; memoria no volátil en el dispositivo, que es más difícil (pero no imposible) para un atacante para obtener una copia sin conexión; permanentemente en el clúster de servidores, por lo que el control de acceso con un puño de hierro; o en un segundo almacenamiento de datos sin relación con el dispositivo o servidor como una tarjeta física o en la memoria de usuario (es decir que con el tiempo será en la memoria volátil, pero no tiene por qué ser largo). Considere el siguiente esquema. El usuario introduce sus credenciales a la memoria de su dispositivo. Debe, por desgracia, confiamos en que el dispositivo de usuario no se vea comprometida por un keylogger o un troyano; lo mejor que puedes hacer en este sentido es para implementar la seguridad de múltiples factores, recordando difícil identificar información falsa sobre los dispositivos que el usuario ha utilizado (MAC / IP, IMEI, etc.), y proporcionar al menos un canal Adicional por qué se puede ver un intento de iniciar sesión en un dispositivo desconocido. Las credenciales, una vez introducido, fueron eclipsados ​​por el software de cliente (usando un hash seguro), y las credenciales de texto sin formato descartados; que han servido a su propósito. Las credenciales se ven opacados enviados a través de un canal seguro para el servidor de autenticación de certificado, que los hashes de nuevo para producir los datos que se utilizan para verificar la validez de inicio de sesión. De este modo, el cliente nunca se sabe lo que es realmente, en comparación con los datos de referencia, el servidor de aplicaciones nunca se sabe las credenciales en texto plano detrás de lo que le pasa por la validación, el servidor de datos nunca se sabe cómo los almacenes de datos para la validación se produce, y un medio para el hombre ve sólo galimatías, incluso si el canal seguro se han comprometido. Una vez verificado, el servidor envía una señal del canal. El token es útil sólo dentro de la sesión segura consiste de ruido aleatorio o una copia cifrada (y por lo tanto verificable) de identificadores de sesión, así como la aplicación de cliente para enviar esta señal en el mismo canal para el servidor como parte de una petición que hacer algo. La aplicación cliente va a hacer esto a menudo, porque no puede hacer cualquier cosa que involucre dinero, los datos sensibles, o cualquier otra cosa que podría ser perjudicial en sí mismo; lugar debe pedir el servidor para realizar esta tarea. La aplicación cliente nunca escribirá ninguna información sensible en la memoria constante en el propio dispositivo, al menos no en texto plano; el cliente puede pedir al servidor a través de un canal seguro a una clave simétrica para cifrar todos los datos locales, el servidor recuerde; una sesión posterior, el cliente puede pedir el servidor para la misma clave para descifrar los datos para su uso en la memoria volátil. Estos datos no serán la única copia, o bien; Sean cuales sean las tiendas de cliente también se deben transmitir de alguna manera con el servidor. Obviamente, esto hace que su aplicación depende en gran medida el acceso a Internet; el dispositivo cliente no puede realizar cualquiera de sus funciones básicas sin conexión correcta y la autenticación en el servidor. No es diferente de Facebook, de verdad. Ahora, el equipo que el atacante quiere es su servidor, ya que no el cliente app / dispositivo es lo que usted puede hacer dinero o causar dolor a otras personas para su placer. Eso está bien; usted obtiene mucho más por tu dinero gastar dinero y esfuerzo para proteger el servidor que en tratar de garantizar a todos los clientes. El servidor puede estar detrás de todo tipo de firewalls y otra electrónica de seguridad, y, además, se puede asegurar físicamente detrás de acero, hormigón, llave de acceso / pin, y videovigilancia las 24 horas. Su atacante debe ser muy sofisticados de hecho para ganar cualquier acceso directo al servidor, y usted (debe) conocer de inmediato. Lo mejor que un atacante puede hacer es robar el teléfono de un usuario y las credenciales e ingrese al servidor con los derechos limitados del cliente. Si esto sucede, así como 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áciles de recordar, y no en la parte posterior de una tarjeta que llevan en su bolso, cartera o carpeta que podrían ser robados junto con el dispositivo móvil) desde cualquier teléfono que pueden acceder a ellas que se conecta directamente a su servicio al cliente. Reclama tu teléfono celular fue robado, proporcionar un identificador de base única, y la cuenta está bloqueada, cualquier transacción que el atacante pudo haber sido capaces de procesar, serán invertidos, y el atacante está de vuelta al punto de partida.

Otávio Cardoso
Posts: 19
Joined: 08 Dec 2014 18:06

Re: Cómo prevenir ingeniería inversa presentar una APK?

Post by Otávio Cardoso » 10 Dec 2014 11:17

Prevención del 100% de ingeniería inversa el Android APK no es posible, pero se puede utilizar estos medios para evitar la extracción de datos, como el código fuente, la forma activa su APK y recursos: Uso ProGuard a ofuscar el código de la aplicación Uso NDK usando C y C ++ para poner su núcleo de la aplicación y la pieza segura de archivos de código .so con el fin de garantizar los recursos, no incluyen todas las características importantes de los activos con la carpeta APK. Descargue estos recursos en el momento de la aplicación se inicia por primera vez.

Rodrigo Costa
Posts: 19
Joined: 04 Dec 2014 13:26

Re: Cómo prevenir ingeniería inversa presentar una APK?

Post by Rodrigo Costa » 10 Dec 2014 11:17

& Amp; Nbsp; 1. ¿Cómo puedo evitar completamente la ingeniería inversa de un Android APK? ¿Es esto posible? Eso es imposible & amp; nbsp; 2. ¿Cómo puedo proteger a todos los recursos de la aplicación, los activos y código fuente para que los piratas informáticos no pueden cortar el archivo APK de alguna manera? Los desarrolladores pueden tomar medidas como el uso de herramientas como ProGuard ofuscar su código, pero hasta ahora ha sido muy difícil de evitar por completo a alguien de descompilación una app. Es una herramienta realmente grande y puede aumentar la dificultad de & quot; invertir & quot; su código mientras que la disminución de la huella de su código. Integrado ProGuard apoyo: ProGuard está ahora incluido con las herramientas de SDK. Ahora los desarrolladores pueden ofuscar su código como parte de una versión de lanzamiento. & Amp; Nbsp; 3. ¿Hay una manera de hacer que la piratería más difícil o incluso imposible? ¿Qué puedo hacer para proteger el código fuente en mi archivo APK? Durante la investigación, llegué a saber sobre HoseDex2Jar. Esta herramienta protegerá su código descompilación, pero no parece posible para proteger su código de fondo. Algunos enlaces de interés, usted puede referirse a ellos. Proguard, Android y servidor de licencias de Seguridad de las aplicaciones Android LVL Safeval.Guru pregunta es realmente imposible proteger aplicaciones para Android ingeniería inversa? Safeval.Guru pregunta ¿Cómo prevenir ingeniería inversa un archivo APK Android para asegurar código?

Joaquín Molina
Posts: 26
Joined: 09 Dec 2014 12:20

Re: Cómo prevenir ingeniería inversa presentar una APK?

Post by Joaquín Molina » 10 Dec 2014 11:18

Los desarrolladores pueden tomar medidas para prevenir un robo APK de alguna manera, la forma más básica es utilizar herramientas como ProGuard ofuscar su código, pero hasta ahora ha sido muy difícil de evitar por completo a alguien de descompilación una app. También he oído hablar de una herramienta HoseDex2Jar. Se detiene Dex2Jar insertando código inofensivo en un APK Android que confunde y desactiva Dex2Jar y protege el código de descompilación. De alguna manera se puede evitar que los hackers descompilación de un APK en código java legible. Utilice una aplicación del lado del servidor para comunicarse con la aplicación sólo cuando es necesario. Puede ayudar a evitar que los datos importantes. En total, no se puede proteger completamente su código de hackers potenciales. De alguna manera, puede hacer que sea difícil y frustrante para ellos simplemente descompilar el código. Uno de la manera más eficiente es escribir en código nativo (C / C ++) y almacenarlo como bibliotecas compilados.

Renata Freitas
Posts: 24
Joined: 09 Dec 2014 11:54

Re: Cómo prevenir ingeniería inversa presentar una APK?

Post by Renata Freitas » 10 Dec 2014 11:18

El principal problema aquí es que los archivos pueden ser compilados dex y la respuesta es que pueden ser & quot; tipo & quot;. Hay desensambladores como dedexer y smali. ProGuard, correctamente configurado, eclipsará su código. DexGuard que es una versión comercial ampliada de ProGuard, puede ayudar un poco más. Sin embargo, el código todavía se puede convertir en smali y desarrolladores con experiencia en ingeniería inversa será capaz de averiguar lo que está haciendo el smali. Tal vez elegir un buen licencia y hacer cumplir la ley de la mejor manera posible.

Felipe Monteiro
Posts: 17
Joined: 02 Dec 2014 17:49

Re: Cómo prevenir ingeniería inversa presentar una APK?

Post by Felipe Monteiro » 10 Dec 2014 11:18

& Amp; Nbsp; 1. ¿Cómo puedo evitar completamente la ingeniería inversa de un Android APK? ¿Es esto posible? Imposible & amp; nbsp; 2. ¿Cómo puedo proteger a todos los recursos de la aplicación, los activos y código fuente para que los piratas informáticos no pueden cortar el archivo APK de alguna manera? Imposible & amp; nbsp; 3. ¿Hay una manera de hacer que la piratería más difícil o incluso imposible? ¿Qué puedo hacer para proteger el código fuente en mi archivo APK? Más duro - es posible, pero en realidad será más difícil, sobre todo para el usuario medio, usted apenas está buscando la piratería guías. Si alguien realmente quiere cortar su aplicación - a cortar antes o después.

BUTTON_POST_REPLY