# 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 # - 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)