Necesito consejos para diseñar el software 'a prueba de grietas'

Question

Actualmente estoy trabajando en un proyecto donde necesito crear una arquitectura, framework o cualquier estándar por el cual pueda "al menos" aumentar el método de cracking para un software, es decir, para agregar a la seguridad del software. Ya hay diferentes formas de activar un software que incluye activación en línea, claves, etc. Actualmente estoy estudiando algunos trabajos de investigación. Pero todavía hay muchas cosas de las que quiero hablar.

¿Podría alguien guiarme a algún foro decente, lista de correo o algo así? o cualquier otra ayuda sería apreciada.

Answer 1

¿No es un signo de éxito cuando se rompe el producto? :)

En serio, un enfoque es utilizar objetos de licencia que se serializan en XML y luego se encriptan usando pares de claves públicas/privadas. Luego se vuelven a leer en el tiempo de ejecución, se deserializan y se procesan para garantizar que sean válidos.

Pero todavía existe el omnipresente método "IsValid()" que se puede descifrar para que siempre sea verdadero.

Incluso podría poner ese método en un ensamblaje firmado para evitar manipulaciones, pero todo lo que ha hecho entonces es crear otra capa de "IsValid()" que también se puede descifrar.

Usamos licencias para activar o desactivar diversas funciones en nuestro software, y para validar períodos de soporte/actualización. Pero esto es solo para nuestros clientes legítimos. Cualquiera que quiera eludirlo probablemente podría.

Confiamos en que nuestros clientes legítimos no intenten eludir las licencias, y aceptamos que nuestros clientes ilegítimos encuentren la manera.

Perderíamos más dinero tratando de imponer la naturaleza "a prueba de manipulaciones" de nuestra solución que perdemos a las personas que piratean el software.

Además, debe tener en cuenta el dolor para nuestros clientes legítimos, y pedirles que peguen una cadena de licencia desde su página de cuenta en línea es tan doloroso como me gustaría. ¿Por qué crear barreras adicionales a la entrada de clientes potenciales?

De todos modos, dependiendo de la solución que ya haya implementado, mi descripción anterior podría brindarle algunas ideas que podrían disminuir la probabilidad de que alguien rompa su producto.

Answer 2

Te diré lo más parecido a "crackproof": una aplicación web.

Las aplicaciones de escritorio están condenadas al fracaso, por muchas otras razones, pero hacer que su aplicación se ejecute "en la nube", en un navegador, le brinda mucho más control sobre la seguridad.

Un software de escritorio se ejecuta en la computadora del cliente, por lo que el cliente tiene acceso completo a él. Una aplicación web se ejecuta en su servidor, por lo que el cliente solo ve un poquito de ella.

Answer 3

Como han mencionado otros, una vez que suelta los bits a los usuarios, ha dejado de controlarlos. Un hacker dedicado puede cambiar el código para hacer lo que quiera. Si desea algo más cercano a la prueba de grietas, no libere los bits a los usuarios. Guárdelo en el servidor. Proporcione acceso a la aplicación a través de Internet o, si el usuario necesita un cliente de escritorio, mantenga los bits críticos en el servidor y brinde acceso a ellos a través de los servicios web.

Answer 4

Como han dicho otros, no hay forma de crear un software completo a prueba de grietas, pero hay formas de dificultar el descifrado del software; la mayoría de estas técnicas son utilizadas por los malos para ocultar el malware dentro de los binarios y por las compañías de juegos para dificultar el crackeo y la copia de los juegos.

Si realmente quiere hacerlo de manera seria, podría verificar, por ejemplo, qué hacen los empaquetadores ejecutables como UPX. Pero luego debes implementar el desempaquetador también. En realidad, no recomiendo hacer esto, pero estudiar protectores de juegos y ofuscación binaria podría ayudarte en tu búsqueda.

Answer 5

Tienes que empezar por infiltrarte en la banda local de hackers, haciéndote pasar por un chico de 11 años que quiere "piratearlo". Una vez que se ha ganado su confianza, puede aprender qué características encuentran más difíciles de descifrar. A medida que liberas secretamente el software "uncrackable" a los tableros de mensajes locales, puedes ver lo que hacen con él. Desarrolle su conocimiento interno hasta que ya no puedan descifrar su software. Cuando haya terminado, deje que se conozca su identidad. Idealmente, esto se verá como un signo de traición, que estás trabajando en contra de ellos. Con suerte, esto los llevará a contactar a otros hackers fuera de la comunidad local para atacar su software.

Continúa hasta que llegues a la parte superior de la mafia hacker. Escriba su tesis como un libro, véndalo a HBO.

Answer 6

Como dijo nuite, cualquier código que suelte a la máquina de un cliente es crackable.

No intente por "uncrackable". Intente por "hay suficiente impedimento para proteger razonablemente mis activos".

Hay muchas formas en que puede intentar y aumentar el costo de agrietamiento. La mayoría de los productos le cuestan, pero hay una cosa que puede hacer para reducir sus costos y aumentar el costo de agrietamiento: realice entregas frecuentes.

Hay un costo finito para descifrar cualquier binario dado. Ese costo aumenta con la cantidad de binarios que se descifran. Si libera nuevas funcionalidades cada semana, esencialmente bifurca a los usuarios en dos grupos:

1. Aquellos que no necesitan las últimas funciones y pueden esperar por una grieta.
2. Aquellos que sí necesitan las últimas características y pagarán por su software.

Al participar en las tradicionales técnicas de craqueo anti, se puede multiplicar el costo de craqueo un uno binario, en consecuencia, aumentar la brecha entre cuando una nueva característica se libera y cuando está disponible en el mercado negro. Para colmo, los costos disminuirán y la cantidad de valor que entregue en un período de tiempo aumentará; eso es lo que lo libera.

Cuanto más a menudo lo suelte, más verá que la calidad y el valor aumentan, el costo baja y las personas menos probables robarán su software.

Answer 7

Antes que nada, ¿en qué idioma estás escribiendo esto? Es cierto que es imposible lograr un programa a prueba de grietas, pero siempre puede hacerlo más difícil. Un enfoque ingenuo para la seguridad de las aplicaciones significa que un programa se puede descifrar en minutos. Algunos consejos:

Si se está implementando en una máquina virtual, eso está muy mal. No hay muchas alternativas allí. Todos los vms populares (java, clr, etc.) son muy simples de descompilar, y no hay ofuscador ni firma suficientes.

oportuno intentar disociar la medida de lo posible la programación de interfaz de usuario con el programa subyacente. Esto también es un gran principio de diseño y hará que el trabajo del cracker sea más difícil desde la GUI (por ejemplo, ingrese su ventana serie) para rastrear el código donde realmente realiza la verificación

Si está compilando en código máquina nativo real, siempre puede establecer la compilación como una versión (no incluir ninguna información de depuración es crucial), con una optimización lo más alta posible. También en las partes críticas de su aplicación (por ejemplo, cuando valida el software), asegúrese de hacer una llamada de función en línea, para que no termine con un único punto de falla. Y llame a esta función desde diferentes lugares en su aplicación.

Como se dijo antes, los envasadores siempre suman otra capa de protección. Y si bien ahora hay muchas opciones confiables, algunos programas antivirus pueden acabar identificándote como un virus falso positivo, y todas las opciones famosas (por ejemplo, UPX) ya tienen un desempaquetador bastante directo.

hay algunos trucos-depuración contra También puede buscar. ¡Pero esto es una molestia para usted, porque en algún momento también podría necesitar depurar la aplicación de lanzamiento!

Tenga en cuenta que su prioridad es hacer que la parte fundamental de su código como imposible de encontrar como sea posible. Cadenas de texto claro, llamadas a la biblioteca, elementos de la interfaz gráfica de usuario, etc. Son todos los puntos donde un atacante puede usar para rastrear las partes críticas de su código.