Manera de proteger de Lucky Patcher / licencia de juego

La respuesta corta no es realmente.

Puede ver un chat de Google IO acerca de algunas prácticas recomendadas para usar la API de licencias, etc. Google IO Anti Pirate

Sé que hay otra charla sobre los patrones generales para frustrar a los piratas perezosos, así, pero no puede encontrar la URL.

En general, si su protección depende de si / luego lógica todo lo que alguien tiene que hacer es parchear el código e invertir esa lógica o pasar por alto todo lo que es bastante fácil en Java.

Puedes hacerlo más difícil ocultando donde estás haciendo esto, haciéndolo en muchos lugares, haciéndolo al azar, y añadiendo ofuscación pro-guard, etc. para disuadir a los hackers casuales.

Incluso la lógica del lado del servidor es simple de omitir a menos que el paquete de devolución se utilice de alguna manera (como un token de cifrado que se sincroniza con el usuario o la información del teléfono para desbloquear el contenido o un esquema de verificación de id de usuario que se requiere para acceder al contenido de la comunidad en línea, etc. .)

Al final, si alguien está determinado y tiene habilidades que pueden obtener alrededor de todo, ya menos que están perdiendo graves ingresos que no vale la pena perder el sueño en mi opinión, que es un problema que todos necesitamos tener!

Después de hacer esto durante 20 años (desarrollo comercial) mi enfoque es hacer que sea difícil mediante el uso de los patrones anteriores, y cambiar de vez en cuando. Eso elimina a los perezosos piratas.

A continuación, olvídese de ella y concentrarse en hacer una aplicación que vale la pena robar por los pro-piratas.

MI ACERCAMIENTO

Mis aplicaciones son principalmente orientadas al contenido.

En general, si alguien compra contenido, se cifra utilizando los tokens del lado del servidor y sin codificar usando el mismo (que no se almacenan sino que generan cada sesión usando fichas de dispositivo y de usuario, lo que hace que sea un poco más difícil de falsificar honestamente)

A continuación, puedo seguir el acceso por el usuario / dispositivo emparejamientos. La desventaja para el hacker es que tienen que pagar una vez, y si sus fichas se están utilizando repentinamente más allá de límites razonables me alerta al hecho, y puedo apagar esa cuenta si quiero (y tengo)

He descubierto que las personas socialmente son mucho menos propensas a dejar que alguien use la información para engañar si se asocia con ellos (aunque ha sucedido) y volverá sobre ellos.

Sigo siguiendo todos los consejos de IO / Dev Blog, etc y si detecto la manipulación, entonces informar al usuario y luego dejarlo ir por el período N de tiempo para que puedan ponerse en contacto conmigo o auto correcto.

Yo también nunca matar una aplicación, pero le digo al usuario que están utilizando malware, y les pregunto si realmente confía en la persona que robó con sus datos, etc esos tipo de pop-up tienen bit'd mensajes tan sencillo búsqueda de cadenas ganó 'T trabajo etc y echar un susto en la gente

También tengo una manera de enviar una ficha de veneno conjunto para el dispositivo que en esencia bloquear los datos que han acumulado con el dispositivo a menos que lo desbloqueo, pero es mejor estar realmente seguro de que son ladrones antes de ir nuclear en ellos.

También no descontar analíticos como una manera de detectar, y determinar la acción apropiada a tomar cuando una copia pirateada se detecta.

Siga las directrices de la publicación del blog y la OI mencionó, a continuación, ser creativo en la aplicación de ellos, y la mezcla de algunos de lo único solución, a continuación, cambiar de vez en cuando para dar a los piratas se ajusta.

Para evitar que su aplicación se distribuya y vuelva a empaquetar en forma agrietada, consulte la siguiente sección para obtener una comprobación de firma. Entonces por lo menos las únicas personas que pueden hacer que su aplicación funcione son aquellos que tienen LuckyPatcher instalado. Una vez que LuckyPatcher crea un APK modificado, se cambia la firma.

Necesita averiguar cuál es su firma cuando ha ejecutado una versión de lanzamiento. En el ejemplo siguiente es -343553346.

String sigChk = MySigCheck.MySigCheck(context); if (sigChk.equalsIgnoreCase("Y")){ handle signature pass } 

Crear una clase

 public class MySigCheck { public static String MySigCheck(Context context) { String sigChk = "B"; Signature[] signature = new Signature[0]; try { signature = context.getPackageManager().getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES).signatures; Log.d("yourapp", Integer.toString(signature[0].hashCode())); << Prints your signature. Remove once you know this and have changed it below. } catch (PackageManager.NameNotFoundException e) { e.printStackTrace(); } if (signature[0].hashCode() == -343553346){ sigChk = "Y"; } return sigChk; } } 

Base en el hecho de que LuckyPatcher utiliza reemplazo odex para su propósito de piratería. Creo que la forma modesta de derrotar su implmentación actual es compilar su importante pieza de código en dex separado, y cargarlo a través de DexClassLoader.

Ref: http://android-developers.blogspot.pt/2011/07/custom-class-loading-in-dalvik.html

La forma en que lo hago, es mantener un ojo en el nombre del paquete de patcher afortunado, en caso de que lo cambien. Así que en tiempo de ejecución comprobar si está instalado, y simplemente no permiten utilizar mi aplicación si ésta está realmente instalado en el teléfono, incluso si compró la aplicación. Advierto al usuario y mato mi aplicación. Así que tendrá que encontrar otra manera de romperlo. Lo peor que puedo conseguir es que tiene que comprar mi aplicación y seguro que pondrá una mala crítica. Pero honestamente, yo prefiero 1 mala revisión de un hacker de 1000 copias piratas al día.

Como ingeniero informático profesional y usuario de energía general (Linux, Windows, Android, OS X, iOS) tan cómodo en interfaces de línea de comandos como gráfica, uso las herramientas a mi disposición para lograr mis objetivos. No podría imaginar usar un dispositivo androide que no esté arraigado, y soy cargado normalmente con una plétora de utilidades que lo requieren. Por lo menos, disfruto de la libertad de controlar el bloatware obligatorio que viene normalmente con mi dispositivo preferido, insertando mis propias aplicaciones del sistema, y ​​haciendo modificaciones legítimas para la estética, la comodidad, y la conveniencia.

Me han forzado algunas avenidas dudosas sólo para lograr la funcionalidad adecuada en aplicaciones cuyos autores optan por paralizar a los usuarios enraizados. Al ser informado de que mi dispositivo tiene "modificaciones no autorizadas" por (por ejemplo) Virgin TV Anywhere hace que mi sangre hierva, y felizmente romperé su código y contravendré algunos acuerdos de licencia si es la única opción disponible para mí en busca de la funcionalidad esperada.

En este sentido, estoy de acuerdo en que está invitando a muchos usuarios, ya sea por rencor indignado o mera utilidad, para frustrar sus esfuerzos en caso de que elija un camino tan draconiano como la solicitud de medios antes mencionados. Esto podría incluso fomentar la piratería de su aplicación en conjunto cuando las versiones 'fijas' de su código se vuelven más frecuentes como torrents que sus ventas legítimas.

Personalmente, siempre voy a ir por la opción de pago, incluso cuando estoy obligado a tragar mi sentido de seguridad y romper con herramientas que apenas confiar para que funcione. Para muchos, sin embargo, la exposición inicial que tendrán a su producto es a través de canales nefastos, y apenas van a ir a pagar por la versión legítima y desesperadamente lisiado.

Entiendo por qué algunos codificadores se ven obligados a tomar estas decisiones, y es bueno ver preguntas sensatas sobre la forma correcta de proteger la propiedad intelectual.

Es aún más tranquilizador ver sentido en las respuestas.

Sólo mi tuppence.

La única forma en la que he oído hablar es hacer la verificación del servidor … haz que tu aplicación contacte con un servidor y comprueba que compraron tu aplicación.

Se trata de la facturación en la aplicación a través de Google, ¿Por qué la verificación de firma en el servidor remoto es más segura que en el dispositivo?

Una buena información sobre el sitio de desarrollo de Google Play en general aquí y en la aplicación de facturación específicamente aquí

Desafortunadamente no encuentro mucho más …

Si tienen un dispositivo enraizado el puede ocultar el binario su para usar la aplicación también la comprobación de la raíz es el mejor método a menos que su puede ser utilizado con la versión no enraizada de la libertad y, a continuación, tendrá que arreglar eso. Poner un cheque para la herramienta de hacking como el asesino del juego va a detener a las personas perezosas, pero no uno que puede descompilar un cambio de la cadena a otro.

Lucky Patcher trabaja en un dispositivo con raíces. Comprobar que el teléfono está arraigado o not.in mi primera actividad comprobar si el teléfono es de raíz, mi aplicación bloqueada de lo contrario mi apertura de la aplicación.

Check es root con el siguiente método:

  private static boolean isRooted() { return findBinary("su"); } public static boolean findBinary(String binaryName) { boolean found = false; if (!found) { String[] places = {"/sbin/", "/system/bin/", "/system/xbin/", "/data/local/xbin/", "/data/local/bin/", "/system/sd/xbin/", "/system/bin/failsafe/", "/data/local/"}; for (String where : places) { if ( new File( where + binaryName ).exists() ) { found = true; break; } } } return found; }