Pentest en Flutter: lo que las herramientas genéricas no ven

Flutter se usa cada vez más en fintech, salud y e-commerce en LatAm — y eso lo pone en la mira. Pero auditar un APK Flutter no es lo mismo que auditar un APK Java/Kotlin: la lógica de la app se compila a un snapshot Dart AOT en lib/libapp.so, y las herramientas genericas (MobSF, apktool, jadx) no desensamblan eso.

Lo que sí se ve en Flutter

• AndroidManifest.xml: permisos, exported components, debuggable, allowBackup, networkSecurityConfig.
• Pool de strings del AOT: URLs, publishable keys, nombres de paquetes Dart, google-services.json inlineado.
• Código nativo (canales MethodChannel, plugins): si tienes lógica sensible en Kotlin/Java o en una .so, sí se analiza con Ghidra o radare2.
• Tráfico de red: igual que en cualquier APK — instalando una CA y capturando con mitmproxy o PCAPdroid.
• Comportamiento con Frida (instrumentación) si la app no se defendió con anti-Frida fuerte.

Lo que NO se ve automáticamente y sí importa

• Lógica de negocio Dart (reglas de cálculo, validaciones, RLS en cliente).
• Tokens generados en runtime o guardados en flutter_secure_storage mal configurado.
• Decisiones que se toman en el cliente (que deberían estar en el backend).

Checklist rápido (qué revisa ProtectPoint en Flutter)

1. Estático: manifest, permisos (incluso los de plugins), exported, networkSecurityConfig, componentes accesibles, certificados.
2. Strings del AOT: extracción de libapp.so con unzip + strings + búsqueda de URLs, API keys, paquetes, JWTs, google-services.
3. Native: .so de plugins (Firebase, mapas, pagos) con Ghidra si manejan crypto o RLS local.
4. SCA / SBOM: pubspec.lock con osv-scanner — 168 paquetes en el caso real sin CVEs, pero es obligatorio verificarlo.
5. Dinámico: instalar la app, captura de tráfico real (sin root con PCAPdroid), análisis de flujo, pruebas de IPC.
6. Frida: con el Gadget si la app lo permite; o sin root con el flujo de reempaquetado instrumentado.

Antipatrones comunes en Flutter LatAm

• Supabase RLS abierta en cliente: la anon key no es secreta, pero si las reglas permiten INSERT/UPDATE, el atacante crea datos sin sesión.
• Service role key en el cliente: crítico si pasó de un backend a un APK.
• Sin FLAG_SECURE: capturas de pantalla con datos financieros en recientes.
• Permisos sin justificación: micrófono/calendario/contactos/SMS sin una razón documentada.
• Firma de release con debug certificate: impide actualizaciones limpias y baja la confianza.
• Datos de sesión en SharedPreferences sin cifrar: flutter_secure_storage mal configurado o con accessibility incorrecta.

Ejemplo real

Auditamos una app de finanzas Flutter con Supabase. Encontramos:

• Firma con debug certificate (alto).
• Token de sesión en SharedPreferences + allowBackup=true (alto).
• 5 componentes exported sin permission (medio).
• Permisos de micrófono y calendario sin justificación (medio).
• API de tipo de cambio de un tercero no validado (medio).
• 168 dependencias con 0 CVEs (PASS para MASVS-CODE-3 vía SCA).

Lo bueno: la RLS de Supabase era correcta (200 [] sin sesión, 401 sin key). Lo crítico no fue el backend — fueron los detalles del cliente.

¿Cuándo auditar Flutter y cuándo no?

Audita Flutter cuando manejás: dinero, datos de salud, datos personales de terceros, o cuando un cliente/inversor/regulador te lo pide. Cuanto antes, más barato: corregir un fallo antes de release cuesta menos que en producción.