javascript - online - ofuscar php
Biblioteca de Javascript: ofuscar o no ofuscar-esa es la pregunta (10)
Necesito escribir una biblioteca de javascript relacionada con la GUI. Esto le dará a mi sitio web un poco de ventaja (en cuanto a la funcionalidad que puedo ofrecer), hasta que mis competidores jueguen con él el tiempo suficiente para descubrir cómo escribirlo por sí mismos (o finalmente piratear el script descargado). Puedo aceptar el hecho de que se emulará a lo largo del tiempo, eso es parte del curso (es parte del negocio). Solo quiero tener un par de meses para respirar donde la gente dice "Wow, ¿cómo diablos hicieron eso?" - Lo que me da unos meses de publicidad gratuita y un poco de impulso para pasar a otras cosas.
Para ser claro, ni siquiera me preocupan los piratas informáticos que aún así hackearán la fuente, es una batalla perdida que no vale la pena pelear (y en cualquier caso, acepto que mi código no es "tan valioso"). Sin embargo, lo que no puedo soportar es la idea de una manera efectiva, simplemente entregar todo el trabajo arduo que habría hecho en la biblioteca a mis competidores, mediante el uso de JavaScript simple que cualquiera puede descargar y usar. Si alguien va a usar lo que he trabajado, entonces no quiero simplemente dárselo, quiero que trabajen duro para decodificarlo. Si pueden decodificarlo, merecen tener el código ( lo más probable es que descubran que podrían haber escrito un código mejor por sí mismos), simplemente no tenían el sentido comercial para poner todos los componentes [de vainilla natural] en ese orden particular ) - Por lo tanto, no estoy diciendo que nadie podría haber escrito esto (lo que en cualquier caso sería una afirmación absurda), sino que lo que estoy diciendo es que nadie (hasta ahora) ha hecho la funcionalidad que soy. hablando, disponible para esta industria en particular, y yo (pensando como un empresario en lugar de un geek / codificador ), quiero ordeñarla por su valor, mientras dure, es decir, hasta que (inevitablemente) sea hackeada.
Es un hecho establecido que ningún sitio web en la industria a la que estoy "atacando" tiene esta funcionalidad, por lo que el valor de dicha biblioteca es innegable y no está sujeto a discusión (es decir, no es lo que estoy preguntando aquí).
Lo que busco descubrir son los pros y los contras de ofuscar una biblioteca de javascript, para que pueda tomar una decisión final.
Dos de mis mayores preocupaciones son la depuración y los errores sutiles que pueden ser introducidos por el ofuscador.
Me gustaría saber:
¿Cómo puedo gestionar esos riesgos (poder depurar el código defectuoso, asegurándome / minimizando los errores de ofuscación)?
¿Hay algunos ofuscadores estándar de la industria de buena calidad que pueda recomendar (preferiblemente algo que use usted mismo)?
¿Cuáles son sus experiencias al usar código confuso en un entorno de producción?
Si pueden decodificarlo, merecen tener el código (lo más probable es que descubran que podrían haber escrito un código mejor por sí mismos), simplemente no tenían el sentido comercial para poner todos los componentes [de vainilla natural] en ese orden particular ).
Entonces, realmente, estás tratando de resolver un problema de negocios con medidas técnicas.
Cualquier persona que valga la pena como programador de Javascript debería poder recrear lo que haces con bastante facilidad con solo mirar el producto en sí, sin necesidad de código. No es como si estuvieras inventando una nueva cosa mágica nunca antes vista, solo estás juntando las piezas de una manera nueva, como te admites. Es solo Javascript.
Incluso si ofuscas el guión, aún funcionará como está, los competidores podrían simplemente tomarlo y correr con él. Algunas personalizaciones no deberían ser demasiado difíciles incluso con código ofuscado.
En su negocio de nicho, probablemente notará rápidamente si alguien "robó" su guión. Si eso sucede, es un problema legal. Si sus competidores quieren estar en el claro legalmente, tendrán que volver a escribir el script desde cero de todos modos, lo que automáticamente le dará tiempo.
Si sus competidores no son técnicamente capaces de copiar su producto sin robar el código directamente, no hará ninguna diferencia si el código está en claro o ofuscado.
Aunque la ofuscación en general es algo malo, IMHO, con Javascript, la historia es un poco diferente. La idea no es ofuscar el Javascript en sí, sino producir una longitud de código más corta (el ancho de banda es costoso, y los usuarios primerizos pueden estar enojados esperando que se cargue el Javascript por primera vez). Inicialmente llamada minificación (con programas como minify), ha evolucionado bastante y ahora hay un compilador completo disponible, como el compilador YUI y el compilador de cierre de Google. Dicho compilador realiza una comprobación estática (lo cual es bueno, pero solo si sigue las reglas del compilador), la minificación (sustituya ese largo nombre de variable por ''ab'') y muchas otras técnicas de optimización. Al final, lo que obtienes es lo mejor de ambos mundos, codificar en código no compilado y desplegar código compilado (, minificado y ofuscado). Desafortunadamente, por supuesto, también deberías probarlo más ampliamente.
El Closure Complier de Google oculta su código después de que termine de escribirlo. Es decir, escriba su código, ejecútelo a través del compilador y publique los js optimizados (y ofuscados).
Debe tener cuidado si utiliza js externos que interactúen con la biblioteca porque cambia los nombres de sus objetos para que no pueda saber qué es qué.
Escriba su sitio web en flash, o mejor aún en Silverlight. Esto le dará a su compañía una GUI incomparable, sobre la cual sus competidores estarán salivando. Pero la naturaleza compilada de flash / dotnet no les permitirá seleccionar fácilmente su código. Es una situación ganar / ganar para ti;)
Información sobre la ofuscación de Javascript:
- Nadie puede ofrecer una ofuscación javascript 100% libre de grietas. Esto significa que con el tiempo y el conocimiento cada ofuscación puede "deshacerse".
- Minify! = Ofuscación: cuando minimiza su objetivo es: reducir el tamaño del código. El código reducido se ve completamente diferente y es mucho más complejo de leer (sugerencia: jsbeautifier.com). La objeción tiene un objetivo completamente diferente: proteger el código. Las transformaciones utilizadas intentan proteger el código ofuscado de la depuración y el espionaje. La ofuscación puede incluso producir una versión aún más grande del código original que es completamente contrario a los objetivos de minificación.
- ¡Ofuscación! = Cifrado: este es obvio, pero es un error común que cometen las personas.
- La ofuscación debería hacer mucho más difícil la depuración, es uno de sus objetivos. Entonces, si se hace correctamente, puede esperar perder mucho tiempo tratando de depurar el código ofuscado. Dicho esto, si se hace correctamente, la introducción de nuevos errores es un problema poco frecuente y puede encontrar fácilmente si se trata de un error de ofuscación. Reemplazando temporalmente el código con código no ofuscado.
- La ofuscación NO es una pérdida de tiempo, es una herramienta. Si se usa correctamente puedes hacer que otros pierdan mucho tiempo;)
Ficción de ofuscación de Javascript: (omitiré esta sección;))
Respuesta a Q2 - Herramientas de ofuscación sugeridas:
- Para obtener una lista extensa de ofuscador javascript: malwareguru.org . Mi elección personal es jscrambler.com.
Respuesta a Q3 - experiencias de uso de código ofuscado
- Hasta la fecha no hay nuevos errores introducidos por ofuscación
- Mucho mejor retención de clientes. Deben venir a la fuente para obtener la fuente;)
- Ocasionales falsos positivos reportados por algunas herramientas antivirus. Se puede probar antes de implementar cualquier código nuevo con una herramienta como Virustotal.com
La ofuscación automática de código completo solo está disponible hasta ahora en el modo Avanzado del compilador de cierre.
El código compilado con el modo Closure Advanced es casi imposible de aplicar ingeniería inversa, incluso si se pasa por un embellecedor, ya que todo el código base (incluida la biblioteca) está ofuscado. También es un 25% pequeño en promedio.
El código JavaScript que está simplemente minimizado (compresor YUI, Uglify, etc.) es fácil de aplicar ingeniería inversa después de pasar por un embellecedor.
Si usa una biblioteca de JavaScript, considere el kit de herramientas de Dojo que es compatible (después de modificaciones menores) con la compilación del modo avanzado del compilador de cierre.
La verdad es ofuscadora o no, cualquier programador que valga la pena su sal podría reproducir lo que hiciste en todo el tiempo que te llevó. Si robaron lo que hiciste, podrías demandarlos. Por lo tanto, desde el punto de vista comercial, la conclusión es que tiene, desde el momento en que publica, aproximadamente la misma cantidad de tiempo que le llevó implementar su diseño hasta que un competidor se ponga al día. Período. Esa es toda la ventaja que tienes. El resto es que usted está innovando más rápido que sus competidores y comercializándolo al menos tan bien como lo hacen ellos.
Podría adoptar un modelo de negocio de código abierto y licenciar sus scripts con la GPL o Creative Commons BY-NC-ND o similar
Respuesta estándar a las preguntas de ofuscación: ¿Es suficiente usar un ofuscador para asegurar mi código JavaScript?
OMI, es una pérdida de tiempo. Si los competidores pueden entender su código de forma clara (suponiendo que se trata de algo más de unos pocos miles de líneas ...), no deberían tener problemas para desenfocarlo.
¿Cómo puedo gestionar esos riesgos (poder depurar el código defectuoso, asegurándome / minimizando los errores de ofuscación)?
La ofuscación causará más errores, puede gestionarlos dedicando tiempo a depurarlos. Depende de la persona que escribió la ofuscación (ya sea usted o alguien más), en última instancia, solo perderá mucho tiempo.
¿Cuáles son sus experiencias al usar código confuso en un entorno de producción?
- Ser completamente anulado por ataques de canal lateral, ataques de repetición, etc.
- Loco.
Si bien puede recorrer el largo y peligroso camino de los ofuscadores, generalmente no los ve en aplicaciones de producción reales por la sencilla razón de que realmente no hacen mucho. Notará que las aplicaciones de Google, que en realidad son un montón de JavaScript propietario y muy valioso cuando lo analizan, solo se minimizan realmente y no se confunde, aunque la forma en que funcionan los minimizadores ahora es tan buena como confusa. Realmente necesitas saber lo que estás haciendo para extraer el significado de ellos, pero los determinados tendrán éxito.
El otro problema es que el código ofuscado debe funcionar, y si funciona, la gente puede hacerlo por completo, sin entenderlo, y usarlo como lo considere oportuno. Claro, no pueden modificarlo directamente, pero no es difícil colocar capas de parches que vuelvan a implementar partes que no les gustan sin tener que profundizar demasiado. Esa es simplemente la naturaleza de JavaScript.
La razón por la que Google y similares no sufren de una serie de competidores de cortar y pegar es porque el JavaScript es solo una parte del paquete. Para tener algún grado de control sobre cómo y dónde se usan estas cosas, un componente grande debe estar basado en el servidor. La buena noticia es que puede aprovechar cosas como Node.js para que sea bastante fácil dividir el código de cliente y servidor sin tener que volver a implementar partes en un idioma completamente diferente.
Lo que podría querer investigar no es tanto confuso, sino dividir su aplicación en partes que pueden cargarse a pedido desde algún tipo de servicio, y como estas partes pueden ser altamente interdependientes y en su mayoría no funcionales sin este núcleo servidor, puede tener un mayor grado de control sobre cuándo y dónde se utiliza esta biblioteca.
Puede ver elementos de esto en cómo Google se está moviendo a una meta-biblioteca que simplemente sirve como un cargador para sus otras bibliotecas. Este es un paso hacia la unificación de las llamadas de carga para Google Apps, Google AdSense, Google Maps, Google Adwords, etc.
Si quería ser un poco inteligente, puede ser como Google Maps y agregar una píldora de veneno a sus bibliotecas de JavaScript, ya que se sirven dinámicamente para que solo operen en un subdominio en particular. Esto requiere generarlos según sea necesario, y si bien siempre puede eliminarse con suficiente experiencia, evita el uso total de copiar y pegar sus archivos JavaScript. Insertar una llamada inteligente que valide document.href no es difícil, y encontrar todas estas instancias en un archivo minimizado agresivamente sería especialmente irritante y probablemente no valga la pena.