victor's hacker blog

Como transformei minha Alexa em um auto-falante inteligente para meu Mac

Sun, 03 May 2026 00:00:00 +0000

No começo desse ano eu percebi o quão distante as Alexas estão ficando em relação ao avanço tecnologico das IAs. Se você não paga subscription os auto-falantes que um dia chamamos de “inteligentes” estão ficando literalmente “burros” a cada dia que passa.

há uns 4 anos atrás eu ganhei uma Echo Show 5 de um amigo e desde então eu tenho usado ela diariamente para controlar algumas coisas aqui em casa, tocar músicas e também para tirar duvidas aleatórias do dia a dia.

Decidi que ja está na hora de aposentar a Echo e dar espaço para uma próxima assistente virtual.

Uma foto da minha alexa ainda no ritmo natalino:

Ao invés de simplesmente vender a echo show eu decidi fazer algo útil com ela.

se a Echo não é tão boa sendo uma uma assistente virtual, então o que ela é boa fazendo?

Eu sei que ela é boa tocando música, os speakers dela são muito bons (talvez até melhor do que o meu PC).

Fora que um speaker para computador que tenha tela touch embutida e que sejam relativamente baratas é raro de se ver.

E dai que veio a ideia de transformar ela em um speaker inteligente pro meu computador. Um projeto que me diverti fazendo, portanto vou compartilhar com vocês os desafios que tive e como resolvi.

Procurando formas de usar a Echo como speaker

Por onde começar nesse projeto de conectar a alexa no meu PC para reproduzir o som?

A resposta mais obvia é simplesmente usar o Spotify que ja vem nativamente. Mas tem um problema nisso: um speaker de verdade não é seletivo, o som vem do PC como um todo e não apenas de um aplicativo.

Será que existe alguma skill no app da alexa que dê para adicionar para isso? bom, eu não encontrei. Depois de muitas pesquisas não achei nenhuma forma oficial de usar como um speaker como eu gostaria.

O único caminho que me restou foi procurar alternativas na conunidade que desse para customizar a alexa a ponto de transformar ela em um speaker…

Tive sorte em encontrar que 1 mês antes no Forum XDA postaram uma forma de “desbloquear” alguns modelos da Echo Show dando possibilidade de instalar seu próprio sistema operacional.

Esse post abriu meus olhos no que a Echo é capaz, ela conseguir rodar Android é incrivel e significa que esse plano (de usar ela como um speaker) tecnicamente é possível.

Apesar de possível, desbloquear o bootloader da Echo Show não é uma tarefa fácil e sem riscos. Se algo der errado você pode simplemente quebrar sua alexa num ponto irrecuperavel.

Instalando Android na Echo Show

Como minha Echo Show 5 é da segunda geração eu precisei seguir esse passo a passo aqui, la tem todos os links necessários. Caso tenha curiosidade o repositório com o exploit chain é R0rt1z2/amonet, juntaram eles em 1 pacote só para que o processo seja facilitado.

Antes de começar a seguir o passo a passo eu li todas as mensagens do post original, vi muitos tutoriais diferentes para entender a fundo o que acontece e o que deve ser feito, se for fazer isso sugiro fazer o mesmo.

Tinha uma pequena chance desse script quebrar minha alexa, então os 5 minutos dele rodando pareceram 30 minutos. Fiquei literalmente assim:

Deu bom!

Confesso que ver a tela de configuração do TWRP deu um alívio.

Com a Echo desbloqueada eu poderia substituir o SO pelo o que eu quisesse, mas seria loucura fazer isso sem backup dos arquivos importantes da sua alexa, melhor prevenir fazendo backup do SO antigo:

Agora que eu tenho backup posso ficar tranquilo caso faça alguma coisa de errado.

Conforme o post eu instalei o LineageOS 18 diretamente pelo TWRP mesmo.

Sucesso !

Em busca de uma solução p/ redirecionar áudio

Apesar da Echo estar rodando um SO Android eu ainda tinha um caminho pela frente até ela virar um Speaker de verdade.

Eu ainda precisava alguma forma de “espelhar” ou redirecionar o audio do meu PC, e para isso tive que pesquisar bastante sobre o assunto e nesse processo descobri várias formas diferentes de fazer isso:

Nome	É software pago?	Artefatos p/ baixar	Método
VLC	é gratis!	Linux/Mac/Windows -> iOS/Android	WIFI
AndroidUsbAudioDevice	é Grátis!	Windows -> Android	USB
audiorelay	Grátis com anúncios!	Linux/Mac/Windows -> Android	WIFI/USB
SoundWire Server	Grátis com anúncios!	Linux/Windows -> Android	WIFI
Airfoil	Pago!	Mac -> iOS/Android	WIFI

No meu caso eu precisava de um programa que suportase Mac -> Android e de preferência algo 100% via USB, grátis e opensource.

A solução do audiorelay é o que chega mais próximos ao que eu preciso out-of-the-box, o VLC me atenderia caso eu rodasse comandos no terminal para redirecionar o uso do WIFI para o USB.

Eu percebi que todas as opções exigiam instalar algo no computador (obviamente) mas também algo no meu Android.

Eu até tolero baixar um app no android da echo, mas eu quero evitar com todas as forças a parte burocrática:

configurar, abrir o app no celular e no computador, rodar comandos toda vez, tudo isso só pra fazer o áudio ir pro celular.

descartei audiorelay por ter anúncios e VLC eu descartei por ter vários passos a serem feitos pra usar, não é plug-and-play como eu gostaria.

E todas as outras que encontrei não atendiam algum dos requisitos, sempre tinham pelo menos um ponto negativo.

Veja, as soluções em si não chegam a ser ruins, eu estava buscando algo bem específico e nesse contexto não eram opções boas.

Desistindo e criando minha própria solução

A experiência ideal é rodar apenas 1 comando no computador e tudo se resolver sozinho.

Esse é um dos principais motivos de eu ser fã do scrcpy e gnirehtet, ambos tem uma experiência de uso muito simples mesmo fazendo várias coisas complexas por baixo dos panos.

O scrcpy redireciona áudio do celular para o PC, portanto de curioso resolvi olhar se nele tinha como fazer o caminho oposto. Recebi um banho de agua fria: o principal mantenedor disse que isso é fora do escopo do scrcpy e faz sentido.

Pelo comentário dele, deu a entender que não é viável tecnicamente redirecionar áudio do PC para celular: "no technical solution anyway"

E foi nesse exato momento que decidi criar eu mesmo alguma solução.

Plano de implementação

Objetivo: ter uma CLI que rodo 1 vez e já faz tudo acontecer, sem config e tudo automágico.

Pré-requisitos:

simples de usar
ser grátis e opensource
USB como meio de transporte de dados

Desisti da ideia de WIFI pois tive a impressão que poderia aumentar muito a latência do áudio.

Então uma visão geral do projeto e caminho dos dados seria tipo assim:

                   (1)   Interface de audio do PC       
                                    │               
                                    ▼               
                (2)   programa rodando no computador
                                    │               
                                    ▼               
                                   usb              
                                    │               
                                    ▼               
                        (3)   meu aplicativo        
                                    │               
                                    ▼               
                        (4)  audio do celular       

Quebrei o problema maior em 4 problemas menores para facilitar.

Esses mesmos “4 problemas menores” iriam tomar entre 1 a 2 semanas (nos horarios livres) de desenvolvimento para finalizar, tudo pra não gastar 1 minuto configurando algo toda vez que for usar kkkkk Mas quem nunca fez isso atire a primeira pedra.

Passo 1: coleta do áudio do PC

essa foi relativamente simples… Como meu objetivo é suportar mac e linux eu foquei em usar alguma ferramenta que funcionasse bem para os 2. Testei algumas mas a que mais saiu melhor foi um binário chamado SoX (Sound eXchange), eu pude escolher uma interface e trazer o dado bruto via STDOUT.

Fazendo vários testes eu consegui chegar a esse comando aqui, ele me traz exatamente o que eu preciso num sample rate e buffer definido.

sox --buffer 3840 \                 # valor calculado
    -t coreaudio "BlackHole 2ch" \  # interface virtual
    -r 48000 \                      # 48 kHz
    -c 2 \                          # 2 canais de áudio
    -b 16 \                         # 16-bit PCM
    -e signed-integer -L \          # little-endian Signed Int
    -t raw - 2>/dev/null            # output sem inferir formato de áudio

coleta do audio de interface de áudio do pc ✅

Passo 2: escrita de dados em um device USB

Com poucas pesquisas já percebi que a melhor biblioteca para isso é a libusb, ela funciona com qualquer versão do USB e funciona cross-platform.

O único problema dessa biblioteca é a documentação, particularmente não achei muito fácil de entender, falta exemplos para as funcionalidades.

Mas de qualquer forma achei vários exemplos online usando essa lib portanto acabou que foi uma boa escolha. No final para escrever dados na interface USB eu precisei seguir um fluxo semelhante a esse:

Abro uma conexão com um device (libusb_open_device_with_vid_pid)
Reivindico a interface USB escolhendo o device (libusb_claim_interface)
Inicio uma transferência passando um callback (libusb_fill_bulk_transfer)
- 3.1. Callback vai inflando o buffer com os bytes conforme vão chegando
Envio os dados para aquele device (libusb_submit_transfer)

envio de dados para o dispositivo via USB ✅

Passo 3: Um app conseguir ler os dados que vem pelo USB

Usar o libusb pra escrever no USB funcionou mas foi sofrido até conseguir ficar certinho como eu queria, por isso para o passo 3 eu fui atrás de soluções fáceis de usar.

Durante minhas pesquisas eu esbarrei com o Android Open Accessory (AOA), um protocolo que permite um aplicativo interagir com o USB do celular de uma forma relativamente simples.

Achei bem promissor, mas fiquei na dúvida se ainda funciona visto que o protocolo é de 15 anos atrás (2011).

Aparentemente da pra saber se seu device suporta o “modo acessory” do AOA usando o comando:

adb shell ls /system/etc/permissions | grep usb.accessory

E pra minha surpresa, TODOS meus devices tinham o arquivo usb.accessory.xml ai na pasta (confirmando que suportam esse modo acessório), isso é muito bom!

Olhando mais a fundo nesse protocolo eu encontrei 2 versões:

v1.0: básica e tem só o essencial
v2.0: adiciona mais capacidades ao protocolo

Como eu precisava só do essencial segui com a versão v1.0.

Foi relativamente simples implementar, precisei declarar no AndroidManifest um Service que tivesse intent filter do USB_ACCESSORY_ATTACHED, passando metadados do acessório:

<usb-accessory
      manufacturer="Victor"
      model="DroidSink"
      version="1.0" />

Essa configuração é essencial para que o programa do pc consiga abrir uma conexão com meu app do celular.

No momento que o usuário aceita o popup de pareamento, o UsbManager nos permite conectar no device e ao fazer isso e recebemos um objeto do tipo ParcelFileDescriptor, combinando ele a um FileInputStream nos permite iniciar a leitura de forma muito simples.

leitura de dados no app via USB ✅

Passo 4: Reproduzir o áudio no aparelho

Com uma stream de dados vindo, reproduzir em aúdio é a ultima etapa do processo. Para fazer isso com qualidade precisamos garantir que o áudio de saída tem as mesmas especificações que o de entrada la no computador.

Usei a API AudioTrack para fazer essa configuração.

Nela posso configurar uma série de coisas, por exemplo a prioridade desse som, o tipo dele, modo de transfêrencia que será usado e por ai vai. Para o tamanho de buffer eu fui com o mesmo valor que defini na coleta de audio do PC:

val minBufferSize = AudioTrack.getMinBufferSize(
      48000, // 48 kHz
      AudioFormat.CHANNEL_OUT_STEREO,
      AudioFormat.ENCODING_PCM_16BIT
)

val chunkSize = 3840 // valor calculado, mesmo do comando do sox

val bufferSizeInBytes = maxOf(
      minBufferSize, 
      chunkSize * 3 // buffer de 3 vezes o tamanho do chunk de leitura
)

Enquanto eu estava implementando esse passo eu tive muitos problemas de áudio picado, depois de bastante troubleshooting eu entendi que caso eu tivesse alguma configuração diferente entre a coleta e a reprodução, eu teria algum tipo de problema. A causa do problema é bem obvia olhando agora, mas na hora eu jurava que buffers maiores resolveriam, mas eu estava errado.

O tempo de latência é calculado se baseando nessas especificações do projeto. Por esse e outros motivos a configuração inicial (sox) e final (no android) são essenciais para uma qualidade decente de áudio.

reprodução de áudio no aparelho ✅

Calculando a latência geral do projeto

⚠️ Não manjo tanto assim de cálculo de latência de áudio, posso ter deixado alguma coisa pra trás, se ver algo errado me avise

Como eu estabeleci que 1 chunk equivale a 3840 bytes a escrita iria demorar cerca de 20ms.

Por garantia eu coloquei o buffer sendo 3 vezes o tamanho de escrita, sacrifico 60ms de latência pela promeça de qualidade de áudio. Estou assumindo que a leitura da stream pelo app iria demorar uns 10ms.

Somando tudo até agora a latência total é de aproximadamente 90ms, mas eu preferi arredondar para cima para caso eu tenha esquecido algo.

Portanto do momento de coleta do som até o momento de reproduzir, a latência final é no minimo ~100ms.

Pelos meus testes esse me pareceu ser um tempo aceitável na maioria dos casos, não é excelente mas também não é incomodo, com excessão de jogos que esse delay faz diferença.

Conclusão

Esse projeto eu chamei de DroidSink, ele está disponivel no meu github caso queira ver como está o código.

Desde a publicação da v1.0.0 (dia Feb 7) eu já usei MUITO, conforme o tempo foi passando fui fazendo algumas melhorias e correções.

Pra mim ele tem funcionado de forma incrível, eu rodo 1 comando e ele ja faz TUDO pra mim:

instala o que precisa instar no celular
configura o que precisa no device
captura audio do pc e reproduz no celular

droidsink run

Veja esse exemplo tocando We didn't start the fire no meu computador e o som saindo na minha Echo rodando android.

Your browser does not support the video tag.

Usando todo esse tempo identifiquei uma série de melhorias que poderiam ser feitas, como por exemplo:

Diminuir latência para no minimo 50ms.
Disponibilizar p/ download em mais lugares.
Garantir compatibilidade “out-of-the-box” com linux-arm64 e linux-x86_64.
Ter alguma UI para ser apresentada no device.
Melhorar o que é apresentado no terminal enquanto roda.
… e várias outras ideias …

Sigo trabalhando nas melhorias conforme aparece um tempinho.

Entender a Interoperabilidade Kotlin-Swift pode evitar que você cause bugs em produção

Sun, 15 Mar 2026 00:00:00 +0000

Interoperabilidade = A capacidade de sistemas distintos conversarem e compartilhar dados.

Talvez isso seja óbvio para alguns devs mobile, mas para quem desenvolve projetos que utilizam Kotlin Multiplatform e ainda não deu a devida atenção e realmente parou para ler sobre a interoperabilidade entre Kotlin e Swift, esse post é minha chance de te convencer a dominar esse tema.

No desenvolvimento com Kotlin Multiplatform, dominar a interoperabilidade do Kotlin com Swift é uma peça chave pra não gerar problemas em produção.

Tudo que vai no commonMain vale pro Android e iOS, portanto nós temos como expectativa que o código seja essencialmente a mesma coisa entre as plataformas: tenha as mesmas funções, classes e se comporte igual.

Esse compartilhamento de código entre a commonMain e código Swift é totalmente transparente para nós devs, tudo que eu escrevo em um aparece “igual” no outro… e após várias iterações disso é fácil esquecer que o código do commonMain passa por uma “etapa intermediária”, onde pode sofrer mudanças para que o Swift consiga entender nativamente.

De uma forma simplista, o código que o Swift vê é o produto da soma commonMain + iosMain + um processo de multiplas compilações, e não somente commonMain + iosMain.

Esse “processo de multiplas compilações” ou essa “etapa intermediária” que eu disse foi apenas uma forma de resumir, se você tiver interesse em como isso funciona vou deixar um link que dá explicações e detalhes técnicos sobre isso:

kotlin/docs/native/compilation-model.md

Quantas vezes você já fez um código que no Kotlin ficou belíssimo, mas quando você abriu o XCode notou que esse mesmo código tava péssimo pra usar? Ou até mesmo tinha coisas a mais nele que você não desenvolveu? Ou coisas faltando… “Cadê os parametros default que configurei??”

Vou te falar um bug que eu causei em produção por não ter conhecimento 100% de como meu código Kotlin ficava para o Swift.

Para quem não manja de swift, quando você faz qualquer código que pode gerar uma exception você é obrigado a declarar isso com uma palavra chave no código: throws. Se sua função tem essa palavra chave, quem chamar ela também é obrigado a tratar senão o projeto não compila.

func canThrowErrors() throws -> String

func cannotThrowErrors() -> String

Tem cenários onde você sabe que não vai gerar uma exception, como por exemplo carregar uma imagem local… Nesse caso voce ainda precisa manualmente desabilitar a propagação do erro.

let photo = try! loadImage(atPath: "./Resources/John Appleseed.jpg")

link para o restante da documentação da apple sobre isso

Qualquer exception lançada onde não está explícito que pode gerar uma exception (ou seja, não está marcada por throws) faz com que o app feche imediatamente. Mesmo quando ela estiver dentro de um do-catch (vulgo try-catch)!!! Esse é o comportamento padrão.

Eu sabia que existia uma annotation chamada @Throws, mas meu pensamento era: “poxa, se eu chamo meu código que vem do Kotlin dentro de um try catch no Swift, ele ja vai ser capturado e tratado - não tem necessidade de colocar essa annotation no Kotlin”.

Era uma exception esperada, ela de fato poderia acontecer eventualmente e ta tudo bem, inclusive foi pensando nisso que eu coloquei o try-catch. No final das contas minha função gerava essa exception em um cenário específico, e justamente por lançar uma exception que o Swift entendeu como inesperada, o aplicativo encerrava pois pra ele foi um erro fatal.

Você pode argumentar que eu só pensava assim pois tenho mais experiência em linguagens que o try-catch pode capturar todos os erros, não pela falta de conhecimento da interoperabilidade em si. E olha, você provavelmente está certo.

Mas num olhar pragmático, KMP para devs mobile que já trabalhavam na área cai EXATAMENTE nesse mesmo cenário: temos uma bagagem/conhecimentos de outras linguagens que acabamos trazendo junto, e isso de um lado é ótimo, mas se não tivermos cuidado isso pode nos sabotar (vide evidência do bug que eu causei).

A realidade é que:

as plataformas/linguagens que se beneficiam com nosso código KMP tem demandas específicas, que ao subestimadas eventualmente vão trazer dores de cabeça para devs e consequentemente para os usuários finais.

Eu poderia simplesmente sair estudando Swift e todas suas particularidades, isso certamente iria fazer diferença para esse erro que comentei mais acima do post. Porém esse caminho apesar de funcionar acaba sendo bem ineficiente.

Se meu objetivo é melhorar o conhecimento e habilitade em desenvolver códigos multiplataforma, estudar uma linguagem inteira seria o equivalente a atirar para todos os lados, eu vou acertar o alvo, mas gastarei toda minha munição no processo.

Seria excelente se tivesse uma documentação ou algo que me alertasse sobre essa particularidade do Swift e ainda me da uma solução? É ai que entra a documentação de interoperabilidade com Swift/ObjC.

Olha aqui ela dizendo exatamente sobre o problema que eu tive e como resolver ele

Se você tem interesse em evoluir as habilidades em KMP, fica como minha sugestão: Estude a interoperabilidade entre as plataformas. Com esse conhecimento você vai saber o que deve evitar no seu código multiplataforma para não causar bugs em produção igual eu fiz.

Usando frida para fazer debug em apps mobile

Thu, 20 Nov 2025 00:00:00 +0000

Introdução

No desenvolvimento mobile somos quase que obrigados a usar alguma ferramenta de debug, só rodar o app e ver o comportamento dele muitas vezes não é o suficiente para entender que uma mudança deu bom ou não, ou até mesmo pra entender como que aquele bug sinistro está acontecendo.

Existem várias ferramentas bem estabelecidas no mundo mobile, acho que todos conhecem android studio e xcode. Quem desenvolveu apps usando react native talvez já ouviu falar de flipper ou reactotron.

Nesse post vamos ver uma ferramenta que talvez você nunca tenha ouvido falar, e que podemos usar para abordar o debug de problemas em aplicativos móveis de uma forma completamente diferente do tradicional.

Além de falar sobre ela, vou mostrar um exemplo simples de como usei ela para resolver um problema que tive recentemente.

Mas já adianto que acho improvável ela substituir outras ferramentas… A ideia aqui está longe disso, é muito mais sobre ter mais uma ferramenta no seu cinto de utilidades. Cada uma das ferramentas tem suas especialidades e seus casos de uso, e como engenheiro de software precisamos reconhecer quais ferramentas funcionam melhor para cada objetivo.

Contexto sobre ferramentas usadas em AppSec

No meu tempo livre as vezes eu me pego estudando sobre segurança da informação focado no mobile, pesquisando na internet mas também fazendo meus próprios testes e explorações, e isso contribuiu para ter novas ideias e perspectivas diferentes sobre aplicações android e ios.

A área de segurança da informação tem várias ‘sub áreas’ (AppSec acho que pode se dizer como uma sub área, certo?), mas acho que todos que trabalham com isso devem conhecer a existência de uma ONG que tem como objetivo melhorar a segurança das aplicações através de projetos open source, a famosa OWASP (Open Worldwide Application Security Project)

Um parenteses aqui, devo ressaltar que a ideia dessa ONG é muito legal e talvez até meio comica se puxarmos essa ideia para desenvolvimento de software: imagine por exemplo uma iniciativa dessa só que com o objetivo de acabar com todos os bugs dos softwares? ou outra pra acabar com as breaking changes ao atualizar?? apesar de meio bizarro isso seria simplesmente maravilhoso kkkkk, cade a ong pra acabar com vendor-lock? fica ai a reflexão pra você.

Dentro da iniciativa da OWASP tem um sub-projeto chamado OWASP Mobile Application Security - e por se tratar de mobile vamos olhar com mais atenção.

O OWASP de Mobile tem uma lista com várias ferramentas open source para facilitar o trabalho para quem quer explorar aplicações mobile.

O que eu tenho percebido é que dependendo do caso elas também podem ajudar os desenvolvedores. Vou abordar em especial a ferramenta Frida, mas essas outras que listei aqui também são interessantes e valem a pena conhecer:

Capacidades, vantagens e desvantagens

Okok eu entendi que essas ferramentas podem ser úteis, mas pra que exatamente?

Para definir Frida em uma frase eu vou usar a que tem no site deles: Dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers., dai falando mais tecnicamente: frida por baixo dos panos usa um módulo escrito em C que permite você injetar códigos JS durante período de execução de tal forma que é possível interagir com APIs que esse módulo provem.

Vou explicar melhor como isso pode ser aplicável no dia a dia.

Você talvez já deve ter pego aquele bug cabuloso onde o uso de debug foi útil e talvez até necessário, aquele cenário de concorrência entre duas funções ou senão um erro que só ocorre quando o app está em um estado muito específico.

Já deve estar cansado de saber que debug em ferramentas como android studio e xcode da pra colocar breakpoints para inspecionar e alterar variáveis, mas algo muito bacana e que não vejo muitas pessoas comentando é sobre o watchpoints (android) onde você consegue registrar um ‘hook’ para pausar a execução do app quando uma variável específica for alterada, ou no iOS o thread return (lldb no iOS) que permite você alterar o valor de retorno de uma função nativa.

A Frida tem as mesmas capacidades de debug que falei acima (leitura, escrita e observar uma variável), mas aborda isso de uma maneira completamente diferente, e eu acredito que é ai que podemos tirar proveito dela.

Um exemplo simples de debug que fiz usando Frida

Nessa semana encontrei um bug muito esquisito que acontecia apenas em dispositivos iOS em um cenário desconhecido, a única evidência ou log que eu tive sobre isso é o código do erro e uma mensagem muito superficial: -25291 (errSecNotAvailable) - que se você ler a doc basicamente diz No trust results are available., no log de erro a seguinte mensagem aparece: No keychain is available..

Bom, depois de muito investigar e achar diversos links de pessoas que passaram pelo mesmo problema e não acharam a causa raiz, ficou muito difícil para reproduzir o erro e corrigir o que causa ele de fato, mas para não sair de mãos vazias eu decidi seguir pela abordagem de assumir que ele vai ocorrer e tratar o erro de forma elegante.

Dai veio um pensamento: Ok mas quando eu fizer essa possível tratativa do erro, como que vou comprovar que minha solução de fato trata o erro se eu nem consegui reproduzir ele? É basicamente uma solução às cegas, um tiro no escuro. Até podemos lançar um throw no meio do código pra fingir que o erro aconteceu, mas com certeza não é a mesma coisa que a API do módulo de Security te retornar esse erro de fato.

Eu poderia usar o modo debug do xcode e tentar colocar um breakpoint e usar o thread return para trocar o valor, mas iria gastar um bom tempo para entender quais comandos usar no lldb para modificar o retorno do método que eu quero… dai veio a ideia de usar o Frida - lendo as docs eu vi que você pode usar APIs em JS para poder modificar os retornos, o que pareceu bem promissor e relativamente simples de fazer, e como no passado eu já tinha configurado e instalado Frida no meu macbook, decidi tentar.

No final eu cheguei nesse código para forçar esse erro a acontecer, escrevi esse script que basicamente faz o hook na função nativa que consulta a keychain e força o retorno do erro que quero.

// keychain_hook_specific_error.js
const secItemCopyMatching = Module.findExportByName("Security", "SecItemCopyMatching");
if (secItemCopyMatching) {
    Interceptor.attach(secItemCopyMatching, {
        onEnter: (args) => {
            console.log("SecItemCopyMatching called");
        },
        onLeave: (retval) => {
            console.log("SecItemCopyMatching returning -25291");
            retval.replace(-25291);
        }
    });
} else {
    console.log("SecItemCopyMatching not found");
}

Lembrando que para usar o frida no iOS você precisa ter o dispositivo jailbroken ou escolher outro método de operação.

Com esse script, toda vez que a função SecItemCopyMatching for chamada, o retorno dela será alterado para o código de erro -25291 para simular o erro que quero testar. Dai depois disso bastou executar o seguinte comando:

ID_DO_SEU_DEVICE="" # serve tanto para simulador quanto device fisico.
# -F pra pegar o app que estiver rodando no momento, portanto abra o app antes de rodar esse comando
frida -D $ID_DO_SEU_DEVICE -F -l ./keychain_hook_specific_error.js

Agora que que esse script está rodando, toda vez que qualquer parte do meu app chamar essa função do módulo de Security, aquele erro vai ser retornado conforme eu configurei, dessa forma eu consigo comprovar que meu código está funcionando pois o módulo literalmente retornou esse erro, só precisei dar um empurrãozinho.

Esse foi um exemplo simples, mas já da pra ter uma ideia do poder do frida para fazer debug em runtime, e o melhor de tudo é que você não precisa modificar o código fonte do app para isso, muito menos saber onde que esse código está, você pode fazer o hook em qualquer função nativa ou gerenciada que quiser.

Além disso vale ressaltar que eu usei apenas 2 módulos do projeto (Interceptor e Module) mas existem outras que podem ser usados.

Tiveram pelo menos mais outras 2 vezes onde eu usei Frida e ferramentas que usam Frida por baixo dos panos (como o objection) para resolver problemas como esse, eu gostei que consegui chegar em uma solução bacana mais rápido do que eu esperava, e ainda por cima com evidências sólidas que minha solução funcionava - o que é muito bom, eu poderia citar elas aqui mas o post vai ficar longo demais, com o exemplo que eu dei já deu para entender por cima como uma ferramenta dessa pode ajudar no fluxo de debug.

Conclusão

Nesse post passamos um pouco sobre ferramentas de que são usadas na área de segurança da informação, dei alguns exemplos e aprofundamos um pouco mais na ferramenta Frida dando um exemplo bem simples.

A principal mensagem que quero que leve desse post é não ficar preso as ferramentas tradicionais por estar acostumado a usá-la.

Explore alternativas, até aquelas que são de outras áreas se realmente tiver interesse. Saber identificar as ““melhores”” ferramentas para cada caso pode te pagar dividendos, uma analogia interessante e meio exagerada para se pensar é: você consegue furar uma parede usando uma parafusadera? Não manjo muito de obras mas acredito que dependendo da potência dela e o material da parede até deve conseguir sim, mas sem dúvidas uma ferramenta própria para isso seria bem mais fácil.

Renderização Declarativa - React Reconciler

Thu, 16 Jan 2025 00:00:00 +0000

Introdução

Eu fiz esse post aqui como forma de eu aprofundar no tema de renderização declarativa, minha ideia é abordar alguams bibliotecas que funcionam dessa forma e entender com mais profundidade as diferenças de abordagens entre cada ferramenta.

Eu quero cobrir tanto o React Reconciler quanto o Jetpack Compose Runtime, e talvez outras ferramentas que eu for encontrando no caminho. Por hora vamos começar com o React Reconciler.

Disclaimer: Nesse artigo vou procurar colocar referencias das informações que eu estou compartilhando, mas é importante ressaltar que essas informações podem mudar com o tempo ou até mesmo eu posso cometer algum erro, portanto minha recomendação é ler este artigo com o ‘livro de regras embaixo do braço’ e sempre verificar a documentação oficial das ferramentas.

React

É uma biblioteca bem conhecida na web, e eu particularmente já usei bastante em projetos usando react-native. Poderíamos falar especificamente do react native, mas como a ideia é falar sobre a renderização declarativa, vou abordar apenas o react.

Eu imagino que você já deve ter ouvido falar algo sobre ou talvez até desenvolvido alguma aplicação que utilize react, se não teve contato com a ferramenta não tem problema, vamos aprofundando aos poucos. Para iniciar um projeto react é bem simples, basta criar um elemento “root” e chamar uma função passando um componente para ser renderizado:

import { createRoot } from 'react-dom/client'; //react-dom@19
import App from './App'; 

const domNode = document.getElementById('root');
const root = createRoot(domNode);

root.render(<App />);

Vamos explorar um pouco como o react-dom funciona por baixo dos panos, e como que só esse trecho de código ja permite que voce renderize e atualize a interface do usuário de forma declarativa.

Procurando no código fonte do react-dom, podemos encontrar a função createRoot aqui. esse é um código exemplo de como ele funciona:

type RootType {
    render: (element: ReactElement) => void;
    // ...
}

export function createRoot(
  container: Element | Document | DocumentFragment,
  options?: CreateRootOptions,
): RootType {

    /*
        usa-se o options para fazer uma serie de configurações que nesse momento não são importantes
    */
        
    // react-reconciler/src/ReactFiberReconciler
     const root = createContainer( 
        container,
        /* ...demais configurações... */
    );
    // ...
    return new ReactDOMRoot(root);
}

Perceba que o createRoot faz algumas configurações que no momento não são relevantes, importante é que ele chama a função createContainer, que vem de uma biblioteca chamada react-reconciler. Ou seja, a lib react-dom sozinha não cuida da renderização dos elementos, ela delega essa responsabilidade para a biblioteca react-reconciler, o que faz sentido pois ter essa logica abstraida em uma lib separada de react-dom permite que o reconciliador possa ser importado e utilizado de forma independente.

Reconciler & Renderer

O react reconciler é responsavel em fazer a gestão das mudanças de estado e props dos componentes, basicamente ele é o motor que faz toda a lógica de comparação entre uma versão D e D+1 da árvore de componentes, e decide quais componentes precisam ser atualizados, removidos ou adicionados.

Além dessa gestão de mudanças sendo feita, existe outro componente que cuida de como essas mudanças são aplicadas na interface do usuário, e é ai que entra o renderer, ele é a camada que faz a ponte entre o reconciler e a plataforma onde a aplicação está rodando, seja ela web, mobile ou desktop.

Por conta dessa arquitetura desacoplada, que permite que sejam criados vários renderers, APIs que se conectam com o react-reconciler e fazem a implementação na sua plataforma especifica, uma imagem bacana sobre isso:

Algoritmo

Agora sabemos que ele é quem faz todo o trabalho pesado de comparar e decidir o que precisa ser atualizado, varrendo toda a arvore de componentes e fazendo essas comparações.

Em uma perpectiva de performance, quanto menos nós sendo atualizados desnecessáriamente, melhor. Essa comparação e identificação é a chave para uma renderização eficiente.

Links para entender mais sobre o algoritmo de reconciliação:

Essas informações salvas dentro desse nó são importantes para que o Reconciler saiba qual nó ele precisa atualizar, e qual ele pode simplesmente ignorar pois não houve mudanças.

Stack Reconciler e Fiber Reconciler

Na versão 15 e anteriores, o react utilizava um algoritmo de reconciliação chamado de “Stack Reconciler”, a desvantagem dele era a performance: ele percorria toda a arvore de componentes de forma sincrona, componente a componente fazendo aplicando as mudanças, isso é passivo a problemas de performance como drop de frames em animações.

Por mais que isso fosse prejudicial, era possivel contornar esse problema de performance fazendo esse trabalho no tempo livre no final dos frames, fazendo uso do requestIdleCallback. Essa saída ajuda mas não é bala de prata porque nós ainda teriamos que percorrer a arvore toda de qualquer forma.

Para resolver de forma definitiva esse problema de performance, foi necessário permitir que o algoritmo pudesse pausar e continuar a execução de um update, além disso esse novo algoritmo introduziu formas de aplicar atualizações com base na prioridade (link para ler mais sobre).

Esse esquema de pausar e continuar os trabalhos, permite que o react quebre todo o trabalho de atualização em pequenos pacotes, essa técnica é chamada de “time-slicing”:

Explain the concept of time-slicing in Concurrent Mode

A versão 16 do react foi lançada em 2017, então ja faz um tempinho que teve essa mudança para o novo algoritmo, portanto talvez você ja deve ter percebido ou ouvido falar que alguns dos updates de estados no react não ocorrem de forma sincrona, em resumo é justamente isso que o novo algoritmo permite.

Lançamento do React v16.0

Árvore de Componentes React

O ‘Fiber Reconciler’ deu nome de cada ‘trabalho’ a ser feito nos componentes como um nodo Fiber, ele é a representação de um trabalho pendente ou um trabalho ja feito.

Esse trabalho a ser feito podem set vários tipos de tarefas, como por exemplo: Executar um ‘Efeito’ como useEffect (link), ou atualizar o estado de um componente (link) e assim por diante.

Mas somente saber o que precisa ser feito não da para construir uma arvore de componentes, precisamos de relações entre cada nodo, portanto dentro de um Fiber temos informações extras que nos ajudam a montar uma arvore, como por exemplo o estado atual do componente, as props, e referencias para os filhos, irmãos e pai, e lista de atualizações pendentes.

Tendo uma estrutura de árvore fica bem mais fácil navegar entre os nodos, saber qual deles tem alguma pendência, as dependencias dos nodos entre si, etc. E para poder fazer tudo isso acontecer foi quebrado em fases.

Na primeira fase do algoritmo (normalmente chamada de “Render phase”), o reconciler precisa entender primeiro qual nó precisa ser adicionado, atualizado, deletado, e também se teve algum efeito colateral a ser computado.

Esses componentes “alterados” são justamente o que vão ser usados na segunda fase!

Para ficar tangível esse comportamento, sugiro ver esse vídeo.

Na segunda fase (normalmente chamada de “Commit phase”), o reconciler teve tempo de calcular todas as mudanças necessárias, portanto agora ele precisa fazer (nessa ordem):

Depois que todas as mudanças foram aplicadas, o reconciler limpa a fila de tarefas e espera o próximo update :) E assim finalizamos o ciclo de vida de um update no react.

victor's hacker blog

Como transformei minha Alexa em um auto-falante inteligente para meu Mac

Procurando formas de usar a Echo como speaker

Instalando Android na Echo Show

Deu bom!

Sucesso !

Em busca de uma solução p/ redirecionar áudio

Desistindo e criando minha própria solução

Plano de implementação

Passo 1: coleta do áudio do PC

Passo 2: escrita de dados em um device USB

Passo 3: Um app conseguir ler os dados que vem pelo USB

Passo 4: Reproduzir o áudio no aparelho

Calculando a latência geral do projeto

Conclusão

Entender a Interoperabilidade Kotlin-Swift pode evitar que você cause bugs em produção

Usando frida para fazer debug em apps mobile

Introdução

Contexto sobre ferramentas usadas em AppSec

Capacidades, vantagens e desvantagens

Um exemplo simples de debug que fiz usando Frida

Conclusão

Renderização Declarativa - React Reconciler

Introdução

React

Reconciler & Renderer

Algoritmo

Stack Reconciler e Fiber Reconciler

Árvore de Componentes React

Referências