El caso de la ofuscación del código?

¿Cuáles son las principales razones para escribir código ofuscado, en términos de un beneficio real para las personas que desarrollan el código y la empresa que ejecuta ese código (si el código en cuestión es de hecho código comercial)? ¿Hay casos documentados (disponibles en línea en algún lugar) que describen cuándo la ofuscación fue más buena que mala? ¿Existen ejemplos bien conocidos en los que, por ejemplo, se haya comprobado que la ofuscación retrasa significativamente a un tercero malintencionado para acceder al código? Parece que, al igual que enrollar las ventanas de su automóvil no evitará que las personas las rompan y roben su estéreo, ofuscar su código solo hace que la gente honesta sea honesta.

=========

Antecedentes:

Este es un intento de desafiar deliberadamente mis suposiciones sobre este tema.

Estoy en contra de usar ofuscación de código en general, pero tengo curiosidad si me falta algo. Entiendo por qué, en casos como JavaScript, la minificación ayuda a que las cosas se carguen más rápido y todo (hay un beneficio real y funcional allí), pero parece que no puedo encontrar una sola razón por la cual la ofuscación del código, con el propósito de ser un obstáculo descubrir lo que hace una sección de código / algoritmo es realmente efectivo para cualquier propósito.

Dado que el código abierto es muy popular, la pregunta parece ser "¿compartir el código o mantenerlo en propiedad?" Cuando se trata de código comercial, puedo entender por qué no puedes compartir todo, y tienes la ley a tu lado para luchar contra el robo.

Por cierto, si la razón por la que alguien está escribiendo un código ofuscado es "seguridad laboral", entonces despediría a cualquier programador que se encuentre consistentemente y deliberadamente usando la ofuscación con el único propósito de ayudar a mantener sus trabajos, a menos que puedan demostrar razonablemente que tenía beneficio comercial Es tan completamente anti-equipo que es ridículo, y señala a alguien que está más preocupado por mantener su trabajo a través de prácticas equivocadas, y luego mantenerlo porque escriben un software increíble.

Solo menciono este caso específico porque, aunque me doy cuenta de que la gente suele estar bromeando, me gustaría disuadir cualquier respuesta cuyo objetivo básico sea que la ofuscación por la seguridad laboral es una buena idea.

Un caso de uso muy interesante para la ofuscación es rastrear el origen de las copias ilícitas. Suponiendo que la ofuscación es una operación relativamente barata, el autor original puede proporcionar a cada cliente versiones de la aplicación ofuscadas de manera diferente, si se encuentra una copia ilícita, el autor puede comparar con las versiones proporcionadas y rastrear el origen de la piratería.

Esa es una forma de esteganografía , inspirada y en variación de los esquemas criptográficos de "rastreo de traidores" . No tengo idea si es común ¹ , o incluso si es una buena idea, pero lo he visto aplicado en la práctica bajo los siguientes parámetros:

• Mercado nacional altamente competitivo con solo dos proveedores,
• Alrededor de 50 implementaciones cubrieron el mercado,
• El tiempo promedio de desarrollo para ambas aplicaciones fue un par de años (más o menos),
• El tiempo promedio de ofuscación para nuestra aplicación fue de un par de horas,
• Se esperaba que la vida útil de ambas aplicaciones fuera de unos diez años.

La razón era, por supuesto, la seguridad a través de la oscuridad inicialmente, y evolucionó en el esquema antes mencionado en algún momento ² . Ambos proveedores tenían acceso al código binario del otro, legalmente, y creo que es obvio que se esperaban intentos de descompilación de ambos. La ofuscación no hizo nada en términos de seguridad, a la larga. Ambos proveedores tenían equipos altamente motivados y talentosos, trabajando en un mercado extremadamente rentable y nicho, al final nuestros productos eran más similares que no, y cualquier ventaja competitiva se obtuvo a través de otros medios menos oscuros.

Realmente no puedo expandirme, porque (a) fue muy temprano en mi carrera y no obtuve una visión clara de las decisiones de diseño o los resultados del esquema de rastreo (si lo hubiera) y (b) algo de mi participación con el proyecto estaba bajo un NDA.

Otro caso de uso válido para la ofuscación podría ser cuando de alguna manera está legalmente obligado a enviar su código a un tercero :

Si su empresa trabaja con IP para empresas de tecnología, o está involucrado en casos relacionados con el código fuente del software, es posible que deba enviar el código fuente de su cliente a la USPTO, un tribunal o un tercero.

Dado que el código fuente se considera un secreto comercial, la mayoría de las agencias reguladoras usan una regla del "50%". El código fuente enviado está oculto, por lo que no se puede usar como está.

IANAL, y el enlace es más relevante para las copias impresas del código en lugar del código de trabajo real, por lo que esto podría ser completamente irrelevante.

Ahora, como Javascript es el ejemplo canónico para la ofuscación, hay un efecto secundario que no se considera comúnmente, y que oculta el código malicioso en Javascript ofuscado. Aunque hay ventajas definitivas en minificar ³ Javascript, no veo ningún punto en la ofuscación real y estoy feliz de que Douglas Crockford esté de acuerdo conmigo :

Luego, finalmente, está la cuestión de la privacidad del código. Esta es una causa perdida. No hay transformación que impida que un hacker determinado comprenda su programa. Esto resulta ser cierto para todos los programas en todos los idiomas, simplemente es más cierto con JavaScript porque se entrega en forma de fuente. El beneficio de privacidad proporcionado por la ofuscación es una ilusión. Si no desea que la gente vea sus programas, desconecte su servidor.

En cuanto a la ofuscación por la "seguridad laboral", ese es un comportamiento que nunca debe pasar la revisión del código, y si se identifica no se debe tolerar. No iría tan lejos como para despedir al culpable al principio, pero los delincuentes reincidentes definitivamente merecen una buena paliza, al menos.

En conclusión, la ofuscación es un ejemplo típico de seguridad a través de la oscuridad, solo es obvio que el mérito es como elemento disuasorio y nada más. Puede haber casos de uso creativo ⁴ que no conozco, pero en general los beneficios son mínimos, en el mejor de los casos.

_{¹ Después de escribir esto, descubrí esta respuesta que básicamente describe el mismo esquema, por lo que podría ser más común de lo que pensaba.
² Aunque la esteganografía sigue siendo seguridad a través de la oscuridad.
³ Minificación ~ eliminar espacios en blanco y acortar fichas, sin oscurecer intencionalmente.
⁴ ¿Cuenta el concurso internacional de código C ofuscado ?}

El caso de la ofuscación del código es que eleva el listón para que un tercero determine qué / cómo funciona el código.

Sin embargo, eso NO significa que un desarrollador deba escribir código ofuscado.

Mira, este es el bit que creo que falta en tu pregunta: la ofuscación de código (al igual que la minificación de JavaScript) no necesita, y no debe, hacerse manualmente por el desarrollador. Del mismo modo, esto tampoco debe almacenarse como sus archivos fuente principales en el control de versiones.

La ofuscación de código debe ocurrir como un paso de procesamiento posterior durante la compilación en su compilación de producción. También hay muchos productos de terceros para hacer esto, por lo que casi no hay razón para hacerlo en casa.

Por ejemplo: Dotfuscator

El IEEE tiene un documento sobre la efectividad de la ofuscación de código

Los resultados muestran que el cambio de nombre del identificador disminuye significativamente la eficacia de los ataques, al menos duplicando el tiempo necesario para completar un ataque exitoso (incluso en el peor de los casos, es decir, contra el mejor atacante). Además, la ofuscación reduce la brecha entre los atacantes novatos y expertos, lo que hace que estos últimos sean menos eficientes y hace que los sistemas que son más fáciles de atacar en claro sean más similares a los que son intrínsecamente más difíciles de romper.

El énfasis es mío.

He participado en el desarrollo de un MMORPG. Esto implicaba la lógica del servidor y la lógica del cliente. Durante el desarrollo de muchos años del proyecto, siempre que consideramos la interfaz entre el cliente y el servidor, la regla era que el cliente debería ser tratado por el servidor en todo momento bajo la presunción de que ha sido pirateado. En otras palabras, el servidor tenía que estar escrito de tal manera que no hubiera respuesta del cliente que pudiera causar que el servidor fallara, o permitir que el cliente hiciera trampa. Sin embargo, desde el principio se supo que los piratas informáticos inevitablemente encontrarían agujeros en el sistema y los explotarían para hacer trampa. Y después de un tiempo lo hicieron.

Por supuesto, antes de enviar al cliente al gran mundo, nos aseguramos de ofuscarlo. Creemos que la ofuscación tuvo los siguientes efectos:

1. Disuadió a los hackers no expertos de intentarlo.
2. Retrasó a los piratas informáticos expertos para lograr cualquier pirateo.
3. Redujo el número de hacks logrados por hackers expertos.
4. Limitó la efectividad de los hacks.
5. Lo más importante: causó que los piratas informáticos realizaran más ejecuciones de prueba con sus clientes pirateados en nuestros servidores antes de lograr un pirateo operativo, lo que aumentó las posibilidades de que los descubramos buscando actividad irregular en los registros del servidor.

Las cuentas de juegos de piratas informáticos descubiertos se cancelaron sin un reembolso, por lo que esto hizo que el negocio de piratería sea más costoso y menos atractivo.

Entonces, debido a todo lo anterior, creo que la ofuscación tuvo un efecto positivo general en nuestro juego, y por extensión, la ofuscación puede tener un efecto positivo general en cualquier pieza de software que pueda ser pirateada. (Por ejemplo, software que contiene medidas de protección contra copia).

Los efectos que la ofuscación tuvo en el mantenimiento fueron casi nulos. Hubo algunos lugares donde algunos programadores inexpertos estaban haciendo suposiciones sobre los nombres de los identificadores (estaban usando la reflexión), pero una vez que se resolvieron, todo estuvo bien. El paso de ofuscación se convirtió en parte del paso de construcción general de la versión de producción del juego, por lo que la mayoría de nosotros, los desarrolladores, nunca tuvimos que preocuparnos ni tener nada que ver con eso. Ya teníamos una herramienta para ver los registros del juego, por lo que modificamos la herramienta para usar la tabla de asociación (mapeo de identificadores ofuscados a identificadores adecuados) producidos por el ofuscador para traducir los registros para nosotros sobre la marcha, por lo que nunca incluso tuvo que ver cualquier identificador ofuscado mientras realizaba exámenes post mortem basados ​​en registros recopilados en el campo.

Leer y comprender (y obviamente escribir) código ofuscado puede ser un desafío mental interesante. Probablemente esté fuera del alcance de lo que estaba preguntando, pero ejemplos como IOCCC pueden ser una fuente de diversión y horror.