Ingeniería inversa para todos y todas

Un aparato puede dejar de ser útil mucho antes de que se rompa. Su pantalla puede funcionar perfectamente. Los botones hacen clic como corresponde y cada uno de sus componentes electrónicos zumba prácticamente como el primer día. Pero puede depender de un servicio que ya no responde o haber dejado de recibir las actualizaciones necesarias para seguir siendo seguro. A veces, también, su vida útil puede quedar a merced del capricho de alguien que, luego de una reunión en un último piso, decide que es necesario incrementar las ventas. Sin importar cuánto cuidemos nuestros objetos electrónicos, su obsolescencia muchas veces responde a arbitrarios motivos que nos escapan.

Históricamente, devolverle vida a estos aparatos inspiró a un puñado de personas empecinadas en desentrañar cómo funcionaban, para que pudieran seguir haciéndolo. Pusieron su ingenio y curiosidad al servicio de estirar su vida útil y rehusarse a aceptar una condena injusta. A este arte de entender cómo funciona alguna cosa sin necesariamente conocer cómo fue hecha se lo conoce como ingeniería inversa: se parte de un objeto o un programa para ir hacia atrás, examinar sus partes, observar cómo interactúan y arriesgar hipótesis sobre su funcionamiento.

A fuerza de rebusque, maña y trabajo detectivesco, muchas veces podemos, si no reconstruir cómo algo fue hecho, al menos hacernos una idea lo suficientemente precisa como para poder meter mano. En el caso del software, esto puede ser especialmente demandante. Los programas que instalamos generalmente fueron compilados, esto es, fueron traducidos de un lenguaje de programación al lenguaje que entienden las máquinas (el famoso código binario). Esto impide que podamos simplemente leer el código tal como sus programadores lo escribieron. Nos queda la tarea de investigar las operaciones que realiza y cómo se conectan para empezar a darles sentido.

De más está decir que esto no solo lo hacen hobbistas en su tiempo libre: en algunos casos fue como surgieron ciertas empresas de tecnología. Un caso muy famoso es el de Compaq, el ahora extinto fabricante de computadoras, cuya historia inspiró el comienzo de la serie Halt and Catch Fire: no alcanzaba con que se pareciera a una IBM sino que tenía que poder funcionar como una. Uno de los obstáculos era el BIOS, aquello que conecta el hardware con el sistema operativo, dicho mal y pronto. Como este código era propiedad de IBM, Compaq necesitaba reproducir su funcionamiento sin copiarlo.

Como cuenta en su libro Rod Canion, uno de los fundadores de Compaq, se repartieron el trabajo entre varios: uno estudiaba qué hacía el código de IBM y lo describía, el otro debía usar esa descripción para escribir uno nuevo funcionalmente equiparable. Este método, conocido como diseño en habitación limpia, les permitió lanzar su Compaq Portable en 1983, compatible con el software de sus clientes acostumbrados a IBM.

Pero las restricciones tecnológicas no tienen por qué ser absolutas para ser efectivas: un fabricante puede convivir con la posibilidad de que alguien entienda o reproduzca su producto si para lograrlo hace falta dedicar suficiente dinero, conocimiento y paciencia. Esa dificultad funciona como una protección práctica, incluso si no es una barrera infranqueable.

El panorama cambia cuando parte de ese trabajo se terceriza en una máquina que puede seguir intentando y buscando alternativas sin tener que comer o ir al baño. Sin ir más lejos, en los últimos tiempos circularon un montón de ejemplos de personas que recurrieron a agentes de inteligencia artificial para investigar y modificar programas y dispositivos. Con herramientas específicas para inspeccionar software, los agentes pueden examinar partes de un programa, interpretar los resultados y repetir el proceso para entender sus conexiones. Por último, intentan reconstruir su funcionamiento.

Algunos de los ejemplos más llamativos son incluso reconfortantes: personas que lograron revivir smart TVs cuyo soporte se extinguió hace quizá una década, o que lograron cambiar el código específico que corre en aparatos como un portarretratos digital, o personas que lograron bloquear las publicidades en dispositivos que no daban esa opción. En resumen, esta ingeniería inversa facilitada les permitió a muchas personas devolverles utilidad a sus viejos aparatos o bien ajustar su funcionamiento a sus deseos.

Esto también toma trabajo, pero ya no es de la misma naturaleza que la ingeniería inversa a la vieja usanza. La sensación, cuando dejamos que la computadora programe por nosotros, suele ser que el primer 90 % es entre prometedor y absolutamente increíble, y luego nos queda un 10 % que se estira eternamente: hay que entender qué hizo la máquina por nosotros y cómo podemos extinguir los errores que trae su código.

Las anécdotas se distribuyen entre personas que se jactan de nunca haber escrito una línea de código en su vida y, sin embargo, pudieron lograr una proeza destacable, y aquellos programadores con décadas de experiencia encima que a veces son un poco más cautos en su entusiasmo. En un caso bien documentado, un programador cuenta cómo pasó tres meses tratando de reconstruir un videojuego y, en particular, se detiene en las limitaciones del código que le devolvió su agente de inteligencia artificial. Una de las tareas fundamentales de la ingeniería inversa es la comprobación o corroboración de los resultados propios. De ahí que sea una actividad tan demandante de tiempo y energía.

La diferencia entre una posibilidad teórica y una posibilidad práctica tiene implicancias para una empresa de tecnología: no es lo mismo dedicar seis meses a entender un dispositivo que poder hacerlo en un fin de semana. Para quienes están dedicando estas capacidades a extender la vida de aparatos que funcionan perfectamente: brindemos por ellos. Las posibilidades son entusiasmantes: la obsolescencia programada, o el deliberado recorte de la vida útil de un producto más allá de su concreta utilidad, podría finalmente reducirse.

Por otro lado, también está el genuino placer de la reapropiación tecnológica: hacer a un lado la intención que se le haya dado a un objeto y resignificarlo a partir de nuestra dedicación, para que funcione tal como lo imaginamos. Aquello que compramos ya no tiene por qué forzarnos a su consumo pasivo bajo las reglas de otros. Podemos meter mano en los objetos con los que habitamos.

Quizá lo que vuelve a este asunto tan atractivo en términos de la ética hacker es que parecería tener un componente justiciero. Algo que, aunque remotamente, podría recordarnos a Robin Hood: la corrección de algo que desde el principio estuvo mal.

La cuestión es quizá la escala. No hace falta que todos nos volvamos expertos: alguien puede hacer el trabajo y compartir el resultado. Una modificación puede pasar así de la proeza individual a una opción disponible para miles de usuarios, capaz de cambiar las condiciones de juego.

Lejos de estar intentando una defensa de las pobres empresas de tecnología y sus abusivas prácticas, también es cierto que algunos modelos de negocios se apoyan en que los usuarios no puedan modificar los productos que compran. El caso típico es la publicidad. Aunque es tentador imaginar a cada persona modificando el software de su televisor, conviene recordar todas las cosas que podríamos hacer y para las que no encontramos tiempo ni motivación. También en nuestra pereza se apoyan muchos de estos negocios, pero esta puede tener menos peso si alcanza con instalar lo que resolvió alguien más.

De todas maneras, modificar un aparato propio no es lo mismo que fabricar una alternativa para competir con quien lo vende. Aunque una cosa no necesariamente siga a la otra, cuando hace un tiempo apareció ArtCraft, una suite de alternativas a los programas de Adobe desarrolladas con IA, algunas proyecciones redujeron casi un 1% sus estimaciones de ingresos. El temor es que algunos usuarios dejen de pagar. Y bien merecido lo tienen.

La ingeniería inversa es una realidad desde el momento en que se inventa cualquier cosa. Pero el tiempo y el costo de reconstruir un producto pueden darle a su fabricante margen para recuperar la inversión. Si esa ventana se reduce, cambia el equilibrio y pueden cambiar los incentivos para innovar. Eso no vuelve indeseable a la competencia: Compaq no necesitaba preservar el negocio de IBM para hacer algo valioso.

El desarrollo de tecnología apoyado en inteligencia artificial también sirve a la ingeniería, y no solo en su variedad inversa, por lo que podría argumentarse que también disminuyen los costos de desarrollo. Pero algo que es fácil dejar de lado es el conocimiento específico que lleva al desarrollo y mantenimiento de un producto. Aunque, a partir de algo terminado, podamos darnos cierta idea más o menos acabada de cómo funciona, esto no necesariamente reconstruye cómo fue el proceso por el cual ese producto originalmente llegó a existir.

A esta altura cabe recordar que alternativas libres a herramientas comerciales de diseño existen desde hace mucho tiempo, fruto del esfuerzo de personas que las mantienen. No es lo mismo sostener ese trabajo que darle cada tanto una instrucción a un agente y seguir con otra cosa. El problema continúa después de conseguir que un programa funcione por primera vez.

El código abierto (y el software libre) ofrece la experiencia de mantener trabajo que otros pueden inspeccionar y modificar. Pero una organización que abraza la apertura desde el vamos arranca bajo condiciones distintas de otra ahora forzada a sobrevivir a un cambio abrupto en la forma en que gana dinero.

El panorama podría volverse oscuro también por otros motivos. Una posible respuesta de las empresas es llevar más funciones a sus propios servidores: si el código no llega a nuestra computadora, ya no podemos inspeccionarlo allí. Podríamos ganar control sobre los aparatos que tenemos y perderlo en los que vendrán después.

A quien revive un aparato abandonado no le cabe la responsabilidad de resolver cómo habrá de mantenerse solvente la empresa que lo fabricó. Y, sin embargo, a medida que este tipo de hazañas se vuelvan más comunes, sus consecuencias podrían alcanzar a personas que en su vida le pedirían a una inteligencia artificial que analice cómo fue desarrollado un programa.

Deshacernos de las viejas limitaciones no define, por sí solo, bajo qué condiciones vamos a fabricar, usar y mantener lo que vendrá después.