La protección de la aplicación

La proteccion de la aplicacion

La proteccion de la aplicacion : Multi-millones de consejos para hacer su vida mas facil.

Como proteger sus aplicaciones.
La perfecta aplicacion del sistema de proteccion
por Vegard A. Larsen
he estado pensando en esto por un largo tiempo, y la creacion de un perfecto sistema de proteccion para mi (y su) aplicaciones podria parecer una tarea imposible. Despues de todo, las grietas para su aplicacion podria estar disponible en Internet el dia despues de la liberacion. Pero, pensando en la forma en que Microsoft (y similares) de las grandes empresas, permitir a los usuarios registrarse simplemente introduciendo un codigo de serie, tengo la idea de como crear un casi perfecto sistema de proteccion. Lo que yo voy a esbozar aqui estan las bases de lo que parece ser una inquebrantable sistema de proteccion. Tenga en cuenta que este articulo no incluye el codigo fuente, asi que esto es simplemente una sugerencia de como hacerlo, y cualquier sugerencia de mejora sera muy apreciada.
Recuperar el numero de serie
El primer pensamiento que me golpeo, era el de tener el sistema habilitado para la web, es decir que se conecte a algun tipo de servidor de autenticacion. En primer lugar, vamos a necesitar que el usuario recupere su numero de serie. Esto se puede hacer en un numero de maneras, pero por el bien de este experimento, voy a especificar un metodo utilizable. El usuario se registra a traves de una aplicacion externa que envia nombre y la organizacion a su servidor, compruebe que el/ella ha hecho el pago, y le envia un e-mail con esta serie. A continuacion, el usuario tendra que escribir esta informacion en la aplicacion principal, donde el 'verdadero' proceso de registro se lleva a cabo.
Comprobacion del numero de serie
veamos el siguiente escenario: un usuario introduce su nombre, la organizacion y el codigo de serie que el/ella recibio cuando el/ella registrado. El sistema se conecta a un servidor de autenticacion, que contiene toda la informacion del usuario (nombre, organizacion y codigo de serie) para todos los usuarios. Nuestra informacion del usuario es enviado (con cifrado aplicado) para el servidor, cuando la respuesta se devuelve a la aplicacion. Esta respuesta tambien necesitara algun tipo de cifrado, la prevencion de posibles galletas de la interceptacion de la señal enviada al servidor (utilizando, por ejemplo, falsos IPs) y simplemente suministro de un '220 ACEPTAR' respuesta a la solicitud. Ademas, el cifrado se aplican a variar de un equipo a otro. Si vamos a utilizar la misma codificacion en cada ordenador, el potencial de cracker podria simplemente obtener el nombre, la organizacion de serie y el codigo de otro usuario registrado, y se han quebrado la aplicacion. Asi que, ¿como generar una clave que varia de un equipo a otro, sin embargo, es reproducible en el mismo, unico equipo? Esto plantea un algo grande problema. Intel ha incorporado un CPU-codigo de IDENTIFICACION de hace algun tiempo, pero esto puede no ser fiable. Supongamos que el usuario decide cambiar su CPU? (Tambien hay parches que se puede quitar esta CPU-codigo de IDENTIFICACION.) Luego este valor de ID iba a cambiar. Tecnicamente, no hay nada dentro de un sistema informatico que se va a quedar exactamente la misma dependiendo de quien esta usando el sistema. Si un usuario decide volver a instalar Windows, todos los datos
guardado en la carpeta de Windows es eliminado, por lo que el almacenamiento de datos (como un aleatorio generado clave de cifrado) no seria la mejor idea.
La respuesta podria ser tan simple como ir por el 'usuario Registrado' valor almacenado por Windows, dentro del registro. Piense en ello, si el usuario decide volver a instalar Windows, el/ella sera mas probable que aun ha de introducir su nombre como usuario registrado! De nuevo, esto plantea un problema: muchos de los equipos que vienen empaquetados, con Windows y un monton de aplicaciones instaladas fuera de la caja, la mayoria de las veces tiene este valor algo como 'usuario'. Asi que cuando nuestro usuario vuelve a instalar su version de Windows, este valor sera mas probable cambio. Esto es cuando vamos a tener que cumplir con 'extras' en el acuerdo de licencia, con indicacion de que si el usuario decide volver a instalar Windows, el/ella tendra que notificarlo a la compañia acerca de este 48 horas de antelacion, o el/ella perderia su licencia.
a Continuacion, podemos hacer lo siguiente: configurar el servidor para que dentro de dicho plazo de 48 horas para permitir volver a registrar de ese usuario especifico, si no lo ha hecho dentro de la fecha limite, restablecer el 'usuario Registrado' de lo que era antes de que el/ella notificado. Para limitar este (para asegurar que el usuario no mantenga la reinstalacion de Windows 3 veces a la semana), vamos a tener un contador del numero de veces que el usuario se ha registrado este año, y un limite de 12 veces al año, va a ser algo normal.
a continuacion, obtener el siguiente resultado: la aplicacion envia los datos cifrados con una clave generada a partir de lo que encontro en el 'usuario Registrado' de la clave, de preferencia mediante la adicion de una comprobacion de coherencia a la de los datos al final. El servidor recibe los datos, comprueba la coherencia, y se descifra con la clave generada a partir de la 'usuario Registrado' valor ' (que ya estaban presentes en el servidor).
a Continuacion, el servidor puede enviar la respuesta, utilizando la misma clave de cifrado, de nuevo al programa, y decirle al programa si el codigo de serie era valido o no. Dependiendo de esto, el programa se bloquea/desbloquea si mismo.
almacenamiento de datos en el sistema actual
evitando la deteccion

hasta ahora, muy bien, pero todavia hay muchos otros aspectos a considerar. Como ahorrar que el programa se han registrado en el equipo local. Si hacen esto, la 'normal', almacenando los valores en el Registro, usted puede estar seguro de que las galletas se han resuelto como conseguir alrededor de el en el dia. Asi, una simple solucion podria ser la de almacenar los datos dentro de la aplicacion exe-archivo, probablemente esta pensando ahora... Mal, este sera el segundo lugar potencial de galletas mirada. Por lo tanto, tuve una idea. Lo que si vamos a anexar nuestros datos despues de la EF de un archivo DLL en el directorio de Windows? Esto es posible, y de esta manera, el archivo no incluso aumentar de tamaño a medida que usted se registre su aplicacion. Ahora, este archivo DLL tiene que ser un archivo que se utiliza muy raramente, pero esta presente en todas las versiones de Windows (NT/2000 y 9x/Me), independientemente de los componentes de los que eligieron a instalar con Windows. La localizacion de un archivo de este tipo podria ser dificil, pero lo que te deja de comprobacion de archivos diferentes en los distintos sistemas? Usted puede tener anexa un archivo en windows NT/2000 sistemas, y a otro archivo en 9x/Me los sistemas. Usted puede incluso dividir los datos en diferentes archivos en la carpeta de Windows, añadiendo solo un byte para cada archivo (lo que te permite almacenar varios bytes de datos (por ejemplo, isRegistered, RegisterRetries). Nota: Usted tendra que comprobar que ningun otro programa ha añadido los datos despues de la EF, debido a que varios programas se podrian utilizar este metodo para almacenar los valores.
seguridad
Para asegurarse de que nadie pueda alterar el ejecutable principal, o la edicion hexadecimal es encontrar un metodo para eliminar el numero de serie de la proteccion, preferiblemente necesidad de varias capas de seguridad, siendo el mas importante el cifrado y la auto-modificacion de codigo. Ahora, el uso de estos al mismo tiempo, puede resultar dificil, especialmente cuando usted tiene que hacer tanto en tiempo de ejecucion. La creacion de auto-modificacion de codigo es facil, pero lo que es trabajar con aplicaciones de cifrado sera dificil, si no imposible. Tambien, si es posible, la compresion sera de ayuda, si simplemente hacer una galleta de la obra de un dolor en su detras. No voy a comentar mucho mas sobre esto, ya que es un tema que me tiene un conocimiento limitado.
El servidor
Hasta ahora, solo he mencionado el servidor, no se explica en detalle. Las bases son claras, va a ser una base de datos, que contenga al menos la siguiente informacion (por supuesto, puede ser extendido para contener a otros elementos tales como el codigo POSTAL, estado, forma de pago, etc.):
nombre de Usuario
Organizacion
usuario Registrado (que no debe confundirse con el nombre de Usuario)
numero de Serie (que tambien puede ser generado por aqui)
Numero de registros de los ultimos 12 meses
El servidor va a tener, al menos, otros dos atributos, el primero es el cifrado. El segundo, que solo acepta conexiones desde ciertos predefinidos puertas de enlace. Esto significa que la aplicacion cliente se conecta a un sistema, que se piensa que es el servidor, aunque esto, en realidad, solo es una puerta de entrada para el servidor. De esta manera, las galletas no tendria forma de saber que sistema es el servidor. El mas puertas de enlace se ejecuta a traves de, la mejor proteccion para el servidor, pero la conexion mas lenta. Asegurese de que las puertas de enlace seguras, lo que significa que tienen como pocos puertos abiertos como sea posible, y que no de la impresion de la IP-direccion a la que redirigir los mensajes (por lo que
cracker no se hackear la puerta de enlace y encontrar la ruta al servidor).
El servidor, por supuesto, tambien tiene que ser como seguro como sea posible, como con cualquier otro servidor.
notas
Ahora, la creacion de un componente como este, va a introducir otro problema: el de Si las galletas logran romper una aplicacion que utiliza este sistema, se le han violado todos ellos. Por lo tanto, un componente de este tipo tendria que ser de codigo Abierto (o, al menos, que se suministra con fuente), por lo que todo el mundo puede modificar su algoritmo de cifrado para sus propias necesidades. Tambien, pueden alterar los archivos de los que la informacion local que se anexa.
¿suena esto como un perfecto sistema de proteccion para usted? Si se puede ver algun fallo, agujeros de seguridad o problemas potenciales, voy a estar contento de saber. Ahora, el objetivo de esto era inspirar a alguien para escribir un componente que hace algo asi como este modelo de contornos. Asi, cuando alguien escribe este componente, asegurese de que me deje saber sobre...
pongase en Contacto conmigo si usted tiene cualquier comentario relacionado con este articulo, puede enviarme un correo electronico aqui. Ya he mostrado en este articulo a algunos de los chicos en el canal de IRC #delphi, EFNet, y que parecia muy ansioso al respecto. Espero que esto ayude a alguien.
Actualizaciones del articulo

Recibido este correo hace unos dias de Timoteo Plocinski, y puedo ver que tiene
tiene algunos increiblemente buenos puntos. Esta en lo cierto, esto es algo muy a menudo,
se pasa por alto, se nos pasan los dias, justo el ajuste fino de las pequeñas partes de nuestra principal programa de interfaz grafica de usuario,
pero deja esto como un trabajo duro para el usuario.

'Vegard,

he disfrutado mucho con tu articulo sobre los esquemas de proteccion de mucho. Se trata de un tema que me
reflexionar sobre (como has) en un nivel teorico, todo el tiempo. I
ver enorme falla en su sistema sin embargo, y
a mi me parece que esto es un problema a menudo pasado por alto. La
aplicacion requiere demasiado de su usuario, y en la parte superior
de que, los trata como si ya estan culpable.

Viendo esta linea:

Esto es cuando vamos a tener que cumplir con 'extras' en la licencia
de acuerdo, indica que si el usuario decide volver a instalar
Windows, el/ella tendra que notificar a su compañia sobre
este con 48 horas de antelacion, o el/ella perderia su
licencia.

tengo que asumir, que la mayoria de los usuarios solo tienen que ir a un otro producto
este punto. Y tener sistemas de bloqueo y desbloqueo de si mismos
segun algunos protocolo hace que el sistema de
'inestable' para cualquier tipo de mision critica aplicacion
usted podria ser el diseño. En un nivel teorico que realmente
ha gustado el articulo, en un nivel practico I creo
limita el usuario demasiado. Despues de todo, la mayoria de los usuarios de software
no criminales, por lo que el tratamiento de la mayoria de esa manera, solo duele en el tiempo
ejecutar.

Atentamente,
Timoteo Plocinski'

Y, recomiendo a todos a leer los comentarios, son todos vale la pena una minuciosa lectura.