¿El caso de ofuscación de código?

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 suministrar a cada cliente versiones de la aplicación ofuscadas de manera diferente, si se encuentra una copia ilícita, el autor puede compararla con las versiones suministradas y rastrear el origen de la piratería.

Es una forma de steganography , inspirada y en la variación de "traitor trazando "esquemas criptográficos . No tengo idea de 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 de desarrollo promedio para ambas aplicaciones fue de 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 justificación fue, por supuesto, seguridad a través de la oscuridad inicialmente, y evolucionó en el esquema mencionado anteriormente 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 largo plazo. Ambos proveedores tenían equipos altamente motivados y talentosos, que trabajaban en un nicho de mercado extremadamente rentable. Al final, nuestros productos eran más similares que no, y cualquier ventaja competitiva se obtenía 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 corresponde) y (b) algunos de mi participación en el proyecto fue bajo un NDA.

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

  

Si su empresa realiza trabajo de IP para compañías de tecnología, o participa en casos relacionados con el código fuente del software, es posible que esté obligado a 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 para que no se pueda utilizar 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, dado que 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 el Javascript ofuscado. Aunque hay ventajas definitivas en la reducción de ³ Javascript, no veo ningún punto en la ofuscación real y estoy feliz Douglas Crockford está de acuerdo conmigo :

  

Entonces, finalmente, está la cuestión de la privacidad del código. Esta es una causa perdida. No hay ninguna transformación que impida que un hacker determinado entienda su programa. Esto resulta ser cierto para todos los programas en todos los idiomas, es más obvio que con JavaScript porque se entrega en formato fuente. El beneficio de privacidad provisto por la ofuscación es una ilusión. Si no quieres que la gente vea tus programas, desconecta tu servidor.

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

En conclusión, la ofuscación es un ejemplo típico de seguridad a través de la oscuridad, solo es un mérito evidente como elemento disuasivo y nada más. Puede haber casos de uso creativos ⁴ 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 que pensé.
² Aunque la esteganografía sigue siendo seguridad a través de la oscuridad.
³ Minification ~ eliminando espacios en blanco y acortando tokens, sin oscurecer intencionalmente.
⁴ ¿Cuenta el concurso internacional de códigos C ofuscados ?}

El caso de ofuscación de código es que eleva el nivel de un tercero para determinar qué / cómo funciona el código.

Sin embargo, eso significa que NO significa que un desarrollador debería escribir código confuso.

Vea, este es el bit que creo que falta en su pregunta: la ofuscación de código (al igual que la reducció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ódigos

  

Los resultados muestran que el cambio de nombre del identi fi cador disminuye significativamente el   eficiencia de los ataques, al menos duplicando el tiempo necesario para completar una   ataque exitoso (incluso en el peor escenario, es decir, contra el   mejor atacante). Además, la ofuscación reduce la brecha entre   atacantes novatos y hábiles, haciendo 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 aquellos   que son intrínsecamente más difíciles de romper.

Énfasis mío.

He participado en el desarrollo de un MMORPG. Esto implicó la lógica del servidor y la lógica del cliente. A lo largo de los muchos años de desarrollo del proyecto, siempre que consideramos la interfaz entre el cliente y el servidor, la regla era que el servidor debía tratar al cliente en todo momento bajo la presunción de que había sido hackeado. En otras palabras, el servidor tuvo que escribirse de tal manera que no hubiera ninguna respuesta que pudiera provenir del cliente que pudiera causar fallas en el servidor, o permitir que el cliente haga trampa. Aún así, se sabía desde el principio que los hackers 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 que existe, nos aseguramos de ofuscarlo. Creemos que la ofuscación tuvo los siguientes efectos:

1. Disuadió a los piratas informáticos no expertos de intentarlo.
2. Retrasó a los hackers expertos para lograr cualquier pirateo.
3. Redujo la cantidad de piruetas logradas por piratas informáticos expertos.
4. Limitó la efectividad de los hacks.
5. Lo más importante: provocó que los piratas informáticos realizaran más ejecuciones de prueba con sus clientes pirateados en comparación con nuestros servidores antes de lograr un hack, lo que incrementó las posibilidades de que los descubriéramos al buscar una actividad irregular en los registros del servidor.

Las cuentas de juego de los piratas informáticos descubiertos se cancelaron sin un reembolso, por lo que el negocio de piratería fue 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 hackeado. (Por ejemplo, software que contiene medidas de protección contra copia).

Los efectos que la ofuscación tuvo en el mantenimiento fueron casi nulos. Había algunos lugares donde algunos programadores inexpertos hacían suposiciones sobre los nombres de los identificadores, (estaban utilizando la reflexión), pero una vez que se resolvieron, todo estaba bien. El paso de ofuscación se convirtió en parte del paso de compilación general para la versión de producción del juego, por lo que la mayoría de los desarrolladores nunca tuvimos que preocuparnos por eso ni tener nada que ver con eso. Ya contábamos con una herramienta para ver los registros del juego, así que modificamos la herramienta para usar la tabla de asociación (mapeo de identificadores confusos e identificadores adecuados) producida por el ofuscador para poder traducir los registros para nosotros sobre la marcha, por lo que nunca Incluso tuve que ver cualquier identificador ofuscado mientras realizaba exámenes post mortem basados en registros recopilados en el campo.

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