obfuscation - ofuscar - obfuscate json
Protección de software para pequeños proveedores (7)
Este es un problema que todos debemos considerar en algún momento.
Después de muchos años y muchos enfoques, tiendo a estar de acuerdo en general con el staterment: "Para cualquier software protegido utilizado por más de unos cientos de personas, puede encontrar una versión crackeada. Hasta ahora, cada esquema de protección puede ser alterado". ¿Su empleador impone el uso de software antipiratería?
Además, cada vez que publico sobre este tema, alguien me lo recordará; "En primer lugar, no importa qué tipo de protección utilizará, un cracker verdaderamente dedicado saldrá finalmente de todas las barreras de protección". Cuál es la mejor protección contra el código c # code para un solo desarrollador
¡Así que, a pesar de estos dos descargos de responsabilidad ampliamente aceptados, hablemos de "protección"!
Sigo pensando que para las aplicaciones más pequeñas que es poco probable que eviten el tiempo y la atención de un cracker experto, la protección ES un ejercicio que vale la pena.
Parece obvio que no importa lo que hagas, si el cracker puede cambiar el resultado de una sentencia IF (jmp) parcheando la aplicación, entonces todas las contraseñas y dongles en el mundo no van a ayudar.
Así que mi enfoque ha sido ofuscar el código con la virtualización utilizando productos como: http://www.oreans.com/codevirtualizer.php. He estado muy contento con este producto. Que yo sepa, nunca ha sido derrotado. Incluso puedo comprimir el ejecutable con PEcompact. ¿Alguien más tiene experiencia con él?
No tuve más que problemas con EXEcryptor http://www.strongbit.com/news.asp Incluso el sitio es un dolor de cabeza para usar. Las aplicaciones compiladas se bloquean al hacer cualquier llamada WMI.
Este enfoque le permite rodear secciones más pequeñas de código con la ofuscación y así proteger la comprobación de seguridad, etc.
Uso el enfoque de autorización en línea, ya que la aplicación necesita datos del servidor regularmente, por lo que no tiene sentido que el usuario la use fuera de línea por períodos prolongados. Por definición, la aplicación no tiene valor en ese punto, incluso si está agrietada.
Entonces, un simple apretón de manos encriptado es bastante bueno. Solo lo reviso ocasionalmente dentro de la protección de ofuscación. Si el usuario instala la aplicación en una máquina diferente, se carga una nueva ID al momento del lanzamiento y el servidor deshabilita la identificación anterior y devuelve una nueva autorización.
También utilizo un hash de la aplicación compilada y la compruebo en el lanzamiento para ver si ha cambiado un bit, luego abro la aplicación como un archivo (con un BLOQUEO de lectura) desde dentro de la aplicación para evitar que alguien la cambie una vez iniciada.
Como todas las cadenas estáticas son claramente visibles en el archivo .exe, intento ser genérico con mensajes de error, etc. No encontrará la cadena "Autorización fallida" en ninguna parte.
Para protegerme contra los volcados de memoria, uso una técnica de ofuscación de texto simple (como XOR cada carácter) Esto hace que los datos de texto simple en la memoria sean más difíciles de distinguir de las variables, etc.
Entonces, por supuesto, hay AES para cualquier dato realmente sensible. Me gusta el modo contador para el texto ya que esto no da como resultado secuencias repetitivas que revelen datos subyacentes como una secuencia de espacios en blanco.
Pero con todas estas técnicas, si el vector de clave o inicialización puede abandonarse desde la memoria, o la sentencia IF omitida, todo se desperdicia.
Tiendo a usar una declaración de cambio en lugar de una declaración condicional. Luego creo una segunda función que es básicamente un callejón sin salida en lugar de la función que realmente realiza la tarea deseada.
Otra idea es codificar punteros con una variable añadida. La variable es el resultado de la autorización (generalmente cero). Esto conducirá inevitablemente a un GPF en algún momento. Solo uso esto como último recurso después de que algunas autorizaciones de nivel inferior han fallado; de lo contrario, los usuarios reales pueden encontrarlo. Entonces la reputación de su software se reduce.
¿Qué técnicas usas?
(NO es un hilo que debata los méritos de implementar algo. Está diseñado para aquellos que han decidido hacer ALGO)
No estoy de acuerdo xsl.
Protegemos nuestro código, no porque queremos proteger nuestros ingresos: aceptamos que aquellos que utilizarían sin licencia probablemente nunca pagarían por ello.
En cambio, lo hacemos para proteger la inversión que nuestros clientes han realizado en nuestro software. Creemos que el uso de nuestro software los hace más competitivos en su mercado y que si otras compañías tienen acceso a él sin pagar, tienen una ventaja injusta, es decir, se vuelven tan competitivos sin tener que sobrecargar el costo de la licencia.
Somos muy cuidadosos en asegurarnos de que la protección, que es de fabricación propia, sea lo más discreta posible para los usuarios válidos, y para este fin nunca consideraríamos la posibilidad de comprar una solución lista para usar que pueda afectar esto.
Yo personalmente uso las técnicas de código discutidas aquí . Estos trucos tienen el beneficio de incomodar a los piratas sin hacer la vida más difícil para sus usuarios finales legítimos.
Pero la pregunta más interesante no es "qué", sino "por qué". Antes de que un proveedor de software se embarque en este tipo de ejercicio, es realmente importante construir un modelo de amenaza. Por ejemplo, las amenazas para un juego B2C a bajo precio son completamente diferentes a las de una aplicación B2B de alto valor.
Patrick Mackenzie tiene un buen ensayo en el que analiza algunas de las amenazas , incluido un análisis de 4 tipos de clientes potenciales. Recomiendo hacer este análisis de amenazas para su propia aplicación antes de tomar decisiones sobre la protección de su modelo comercial.
He utilizado .NET Reactor en el pasado con buenos resultados - http://www.eziriz.com/
Lo que me gustó de este producto es que no requería que ocultaras el código para tener una protección bastante buena.
Implementé hardware dying (dongles) antes que yo, así que no estoy totalmente familiarizado con los problemas. De hecho, lo he pensado mucho. No estoy de acuerdo con que alguien viole la ley de derechos de autor, como lo están haciendo sus crackers. Cualquier persona que no quiera adquirir legalmente una copia de su software debería prescindir de. Nunca violo los derechos de autor del software yo mismo. Habiendo dicho eso...
Realmente, realmente no me gusta la palabra "proteger" utilizada aquí. Lo único que intenta proteger es su control . Usted no está protegiendo el software. El software está bien de todos modos, al igual que sus usuarios.
La razón por la cual evitar que la gente copie y comparta su software es una PITA tan impía que impedir esas actividades no es natural. Todo el concepto de una computadora gira en torno a la copia de datos, y es simple naturaleza humana querer compartir cosas útiles. Puedes luchar contra estos hechos si realmente insistes, pero será una pelea de por vida. Dios no está haciendo a los humanos de manera diferente, y no compraré una computadora que no pueda copiar cosas. Tal vez sería mejor encontrar alguna forma de trabajar con computadoras y personas, en lugar de luchar contra ellos todo el tiempo?
Yo, junto con la mayoría de los desarrolladores de software profesionales, estoy empleado a tiempo completo por una compañía que necesita software desarrollado para que pueda hacer su negocio, no para que pueda tener un "producto de software" con escasez artificial para "vender" a los usuarios. Si escribo algo generalmente útil (que no se considera una "ventaja competitiva" aquí), podemos lanzarlo como Software Libre. No se necesita "protección".
No necesita unos pocos cientos de usuarios para obtener su software crackeado. Me molestó que mi shareware se rompiera tantas veces, así que como experimento, creé un programa llamado Magic Textbox (que era solo un formulario con un cuadro de texto) y lo lancé a sitios de shareware (tenía su propio archivo PAD y todo ) Un día después, estaba disponible una versión descifrada de Magic Textbox.
Esta experiencia me hizo casi dejar de tratar de proteger mi software con algo más que una protección de copia rudimentaria.
De algunos de los enlaces:
El concepto que traté de explicar es lo que yo llamo el "crack spread". No importa que exista una grieta (o keygen, o serie pirateada, o lo que sea) para su aplicación. Lo que importa es cuántas personas tienen acceso al crack.
Dónde / cuándo verificar el número de serie: lo compruebo una vez al inicio. Mucha gente dice "Check in todo tipo de lugares", para que sea más difícil que alguien se agriete quitando el cheque. Si quieres ser particularmente desagradable con el cracker, revisa todo tipo de lugares usando el código en línea (es decir, NO lo externalices todo en SerialNumberVerifier.class) y, si es posible, hazlo multihilo y difícil de reconocer cuando falla , también. Pero esto solo hace que sea más difícil hacer el crack, no es imposible, y recuerda que tu objetivo generalmente no es vencer al cracker. Derrotar al cracker no te hace una cantidad apreciable de dinero. Solo necesita vencer al usuario ocasional en la mayoría de los casos, y el usuario ocasional no tiene acceso a un depurador ni sabe cómo usarlo.
Si va a llamar a su casa, debería llamar a su casa con su información de usuario y aceptar el número de serie como resultado de la secuencia de comandos de su servidor, no llamando a casa con el número de serie y aceptando un booleano, etc., como salida. es decir, debería estar haciendo la inyección de clave, no la verificación de clave. La verificación clave tiene que ocurrir en última instancia dentro de la aplicación, por lo que la clave pública de cifrado es la mejor manera de hacerlo. La razón es que la conexión a Internet también está en manos del adversario :) Usted es un archivo de hosts que cambia de un exploit break-once, break-everywhere si su software solo espera leer un booleano fuera de Internet.
No haga una protección "interesante" o "desafiante". Muchas galletas se agrietan solo por el desafío intelectual. Haga que su protección sea difícil de romper, pero lo más aburrido posible.
Hay algunas grietas que buscan patrones de bytes en la búsqueda del lugar para parchar. Por lo general, no son derrotados por una recompilación, pero si tu .EXE está empaquetado (por ASProtect, Armadillo, etc.) este tipo de grietas primero debe descomprimir el .EXE ... y si usas un buen empacador como ASProtect, el cracker podrá descomprimir el EXE manualmente utilizando un depurador de nivel de ensamblaje como SoftICE, pero no podrá crear una herramienta que descomprima el .EXE automáticamente (para aplicar los parches de bytes posteriormente).
xsl, ese es un punto de vista muy estrecho con MUCHAS incorporaciones incorporadas.
Me parece obvio que cualquier aplicación que dependa de entregar algo de un servidor bajo su control debería poder hacer un buen trabajo al calcular quién tiene una cuenta válida.
También estoy convencido de que las actualizaciones periódicas (es decir, una aplicación recién compilada con código en diferentes ubicaciones) harán que las vulnerabilidades se vuelvan obsoletas rápidamente. Si su aplicación se comunica con un servidor, iniciar un proceso secundario para reemplazar el ejecutable principal cada semana es pan comido.
Así que sí, nada es imposible de descifrar, pero con un diseño intrínseco inteligente, se convierte en un punto discutible. El único factor que es significativo es cuánto tiempo están dispuestos a gastar los crackers en él, y cuánto esfuerzo están dispuestos a ejercer sus clientes potenciales para tratar de encontrar el producto de sus esfuerzos de manera semanal o incluso diaria.
Sospecho que si su aplicación ofrece una valiosa función útil, estarán dispuestos a pagar un precio justo por ella. De lo contrario, los productos Competitivos entrarán en el mercado y su problema simplemente se resolverá solo.