
Biblioteca em desenvolvimento injetada no Steam para bloquear a thread oculta CFillMachineInfoThread que coleta HWID, disco, adaptador de rede e dados de impressão digital do registro.
Biblioteca em desenvolvimento (atualmente apenas registra a inicialização da thread) que, uma vez injetada no steam, tem como objetivo bloquear CSteamEngine::CFillMachineInfoThread, que é uma thread oculta que coleta informações criptografadas sobre seus discos rígidos, adaptadores de rede e periféricos ópticos com o propósito lamentável de bloquear todas as suas contas alternativas e fazer você perder milhares de dinheiro (e eu realmente não quero pagar um centavo a mais pelo salário do burtonJ)
Você pode encontrar a instrução procurando por esta string no IDA e xref:
Você não pode simplesmente terminar ou retornar a thread, mas possibilidades interessantes se abrem. Essa função faz parte da única função (além do construtor, iniciador e terminador/desconstrutor) de uma tabela virtual que herda CScheduledFunction.
'MachineGuid' é coletado do registro e passa por SHA1, possivelmente com uma constante "BB3"? Eu não sei porra nenhuma sobre criptografia
Outras informações de registro de dispositivo são então coletadas
Ao mesmo tempo, consultas CIMV2 WMIC para recuperar adaptadores de rede são executadas
Desta vez os dados acima são criptografados com a constante "FF2"? Uma abordagem interessante sem bloquear toda a thread poderia ser alterar essas constantes para modificar os resultados do digest. Se a Steam voltasse a não criptografar essas strings, eles poderiam estar violando o GDPR, pois estão coletando informações que podem ser classificadas como "dados pessoais"
Mais consultas se seguem, a quantidade de dados que eles coletam é assustadora.
"SELECT * FROM Win32_DiskPartition", eles verificam BootPartitions, DeviceID, DiskIndex, novamente "SELECT * FROM Win32_DiskDrive", mais coisas, então mais uma VEZ "SELECT * FROM Win32_PhysicalMedia", eles verificam números de série e fabricante.
Criptografado novamente, constante "3B3" (?)
Finalmente, o segundo argumento do chamado é criptografado (se não for NULL) com a constante "333" (?)