¿Merece la pena Dexguard? ¿Alguien lo ha usado?

[josemwarrior]

Buenas a todos chicos,

tengo la siguiente cuestión, tengo una app gratuita, pero que se desbloquea mediante compra in-app (ya lo tengo implementado). Como la capa de seguridad que te ofrece Google, es finiiiisiiimaa, no quiero que venga un hacker (o cracker) la hackee ("crack-quee" o como se diga en español) y despues suba la app desbloqueada a varios markets piratas.

Entonces me estuve documentado sobre Proguard, para ofuscar el código fuente. Pero Proguard es para java generico, pero existe una versión mejorada especifica para Android llamada Dexguard, pero es de pago (para ser exactos 480 € para una sola app) que tiene algunas caracteristicas mas que Proguard.

http://i.imgur.com/Ih4ewHl.png

Digamos que esta versión protege el terminal contra el ataque pasivo o estático, ingeniería inversa.

Hay otra versión Enterprise (que sobrepasa los 2.000 euros) que esta si que te protege contra ataques dinamicos, runtime, debuggin en tiempo real, emulación, si detecta (root y root hiding mode), tampering, etc.

¿Cómo veis el uso (y pago) de esta versión estandar? Alguien la esta usando y que tal le va?

Agradecería cualquier tipo de comentario (incluso un saludo también seria bien recibido :hola:).

Se que no existe protección 100% absoluta contra una apk hecha en bytecode, pero la cosa sería ponérselo más difícil a los crackers. :sisi1:

[mocelet]

Bienvenido al foro ;)

Si lo que te preocupa es la seguridad de las compras in-app, supongo que lo estarás haciendo con un servidor que compruebe la compra. Si la comprobación se hace en local no hace falta ni siquiera que modifiquen tu app para desbloquearla, con hacerse pasar por el servicio de licencias de Google Play ya engañan a tu app.

En otros escenarios, como p.ej. los juegos, está de moda cambiar las puntuaciones o las monedas gracias a programas, incluso hay tutoriales en este foro. Ahí sí viene bien la protección contra el cambio de valores en memoria, aunque yo usaría métodos más baratos como hashes de los valores importantes para detectar alteraciones.

La experiencia dicta además que mientras más perversiones se hagan al bytecode más fácil que falle la aplicación sin saber por qué, especialmente si se usan bibliotecas de terceros.

[kriogeN]

ProGuard tampoco es que haga mucho, lo único que hace es renombrar las clases, las propiedades y los métodos para que sea "menos intuitivo" encontrar una función concreta en el código.

Aunque precisamente (como ya sabrás si estás usando ProGuard) la clase que interviene en el proceso de compra InApp no puedes ofuscarla.

Quien quiera piratearte la app lo va a hacer, de hecho si no estás usando un servidor para comprobar la compra hay muchísimas utilidades que simulan la compra, incluso sin ser Root, con lo cual no se tienen que molestar ni en crackearla.

EDIT: Se me adelantó Mocelet con lo de las apps que simulan compras :)

[josemwarrior]

Si lo que te preocupa es la seguridad de las compras in-app, supongo que lo estarás haciendo con un servidor que compruebe la compra. Si la comprobación se hace en local no hace falta ni siquiera que modifiquen tu app para desbloquearla, con hacerse pasar por el servicio de licencias de Google Play ya engañan a tu app.

En otros escenarios, como p.ej. los juegos, está de moda cambiar las puntuaciones o las monedas gracias a programas, incluso hay tutoriales en este foro. Ahí sí viene bien la protección contra el cambio de valores en memoria, aunque yo usaría métodos más baratos como hashes de los valores importantes para detectar alteraciones.

La experiencia dicta además que mientras más perversiones se hagan al bytecode más fácil que falle la aplicación sin saber por qué, especialmente si se usan bibliotecas de terceros.

ProGuard tampoco es que haga mucho, lo único que hace es renombrar las clases, las propiedades y los métodos para que sea "menos intuitivo" encontrar una función concreta en el código.
Aunque precisamente (como ya sabrás si estás usando ProGuard) la clase que interviene en el proceso de compra InApp no puedes ofuscarla.
Quien quiera piratearte la app lo va a hacer, de hecho si no estás usando un servidor para comprobar la compra hay muchísimas utilidades que simulan la compra, incluso sin ser Root, con lo cual no se tienen que molestar ni en crackearla.

Muchas gracias a ambos, dexguard hace mas que proguard, encripta las clases.
Alteraciones mediante hashes también lo tengo implementado.
Lo de montar un server para validar las compras lo veo muy engorroso consumiría muchas horas para lanzar el producto final. Digamos que al final también devolvería un valor booleano de si si o si no? cierto?

El API de Google de compras inapp va por la v3 (version 3), y han añadido algunas mejoras de seguridad in app, ambos me habéis dicho que se puede hackear sin ser root y fácilmente, digamos que si yo os diera acceso a la beta de mi app (en un futuro), sin que os tomara mucho tiempo, ni que tuvieras que calentaros mucho la cabeza, podríais hacer una miniprueba y engañarla? A ver si se rompe tan fácil?

EDIT: si conseguimos burlar la app, creo que reforzare la seguridad con un server checkeando las compras.

[kriogeN]

Muchas gracias a ambos, dexguard hace mas que proguard, encripta las clases.
Alteraciones mediante hashes también lo tengo implementado.
Lo de montar un server para validar las compras lo veo muy engorroso consumiría muchas horas para lanzar el producto final. Digamos que al final también devolvería un valor booleano de si si o si no? cierto?

El API de Google de compras inapp va por la v3 (version 3), y han añadido algunas mejoras de seguridad in app, ambos me habéis dicho que se puede hackear sin ser root y fácilmente, digamos que si yo os diera acceso a la beta de mi app (en un futuro), sin que os tomara mucho tiempo, ni que tuvieras que calentaros mucho la cabeza, podríais hacer una miniprueba y engañarla? A ver si se rompe tan fácil?

Sobre la validez de las compras, no es así exactamente. Cuando realizas la compra el servidor de Google te da unas keys, entonces ya en otro proceso distinto al de la compra en sí compruebas en TU servidor si esas keys son válidas (tu servidor se comunica con el de Google para comprobarlo) en el caso de que lo sean aceptas la compra como válida.

Si te hackean la app se salta igualmente, pero en el caso de las apps que simulan las compras como las keys que generan no son válidas ya sería TU app la que invalidaría la compra. Digamos que añade un paso extra que al no usar servidor no tienes.

Al final es como dice un amigo, la app más segura del mundo es la que se ejecuta en una nube. El resto consideralas hackeadas.

[mocelet]

Estando esos "inventos" para simular compras, que hackeen el código para quitar la protección es lo de menos. No uso ningún sistema de esos, así que no he probado su eficacia, pero ya doy por hecho que si alguien quiere piratear una app en Android lo puede hacer.

Y si alguien modifica tu app, le quita la protección y lo sube a otro market alternativo, lo que está subiendo es una versión concreta. Aquí ya depende de qué tipo de app hablamos, pero si es una app que justifique tener actualizaciones frecuentes siempre va a dejar descolgado al usuario "pirata" y si le resulta útil la app comprenderá el valor de comprarla.

O si la app requiere servidor para algunas funciones, si detectas que han pirateado una versión puedes sacar una actualización con otro mecanismo y evitar que las anteriores se conecten.

[josemwarrior]

Sois unos cracks, ya te digo es por eso, al fin y a cuentas aunque tu les pases unas keys y el servidor compruebe que eres tu, al final dentro de tus app habra algo como (if respuestaServidorSobreSiSonMisKeys == true), lo valida otro servidor pero al final es en tu app en local cuando tienes la llave de abrir o cerrar.

Es un tema interesante, pues mi app, mocelet, digamos que es sobre Personalización del dispositivo, por supuesto que podría añadir mas actualizaciones (como casi en todas las apps), pero estas no seran vitales, tampoco proporcionan ninguna utilidad, ya que es de adorno.
Es cierto que la app mas segura es la que se ejecuta en la nube, pero al ser una app de personalización del dispositivo, no puede estar en la nube :/

A golpe de buscador he encontrado estos cuatro términos por el foro:
Lucky patcher
Gamecih
GameGuardian
freedom apk

Probare hackear mi propia app, si no lo consigo hacer, os solicitare ayuda, por suerte dispongo de un terminal rooteado. Intentare marear estas apps, a ver si tengo suerte. ;)

[kriogeN]

Sois unos cracks, ya te digo es por eso, al fin y a cuentas aunque tu les pases unas keys y el servidor compruebe que eres tu, al final dentro de tus app habra algo como (if respuestaServidorSobreSiSonMisKeys == true), lo valida otro servidor pero al final es en tu app en local cuando tienes la llave de abrir o cerrar.

Es un tema interesante, pues mi app, mocelet, digamos que es sobre Personalización del dispositivo, por supuesto que podría añadir mas actualizaciones (como casi en todas las apps), pero estas no seran vitales, tampoco proporcionan ninguna utilidad, ya que es de adorno.
Es cierto que la app mas segura es la que se ejecuta en la nube, pero al ser una app de personalización del dispositivo, no puede estar en la nube :/

A golpe de buscador he encontrado estos cuatro términos por el foro:
Lucky patcher
Gamecih
GameGuardian
freedom apk

Probare hackear mi propia app, si no lo consigo hacer, os solicitare ayuda, por suerte dispongo de un terminal rooteado. Intentare marear estas apps, a ver si tengo suerte. ;)

Obviamente, al final tienes un salto que se realiza si la comprobación de tu servidor es cierta y otro si es falsa.

Recuerdo en mis tiempos cuando hackeaba aplicaciones de Windows, la mayoría eran bastante simples y al final todo se limitaba a buscar el punto donde estaba la comprobación de la licencia donde normalmente había una instrucción "je .....", la cambiabas por "nop" y listo.

En cuanto a las apps que has mencionado, estás mezclando conceptos:

Lucky Patcher y Freedom son aplicaciones para simular compras in app (Lucky Patcher hace más cosas además de eso), mientras que GameGuardian y GameCIH son aplicaciones para hacer búsquedas y sustituciones en la memoria, vamos, aplicaciones para trucar juegos, lo que en Windows sería Cheat Engine.

[josemwarrior]

Lucky Patcher y Freedom son aplicaciones para simular compras in app (Lucky Patcher hace más cosas además de eso), mientras que GameGuardian y GameCIH son aplicaciones para hacer búsquedas y sustituciones en la memoria, vamos, aplicaciones para trucar juegos, lo que en Windows sería Cheat Engine.

Apuntado, en primer lugar reforzare el sistema de compras y la "seguridad" en local, después investigare más a fondo sobre estas herramientas, y después haré la app :sisi1::sisi1:
Supongo que al final todo sera cuestión de investigar, es decir, sera hackable si o si, pero lo que no quiero que un cracker que se dedica a crackear al día 200 apps, lance un batch automático para crackearla, sino que se tenga que poner abrir y tomarse mas de diez minutos en crackearla.
Si saco algo en claro, os lo comentaré.

[Dexafree]

Algo que te recomiendo si te preocupa la seguridad es que, si usas claves para cifrar/descifrar, no las pongas como

private final static String MI_PASSWORD_SUPER_SECRETO = "pepitodelospalotes";

Sino que te curres un poco alguna rutina de cifrado implementando las clases (el codigo de un AES256 lo encontraras en mil sitios), y las keys las guardes como byte[]

Luego, si llamas Cifrador a la clase, no das pistas sobre que tipo de algoritmo es, y añades una pequeña capa extra.
Lo digo porque me paso una vez comprobando la seguridad de una app, que la comprobacion estaba hecha tal que asi:

String password = AES256.encrypt(cuentaDelUsuario + "nombre_de_la_app");

boolean isOk = edittext.getText().toString().equals(password);

Y la app tenia proguard.
A lo que me refiero es que aunque metas proguard, los String literales los respeta, así que por mucho que descifren podran encontrarlo.

Haciendole un base64 a la contraseña (OJO, BASE64 no es metodo de cifrado ni de hash) y guardandolo como byte[] ya añades una pequeña capa.

Si alguno se aburre y se pone a intentar seguir toda la logica, lo podra terminar sacando, pero al menos ya haces que se tire un ratillo.

[kriogeN]

Algo que te recomiendo si te preocupa la seguridad es que, si usas claves para cifrar/descifrar, no las pongas como

private final static String MI_PASSWORD_SUPER_SECRETO = "pepitodelospalotes";

Sino que te curres un poco alguna rutina de cifrado implementando las clases (el codigo de un AES256 lo encontraras en mil sitios), y las keys las guardes como byte[]

Luego, si llamas Cifrador a la clase, no das pistas sobre que tipo de algoritmo es, y añades una pequeña capa extra.
Lo digo porque me paso una vez comprobando la seguridad de una app, que la comprobacion estaba hecha tal que asi:

String password = AES256.encrypt(cuentaDelUsuario + "nombre_de_la_app");

boolean isOk = edittext.getText().toString().equals(password);

Y la app tenia proguard.
A lo que me refiero es que aunque metas proguard, los String literales los respeta, así que por mucho que descifren podran encontrarlo.

Haciendole un base64 a la contraseña (OJO, BASE64 no es metodo de cifrado ni de hash) y guardandolo como byte[] ya añades una pequeña capa.

Si alguno se aburre y se pone a intentar seguir toda la logica, lo podra terminar sacando, pero al menos ya haces que se tire un ratillo.

De hecho eso es lo que hacen las apps que ofuscan Strings, meten una función que descifra cadenas, y a todas las String les mete una capa del estilo getString() donde pasan la cadena ofuscada.

[josemwarrior]

Algo que te recomiendo si te preocupa la seguridad es que, si usas claves para cifrar/descifrar, no las pongas como

private final static String MI_PASSWORD_SUPER_SECRETO = "pepitodelospalotes";

Sino que te curres un poco alguna rutina de cifrado implementando las clases (el codigo de un AES256 lo encontraras en mil sitios), y las keys las guardes como byte[]

Luego, si llamas Cifrador a la clase, no das pistas sobre que tipo de algoritmo es, y añades una pequeña capa extra.
Lo digo porque me paso una vez comprobando la seguridad de una app, que la comprobacion estaba hecha tal que asi:

String password = AES256.encrypt(cuentaDelUsuario + "nombre_de_la_app");

boolean isOk = edittext.getText().toString().equals(password);

Y la app tenia proguard.
A lo que me refiero es que aunque metas proguard, los String literales los respeta, así que por mucho que descifren podran encontrarlo.

Haciendole un base64 a la contraseña (OJO, BASE64 no es metodo de cifrado ni de hash) y guardandolo como byte[] ya añades una pequeña capa.

Si alguno se aburre y se pone a intentar seguir toda la lógica, lo podrá terminar sacando, pero al menos ya haces que se tire un ratillo.

Wow! de hecho se ve que ya has pasado por el camino que voy recorriendo.
Pues tengo pensado compilar en C, parte de la clave publica y recuperarla a través de un JNI, solo una parte, porque "no se pueden poner todos los huevos en la misma cesta" :B. Y otra técnica buena aun, pero que no quiero compartirla públicamente en un foro.

EDIT: ya que uso mi mismo seudónimo en todos lados, y un hacker español podría dar buena cuenta de ello jjej, pero no me importara compartirla por privado.
Por cierto, Proguard no te encripta las strings pero Dexguard si. :)

He tomado buena nota de tus consejos y los seguiré al pie de la letra.

Lo de checkear el valor de compra a través de un server propio, me parece muchísimo trabajo extra.
Mi objetivo es que no se pueda engañar con una aplicación automática fácilmente. Si cuando la termine, es así, pues ya si le meto mano a chequear el valor de compra.
Vamos me buscare la manera para que no sea algo trivial. :)

[mocelet]

Como te decíamos, si no compruebas con el servidor lo tienen muy fácil porque no hace falta modificar tu app para nada, con interceptar la llamada al servicio de Google y responder que la compra fue correcta tu app se lo cree y validará la compra falsa.