Pregunta

Estoy intentando hacer un código difícil de descifrar usando Objective-C en una Mac.

Una de las cosas que tengo que hacer es comprobar si la aplicación fue descifrada.

Soy nuevo en Objective-C y Xcode y cualquier forma que imagine para probar mi aplicación siempre termino con una prueba básica que se puede parchear fácilmente.

Por ejemplo:Supongamos que estoy a punto de probar la existencia de un valor determinado en una determinada parte del binario.Esa operación será algo como:

"¿Es este valor = x?" Si no, está agrietado.

Esto es muy fácil de descifrar.El hacker puede parchear fácilmente la prueba y hacer que sea cierta siempre.

Estoy tratando de imaginar algo que pueda probar algo, que no aparezca como una prueba que pueda parchearse fácilmente.

Sé que no puedo detener la piratería al 100%, pero al menos estoy intentando hacer las cosas más difíciles, para disuadir a la mayoría de los crackers que existen.

¿Alguna idea de cómo se pueden hacer cosas como esta y dificultar las cosas para alguien que mira el binario?

Gracias por cualquier ayuda.

¿Fue útil?

Solución

Facilíteles la evaluación de su plan y cámbielo periódicamente.Un ejemplo de libro de texto es realizar la verificación en intervalos impares, lo que les llevará mucho tiempo localizar las fuentes de sus comprobaciones y todas las referencias cruzadas durante el progreso de la evaluación de la licencia.Combine eso con múltiples controles y estará listo para la mayoría de los lanzamientos, solo agregue una buena dosis de creatividad al crear su esquema.Además, es un poco divertido jugar su juego;para lograr que liberen un crack que falla 1 mes después de que se publica el crack...Vale, eso puede resultar contraproducente para ti, pero si te esfuerzas por luchar contra ellos en primer lugar...

Es una comunidad interesante;Si eres nuevo en esto, estudiar las comunidades también te resultará beneficioso.Como se mencionó anteriormente, las grietas ocurren por desafío, algunas versiones de productos simplificarán su esquema de protección de copia para "publicidad gratuita".Entonces...Realmente no puedes luchar demasiado contra el cracking porque si alguien está decidido, sólo te hará perder el tiempo y te frustrará.Observar la cultura puede ser interesante.Probablemente esté en la mejor posición si reconoce que ser descifrado equivale a "software popular" y, por lo tanto, debería estar contento.Por lo general, no deberías perder mucho el sueño por esto (aunque, por supuesto, existen excepciones).Además, como esta pregunta figura en la categoría Mac:No voy a desenterrar estadísticas, pero es menos probable que su software reciba atención de los crackers si su objetivo es OS X.

Si es un programador principiante, el uso inteligente de esa información (y la aceptación) puede ser todo lo que necesita saber para combatir eficazmente a los crackers.

Otros consejos

A menos que su software está relacionada con la seguridad, creo que un mejor enfoque sería para cambiar el plan de licencias para hacer el software libre para usuarios domésticos que apenas utilizan el software y costoso para las organizaciones.

Organizaciones rara vez utilizan el software agrietado, debido a los problemas legales, en tanto que los usuarios domésticos que son usuarios ocasionales no me gusta gastar $ 100s para utilizar el software de vez en cuando.

Esto eliminaría la motivación de galletas para romper el software.

No lo haga. Recuerde, (bien) galletas grieta de software para la diversión. El más elaborado su esquema de protección es, más desafiante y divertido que será para el cracker. Además, las personas que son propensos a utilizar el software de forma ilegal no van a pagar por él de todos modos, incluso si no pueden obtener una versión agrietada. Su tiempo será mejor gastado haciendo que su producto mejor.

Una vez dicho esto, puede disuadir a la mayoría de las galletas de aficionados por extracción de su ejecutable de símbolos de depuración. Vas a tener que permitir esto en las preferencias del proyecto.

Todos los esquemas de protección muy fuertes yo sepa uso código mutante ampliamente , De una manera u otra. Sin embargo, esto es definitivamente no es algo que un programador principiante debe estar preparado para manejar.

Uno de los peligros es que si vas a excesivamente grandes longitudes, puede terminar rompiendo cosas para los usuarios legítimos. Un número de máquinas de arcade de Atari en la década de 1980 tenía código que hacer varias cosas interesantes si se detecta que la ROM se vio alterada. Los efectos serían sutiles; por ejemplo, un juego llamado Tempest otorgaría juegos gratis ilimitadas si el juego terminó cuando un jugador tenía ciertos valores de puntuación. En el comunicado de la ROM de la tempestad, sin embargo, la suma de comprobación se calcula de forma incorrecta, por lo que todas las máquinas tenían este comportamiento. No estoy seguro de que las ganancias en qué medida este error afectadas en máquinas desplegadas, pero me imagino que algunos operadores habrían sido bastante molesto al descubrir a él.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top