Scenario: ho un'app per Android che utilizza una libreria con licenza LGPL. Per soddisfare questa licenza, collego dinamicamente a quanto detto lib in runtime che consente all'utente di modificare il file .so se ci fosse un aggiornamento alla libreria o per qualsiasi altro motivo.
Problema: Per sostituire il file .so, l'utente dovrebbe decomprimere l'apk, sostituire il file .so, reimballarlo, quindi ridimensionarlo. Strumenti come apktool funzionano bene per questo, ma la mia app si basa in gran parte su un back-end che richiede che l'apk venga firmato dal mio keystore. Scambiare questa libreria renderebbe l'app inutilizzabile.
La mia soluzione: quando l'utente avvia l'app, semplicemente copio il file .so da casa sua in
"/ data / data / package name / lib" in una directory a cui l'utente può accedere. Quindi utilizzo void *handle = dlopen("path/to/external/storage", RTLD_NOW|RTLD_GLOBAL); per collegarmi alla libreria. Questa soluzione funziona alla grande permettendo all'utente di modificare liberamente il file .so a loro piacimento.
La mia domanda: ci sono dei rischi per la sicurezza? Oltre a guardare Mr. Robot, non ho esperienza con "hacking". In questo caso, qualcuno potrebbe modificare e compilare il proprio .so usando gli stessi simboli a cui collego permetterebbe loro di eseguire il loro codice dietro tutte le autorizzazioni che la mia app ha permesso. Si tratta di una potenziale minaccia o non importa, perché sarebbe solo sul dispositivo dell'utente? C'è un modo migliore per fare questo? Infine, ho anche bisogno di dare all'utente l'accesso in questo modo poiché tecnicamente possono decomprimere e ripacchettare l'apk per modificare il file .so in modo che la LGPL sia soddisfatta anche se non sarebbero in grado di superare l'attività di accesso dopo averlo fatto ?