Fast16: sabotagem de software de alta precisão 5 anos antes do Stuxnet

 (sentinelone.com)
2 pontos por GN⁺ 2 일 전 | 1 comentários | Compartilhar no WhatsApp
  • Framework de sabotagem não documentado criado em 2005, projetado para aplicar patches no código em memória de softwares de cálculo selecionados e distorcer resultados numéricos
  • svcmgmt.exe parece externamente um wrapper de serviço, mas internamente contém uma máquina virtual Lua 5.0, bytecode criptografado, DLLs auxiliares e o driver fast16.sys, executando separadamente payloads por tarefa
  • fast16.sys é um driver de sistema de arquivos iniciado no boot que é carregado em estágio muito inicial e então seleciona .EXE compilados com o compilador Intel C/C++, realizando patches de memória em nível de kernel
  • O mecanismo de patch opera com 101 regras e, em especial, usa blocos de instruções FPU para alterar o escalonamento de valores em arrays internos, deixando indícios de ter mirado ferramentas de cálculo especializadas como engenharia civil, física e simulação de processos
  • Combinado com o marcador fast16 vazado pelo ShadowBrokers, isso revela que sabotagem industrial de precisão anterior ao Stuxnet já existia em uma forma que combinava scripting embutido, alvo altamente restrito e patches em kernel

Visão geral e indícios de identificação

  • fast16 é um framework de ciber-sabotagem não documentado com componentes centrais de 2005, no qual fast16.sys mira seletivamente softwares de cálculo de alta precisão, aplicando patches no código em memória e distorcendo resultados de cálculo
  • svcmgmt.exe parece externamente um wrapper de serviço comum da era Windows 2000/XP, mas internamente contém uma máquina virtual Lua 5.0 e um contêiner de bytecode criptografado que é extraído pelo ponto de entrada do serviço
  • No processo de rastreamento de malware baseado em Lua, os bytes mágicos de bytecode 1B 4C 75 61, o byte de versão, LUA_PATH e uma API C característica serviram como pistas, e nesse fluxo svcmgmt.exe foi identificado
  • A string C:\buildy\driver\fd\i386\fast16.pdb dentro de svcmgmt.exe serve como pista forense que liga o executável de serviço ao projeto do driver de kernel
  • O mesmo nome fast16 também aparece em drv_list.txt do vazamento de 2017 do ShadowBrokers, conectando a string PDB de svcmgmt.exe e o driver de sabotagem de precisão em uma mesma linha de evidência
  • A assinatura de evasão do lado do ShadowBrokers inclui a frase fast16 *** Nothing to see here – carry on***

Estrutura do carrier e forma de execução

  • svcmgmt.exe foi projetado como um carrier adaptável que muda de comportamento conforme os argumentos de linha de comando
    • Sem argumento: executa como serviço do Windows
    • -p: define InstallFlag = 1 e executa como serviço
    • -i: define InstallFlag = 1 e executa código Lua
    • -r: executa código Lua sem flag de instalação
    • Qualquer outro <filename>: opera em modo Wrapper/Proxy, criando dois processos-filho com o comando original e com o argumento -r anexado
  • O armazenamento interno contém bytecode Lua criptografado, DLLs auxiliares e o driver fast16.sys
  • O ambiente Lua vai além do estado padrão e oferece o módulo wstring, a função de criptografia simétrica embutida b e módulos de binding para APIs do Windows NT de sistema de arquivos, registro, controle de serviços e rede
  • O binário carrier externo é mantido relativamente estável, enquanto payloads por tarefa são separados em forma criptografada para poderem ser reutilizados conforme o ambiente e os objetivos operacionais
  • Os identificadores de svcmgmt.exe são os seguintes
    • nome do arquivo svcmgmt.exe
    • tamanho 315,392 bytes
    • MD5 dbe51eabebf9d4ef9581ef99844a2944
    • SHA1 de584703c78a60a56028f9834086facd1401b355
    • SHA256 9a10e1faa86a5d39417cae44da5adf38824dfb9a16432e34df766aa1dc9e3525
    • tipo PE32 executable for MS Windows 4.00 (console), Intel i386
    • link time 2005-08-30 18:15:06 UTC

Estrutura de propagação wormlet e evasão

  • svcmgmt.exe funciona como um carrier no estilo munição cluster capaz de carregar vários wormlets, e a amostra confirmada contém apenas um SCM wormlet
  • O fluxo de execução segue por preparação de configuração, conversão para wide string, elevação de privilégio, instalação e inicialização do serviço SvcMgmt, implantação condicional de fast16.sys, liberação do wormlet, atraso inicial e execução repetida até um limite de falhas ou condição externa de encerramento
  • O SCM wormlet mira ambientes Windows 2000/XP e encontra servidores de rede usando compartilhamentos de arquivos com senhas de administrador fracas ou padrão, copia o payload e então inicia um serviço remoto
  • A propagação não depende de um protocolo de rede customizado, mas de funções padrão de administração do Windows como a API de controle de serviços e a API de compartilhamento de arquivos
  • Antes da instalação, ok_to_install() chama ok_to_propagate() para verificar o ambiente e, sem forçamento manual, determina a viabilidade de propagação pela presença de chaves de registro de determinados produtos de segurança
  • Se qualquer uma das chaves de registro abaixo existir, a instalação é interrompida para evitar implantação em ambientes de monitoramento
    • 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 assume o papel de canal mínimo de reporte
    • É registrado pela API do Windows AddConnectNotify() e chamado sempre que uma nova conexão de rede baseada em RAS é criada
    • Decodifica uma string ofuscada para obter o named pipe \\.\pipe\p577, conecta-se ao pipe local, registra os nomes de conexão remota e local e então encerra
    • Não é um módulo executável independente e requer registro pelo processo hospedeiro
    • nome do arquivo svcmgmt.dll
    • tamanho 45056 bytes
    • MD5 410eddfc19de44249897986ecc8ac449
    • SHA1 675cb83cec5f25ebbe8d9f90dea3d836fcb1c234
    • SHA256 8fcb4d3d4df61719ee3da98241393779290e0efcd88a49e363e2a2dfbc04dae9
    • link time 2005-06-06 18:42:45 UTC
    • tipo PE32 DLL (i386, 4 sections)

Estrutura do driver e método de patch em memória

  • fast16.sys é o componente mais poderoso do framework e foi configurado como um driver de sistema de arquivos de inicialização do boot, sendo carregado em um estágio muito inicial junto com o driver de disco
  • A configuração é Start=0, Type=2, grupo de classe SCSI, e ele se insere acima de NTFS, FAT e MRxSMB
  • Na entrada inicial, define o valor EnablePrefetcher em Session Manager\PrefetchParameters como 0, fazendo com que as solicitações posteriores de páginas de código passem por toda a pilha do sistema de arquivos
  • Usa cifra simples de strings por XOR e varredura de ntoskrnl.exe para resolver dinamicamente APIs do kernel, e expõe \Device\fast16, \??\fast16 e o DeviceType personalizado 0xA57C
  • Com IoRegisterFsRegistrationChange, anexa um worker device object sobre dispositivos de sistema de arquivos ativos e novos, e intercepta IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_CLOSE, IRP_MJ_QUERY_INFORMATION, IRP_MJ_FILE_SYSTEM_CONTROL e os caminhos Fast I/O relacionados
  • Embora seja carregado no momento do boot, o verdadeiro motor de injeção de código em nível de kernel só é ativado depois que o explorer.exe é aberto
  • O alvo do patch deve satisfazer duas condições ao mesmo tempo
    • o nome do arquivo termina em .EXE
    • há uma string ASCII imprimível começando com Intel logo após o último cabeçalho de seção PE
  • Essas condições miram executáveis compilados com o compilador Intel C/C++, mostrando que os autores conheciam o toolchain do software-alvo
  • Em arquivos que atendem aos critérios, aplica-se uma modificação do cabeçalho PE em memória, com a injeção de duas novas seções, .xdata e .pdata, além do preenchimento dos bytes da seção de código original para manter uma cópia limpa do código
  • Os identificadores de fast16.sys são os seguintes
    • nome do arquivo fast16.sys
    • tamanho 44,580 bytes
    • MD5 0ff6abe0252d4f37a196a1231fae5f26
    • SHA1 92e9dcaf7249110047ef121b7586c81d4b8cb4e5
    • SHA256 07c69fc33271cf5a2ce03ac1fed7a3b16357aec093c5bf9ef61fbfa4348d0529
    • tipo PE32 executable for MS Windows 5.00 (native), Intel i386, 5 sections
    • horário de linkedição 2005-07-19 15:15:41 UTC

Motor de patch baseado em regras e características do alvo

  • O motor de patch é um scanner mínimo baseado em estados, composto por 101 regras, que altera silenciosamente em memória o código executável com lógica de correspondência de padrões e substituição quando o arquivo é lido do disco
  • Para manter o desempenho, ele usa um dispatch array de 256 bytes para filtrar rapidamente apenas alguns bytes iniciais, permite wildcard dentro dos padrões e, em algumas regras, define e verifica flags de estado para executar sequências de modificação em múltiplas etapas
  • A maior parte dos padrões de patch corresponde a sequências comuns de instruções em código x86 que sequestram ou afetam o fluxo de execução, mas um deles é composto por um bloco muito maior de instruções FPU
  • Esse bloco FPU é um código dedicado a aritmética de precisão e escalonamento de valores em arrays internos, mostrando uma natureza diferente da injeção maliciosa comum
  • Os pesquisadores converteram as regras de patch em padrões hexadecimais de assinaturas YARA e os aplicaram a um corpus de softwares da mesma época; houve menos de 10 arquivos com dois ou mais padrões correspondentes, um número extremamente baixo
  • Os arquivos atingidos tinham em comum o fato de serem ferramentas de cálculo especializadas em áreas como engenharia civil, física e simulação de processos físicos
  • O patch FPU altera sutilmente os cálculos ao escalonar valores passados para três arrays internos, mostrando que o objetivo não era acesso não autorizado nem propagação geral, mas sim a adulteração de resultados numéricos
  • Como não foi possível confirmar completamente tanto os binários exatos visados quanto as cargas de trabalho, o significado dos arrays não foi determinado por completo
  • Essa sabotagem pode falhar se os cálculos forem validados em um sistema separado, mas, se o mesmo driver for implantado em vários sistemas que compartilham a mesma rede e o mesmo ambiente de segurança, a probabilidade de divergência em verificações independentes também diminui
  • O apêndice inclui alguns padrões extraídos do motor de patch tal como estão
    • 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 alvo do patch

  • Os alvos com sobreposição mais forte nos resultados de correspondência de padrões foram LS-DYNA 970, PKPM e MOHID
  • LS-DYNA 970 é um software de simulação de engenharia que analisa o comportamento de materiais e estruturas em condições extremas, cobrindo colisões automotivas, explosões, impactos, conformação de metais e processos de manufatura, e era usado nos setores automotivo, aeroespacial, de defesa e pesquisa militar, além de manufatura e ciência dos materiais
    • É desenvolvido desde 1976
    • MD5 1d2f32c57ae2f2013f513d342925e972
    • SHA1 2fa28ef1c6744bdc2021abd4048eefc777dccf22
    • SHA256 5966513a12a5601b262c4ee4d3e32091feb05b666951d06431c30a8cece83010
    • Tamanho do arquivo 5,225,591 bytes
    • Link time 2003-10-24 16:34:57 UTC
    • Tipo de arquivo PE32 executable for MS Windows 4.00 (console), Intel i386, 7 sections
  • PKPM é uma suíte de CAD para engenharia estrutural amplamente usada na China, composta por vários módulos executáveis que cobrem todo o ciclo de projeto de estruturas de edifícios
    • O SATWE é o mecanismo central responsável pela análise estrutural 3D de lajes, vigas, pilares, paredes e estruturas em geral
    • Identificadores do módulo de projeto de cisalhamento em concreto
      • MD5 af4461a149bfd2ba566f2abefe7dcde4
      • SHA1 586edef41c3b3fba87bf0f0346c7e402f86fc11e
      • SHA256 09ca719e06a526f70aadf34fb66b136ed20f923776e6b33a33a9059ef674da22
      • Tamanho do arquivo 7716864 bytes
      • Tipo de arquivo PE32 executable for MS Windows 4.00 (GUI), Intel i386, 6 sections
      • Link time 2011-08-26 10:58:17 UTC
    • Identificadores do módulo Building Structure CAD
      • MD5 49a8934ccd34e2aaae6ea1e6a6313ffe
      • SHA1 3ce5b358c2ddd116ac9582efbb38354809999cb5
      • SHA256 8b018452fdd64c346af4d97da420681e2e0b55b8c9ce2b8de75e330993b759a0
      • Tamanho 11849728 bytes
      • Link time 2005-12-01 08:35:46 UTC
      • MD5 e0c10106626711f287ff91c0d6314407
      • SHA1 650fc6b3e4f62ecdc1ec5728f36bb46ba0f74d05
      • SHA256 06361562cc53d759fb5a4c2b7aac348e4d23fe59be3b2871b14678365283ca47
      • Tamanho 16355328 bytes
      • Link time 2012-07-07 08:47:11 UTC
    • Identificadores do mecanismo de análise estrutural SATWE
      • MD5 2717b58246237b35d44ef2e49712d3a2
      • SHA1 d475ace24b9aedebf431efc68f9db32d5ae761bd
      • SHA256 bd04715c5c43c862c38a4ad6c2167ad082a352881e04a35117af9bbfad8e5613
      • Tamanho 9908224 bytes
      • Link time 2011-01-12 06:37:39 UTC
      • MD5 daea40562458fc7ae1adb812137d3d05
      • SHA1 1ce1111702b765f5c4d09315ff1f0d914f7e5c70
      • SHA256 da2b170994031477091be89c8835ff9db1a5304f3f2f25344654f44d0430ced1
      • Tamanho 8454144 bytes
      • Link time 2012-11-29 03:10:12 UTC
      • MD5 2740a703859cbd8b43425d4a2cacb5ec
      • SHA1 ca665b59bc590292f94c23e04fa458f90d7b20c9
      • SHA256 aeaa389453f04a9e79ff6c8b7b66db7b65d4aaffc6cac0bd7957257a30468e33
      • Tamanho 16568320 bytes
      • Link time 2014-12-30 03:23:43 UTC
      • MD5 ebff5b7d4c5becb8715009df596c5a91
      • SHA1 829f8be65dfe159d2b0dc7ee7a61a017acb54b7b
      • SHA256 37414d9ca87a132ec5081f3e7590d04498237746f9a7479c6b443accee17a062
      • Tamanho 8089600 bytes
      • Link time 2009-04-22 01:46:46 UTC
      • MD5 cb66a4d52a30bfcd980fe50e7e3f73f0
      • SHA1 e6018cd482c012de8b69c64dc3165337bc121b86
      • SHA256 66fe485f29a6405265756aaf7f822b9ceb56e108afabd414ee222ee9657dd7e2
      • Tamanho 9219072 bytes
      • Link time N/A
    • Identificadores adicionais de arquivos PKPM CAD
      • MD5 075b4aa105e728f2b659723e3f36c72c
      • SHA1 145ef372c3e9c352eaaa53bb0893749163e49892
      • SHA256 c11a210cb98095422d0d33cbd4e9ecc86b95024f956ede812e17c97e79591cfa
      • Tamanho 6852608 bytes
      • Link time 2012-06-18 10:01:54 UTC
      • MD5 cf859f164870d113608a843e4a9600ab
      • SHA1 952ed694b60c34ba12df9d392269eae3a4f11be4
      • SHA256 7e00030a35504de5c0d16020aa40cbaf5d36561e0716feb8f73235579a7b0909
      • Tamanho 8392704 bytes
      • Link time 2012-11-29 03:10:12 UTC
  • MOHID é um sistema open source de modelagem de corpos d'água desenvolvido pela MARETEC do Instituto Superior Técnico, em Lisboa, Portugal, cobrindo hidrodinâmica marinha e costeira, simulação da qualidade da água, transporte de sedimentos, modelagem de derramamento de óleo e rastreamento lagrangiano de partículas
    • Foi informado que, mesmo no momento atual, ainda não foi possível identificar de forma conclusiva o efeito pretendido do ataque
    • MD5 f4dbbb78979c1ee8a1523c77065e18a5
    • SHA1 9e089a733fb2740c0e408b2a25d8f5a451584cf6
    • SHA256 e775049d1ecf68dee870f1a5c36b2f3542d1182782eb497b8ccfd2309c400b3a
    • Tamanho do arquivo 5443584 bytes
    • Tipo de arquivo PE32 executable for MS Windows 4.00 (console), Intel i386, 3 sections
    • Link time 2002-10-18 09:29:54 UTC
  • O LS-DYNA já foi citado em reportagens públicas sobre suspeitas de violação da Section T do JCPOA pelo Irã, junto com pesquisas de modelagem computacional relacionada ao desenvolvimento de armas nucleares

Regras de detecção e indicadores de comprometimento

  • Indicadores de comprometimento

    • Os três arquivos identificados são fast16.sys, connotify.dll e 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

    • Foi projetado para detectar o carrier, payloads em Lua e variantes em texto puro, e o hash de referência é 9a10e1faa86a5d39417cae44da5adf38824dfb9a16432e34df766aa1dc9e3525
    • Usa o magic bytecode de Lua 1B 4C 75 61 e as strings build_wormlet_table, unpropagate, scm_wormlet_install, install_implant, start_worm, ok_to_propagate
    • Também inclui como condição diversas chaves de registro de produtos de segurança, como Symantec, Sygate Personal Firewall, Zone Labs\TrueVector, Kaspersky Anti-Hacker
    • Também detecta padrões de bytes de strings criptografadas, duas constantes de cifra, código de descriptografia do comprimento do contêiner de armazenamento e uma assinatura de registro de armazenamento contendo a string file
    • A condição é satisfeita com cabeçalho MZ e arquivos abaixo de 10MB, quando atende a 3 itens de $s*, 12 itens de $rk*, qualquer item de $e*, a disposição próxima de duas constantes de cifra e um entre $code1 e $stor1, ou quando atende ao magic de Lua e a 7 itens de $s*

  • apt_fast16_driver

    • Foi projetado para detectar o driver ou arquivos de projeto relacionados, e o hash de referência é 07c69fc33271cf5a2ce03ac1fed7a3b16357aec093c5bf9ef61fbfa4348d0529
    • Usa várias strings de identificação de arquivos-fonte como @(#)foo.c :, @(#)par.h :, @(#)pae.h :, @(#)ree.c :
    • Inclui padrões como \\Device\\fast16, \\??\\fast16, C:\\buildy\\, driver\\fd\\i386\\fast16.pdb, push 0A57Ch ; DeviceType
    • A assinatura também inclui padrões de API que fazem push em forma de XOR de ExAllocatePool, ExAllocatePoolWithTag, ExFreePool, ExFreePoolWithTag
    • A condição é satisfeita em arquivos abaixo de 10MB com cabeçalho MZ quando atende a 2 caminhos PDB, C:\\buildy\\ e 1 identificador de fonte, #devtype == 3, pe.machine == pe.MACHINE_I386, pe.subsystem == pe.SUBSYSTEM_NATIVE, qualquer api* e um entre 2 dev*, ou quando atende a 6 identificadores de fonte

  • clean_fast16_patchtarget

    • Detecta o software alvo do patch, está marcado como most probably clean e o hash de referência é 8fcb4d3d4df61719ee3da98241393779290e0efcd88a49e363e2a2dfbc04dae9
    • Usa vários padrões de bytes que vão de $el0 até $el99
    • A condição é satisfeita em arquivos abaixo de 20MB, com cabeçalho MZ, quando há 2 ou mais correspondências entre as assinaturas definidas

  • apt_fast16_patch

    • Detecta o próprio código de patch e pode estar presente em arquivos estaticamente corrigidos ou em dumps de memória
    • O hash de referência é 0ff6abe0252d4f37a196a1231fae5f26
    • Define três padrões de bytes: $p1, $p2, $p3
    • A condição é any of them, ou seja, a detecção ocorre mesmo que apenas um dos três padrões corresponda

Linhagem e implicações históricas

  • A string @(#)par.h $Revision: 1.3 $ dentro do binário é uma pista que permite supor a linhagem desse framework
  • O prefixo @(#) remete à convenção de gestão de código-fonte da família SCCS/RCS do Unix dos anos 1970 e 1980, e esse tipo de vestígio é raro em drivers de kernel do Windows de meados dos anos 2000
  • Esses artefatos parecem mais próximos de marcas de engenheiros veteranos, acostumados à cultura e ao toolchain de ambientes Unix antigos e de alta segurança, do que de desenvolvedores típicos focados exclusivamente em Windows
  • svcmgmt.exe foi enviado ao VirusTotal há quase 10 anos, mas ainda hoje tem taxa de detecção muito baixa, e apenas um mecanismo o classifica como malware genérico com confiança limitada
  • Em combinação com as assinaturas de Territorial Dispute do ShadowBrokers, fast16 leva a rever o momento de desenvolvimento de uma séria sabotagem cibernética de nível estatal e altamente furtiva
  • fast16 mostra, antes de famílias mais amplamente conhecidas, uma estrutura consistente que combina motor de scripting embarcado, segmentação estreita baseada em compilador e patch em nível de kernel
  • Por muito tempo, houve quase nenhuma ligação com análises públicas, campanhas nomeadas ou incidentes emblemáticos, e até as marcas legíveis deixadas internamente se limitam a formas contidas como *** Nothing to see here – carry on***
  • Ele se posiciona como um ponto de conexão na evolução dos APTs que leva a toolkits posteriores baseados em Lua e LuaJIT

Leituras relacionadas

1 comentários

 
GN⁺ 2 일 전
Comentários do Hacker News

  • Esta parte foi especialmente interessante
    A comparação de que a notação SCCS/RCS aparecer em código do kernel do Windows em 2005 seria como ver um telefone de disco num escritório hoje em dia pareceu bem convincente
    Até um laboratório de astrofísica onde trabalhei em 2006 ainda usava svn, e no codebase havia muito Fortran com vestígios de sistemas das décadas de 70 e 80
    Mesmo assim, tudo rodava bem graças aos compiladores modernos de otimização, e a migração de Vax para Linux nos anos 90 também foi surpreendentemente suave
    Isso me lembrou uma apresentação antiga sobre do over or make due, cuja ideia era basicamente que reescrever por completo um codebase grande que ainda funciona geralmente não vale a pena se for possível mantê-lo em pé com ferramentas modernas e alguns remendos

    • Trabalhei numa empresa que ainda usava SCM baseado em RCS até por volta de 2012, mas era um sistema improvisado que forçava RCS em cima de um servidor de arquivos compartilhado
      O nome era MKS, e ele gerenciava uma árvore específica de revisões como um "project file", mas parecia coisa dos anos 90, nem era uma versão refeita em Java EE
      No topo dos arquivos entravam tags como $Revision: 1.3 $ e um changelog, mas muitos arquivos novos nem tinham a tag, então a substituição nem acontecia e a consistência era um caos
      A linha de dispositivos-alvo tinha começado em meados dos anos 90, mas naquele ponto praticamente nenhum trecho do código em si tinha mais de 5 anos
      Mesmo com só algumas dezenas de engenheiros, conflitos de commit eram frequentes e a árvore inteira quebrava com frequência
      Por diversão, escrevi um script para ler todo o histórico e importar para git, mas bastava voltar alguns anos para os registros virarem uma bagunça completa
      Não sei por que ainda usavam aquilo naquela época, mas empresas de hardware às vezes tratavam controle de código-fonte, até bem recentemente, como se fosse basicamente uma "pasta compartilhada remota", então controle de versão do lado de software talvez simplesmente não fosse prioridade
    • Se você estiver usando R em 2026, há uma boa chance de que em algum ponto esteja quase certamente chamando código compilado de Fortran dos anos 70 ou 80
      Essa linhagem ainda serve de base no mundo da computação numérica
    • Eu costumava desconfiar um pouco da teoria de patrocínio estatal por trás do Stuxnet, mas vendo notas assim dá para entender por que essa hipótese surgiu
      Havia mesmo lugares usando RCS até os anos 2000, e em certos aspectos a ferramenta até tinha vantagens sobre SVN ou CVS
    • Então fico pensando se isso quer dizer que aquelas agências de siglas de 3 letras conseguiam puxar gente com experiência na área certa para cada tipo de malware
      Por exemplo, dá para imaginar que fast16 tenha sido escrito por alguém que antes fazia software de computação científica, e Stunex por alguém que trabalhava na Siemens
    • Refatoração não é cura para tudo
      Se a causa que fez o código precisar de refatoração continua lá, no fim ele volta ao mesmo estado
      Muitas vezes essa causa está enterrada em camadas psicológicas profundas, como hábitos, crenças e traumas profissionais dos desenvolvedores
      Somando isso à Lei de Conway, a equipe inevitavelmente acaba produzindo software que se parece com a estrutura organizacional maior, e se a organização não muda, o resultado da refatoração tende a se repetir
      A exceção costuma ser quando você assume o codebase de outro time ou de um antecessor e reorganiza a estrutura
      Mas quando as mesmas pessoas anunciam uma refatoração do próprio código, muitas vezes acabam só construindo uma ratoeira mais conveniente para elas mesmas
      Melhorar repetidamente o produto da própria forma de pensar é ok, mas para sair do carrossel é preciso anotar as causas da arquitetura ruim e fazer uma autoavaliação fria
      Aquela ideia em que muitos desenvolvedores gostam de acreditar — de que "se você for cuidadoso e diligente, até um design meio ruim pode ser bem implementado" — na maioria das vezes não se sustenta
      No fim, a raiz é o design, e ou você aceita a árvore que cresceu dali ou a corta; só podar os galhos tem limite

  • Este texto passa uma sensação bem sinistra
    Só o fato de esse malware ter ficado 20 anos abaixo do radar já é suficientemente perturbador

  • Aqui vai o link de download para quem estiver curioso
    https://bazaar.abuse.ch/sample/9a10e1faa86a5d39417cae44da5ad...
    Acho que eu começaria montando uma VM com Windows XP

    • Fico me perguntando se já apareceu o arquivo de serviço do Windows
      Aquilo parece ser só o loader

  • IEEE-754 só exige arredondamento correto para +-*/ e sqrt
    Funções transcendentes como sin/cos/exp/log/pow permitem diferenças de alguns ULPs no final, e glibc, musl, MSVC e Intel SVML de fato se comportam assim
    PID usa principalmente operações básicas, então sofre menos com diferenças de libm, mas controle vetorial de motores e linearização de sensores mexem nessas funções a cada ciclo, então pequenas discrepâncias vão se acumulando
    Por isso, mesmo sem nenhuma diff no código-fonte, só trocar a libm linkada já pode fazer o comportamento em campo derivar
    Essas diferenças realmente aparecem em reduction de argumentos de Payne-Hanek ou nos piores limites do table-maker's dilemma
    Provavelmente é por isso que guias de sistemas críticos de segurança não escrevem apenas "conforme IEEE-754", mas fixam um build específico da libm

  • É uma descoberta realmente impressionante
    Fico muito curioso sobre o que exatamente essas regras miravam e como alteravam o resultado
    Talvez tenham sido projetadas para produzir diferenças só em condições de simulação muito específicas, como num reator

    • Dei uma investigada em como um software como LS-DYNA poderia ser adulterado
      Por exemplo, a equação EOS_JWL no manual público [1] é uma das fórmulas implementadas pelo LS-DYNA, e junto com outras equações parece poder ser usada para calcular coisas como o tempo até que o espoleta de uma ogiva de míssil detone a carga principal e gere uma determinada onda de pressão a 20 m de distância
      Usando esse resultado ao contrário, também daria para estimar o timing necessário do fusível
      As equações e parâmetros usados pelo LS-DYNA vêm de pesquisas científicas como [2], que é um estudo do governo dos EUA dos anos 1980 sobre testes com explosivos de alto poder
      Há inclusive experimentos medindo como o explosivo interage por atrito com vários materiais ao redor
      Como as fórmulas para modelagem de explosivos já estão prontas, bastaria mexer de leve nelas e adicionar ruído de ±20% ao coeficiente de atrito para que cientistas ou engenheiros provavelmente suspeitassem primeiro de problemas na qualidade de fabricação do aço, e não de manipulação do software
      Uma analogia moderna seria imaginar algum país adversário usando uma cópia pirateada de Ansys Autodyn 2026 R1 postada num fórum chinês por um grupo chinês de cracking, baixada de alguns poucos seeders atrás de um ISP russo
      Aí, só mais tarde, quando os resultados experimentais e calculados começassem a divergir repetidamente, é que poderiam suspeitar que a cópia pirateada foi adulterada de propósito
      Ainda assim, hoje talvez fosse mais fácil para esse país adversário obter uma cópia legítima extraída de redes invadidas de alguma universidade aleatória ou de uma consultoria aeroespacial/defesa
      Também pode ser ingênuo presumir que um país adversário em 2026 não conseguiria desenvolver o software do zero, e dá para chegar a resultados desejados também com cálculos manuais ou experimentação
      No fim, para verificar a qualidade de fabricação, equipamento e capacidade experimental já são necessários de qualquer forma
      Software de simulação serve principalmente para reduzir o número de protótipos e de testes físicos, economizando tempo e dinheiro
      Por exemplo, rodar 1000 simulações de um projétil atingindo uma chapa de blindagem como em [3] é barato, mas repetir isso no mundo real é muito mais caro e demorado
      [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

  • Quando veem que as coisas que eu publico vêm com dados de revisão do RCS, espero que as pessoas pelo menos parem por um instante

  • Um livro que li recentemente foi Sandworm: A New Era of Cyberwar and the Hunt for the Kremlin's Most Dangerous Hackers, de Andy Greenberg
    Gostei bastante, e como novas informações continuam surgindo, acho que talvez até mereça uma continuação

  • Vendo Guix e computação reproduzível sendo portados até para PowerPC e máquinas legadas, imagino que governos e instituições tipo 1984, além de alguns grupos no Oriente Médio, realmente devam odiar isso
    Quanto mais heterogêneo o ambiente, melhor

  • A chave é o worm
    Não adianta verificar em outro computador se ele também não detecta nada, porque para começar nem existe um segundo computador realmente limpo

  • É uma descoberta interessante, mas o comentário sobre controle de código-fonte parece um pouco fora de tom
    Naquela época ainda devia haver coisas parecidas com SCCS por aí, e por um momento até fiquei em dúvida se CVS não era de um estilo semelhante

    • Acho que o comentário queria dizer que isso era raro em software para Windows
      Isso sugere que os desenvolvedores originalmente também trabalhavam no lado UNIX, onde SCCS/RCS era comum