Protecció de fitxers APK¶
Els desenvolupadors es veuen en la necessitat de protegir les seves aplicacions Android de manera que un hacker no en pugui manipular el codi o els recursos.
És impossible evitar completament l'enginyeria inversa, però existeixen estratègies per fer-la més difícil.
Limitacions
Cap mètode pot garantir una protecció del 100% contra l'enginyeria inversa. Qualsevol protecció implementada pot ser desactivada o eliminada per un atacant determinat, però es poden prendre mesures per fer que sigui més difícil.
Enginyeria inversa d'aplicacions¶
Utilitzant l', els atacants descompilen i analitzen el codi de l'aplicació per descobrir vulnerabilitats, extreure dades sensibles o replicar-ne funcionalitats pròpies.
Les aplicacions d'Android es desenvolupen normalment amb Java o Kotlin, i després de la compilació, es converteixen en bytecode que s'executa a l'Android Runtime (ART) o a la màquina virtual Dalvik.
Aquest bytecode s'emmagatzema en fitxers .dex que es poden descompilar amb relativa facilitat en un format llegible mitjançant eines d'enginyeria inversa com JADX o ApkTool. Un cop descompilat, els atacants poden analitzar el codi per:
- identificar i explotar vulnerabilitats
- manipular el comportament de l'aplicació
- crear aplicacions que imiten l'original per enganyar els usuaris
- descobrir claus d'API
- esbrinar el funcionament d'algorismes de xifratge
- analitzar o copiar la lògica de codi propietari
- etc.
Estratègies de protecció¶
Ofuscació del codi¶
Consisteix a transformar el codi en una versió difícil d'entendre per als humans, mentre segueix sent totalment funcional per a la màquina.
S'oculta el funcionament intern de l'aplicació canviant el nom de classes, mètodes i variables per identificadors sense sentit, i s'altera el flux de control per fer que la lògica del codi sigui més difícil de seguir.
L'ofuscació no és una protecció en sí mateixa. El seu objectiu és fer que el codi descompilat sigui confús i requereixi molt de temps per ser analitzat pels atacants, complicant significativament el procés d'enginyeria inversa.
L'SDK d'Android inclou l'eina ProGuard per ofuscar, minificar i compactar el codi abans de distribuir-lo.
Exemple d'ofuscació de codi:
console.log( "Hello, world!" );
var _0x8b75=["\x48\x65\x6C\x6C\x6F\x2C\x20\x77\x6F\x72\x6C\x64\x21","log"];
console[_0x8b75[1]](_0x8b75[0])
Minificació
És un procés molt utilitzat sobretot en programació web per reduir la mida del codi.
D'aquesta manera s'economitzen dades i de passada es redueix el temps de descàrrega des del servidor web.
Exemple de minificació de codi:
// Funció que retorna el doble d'un número (aquest comentari s'eliminarà)
function doble(numero) {
return numero * 2;
}
const d=n=>2*n
Finalitat de l'ofusacació
A vegades n'hi ha prou que els hackers necessitin invertir molt de temps per crackejar una aplicació.
Això dona una finestra de beneficis més àmplia als productes comercials, que sabran que reduiran les seves vendes un cop passat el període de novetat al mercat i el moment que siguin crackejades.
Aquesta és l'estratègia que s'utilitza quan es protegeix productes amb sistemes d'ofuscació i xifrat dinàmic com ara Denuvo a la indústria dels videojocs. Un cop superada la finestra de benefici, es pot retirar aquesta protecció sense afectar significativament les vendes.
Xifrat¶
Consisteix a xifrar recursos i dades sensibles mitjançant algun algorisme de xifrat reversible.
S'utilitza per protegir recursos com ara fitxers de configuració, claus d'API i altra informació sensible que es pugui exposar durant els intents d'enginyeria inversa.
Per minimitzar els riscos, les dades a desxifrar poden no estar contingudes dins del fitxer APK, sino que es descarreguin d'un servidor en temps d'execució per desxifrar-se després dins de l'aplicació.
Això afegeix una capa addicional de seguretat, ja que els recursos no són directament accessibles des de l'APK encara que sigui descodificat amb apktool.
Ús de biblioteques natives¶
Consisteix a utilitzar biblioteques natives escrites en C o C++ al codi de parts crítiques de l'aplicació. Aquestes es compilen a fitxers .so, que són més difícils de descompilar que el codi en Java o Kotlin.
Processament a un servidor extern¶
Consisteix a moure el codi de funcionalitats crítiques de l'aplicació a un servidor remot.
Per fer-ho s'implementa el codi a protegir a un servidor extern, i l'aplicació s'hi comunica a través de xarxa per processar les dades. D'aquesta manera, el codi sensible mai es distribueix amb l'APK.
Important: caldrà assegurar la disponibilitat
L'aplicació no podrà funcionar si no hi ha connexió de xarxa o si el servidor remot no és accessible.
Detecció de root¶
Ser root a un dispositiu dóna a un atacant privilegis elevats, cosa que li permet evitar moltes restriccions de seguretat que normalment imposa Android.
Les tècniques de detecció de root poden identificar si l'aplicació s'està executant a un dispositiu rootejat comprovant indicadors com ara:
- presència de binaris de superusuari (p.ex.
/sbin/su) - processos executant-se amb privilegis inusualsment elevats
- modificacions a la partició del sistema
- rutes de fitxer sospitoses (p.ex. fora del path del sistema)
- etc.
En detectar l'accés root, una aplicació pot actuar en conseqüencia i impedir la seva execució, restringir determinades funcions o activar mesures de seguretat addicionals.
Detecció de virtualització¶
Els atacants solen utilitzar entorns de virtualització, com ara emuladors d'Android o màquines virtuals, per analitzar i manipular aplicacions de manera segura.
Aquests entorns es poden detectar comprovant certes característiques del maquinari, com ara:
- propietats inusuals de la CPU
- existència de fitxers específics
- mancança de sensors físics
- etc.
En detectar que s'està executant en un entorn virtualitzat, una aplicació pot actuar en conseqüencia i impedir la seva execució, restringir determinades funcions o activar mesures de seguretat addicionals.