¿Es posible alojar de forma remota un recurso utilizado en una aplicación para Android de tal manera que sólo pueda utilizarla mi aplicación?

Básicamente lo que estoy tratando de lograr es alojar un archivo CSV que será recuperado y utilizado por mi aplicación como fuente de datos para rellenar algunas tablas. El CSV se actualizará con los datos más recientes, y veo que de vez en cuando la aplicación recibirá la última versión para asegurar que los datos dentro de ella estén actualizados.

Mi pregunta es si es posible asegurar que este recurso CSV remoto solo sea usado por mi aplicación.

Presumiblemente si acabo de hacer una URL de plan en la ubicación de la CSV esto podría ser olfateado y el camino utilizado por otros. No veo cómo podría restringir el acceso a él ya que los usuarios podrían estar utilizando la aplicación de casi cualquier conexión.

Si utilizo algún tipo de encriptación en el archivo, ¿podría estar expuesta la clave de descifrado si alguien descompiló el archivo java apk?

¿Hay otros enfoques para asegurar que mi fuente de datos csv sólo sea utilizada por mi aplicación?

Gracias

(Estoy usando un CSV porque los datos no son muy complejos, y no garantiza una base de datos, he leído un poco sobre el enfoque de la base de datos de App-> webservice-> a este problema al usar una base de datos)

La pregunta que usted pide, debe ser: ¿qué tan difícil puedo hacer que vivan las galletas? Si está distribuyendo su aplicación a través de la tienda, eche un vistazo a esta pregunta , aunque esté marcado fuera del tema, las respuestas y los enlaces son valiosos.

Supongo que su aplicación no es gratuita (ya que el .csv parece valioso), así que tenga una mirada más profunda en la Biblioteca de verificación de licencias y este blogpost , esp. Las partes Técnica: Licencia de descarga de licencia a un servidor de confianza y Técnica: Hacer su aplicación resistente a la manipulación .

En breve y por lo que yo entiendo, la forma en que usted va es la siguiente:

Cargue su apk en google con su clave pública de RSA.
Implementar la solicitud LVL dentro de su aplicación (sin encriptación y sin la clave privada dentro del paquete de aplicación **
Enviar la respuesta lvl a su servidor con la publicación a través de una conexión SSL segura
En su servidor de confianza, utilizando su clave privada RSA debe comprobar las cosas mencionadas en el blogpost, esp. Poner los ID de usuario solicitados en una base de datos y contar las solicitudes de un solo UID, si es mucho más alto que el promedio, puede asumir que este ID de usuario sea el que se utilizó para las solicitudes no válidas.
No responda si algo sale mal con el cheque
Si todo está bien, conteste con su csv. Sólo persiste sus datos en el cliente android, si desea que el usuario use el csv sin conexión, de lo contrario cualquier dispositivo enraizado o agrietado apk podría obtener acceso y redistribuir el csv – mejor: sólo empujar las partes solicitadas (por ejemplo, las líneas) de csv a el usuario

Ver esta pregunta y los ataques de repetición de búsqueda y cómo prevenirlo, para no permitir que nadie repita una llamada que proporcionó el csv o partes de él (por ejemplo, números de secuencia por UID).

Ofuscar su código tan bueno como sea posible para hacer el trabajo aún más difícil, como @VinceFR mencionado ya.

Todavía hay algunos ataques, como estos dos:

Root del dispositivo e inspeccionar el csv almacenado, que redistribuir – es por eso que no desea almacenar su csv en el cliente
Ingeniería inversa de su aplicación, registro de la esperanzadamente completa csv que obtuvieron y utilizarlo, probablemente eliminar el código LVL para utilizar su aplicación de forma gratuita – es por eso que todavía tiene que ofuscar y enviar sólo las partes solicitadas

Incluso checksumming, usando PackageManager , apk firma etc pp no lo hará por el 100%.

Pero de hecho, hasta que el cliente primero descarga el csv (o cualquier otro dato) sus datos se guardan. Es incluso ahorrar, siempre y cuando usted puede confiar en sus usuarios (por ejemplo, círculo de usuario limitado de confianza para una aplicación interna o algo así, entonces usted debe preferir androids vpn opciones para acceder al archivo). Después de eso, es sólo una cuestión de tiempo y esfuerzo para poner en la grietas de su aplicación y obtener el valioso csv – y la cuestión es, si vale la pena para cualquier persona poner ese tiempo en ella.

Un enlace adicional que proporciona más información y enlaces sobre LVL por Justin Case .

Tener una buena lectura en todos estos enlaces y recordar: lo que es lo suficientemente duro para que sea inestimable no puede detener las galletas que están tomando el valor del éxito – lo que quiero decir es, el cracking algún tipo de un software "crack-proof" es Más valioso, incluso sin conseguir pagado o algo, para algún tipo de personas.

PS: vea esta respuesta en otra pregunta, para un software "a prueba de crack" – pero incluso un sitio web y sus datos pueden ser duplicados constantemente, si vale la pena.

Además de todas las otras respuestas aquí, hay un post en el blog de desarrolladores de Android titulado "Verificación de llamadas de fondo de aplicaciones de Android", que también debería ser de interés para usted, por si acaso no lo ha encontrado todavía.

No, no es posible.

Como usted sospechaba, su aplicación siempre puede ser ingeniería inversa para revelar cómo obtener el recurso.

Si utiliza un cifrado casero (basado en tipos de cifrado bien conocidos), otras aplicaciones podrían leer su archivo CSV, pero su aplicación será la única que lo comprenda. Para aumentar la complejidad de ingeniería inversa de su código de cifrado, puede crear un cifrador que mezcla Java y C (use JNI ), y por supuesto, no olvide usar proguard u otro obfuscator.

Como se mencionó, si su aplicación puede llegar a los datos, entonces con un poco de esfuerzo de terceros pueden llegar a ella también.

Sin embargo, una solución de baja tecnología simplemente podría establecer el http referer a su aplicación y comprobar que en su servidor.

Sólo mantendrá a los usuarios no autorizados, pero para algunos casos de uso la relación de retorno / esfuerzo puede ser suficiente.