2009-05-10 6 views
62

¿Cuáles son los métodos aceptados para reducir la piratería de aplicaciones de iPhone, que no violan el proceso de evaluación de Apple?Reducción de la piratería de las aplicaciones de iPhone

Si mi aplicación "toca la página de inicio" para proporcionar el ID único del dispositivo en el que se ejecuta, ¿qué otra información necesitaría recopilar (por ejemplo, la ID de Apple utilizada para comprar la aplicación) para crear un token de registro válido que autorice uso de la aplicación? Del mismo modo, ¿qué código usaría para acceder a esos datos adicionales?

¿Cuáles parecen ser los mejores enfoques técnicos disponibles para este problema, en este momento?

(Por favor, abstenerse de no responde a la programación acerca de cómo la piratería es inevitable, etc. Sé que la piratería es inevitable. Estoy interesado en respuestas basadas en programación que discutir cómo reducirla. Gracias de antemano por su comprensión.)

+36

Me encantan las preguntas que especifican de antemano qué respuesta quieren escuchar. Así es como obtienes las mejores respuestas. ;) – jalf

+2

Solo trato de cortar los descarrilamientos filosóficos al principio. Las respuestas técnicas son obviamente preferibles. –

+0

@Alex es más fácil evitar las respuestas de "no se puede hacer eso" si no se usa terminología como "derrota" en lugar de "mitigar" –

Respuesta

48

ACTUALIZACIÓN

favor visit and read

Gracias a Chpwn en los comentarios.

¡Código que es demasiado viejo! - 11 de mayo de 2009

Por ahora hay una forma más fácil de detectar si su aplicación de iPhone se ha descifrado para uso de piratería. Esto no implica que verifique los ID exclusivos de iPhone con una lista de ID aceptados.

Actualmente hay tres cosas que hacen las galletas:

  1. editar el archivo Info.plist
  2. decodificar la Info.plist de binario a UTF-8 o ASCII
  3. Añadir un par de claves de info.plist {SignerIdentity, iPhone OS de Apple de aplicaciones de firma}

El último es más fácil de comprobar con este código:

NSBundle *bundle = [NSBundle mainBundle]; 
NSDictionary *info = [bundle infoDictionary]; 
if ([info objectForKey: @"SignerIdentity"] != nil) 
{ /* do something */ } 

general que no tienen SignerIdentity en cualquiera de las aplicaciones de la App Store que construimos lo que la comprobación de cero a continuación, realizan instrucciones del equipo deben hacer que sea más difícil para las galletas y los piratas.

No me puedo atribuir el mérito de esto, por favor visite How to Thwart iPhone IPA Crackers.. Hay mucha información sobre piratería en iPhone y cómo controlarla.

+0

Gracias por responder la pregunta que hice. –

+3

@David Pregunta rápida que nadie puede responder: si esta es una solución tan fácil (potencialmente de 5 líneas), ¿por qué no se ha implementado con más frecuencia? ¿Hay algún inconveniente del que seas consciente? La mayoría VAST de las aplicaciones en la tienda de aplicaciones se han descifrado y están disponibles para su descarga. – mmc

+7

Es muy fácil para el cracker verificar la cadena literal SignerIdentity o llamar al selector infoDictionary. Es probable que desee ocultarlos. La parte "hacer algo" también es engañosa: no se puede fallar de inmediato, ya que esto alarmaría a la galleta.Por lo tanto, debe fallar con una gran demora (tal vez darles una prueba de 30 días y luego pedirle que compre una copia legítima). Ver, hacer que esto sea útil ya no es tan simple. –

5

Como lo señaló Andrey Tarantsov en los comentarios, buscar la cadena "SignerIdentity" en el binario (usando una aplicación como HexEdit) y reemplazarla es bastante fácil.

Podrías codificar esa cadena, pero nuevamente todo lo que tienes que hacer es cambiar un carácter y la aplicación ya no buscará la clave "SignerIdentity" sino para alguna otra clave que probablemente no exista (por lo tanto es nulo). Esa clave es nula, la aplicación cree que no está rota (ya que SignerIdentity debe ser nula si la aplicación no está rajada).

En su lugar, preferiría verificar el tamaño del info.plist y compararlo con un valor de referencia.Noté que las compilaciones de Simulator y Devices no tienen el mismo tamaño de archivo info.plist. Lo mismo ocurre con las compilaciones de Depuración, Liberación y Distribución. Por lo tanto, asegúrese de establecer el valor de referencia utilizando el tamaño del archivo info.plist para la compilación de distribución de dispositivos.

Cómo buscar el filesize at launch:

-1

Comprobar iTunesMetadata.plist de la fecha de Purchace ya que a veces, cuando se quebró una aplicación, esa fecha se cambia a algo extravagante.

También verifique si existe el campo del nombre del comprador. En mi experiencia con el crackeo de aplicaciones para uso personal, generalmente se elimina. Si alguien sabe cómo funciona la protección anti-volcado de Temple Run, podrías usar eso junto con una protección que poedCrackMod no puede obtener (google poedCrackMod crea cuenta hackulo.us, ve al centro de desarrollo busca poedCrackMod, instálalo en iDevice) .

El embrague que no va a romper cosas con Temple Run como protección, tiene una función llamada OverDrive destinada a silenciar la detección de grietas de una aplicación. poedCrackMod tiene LamestPatch, que no es tan bueno. También poedCrackMod es un script de bash de código abierto que puede ser de ingeniería inversa. Para recapitular, tienes una aplicación que tiene protección contra copia que no se puede eludir con embrague/sobremarcha pero que se puede romper con poedCrackMod. Sin embargo, poedCrackMod no puede eludir los controles de piratería de la aplicación en la aplicación. Es difícil parchear manualmente las verificaciones integradas en el ejecutable de la aplicación. Entonces, tu aplicación es difícil de descifrar.

0

Parece que guardar la suma de comprobación MD5 de Plist y comprobar que CryptID debería funcionar hasta cierto tiempo.

Cuestiones relacionadas