Root shell na Samsung TV: o que isso tem a ver com Bun

Tem um print rodando por aí de um terminal com # no prompt, e o aparelho do outro lado é uma televisão. O post original mostra um root shell na Samsung TV, ou seja, acesso total ao sistema operacional da TV da sala. Não é o app da Netflix nem o menu de configurações. É o Linux que fica embaixo de tudo isso, com permissão para mexer em qualquer coisa.

Assim que vi, pensei duas coisas. A primeira foi: "isso é um problema de segurança gigante". A segunda, como todo dev JavaScript com problema: "será que roda Bun?"

Vou falar das duas.

O que significa ter root shell na Samsung TV

As TVs da Samsung rodam Tizen, um sistema baseado em Linux. Por cima dele fica a interface que você conhece, a loja de apps e os serviços da própria Samsung. Por baixo tem kernel, processos, sistema de arquivos e rede, como em qualquer servidor.

Um shell comum já permite rodar comandos. Um shell root permite rodar qualquer comando, como o usuário com mais poder do sistema. Na prática, quem tem esse acesso consegue:

• ler e alterar arquivos do sistema, inclusive os que a fabricante protege;
• ver o que trafega na rede da TV;
• instalar e executar binários que nunca passaram pela loja oficial;
• deixar um processo rodando em segundo plano para sempre.

Não vou entrar em como o acesso foi obtido. Primeiro porque o detalhe técnico é do autor e quem quiser deve ler na fonte. Segundo porque um passo a passo de exploit não é o que esse blog faz. O que me interessa é o que isso mostra para quem escreve software.

Por que isso importa para quem não é pesquisador de segurança

Você provavelmente não vai fazer jailbreak na sua TV hoje à noite. Mesmo assim, essa notícia diz respeito ao seu trabalho.

Uma TV smart é um computador Linux ligado 24 horas por dia, conectado à sua rede doméstica, com microfone em alguns modelos e atualização controlada por uma empresa que vai parar de dar suporte daqui a alguns anos. Agora pense em quantos desses existem na mesma rede que o seu notebook de trabalho.

Todo dispositivo "inteligente" é um servidor Linux que você não administra.

Essa é a parte que incomoda. No seu servidor você controla a versão do kernel, as portas abertas e os pacotes instalados. Na TV você não controla nada. Você confia que a fabricante fez direito e vai continuar fazendo. Quando aparece um root shell público, essa confiança leva um soco.

Para quem desenvolve, ficam três lições:

1. A rede local não é zona segura. Se sua API de desenvolvimento escuta em 0.0.0.0 sem autenticação "porque é só na minha rede", qualquer aparelho comprometido nessa rede consegue chamar ela.
2. Firmware velho é dívida técnica de outra pessoa que cai no seu colo. O mesmo vale para a imagem Docker que você não atualiza desde 2023.
3. Atualização automática é recurso de segurança. Odiar update que reinicia a TV é normal. Desligar update é pior.

O primeiro ponto é o mais fácil de corrigir hoje. No Bun, por exemplo:

Bun.serve({
  hostname: "127.0.0.1", // só a sua máquina enxerga
  port: 3000,
  fetch: () => new Response("ok"),
});

Uma linha muda quem consegue falar com o seu servidor.

E onde o Bun entra nessa história

Agora a parte divertida. Imagine que a TV é sua, o acesso é seu e você quer rodar código seu nela. Um dashboard da casa, um bot que desliga a TV quando passa da meia-noite, um servidor que expõe métricas. Qualquer coisa.

O caminho clássico seria compilar C para a arquitetura da TV. Funciona, mas dá trabalho: toolchain cruzada, bibliotecas, linkagem. Para quem vive de TypeScript, o Bun oferece um atalho bem interessante: o bun build --compile.

Esse comando pega o seu código, junta com o runtime do Bun e gera um único executável. Sem node_modules, sem instalar nada no destino. E dá para gerar esse binário para outra arquitetura direto do seu notebook:

bun build ./tv.ts --compile --target=bun-linux-arm64 --outfile tv-server

Depois é copiar o arquivo e rodar. Nada de npm install num aparelho com pouco espaço e sem gerenciador de pacotes.

O tv.ts pode ser bem simples:

import { cpus, freemem, uptime } from "node:os";

Bun.serve({
  hostname: "127.0.0.1",
  port: 8080,
  fetch() {
    return Response.json({
      cpus: cpus().length,
      freeMB: Math.round(freemem() / 1024 / 1024),
      uptimeH: Math.round(uptime() / 3600),
    });
  },
});

Como o Bun implementa boa parte das APIs do Node, os módulos node:os, node:fs e node:child_process funcionam como você espera. Você escreve o mesmo TypeScript de sempre e roda num aparelho que, há dez minutos, era só uma tela.

Os limites reais (antes que você tente)

Aqui entra a parte honesta, porque o print bonito esconde os detalhes chatos.

Arquitetura. O Bun gera binários para Linux x64 e arm64, com variantes para glibc e musl. Ele não tem suporte oficial para ARM de 32 bits. Muita TV tem processador ARM de 64 bits mas roda o sistema em 32 bits, e aí o binário simplesmente não executa. Antes de qualquer coisa, rode isto no shell da TV:

uname -m

Se aparecer aarch64, tem chance. Se aparecer armv7l, esquece o Bun e vai de C, Go ou Rust.

Tamanho. Um executável compilado com Bun passa fácil de 50 MB, porque o runtime inteiro vai junto. No seu SSD isso é nada. Numa TV com armazenamento interno apertado e partições somente leitura, pode ser o fim da linha. Um binário em Go faria o mesmo trabalho com uma fração disso.

Memória. JavaScriptCore é eficiente, mas não é mágica. TV já usa boa parte da RAM para decodificar vídeo. Seu servidorzinho vai disputar memória com o player, e o sistema pode matar o processo quando apertar.

Persistência. Root shell não garante que seu processo sobreviva a um reboot ou a uma atualização. Muitas vezes a próxima atualização de firmware fecha a falha e apaga o que você instalou. Ou seja, o acesso dura até a Samsung lançar um patch.

Minha opinião forte aqui: Bun numa TV é um ótimo experimento e uma péssima arquitetura. Para hackear no fim de semana, a velocidade de ir de "tenho uma ideia" até "está rodando" é imbatível. Para algo que precisa ficar de pé por meses num dispositivo limitado, uma linguagem que gera binário pequeno e nativo é a escolha certa.

O que fazer se você ficou curioso

Se a notícia te deu vontade de mexer, algumas regras simples:

• Só no seu aparelho. Acessar o dispositivo de outra pessoa sem autorização é crime, não pesquisa.
• Espere a garantia acabar, ou aceite perder ela. Root costuma anular garantia, e a fabricante não vai ter pena.
• Nunca exponha o que você rodar para a internet. Uma TV com root e uma porta aberta para fora vira o aparelho mais fácil de invadir da sua casa.
• Leia a fonte original e acompanhe se a Samsung vai responder com patch. Esse tipo de descoberta normalmente segue um ciclo: divulgação, correção, e depois os detalhes técnicos completos.

Se você não quer mexer em nada, a ação útil é outra: confira se a sua TV está com a atualização automática ligada. É chato, mas é a única defesa que você tem num aparelho que não administra.

Minha leitura

O que mais me chama atenção nessa história é como a distância entre "eletrodoméstico" e "servidor" sumiu. Sua TV, sua geladeira e seu roteador rodam a mesma base de software dos servidores que você faz deploy. E o mesmo TypeScript que você escreve para uma API consegue, com um comando, virar um executável dentro de um deles.

Isso é poderoso e assustador na mesma medida. Para quem desenvolve, a lição prática é tratar a rede local com a mesma desconfiança que a internet, e lembrar que ferramentas como o Bun deixaram muito fácil levar código para lugares onde antes só C entrava. Use isso para construir coisas legais no hardware que é seu.

Eu já tenho uma TV velha guardada esperando um fim de semana livre. Se virar projeto, vai aparecer junto com os outros.

Vi um root shell rodando numa Samsung TV e minha primeira reação foi: será que roda Bun?

A segunda foi mais séria. Toda TV smart é um servidor Linux ligado 24h na sua rede, e quem administra ele não é você.

Por isso sua API de dev escutando em 0.0.0.0 "porque é só na rede de casa" é um risco real. Uma linha com hostname 127.0.0.1 já resolve.

E sim, dá para levar TypeScript até lá com bun build --compile. Funciona bem como experimento de fim de semana, mas como arquitetura é péssimo: binário de 50 MB, RAM disputada com o player de vídeo e nada de ARM 32 bits.

Escrevi sobre os limites reais e o que essa história ensina para quem desenvolve. O link está nos comentários.

#Bun #TypeScript #SegurançaDaInformação #IoT #Linux