Do monorepo de IA ao reconnaissance com Google dorking: troubleshooting real no lab Linux

Montar ambientes de desenvolvimento e ferramentas de segurança no Linux é uma daquelas tarefas em que o primeiro contato com o terminal sempre traz surpresas. Recentemente, passei por duas rodadas completas de troubleshooting na minha máquina com CachyOS e dentro de containers Docker de teste.

A primeira missão foi colocar de pé a interface e os modelos de um ecossistema complexo de IA local em monorepo (o projeto AIRI); a segunda foi configurar uma esteira de OSINT automatizada com busca via Google Dorking programável.

Abaixo, compartilho o diário de bordo com as falhas enfrentadas, a análise dos logs e os contornos práticos que resolveram os problemas.

Parte 1: Domando monorepos Node.js e conflitos de runtime no CachyOS#

O objetivo inicial era rodar localmente o projeto AIRI, uma stack de IA com suporte a avatares e processamento de áudio/visão. O repositório depende de um monorepo extenso com dezenas de workspaces gerenciados via pnpm.

1. O conflito entre versões do pnpm e o FNM#

Ao tentar executar a instalação com npx pnpm install, o corepack solicitou o download do pnpm-10.33.0. Ao verificar os caminhos do binário com which -a pnpm, percebi a coexistência de instâncias:

/run/user/1000/fnm_multishells/44696_1784149451542/bin/pnpm
/usr/bin/pnpm
/bin/pnpm

No CachyOS / Arch, os binários instalados via gerenciador de pacotes do sistema em /usr/bin amarram a execução ao Node do sistema. Ao tentar rodar pnpm install ou pnpm dev logo em seguida, o processo travou de forma silenciosa no terminal.

2. O erro EUNSUPPORTEDPROTOCOL com catálogos#

Na tentativa de contornar o travamento utilizando o cliente clássico npm install, a execução abortou imediatamente:

npm error code EUNSUPPORTEDPROTOCOL
npm error Unsupported URL Type "catalog:": catalog:

Diagnóstico: O monorepo utiliza o recurso de pnpm Catalogs (catalog:), introduzido para centralizar versões de dependências em monorepos. O npm tradicional não reconhece esse protocolo, tornando o uso do pnpm estritamente obrigatório.

3. A solução com npx pnpm@latest e o gargalo do onnxruntime-node#

Para ignorar qualquer inconsistência de links simbólicos ou wrappers de ambiente, forcei o uso do binário limpo diretamente via NPX:

npx pnpm@latest install

O download de pacotes pesados de Machine Learning e visão computacional iniciou normalmente, totalizando mais de 2.700 dependências. No entanto, o script de pós-instalação quebrou com ELIFECYCLE:

node_modules/.pnpm/onnxruntime-node@1.21.0/node_modules/onnxruntime-node: Running postinstall script, failed in 183ms
.../node_modules/onnxruntime-node postinstall$ node ./script/install
│ Failed to detect CUDA version from `nvcc --version`: Unsupported CUDA version: 13
│ AggregateError [ECONNREFUSED]:
│     Error: connect ECONNREFUSED ::1:443
│     Error: connect ECONNREFUSED 127.0.0.1:443

Diagnóstico: O script de build do onnxruntime-node tentou compilar binários com suporte a GPU, mas não reconheceu a versão do CUDA (versão 13) e tentou conexões de rede locais que foram recusadas.

4. Bypass de scripts e compilação dos workspaces internos#

Para contornar o script com falha e estruturar a árvore de dependências, usei a flag --ignore-scripts:

npx pnpm@latest install --ignore-scripts

A instalação concluiu em segundos. Ao rodar npx pnpm@latest dev, o Vite iniciou mas disparou alertas de resolução de módulos:

(!) Failed to run dependency scan. Skipping dependency pre-bundling. Error: The following dependencies are imported but could not be resolved:
  @proj-airi/font-cjkfonts-allseto/index.css
  @proj-airi/core-agent
  @proj-airi/stream-kit
  @proj-airi/server-shared/types

Diagnóstico: Como pulei os scripts de build globais na instalação, os pacotes internos do próprio monorepo ainda não haviam gerado suas saídas em /dist.

A sequência funcional definitiva para colocar a stack de pé foi:

# 1. Compila os pacotes e tipagens internas do monorepo na ordem correta
npx pnpm@latest build

# 2. Inicia o servidor web de desenvolvimento
npx pnpm@latest dev

Parte 2: Trufflehog e resolução de escopo de volumes em Docker#

Em paralelo, estruturei um fluxo de auditoria de credenciais com o TruffleHog, executando a ferramenta dentro de um container Docker do Kali Linux para analisar repositórios locais.

Ao rodar a verificação de sistema de arquivos:

trufflehog filesystem /root/shared/airi

O comando retornou erro de arquivo não encontrado:

error   trufflehog   encountered errors during scan   {"job": 1, "source_name": "trufflehog - filesystem", "errors": ["lstat /root/shared/airi: no such file or directory"]}

Diagnóstico: O alias de inicialização do container montava no volume /root/shared o diretório atual do host (red-lab/kalilinux). Como o projeto alvo estava em outra pasta (ia-lab/airi), o container não tinha visibilidade do caminho.

Correção: Duas abordagens resolveram o isolamento:

1. Navegar diretamente até o diretório do projeto no host antes de instanciar o container para que o volume seja montado sobre o alvo correto.
2. Criar um link simbólico no host conectando as pastas compartilhadas:

ln -s /home/user/labs/ia-lab/airi /home/user/labs/red-lab/kalilinux/airi

Parte 3: Automação de OSINT com googledorker e Google custom search API#

Para a fase de reconhecimento passivo, integrei a ferramenta GoogleDorker (RevoltSecurities) ao ambiente virtual em Python dentro do Kali.

1. Instalação e estrutura do pacote#

Ao clonar o repositório, o script raiz não era executável direto via python3 googledorker.py. Tratava-se de um pacote Python estruturado com setup.py. A instalação correta dentro do venv exigiu:

# Dentro do ambiente virtual ativo
pip install .

Isso registrou o comando de console global dorker.

2. O erro de credenciais ausentes da API#

Ao tentar disparar uma busca inicial com dorker -q "site:meudominio.com filetype:sql", a ferramenta falhou:

[version]: dorker current version v1.0.1 (latest)
[ERR]: Exception occured in the Keyreader module due to: Cannot choose from an empty sequence,
[ERR]: Exception occured in the google search request module due to: cannot unpack non-iterable NoneType object

Diagnóstico: O GoogleDorker utiliza a API oficial de Pesquisa Personalizada do Google para contornar bloqueios e CAPTCHAs, exigindo credenciais válidas configuradas no arquivo ~/.config/dorker/provider-config.yaml.

3. A armadilha do Search Engine ID (CX ID)#

No console do Google Programmable Search Engine, a opção antiga de "pesquisar em toda a web" não está mais disponível por padrão para novos buscadores gratuitos, e o uso de curingas como :///* é rejeitado.

O contorno funcional validado para permitir escopo amplo foi configurar padrões estruturados:

• www.google.com/*
• .google.com/

Com isso, a plataforma gerou com sucesso o ID do mecanismo de pesquisa (CX ID).

4. Provisionamento da API key no Google Cloud Console#

Para obter a credencial de acesso:

1. Acesse o projeto no Google Cloud Console.
2. Ative explicitamente a Custom Search API (se ela não estiver habilitada, o seletor de restrição de chave exibirá a mensagem "No items to display").
3. Em APIs e Serviços > Credenciais, crie uma nova Chave de API e restrinja seu escopo exclusivamente à Custom Search API.
4. Preencha o arquivo de configuração dentro do container:

# Arquivo: ~/.config/dorker/provider-config.yaml
google:
  - api_key: "AIzaSy..."
    cx: "1074f00b491db440b"

Com o arquivo populado, o dorker passou a executar as consultas contra as APIs programáveis sem bloqueios de rede ou exceções de runtime.

Conclusão: lições práticas para o laboratório#

Seja lidando com monorepos de front/AI no Arch Linux ou configurando ferramentas de reconhecimento em containers, o segredo está em entender o que acontece por baixo do capô: protocolos de package managers (como o catalog: do pnpm), mapeamento correto de volumes no Docker e as regras de autorização de APIs externas do Google Cloud.

Veja também

Cibersegurança Troubleshooting real: do crash status 255 no Fail2ban ao backend systemd e modularização no Nginx

Cibersegurança Anatomia de um incidente: mitigando ataques L7 simultâneos, dos no Dovecot e gargalos de CPU

Cibersegurança Análise forense de um comprometimento no CloudLinux e cPanel: da armadilha do sshd_config à persistência no PAM e IPMI

Este post está licenciado sob CC BY-NC.