234 lines
10 KiB
Markdown
234 lines
10 KiB
Markdown
# Epifah
|
|
|
|
Reimplementação moderna do lado "telemóvel" do protocolo Aha Radio, para
|
|
usar o MediaNav Evolution de um Renault Clio IV como ecrã/controlo de uma
|
|
app de media atual (rádios web, podcasts, biblioteca local, etc.).
|
|
|
|
> *Epifah* é o nome do projeto. Reimplementação independente, **não afiliada à Harman
|
|
> nem à Renault**. "Aha Radio" é referida apenas para descrever a compatibilidade.
|
|
|
|
> Estado: **fase 0, ainda sem nenhuma descoberta confirmada.**
|
|
> Tudo o que está marcado como *hipótese* tem de ser validado com capturas reais.
|
|
|
|
---
|
|
|
|
## Identidade do projeto
|
|
|
|
| Item | Valor |
|
|
|---|---|
|
|
| Nome | Epifah |
|
|
| Slug do repositório | `epifah` |
|
|
| Package id Android | `pt.ruifpb.epifah` |
|
|
| Domínio | `ruifpb.pt` (ex.: `epifah.ruifpb.pt` para docs/site, opcional) |
|
|
| Descrição curta | Reimplementação independente do protocolo da app legada Aha Radio, para usar o MediaNav Evolution com apps de media atuais. Não afiliada à Harman nem à Renault. |
|
|
|
|
Regras de marca:
|
|
- Não usar "Aha", "Harman", "Renault", "Clio", "MediaNav", "R-Link" no nome, slug,
|
|
package id, ícone ou nome da app. Só na documentação, de forma descritiva.
|
|
- Sem logótipos, cores ou grafismo que lembrem a Aha, a Harman ou a Renault.
|
|
- Manter o aviso de "não afiliado" no README e na página da app.
|
|
- Antes de publicar (Play Store, GitHub público): pesquisar "Epifah" e variantes (Epifa, Epiphah)
|
|
no EUIPO TMview, GitHub e Google Play.
|
|
|
|
---
|
|
|
|
## 1. Objetivo
|
|
|
|
- Fazer o MediaNav Evolution voltar a mostrar e controlar conteúdo vindo do
|
|
telemóvel através do mesmo mecanismo que a app Aha Radio usava.
|
|
- Recuperar funcionalidades que o streaming Bluetooth genérico (A2DP/AVRCP) não dá
|
|
(navegar listas/estações no ecrã do carro, presets, escolher conteúdo sem mexer no telemóvel).
|
|
- Aprender: é um projeto de reverse engineering por interesse próprio.
|
|
|
|
**Não-objetivos**
|
|
|
|
- Android Auto / CarPlay completos (o ecrã do carro é um template fixo).
|
|
- Redistribuir código, APK ou serviços da Harman.
|
|
- Mexer no firmware ou nas ECUs do carro.
|
|
|
|
---
|
|
|
|
## 2. Contexto
|
|
|
|
| Item | Valor |
|
|
|---|---|
|
|
| Carro | Renault Clio IV |
|
|
| Head unit | MediaNav Evolution (sem Android Auto / CarPlay na unidade em causa) |
|
|
| App original | Aha Radio (Harman). Serviço cloud praticamente morto |
|
|
| Estado da app | APK instalado à força, funciona "minimamente" |
|
|
| Ligação testada | Bluetooth. USB nunca testado |
|
|
|
|
### Pistas externas (pesquisa feita)
|
|
|
|
- A Aha foi adquirida pela Harman em 2010, ligava-se aos carros por
|
|
Bluetooth ou USB, e o serviço está hoje inativo.
|
|
- Manuais da Kenwood e da Kia indicam que em **Android** a ligação à head unit
|
|
usa **Bluetooth SPP (Serial Port Profile) + A2DP**, e que em **iOS** usa **USB**.
|
|
Isto sugere fortemente: *dados/controlo por RFCOMM, áudio por A2DP*.
|
|
(Continua a ser hipótese para o MediaNav Evolution específico.)
|
|
- A mesma plataforma Aha foi usada por Pioneer, Kenwood, Subaru (Fujitsu Ten), Kia e outros.
|
|
O protocolo pode ser comum ou quase comum entre eles, o que ajuda se
|
|
aparecer documentação de outro fabricante.
|
|
- **Não foi encontrado nenhum projeto open source** que documente o
|
|
protocolo Aha nem que o reimplemente para Renault.
|
|
- Projetos adjacentes (úteis só como inspiração): `ddt4all` (diagnóstico/configuração
|
|
de ECUs Renault) e vários projetos no Hackaday sobre o protocolo do display Renault (CAN).
|
|
Não são o mesmo problema.
|
|
|
|
### Ponto a verificar antes de investir semanas
|
|
|
|
A Renault anuncia Android Auto/CarPlay para alguns MediaNav Evolution.
|
|
Confirmar **versão exata de hardware e de software** da unidade e se existe
|
|
atualização de firmware oficial que o ative. Se existir, o projeto passa a ser
|
|
só "por interesse", o que continua válido, mas convém saber.
|
|
|
|
---
|
|
|
|
## 3. Conhecimento atual
|
|
|
|
**Confirmado**
|
|
- A unidade integra com a app Aha Radio em Android.
|
|
- A app corre no telemóvel do dono (ver `../AGENTS.md` para versão).
|
|
|
|
**Hipóteses (por validar)**
|
|
- H1. Canal de controlo = RFCOMM/SPP com UUID próprio.
|
|
- H2. Áudio = A2DP normal, fora do protocolo.
|
|
- H3. O carro mostra um template fixo (lista de estações, "now playing", presets).
|
|
- H4. O protocolo é binário com framing (cabeçalho + tipo + payload, possivelmente checksum).
|
|
- H5. Pode não haver autenticação do lado do carro. Se houver, é o maior risco do projeto.
|
|
|
|
**Desconhecido**
|
|
- Quem inicia a ligação RFCOMM (carro ou telemóvel).
|
|
- Se parte do protocolo está em código nativo (`.so`).
|
|
- Se a unidade suporta AVRCP 1.4 com browsing (alternativa muito mais simples).
|
|
|
|
---
|
|
|
|
## 4. Riscos
|
|
|
|
| Risco | Impacto | Mitigação |
|
|
|---|---|---|
|
|
| Handshake com autenticação/assinatura | Pode bloquear o projeto | Descobrir cedo (fase 2). Decidir parar ou não |
|
|
| Protocolo em código nativo ofuscado | Mais trabalho | Frida a nível de socket em vez de ler o código |
|
|
| Template do carro muito limitado | Funcionalidade final reduzida | Definir expectativas na fase 3 |
|
|
| Aha app esperar respostas da cloud para o carro funcionar | Precisamos de simular a cloud | Mapear dependências de rede com mitmproxy |
|
|
| Limitações de SDKs/APIs de serviços de terceiros | Integrações limitadas ou instáveis | Tratar serviços externos como fontes opcionais e plugáveis, verificar limites atuais |
|
|
| Aspetos legais | Exposição | Ver secção 5 |
|
|
|
|
---
|
|
|
|
## 5. Legal e ética
|
|
|
|
- Análise feita sobre equipamento próprio, para interoperabilidade. Na UE a
|
|
diretiva de software prevê exceções para isso, mas **não sou advogado e isto não é aconselhamento legal**.
|
|
- **Não commitar** o APK da Harman, código descompilado nem dumps de recursos.
|
|
- Código da nova app escrito de raiz. Documentação do protocolo escrita nas nossas palavras.
|
|
- Capturas BT/rede: remover endereços MAC, tokens, credenciais antes de commitar.
|
|
- Sem afiliação com Harman ou Renault. Marcas só para identificação.
|
|
|
|
---
|
|
|
|
## 6. Plano por fases
|
|
|
|
Cada checkbox pode virar um issue no Gitea. Sugestão de milestones = fases.
|
|
|
|
### Fase 0: Preparação
|
|
- [ ] Registar versões: telemóvel/Android, versão do APK Aha, versão de hardware/software do MediaNav
|
|
- [ ] Verificar se há atualização de firmware oficial com Android Auto
|
|
- [ ] Teste rápido: o MediaNav suporta **AVRCP browsing**? (usar uma app com `MediaBrowserService`, ver se aparece navegação no ecrã)
|
|
- [ ] Testar o que a unidade faz por **USB** com o telemóvel (modo storage, iAP, outro)
|
|
- [ ] Criar repositório com estrutura da secção 8
|
|
- [ ] Preparar ferramentas: jadx, apktool, Wireshark, Frida, mitmproxy, adb
|
|
|
|
### Fase 1: Análise estática do APK
|
|
- [ ] Decompilar com jadx/apktool (localmente, não commitar)
|
|
- [ ] Ler `AndroidManifest.xml`: permissões, serviços, receivers, `uses-feature`
|
|
- [ ] Procurar `UUID.fromString`, `listenUsingRfcomm*`, `createRfcommSocket*`, `BluetoothServerSocket`
|
|
- [ ] Listar bibliotecas nativas (`lib/*/*.so`) e perceber o que fazem
|
|
- [ ] Identificar classes de framing/serialização
|
|
- [ ] Mapear dependências de rede (hosts, endpoints) em `docs/findings/network.md`
|
|
|
|
### Fase 2: Captura de tráfego
|
|
- [ ] Ativar *Bluetooth HCI snoop log*, repetir cenários e extrair `btsnoop_hci.log`
|
|
- [ ] Analisar SDP no Wireshark (UUID do serviço que o carro procura)
|
|
- [ ] Frida: hook em `BluetoothSocket` input/output streams para ver frames em claro
|
|
- [ ] Cenários padronizados (ver `docs/captures/README.md`): ligar, abrir app, lista de estações, escolher estação, next/prev, presets, desligar
|
|
- [ ] Decidir: existe autenticação? Documentar em `docs/protocol/handshake.md`
|
|
|
|
### Fase 3: Especificação do protocolo
|
|
- [ ] Framing, tipos de mensagem, campos
|
|
- [ ] Máquina de estados do handshake
|
|
- [ ] O que o carro consegue mostrar (campos, limites de texto, imagens?)
|
|
- [ ] Escrever `docs/protocol/SPEC.md` com cada afirmação ligada a uma captura
|
|
|
|
### Fase 4: Prova de conceito
|
|
- [ ] Cliente de teste (Python ou app Android mínima) que faz o handshake
|
|
- [ ] Mostrar uma estação/lista fictícia no ecrã do carro
|
|
- [ ] Receber eventos do carro (botões, seleção)
|
|
|
|
### Fase 5: App real (MVP)
|
|
- [ ] Serviço Android em foreground com o UUID e handshake corretos
|
|
- [ ] "Now playing" com metadados, play/pause/next/prev
|
|
- [ ] Lista de presets/favoritos no ecrã do carro
|
|
- [ ] Fontes de conteúdo plugáveis: rádios web (radio-browser.info), podcasts, biblioteca local
|
|
- [ ] Gestão de áudio (A2DP, audio focus)
|
|
|
|
### Fase 6: Extras
|
|
- [ ] Integrações com serviços de streaming de terceiros (via SDK/API disponíveis na altura, a verificar)
|
|
- [ ] Navegação por playlists/álbuns no ecrã do carro
|
|
- [ ] UI de configuração no telemóvel
|
|
- [ ] Teste de USB se a Fase 0 mostrar algo interessante
|
|
|
|
---
|
|
|
|
## 7. Stack proposta (a confirmar)
|
|
|
|
- Android, Kotlin, API recente. `BluetoothSocket` clássico (RFCOMM).
|
|
- Análise: jadx, apktool, Wireshark (com dissector/Lua se justificar), Frida, mitmproxy.
|
|
- Protótipos de protocolo: Python (sockets RFCOMM em Linux, ou `pybluez`/`bleak` consoante o caso).
|
|
- Testes de parsing com ficheiros de captura reais (golden files, sanitizados).
|
|
|
|
---
|
|
|
|
## 8. Estrutura de repositório sugerida
|
|
|
|
```
|
|
/
|
|
├── AGENTS.md # contexto para humanos e LLMs
|
|
├── README.md
|
|
├── docs/
|
|
│ ├── PROJECT.md # este ficheiro
|
|
│ ├── findings/ # notas de descobertas (uma por tema)
|
|
│ ├── protocol/ # SPEC.md, handshake.md, mensagens
|
|
│ ├── captures/ # README + capturas SANITIZADAS
|
|
│ └── decisions/ # ADRs curtos
|
|
├── tools/ # scripts Frida, parsers, helpers de análise
|
|
├── prototype/ # PoC em Python
|
|
└── app/ # app Android final
|
|
```
|
|
|
|
`.gitignore` obrigatório para: APKs, `jadx-out/`, `apktool-out/`, `*.apk`, capturas não sanitizadas.
|
|
|
|
---
|
|
|
|
## 9. Modelo de nota de descoberta
|
|
|
|
```markdown
|
|
# <tema>
|
|
- Data:
|
|
- Pergunta:
|
|
- Método (ferramenta, ficheiro de captura, hook):
|
|
- Evidência (excerto, offset, hash do ficheiro):
|
|
- Conclusão:
|
|
- Confiança: alta / média / baixa
|
|
- Próximo passo:
|
|
```
|
|
|
|
## 10. Referências
|
|
|
|
- Kenwood: manuais Aha Radio (requisitos Android: SPP + A2DP)
|
|
- Kia: página de referência Aha Radio (Android via Bluetooth, iOS via USB)
|
|
- Renault: páginas Media Nav Evolution (Android Auto/CarPlay em algumas versões)
|
|
- Hackaday: projetos de reverse engineering do protocolo display/rádio Renault (CAN)
|
|
- `ddt4all` no GitHub (diagnóstico de ECUs Renault)
|