Recientemente escribí sobre la protección de la idea de una app y por qué no vale la pena patentarla antes de su lanzamiento real. En cuanto al concepto de diseño, los elementos de la UI y los principios de la UX, hay una parte de ingeniería tan enmarañada como importante para la viabilidad del proyecto.
Si puedes proteger con derechos de autor el diseño y la identidad, ¿qué pasa detrás de las líneas de código? Están protegidas contra el plagio? Cómo es que hay tantos aaps idénticos? ¿Es sólo porque «las grandes mentes piensan igual»? ¿O se está produciendo un desmadre? Intentaré responder a esas preguntas con la ayuda de mis compañeros desarrolladores de móviles.
Lo que puede ocurrir con las apps desprotegidas
El código fuente de las aplicaciones es la esencia de cualquier aplicación. En el código fuente de la aplicación se esconden cientos de horas de trabajo, todo el conocimiento, los descubrimientos, las soluciones con cinta aislante y todas las esperanzas de triunfar. Como el vientre de una bestia es vulnerable y las consecuencias de que se dañe son terribles.
Así que si alguien roba o descompila un trozo del código fuente de tu aplicación, o todo el código, básicamente secuestra tu aplicación de iOS o Android, ¿qué puedes hacer? Los peores escenarios incluyen los siguientes resultados:
- Su aplicación es crackeada. Si tu aplicación es de pago, el villano puede hacer una versión gratuita de la misma y acabar con tu modelo de negocio. Lo más probable es que esto te obligue a abandonar tu proyecto y a idear otro. Difícil decisión.
- Tu app se infecta. Mantienen la app de pago y normal, pero la infectan con virusware o malware para crear esquemas de estafa en posteriores builds. En este caso tus usuarios fieles se llevan una patada en los dientes que arruina todo lo que has construido. Esto es malo y lo más probable es que te obligue a abandonar el negocio, por no hablar de los problemas legales.
- Tu aplicación se convierte en un conejillo de indias. Si la app que has creado tiene algún éxito, tiene diana en la espalda. Si tus competidores se hacen con el código fuente de tu app, la harán pedazos y se quedarán con trozos de tu antigua ventaja competitiva. Lo más probable es que acabe con la vida de tu aplicación.
Ahora vamos a relajarnos un poco y a ver cómo y por qué pueden robar el código fuente de tu aplicación. Una vez que la aplicación está fuera, puedes esperar que la gente empiece a trastear con ellos.
¿Vale la pena la ingeniería inversa de la app?
Así que aparte de todo el drama, que te roben el código es un fastidio que si no arruina tu marca, puede ser una enorme distracción que arrastra el tiempo de lo que realmente importa: tus objetivos de negocio. En Shakuro, consideramos que el código fuente de una aplicación es nuestra responsabilidad al 100%. Su seguridad, protección y resistencia tienen que ser constantemente probadas a medida que se implementan las características.
Seguridad del código de iOS
Nuestras aplicaciones de iOS tienen código escrito en Objective-C y Swift que se compilan en un código binario. El código fuente se almacena en nuestro repositorio privado de GitHub, o en repositorios del lado del cliente. La interacción de los datos del usuario entre la aplicación y el servidor pasa por las funciones nativas de iOS o por un certificado OpenSSL para cifrar el tráfico para una mayor protección.
Esto básicamente convierte nuestras aplicaciones de iOS en cajas negras en las que no se puede ver realmente. Pero con cierta cantidad de persistencia, pueden asomarse desde diferentes ángulos y pescar algo. Las aplicaciones constan de diferentes partes como:
- Ejecutable encriptado – código compilado, el núcleo.
- Metadatos – variables.
- Framework encriptado – módulos.
- Activos – imágenes, cadenas, etc.
La parte ejecutable es la que suele estar blindada para proteger la aplicación de intrusiones. Los frameworks también pueden ser intervenidos. Un ingeniero inverso puede trabajar con dos estados de una aplicación: activo e inactivo. Pueden estudiar el tráfico e inyectar código cuando la aplicación se está ejecutando, y estudiar los binarios cuando la aplicación no se está ejecutando. Descifrar el código binario requiere un amplio conjunto de habilidades dignas de un desarrollador de aplicaciones muy competente.
Además, Swift, al ser una tecnología bastante nueva, es segura por naturaleza, ya que las herramientas para descifrar su código aún no existen. En cuanto a Objective-C, hay múltiples herramientas complicadas que tienen que ser utilizadas específicamente para ciertas partes del proceso de ingeniería inversa y requieren tanto esfuerzo, que casi anula el efecto, por no mencionar que es poco ético e ilegal.
Ofuscación del código de iOS
Si alguien realmente está tratando de descompilar el código Swift, está ofuscado de forma nativa. Citando a hotpaw2 de stack overflow: «Xcode también convierte el código Swift en una especie de representación intermedia bytecode, llamada bitcode por Apple. Pero, IIRC, el código de bits es eliminado por Apple antes de enviar una aplicación a los clientes, y el código compilado de la aplicación también es encriptado por Apple.»
En lugar de dedicar tiempo a complejizar el código de la aplicación que no es visible en la compilación, lo que realmente nos esforzamos por proteger son las bibliotecas del SDK que contienen módulos personalizados.
Además de las características nativas, podemos utilizar Obfuscator que es una herramienta para la ofuscación de cadenas sensibles a la seguridad codificadas. Obfuscator convierte las cadenas en matrices de bytes y en lugar de pasarlas por la aplicación, decodifica las matrices de bytes para revelar las cadenas. No requiere que todo el código de la aplicación sea ofuscado, sino que le da la opción de afectar sólo a las cadenas más cruciales.
Seguridad del código de Android
No hay manera de proporcionar un 100% de seguridad de una aplicación de Android. Si alguien se compromete a entrar en el código de tu aplicación, lo hará. La única forma de combatirlo es dejarlo sin sentido.
En el caso de una app para iOS escrita en Swift es un proceso duro y minucioso, debido a su relativa novedad, pero ¿qué pasa con Java? Lleva décadas en el mercado y hay millones de desarrolladores. Teniendo en cuenta las peculiaridades del sistema operativo Android, he aquí cómo se puede proteger una aplicación. El código fuente de las aplicaciones Android suele estar escrito en Java, pero no se distribuye en las compilaciones como bytecode de Java, sino que se carga en archivos .dex, que pueden descompilarse en código fuente de Java. La única contramedida eficiente en la que la comunidad parece estar de acuerdo es la ofuscación.
Ofuscación del código de Android
Una de las formas más potentes de asegurar un APK de Android es utilizar la ofuscación del código. Esta práctica cambia los nombres de las variables de la app y las clases de forma regular para que las cadenas de código sean confusas y rompan las dependencias. Pero es más que eso. La ofuscación de código también reduce el código, oculta algunos de los fragmentos y lo reduce significativamente. Algunas de las herramientas de ofuscación más populares son:
- Proguard
- DexProtector
Son herramientas sólidas que evitan las intrusiones a través de algunos algoritmos criptográficos fuertes mientras que también inyectan controles de seguridad en el APK de Android. La aplicación puede ser bloqueada una vez que la herramienta se da cuenta de que el código de la aplicación está siendo intervenido.
Las licencias de las aplicaciones de Android
Una característica incorporada que las licencias de las aplicaciones de Android es, es un intento de aplicar una política de licencias flexible sobre una base de aplicación por aplicación – cada aplicación puede hacer cumplir las licencias de la manera más adecuada para ella. Concede una especie de control de acceso a su aplicación.
«Cuando una aplicación comprueba el estado de la licencia, el servidor de Google Play firma la respuesta del estado de la licencia utilizando un par de claves que se asocia de forma exclusiva con la aplicación. Tu aplicación almacena la clave pública en su archivo .apk compilado y la utiliza para verificar la respuesta del estado de la licencia.»
«Por ejemplo, una aplicación puede comprobar el estado de la licencia y luego aplicar restricciones personalizadas que permitan al usuario ejecutarla sin licencia durante un periodo de validez específico. Una aplicación también puede restringir el uso de la aplicación a un dispositivo específico, además de cualquier otra restricción.» Esta característica ya se está utilizando para integrar la seguridad y la transparencia al uso del código de la app del lado del cliente.
Directrices generales de seguridad de la app en Shakuro
Como podría parecer, el código no es la parte más valiosa de tu app, ciertamente es el corazón de una app, pero es casi contraintuitivo lo que cuesta descompilar el código y construir un clon del mismo. En cambio, hay algunas cuestiones específicas de los móviles que afectan al activo más valioso que tienes: la información. El objetivo principal del desarrollador es mantener la información segura y privada.
Almacenamiento de datos
Si una aplicación almacena cualquier dato del usuario, especialmente credenciales, tokens y claves de acceso, esas cosas tienen que estar protegidas mejor que simplemente por un archivo Info.plist. En su lugar, utilice los servicios de llavero del sistema nativo o las bibliotecas de terceros para el almacenamiento seguro. También usar la caché y no hacer copias de seguridad de todos los datos en los servicios en la nube puede ahorrar espacio y evitar que alguien los analice.
Canales de comunicación seguros
El protocolo HTTP es un método de comunicación entre la aplicación y el servidor sin cifrar. Los puntos de Wi-Fi públicos a los que se conectan muchos teléfonos a diario pueden ser el medio para los ataques man-in-the-middle. Así que si se envía algo confidencial o crítico para la seguridad, HTTPS es el canal de comunicación más seguro. Para los protocolos de red personalizados, utilice TLS.
Datos del usuario
A medida que más aplicaciones se integran en nuestras vidas a través de diversas funciones útiles, los teléfonos se convierten en los últimos centros de información personal y sensible que tiene que ser almacenada de manera responsable. Si un usuario concede a tu app acceso a esa información, no debería duplicarse y almacenarse por separado en algún lugar. Hay que tener muy en cuenta dónde se almacena la información y sólo utilizar fuentes no comprometidas.
Consejos específicos para Android
- Evitar Webview debido a las vulnerabilidades de la interfaz Javascript.
- Evitar la redelegación de permisos debido al acceso no autorizado de apps de terceros.
- Evitar Intentos debido a los riesgos de ser intervenidos.
- Evitar Inyecciones SQL debido a la introducción inadvertida de vulnerabilidades.
Finalidad
Una de las mejores maneras de resistir es hacer que el jugo no valga la pena el apretón. El objetivo de la piratería de aplicaciones es robar una aplicación y obtener algún tipo de recompensa por ello. Si la importancia de la recompensa no supera el tiempo y el esfuerzo invertidos, los piratas y hackers oportunistas la abandonarán. A fin de cuentas, también son hombres de negocios… poco éticos e ilegales, pero respaldados por una lógica retorcida.
La inmensa mayoría de los desarrolladores dicen que si alguien quiere hacer ingeniería inversa de una aplicación, lo harán.
Es justo decir que el código fuente no es la razón por la que los clientes aprecian a los desarrolladores. Sí, es el producto y el resultado de todo el trabajo duro, pero no es la razón por la que nos pagan. Cuando los clientes contratan a un equipo, invierten en la solución de su tarea, que va más allá del código. Deciden contratar al equipo en función de sus capacidades técnicas, su experiencia, su modelo de negocio, etc. Nos ganamos a los clientes por la forma en que nos comunicamos y nos esforzamos por entender sinceramente sus proyectos, y mostramos nuestro compromiso con ellos una vez que empezamos.