10 KiB
10 KiB
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.mdpara 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
BluetoothSocketinput/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.mdcom 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.
BluetoothSocketclá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/bleakconsoante 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
# <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)
ddt4allno GitHub (diagnóstico de ECUs Renault)