Fast16: sabotaje de software de alta precisión, 5 años antes de Stuxnet

 (sentinelone.com)
2 puntos por GN⁺ 2 일 전 | 1 comentarios | Compartir por WhatsApp
  • Framework de sabotaje no documentado creado en 2005, diseñado para parchear el código en memoria de software de cálculo seleccionado y distorsionar los resultados numéricos
  • svcmgmt.exe parece por fuera un envoltorio de servicios, pero por dentro contiene una máquina virtual Lua 5.0, bytecode cifrado, DLL auxiliares y el controlador fast16.sys, con lo que ejecuta por separado payloads específicos para cada tarea
  • fast16.sys es un controlador de sistema de archivos de inicio de arranque que se carga en una etapa muy temprana y luego selecciona .EXE compilados con Intel C/C++ Compiler para aplicar parches de memoria a nivel kernel
  • El motor de parches opera con 101 reglas y, en particular, usa bloques de instrucciones FPU para cambiar el escalado de valores en arreglos internos, dejando rastros de haber apuntado a herramientas de cálculo especializadas como ingeniería civil, física y simulación de procesos
  • Al combinarlo con la marca fast16 de la filtración de ShadowBrokers, queda claro que ya existía sabotaje industrial de precisión antes de Stuxnet, en una forma que combinaba scripting embebido, targeting estrecho y parches de kernel

Resumen e indicios de identificación

  • fast16 es un framework de ciber-sabotaje no documentado con componentes centrales de 2005, donde fast16.sys apunta selectivamente a software de cálculo de alta precisión, parchea código en memoria y distorsiona los resultados de los cálculos
  • svcmgmt.exe parece por fuera un envoltorio de servicios típico de la era Windows 2000/XP, pero en su interior contiene una máquina virtual Lua 5.0 y un contenedor de bytecode cifrado que el punto de entrada del servicio descifra
  • En el proceso de rastrear malware basado en Lua, fueron pistas los magic bytes del bytecode 1B 4C 75 61, el byte de versión, LUA_PATH y una API C característica, y en ese flujo se identificó svcmgmt.exe
  • La cadena C:\buildy\driver\fd\i386\fast16.pdb dentro de svcmgmt.exe sirve como pista forense que conecta el ejecutable del servicio con el proyecto del controlador de kernel
  • En drv_list.txt de la filtración de ShadowBrokers de 2017 también aparece el mismo fast16, lo que vincula en una sola línea la cadena PDB de svcmgmt.exe y el controlador de sabotaje de precisión
  • La firma de evasión del lado de ShadowBrokers incluía la frase fast16 *** Nothing to see here – carry on***

Estructura del carrier y modo de ejecución

  • svcmgmt.exe está diseñado como un carrier adaptativo que cambia su comportamiento según los argumentos de línea de comandos
    • Sin argumentos: se ejecuta como servicio de Windows
    • -p: configura InstallFlag = 1 y se ejecuta como servicio
    • -i: configura InstallFlag = 1 y ejecuta código Lua
    • -r: ejecuta código Lua sin flag de instalación
    • Cualquier otro <filename>: opera en modo Wrapper/Proxy, creando dos procesos hijo, uno con el comando original y otro con el comando más el argumento -r
  • El almacenamiento interno incluye bytecode Lua cifrado, DLL auxiliares y el controlador fast16.sys
  • El entorno Lua está ampliado más allá del estado base y ofrece el módulo wstring, la función criptográfica simétrica integrada b, y módulos de binding para APIs de Windows NT de sistema de archivos, registro, control de servicios y red
  • El binario carrier externo se mantiene relativamente estable, mientras que los payloads específicos de cada tarea se separan en forma cifrada para poder reutilizarlos según el entorno y el objetivo operativo
  • Los identificadores de svcmgmt.exe son los siguientes
    • Nombre de archivo svcmgmt.exe
    • Tamaño 315,392 bytes
    • MD5 dbe51eabebf9d4ef9581ef99844a2944
    • SHA1 de584703c78a60a56028f9834086facd1401b355
    • SHA256 9a10e1faa86a5d39417cae44da5adf38824dfb9a16432e34df766aa1dc9e3525
    • Tipo PE32 executable for MS Windows 4.00 (console), Intel i386
    • Hora de enlace 2005-08-30 18:15:06 UTC

Estructura de propagación por wormlets y evasión

  • svcmgmt.exe funciona como un carrier tipo munición de racimo capaz de transportar varios wormlets, y en la muestra confirmada solo se encontró un wormlet SCM
  • El flujo de ejecución continúa con preparación de configuración, conversión a cadenas anchas, elevación de privilegios, instalación e inicio del servicio SvcMgmt, despliegue condicional de fast16.sys, liberación del wormlet, retraso inicial y ejecución repetida hasta alcanzar un umbral de fallos o una condición externa de terminación
  • El wormlet SCM apunta a entornos Windows 2000/XP y usa recursos compartidos de archivos con contraseñas de administrador débiles o por defecto para encontrar servidores en la red, copiar el payload y luego iniciar servicios remotos
  • La propagación no depende de un protocolo de red personalizado, sino de funciones estándar de administración de Windows como la API de control de servicios y la API de recursos compartidos de archivos
  • Antes de instalar, ok_to_install() llama a ok_to_propagate() para revisar el entorno y, salvo que haya una imposición manual, determina si puede propagarse según la presencia de claves de registro de ciertos productos de seguridad
  • Si existe хотя бы una de las siguientes claves de registro, la instalación se detiene para evitar desplegarse en entornos monitorizados
    • HKLM\SOFTWARE\Symantec\InstalledApps
    • HKLM\SOFTWARE\Sygate Technologies, Inc.\Sygate Personal Firewall
    • HKLM\SOFTWARE\TrendMicro\PFW
    • HKLM\SOFTWARE\Zone Labs\TrueVector
    • HKLM\SOFTWARE\F-Secure
    • HKLM\SOFTWARE\Network Ice\BlackIce
    • HKLM\SOFTWARE\McAfee.com\Personal Firewall
    • HKLM\SOFTWARE\ComputerAssociates\eTrust EZ Armor
    • HKLM\SOFTWARE\RedCannon\Fireball
    • HKLM\SOFTWARE\Kerio\Personal Firewall 4
    • HKLM\SOFTWARE\KasperskyLab\InstalledProducts\Kaspersky Anti-Hacker
    • HKLM\SOFTWARE\Tiny Software\Tiny Firewall
    • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Look n Stop 2.05p2
    • HKCU\SOFTWARE\Soft4Ever
    • HKLM\SOFTWARE\Norman Data Defense Systems
    • HKLM\SOFTWARE\Agnitum\Outpost Firewall
    • HKLM\SOFTWARE\Panda Software\Firewall
    • HKLM\SOFTWARE\InfoTeCS\TermiNET
  • connotify.dll cumple la función de canal mínimo de reporte
    • Se registra mediante la API de Windows AddConnectNotify() y es llamado cada vez que aparece una nueva conexión de red basada en RAS
    • Descifra cadenas ofuscadas para obtener el named pipe \\.\pipe\p577, se conecta al pipe local, registra los nombres de conexión remota y local, y luego termina
    • No es un módulo ejecutable independiente y requiere registro por parte del proceso host
    • Nombre de archivo svcmgmt.dll
    • Tamaño 45056 bytes
    • MD5 410eddfc19de44249897986ecc8ac449
    • SHA1 675cb83cec5f25ebbe8d9f90dea3d836fcb1c234
    • SHA256 8fcb4d3d4df61719ee3da98241393779290e0efcd88a49e363e2a2dfbc04dae9
    • Hora de enlace 2005-06-06 18:42:45 UTC
    • Tipo PE32 DLL (i386, 4 sections)

Estructura del driver y método de parcheo en memoria

  • fast16.sys es el componente más potente del framework; está configurado como driver de sistema de archivos de inicio de arranque, por lo que se carga en una etapa muy temprana junto con el driver de disco
  • La configuración es Start=0, Type=2, grupo de clase SCSI, y se inserta por encima de NTFS, FAT y MRxSMB
  • En la entrada inicial, establece el valor EnablePrefetcher bajo Session Manager\PrefetchParameters en 0, haciendo que las solicitudes posteriores de páginas de código pasen por toda la pila del sistema de archivos
  • Mediante cifrado simple de cadenas con XOR y un escaneo de ntoskrnl.exe, resuelve dinámicamente la API del kernel y expone \Device\fast16, \??\fast16 y un DeviceType personalizado 0xA57C
  • Con IoRegisterFsRegistrationChange, adjunta un worker device object sobre dispositivos de sistema de archivos activos y nuevos, e intercepta IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_CLOSE, IRP_MJ_QUERY_INFORMATION, IRP_MJ_FILE_SYSTEM_CONTROL y las rutas Fast I/O relacionadas
  • Aunque se carga en el momento del arranque, el verdadero motor de inyección de código a nivel kernel no se activa hasta después de que explorer.exe se haya abierto
  • El objetivo del parche debe cumplir dos condiciones al mismo tiempo
    • El nombre del archivo termina en .EXE
    • Justo después del último encabezado de sección PE hay una cadena ASCII imprimible que comienza con Intel
  • Esta condición apunta a ejecutables compilados con el compilador Intel C/C++, lo que muestra que conocían el toolchain del software objetivo
  • A los archivos que cumplen la condición se les aplica una modificación del encabezado PE en memoria; se inyectan de nuevo las dos secciones .xdata y .pdata, y se rellenan bytes de la sección de código original para mantener una copia limpia del código
  • Los valores de identificación de fast16.sys son los siguientes
    • Nombre de archivo fast16.sys
    • Tamaño 44,580 bytes
    • MD5 0ff6abe0252d4f37a196a1231fae5f26
    • SHA1 92e9dcaf7249110047ef121b7586c81d4b8cb4e5
    • SHA256 07c69fc33271cf5a2ce03ac1fed7a3b16357aec093c5bf9ef61fbfa4348d0529
    • Tipo PE32 executable for MS Windows 5.00 (native), Intel i386, 5 sections
    • Hora de enlace 2005-07-19 15:15:41 UTC

Motor de parcheo basado en reglas y características del objetivo

  • El motor de parcheo es un escáner mínimo basado en estados compuesto por 101 reglas; cuando el archivo se lee desde disco, cambia silenciosamente el código ejecutable en memoria mediante lógica de coincidencia de patrones y sustitución
  • Para mantener el rendimiento, usa un dispatch array de 256 bytes para descartar rápidamente algunos bytes iniciales, permite wildcards dentro de los patrones y, en algunas reglas, establece y comprueba banderas de estado para ejecutar secuencias de modificación de varias etapas
  • La mayoría de los patrones de parcheo corresponden a secuencias de instrucciones comunes en código x86 para secuestrar o afectar el flujo de ejecución, pero uno está compuesto por un bloque mucho mayor de instrucciones FPU
  • Este bloque FPU es código dedicado a aritmética de precisión y al escalado de valores en arreglos internos, y muestra una naturaleza distinta a la de una inyección maliciosa común
  • Los investigadores convirtieron las reglas de parcheo en patrones hexadecimales de firmas YARA y las aplicaron a un corpus de software de la misma época; hubo menos de 10 archivos con dos o más patrones coincidentes, una cantidad muy reducida
  • Los archivos que coincidieron tenían en común que eran herramientas de cálculo especializadas en áreas como ingeniería civil, física y simulación de procesos físicos
  • El parche FPU escala los valores pasados a tres arreglos internos para alterar sutilmente los cálculos, lo que muestra que el objetivo no era el acceso no autorizado ni la propagación general, sino la manipulación de resultados numéricos
  • Como no se pudieron identificar por completo tanto los binarios objetivo exactos como las cargas de trabajo, el significado de los arreglos no quedó totalmente determinado
  • Si los cálculos se verifican en un sistema aparte, este sabotaje podría fallar; pero si el mismo driver se despliega en varios sistemas que comparten la misma red y entorno de seguridad, también se reduce la posibilidad de discrepancias en verificaciones independientes
  • En el apéndice se incluyen tal cual algunos patrones extraídos del motor de parcheo
    • 48 89 84 24 9C 00 00 00 4B 0F 8F 79 FF FF FF 00
    • D8 E1 D9 5D FC D9 04 00
    • 55 8B EC 83 EC 14 53 56 57 8B 3D ?? ?? ?? ?? 8B 0D 00
    • 8D 1D ?? ?? ?? ?? 52 8D 05 ?? ?? ?? ?? 51 8D 15 ?? ?? ?? ?? 8D 0D ?? ?? ?? ?? 53 50 52 51 56 57 E8 ?? ?? ?? ?? 83 C4 38 EB 0E 83 EC 04 00
    • B9 01 00 00 00 C1 E7 02 8B BF ?? ?? ?? ?? 8B D7 85 FF 8B 55 30 8B 45 30 D8 C9 8B 75 2C 00 9A 8B 00 00 00 1B 00 90 0F 94 C3 0B D8 33 D2 83 3D 00

Candidatos a objetivos del parche

  • Los objetivos con la coincidencia más fuerte en los resultados de pattern matching fueron LS-DYNA 970, PKPM y MOHID
  • LS-DYNA 970 es un software de simulación de ingeniería que analiza el comportamiento de materiales y estructuras en condiciones extremas, y se usa para estudiar choques automotrices, explosiones, impactos, conformado de metales y procesos de manufactura; se ha utilizado en los sectores automotriz, aeroespacial, de defensa e investigación militar, manufactura y ciencia de materiales
    • Se ha desarrollado desde 1976
    • MD5 1d2f32c57ae2f2013f513d342925e972
    • SHA1 2fa28ef1c6744bdc2021abd4048eefc777dccf22
    • SHA256 5966513a12a5601b262c4ee4d3e32091feb05b666951d06431c30a8cece83010
    • Tamaño del archivo 5,225,591 bytes
    • Link time 2003-10-24 16:34:57 UTC
    • Tipo de archivo PE32 executable for MS Windows 4.00 (console), Intel i386, 7 sections
  • PKPM es una suite de CAD de ingeniería estructural ampliamente usada en China, compuesta por varios módulos ejecutables que cubren todo el ciclo de diseño de estructuras de edificios
    • SATWE es el motor principal encargado del análisis estructural tridimensional de losas, vigas, columnas, muros y marcos en general
    • Identificadores del módulo de diseño de cortante en concreto
      • MD5 af4461a149bfd2ba566f2abefe7dcde4
      • SHA1 586edef41c3b3fba87bf0f0346c7e402f86fc11e
      • SHA256 09ca719e06a526f70aadf34fb66b136ed20f923776e6b33a33a9059ef674da22
      • Tamaño del archivo 7716864 bytes
      • Tipo de archivo PE32 executable for MS Windows 4.00 (GUI), Intel i386, 6 sections
      • Link time 2011-08-26 10:58:17 UTC
    • Identificadores del módulo Building Structure CAD
      • MD5 49a8934ccd34e2aaae6ea1e6a6313ffe
      • SHA1 3ce5b358c2ddd116ac9582efbb38354809999cb5
      • SHA256 8b018452fdd64c346af4d97da420681e2e0b55b8c9ce2b8de75e330993b759a0
      • Tamaño 11849728 bytes
      • Link time 2005-12-01 08:35:46 UTC
      • MD5 e0c10106626711f287ff91c0d6314407
      • SHA1 650fc6b3e4f62ecdc1ec5728f36bb46ba0f74d05
      • SHA256 06361562cc53d759fb5a4c2b7aac348e4d23fe59be3b2871b14678365283ca47
      • Tamaño 16355328 bytes
      • Link time 2012-07-07 08:47:11 UTC
    • Identificadores del motor de análisis estructural SATWE
      • MD5 2717b58246237b35d44ef2e49712d3a2
      • SHA1 d475ace24b9aedebf431efc68f9db32d5ae761bd
      • SHA256 bd04715c5c43c862c38a4ad6c2167ad082a352881e04a35117af9bbfad8e5613
      • Tamaño 9908224 bytes
      • Link time 2011-01-12 06:37:39 UTC
      • MD5 daea40562458fc7ae1adb812137d3d05
      • SHA1 1ce1111702b765f5c4d09315ff1f0d914f7e5c70
      • SHA256 da2b170994031477091be89c8835ff9db1a5304f3f2f25344654f44d0430ced1
      • Tamaño 8454144 bytes
      • Link time 2012-11-29 03:10:12 UTC
      • MD5 2740a703859cbd8b43425d4a2cacb5ec
      • SHA1 ca665b59bc590292f94c23e04fa458f90d7b20c9
      • SHA256 aeaa389453f04a9e79ff6c8b7b66db7b65d4aaffc6cac0bd7957257a30468e33
      • Tamaño 16568320 bytes
      • Link time 2014-12-30 03:23:43 UTC
      • MD5 ebff5b7d4c5becb8715009df596c5a91
      • SHA1 829f8be65dfe159d2b0dc7ee7a61a017acb54b7b
      • SHA256 37414d9ca87a132ec5081f3e7590d04498237746f9a7479c6b443accee17a062
      • Tamaño 8089600 bytes
      • Link time 2009-04-22 01:46:46 UTC
      • MD5 cb66a4d52a30bfcd980fe50e7e3f73f0
      • SHA1 e6018cd482c012de8b69c64dc3165337bc121b86
      • SHA256 66fe485f29a6405265756aaf7f822b9ceb56e108afabd414ee222ee9657dd7e2
      • Tamaño 9219072 bytes
      • Link time N/A
    • Identificadores de archivos CAD adicionales de PKPM
      • MD5 075b4aa105e728f2b659723e3f36c72c
      • SHA1 145ef372c3e9c352eaaa53bb0893749163e49892
      • SHA256 c11a210cb98095422d0d33cbd4e9ecc86b95024f956ede812e17c97e79591cfa
      • Tamaño 6852608 bytes
      • Link time 2012-06-18 10:01:54 UTC
      • MD5 cf859f164870d113608a843e4a9600ab
      • SHA1 952ed694b60c34ba12df9d392269eae3a4f11be4
      • SHA256 7e00030a35504de5c0d16020aa40cbaf5d36561e0716feb8f73235579a7b0909
      • Tamaño 8392704 bytes
      • Link time 2012-11-29 03:10:12 UTC
  • MOHID es un sistema de modelado hidrológico de código abierto desarrollado por MARETEC del Instituto Superior Técnico de Lisboa, Portugal, que abarca hidrodinámica marina y costera, simulación de calidad del agua, transporte de sedimentos, modelado de derrames de petróleo y seguimiento lagrangiano de partículas
    • Señalaron que incluso en la actualidad no han podido identificar de forma concluyente el efecto pretendido del ataque
    • MD5 f4dbbb78979c1ee8a1523c77065e18a5
    • SHA1 9e089a733fb2740c0e408b2a25d8f5a451584cf6
    • SHA256 e775049d1ecf68dee870f1a5c36b2f3542d1182782eb497b8ccfd2309c400b3a
    • Tamaño del archivo 5443584 bytes
    • Tipo de archivo PE32 executable for MS Windows 4.00 (console), Intel i386, 3 sections
    • Link time 2002-10-18 09:29:54 UTC
  • LS-DYNA ha sido citado en reportes públicos sobre las sospechas de violación por parte de Irán de la Sección T del JCPOA, junto con investigaciones de modelado computacional relacionado con el desarrollo de armas nucleares

Reglas de detección e indicadores de compromiso

  • Indicadores de compromiso

    • Los tres archivos identificados son fast16.sys, connotify.dll y svcmgmt.exe
    • fast16.sys: MD5 0ff6abe0252d4f37a196a1231fae5f26, SHA1 92e9dcaf7249110047ef121b7586c81d4b8cb4e5, SHA256 07c69fc33271cf5a2ce03ac1fed7a3b16357aec093c5bf9ef61fbfa4348d0529
    • connotify.dll: MD5 410eddfc19de44249897986ecc8ac449, SHA1 675cb83cec5f25ebbe8d9f90dea3d836fcb1c234, SHA256 8fcb4d3d4df61719ee3da98241393779290e0efcd88a49e363e2a2dfbc04dae9
    • svcmgmt.exe: MD5 dbe51eabebf9d4ef9581ef99844a2944, SHA1 de584703c78a60a56028f9834086facd1401b355, SHA256 9a10e1faa86a5d39417cae44da5adf38824dfb9a16432e34df766aa1dc9e3525

  • apt_fast16_carrier

    • Fue diseñada para detectar el carrier, el payload Lua y variantes en texto plano, y su hash de referencia es 9a10e1faa86a5d39417cae44da5adf38824dfb9a16432e34df766aa1dc9e3525
    • Usa el magic de bytecode de Lua 1B 4C 75 61, y las cadenas build_wormlet_table, unpropagate, scm_wormlet_install, install_implant, start_worm, ok_to_propagate
    • También incluye como condiciones múltiples claves de registro de productos de seguridad como Symantec, Sygate Personal Firewall, Zone Labs\TrueVector, Kaspersky Anti-Hacker
    • También detecta patrones de bytes de cadenas cifradas, dos constantes criptográficas, código para descifrar la longitud del contenedor de almacenamiento y una firma de registro de almacenamiento que incluye la cadena file
    • La condición se cumple para archivos menores de 10 MB con encabezado MZ cuando se satisfacen 3 elementos de $s*, 12 de $rk*, cualquier elemento de $e*, la proximidad de 2 constantes criptográficas y uno entre $code1 o $stor1, o bien cuando se cumplen el magic de Lua y 7 elementos de $s*

  • apt_fast16_driver

    • Fue diseñada para detectar el driver o archivos de proyecto relacionados, y su hash de referencia es 07c69fc33271cf5a2ce03ac1fed7a3b16357aec093c5bf9ef61fbfa4348d0529
    • Usa múltiples cadenas identificadoras de archivos fuente como @(#)foo.c :, @(#)par.h :, @(#)pae.h :, @(#)ree.c :
    • Incluye patrones como \\Device\\fast16, \\??\\fast16, C:\\buildy\\, driver\\fd\\i386\\fast16.pdb, push 0A57Ch ; DeviceType
    • La firma también incorpora patrones de API que hacen push en forma XOR de ExAllocatePool, ExAllocatePoolWithTag, ExFreePool, ExFreePoolWithTag
    • La condición se cumple en archivos menores de 10 MB con encabezado MZ cuando además se satisfacen 2 rutas PDB, C:\\buildy\\ y 1 identificador de fuente, #devtype == 3, pe.machine == pe.MACHINE_I386, pe.subsystem == pe.SUBSYSTEM_NATIVE, cualquiera de api*, o uno entre 2 dev*; o cuando se cumplen 6 identificadores de fuente

  • clean_fast16_patchtarget

    • Detecta el software objetivo del parche, está marcado como most probably clean y su hash de referencia es 8fcb4d3d4df61719ee3da98241393779290e0efcd88a49e363e2a2dfbc04dae9
    • Usa múltiples patrones de bytes consecutivos desde $el0 hasta $el99
    • La condición es: archivo menor de 20 MB, encabezado MZ y 2 o más coincidencias entre las firmas definidas

  • apt_fast16_patch

    • Detecta el código de parche en sí, y puede estar presente en archivos parcheados estáticamente o en volcados de memoria
    • Su hash de referencia es 0ff6abe0252d4f37a196a1231fae5f26
    • Define tres patrones de bytes: $p1, $p2, $p3
    • La condición es any of them, por lo que se detecta aunque coincida solo uno de los tres patrones

Linaje e implicaciones históricas

  • La cadena @(#)par.h $Revision: 1.3 $ dentro del binario ofrece una pista para inferir el linaje de este framework
  • El prefijo @(#) remite a la convención de gestión de código fuente de la familia SCCS/RCS del Unix de las décadas de 1970 y 1980, y este tipo de rastro es raro en drivers del kernel de Windows de mediados de los 2000
  • Estos artefactos parecen más cercanos a la huella de un ingeniero veterano familiarizado con la cultura y el toolchain de entornos Unix antiguos de alta seguridad que al perfil típico de un desarrollador exclusivamente enfocado en Windows
  • svcmgmt.exe fue subido a VirusTotal hace casi 10 años, pero incluso hoy su tasa de detección sigue siendo muy baja, y solo un motor lo clasifica como malware genérico con confianza limitada
  • En combinación con las firmas de ShadowBrokers de Territorial Dispute, fast16 obliga a reconsiderar el momento de desarrollo de un grave ciber-sabotaje de nivel estatal y altamente sigiloso
  • fast16 muestra, antes que familias más conocidas, una arquitectura coherente que combina motores de scripting embebidos, targeting estrecho basado en compilador y parches a nivel kernel
  • Durante mucho tiempo casi no hubo análisis públicos, campañas con nombre ni vínculos con incidentes emblemáticos, y las marcas legibles que quedaron adentro también fueron mínimas y contenidas, como *** Nothing to see here – carry on***
  • Se posiciona como un punto de conexión dentro de la evolución APT que lleva a posteriores toolkits basados en Lua y LuaJIT

Lecturas relacionadas

1 comentarios

 
GN⁺ 2 일 전
Comentarios de Hacker News

  • Esta parte me pareció especialmente interesante
    La comparación de que ver la notación de SCCS/RCS en código del kernel de Windows de 2005 era como encontrarte un teléfono de disco en una oficina hoy en día me pareció bastante convincente
    Incluso en el laboratorio de astrofísica donde trabajé en 2006 seguían usando svn, y en el codebase había mucho Fortran con rastros de sistemas de los 70 y 80
    Aun así funcionaba bien gracias a compiladores modernos de optimización, y también fue sorprendentemente fluida la migración de Vax a Linux en los 90
    Esto me recordó una charla antigua, do over or make due, cuya idea era más o menos que reescribir por completo un codebase grande que básicamente funciona no vale la pena si con herramientas modernas todavía puedes mantenerlo unido y hacerlo servir

    • Yo trabajé en una empresa que todavía usaba SCM basado en RCS hasta alrededor de 2012, pero era un sistema medio improvisado que forzaba RCS encima de un servidor de archivos compartido
      Se llamaba MKS, y manejaba un árbol de revisiones específico como un "project file"; incluso la versión rehecha en Java EE se sentía como una reliquia de los 90
      En la cabecera de los archivos iban etiquetas como $Revision: 1.3 $ y changelogs, pero en muchos archivos nuevos ni siquiera ponían la etiqueta, así que no se sustituía nada y la consistencia era un desastre
      La familia de dispositivos objetivo había empezado a mediados de los 90, pero en ese momento casi nada del código en sí tenía realmente más de 5 años
      Aunque solo había unas decenas de ingenieros, los conflictos de commit eran frecuentes y el árbol completo se rompía seguido
      Por diversión escribí un script para leer todo el historial e importarlo a git, y con solo retroceder unos cuantos años los registros ya eran un caos total
      No sé por qué siguieron usando eso hasta entonces, pero en empresas de hardware era más común de lo que uno pensaría que el control de código fuente se viera poco más o menos como una "carpeta compartida remota", así que supongo que la gestión de versiones del software no era prioridad
    • Si en 2026 estás usando R, es muy probable que en alguna parte casi seguro estés llamando código compilado desde Fortran de los 70 u 80
      En el mundo del cómputo numérico, ese linaje todavía sigue siendo la base
    • Antes yo dudaba un poco de la teoría de que Stuxnet tuviera respaldo estatal, pero viendo notas como esta entendí por qué surgió esa suposición
      Sí había lugares usando RCS todavía en los 2000, y como herramienta en sí incluso tenía algunas ventajas frente a SVN o CVS
    • Entonces me pregunto si eso significa que esas agencias de tres letras podían reclutar gente con experiencia en cada dominio según el tipo de malware
      Por ejemplo, uno se imagina que fast16 pudo haberlo escrito alguien que originalmente hacía software de cálculo científico, y Stunex alguien que trabajaba en Siemens
    • El refactoring no es una cura milagrosa para todo
      Si las causas que hicieron que el código necesitara refactorización al principio siguen ahí, al final va a volver al mismo estado
      Muchas veces esas causas están clavadas muy hondo, incluso en capas psicológicas como hábitos del desarrollador, creencias o traumas profesionales
      Si además se cruza la ley de Conway, el equipo termina construyendo software que inevitablemente se parece a la estructura de la organización más grande, y si la organización no cambia, el resultado de la refactorización también suele repetirse
      La excepción suele ser cuando te toca un codebase de otro equipo o de un predecesor y ahí sí puedes replantear la estructura
      Pero cuando las mismas personas anuncian que van a refactorizar su propio código, muchas veces lo único que logran es fabricar otra ratonera más cómoda para ellas mismas
      Mejorar iterativamente algo que nació de tu propia manera de pensar está bien, pero para bajarte del carrusel hay que anotar las causas de una mala arquitectura y examinarse con frialdad
      Eso de que "si eres cuidadoso y disciplinado puedes implementar bien incluso un diseño algo malo", como les gusta creer a muchos desarrolladores, por lo general no es cierto
      Al final la raíz es el diseño: o aceptas el árbol que creció de ahí o lo talas; solo podarlo tiene límites

  • Este artículo da bastante escalofrío
    El simple hecho de que este malware haya permanecido 20 años por debajo del radar ya da muy mala espina

  • Aquí está el enlace de descarga para quien tenga curiosidad
    https://bazaar.abuse.ch/sample/9a10e1faa86a5d39417cae44da5ad...
    Yo probablemente empezaría armando una VM de Windows XP

    • Me pregunto si ya ha aparecido alguna vez el archivo de servicio de Windows
      Eso solo parece el loader

  • IEEE-754 solo exige redondeo correcto para +-*/ y sqrt
    Las funciones trascendentales como sin/cos/exp/log/pow permiten diferencias de unas cuantas ULP al final, y así funcionan en la práctica glibc, musl, MSVC e Intel SVML
    Los PID usan operaciones básicas, así que sufren menos por diferencias de libm, pero el control vectorial de motores o la linearización de sensores tocan este tipo de funciones en cada ciclo, así que pequeñas discrepancias se van acumulando
    Por eso, incluso sin ningún diff en el código fuente, solo cambiar la libm enlazada puede hacer que el comportamiento en campo empiece a derivar
    Estas diferencias realmente aparecen en cosas como la reducción de argumento de Payne-Hanek o en los peores límites del table-maker's dilemma
    Supongo que por eso las guías para sistemas críticos de seguridad no dicen simplemente "cumple con IEEE-754", sino que fijan un build específico de libm

  • De verdad es un hallazgo impresionante
    Tengo muchísima curiosidad por saber exactamente qué objetivos tenían estas reglas y cómo alteraban los resultados
    Tal vez estaban diseñadas para introducir diferencias solo bajo condiciones de simulación muy específicas, como en un reactor nuclear

    • Me puse a investigar un poco cómo podría manipularse software como LS-DYNA
      Por ejemplo, la ecuación EOS_JWL del manual público [1] es una de las fórmulas que implementa LS-DYNA, y parece que, usada junto con otras ecuaciones, podría servir para calcular cuánto tarda el detonador de una ojiva de misil en hacer explotar la carga principal y generar una onda de presión concreta a 20 m de distancia
      Si inviertes ese resultado, también podrías estimar el tiempo de espoleta necesario
      Las ecuaciones y parámetros que entran en LS-DYNA vienen de investigaciones científicas como [2], que es un estudio del gobierno de EE. UU. de los años 80 sobre explosivos de alta potencia
      Ahí también se incluyen experimentos para medir cómo el explosivo interactúa por fricción con distintos materiales que lo recubren
      Como las ecuaciones para modelar explosivos ya están listas, bastaría con tocar un poco esas fórmulas y meter ruido de ±20% al coeficiente de fricción para que un científico o ingeniero sospechara primero de un problema de calidad en la fabricación del acero antes que de una manipulación del software
      Una analogía moderna sería imaginar a algún país adversario usando una copia pirateada de Ansys Autodyn 2026 R1 que un grupo chino de cracking publicó en un foro chino y que descargaron de unos pocos seeders detrás de un ISP ruso
      Y luego, cuando los resultados experimentales y los calculados empiecen a no coincidir, recién entonces podrían sospechar que la copia fue alterada deliberadamente
      Aun así, hoy quizá le resulte más fácil a ese país adversario sacar una copia legítima de una red comprometida de alguna universidad cualquiera o de una consultora aeroespacial o de defensa
      También sería ingenuo asumir que un país adversario en 2026 no podría desarrollar el software desde cero
      Incluso apoyándose en cálculos manuales o en experimentación podría llegar al resultado que busca
      Al final, para validar la calidad de fabricación, de todos modos hacen falta instrumentos y capacidad experimental
      El software de simulación sirve sobre todo para reducir el número de maquetas y de pruebas físicas, y así ahorrar tiempo y dinero
      Por ejemplo, correr 1000 veces un escenario como el de [3], donde un proyectil impacta una placa de blindaje, es barato; repetir eso en el mundo real cuesta mucho más y toma mucho más tiempo
      [1] https://ftp.lstc.com/anonymous/outgoing/jday/manuals/LS-DYNA...
      [2] https://www.osti.gov/servlets/purl/6530310
      [3] https://www.youtube.com/watch?v=_dv2PecKUBM

  • Cuando la gente vea que las cosas que publico llevan datos de revisión de RCS, ojalá al menos se detengan un segundo

  • El libro que leí hace poco es Sandworm: A New Era of Cyberwar and the Hunt for the Kremlin's Most Dangerous Hackers, de Andy Greenberg
    Me gustó bastante, y como siguen saliendo nuevos datos, hasta creo que podría ameritar una secuela

  • Viendo cómo Guix y la computación reproducible se pueden portar incluso a PowerPC o a máquinas legacy, siento que a gobiernos o instituciones tipo 1984, y a algunos grupos de Medio Oriente, eso realmente les debe disgustar mucho
    Mientras más heterogéneo sea el entorno, mejor

  • La cifra clave es el gusano
    No lo detectas revisando otra computadora, porque para empezar ni siquiera existe una segunda computadora limpia

  • Es un hallazgo interesante, pero el comentario sobre control de código fuente me suena un poco desfasado
    Incluso en esa época todavía debían quedar cosas parecidas a SCCS, y por un momento hasta me confundí pensando si CVS tenía un estilo similar

    • Creo que ese comentario probablemente se refería a que eso era raro dentro del software de Windows
      Sugiere que los desarrolladores originalmente también trabajaban del lado de UNIX, porque SCCS/RCS eran comunes allá