Creación de software Java comercial (DRM)

Question

Tengo la intención de hacer que algún software se venda a través de Internet. Solo he creado código abierto antes, así que realmente no tengo idea de cómo protegerlo para que no se agriete y se distribuya como warez. Teniendo en cuenta que yo sé como dos Programms que no están agrietados, ya sea o no realmente útil decidí que la única manera más o menos fiable puede tener este aspecto:

1. conectarse a un servidor y proporcionar información de licencias y algunos tipo de información de resumen de hardware
2. Si todo está bien, el servidor devuelve algunas partes cruciales que faltan del programa vinculadas a esa cierta PC junto con el límite de uso de, por ejemplo, 2 días
3. Que cosas cruciales no se guardan en el disco duro, por lo que se descarga cada vez que se inicia el programa, si el programa se ejecuta más de 2 días, los datos se descargan nuevamente
4. Si se utiliza la misma información desde diferentes computadoras, suspender la cuenta del cliente

¿Qué opina sobre esto? Puede parecer un poco restrictivo, pero será mejor que haga menos ventas al principio y luego vea que mi preciosa aplicación asesina se descargue de forma gratuita. De todas formas, primero necesito algunas teorías/tutoriales/guías básicas sobre cómo asegurar que el usuario solo use una determinada aplicación Java si la ha pagado, así que sugiérele un poco.

Gracias

Answer 1

Yo trabajo para una compañía que vende protegido software de Java.

No comentaré sobre el esquema de autenticación de usuario, pero puedo comentar sobre la verificación de licencia en línea.

No lo hagas ni siquiera "trabajar durante dos días": así es como pirateo la mayoría del software ... Máquina virtual configurada "atrás en el tiempo" y cortada con un firewall externo para que ya no "llame a casa" (eso es: solo permitiéndole contactar al servidor una vez, para obtener la clave de prueba), siempre reimpactada desde el punto donde el software se instaló recientemente y el bingo, la prueba de 30 días (o dos días de prueba) se ha convertido en una prueba de por vida. ¿Por qué hago esto? Para aprender cómo proteger mejor nuestra aplicación, por supuesto;) (ok, ok, lo hago solo por diversión)

Lo que hacemos en nuestro software comercial de Java es verificar la licencia en cada inicio.

Tenemos cientos de clientes y nadie se ha quejado al respecto. Ni una sola vez. Generamos una clase única en cada ejecución, que es diferente en cada ejecución, que depende tanto de las cosas únicas para ese lanzamiento en el lado del cliente como de las cosas generadas una vez en el lado del servidor.

Además de tener la aplicación, póngase en contacto con su servidor en cada lanzamiento para recopilar análisis: descarga a prueba, nb promedio de lanzamientos por prueba, etc. Y ya no es tan desagradable tener un Urchin/Google JavaScript rastreador en cada página web es desagradable.

Simplemente deje claro a las personas que su software realiza la verificación de la licencia en línea: hemos activado o desactivado una enorme casilla de verificación que dice: "Verificación de licencia en línea: OK/Fallido". Y eso es. La gente sabe que hay un cheque. Si no les gusta, usan productos inferiores de la competencia y la vida es buena.

La gente está acostumbrada a vivir en un mundo cableado.

¿Con qué frecuencia puede no acceder a GMail porque su conexión a Internet está caída?¿Con qué frecuencia puede no acceder a FaceBook o SO porque su conexión a Internet no funciona?

Point es: hacer tanto como sea posible el cálculo depende del lado del servidor:

• comprobación de licencia
• guardar las preferencias del usuario
• copia de seguridad de los datos generados por la aplicación
• etc.

Nadie se quejará. Tendrá un 0,1% de usuarios que se quejan y, de todos modos, no los quiere a estos usuarios: son ellos los que se quejan de otras cosas y publican comentarios negativos sobre su aplicación en línea. Es mejor que no usen el software y se quejan de que requiere una conexión a Internet siempre activa (que es el 99.99% de su público objetivo y por lo tanto no les importará la queja) en lugar de utilizarlas. la aplicación, y quejarse de otras cosas relacionadas con su aplicación.

En cuanto a la descompilación, .class generalmente se puede descompilar de nuevo en .java, a menos que esté utilizando un ofuscador de flujo de código que produzca un bytecode válido pero que sea imposible generarlo desde el archivo .java (por lo tanto, es imposible recuperarlo archivo .java válido).

El ofuscador de cuerdas ayuda a que sea más difícil de descifrar.

El código fuente obfuscator ayuda a que sea más difícil de descifrar.

Bytecode obfuscator como Proguard gratuito lo hace más difícil (y produce código más rápido, especialmente notable en el mundo de los dispositivos móviles) para averiguarlo.

Si está enviando Windows/Linux sólo entonces se puede usar un convertidor de Java a los nativos como Excelsior Jet (no libre y un poco caro para los arranques, pero produce código nativo desde el que simplemente puede no encontrar el archivos .java de vuelta).

Como nota curiosa verá a gente tratando de meterse con su servidor en línea ... Cerca de 30 beta-testers ya teníamos personas (que sabemos que formaban parte de la prueba) tratando de piratear nuestros servidores en línea .

Answer 2

A menos que su aplicación es específicamente web basan sus usuarios encontrarán que es una gran molestia para requerir una conexión a Internet con el fin de que pudieran acceder al producto. Lo que está sugiriendo funcionará, a menos que se rompa, como lo hacen todos los sistemas DRM. Entiendo que quiera proteger su propiedad intelectual, pero con muchas compañías como ejemplos, estos sistemas generalmente se rompen o el producto empeora debido a ellos.

Answer 3

Esa es una tarea realmente difícil, especialmente con algo que se ejecuta en una máquina virtual. Diría que podría estar pensando en la dirección correcta. Ofuscarlo para que sea razonablemente difícil de modificar podría evitar que las personas eludan los controles de licencia incorporados.

Sin embargo, en última instancia, si su aplicación es autónoma, siempre será crackable. Si puede compilarlo para que use los servicios que usted proporciona, de lo que probablemente pueda ordenar su uso.

Answer 4

tengo realmente ninguna idea de cómo protegerlo de ser agrietado y distribuidos como warez.

En primer lugar, sería mejor elegir un idioma además de Java, si esto es una preocupación. Esta es la razón por C++ todavía está vivo y bien en el mundo de las aplicaciones comerciales. A menos que vaya a usar un compilador de Java real para el exe nativo, reconsideraría Java por razones de protección de IP.

De hecho, incluso C++ no es impermeable a las grietas, pero la prorección de IP frente a las grietas son dos preocupaciones separadas e importantes.

Answer 5

Esa es una de las DRM más duras que he escuchado, tus usuarios la odiarían.

Además, tenga en cuenta que hay muchos descompiladores de Java buenos debido a la naturaleza del lenguaje y que alguien tan determinado pueda encontrar áreas del programa que tratan con su DRM y omitir/deshabilitar y luego volver a compilar es (according to this una recompilación sería poco realista) ... por lo que incluso tendría que hacer un esfuerzo para implementar su código lo más complejo posible para evitar que un pirata informático tenga éxito. (Que podría hacerse con una de esas herramientas de ofuscación de código que pueden tener por ahí.)

Answer 6

Lamento rechazarlo, pero primero debe tener una idea de lo que quiere compilar; entonces debería probar que su idea no solo funciona, sino que también es amada por los usuarios hasta el punto en que quieren para piratearla. En tercer lugar, debe asegurarse de que el tiempo que invierte para que sea "seguro" realmente vale la pena el valor de la aplicación.

Si usted lo vende por un dólar, y usted solo vende diez copias, y usted pasó 100 horas haciéndolo seguro, usted hace los cálculos y me dice si su tiempo valía ese poco dinero.

El mensaje final es: todo se puede descifrar o copiar. Al final hay mucha gente más brillante que nosotros haciendo esto (iPhone crackeando, televisión digital, juegos, etc.) y nadie encontró la bala de plata. Lo único que puede hacer es hacerlo más difícil para descifrar su aplicación (a menudo a expensas de facilidad de uso, facilidad de instalación y cortando esquinas para algunos escenarios de uso). Preguntándose si vale la pena es siempre un buen punto de partida.

Answer 7

No te molestes.

La industria del juego ha estado luchando contra la piratería durante décadas. Los juegos multijugador en línea con un servidor central generalmente requieren una suscripción para jugar. Ese modelo es bastante resistente a la piratería. Casi todos los demás juegos están muy pirateados, a pesar de los innumerables intentos de DRM.

Su aplicación estará rajada y pirateada, sin importar el idioma en que la escriba ni las herramientas que use para evitarla. Si su DRM realmente funciona, las personas que lo habrían pirateado aún no lo comprarán. Además, los usuarios legítimos preferirán otros productos que no tengan DRM intrusivo. Si no hay productos en competencia y el suyo tiene algún mercado del que hablar, alguien creará uno.

Answer 8

Veo una debilidad específica en su ejemplo, además del comentario que la mayoría de la gente ya hizo de que el DRM es difícil (imposible) de implementar y, a menudo, fácil de eludir.

En su segundo punto:

Si todo está bien, el servidor vuelve algunas partes que faltan cruciales de el programa asociado a esa cierta pc junto con el límite de uso de, digamos, 2 días

Este límite de 2 (o X) días probablemente será extremadamente fácil de eludir, esto solo tardaría unos minutos en encontrarlo y aplicarle un parche (crackear).

Si realmente desea tener un modelo de DRM, la única manera razonable de hacerlo es colocar una parte significativa de la aplicación como un servicio web y requerir una conexión constante de los usuarios.

Antes de intentar algo de esto, asegúrese de leer Exploiting Software y lo pensará dos veces antes de intentar hacer DRM.

Answer 9

Para parafrasear a un Sr. Jeff Atwood, es mejor facilitar que su cliente le pague que romper su aplicación. En otras palabras, creo que estás atacando el problema equivocado. Haga que la compra de su producto sea REALMENTE fácil y luego sus clientes no sentirán que necesitan hacer el esfuerzo de descifrarlo.

Answer 10

Echaré un vistazo a la reacción del juego Spore antes de tomar una decisión sobre un plan de licencias. Lo tenían teléfono a casa, y solo permitían tantas instalaciones, etc. etc. Se suponía que Spore era su "aplicación asesina" y realmente lo pasaba mal simplemente por la licencia. Usted dice que está dispuesto a tener menos ventas que las personas que lo usan de forma gratuita, pero es posible que desee tener cuidado con lo que pide. Tenía muchas ganas de esporas (y mis hijos también), pero nunca lo compré por el esquema DRM.

No importa lo que hagas, se rajará en muy poco tiempo, especialmente si el programa realmente vale algo.

Si va con un esquema de licencias, hágalo simple y utilizable para que no esté castigando a aquellos que realmente han pagado por su software. Además, evitaría los controles de estilo de la casa del teléfono, de esa manera sus clientes podrán continuar usando el software incluso si no quieren seguir pagando por ese dominio dentro de 3 años.

Answer 11

Creo que, dado el contexto, la forma más efectiva de protección por ahora sería el enfoque limitado de demostración/clave de licencia: le daría a la gente tiempo para enamorarse de su aplicación para que estén dispuestos a pagarla. , sin embargo, evitar la copia casual.

Una vez que sepa que su aplicación tiene un gran éxito, y que las galletas probablemente extraen una parte significativa de sus posibles ingresos, puede agregar cheques adicionales.

Otra cosa a considerar es dónde se va a usar su aplicación: si es algo que las personas pondrían en sus computadoras portátiles para usar sobre la marcha, la conectividad de red no es un hecho.

Answer 12

Siempre que se trate de una aplicación de Internet, puede restringirla de esa manera. A menos que se rompa el programa, esto funcionaría bien, excepto para los ataques de repetición.

Por ejemplo, si puedo capturar el tráfico que va a su servidor, y simplemente volver a reproducirlo en mi programa cada vez, todavía estoy bien. Por ejemplo, podría crear mi propio "servidor web" y asegurarme de que el programa llegue a ese servidor en lugar de a su servidor.

Answer 13

Debería leer "Surreptitious Software" de Collberg and Nagra. Este libro es realmente bueno para ayudarlo a comprender cómo funcionan los mecanismos de protección de software (como ofuscación de código, marca de agua, marca de nacimiento, etc.).

Como dijo lorenzog, la seguridad total no existe y la seguridad del software es como una constante carrera entre los vendedores de software y los piratas.

Debe usar transformaciones ofuscantes baratas (para que los gastos generales incurran no maten las actuaciones) para evitar que tantos atacantes (recuerden a la mayoría de ellos son script kiddies) como para "robar" sus algoritmos asesinos o cualquier información secreta .

Si desea aumentar aún más la seguridad, puede marcar los algoritmos y marcar con agua sus copias para encontrar quién filtró su creación. Pero incluso si lo hace, esto no significa que su software esté 100% seguro. Además, el tiempo que gastará agregando estos mecanismos podría no valer la pena.

Estos conceptos están muy bien explicados en el libro que mencioné antes que merece la pena leer.

Answer 14

Si tuviera suficientes puntos de reputación, votaría esta pregunta. La protección de software comercial es una pérdida de tiempo, dinero y esfuerzo por muchas razones. Concéntrese en hacer que valga la pena comprar una pieza de software. Si su software es lo suficientemente popular como para mantener una amplia siembra de piratas, es probable que tenga éxito en ese momento y que ni siquiera se preocupe por la piratería. De todos modos, las galletas crackean la protección del software sobre todo por diversión. Mientras más fuerte sea tu protección, mejor será el desafío que presenta y más querrán resolverlo. Su mejor esfuerzo le costará miles, le tomará meses y se agrietará en solo unos días.