Determinar si un iPhone está en la cárcel roto Programáticamente

¿Cómo se determina (mediante progtwigción) si un iPhone / iPod es:

  1. Cárcel rota
  2. Ejecutando una copy rota de su software

Pinch Media puede detectar si un teléfono está en la cárcel o si el software que se está ejecutando está dañado, ¿alguien sabe cómo lo hacen? ¿Hay alguna bibliotecas?

Aquí hay una de las forms de detectar si su aplicación fue rota.

En resumen: el cracking usualmente requiere cambiar el Info.plist. Dado que es un file regular al que tiene acceso, es bastante fácil determinar dichos cambios.

Detectar un teléfono bloqueado es tan fácil como comprobar la presencia de /private/var/lib/apt/ folder. Aunque esto no detecta usuarios que solo instalen, por ahora la mayoría tiene instalado Cydia, Icy o RockYourPhone (todos los cuales usan apt)

Para detectar a los usuarios pirateados, la forma más fácil es verificar la presencia de una key SignerIdentity en SignerIdentity de su aplicación. Dado que los crackers avanzados pueden encontrar fácilmente el [[[NSBundle mainBundle] infoDictionary] objectForKey: @"SignerIdentity"] estándar [[[NSBundle mainBundle] infoDictionary] objectForKey: @"SignerIdentity"] , es mejor ocultar estas llamadas utilizando el time de ejecución Objective C disponible a través de #import <objc/runtime.h> o usar equivalentes alternativos

Solo para ampliar la respuesta de zakovyrya, puede usar el siguiente código:

 if ([[[NSBundle mainBundle] infoDictionary] objectForKey: @"SignerIdentity"] != nil) { // Jailbroken } 

SIN EMBARGO, la persona que arrienda su aplicación puede editar hexadecimalmente su progtwig y, como tal, podría editar la cadena @ "SignerIdentity" para leer @ "siNGeridentity" o algo más que no devolvería nada y, por lo tanto, pasaría.

Entonces, si usa esta (o cualquiera de las otras sugerencias de http://thwart-ipa-cracks.blogspot.com/2008/11/detection.html ):

  • No esperes que funcione para siempre
  • No use esta información para romper / obstaculizar su aplicación de ninguna manera (de lo contrario, tendrán motivos para hexeditarlo, por lo que su aplicación no sabrá si está jailbroken)
  • Probablemente es sabio ofuscar esta parte del código. Por ejemplo, podría poner la cadena invertida codificada en base64 en su código, y luego decodificarla en la aplicación invirtiendo el process.
  • Valide su validation más adelante en su código (por ejemplo, cuando dije SignerIdentity, ¿realmente decía SignerIdentity o siNGeridentity?)
  • No le digas a las personas en un website público como stackoverflow cómo lo haces
  • Tenga en count que es solo una guía y no es infalible (¡ni a testing de crack!): Con gran poder viene una gran responsabilidad.

Para ampliar los comentarios de Yonel y Benjie anteriores:

1) El método de Landon Fuller basado en el control de encriptación, vinculado anteriormente por yonel, parece ser el único que aún no ha sido derrotado por las herramientas automatizadas de cracking. No me preocuparía demasiado que Apple cambie pronto el estado del encabezado LC_ENCRYPTION_INFO. Parece tener algunos efectos impnetworkingecibles en los iPhones jailbreak (incluso cuando el usuario ha comprado una copy …)

En cualquier caso, no tomaría ninguna acción precipitada contra un usuario basado en ese código …

2) Para complementar el comentario de Benjie. ofuscación (una necesidad absoluta cuando se trata de cualquier valor de cadena en su código antipiratería): una forma similar, pero tal vez incluso más fácil, es siempre verificar una versión con hash salada del valor que está buscando. Por ejemplo (a pesar de que esa comprobación ya no es eficiente), verificaría el nombre de key de cada MainBundle como md5 (keyName + "some secret salt") contra la constante apropiada … Bastante básico, pero seguro para vencer cualquier bash de localizar el string.

Por supuesto, esto requiere que sea capaz de consultar indirectamente el valor que desea comparar (por ejemplo, pasando por una matriz que lo contiene). Pero esto es lo más a menudo posible.