burrowers/garbleOfusca builds Go envolvendo o toolchain Go, substituindo identificadores, caminhos de pacotes e dados de posição por hashes e removendo informações de debug e de build.
go install mvdan.cc/garble@latest # or @master
Ofusque o código Go envolvendo a toolchain do Go. Requer Go 1.27 ou posterior.
garble build [build flags] [packages]
A ferramenta também suporta garble test para executar testes com código ofuscado,
garble run para ofuscar e executar programas simples,
garble reverse para desofuscar texto, como stack traces,
e garble bug para registrar um relatório de bug pré-preenchido.
Execute garble -h para ver todos os comandos e flags disponíveis.
Produzir um binário que funcione tão bem quanto uma build normal, mas que tenha o mínimo de informação possível sobre o código-fonte original.
A ferramenta foi projetada para ser:
cmd/go, para suportar módulos e cache de buildA ferramenta envolve chamadas ao compilador e linker do Go para transformar a build do Go, a fim de:
-literals for fornecida-tiny for fornecidaA ferramenta ofusca todos os pacotes suportados que estão sendo compilados, incluindo o runtime padrão.
Os pacotes não suportados runtime/cgo e crypto/internal/fips140 são excluídos.
A ofuscação do runtime segue os alvos GOOS/GOARCH suportados pelo Go; o Garble não
mantém uma lista de arquiteturas permitidas mais restrita.
Observe que comandos como garble build usarão a versão do go encontrada no seu
$PATH. Para usar versões diferentes do Go, você pode usar GOTOOLCHAIN.
Uma pergunta comum é por que um ofuscador de código é necessário para Go, uma linguagem compilada. Binários Go incluem uma quantidade surpreendente de informações sobre o código-fonte original; mesmo com informações de debug e tabelas de símbolos removidas, muitos nomes e posições permanecem no lugar por causa de traces, reflexão e depuração.
Alguns casos de uso para Go exigem compartilhar um binário Go com o usuário final. Se o código-fonte do binário é privado ou requer compra, sua ofuscação pode ajudar a desencorajar engenharia reversa.
Um caso de uso semelhante é uma biblioteca Go cujo código-fonte é privado ou comprado. Como bibliotecas Go não podem ser importadas em forma binária, e plugins Go têm suas deficiências, compartilhar código-fonte ofuscado torna-se uma opção. Veja #369.
A ofuscação também pode ajudar com aspectos totalmente não relacionados a licenciamento.
Por exemplo, a flag -tiny pode tornar os binários 15% menores,
semelhante à prática comum no Android para reduzir o tamanho dos apps.
A ofuscação também ajudou alguns desenvolvedores de código aberto a contornar
verificações antivírus que tratavam incorretamente binários Go como malware.
Usar a flag -literals faz com que expressões literais, como strings, sejam
substituídas por expressões mais complexas, que resultam no mesmo valor em tempo de execução.
Literais de string injetados via -ldflags=-X também são substituídos por essa flag.
Esse recurso é opt-in, pois pode causar lentidão dependendo do código de entrada.
Literais usados em expressões constantes não podem ser ofuscados, pois são
resolvidos em tempo de compilação. Isso inclui quaisquer expressões que fazem parte de uma
declaração const, por exemplo.
Observe que esse processo pode ser revertido com esforço suficiente; veja #984.
Com a flag -tiny, ainda mais informações são removidas do binário Go.
As informações de posição são removidas completamente, em vez de serem ofuscadas.
Código de runtime que imprime panics, erros fatais e informações de trace/debug é removido.
Muitos nomes de símbolos também são omitidos das seções do binário em tempo de link.
No geral, isso pode tornar os binários cerca de 15% menores.
Com essa flag, nenhum panic ou erro fatal de runtime será impresso, mas eles
ainda podem ser tratados internamente com recover normalmente.
Observe que essa flag pode dificultar a depuração de crashes, pois um panic simplesmente
encerrará todo o programa sem imprimir um stack trace, e posições do código-fonte
e muitos nomes são removidos.
Da mesma forma, garble reverse geralmente não é útil nesse modo.
Veja: CONTROLFLOW.md
garble build deve levar cerca de duas vezes mais tempo que go build, pois precisa
completar duas builds. A build original, para poder carregar e verificar tipos do
código de entrada, e depois a build ofuscada.
O Garble ofusca um pacote por vez, espelhando como o Go compila um pacote
por vez. Isso permite que o Garble suporte totalmente o cache de build do Go; chamadas
incrementais de garble build devem apenas reconstruir e reofuscar o código modificado.
Observe que a primeira chamada a garble build pode ser comparativamente lenta,
pois precisa ofuscar cada pacote pela primeira vez. Isso é semelhante a limpar
GOCACHE com go clean -cache e executar um go build do zero.
O Garble também usa seu próprio cache para reutilizar trabalho, semelhante ao GOCACHE do Go.
Ele usa por padrão um diretório sob o diretório de cache do seu usuário,
como ~/.cache/garble, e pode ser colocado em outro lugar definindo GARBLE_CACHE.
Assim como o Go, as builds do garble são determinísticas e reproduzíveis por natureza.
Isso traz benefícios significativos, como cachear builds e poder usar
garble reverse para desofuscar stack traces.
Por padrão, o garble ofuscará cada pacote de uma forma única, que mudará se sua entrada de build mudar: a versão do garble, a versão do Go, o código-fonte do pacote ou qualquer parâmetro de build como GOOS ou -tags. Esse é um padrão razoável, já que adivinhar essas entradas é muito difícil.
Você pode usar a flag -seed para fornecer sua própria seed de aleatoriedade de ofuscação.
Reutilizar a mesma seed pode ajudar a produzir a mesma ofuscação de código,
o que pode ajudar ao depurar ou reproduzir problemas.
Rotacionar regularmente a seed também pode ajudar contra engenharia reversa no longo prazo,
pois, caso contrário, pode-se observar mudanças em como a biblioteca padrão do Go é ofuscada
para adivinhar quando as versões do Go ou do garble foram alteradas ao longo de uma série de builds.
Para sempre usar uma seed diferente em cada build, use -seed=random.
Observe que cuidados extras devem ser tomados ao usar seeds personalizadas:
se um valor de -seed usado em uma build for perdido, garble reverse não funcionará.
A maioria delas pode melhorar com tempo e esforço. O propósito desta seção é documentar as deficiências atuais desta ferramenta.
Métodos exportados nunca são ofuscados no momento, pois podem ser exigidos por interfaces. Esta área é um trabalho em andamento; veja #3.
Não há forma suportada de excluir a ofuscação de uma seleção de arquivos ou pacotes. Na maioria das vezes, um usuário gostaria de fazer isso para contornar um bug; por favor, registre o bug em vez disso.