2012-02-29 5 views
12

AntiLVL descifra automáticamente la aplicación en la que estoy trabajando (aunque no estoy usando LVL en mi aplicación).¿Cómo debo codificar para resistir la "piratería con un solo clic"?

Para proteger mi aplicación de "piratería con un solo clic", estoy implementando tampering detection techniques explained at Google IO.

He intentado verificar la firma tanto con getPackageInfo() como con la reflexión (invoke()), pero AntiLVL fue capaz de descifrar la aplicación automáticamente en ambos casos.

¿Cómo puedo escribir el código que no se descifrará automáticamente con la versión actual de antiLVL (1.4.0)? Quiero decir, aparte de usar JNI.

PD: No estoy hablando de prevenir la piratería en general. Solo quiero que el pirata profundice en el código a mano en lugar de utilizar un cracker automático.

Respuesta

1

El problema es que cualquier API que solo sirva para verificar la validez de su aplicación se puede subvertir y reemplazar por una versión que siempre arroje el resultado que espera. No he analizado el Anti-LVL en detalle, pero me imagino que está haciendo esto, por lo que sus intentos de verificar su código utilizando las API integradas de Dalvik para este propósito están fallando.

Para que funcione, tendrá que hacer el trabajo usted mismo, utilizando solo API que tienen múltiples propósitos y que no pueden subvertirse tan fácilmente.

Una forma de hacerlo es calcular una suma de comprobación de su archivo .apk o solo el archivo classes.dex dentro de él, y verificarlo con algún recurso externo (servidor en línea con lista de versiones correctas conocidas, archivo descargado a Tarjeta SD en la primera ejecución, etc., recurso en el archivo .apk que no está incluido en classes.dex). Esto evita la modificación del código, que creo que es cómo funciona el anti-LVL. No lo he intentado yo mismo, pero sospecho que debería funcionar.

+0

Gracias por responder. AntiLVL es un hermoso software. Limpio, potente, bien pensado y personalizable. Es "fácil" eludirlo en el sentido de que "solo" necesita escribir un código que no sea capturado por las reglas grep-and-replace (provistas en un archivo xml separado). Sin embargo, simplemente no tengo tiempo suficiente para aprender cómo generar smali inusual. En mi código, AntiLVL fue capaz de desenganchar y castrar todos mis intentos de suma de comprobación. – tos

+0

No sé lo suficiente como para entender la parte de "reemplazo" de las reglas (sería útil saber qué sucede detrás de las escenas). Pensé en tu punto acerca de las API de múltiples propósitos. Pensé en colocar un campo de minas en el software: el programa de descifrado eliminaría una parte importante del programa, lo que podría colapsarlo o inutilizarlo. Hasta ahora no encontré nada. – tos

Cuestiones relacionadas