and.roid.es
@androides: @thearcherblog no lo sé, yo hoy lo he probado en la oficial del nexus... ¿a alguien le hace fc Opera Mini con la última de cyanogen?
Síguenos en:
Protege tu aplicación de la piratería
Creo que la preocupación de todo desarrollador de aplicaciones es como evitar que su aplicación sea copiada y distribuida ilegalmente. Pero también está claro que nunca se puede conseguir una protección completa para las aplicaciones instaladas en un terminal. En todos los dispositivos móviles actuales Android, iPhone, Symbian es más o menos fácil conseguir esa aplicación de pago que tanto te gusta de forma no licita.
¿Cómo está ese tema en Android? Cualquiera con root puede copiar y distribuir cualquier aplicación con bastante facilidad. Esta facilidad junto a la opción de devolver las aplicaciones de pago a las 24 horas, te da pocas opciones para poder remunerar tu aplicación.
Aún así, hay ciertos métodos que podemos aplicar en nuestra aplicación. Estos métodos deben centrarse en la protección de los datos, relacionado con alguna característica única del teléfono, autorización contra un servidor propio o un método híbrido. Por ejemplo a mi se me ocurren los siguientes métodos:
- Protección por cuenta de Google: En Android existe un permiso (android.permission.GET_ACCOUNTS) para conseguir la cuenta asociada al teléfono. En la primera ejecución se podría crear un MD5 para asegurar que la aplicación está siendo usada por esa misma cuenta, de forma que una vez utilizada imposibilita el uso por otras cuentas de Google.
- Protección por IMEI: En Android existe un permiso (android.provider.SETTINGS) que permite conseguir el IMEI del teléfono. Sería similar al anterior generar un MD5 relacionado con el IMEI para asegurar que la aplicación está siendo utilizada en el móvil donde se ha comprado.
- Autenticación contra servidor: Obligar a un registro de usuario que será verificado a cada inicio de la aplicación.
- Protección por número de factura: Al comprar la aplicación Google Checkout genera una factura para el vendedor y comprador con un número supuestamente único. En la primera ejecución la aplicación no se desbloqueará a menos que introduzcas la cuenta de Google de la compra y el número de factura. Este método es un híbrido entre servidor de autenticación y datos únicos del teléfono. Sin duda el más complejo, pero requiere un servidor y una aplicación que vaya tratando las facturas automáticamente. Este método ya está siendo usado por CoPilot.
La opción 1 y 2 son una pequeña barrera, pero que limitan que tu aplicación sea prostituida con la facilidad actual. La opción 3, es buena, pero problemática para el usuario si la aplicación puede funcionar sin conexión, estarías cuartando la utilización por parte de los usuarios. La mejor opción sin duda es la 4, pero no obstante requiere una infraestructura de servidor+software de tratamiento de facturas, que complica la vida al desarrollador y seguramente implique un cargo excepcional en el precio final de la aplicación. En conclusión, no hay forma de parar la piratería, pero hay métodos para poner una barrera de entrada alta para que no todo el mundo se una a la fiesta loca de la copia ilegal 
¿Alguna idea más?
17 comentarios para “Protege tu aplicación de la piratería”
App Android de la semana
Encuesta
¿Habrá un boom de tablets con Android?
- Sí, al menos tendrá multitarea (48%, 135 Votes)
- No lo necesito teniendo un móvil Android (40%, 112 Votes)
- Quiero un iPad (9%, 25 Votes)
- ¿Qué es una tablet? (3%, 13 Votes)
Total Voters: 283
Loading ...Comentarios
- iSuriv: Probar Calculate Net Salary Spain Pero a mi me sale.
- Raya: 16. ipaelo: Muchas gracias y mucha suerte a ti también como editor aquí! Muchos ánimos!
17. erchoquero y 18.... - La Gran M: Luego a ver si tengo un rato y lo pruebo, que ya era hora de que lo sacasen!
- Land-of-Mordor: Pues ya permitir la intercomunicación entre aplicaciones me parece un gran paso, visto sobretodo el...
- [LuY]: A mi no me aparece en el market. Buscando por csn – csn spain. Nexus one – Vodafone Irlanda.
Últimos artículos
- Puzzle Tron, Un Clásico de Puzzles
- Actualización Calcular Sueldo Neto (CSN)
- Opera Mini 5 beta recién lanzado
- Android Chip 8 Emulator
- Adobe libera el Photoshop de Android
- Microsoft Tag para Android
- Gesture Search, Buscar mediante gestos
- Google premia a los desarrolladores de Android
- Android vuelve a linux
- Liberada la nueva versión de Android NDK r3
RSS
Bitacoras.com dijo el 17.10.09 a las 12:13:
Información Bitacoras.com…
Valora en Bitacoras.com: Creo que la preocupación de todo desarrollador de aplicaciones es como evitar que su aplicación sea copiada y distribuida ilegalmente. Pero también está claro que nunca se puede conseguir una protección completa para las a…
androidsis dijo el 17.10.09 a las 12:30:
Hola.
La 1 y la 2, hace que la aplicación sea inutil si por ejemplo tengo dos cuentas de gmail y la quiero utilizar en las dos, o si tengo dos teléfonos, ¿tendría que comprar la aplicación dos veces?. La 3 habría que además de registrarse en el servidor tener algún método para saber que la aplicación con número tal la compró fulanito de tal. La 4 creo que es la más acertada y quizás la más difícil de saltarse.
Sin usar un servidor la verdad que es bastante complicado.
Un saludo
rallat dijo el 17.10.09 a las 12:58:
Ahora mismo, sin ningún método de protección, si tienes dos teléfonos con cuentas de distintas tendrás que comprar la aplicación dos veces igualmente. Por lo tanto, no cambia nada el método 1,2,3,4 y no provocan ninguna inutilidad. En cambio, puedes tener como yo, dos teléfonos con la misma cuenta
Respecto a lo que comentas de la 3, le obligas a registrarse en el sentido de que le dejas autenticarse con su cuenta de mail. Es decir, si tu mail compró la aplicación te doy paso, sino no.
Gracias por el comentario!
rocapal dijo el 17.10.09 a las 13:36:
La solución está clara, no hay que basar el modelo de negocio en vender licencias de software. Licencialo como software libre y gana dinero dando soporte o dándole un valor añadido. Sino, el día que tu app sea grande, gastarás todos tus beneficios en juicios y denuncias a quienes piratean el software.
Estaremos de acuerdo en que Google es una buena compañia, con 2 dedos de frente y que tiene muchos beneficios … ¿acaso se dedica a vender software? No
Interesante post!
carthesian dijo el 17.10.09 a las 13:37:
Desde luego los dispositivos móviles permiten poner más trabas a la piratería aunque estoy convencido que aparecerán mercados de aplicaciones pirateadas igual que ocurre con las consolas psp, nds, wii… o como ha ocurrido toda la vida con el software de PC/Mac.
Pero bueno, podemos hacer que no sea tan sencillo como pasarse un mp3.
Aunque (de esto tenemos que escribir otro día) podemos plantear modelos de negocio basados en software libre y gratuito que suelen ser las mejores armas contra la piratería
Escapology dijo el 17.10.09 a las 20:55:
La forma de frenar la piratería es banear de las aplicaciones de pago a los usuarios con acceso root… sin acceso root no hay piratería porque no se pueden distribuir los apk al no tener acceso a esa carpeta del sistema…
Google dejo sin aplicaciones de pago a sus Dev Phones por eso… podían copiar las aplicaciones de pago…
rallat dijo el 17.10.09 a las 21:59:
Creo que es imposible detectar un usuario root y aunque fuera posible, se podría crear una aplicación para evitar ser detectado. Al igual que ahora un usuario root puede entrar en cualquier market con el market enabler. Básicamente el usuario root permite hacer cualquier cosa, ese es el problema jeje.
Gracias por comentar Escapology!!
pelo dijo el 17.10.09 a las 22:07:
Nose porque este articulo, no se supone que la lucha de todos es por software libre?? No mas trabas a la distribucion de software
Escapology dijo el 18.10.09 a las 01:32:
Software libre no significa que sea gratis…
mi dijo el 18.10.09 a las 15:26:
Los primeros metodos serian validos pero, como y donde guardo los datos del usuario de la aplicacion? Se guardan los shared preferences en el APK o las BBDD sqlite?
Porque si esa informacion persiste pero solo en el telefono el usuario puede extraer el apk y la comprobacion se habra ido al garete no es asi?
rallat dijo el 18.10.09 a las 16:37:
@mi gracias por comentar, se guardaría dentro del shared preferences o del BBDD sqlite, en ambos casos se podría encontrar y utilizar por otros, por eso he dicho que ponen vayas pero no cortan el problema
solo hacen un poco más complicado.
mi dijo el 19.10.09 a las 01:29:
Hola rallat, gracias por contestar. Mi duda es acerca de si las shared preferences se mantienen al volcar el apk de un terminal a otro o se guardan dentro de un terminal y al extraer el apk se pierden?
Porque si quedan guardadas en algun lugar del apk instalable no veo ningun problema en usar un poco de criptografia y a ver quien es el majo que lo edita.
saludos! excelente post
Enrique dijo el 10.12.09 a las 20:47:
Escapology, de acuerdo en que “software libre” no es “software gratis”, pero una vez que un usuario adquiere, pagando, su copia de la aplicación, si ésta es libre, tiene derecho a sacar tantas copias y redistribuirlas como le venga en gana. Esa es una de las condiciones para poder ser “software libre”. Así que es perfectamente posible que un usuario pague por una aplicación libre y luego se la copie _legalmente_ a sus amigos. De todos modos, estoy de acuerdo en que no merece la pena romperse mucho la cabeza por la “piratería”. Si tu aplicación es buena, está a buen precio y ofreces servicios adicionales, obtendrás ingresos. Lo de que la gente sólo quiere el “gratis total” es una leyenda interesada…
Enrique dijo el 10.12.09 a las 23:44:
Dos grandes artículos sobre modelos de negocio rentables aún permitiendo la copia libre: http://www.rtve.es/noticias/20091210/modelos-negocio-como-ganar-dinero-mundo-perfectamente-copiable/305282.shtml
http://www.rtve.es/noticias/20091210/modelos-negocio-como-ganar-dinero-mundo-perfectamente-copiable/305322.shtml
Ricardo Amores dijo el 11.12.09 a las 09:55:
Enrique, estás MUY equivocado. Para que sea software libre lo que tiene que ser posible distribuir es el CODIGO, no la aplicación. Por ejemplo, si la aplicación contiene imágenes, sonidos y otro tipo de contenido similar (el ejemplo más claro es un videojuego, con sus dibujos, sonidos, datos de niveles, etc) no podrías distribuir la aplicación, sólamente el código. Y el código de un videojuego sin contenido no te servirá de nada. A no ser que crees tú el contenido.
Sería software libre, pero no gratis ni tampoco podrías distribuir la aplicación.
Y lo de que la gente quiere el gratis total, es cierto, no es leyenda interesada, es simple naturaleza humana.
No hay más que ver cómo la gente se piratea las apps de android, iphone, etc, que la más cara que vi eran 4 euros- y suele ser en en juegos- y los precios rondan el 1-2 eurosv como mucho, que no es dinero. Con 24 horas de prueba con reembolso no hay excusa posible.
Pero sin embargo la gente lo piratea.. y es triste que haya que tomar medidas al respecto
Ricardo Amores dijo el 11.12.09 a las 10:00:
Por cierto, la mejor opción para prevenir el pirateo (pero que tampoco sería totalmente seguro) sería utilizar el primer método pero con una compilación especial de la aplicación para ese cliente que tuviera esa información.
Es decir, el cliente con cuenta X te compra la aplicación, y tú aplicas el método 1 del artículo e incluyes ese MD5 como comprobación en el código directamente (no externa). Así generas una versión de la aplicación específica para dicho cliente.
Sin embargo para poder hacer eso en el market necesitas más infraestructura que en el modelo 4, ya que lo que tendrías que meter en el market es una aplicación “instalador” que al ejecutarla e identificarte pida a un servidor la aplicación y ésta te la suministre (previa generación automática al comprarla)
La cosa está complicada, y como digo tampoco es un método infalible.
Ricardo Amores dijo el 11.12.09 a las 10:10:
Algo parecido usan en el juego Friday Escape, pero no por piratería, sino porque el juego está programado usando el NDK, luego el código es nativo.
El juego, una vez comprado, lo primero que hace es conectarse a un servidor externo y bajar todos los datos para a continuación instalarlos en el móvil, realizando este proceso sólamente la primera vez que se instala.
Esto se hace porque si aparece otro móvil Android con otro procesador distinto de los actuales habría que crear otra versión del ejecutable, y conociendo el móvil desde el cual se intenta instalar, se puede servir el ejecutable /librerías para un procesador concreto u otro.