# Auditoria técnica do firmware H2O Ultra DI v2.1.1

## Escopo

A revisão abrangeu inicialização, máquina de estados, segurança, persistência, perfis, componentes, rede local, autenticação, OTA, sensores, atuadores, automação e frontend embarcado.

## Resumo executivo

A base atual é adequada para prototipagem avançada e ensaios de bancada, mas ainda não deve ser tratada como uma plataforma comercial multi-hardware ou como uma Controller pronta para gestão remota irrestrita. O inventário de componentes é parametrizável, porém o caminho operacional crítico continua preso a GPIOs fixos e classes específicas. A próxima versão deve separar identidade, hardware, processo, segurança e comunicação remota em domínios independentes.

## Achados críticos

### 1. Credenciais padrão e Access Point conhecido

`admin/admin`, senha fixa do AP e fallback aberto permanecem compilados no firmware. O fallback aberto é útil em recuperação, mas cria uma superfície de ataque inadequada para produto comercial.

**Correção:** senha técnica obrigatória no primeiro acesso, senha de AP derivada por unidade, fallback aberto somente por ação física local e janela temporária.

### 2. Senha administrativa armazenada em texto simples

A senha é persistida diretamente na NVS. Uma leitura física da flash ou um dump de manutenção pode expor a credencial.

**Correção:** armazenar hash com salt por dispositivo; proteger segredos de nuvem com NVS Encryption ou chave vinculada ao chip.

### 3. CSRF incompleto

O `SessionManager` gera token CSRF, mas as rotas mutáveis não o verificam. Uma sessão autenticada no navegador pode ser induzida a enviar comandos por outra página.

**Correção:** exigir `X-CSRF-Token` em toda rota POST/PUT/PATCH/DELETE e validar `Origin`/`Host`.

### 4. OTA sem assinatura e sem compatibilidade de hardware

O upload aceita um binário autenticado por sessão, mas não valida assinatura digital, família de hardware, revisão mínima, versão ou política de downgrade.

**Correção:** manifesto de firmware assinado, Secure Boot quando viável, hash SHA-256, hardware target, rollback e confirmação de boot saudável.

### 5. Arquitetura multi-hardware ainda inexistente no núcleo

`Config.h`, `Sensors` e `Actuators` usam GPIOs e funções fixas. O componente cadastrado no frontend não é a fonte de verdade da máquina de estados.

**Risco:** uma interface pode indicar um mapeamento, enquanto o controle real usa outro.

**Correção:** introduzir `HardwareManifest`, `HardwareAbstraction`, `SignalRegistry` e `ProcessBinding` versionados.

## Achados altos

### 6. Autoteste não valida hardware

A máquina de estados transita de `SELF_TEST` para `IDLE` imediatamente. Não existe resultado de autoteste impeditivo para ADC, entradas críticas, drivers, armazenamento ou perfil.

### 7. Segurança não considera validade de cada medição

Pressão e condutividade são avaliadas por valor, mas o núcleo não exige explicitamente `online`, idade máxima da amostra, CRC ou qualidade do canal antes de iniciar produção.

### 8. Fallback analógico pode mudar silenciosamente a cadeia metrológica

Quando o ADS1115 falha, o sistema usa ADC interno. Isso altera resolução, referência, faixa e ruído sem bloquear produção.

**Correção:** fallback configurável por hardware; para versões comerciais, falha do ADC principal deve impedir partida até validação técnica.

### 9. Perfis exportam estruturas binárias dependentes de ABI

O pacote usa `sizeof(ComponentConfig)` e cópia binária direta. Mudanças de compilador, alinhamento ou struct podem quebrar compatibilidade futura.

**Correção:** formato canônico CBOR/JSON versionado por campos, com migração explícita.

### 10. Configurações gerais não possuem dual-slot e readback equivalente ao inventário

O inventário foi endurecido, mas as configurações principais ainda são gravadas chave a chave. Uma perda de energia pode deixar revisão parcialmente aplicada.

**Correção:** snapshot transacional A/B com CRC e marcador ativo.

### 11. Comandos HMI e locais não possuem identidade/idempotência uniforme

O protocolo serial possui ACK, mas os caminhos local, HMI e remoto ainda não compartilham um envelope único de comando.

### 12. Ausência de fila offline de telemetria

Sem internet, a futura integração perderia amostras. É necessário buffer circular persistente com limite de desgaste da flash.

## Achados médios

- Sessão única em RAM e bloqueio de login global, não por origem.
- HTTP local sem TLS; aceitável somente em AP técnico controlado.
- Uso intensivo de `String` e concatenação JSON pode fragmentar heap em longa duração.
- Logs em RAM não oferecem trilha persistente de incidentes.
- TDS/condutividade alta gera apenas aviso; a política de processo precisa definir bloqueio ou desvio.
- Seleção de redundância é lógica; a atuação física ainda não usa os UIDs vinculados.
- GPIOs fixos e componentes dinâmicos podem divergir.
- Não há contador persistente de ciclos, volume, horas UV, manutenção ou vida dos consumíveis.
- Não há esquema formal de compatibilidade entre perfil, firmware e hardware.
- Não há mecanismo de rotação/revogação da credencial remota.

## Arquitetura recomendada para v2.2

### Domínios

1. `DeviceIdentityManager`
   - número de série obrigatório;
   - patrimônio, cliente, endereço;
   - device UID imutável;
   - trilha de edição autenticada.

2. `HardwareManifestRegistry`
   - família, modelo, revisão e variante;
   - capacidades e GPIOs permitidos;
   - mapa de entradas, saídas, barramentos e limites elétricos;
   - compatibilidade mínima/máxima de firmware.

3. `SignalRegistry`
   - sinais semânticos como `FEED_WATER_OK`, `TANK_FULL`, `PUMP_MAIN`;
   - vínculo entre função de processo e canal físico;
   - validação antes da produção.

4. `ProvisioningManager`
   - estados `UNPROVISIONED`, `IDENTIFIED`, `PROFILE_SELECTED`, `COMMISSIONED`;
   - bloqueio de produção antes do comissionamento.

5. `CloudSyncService`
   - HTTPS com validação de CA;
   - HMAC por dispositivo;
   - telemetry batch;
   - desired/reported configuration;
   - fila semântica com ACK/NACK, expiração e idempotência.

6. `PersistentQueue`
   - buffer circular de telemetria e ACKs;
   - limite de tamanho e política de descarte;
   - gravação agregada para reduzir desgaste.

7. `SecureOtaManager`
   - manifesto assinado;
   - target de hardware;
   - anti-downgrade configurável;
   - confirmação de boot e rollback.

## Critérios de liberação comercial

- 72 horas de teste contínuo por revisão de hardware.
- 500 ciclos de partida/parada automatizados.
- ensaio de perda de energia durante gravação e OTA.
- ensaio de perda/reconexão Wi-Fi e servidor.
- validação de comando duplicado, expirado e fora de ordem.
- falha de cada sensor crítico com saída segura.
- teste de ruído com bomba, válvulas e UV comutando.
- teste de recuperação de NVS e fila persistente.
- rastreabilidade de firmware, hardware, perfil e operador.