Pregunta

¿Alguien conoce un buen oscurecedor de código para Perl?Me piden que analice la opción de ocultar el código antes de entregárselo a un cliente.Sé que el código ofuscado todavía se puede aplicar ingeniería inversa, pero esa no es nuestra principal preocupación.

Algunos clientes están haciendo pequeños cambios al código fuente que les damos y nos dan pesadillas cuando algo sale mal y tenemos que arreglarlo, o cuando lanzamos un parche que no funciona con lo que han cambiado.Entonces, la intención es simplemente hacer que les resulte difícil realizar sus propios cambios en el código (de todos modos, se supone que no deben hacerlo).

¿Fue útil?

Solución

He pasado por este camino antes y es una pesadilla absoluta cuando tienes que trabajar en código "ofuscado" porque aumenta enormemente los costos al tratar de depurar un problema en el servidor del cliente cuando tú, el desarrollador, no puedes leer el código. .Termina con "desofuscadores", copiando el "código real" al servidor del cliente o cualquiera de una serie de otros problemas que se convierten en una verdadera molestia de mantener.

Entiendo de dónde vienes, pero parece que la gerencia tiene un problema y están esperando que usted implemente una solución elegida en lugar de descubrir cuál es la solución correcta.

En este caso, parece que se trata realmente de una cuestión contractual o de licencia.Permítales tener el código fuente abierto, pero hágalo parte de la licencia que cualquier cambio que envíen debe regresar a usted y ser aprobado.Cuando publique parches, verifique las sumas md5 de todo el código y, si no coincide con lo esperado, están violando la licencia y se les cobrará en consecuencia (y debería ser una tarifa mucho, mucho más alta).(Recuerdo una empresa que nos permitió tener el código de código abierto, pero dejó claro que si cambiábamos algo, "compramos" el código por 25.000 dólares y ya no eran responsables de ninguna corrección de errores o actualizaciones a menos que compráramos un nueva licencia).

Otros consejos

No.Simplemente no lo hagas.

Escríbalo en el contrato (o revise el contrato si es necesario), que no es responsable de los cambios que realicen en el software.Si están arruinando tu código y luego esperan que lo arregles, tienes problemas con el cliente que no se resolverán ofuscando el código.Y si lo confunde y encuentran un problema real, buena suerte para que informen con precisión el número de línea, etc., en el informe de error.

Por favor no hagas eso.Si no desea que la gente altere su código Perl, colóquelo bajo una licencia adecuada y haga cumplir esa licencia.Si las personas cambian su código cuando su licencia dice que no deberían hacerlo, entonces no es su problema cuando sus actualizaciones ya no funcionan con su instalación.

Ver La respuesta de perlfaq3 a "¿Cómo puedo ocultar el código fuente de mis programas Perl? para más detalles.

Parecería que su principal problema es que los clientes modifican el código, lo que le dificulta admitirlo.Le sugeriría que solicite sumas de verificación (md5, sha, etc.) de sus archivos cuando acudan a usted en busca de soporte y, de manera similar, verifique las sumas de verificación de los archivos cuando apliquen parches.Por ejemplo, puede pedirle al cliente que proporcione el resultado de un programa proporcionado que realice su instalación y sume todos los archivos.

En última instancia, ellos tienen el código, por lo que pueden hacer lo que quieran con él.Lo mejor que puede hacer es hacer cumplir sus licencias y asegurarse de que solo admite código no modificado.

En este caso, ofuscar es el enfoque equivocado.

Cuando entrega el código al cliente, debe conservar una copia del código que le envía (ya sea en el disco o preferiblemente en su control de versiones como una etiqueta/rama).

Luego, si su cliente realiza cambios, puede comparar el código que tiene con el código que le envió y detectar fácilmente los cambios.Después de todo, si sienten la necesidad de realizar cambios, hay un problema en alguna parte y debes solucionarlo en el código base maestro.

Otra alternativa para convertir su programa a binario es la gratuita Empacador PAR herramienta en CPAN.Incluso hay filtros para la ofuscación de código, aunque, como han dicho otros, eso posiblemente sea más problemático de lo que vale.

Estoy de acuerdo con las sugerencias anteriores.

Sin embargo, si realmente lo deseas, puedes investigar PAR y/o Filtro::Cripto Módulos CPAN.También puedes usarlos juntos.

Utilicé este último (Filter::Crypto) como una forma realmente ligera de "protección" cuando enviábamos nuestro producto en medios ópticos.No te "protege", pero detendrá al 90% de las personas que quieran modificar tus archivos fuente.

Esta no es una sugerencia seria, sin embargo, eche un vistazo a Acme::Buffy.

¡Al menos te alegrará el día!

Una alternativa a la ofuscación es convertir su script a binario usando algo como Kit de desarrollo Perl de ActiveState.

Estoy ejecutando un sistema operativo Windows y uso perl2exe de IndigoSTAR.Es poco probable que el archivo .EXE resultante se modifique en el sitio.

Como han dicho otros, "¿cómo puedo ofuscarlo?" es la pregunta equivocada."¿Cómo evito que el cliente cambie el código?" es la correcta.

Las ideas de suma de verificación y contrato son buenas para prevenir los "problemas" que usted describe, pero si el costo para usted es la dificultad de implementar actualizaciones y correcciones de errores, ¿cómo hacen sus clientes cambios que no pasan los requisitos? conjunto de pruebas completo?Si son capaces de realizar estos cambios (o al menos, realizar un cambio que exprese lo que quieren que haga el código), ¿por qué no simplemente facilitarles o automatizar la apertura de un ticket de soporte y cargar el parche?El cliente siempre tiene la razón sobre lo que el cliente quiere (Es posible que no tengan idea de cómo hacerlo "de la manera correcta", pero es por eso que le pagan).

Una mejor razón para querer un ofuscador sería la implementación de escritorios en el mercado masivo donde no todos los clientes tienen un contrato permanente.En ese caso, algo como PAR: cualquier cosa que incluya la lógica de cifrado/ofuscación en un binario compilado es el camino a seguir.

Como ya han dicho varias personas:no.

Está bastante implícito, dada la naturaleza del intérprete de Perl, que cualquier cosa que haga para ofuscar Perl debe poder deshacerse antes de que Perl lo tenga en sus manos, lo que significa que debe dejar el script/binario de de ofuscación tirado donde está el intérprete. (y por lo tanto su cliente) puede encontrarlo :)

Solucionar el verdadero problema:sumas de verificación y/o una licencia debidamente redactada.Y el personal de soporte está capacitado para decir '¿lo cambiaste?'estamos invocando la cláusula 34b de nuestra licencia, y serán $X,000 antes de que la toquemos'...

Además, lea ¿Por qué debería usar la ofuscación? para una respuesta más general.

Simplemente los invitaría a mi árbol SVN en su propia rama para que puedan proporcionar cambios y yo pueda verlos e integrar sus cambios en mi árbol de desarrollo.

No luches contra ello, abrázalo.

Como dice Ovidio, es un problema social contractual.Si cambian el código invalidan la garantía.Cobrarles mucho para arreglar eso, pero al mismo tiempo, darles un canal donde puedan sugerir cambios.Además, mire lo que quieren cambiar y, si puede, hágalo parte de la configuración.Tienen algo que quieren hacer y, hasta que usted lo satisfaga, seguirán intentando eludirlo.

En Dominar Perl, hablo un poco sobre derrotar a los ofuscadores.Incluso si haces cosas como crear nombres de variables sin sentido y similares, módulos como B::Salir y B::Desofuscar, junto con herramientas Perl como Perl::Ordenado, haga que sea bastante fácil para la persona conocedora y motivada obtener su fuente.No tienes que preocuparte tanto por los desconocidos y desmotivados porque de todos modos no saben qué hacer con el código.

Cuando hablo con los gerentes sobre esto, realizamos el análisis normal de costo-beneficio.Hay todo tipo de cosas que podría hacerlo, pero no mucho cuesta menos que el beneficio que obtiene.

Buena suerte,

Otra sugerencia no seria es usar Acme::blanqueador, hará que tu código esté muy limpio ;-)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top