In this LABScon 25 presentation, Joe FitzPatrick explores how networked devices manufactured overseas have quietly become indispensable to everything from small-business prototyping labs to roadside infrastructure. He argues that the safeguards meant to manage the risks these devices introduce are, in practice, largely ineffective.
Starting with recent reports of undocumented cellular radios found in solar inverters used in U.S. highway infrastructure, Joe notes that adding that kind of connectivity to a device with an exposed serial port takes minutes and can be done by anyone: the manufacturer, the installer, or someone who came along later.
From there he covers the familiar mechanisms by which banned hardware finds its way into supply chains anyway, through relabeling and FCC-certified modular components, before turning to mandatory product activation in consumer devices like drones and 3D printers, and what it actually takes to use them without phoning home.
The deeper problem is that small businesses and infrastructure operators are genuinely dependent on imported hardware because it works and it’s affordable. A significant amount of it runs on devices that connect to foreign entities by default, and there’s no clean domestic alternative.
Joe concludes that import bans don’t fix problems that exist equally in domestic products, and that trade policy is the wrong tool for what is fundamentally a consumer safety problem. His preferred alternatives are right to repair with offline use guarantees, hardware and firmware bills of materials, and comprehensive privacy legislation.
This talk is essential viewing for security practitioners concerned about hardware supply chain risks, the unexpected connectivity of critical infrastructure, or the US’s deep dependence on foreign-manufactured consumer electronics.
About the Author
Joe FitzPatrick (@securelyfitz) is an Instructor and Researcher at SecuringHardware.com. Joe has spent most of his career working on low-level silicon debug, security validation, and penetration testing of CPUs, SoCs, and microcontrollers. He has spent the past decade developing and delivering hardware security related tools and training, instructing hundreds of security researchers, pen testers, and hardware validators worldwide. When not teaching Applied Physical Attacks training, Joe is busy developing new course content or working on contributions to the NSA Playset and other misdirected hardware projects, which he regularly presents at all sorts of fun conferences.
LABScon is a unique venue for original research to be shared among peers. The benefit of an invite-only audience of researchers is that there’s no need for long preambles or introductions – speakers are encouraged to dive right into their technical findings.
Original content only.
Talks are 20 minutes long + 5 minutes for Q&A.
Workshops are 90 minutes long.
LABScon is primarily a threat intelligence and vulnerability research conference but we keep an open-mind.
About LABScon
This presentation was featured live at LABScon 2025, an immersive 3-day conference bringing together the world’s top cybersecurity minds, hosted by SentinelOne’s research arm, SentinelLABS.
In this LABScon 25 presentation, Marc Rogers and Silas Cutler explore the complex, “shadow” supply chain of ultra-cheap Chinese smart home devices, specifically focusing on video doorbells and security cameras widely sold on mainstream online shopping platforms under various rotating brand names like Eken and Tuck.
Marc, who assisted the FCC Enforcement Bureau in its investigations, and Silas reveal how these devices often share identical hardware platforms powered by Allwinner semiconductors, a company heavily subsidized by the Chinese government.
Firmware analysis uncovered hardcoded root passwords and supposed security fixes that amounted to little more than commenting out vulnerable services from startup scripts rather than removing them. Despite appearing to use local cloud services, metadata and video content are frequently routed through servers in Hong Kong and China.
Rogers and Cutler trace a network of shell companies and fictional personas entirely absent from tax and voter records. These entities use non-responsive registered agents and PO boxes specifically set up to refuse legal service, effectively shielding the actual manufacturers from regulatory oversight and making enforcement nearly impossible.
The rapid iteration of hardware versions with no long-term support mirrors distribution patterns more commonly associated with malware campaigns.
While the investigation stops short of attributing direct malice, Rogers and Cutler argue that these devices collectively form a massive, vulnerable IoT surface that can be controlled through simple configuration pushes from overseas. Consumers are drawn in by low prices and subscription features, unaware that their data ultimately resides under foreign control.
About the Authors
Marc Rogers is Co-Founder and Chief Technology Officer for the AI observability startup nbhd.ai. Marc has served as VP of Cybersecurity Strategy for Okta, Head of Security for Cloudflare and Principal Security researcher for Lookout. In his role as technical advisor on USA’s “Mr. Robot” and the BBC’s “The Real Hustle”, he helped create on-screen hacks for both shows.
Silas Cutler is a Principal Security Researcher at Censys, with over a decade of experience tracking threat actors and developing methods for pursuit. Before Censys, he worked as Resident Hacker for Stairwell, Reverse Engineering Lead for Google Chronicle, and as a Senior Security Researcher on CrowdStrike’s Intelligence team.
LABScon is a unique venue for original research to be shared among peers. The benefit of an invite-only audience of researchers is that there’s no need for long preambles or introductions – speakers are encouraged to dive right into their technical findings.
Original content only.
Talks are 20 minutes long + 5 minutes for Q&A.
Workshops are 90 minutes long.
LABScon is primarily a threat intelligence and vulnerability research conference but we keep an open-mind.
About LABScon
This presentation was featured live at LABScon 2025, an immersive 3-day conference bringing together the world’s top cybersecurity minds, hosted by SentinelOne’s research arm, SentinelLABS.
Cybersecurity researchers at Fortinet have discovered Nexcorium, a new Mirai-based malware targeting TBK DVR systems to turn them into a botnet for DDoS attacks.
Mirai malware evolves into hundreds of variants, driving botnet growth, including Aisuru and KimWolf, powering large-scale attacks, and increasing risks to vulnerable IoT devices worldwide.
CISA warns Honeywell CCTVs are affected by a critical auth bypass flaw (CVE-2026-1670) allowing unauthorized access or account hijacking.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) warns that Honeywell CCTVs are affected by a critical authentication bypass flaw, tracked as CVE-2026-1670 (CVSS score of 9.8), that lets attackers change the recovery email without logging in. This vulnerability enables account takeovers and unauthorized access to camera feeds by exploiting an unauthenticated API endpoint for password recovery.
“Successful exploitation of this vulnerability could lead to account takeovers and unauthorized access to camera feeds; an unauthenticated attacker may change the recovery email address, potentially leading to further network compromise.” reads the alert published by CISA.
The vulnerability was discovered by cybersecurity researcher Souvik Kandar.
The vulnerability impacts the following Honeywell CCTVs models:
A critical auth bypass flaw in Honeywell CCTV models could allow attackers to take over accounts, granting unauthorized access to live feeds. Many of these cameras are used in critical infrastructure, corporate sites, and government facilities worldwide. The flaw can be exploited remotely, risking sensitive surveillance data and enabling attackers to move laterally within networks, making it a severe threat to security, privacy, and operational integrity.
CISA advises organizations to reduce risk from this Honeywell CCTV flaw by isolating control system devices from the Internet, using firewalls, and placing remote devices behind secure networks. When remote access is needed, employ updated VPNs and ensure connected devices are secure. Organizations should perform risk assessments before deploying defenses, follow ICS security best practices from cisa.gov/ics, and report suspicious activity. Users should avoid phishing and unsolicited links; no active exploitation has been reported.
The US agency is not aware of attacks exploiting this flaw in the wild.
Russia's current isolation from the Olympics may lead to increased cyberthreats targeting the 2026 Winter Games. We discuss the potential threat picture.
Milhões de sistemas de TI, sendo que alguns deles são industriais e outros de IoT, podem começar a se comportar de forma imprevisível em 19 de janeiro. As possíveis falhas incluem: falhas no processamento pagamentos com cartão; alarmes falsos de sistemas de segurança; operação incorreta de equipamentos médicos; falhas nos sistemas automatizados de iluminação, aquecimento e abastecimento de água; e muitos tipos de erros mais ou menos graves. O problema é que… isso acontecerá em 19 de janeiro de 2038. Não que isso seja motivo para relaxar, muito pelo contrário! O tempo restante para providenciar os preparativos talvez seja insuficiente. A causa dessa infinidade de problemas será um estouro nos números inteiros que armazenam data e hora. Embora a causa raiz do erro seja simples e clara, corrigi-lo exigirá esforços extensos e sistemáticos em todos os níveis : de governos e organismos internacionais a organizações e indivíduos.
O padrão informal da Época Unix
A Época Unix é o sistema de cronometragem adotado pelos sistemas operacionais Unix que se tornou popular em todo o setor de TI. Ele conta os segundos de 00:00:00 UTC em 1º de janeiro de 1970, considerado o ponto zero. Qualquer momento no tempo é representado como o número de segundos que se passaram desde aquela data. Para datas anteriores a 1970, são usados valores negativos. Essa abordagem foi escolhida pelos desenvolvedores do Unix por sua simplicidade, em vez de armazenar o ano, mês, dia e hora separadamente, apenas um único número é necessário. Isso facilita operações como classificar ou calcular o intervalo entre datas. Hoje, a Época Unix é usada muito além dos sistemas Unix: em bancos de dados, linguagens de programação, protocolos de rede e em smartphones executando iOS e Android.
A bomba-relógio Y2K38
Inicialmente, quando o Unix foi desenvolvido, foi tomada a decisão de armazenar o tempo como um inteiro com sinal de 32 bits. Isso permitia representar um intervalo de datas de aproximadamente 1901 a 2038. O problema é que, em 19 de janeiro de 2038, às 03:14:07 UTC, esse número atingirá seu valor máximo (2.147.483.647 segundos) e sofrerá um estouro, tornando-se negativo, fazendo com que os computadores se “teletransportem” de janeiro de 2038 para 13 de dezembro de 1901. Em alguns casos, no entanto, uma “viagem no tempo” mais curta pode acontecer, até o ponto zero, que é o ano de 1970.
Esse evento, conhecido como “problema do ano 2038”, “Epochalypse” ou “Y2K38”, poderá ocasionar falhas em sistemas que ainda usam a representação de tempo de 32 bits, como terminais POS, de sistemas integrados e roteadores, passando por automóveis, até equipamentos industriais. Os sistemas modernos resolvem esse problema usando 64 bits para armazenar o tempo. Isso estende o intervalo de datas para centenas de bilhões de anos no futuro. No entanto, milhões de dispositivos com datas de 32 bits ainda estão em operação e precisarão ser atualizados ou substituídos antes da chegada do “dia Y”.
Neste contexto, 32 e 64 bits se referem especificamente ao formato de armazenamento de data. Só porque um sistema operacional ou processador é de 32 bits ou 64 bits, isso não significa automaticamente que ele armazene a data em seu formato de bits “nativo”. Além disso, muitos aplicativos armazenam datas de maneiras completamente diferentes e podem ser imunes ao problema Y2K38, independentemente de sua quantidade de bits.
Nos casos em que não há necessidade de tratar datas anteriores a 1970, a data é armazenada como um número inteiro não assinado de 32 bits. Esse tipo de número pode representar datas de 1970 a 2106, portanto, o problema chegará em um futuro mais distante.
Diferenças do problema do ano 2000
O infame problema do ano 2000 (Y2K) do final do século 20 era semelhante. Naquelas circunstâncias, os sistemas que armazenavam o ano como dois dígitos poderiam confundir a nova data com o ano 1900. Tanto os especialistas quanto a mídia temiam um apocalipse digital, mas, no fim, houve apenas numerosas manifestações isoladas que não resultaram falhas catastróficas globais.
A principal diferença entre Y2K38 e Y2K é a escala da digitalização em nossas vidas. O número de sistemas que precisarão de atualização é muito maior do que o número de computadores no século 20, e a contagem de tarefas e processos diários gerenciados por computadores está além do cálculo. Enquanto isso, o problema Y2K38 já foi, ou será muito em breve, corrigido em computadores e sistemas operacionais comuns com atualizações de software simples. No entanto, os microcomputadores que gerenciam aparelhos de ar-condicionado, elevadores, bombas, fechaduras eletrônicas e linhas de montagem industriais podem muito bem continuar operando pela próxima década com versões de software desatualizadas e vulneráveis ao Y2K38.
Possíveis problemas do Epochalypse
A passagem da data para 1901 ou 1970 afetará sistemas diferentes, de maneiras diferentes. Em alguns casos, como em um sistema de iluminação programado para ligar todos os dias às 19h, a programação poderá passar completamente despercebida. Em outros sistemas que dependem de carimbos de data/hora completos e precisos, uma falha completa poderá ocorrer – por exemplo, no ano 2000, terminais de pagamento e catracas de transporte público pararam de funcionar. Casos cômicos também são possíveis, como a emissão de uma certidão de nascimento com uma data em 1901. Muito pior seria a falha de sistemas críticos, como o desligamento completo de um sistema de aquecimento ou a falha de um sistema de análise de medula óssea em um hospital.
A criptografia ocupa um lugar especial no Epochalypse. Outra diferença fundamental entre 2038 e 2000 é o uso generalizado de criptografia e assinaturas digitais para proteger todas as comunicações. Os certificados de segurança geralmente falham na verificação se a data do dispositivo estiver incorreta. Isso significa que um dispositivo vulnerável seria eliminado da maioria das comunicações, mesmo que seus aplicativos de negócios principais não tenham nenhum código que manipule incorretamente a data.
Infelizmente, o espectro completo de consequências só poderá ser determinado por meio de testes controlados de todos os sistemas, com a análise separada de uma potencial cascata de falhas.
A exploração maliciosa do Y2K38
As equipes de TI e InfoSec devem tratar o Y2K38 não como um simples bug de software, mas como uma vulnerabilidade que poderá ocasionar várias falhas, inclusive a negação de serviço. Em alguns casos, ela poderá até mesmo ser explorada por agentes maliciosos. Para fazer isso, eles precisarão ter a capacidade de manipular a hora no sistema de destino. Isso é possível em pelo menos dois cenários:
Interferência nos dados do protocolo NTP ao fornecer ao sistema invadido um servidor de tempo falso
Falsificação do sinal de GPS, caso o sistema dependa da hora via satélite
A exploração desse erro é mais provável em sistemas OT e IoT, onde as vulnerabilidades são tradicionalmente lentas para serem corrigidas e as consequências de uma falha podem ser muito mais substanciais.
Um exemplo de uma vulnerabilidade facilmente explorável relacionada à contagem de tempo é CVE-2025-55068 (CVSSv3 8.2, CVSSv4 base 8.8) nos consoles de medidor de tanque de combustível Dover ProGauge MagLink LX4. A manipulação do tempo pode causar uma negação de serviço no posto de gasolina e bloquear o acesso ao painel de gerenciamento da Web do dispositivo. Esse defeito ganhou seu próprio alerta da CISA.
O status atual da atenuação do Y2K38
Os parâmetros de resolução para o problema do Y2K38 foram estabelecidos com êxito nos principais sistemas operacionais. O kernel do Linux adicionou suporte para o tempo de 64 bits, mesmo em arquiteturas de 32 bits, a partir da versão 5.6, em 2020, e o Linux de 64 bits sempre foi protegido desse problema. A família BSD, macOS e iOS usam o tempo de 64 bits em todos os dispositivos modernos. Todas as versões do Windows lançadas no século 21 não são suscetíveis ao Y2K38.
A situação no armazenamento de dados e no nível do aplicativo é muito mais complexa. Sistemas de arquivos modernos, como ZFS, F2FS, NTFS e ReFS foram desenvolvidos com carimbos de data/hora de 64 bits, enquanto sistemas mais antigos como ext2 e ext3 permanecem vulneráveis. O Ext4 e o XFS exigem que sinalizadores específicos sejam ativados (inode estendido para ext4 e bigtime para XFS), além disso, eles podem necessitar da conversão off-line de sistemas de arquivos existentes. Nos protocolos NFSv2 e NFSv3, o formato de armazenamento de tempo desatualizado persiste. O cenário é igualmente fragmentado nos bancos de dados, o tipo TIMESTAMP do MySQL é intrinsecamente limitado ao ano de 2038 e exige migração para DATETIME, enquanto os tipos de carimbo de data/hora padrão do PostgreSQL são seguros. Para aplicativos escritos em C, os caminhos foram criados para usar o tempo de 64 bits em arquiteturas de 32 bits, mas todos os projetos precisam de recompilação. Linguagens como Java, Python e Go normalmente usam tipos que evitam o estouro, mas a segurança dos projetos compilados depende da possibilidade de interação com bibliotecas vulneráveis escritas em C.
Um grande número de sistemas de 32 bits, dispositivos integrados e aplicativos permanecem vulneráveis até que eles sejam reconstruídos e testados e, em seguida, tenham as atualizações instaladas por todos os usuários.
Várias organizações e entusiastas estão tentando sistematizar informações sobre isso, mas os esforços estão fragmentados. Consequentemente, não há um “banco de dados de vulnerabilidades Y2K38 comum” disponível (1, 2, 3, 4, 5).
Abordagens para correção do Y2K38
As metodologias criadas para priorizar e corrigir vulnerabilidades são diretamente aplicáveis ao problema do ano de 2038. O principal desafio consiste no fato de que nenhuma ferramenta contemporânea pode criar uma lista exaustiva de software e hardware vulneráveis. Portanto, é essencial atualizar o inventário de ativos de TI corporativos, garantir que ele seja enriquecido com informações detalhadas sobre firmware e software instalado e, em seguida, investigar sistematicamente a questão da vulnerabilidade.
A lista pode ser priorizada de acordo com a criticidade dos sistemas de negócios e com os dados na pilha de tecnologia na qual cada sistema está construído. As próximas etapas são: estudar o portal de suporte do fornecedor, fazer perguntas diretas aos fabricantes de hardware e software sobre seu status Y2K38 e, como último recurso, fazer a verificação por meio de testes.
Ao testar sistemas corporativos, é fundamental tomar precauções especiais:
Nunca teste os sistemas que estão em produção.
Crie um backup de dados imediatamente antes do teste.
Isole o sistema em teste das comunicações, para que ele não interfira em outros sistemas da organização.
Caso a alteração da data use NTP ou GPS, verifique e confirme se os sinais de teste do 2038 não podem alcançar outros sistemas.
Após o teste, defina os horários de volta para a hora correta nos sistemas e documente minuciosamente todos os seus comportamentos observados.
Caso um sistema seja considerado vulnerável ao Y2K38, uma linha do tempo de correção deverá ser solicitada ao fornecedor. Caso uma correção seja impossível, planeje uma migração; felizmente, o tempo que nos resta ainda permite a atualização de sistemas bastante complexos e caros.
A coisa mais importante para enfrentar o Y2K38 é não pensar nele como um problema futuro distante cuja solução pode facilmente esperar mais cinco a oito anos. É altamente provável que já não tenhamos tempo suficiente para erradicar completamente o defeito. No entanto, dentro de uma organização com seu parque tecnológico, o planejamento cuidadoso e a abordagem sistemática para resolver o problema permitirão realmente fazer tudo isso em tempo hábil.
A polícia sul-coreana prendeu quatro suspeitos ligados à violação de aproximadamente 120 mil câmeras IP instaladas em residências e espaços comerciais, incluindo karaokês, estúdios de pilates e uma clínica de ginecologia. Dois dos hackers venderam imagens sexualmente explícitas captadas pelas câmeras por meio de um site estrangeiro de conteúdo adulto. Nesta publicação, explicamos o que são as câmeras IP e quais as suas vulnerabilidades. Também nos aprofundamos nos detalhes do incidente na Coreia do Sul e compartilhamos conselhos práticos sobre como evitar se tornar um alvo para invasores que buscam conteúdo de vídeos íntimos.
Como as câmeras IP funcionam?
Uma câmera IP é uma câmera de vídeo conectada à Internet usando o Protocolo de Internet (IP). Essa conexão faz com que seja possível visualizar seu feed remotamente usando um smartphone ou computador. Ao contrário dos sistemas de vigilância CCTV tradicionais, essas câmeras não exigem uma central de vigilância local, como mostrado nos filmes, nem mesmo um computador dedicado conectado a elas. Uma câmera IP transmite o vídeo em tempo real pela Internet para qualquer dispositivo que esteja conectado a ela. Atualmente, a maioria dos fabricantes de câmeras IP também oferece planos opcionais de armazenamento em nuvem, permitindo que você acesse as imagens gravadas em qualquer lugar do mundo.
Nos últimos anos, as câmeras IP se tornaram muito populares e estão por toda parte, sendo usadas para os mais diversos fins: desde cuidar de crianças e animais de estimação em casa até proteger armazéns, escritórios, apartamentos de aluguel por temporada (às vezes de maneira irregular) e pequenos negócios. Modelos básicos podem ser encontrados online por preços a partir de 25 a 40 dólares.
Você pode encontrar uma câmera IP Full HD em mercados virtuais por menos de 25 dólares. Os preços acessíveis fizeram com que elas se tornassem extremamente populares tanto para uso doméstico quanto em pequenos negócios.
Um dos recursos essenciais das câmeras IP é terem sido projetadas originalmente para acesso remoto. A câmera conecta-se à Internet e aceita silenciosamente conexões de entrada, e ela já pode transmitir vídeo para qualquer pessoa que tenha seu endereço e senha. E isso gera dois problemas comuns desses dispositivos.
Senhas padrão. Os proprietários de câmeras IP não costumam alterar os nomes de usuário e senhas padrão que já vêm pré-configurados no dispositivo.
Vulnerabilidades em softwares desatualizados. Atualizações de software para câmeras geralmente exigem intervenção manual: você precisa acessar a interface de administração, verificar se há uma atualização e instalá-la manualmente. Muitos usuários costumam ignorar isso completamente. Ou pior, as atualizações podem nem ao menos existir, pois muitos fornecedores de câmeras ignoram a segurança e deixam de oferecer suporte logo após a venda.
O que aconteceu na Coreia do Sul?
Vamos voltar ao que ocorreu neste outono na Coreia do Sul. As autoridades policiais relataram uma violação de cerca de 120 mil câmeras IP e a prisão de quatro suspeitos ligados aos ataques. Aqui está o que sabemos sobre cada um deles.
Suspeito 1, desempregado, hackeou cerca de 63 mil câmeras IP, produziu e depois vendeu 545 vídeos de conteúdo sexual explícito por um total de 35 milhões de wons sul-coreanos, o equivalente a pouco menos de 24 mil dólares.
Suspeito 2, funcionário de escritório, violou cerca de 70 mil câmeras IP e vendeu 648 vídeos sexuais ilícitos por 18 milhões de wons sul-coreanos (cerca de 12 mil dólares).
Suspeito 3, autônomo, hackeou 15 mil câmeras IP e criou conteúdo ilegal, incluindo imagens de menores de idade. Até o momento, não há informações indicando que ele vendeu algum material.
Suspeito 4, funcionário de escritório, aparentemente violou apenas 136 câmeras IP e não foi acusado de produzir ou vender conteúdo ilegal.
O leitor atento pode ter percebido que os números não batem exatamente: as cifras acima totalizam bem mais de 120 mil. As autoridades sul-coreanas não forneceram uma explicação clara para essa discrepância. Os jornalistas especulam que alguns dispositivos podem ter sido comprometidos por mais de um invasor.
A investigação revelou que só dois suspeitos venderam o conteúdo sexual que roubaram. No entanto, a dimensão da operação deles é impressionante. No ano passado, o site que ambos os autores utilizaram para vender seus vídeos e que hospeda conteúdo de voyeurismo e exploração sexual recebeu 62% de seus uploads só desses indivíduos. Em essência, isso significa que a dupla de entusiastas de vídeo forneceu a maior parte do conteúdo ilegal da plataforma. Também foi relatada a detenção de três compradores desses vídeos.
Os investigadores sul-coreanos conseguiram identificar com precisão o local de 58 câmeras hackeadas. Eles notificaram as vítimas e forneceram orientações sobre como alterar as senhas para proteger suas câmeras IP. Ainda que os investigadores não tenham divulgado detalhes sobre o método de comprometimento, isso indica que os invasores usaram força bruta para decifrar as senhas simples das câmeras.
Outra possibilidade é que os proprietários, como acontece com frequência, simplesmente nunca tenham alterado os nomes de usuário e as senhas padrão. Essas credenciais padrão são amplamente conhecidas, portanto, é perfeitamente plausível que, para obter acesso, os invasores só precisassem saber o endereço IP da câmera e testar algumas combinações comuns de nome de usuário e senha.
Como evitar ser vítima de hackers voyers
As principais lições de todo esse dorama sul-coreano saem diretamente do nosso manual:
Sempre substitua as credenciais de fábrica por logins e senhas próprios.
Nunca use senhas fracas ou simples, mesmo para contas ou gadgets aparentemente inofensivos. Você não precisa trabalhar no Louvre para ser um alvo. Não é possível saber quais credenciais os invasores tentarão quebrar ou para onde essa violação inicial pode levá-los.
Sempre defina senhas exclusivas. Ao reutilizar senhas, um vazamento de dados de um serviço pode colocar todas as suas outras contas em risco.
Essas regras são universais: valem tanto para contas de redes sociais e serviços bancários quanto para robôs aspiradores, câmeras IP e qualquer outro dispositivo inteligente da sua casa.
Para manter todas essas senhas exclusivas organizadas sem perder a cabeça, recomendamos um gerenciador de senhas confiável. O Kaspersky Password Manager pode armazenar todas as suas credenciais com segurança e gerar senhas aleatórias, complexas e indecifráveis. Com ele, você pode ter a tranquilidade de que ninguém descobrirá as senhas de suas contas ou dispositivos. Além disso, ele ajuda você a gerar códigos únicos para autenticação de dois fatores, salvar e preencher automaticamente chaves de acesso e sincronizar seus dados sensíveis (não apenas logins e senhas, mas também dados de cartões bancários, documentos e até fotos privadas) de forma criptografada em todos os seus dispositivos.
Desconfia que uma câmera oculta pode estar filmando você? Leia mais em nossas publicações:
Imagine que convidaram você para um jogo de pôquer privado com atletas famosos. Em quem você confiaria mais para embaralhar as cartas: em um crupiê ou em um dispositivo automatizado especializado? Fundamentalmente, essa questão se resume ao que você mais acredita: na honestidade do crupiê ou na confiabilidade da máquina. É provável que muitos jogadores de pôquer prefiram o dispositivo especializado, já que é muito mais difícil subornar ou coagir uma máquina do que um ser humano. No entanto, em 2023, pesquisadores de segurança cibernética demonstraram que um dos modelos mais populares, o DeckMate 2, fabricado pela Light & Wonder, é, na verdade, muito fácil de hackear.
Dois anos depois, a polícia encontrou vestígios de manipulação desses dispositivos não em um laboratório, mas em estabelecimentos. Esta postagem detalha como o embaralhador DeckMate 2 funciona, por que seu design facilita a trapaça, como os criminosos usaram o hack e o que o basquete tem a ver com tudo isso.
Como funciona o embaralhador automático de cartas DeckMate 2
O embaralhador automático DeckMate 2 começou a ser fabricado em 2012. Desde então, ele se tornou um dos modelos mais populares, usado em quase todos os principais cassinos e clubes de pôquer privados do mundo. O dispositivo é uma caixa preta, quase do tamanho de uma fragmentadora de papel comum, geralmente instalada sob a mesa de pôquer.
O DeckMate 2 é um embaralhador automático de cartas profissional que mistura rapidamente o baralho enquanto verifica se todas as 52 cartas estão presentes e se nenhuma carta extra foi inserida. Fonte
Na superfície da mesa, é possível ver apenas um pequeno compartimento onde as cartas são colocadas para serem embaralhadas. É provável que a maioria dos jogadores comuns não perceba que a parte “submersa” do “iceberg” é muito maior e mais complexa do que parece à primeira vista.
É assim que o DeckMate 2 se parece quando é instalado em uma mesa de jogo: a parte divertida está escondida sob a superfície. Fonte
Depois que o crupiê coloca o baralho dentro do DeckMate 2, a máquina faz as cartas passarem pelo módulo de leitura, uma a uma. Nesse estágio, o dispositivo verifica se o baralho contém todas as 52 cartas e nada além delas. Se houver algo fora do normal, a tela conectada exibirá um alerta. Depois, a máquina embaralha as cartas e devolve o baralho ao crupiê.
O DeckMate 2 leva apenas 22 segundos para embaralhar e verificar as cartas. A verificação de cartas ausentes ou extras é feita por uma câmera interna que confere todas. Ela também participa da ordenação do baralho. É difícil imaginar o uso prático desse último recurso em jogos de cartas. Supõe-se que os designers o adicionaram apenas porque podiam.
Seguindo adiante, foi exatamente essa câmera que literalmente permitiu que pesquisadores e infratores visualizassem a sequência das cartas. O modelo anterior, chamado Deck Mate, não tinha essa câmera e, portanto, não oferecia uma maneira de espiar a ordem das cartas.
Para impedir a ação de hackers, o DeckMate 2 utiliza uma verificação de hash que garante que o software permaneça inalterado após a instalação. Na inicialização, o dispositivo calcula o hash do firmware e o compara com a referência armazenada na sua memória. Se os valores coincidirem, a máquina entende que o firmware está íntegro e prossegue. Caso contrário, identifica uma tentativa de adulteração.
Além disso, o design do DeckMate 2 inclui uma porta USB, que é usada para carregar atualizações de firmware. Os dispositivos DeckMate 2 também podem ser alugados da Light & Wonder em um modelo de pagamento por uso, em vez de adquiridos. Nesse caso, é comum eles estarem equipados com um modem celular que transmite dados de uso ao fabricante para fins de cobrança.
Como os pesquisadores conseguiram comprometer o DeckMate 2
Os leitores de longa data do nosso blog provavelmente já detectaram várias falhas no design do DeckMate 2 que foram exploradas pelos pesquisadores para sua prova de conceito. Eles fizeram uma demonstração na conferência de segurança cibernética Black Hat em 2023.
A primeira etapa do ataque foi conectar um pequeno dispositivo à porta USB. Para a prova de conceito, os pesquisadores usaram um microcomputador Raspberry Pi, que é menor do que a palma da mão de um adulto. No entanto, eles observaram que, com recursos suficientes, os infratores conseguem executar o mesmo ataque usando um módulo ainda mais compacto, que tem o tamanho de uma unidade flash USB padrão.
Depois de conectado, o dispositivo modificava o código do DeckMate 2 e assumia o controle. Isso também concedeu aos pesquisadores acesso à câmera interna mencionada acima, usada para verificar o baralho. Agora eles conseguiam visualizar a ordem exata das cartas no baralho em tempo real.
Essas informações foram transmitidas via Bluetooth para um celular próximo, onde um app experimental mostrava a sequência das cartas.
O aplicativo experimental criado pelos pesquisadores: recebe a ordem das cartas do DeckMate 2 hackeado via Bluetooth.Fonte
O sucesso do golpe depende do fato de que o cúmplice do trapaceiro mantém o celular com o app instalado. Essa pessoa pode então usar gestos discretos para o jogador trapaceiro.
O que permitiu aos pesquisadores obter esse grau de controle sobre o DeckMate 2 foi uma vulnerabilidade nas suas senhas embutidas no código. Para os testes, eles compraram vários embaralhadores usados, e um dos vendedores forneceu a eles a senha de manutenção do DeckMate 2. Os pesquisadores extraíram as senhas restantes diretamente do firmware, incluindo a senha de root.
Essas senhas de sistema no DeckMate 2 são definidas pelo fabricante e devem ser iguais em todos os aparelhos. Enquanto estudavam o código do firmware, os pesquisadores descobriram que as senhas estavam embutidas no sistema, tornando-as difíceis de alterar. Como resultado, o mesmo conjunto de senhas, conhecido por muita gente, provavelmente protege a maioria das máquinas em circulação. Isso significa que quase todos os dispositivos estão potencialmente vulneráveis ao ataque desenvolvido pelos pesquisadores.
Para burlar a verificação de hash, os pesquisadores simplesmente substituíram o hash de referência armazenado na memória. Na inicialização, o dispositivo calcularia o hash do código alterado, compararia com o valor também alterado e aceitaria o firmware como autêntico.
Os pesquisadores também notaram que modelos com modem celular poderiam ser invadidos remotamente por meio de uma estação falsa, enganando o dispositivo em vez de usar uma torre real. Embora eles não tenham testado a viabilidade desse vetor, ele não parece improvável.
Como a máfia manipulou máquinas DeckMate 2 em jogos de pôquer reais
Dois anos depois, os avisos dos pesquisadores receberam uma confirmação no mundo real. Em outubro de 2025, o Departamento de Justiça dos EUA indiciou 31 pessoas por fraudarem vários jogos de pôquer. De acordo com os documentos do caso, nesses jogos, um grupo criminoso usou vários meios técnicos para obter informações sobre as cartas dos adversários.
Esses meios incluíam cartas com marcações invisíveis detectáveis por telefones, óculos especiais e lentes de contato capazes de ler essas marcas secretamente. Mas, para o contexto desta postagem, o ponto essencial é que os golpistas também invadiram máquinas DeckMate 2, programadas para transmitir secretamente quais cartas seriam distribuídas a cada jogador.
E é aqui que finalmente vamos falar sobre basquete e atletas da NBA. De acordo com a acusação, o esquema envolveu membros de várias famílias da máfia e ex-jogadores da NBA.
A investigação revelou que os golpistas organizaram vários jogos de pôquer de alto risco ao longo de muitos anos em diversas cidades dos EUA. Vítimas ricas foram atraídas pela oportunidade de jogar com estrelas da NBA (que negamqualquer irregularidade). Os investigadores estimam que as vítimas perderam mais de US$ 7 milhões.
Os documentos divulgados contêm um relato minucioso de como os golpistas usaram máquinas DeckMate 2 hackeadas. Em vez de alterar dispositivos DeckMate 2 de terceiros via USB (como demonstrado pelos pesquisadores), os criminosos usaram unidades já hackeadas. Houve até mesmo um caso em que membros da máfia apontaram uma arma para uma pessoa e tomaram seu dispositivo comprometido.
Apesar dessa modificação peculiar, o essencial do ataque seguiu quase igual à prova de conceito dos pesquisadores. As máquinas comprometidas do DeckMate 2 repassaram dados a um operador remoto, que os encaminhou ao telefone de um dos participantes. Os criminosos chamavam esse operador de “quarterback”. O golpista então usava sinais sutis para influenciar o jogo.
O que podemos aprender com essa história
Os fabricantes do DeckMate 2 afirmaram aos jornalistas que, após a pesquisa sobre a vulnerabilidade do dispositivo, implementaram várias alterações no hardware e no software. Essas melhorias incluíram desativar a porta USB exposta e atualizar as rotinas de verificação do firmware. Certamente, os cassinos licenciados já instalaram essas atualizações. Bem, esperamos que sim.
No entanto, a integridade desses dispositivos usados em clubes de pôquer privados e cassinos ilegais segue bastante duvidosa. Esses locais costumam usar máquinas DeckMate 2 usadas sem atualizações ou manutenção, tornando-as mais vulneráveis. E isso sem considerar quando o próprio estabelecimento pode querer manipular as máquinas.
Apesar de todos os detalhes intrigantes do hack do DeckMate 2, os precursores são comuns: senhas reutilizadas, uma porta USB e, claro, jogos não licenciados. A este respeito, o único conselho para entusiastas de jogos é evitar clubes ilegais.
A principal lição desta história é que senhas padrão devem ser trocadas em qualquer dispositivo, seja um roteador Wi-Fi ou um embaralhador de cartas. Para gerar uma senha forte e exclusiva e ser capaz de lembrá-la, use um gerenciador de senhas confiável. A propósito, você também pode usar o Kaspersky Password Manager para gerar códigos de uso único para autenticação em duas etapas.
Neste ano, o Brasil sofreu mais de 315 bilhões de tentativas de ataque cibernético apenas no primeiro semestre — número que representa cerca de 84% de todo o tráfego malicioso registrado na América Latina no período, de acordo com um levantamento da Fortinet divulgado em agosto passado. Com adversários fazendo uso crescente de IA para conduzir campanhas de phishing, ataques DDoS e exploração de vulnerabilidades em ambientes híbridos e multicloud, líderes de segurança corporativa se veem diante de uma encruzilhada: manter o SOC (Security Operations Center) da forma como está ou apostar em novas tecnologias e formas de trabalho que respondam à nova realidade.
Grupos criminosos adotam táticas avançadas e combinam técnicas de Advanced Persistent Threat (APT) com ferramentas de IA para driblar as defesas tradicionais. Golpes que envolvem deepfakes ou phishing automatizado por IA tornam cada vez mais difícil distinguir o legítimo do malicioso. Ao mesmo tempo, a superfície de ataque das organizações se expandiu dramaticamente. Com ambientes de TI híbridos e multicloud, centenas de novos serviços e integrações são adicionados constantemente aos ecossistemas corporativos, abrindo brechas que muitas vezes são difíceis de monitorar.
O problema é que grande parte dos SOCs atuais foi concebida para um contexto em que as ameaças eram baseadas em assinatura e o volume de eventos era controlável. Hoje, porém, a multiplicação de fontes de telemetria, tais como endpoints, nuvens, APIs, identidades, dispositivos IoT e aplicações SaaS, faz com que o volume de logs cresça de forma exponencial.
Não se trata apenas de mais dados, mas de dados de naturezas distintas, com diferentes formatos, níveis de granularidade e relevância operacional. Ferramentas modernas de detecção e monitoramento, como EDRs, XDRs e soluções de observabilidade, coletam informações em tempo real e geram fluxos contínuos de telemetria que precisam ser correlacionados com ameaças conhecidas e comportamentos anômalos. Sem uma arquitetura de dados e automação adequadas, esse ecossistema torna-se difícil de orquestrar – e o SOC passa a lidar menos com ruído e mais com complexidade analítica. O desafio, portanto, deixou de ser filtrar falsos positivos e passou a ser transformar grandes volumes de logs em inteligência acionável com velocidade e contexto.
E, quando os adversários passam a empregar IA para criar malwares praticamente indetectáveis, um SOC calcado apenas em esforço humano não consegue escalar na mesma proporção do risco. O resultado é um descompasso perigoso entre a capacidade defensiva e a velocidade com que as ameaças modernas atuam, evidenciando que manter o status quo não é mais sustentável.
Uma das principais transformações em curso é a adoção do modelo de SOC as a Service, que redefine a forma como as empresas estruturam sua defesa cibernética. Diferente do modelo híbrido ou totalmente interno, o SOCaaS oferece monitoramento, detecção e resposta a incidentes 24×7 por meio de uma plataforma escalável e baseada em nuvem, administrada por especialistas em cibersegurança.
Esse formato elimina a necessidade de manter infraestrutura local pesada e reduz o tempo de implantação, ao mesmo tempo em que garante acesso contínuo a tecnologias e analistas altamente especializados.
Ao integrar telemetria proveniente de múltiplas camadas, o SOC as a Service consolida os eventos em um único datalake de análise, aplicando correlação e contextualização automatizadas com apoio de SOAR e machine learning. Assim, os alertas deixam de ser tratados de forma isolada e passam a compor narrativas completas de ataque, permitindo uma visão tática e antecipada das ameaças.
Essa automação nativa reduz drasticamente o tempo médio de detecção (MTTD) e o tempo médio de resposta (MTTR), pontos críticos para conter ataques modernos que podem se propagar em minutos.
Outro benefício do modelo é a atualização contínua da inteligência de ameaças. Fornecedores de SOCaaS normalmente operam com bases globais de threat intelligence, alimentadas por fontes de ciberinteligência regionais e internacionais.
Essa atualização constante amplia a visibilidade sobre novas campanhas maliciosas, técnicas de exploração e indicadores de comprometimento (IoCs), garantindo que o ambiente corporativo permaneça protegido mesmo diante de vetores inéditos. Ao mesmo tempo, as plataformas de SOCaaS modernas integram recursos de análise comportamental (UEBA) e aprendizado contínuo, permitindo identificar padrões anômalos e prevenir movimentos laterais antes que evoluam para incidentes graves.
Mais do que uma modernização tecnológica, a adoção de modelos de SOC as a Service representa um novo paradigma de defesa cibernética. O CISO que ainda vê o SOC apenas como um centro de monitoramento precisa agora encará-lo como um núcleo de inteligência e antecipação, sustentado por automação, correlação de dados e aprendizado de máquina.
Os ataques de ransomware estão longe de desacelerar. No último ano, foram registradas 11.796 vítimas diretas desse tipo de ciberataque ao redor do mundo, 1,3 vítimas por hora, segundo dados do BTTng da Apura Cyber Intelligence, plataforma de inteligência em ameaças cibernéticas. O impacto vai além dos números: empresas paralisadas, serviços essenciais comprometidos e milhões de pessoas expostas a riscos iminentes.
A onda de ataques abrange qualquer empresa de todos os segmentos, desde a saúde até os serviços públicos. Em maio passado, a Ascension Healthcare, uma das maiores operadoras de saúde dos EUA, foi alvo de um ataque cibernético que comprometeu sistemas críticos, incluindo registros médicos e comunicação interna. Hospitais ficaram sem acesso a informações essenciais por semanas, forçando equipes a recorrerem a procedimentos manuais. “Isso gerou riscos reais, com erros relatados no Kansas e em Detroit, que poderiam ter resultado em graves consequências médicas”, explica Anchises Moraes, Especialista de Theat Intel da Apura.
A Ascension não divulgou oficialmente o grupo por trás do ataque, mas investigações apontam para o Black Basta. Sete dos vinte e cinco mil servidores foram comprometidos, e 5,6 milhões de indivíduos receberam notificações sobre o possível vazamento de dados.
No Brasil, a TOTVS foi alvo do grupo BlackByte, com relatos de que dados da empresa foram acessados. A companhia informou seus acionistas, garantindo a continuidade dos serviços, mas sem dissipar completamente a incerteza. Já a Sabesp sofreu um ataque do grupo RansomHouse, que não apenas roubou dados, mas também os publicou posteriormente.
O futuro dos ataques: alvos menores, impactos maiores
Se antes os criminosos miravam grandes corporações exigindo valores exorbitantes, a tendência é que ataques menores, porém em massa, ganhem força em todo o mundo, incluindo o Brasil. Pequenas e médias empresas se tornaram alvos fáceis, já que possuem menos recursos para segurança e maior propensão a pagar resgates. “Elas têm mais dificuldade em recuperar dados roubados ou encriptados, tornando-se presas ideais para esses criminosos”, alerta Anchises.
Outro ponto crítico é a ascensão da Internet das Coisas (IoT). O crescimento de dispositivos conectados, tanto em ambientes domésticos quanto industriais, expande a superfície de ataque. Botnets formadas por aparelhos desprotegidos alimentam ataques de negação de serviço (DDoS), enquanto falhas em sistemas industriais expõem infraestruturas críticas a riscos catastróficos.
“Quanto mais automatizado, maior a vulnerabilidade. Empresas que adotam tecnologia intensiva, como na Indústria 4.0, precisam investir tanto em proteção cibernética quanto na capacitação de seus colaboradores”, destaca o especialista.
A resposta global? O endurecimento das leis e a repressão ao pagamento de resgates. Nesse ambiente, governos e entidades reguladoras estão apertando o cerco. Leis mais rigorosas para setores críticos, como saúde, finanças e infraestrutura, estão sendo discutidas e aplicadas ao redor do mundo. Penalidades mais severas para empresas que negligenciarem a segurança cibernética também estão no radar.
“Infelizmente, muitas empresas só reagem quando o prejuízo financeiro se torna inegável. Com regulamentação mais dura e multas elevadas, elas serão forçadas a reforçar suas defesas”, conclui.
Outra tendência é o desestímulo ao pagamento de resgates. Algumas legislações já estão sendo elaboradas para coibir essa prática, retirando dos criminosos seu principal incentivo. Fiscalizações mais rigorosas e colaboração internacional também fazem parte do arsenal contra o ransomware.
Merece destaque a ação das forças da lei, que no ano passado foi sentido por grandes grupos de ransomware. Em fevereiro de 2024 foi anunciada a ‘Operação Cronos’ realizada de forma conjunta por agências de segurança de diversos países, incluindo o FBI, a Agência Nacional do Crime (NCA) do Reino Unido e a Europol, com o objetivo de desmantelar as atividades do grupo LockBit, um dos grupos mais ativos até então. Estima-se que o líder do grupo pode ter lucrado, sozinho, cerca de US$100 milhões.
“A guerra contra os cibercriminosos está longe de acabar. Mas empresas, governos e indivíduos precisam agir agora para que a próxima grande vítima não seja apenas mais uma estatística”, sublinha Anchises.
It’s often said online that if a product is free, you’re the product, but what if that bargain was no longer true? What if, depending on the device you paid hard-earned money for, you still became a product yourself, to be measured, anonymized, collated, shared, or sold, often away from view?
In 2024, a consumer rights group out of the UK teased this new reality when it published research into whether people’s air fryers—seriously–might be spying on them.
By analyzing the associated Android apps for three separate air fryer models from three different companies, researchers learned that these kitchen devices didn’t just promise to make crispier mozzarella sticks, crunchier chicken wings, and flakier reheated pastries—they also wanted a lot of user data, from precise location to voice recordings from a user’s phone.
As the researchers wrote:
“In the air fryer category, as well as knowing customers’ precise location, all three products wanted permission to record audio on the user’s phone, for no specified reason.”
Bizarrely, these types of data requests are far from rare.
Today, on the Lock and Code podcast, we revisit a 2024 episode in which host David Ruiz tells three separate stories about consumer devices that somewhat invisibly collected user data and then spread it in unexpected ways. This includes kitchen utilities that sent data to China, a smart ring maker that published de-identified, aggregate data about the stress levels of its users, and a smart vacuum that recorded a sensitive image of a woman that was later shared on Facebook.
These stories aren’t about mass government surveillance, and they’re not about spying, or the targeting of political dissidents. Their intrigue is elsewhere, in how common it is for what we say, where we go, and how we feel, to be collected and analyzed in ways we never anticipated.
It seems like every manufacturer of anything electrical that goes in the house wants to be part of the IoT story these days. Further, they all want their own app, which means you have to go to gazillions of bespoke software products to control your things. And they're all - with very few exceptions - terrible:
That's to control the curtains in my office and the master bedroom, but the hubs (you need two, because the range is rubbish) have stopped communicating.
That one is for the spa, but it looks like the service it's meant to authenticate to has disappeared, so now, you can't.
And my most recent favourite, Advantage Air, which controls the many tens of thousands of dollars' worth of air conditioning we've just put in. Yes, I'm on the same network, and yes, the touch screen has power and is connected to the network. I know that because it looks like this:
That might look like I took the photo in 2013, but no, that's the current generation app, complete with Android tablet now fixed to the wall. Fortunately, I can gleefully ignore it as all the entities are now exposed in Home Assistant (HA), then persisted into Apple Home via HomeKit Bridge, where they appear on our iThings. (Which also means I can replace that tablet with a nice iPad Mini running Apple Home and put the Android into the server rack, where it still needs to act as the controller for the system.)
Anyway, the point is that when you go all in on IoT, you're dealing with a lot of rubbish apps all doing pretty basic stuff: turn things on, turn things off, close things, etc. HA is great as it abstracts away the crappy apps, and now, it also does something much, much cooler than just all this basic functionality...
Start by thinking of the whole IoT ecosystem as simply being triggers and actions. Triggers can be based on explicit activities (such as pushing a button), observable conditions (such as the temperature in a room), schedules, events and a range of other things that can be used to kick off an action. The actions then include closing a garage door, playing an audible announcement on a speaker, pushing an alert to a mobile device and like triggers, many other things as well. That's the obvious stuff, but you can get really creative when you start considering devices like this:
That's a Sonoff IoT water valve, and yes, it has its own app 🤦♂️ But because it's Zigbee-based, it's very easy to incorporate it into HA, which means now, the swag of "actions" at my disposal includes turning on a hose. Cool, but boring if you're just watering the garden. Let's do something more interesting instead:
The valve is inline with the hose which is pointing upwards, right above the wall that faces the road and has one of these mounted on it:
That's a Ubiquiti G4 Pro doorbell (full disclosure: Ubiquiti has sent me all the gear I'm using in this post), and to extend the nomenclature used earlier, it has many different events that HA can use as triggers, including a press of the button. Tie it all together and you get this:
Not only does a press of the doorbell trigger the hose on Halloween, it also triggers Lenny Troll, who's a bit hard to hear, so you gotta lean in real close 🤣 C'mon, they offered "trick" as one of the options!
Enough mucking around, let's get to the serious bits and per the title, the AI components. I was reading through the new features of HA 2025.8 (they do a monthly release in this form), and thought the chicken counter example was pretty awesome. Counting the number of chickens in the coop is a hard problem to solve with traditional sensors, but if you've got a camera that take a decent photo and an AI service to interpret it, suddenly you have some cool options. Which got me thinking about my rubbish bins:
The red one has to go out on the road by about 07:00 every Tuesday (that's general rubbish), and the yellow one has to go out every other Tuesday (that's recycling). Sometimes, we only remember at the last moment and other times, we remember right as the garbage truck passes by, potentially meaning another fortnight of overstuffing the bin. But I already had a Ubiquiti G6 Bullet pointing at that side of the house (with a privacy blackout configured to avoid recording the neighbours), so now it just takes a simple automation:
- id: bin_presence_check
alias: Bin presence check
mode: single
trigger:
- platform: state
entity_id: binary_sensor.laundry_side_motion
to: "off"
for:
minutes: 1
condition:
- condition: time
weekday:
- mon
- tue
action:
- service: ai_task.generate_data
data:
task_name: Bin presence check
instructions: >-
Look at the image and answer ONLY in JSON with EXACTLY these keys:
- bin_yellow_present: true if a rubbish bin with a yellow lid is visible, else false
- bin_red_present: true if a rubbish bin with a red lid is visible, else false
Do not include any other keys or text.
structure:
bin_yellow_present:
selector:
boolean:
bin_red_present:
selector:
boolean:
attachments:
media_content_id: media-source://camera/camera.laundry_side_medium
media_content_type: image/jpeg
response_variable: result
- service: "input_boolean.turn_{{ 'on' if result.data.bin_yellow_present else 'off' }}"
target:
entity_id: input_boolean.yellow_bin_present
- service: "input_boolean.turn_{{ 'on' if result.data.bin_red_present else 'off' }}"
target:
entity_id: input_boolean.red_bin_present
Ok, so it's a 40-line automation, but it's also pretty human-readable:
When there's motion that's stopped for a minute...
And it's a Monday or Tuesday...
Create an AI task that requests a JSON response indicating the presence of the yellow and red bin...
And attach a snapshot of the camera that's pointing at them...
Then set the values of two input booleans
From that, I can then create an alert if the correct bin is still present when it should be out on the road. Amazing! I'd always wanted to do something to this effect but had assumed it would involve sensors on the bins themselves. Not with AI though 😊
And then I started getting carried away. I already had a Ubiquiti AI LPR (that's a "license plate reader") camera on the driveway and it just happened to be pointing towards the letter box. Now, I've had Zigbee-based Aqara door and window sensors (they're effectively reed switches) on the letter box for ages now (one for where the letters go in, and one for the packages), and they announce the presence of mail via the in-ceiling Sonos speakers in the house. This is genuinely useful, and now, it's even better:
I screen-capped that on my Apple Watch whilst I was out shopping, and even though it was hard to make out the tiny picture on my wrist, I had no trouble reading the content of the alert. Here's how it works:
- id: letterbox_and_package_alert
alias: Letterbox/Package alerts
mode: single
trigger:
- id: letter
platform: state
entity_id: binary_sensor.letterbox
to: "on"
- id: package
platform: state
entity_id: binary_sensor.package_box
to: "on"
variables:
event: "{{ trigger.id }}" # "letter" or "package"
title: >-
{{ "You've got mail" if event == "letter" else "Package delivery" }}
message: >-
{{ "Someone just left you a letter" if event == "letter" else "Someone just dropped a package" }}
tts_message: >-
{{ "You've got mail" if event == "letter" else "You've got a package" }}
file_prefix: "{{ 'letterbox' if event == 'letter' else 'package_box' }}"
file_name: "{{ file_prefix }}_{{ now().strftime('%Y%m%d_%H%M%S') }}"
snapshot_path: "/config/www/snapshots/{{ file_name }}.jpg"
snapshot_url: "/local/snapshots/{{ file_name }}.jpg"
action:
- service: camera.snapshot
target:
entity_id: camera.driveway_medium
data:
filename: "{{ snapshot_path }}"
- service: script.hunt_tts
data:
message: "{{ tts_message }}"
- service: ai_task.generate_data
data:
task_name: "Mailbox person/vehicle description"
instructions: >-
Look at the image and briefly describe any person
and/or vehicle standing near the mailbox. They must
be immediately next to the mailbox, and describe
what they look like and what they're wearing.
Keep it under 20 words.
attachments:
media_content_id: media-source://camera/camera.driveway_medium
media_content_type: image/jpeg
response_variable: description
- service: notify.adult_iphones
data:
title: "{{ title }}"
message: "{{ (description | default({})).data | default('no description') }}"
data:
image: "{{ snapshot_url }}"
This is really helpful for figuring out which of the endless deliveries we seem to get are worth "downing tools" for and going out to retrieve mail. Equally useful is the most recent use of an AI task, recorded just today (and shared with the subject's permission):
Like packages, we seem to receive endless visitors and getting an idea of who's at the door before going anywhere near it is pretty handy. We do get video on phone (and, as you can see, iPad), but that's not necessarily always at hand, and this way the kids have an idea of who it is too. Here's the code (it's a separate automation that plays the doorbell chime):
- id: doorbell_ring_play_ai
alias: The doorbell is ringing, use AI to describe the person
trigger:
platform: state
entity_id: binary_sensor.doorbell_ring
to: 'on'
action:
- service: ai_task.generate_data
data:
task_name: "Doorbell visitor description"
instructions: >-
Look at the image and briefly describe how many people you see and what they're wearing, but don't refer to "the image" in your response.
If they're carrying something, also explain that but don't mention it if they're not.
If you can recognise what job they might, please include this information too, but don't mention it if you don't know.
If you can tell their gender or if they're a child, mention that too.
Don't tell me anything you don't know, only what you do know.
This will be broadcast inside a house so should be conversational, preferably summarised into a single sentence.
attachments:
media_content_id: media-source://camera/camera.doorbell
media_content_type: image/jpeg
response_variable: description
- service: script.hunt_tts
data:
message: "{{ (description | default({})).data | default('I have no idea who is at the door') }}"
I've been gradually refining that prompt, and it's doing a pretty good job of it at the moment. Hear how the response noted his involvement in "detailing"? That's because the company logo on his shirt includes the word, and indeed, he was here to detail the cars.
This is all nerdy goodness that has blown hours of my time for what, on the surface, seems trivial. But it's by playing with technologies like this and finding unusual use cases for them that we end up building things of far greater significance. To bring it back to my opening point, IoT is starting to go well beyond the rubbish apps at the start of this post, and we'll soon be seeing genuinely useful, life-improving implementations. Bring on more AI-powered goodness for Halloween 2025!
Edit: I should have included this in the original article, but the ai_task service is using OpenAI so all processing is done in the cloud, not locally on HA. That requires and API key and payment, although I reckon that pricing is pretty reasonable (and the vast majority of those requests are from testing):
Entrar
