Risc de Dynamic Code Loading a Android: amenaces per a l'empresa
- El Dynamic Code Loading (DCL) permet carregar codi fora de l'APK original, creant fortreses de seguretat.
- Els atacants poden substituir fitxers DEX per executar accions malicioses amb els permisos de l'app.
- Google Play prohibeix moltes formes de DCL, especialment si provenen de fonts remotes no segures.
- Les empreses tecnològiques a Espanya han de revisar les seves arquitectures de plugins i actualitzacions.
La seguretat en el desenvolupament d'aplicacions mòbils ha deixat de ser una qüestió tècnica per convertir-se en un pilar estratègic per a qualsevol emprenedor del sector tech. Un dels punts més crítics i, sovint, menys vigilats és el fenomen del Dynamic Code Loading (DCL). Aquesta tècnica, tot i que ofereix flexibilitat per a els desenvolupadors, obre una porta posterior que els atacants poden aprofitar per comprometre totalment la integritat d'un dispositiu Android.
Què és exactament el Dynamic Code Loading?
El DCL és la capacitat d'una aplicació de carregar i executar codi que no formava part del paquet original (APK) al moment de la instal·lació. Aquesta pràctica és habitual en arquitectures basades en plugins, mòduls de funcions dinàmiques o marcs de treball per a correccions ràpides (hot-patch frameworks). Per aconseguir-ho, Android utilitza classes específiques com DexClassLoader, PathClassLoader o InMemoryDexClassLoader
L'objectiu teòric és permetre que l'app evolucioni o s'estengi sense haver de forçar l'usuari a descarregar una versió completa i nova des de la botiga. No obstant això, aquesta flexibilitat introdueix un risc sistèmic: si el codi que s'està carregant dinàmicament pot ser manipulat, l'aplicació es converteix en un vehicle per a l'atacant.
El mecanisme de l'atac i la substitucció de fitxers DEX
El perill real emergeix quan el codi DEX (Dalvik Executable) es carrega des d'una ruta on un atacant té permís d'escriptura. En molts casos, les aplicacions vulnerables configuren la ruta de càrrega en l'emmagatzematge extern del dispositiu, com ara la carpeta /sdcard/. En versions antigues de l'API d'Android, aquest espai era accessible per a qualsevol app amb permisos d'escriptura; en versions modernes, el risc persisteix si l'usuari concedeix accés a directoris compartits a través de l'emmagatzematge amb Àmbit (Scoped Storage).
Un atacant pot desplegar un fitxer DEX maliciosament construït en aquesta ruta. Si l'aplicació està programada per carregar una classe amb un nom específic i executar un mètode concret, l'atacant només ha de crear una classe que coincideixi amb aquest nom. Un cop l'app executa el mètode, el codi malicios corre amb el mateix UID i els mateixos permisos que l'aplicació original, cosa que permet accedir a dades sensibles o realitzar accions no autoritzades en nom de l'usuari.
Polítiques de Google Play i la mitigació de riscos
Google és plenament conscient d'aquest vector d'atac. Per aquest motiu, moltes formes de Dynamic Code Loading, especialment aquelles que utilitzen fonts remotes per descarregar codi, infringeixen les polítiques de Google Play. La companyia busca evitar que les aplicacions modifiquin el seu comportament de manera opaca després d'haver passat el procés de revisió de la botiga.
L'introducció de codi carregat dinàmicament en una aplicació introdueix un nivell de risc que ha de ser mitigat, ja que els atacants podrien manipular o substituir el codi per accedir a dades sensibles.
Per reduir aquests riscos, els desenvolupadors han de seguir certes pautes estrictes. La recomanació principal és evitar totalment l'ús de DCL si no és estrictament necessari. Si s'ha de fer servir, és imperatiu utilitzar fonts de confiança, realitzar comprovacions d'integritat rigoroses i signar digitalment el codi que s'està carregant per assegurar que no ha estat alterat durant el trànsit o l'emmagatzematge. Pots trobar més detalls sobre aquests riscos a la documentació oficial de Android Developers.
Vulnerabilitats en actualitzacions internes i RCE
Un altre angle crític és la implementació d'actualitzacions internes (in-app updates) que no segueixen els protocols de seguretat estàndard. Quan una aplicació gestiona el seu propi procés d'actualització descarregant components i executant-los, pot obrir la porta a una Execució Remota de Codi (RCE). Si el canal de descàrrega no és segur o si l'aplicació no verifica la signatura del fitxer descarregat, un atacant pot interceptar la connexió i injectar el seu propi codi.
Aquest tipus de vulnerabilitats són objecte d'estudi constant en el món del pentesting mòbil. L'ús d'eines de descompilació i anàlisi permet detectar ràpidament si una app utilitza classes com DexClassLoader i on busca els fitxers. La combinació d'una ruta d'escriptura poc segura i la càrrega dinàmica és la recepta perfecta per a un compromís total del sistema.
Estratègies de defensa per a equips de desenvolupament
Per protegir les aplicacions, els equips tècnics han de moure's cap a models de seguretat proactius. No es tracta només de corregir bugs, sinó de dissenyar l'arquitectura per eliminar el vector d'atac. Les mesures més efectives inclouen:
L'ús de l'API de Play Integrity per verificar que l'aplicació no ha estat modificada i que corre en un entorn segur. A més, és vital restringir l'accés a l'emmagatzematge extern i utilitzar el memòria interna privada de l'aplicació per a qualsevol component dinàmic, tot i que això no elimina el risc si el dispositiu està arrelat (rooted). Finalment, la implementació de checksums i signatures criptogràfiques per a cada mòdul carregat és la única manera de garantir que el codi executat és exactament el que els desenvolupadors han creat.
Impacte per a l'ecosistema empresarial a Catalunya i Espanya
Per a les empreses tecnològiques de Barcelona i el mercat espanyol, aquesta problemàtica té una rellevància especial en el context actual de regulació i creixement. Catalunya s'ha consolidat com un hub de startups i desenvolupament de software, on moltes aplicacions gestionen dades crítiques de sectors com la fintech, la salut o la logística. Una vulnerabilitat de DCL no és només un problema tècnic, sinó un risc legal i reputacional.
Amb l'entrada en vigor de l'AI Act i el reforç de les normatives de ciberseguretat a la Unió Europea, la responsabilitat del desenvolupador augmenta. Les empreses que implementen solucions d'IA dinàmiques en mòbils —que sovint requereixen actualitzacions freqüents de models o scripts— podrien caure en la temptació d'utilitzar el Dynamic Code Loading per optimitzar els processos. No obstant això, sota el marc normatiu europeu, la manca de diligència en la seguretat del codi pot derivar en sancions severes per falta de protecció de les dades dels usuaris.
El teixit empresarial català, caracteritzat per una gran agilitat, ha de integrar el seguretat des del disseny (Security by Design). Això implica que els CTOs i els líders de producte a Espanya no poden veure la seguretat com una fase final de revisió, sinó com una part integral del cicle de vida del desenvolupament. En un mercat on la confiança del consumidor és el principal actiu, evitar vulnerabilitats com el DCL és essencial per mantenir la competitivitat i l'escalabilitat a nivell global.
Preguntes freqüents
Què és el fitxer DEX en Android?
El fitxer DEX (Dalvik Executable) és el format de codi compilat que utilitza la màquina virtual d'Android per executar les aplicacions.
Per què el Dynamic Code Loading és perillós?
És perillós perquè permet que l'aplicació executi codi que no estava present en l'instal·lació original, i si un atacant pot substituir aquest codi, pot prendre el control de l'app.
Google Play permet el Dynamic Code Loading?
Google Play prohibeix moltes implementacions de DCL, especialment si el codi es descarrega de fonts remotes, per evitar que les apps canviin el seu comportament després de la revisió.
Com poden les empreses catalanes evitar aquest risc?
Implementant seguretat des del disseny, evitant el DCL sempre que sigui possible i utilitzant l'API de Play Integrity per verificar l'estat de l'aplicació.
Fonts: Developer, Hacktricks, Nirajkharel ·
glacom · IA per a restaurants: reserves, comandes i un telèfon que respon →Scrivila qui: Susanna, l assistente AI di glacom, ti risponde via email con un approfondimento gratuito.
Nessuna consulenza personalizzata (finanziaria, legale o medica): solo informazione e fonti. Email usata solo per rispondere.
oppure scrivile su: WhatsApp · Telegram · SimpleX · Delta Chat · Email
