Protección de software para pequeños vendedores.

Question

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 la declaración: " Para cualquier software protegido utilizado por más de unos pocos cientos de personas, puede encontrar una versión descifrada. Hasta ahora, todos los esquemas de protección pueden ser manipulados. ¿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 emplearás, una galleta verdaderamente dedicada, eventualmente, superará todas las barreras protectoras". ¿Cuál es la mejor relación calidad-precio? protección de código c # para un único desarrollador

Entonces, a pesar de estos dos descargos de responsabilidad generales, hablemos de "protección"

Todavía siento que para aplicaciones más pequeñas que es poco probable que justifiquen 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 haga, si el cracker puede cambiar el resultado de una declaración IF (jmp) parcheando la aplicación, entonces todas las contraseñas y dongles en el mundo no ayudarán.

Entonces, mi enfoque ha sido ofuscar el código con virtualización utilizando productos como: http://www.oreans.com/codevirtualizer.php Estoy 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 tenía 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 bloquearían 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.

I Utilice 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 durante períodos prolongados. Por definición, la aplicación no tiene valor en ese punto, incluso si está rota.

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 iniciar y el servidor deshabilita la ID anterior y devuelve una nueva autorización.

También utilizo un hash de la aplicación compilada y la verifico en el lanzamiento para ver si ha cambiado un bit, luego abro la aplicación como un archivo (con un BLOQUEO de lectura) desde la aplicación para evitar que alguien la cambie una vez que se inicia .

Dado que todas las cadenas estáticas son claramente visibles en el archivo .exe, trato de ser genérico con mensajes de error, etc. No encontrará la cadena "Autorización fallida" en cualquier lugar.

Para proteger contra los volcados de memoria, utilizo una técnica de ofuscación de texto simple (como XOR cada carácter) Esto hace que los datos de texto sin formato en la memoria sean más difíciles de distinguir de las variables, etc.

Entonces, por supuesto, hay AES para cualquier dato que sea realmente sensible. Me gusta el modo de contador para el texto, ya que esto da como resultado que no se repitan secuencias que revelen datos subyacentes como una secuencia de espacios en blanco.

Pero con todas estas técnicas, si la clave o el vector de inicialización se pueden volcar de la memoria, o si se omite la instrucción IF, 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

Answer 1

No estoy de acuerdo con xsl.

Protegemos nuestro código, no porque queramos proteger nuestros ingresos; aceptamos que aquellos que los usarían sin una licencia probablemente nunca lo pagarían de todos modos.

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 pagar el costo de la licencia.

Somos muy cuidadosos para garantizar que la protección, que es de cosecha propia, sea lo más discreta posible para los usuarios válidos, y para este fin nunca consideraríamos 'comprar' una solución estándar que pueda afectar esto.

Answer 2

No necesita unos pocos cientos de usuarios para descifrar su software. 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 shareware (tenía su propio archivo PAD y todo ) Un día después, una versión descifrada de Magic Textbox estaba disponible.

Esta experiencia me hizo dejar de intentar proteger mi software con algo más que una protección de copia rudimentaria.

Answer 3

Yo personalmente uso las técnicas de código discutido aquí . Estos trucos tienen la ventaja de incomodar a los piratas sin hacerles la vida más difícil a 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 de bajo precio son completamente diferentes a las de una aplicación B2B de alto valor.

Patrick Mackenzie tiene un buen ensayo donde 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 de negocio.

Answer 4

He implementado claves de hardware (dongles) antes que yo, así que no estoy totalmente familiarizado con los problemas. De hecho, lo he pensado mucho. No estoy de acuerdo con nadie que 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 ella. Yo nunca violé los derechos de autor del software. Dicho esto ...

Realmente no me gusta la palabra "proteger" utilizado aquí Lo único que intenta proteger es su control . no está protegiendo el software. El software está bien de cualquier manera, al igual que sus usuarios.

La razón por la que evitar que las personas copien y compartan su software es una PITA tan impía es que evitar tales actividades no es natural. Todo el concepto de una computadora gira en torno a la copia de datos, y es una simple naturaleza humana querer compartir cosas útiles. Puedes luchar contra estos hechos si realmente insistes, pero será una lucha de por vida. Dios no está haciendo a los humanos de manera diferente, y no estoy comprando una computadora que no pueda copiar cosas. ¿Quizás 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 empresa que necesita software desarrollado para que pueda hacer sus negocios, 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. Sin protección es necesario.

Answer 5

De algunos de los enlaces:

El concepto que intenté explicar es lo que llamo el & # 8220; crack spread & # 8221 ;. No importa que exista un crack (o keygen, o serie pirateada, o lo que sea) para su aplicación. Lo que importa es cuántas personas tienen acceso a la grieta.

Dónde / cuándo verificar el número de serie: lo verifico una vez al inicio. Mucha gente dice & # 8220; Revise todo tipo de lugares & # 8221 ;, para que sea más difícil que alguien se rompa quitando el cheque. Si desea ser particularmente desagradable con el cracker, verifique todo tipo de lugares utilizando código en línea (es decir, DON & # 8217; T lo externalice todo en SerialNumberVerifier.class) y, si es posible, hágalo multiproceso y difícil de reconocer cuando también falla. Pero esto hace que sea más difícil hacer el crack, no imposible, y recuerde que su objetivo generalmente no es derrotar al cracker. Derrotar a la galleta no te hace una cantidad apreciable de dinero. Solo necesita derrotar al usuario casual en la mayoría de los casos, y el usuario casual no tiene acceso a un depurador ni sabe cómo usar uno.

Si va a llamar a su casa, debe llamar a su casa con su información de usuario y aceptar el número de serie como la salida de la secuencia de comandos de su servidor, no llamar a su casa con el número de serie y aceptar un booleano, etc., como la salida. es decir, deberías estar haciendo una inyección clave, no una verificación clave. La verificación de la clave tiene que suceder finalmente dentro de la aplicación, por lo que la criptografía de clave pública 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 cambio de archivo de hosts lejos de una explotación de una sola vez, si su software solo espera leer un booleano de Internet .

No haga un & # 8220; interesante & # 8221; o & # 8220; desafiante & # 8221; proteccion. Muchos crackers solo por el desafío intelectual. Haga que su protección sea difícil de descifrar pero lo más aburrida posible.

Hay algunas grietas que buscan patrones de bytes en busca del lugar para parchear. Por lo general, no son derrotados por una recompilación, pero si su .EXE está empaquetado (por ASProtect, Armadillo, etc.), este tipo de grietas primero debe desempaquetar el .EXE ... y si usa un buen empaquetador como ASProtect, el cracker podrá descomprimir el EXE manualmente usando un depurador de nivel de ensamblaje como SoftICE, pero no podrá crear una herramienta que desempaquete el .EXE automáticamente (para aplicar los parches de bytes después).

Answer 6

xsl, ese es un punto de vista muy estrecho con MUCHAS suposiciones integradas.

¡Me parece obvio que cualquier aplicación que se base en entregar algo de un servidor bajo su control debería ser capaz de hacer un trabajo bastante bueno al descubrir quién tiene una cuenta válida!

También creo que las actualizaciones periódicas (es decir, una aplicación recién compilada con código en diferentes ubicaciones) harán que las vesículas agrietadas 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.

Entonces sí, nada es indescifrable, pero con un diseño intrínseco inteligente, se convierte en un punto discutible. ¡El único factor significativo es cuánto tiempo están dispuestos a gastar los crackers en él, y cuánto esfuerzo están dispuestos a hacer sus clientes potenciales para tratar de encontrar el producto de sus esfuerzos semanalmente o incluso a diario!

Sospecho que si su aplicación proporciona una función útil y valiosa, estarán dispuestos a pagar un precio justo por ella. De lo contrario, los productos competitivos ingresarán al mercado y su problema se resolverá solo.

Answer 7

He usado .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.