Determinar si un iPhone está roto por la cárcel mediante progtwigción

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

  1. Jaula rota
  2. Ejecutando una copia descifrada de su software

Pinch Media puede detectar si un teléfono está roto o si el software en ejecución está agrietado, ¿alguien sabe cómo lo hacen? ¿Hay alguna biblioteca?

Esta es una de las formas de detectar si tu aplicación está agrietada.

En resumen: el crackeo generalmente requiere cambiar el Info.plist. Como es un archivo común al que tiene acceso, es bastante fácil determinar dichos cambios.

Detectar un teléfono con jailbreak es tan fácil como verificar la presencia de la carpeta /private/var/lib/apt/ . Aunque esto no detecta usuarios que solo instalan, a estas alturas la mayoría ya tiene instalado Cydia, Icy o RockYourPhone (todos usan apt)

Para detectar usuarios pirateados, la forma más fácil es verificar la presencia de una clave SignerIdentity en SignerIdentity de su aplicación. Como los crackers avanzados pueden encontrar fácilmente el estándar [[[NSBundle mainBundle] infoDictionary] objectForKey: @"SignerIdentity"] , es mejor oscurecer estas llamadas utilizando el tiempo de ejecución de Objective C disponible a través de #import o usar equivalentes alternativos.

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

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

SIN EMBARGO, la persona que desbloquea tu aplicación puede hexeditar tu progtwig y, como tal, pueden editar la cadena @ “SignerIdentity” para leer @ “siNGeridentity” u otra cosa que devuelva nil, y así pasar.

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

  • No esperes que funcione para siempre
  • No utilice esta información para romper / obstaculizar su aplicación de ninguna manera (de lo contrario, tendrán motivos para hexagitarla, por lo que su aplicación no sabrá que está jailbreak)
  • Probablemente sea prudente ofuscar este fragmento del código. Por ejemplo, puede poner la cadena invertida codificada en base64 en su código y luego decodificarla en la aplicación invirtiendo el proceso.
  • Valide su validación más adelante en su código (por ejemplo, cuando dije SignerIdentity, ¿dijo realmente SignerIdentity o siNGeridentity?)
  • No le digas a la gente en un sitio web público como stackoverflow cómo lo haces
  • Tenga en cuenta que es solo una guía y no es a prueba de tontos (¡ni a prueba de craqueo!): Con gran poder viene una gran responsabilidad.

Para ampliar los comentarios de yonel y Benjie anteriores:

1) El método de Landon Fuller que se basa en la verificación de cifrado, enlazado anteriormente por yonel, parece ser el único que aún no ha sido derrotado por las herramientas automáticas de cracking. No estaría demasiado preocupado porque Apple cambie el estado del encabezado LC_ENCRYPTION_INFO pronto. Parece tener algunos efectos impredecibles en iPhones jailbreak (incluso cuando el usuario ha comprado una copia …)

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

2) 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 quizás incluso más fácil es verificar siempre una versión en hash salada del valor que está buscando. Por ejemplo (aunque esa comprobación ya no sea eficiente), debería verificar el nombre de clave de cada MainBundle como md5 (keyName + “alguna sal secreta”) contra la constante apropiada … Bastante básico, pero seguro para vencer cualquier bash de localizar el cuerda.

Por supuesto, esto requiere que pueda consultar indirectamente el valor que desea comparar (por ejemplo, al pasar por una matriz que lo contiene). Pero esto es más a menudo el caso.