icon - set border jpanel java
Haciendo software Java comercial(DRM) (14)
Realmente no tengo idea de cómo protegerlo de ser rajado y distribuido como warez.
Primero, sería mejor elegir un idioma además de Java, si esto es una preocupación. Esta es la razón por la que C ++ sigue vivo y bien en el mundo de las aplicaciones comerciales. A menos que vaya a utilizar un compilador Java real a un archivo nativo, reconsideraría Java por razones de protección IP.
En este sentido, incluso C ++ no es insensible a las grietas, pero la protección de IP frente a las grietas son dos preocupaciones importantes e independientes.
Tengo la intención de hacer algún software para ser vendido en internet. Solo he creado código abierto antes, así que realmente no tengo idea de cómo protegerlo de ser descifrado y distribuido como warez. Teniendo en cuenta que conozco dos programas que no están agrietados o no son realmente útiles, decidí que la única forma más o menos confiable podría tener este aspecto:
- Conéctese a un servidor y proporcione información de licencias y algún tipo de información de resumen de hardware
- Si todo está bien, el servidor devuelve algunas partes cruciales del programa relacionadas con esa PC junto con el límite de uso de, por ejemplo, 2 días.
- Esa información crucial no se guarda en el disco duro, por lo que se descarga cada vez que se inicia el programa, si el programa se ejecuta durante más de 2 días, los datos se vuelven a descargar.
- Si se usa la misma información desde diferentes computadoras, suspenda la cuenta del cliente
¿Qué piensas sobre esto? Puede parecer un poco restrictivo, pero es mejor que haga menos ventas al principio para luego ver mi preciosa aplicación asesina descargada de forma gratuita. De todos modos, primero necesito algunas teorías / tutoriales / guías básicos sobre cómo garantizar que el usuario solo use una determinada aplicación Java si la ha pagado, así que sugiera alguna.
Gracias
A menos que su aplicación esté específicamente basada en la web, sus usuarios encontrarán que es una gran molestia requerir una conexión a Internet para que puedan acceder al producto. Lo que está sugiriendo funcionará, a menos que se rompa, como lo hacen todos los sistemas DRM. Entiendo el deseo de proteger su propiedad intelectual, pero con muchas compañías como ejemplos, estos sistemas generalmente están rotos o el producto empeora debido a ellos.
Creo que, dado el contexto, la forma más efectiva de protección por ahora sería el enfoque clave de demostración / licencia limitada: le daría a las personas el tiempo de enamorarse de su aplicación para que estén dispuestas a pagar por ella y, a la vez, evitar proceso de copiar.
Una vez que sepa que su aplicación es grande y que los crackers pueden extraer una parte significativa de sus posibles ganancias, aún puede agregar cheques adicionales.
Otra cosa a considerar es dónde se usará su aplicación: si es algo que la gente pondría en sus computadoras portátiles para usar en cualquier lugar, la conectividad de red no es un hecho.
Debería leer "Software subrepticio" de Collberg y Nagra. Este libro es realmente bueno para ayudarlo a comprender cómo funcionan los mecanismos de protección del 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 carrera constante entre los vendedores de software y los piratas.
Debes usar transformaciones de ofuscación baratas (por lo que la sobrecarga en la que incurren no es matar las ejecuciones) para evitar que tantos atacantes (recuerde que la mayoría de ellos son chiquillos) para "robar" tus algoritmos asesinos o cualquier información secreta.
Si está dispuesto a impulsar aún más la seguridad, puede marcar sus algoritmos y marcar sus marcas de agua para identificar 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 dedique a agregar estos mecanismos podría no valer la pena.
Estos conceptos están muy bien explicados en el libro que mencioné anteriormente, que vale la pena leer.
Es uno de los DRM más duros que he escuchado, sus usuarios lo odiarían.
Además, tenga en cuenta que hay muchos buenos descompiladores de Java por ahí debido a la naturaleza del lenguaje y alguien suficientemente determinado podría encontrar áreas del programa relacionadas con su DRM y omitirlo / deshabilitarlo y luego volver a compilarlo (de acuerdo con esto una recompilación sería poco realista) ... por lo que incluso tendría que esforzarse para implementar su código lo más complejo posible para evitar que un pirata informático tenga éxito. (Lo que se podría hacer con una de esas herramientas de ofuscación de código que pueden tener por ahí).
Esa es una tarea realmente difícil, especialmente con algo que se ejecuta en una máquina virtual. Yo diría que podrías estar pensando en la dirección correcta. La ofuscación para que sea razonablemente difícil de modificar podría evitar que las personas evadan los controles de licencia incorporados.
Sin embargo, en última instancia, si su aplicación es autocontenida, siempre será craqueable. Si puede construirlo de manera que use los servicios que proporciona, entonces probablemente pueda controlar su uso.
Lamento rechazarte, pero primero debes tener una idea de lo que quieres construir; entonces debe probar que su idea no solo funciona, sino que también es amada por los usuarios hasta el punto en que quieren piratearla. En tercer lugar, debe asegurarse de que el tiempo que invierte en hacerlo "seguro" realmente valga la pena el valor de la aplicación.
Si lo vendes por un dólar, y solo vendes diez copias, y pasas 100 horas asegurándolo, haces los cálculos y me dices si tu tiempo valía tan poco dinero.
El mensaje para llevar a casa aquí es: todo puede ser roto o copiado. Al final, hay gente más inteligente que nosotros haciendo esto (crackeo de iPhone, TV digital, juegos, etc.) y nadie encontró la bala de plata. Lo único que puede hacer es hacer que sea más difícil descifrar su aplicación (a menudo a expensas de la facilidad de uso, la facilidad de instalación y los recortes para algunos escenarios de uso). Preguntarse si vale la pena la molestia, siempre es un buen punto de partida.
Me gustaría echar un vistazo a la reacción del juego Spore antes de decidir sobre un esquema de licencia. Lo tenían en 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 gratis, pero puede querer tener cuidado con lo que pide. Tenía muchas ganas de tomar esporas (y también mis hijos), pero nunca lo compré debido al esquema DRM.
No importa lo que haga, se resquebrajará en muy poco tiempo, especialmente si el programa realmente vale la pena.
Si va con un esquema de licencias, hágalo simple y utilizable para no castigar a los que realmente han pagado por su software. Además, evitaría cualquier tipo de verificación de teléfono en casa, de esa manera sus clientes podrán continuar usando el software incluso si no desea seguir pagando ese dominio dentro de 3 años.
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 fuertemente pirateados, a pesar de los innumerables intentos de DRM.
Su aplicación será dañada y pirateada, independientemente del idioma en que la escriba y las herramientas que utilice para evitarla. Si su DRM realmente funciona, las personas que lo habrían pirateado todavía no lo comprarán. Además, los usuarios legítimos preferirán otros productos que no tengan DRM intrusivo. Si no hay productos de la competencia y el suyo tiene algún mercado del que hablar, alguien creará uno.
Parafraseando a un Sr. Jeff Atwood, es mejor facilitar que su cliente le pague a usted que a crackear 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 un esfuerzo para romperlo.
Si tuviera suficientes puntos de reputación, rechazaría esta pregunta. La protección del software comercial es una pérdida de tiempo, dinero y esfuerzo por muchas razones. Concéntrate en hacer una pieza de software que valga la pena comprar. Si su software es lo suficientemente popular como para mantener una amplia siembra por parte de piratas, es probable que tenga suficiente éxito en ese momento que ni siquiera se preocupe por la piratería. De todos modos, los crackers protegen el software principalmente por diversión. Cuanto más fuerte sea su protección, mejor será el desafío que presenta y más querrán resolverlo. Su mejor esfuerzo le costará miles de dólares, tomará meses y será resquebrajado en solo unos días.
Siempre que sea una aplicación de Internet, puede restringirla de esa manera. Aparte de descifrar el programa, esto funcionaría bien, excepto por 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 tenga éxito en lugar de su servidor.
Trabajo para una empresa que vende software protegido 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 haga que "funcione durante dos días": así es como pirateo la mayoría del software ... La máquina virtual está "atrasada en el tiempo" y tiene un servidor de seguridad externo para que ya no "llame a casa" (es decir, solo permite para contactar con el servidor una vez, para obtener la clave de prueba), siempre reimaged desde el momento en que 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 de eso. 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, tener la aplicación en contacto con su servidor en cada lanzamiento es una excelente manera de recopilar analíticas: relación de descarga a prueba, nb promedio de lanzamientos por prueba, etc. Y ya no es desagradable más que tener un rastreador Urchin / Google JavaScript en cada página web es asqueroso.
Simplemente deje en claro a las personas que su software realiza la verificación de la licencia en línea: tenemos una gran casilla de verificación activada o desactivada que dice: "Verificación de la licencia en línea: OK / Error". Y eso es. La gente sabe que hay un cheque. Si no les gusta, usan productos de la competencia inferior y la vida es buena.
La gente está acostumbrada a vivir en un mundo alámbrico.
¿Con qué frecuencia no puede acceder a Gmail porque su conexión a Internet no funciona? ¿Con qué frecuencia no puede acceder a FaceBook o SO porque su conexión a Internet no funciona?
El punto es: haga tanto cálculo como sea posible dependiendo del lado del servidor:
- verificación de licencia
- guardar las preferencias del usuario
- Copia de seguridad de los datos generados por su aplicación.
- etc.
Nadie se quejará. Tendrá un 0,1% de las quejas de los usuarios y, de todos modos, no querrá que estos usuarios: ellos se quejen de otras cosas y publiquen comentarios negativos sobre su aplicación en línea. Es mejor que no utilicen el software y se quejan del hecho de que requiere una conexión a Internet siempre activa (que el 99.99% de su objetivo demográfico y por lo tanto no se preocupan por la queja) en lugar de tener que usarlos. la aplicación, y se quejan de otras cosas relacionadas con su aplicación.
Con respecto 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 genere un bytecode válido pero que sea imposible generarlo desde el archivo .java (por lo tanto, es imposible recuperar un archivo .java válido ).
El ofuscador de cuerdas ayuda a que sea más difícil de descifrar.
El ofuscador de código fuente ayuda a que sea más difícil de descifrar.
El ofuscador de códigos de bytes, como el Proguard gratuito, lo hace más difícil (y produce un código más rápido, especialmente notable en el mundo móvil) para descubrirlo.
Si está enviando solo Windows / Linux, entonces puede usar un convertidor de Java a nativo como Excelsior Jet (no es gratis y un poco caro para las startups, pero produce un código nativo del cual simplemente no puede encontrar los archivos .java).
Como nota graciosa, verá gente tratando de entrometerse con su servidor en línea ... En aproximadamente 30 beta-testers ya teníamos personas (que sabemos en qué parte de la prueba) que intentan piratear nuestros servidores en línea.
Veo una debilidad específica en su ejemplo, además del comentario que la mayoría de las personas ya mencionan que el DRM es difícil (imposible) de implementar y, a menudo, simple de eludir.
En su segundo punto:
Si todo está bien, el servidor devuelve algunas partes cruciales del programa relacionadas con esa PC junto con el límite de uso de, por ejemplo, 2 días.
Es probable que este límite de 2 (o X) días sea extremadamente simple de sortear, solo será de unos minutos para encontrar y parchar (crack).
Si realmente desea tener un modelo 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 probar algo de esto, asegúrese de leer Exploiting Software y lo pensará dos veces antes de intentar hacer DRM.