Autore Topic: Sicurezza applicazione  (Letto 1601 volte)

Offline topix93

  • Utente junior
  • **
  • Post: 84
  • Respect: +1
    • Google+
    • Mostra profilo
  • Dispositivo Android:
    LG Optimus ONE
  • Sistema operativo:
    Windows 7 Professional 64 bit, Ubuntu 11.04
Sicurezza applicazione
« il: 06 Settembre 2012, 16:11:12 CEST »
0
C'è un modo efficace per impedire al meglio che la propria applicazione apk possa venire disassemblata?

Offline bradipao

  • Moderatore globale
  • Utente storico
  • *****
  • Post: 4043
  • keep it simple
  • Respect: +567
    • Github
    • Google+
    • bradipao
    • Mostra profilo
  • Dispositivo Android:
    Nexus 5
  • Play Store ID:
    Bradipao
  • Sistema operativo:
    W7
Re:Sicurezza applicazione
« Risposta #1 il: 06 Settembre 2012, 16:22:25 CEST »
0
C'è un modo efficace per impedire al meglio che la propria applicazione apk possa venire disassemblata?

A parte varie risposte che parlano di Proguard e offuscamenti vari, per impedirlo al meglio secondo me dovresti scriverla nativa con NDK.
NON rispondo a domande nei messaggi privati
Bradipao @ Play Store

Offline topix93

  • Utente junior
  • **
  • Post: 84
  • Respect: +1
    • Google+
    • Mostra profilo
  • Dispositivo Android:
    LG Optimus ONE
  • Sistema operativo:
    Windows 7 Professional 64 bit, Ubuntu 11.04
Re:Sicurezza applicazione
« Risposta #2 il: 06 Settembre 2012, 16:37:28 CEST »
0
puoi darmi qualche dettaglio in piu? perche non ho la piu pallida idea di cosa sia ndk e cosa voglia dire scriverla nativa

Offline undead

  • Utente senior
  • ****
  • Post: 666
  • Respect: +113
    • Mostra profilo
  • Dispositivo Android:
    Samsung Galaxy S6
  • Play Store ID:
    DrKappa
  • Sistema operativo:
    Windows 10 64-bit, Windows 8.1 64-bit
Re:Sicurezza applicazione
« Risposta #3 il: 06 Settembre 2012, 16:42:47 CEST »
0
NDK = native development kit = kit di sviluppo nativo

Codice nativo in spiccioli significa che invece di farti la app in java te la fai in C/C++ senza tutte le comodità del caso. Significa anche che ti scegli una CPU di riferimento (tipo arm7) e buonanotte a quelli che hanno un altro tipo di architettura (visto che ora iniziano ad uscire cellulari con x86).

Però occhio le stringhe che ci infili dentro non sono protette nemmeno su codice nativo.  :-(

Offline iceweasel

  • Moderatore globale
  • Utente senior
  • *****
  • Post: 878
  • Respect: +147
    • Mostra profilo
  • Dispositivo Android:
    LGE P990 - Google Nexus 5
  • Sistema operativo:
    Linux Debian Sid
Re:Sicurezza applicazione
« Risposta #4 il: 06 Settembre 2012, 18:16:52 CEST »
0
e buonanotte a quelli che hanno un altro tipo di architettura (visto che ora iniziano ad uscire cellulari con x86).

L'ultima versione ufficiale del NDK supporta ARM6, ARM7 (+ NEON), x86 e MIPS.
adb logcat | tee /tmp/logcat | grep TAG

Offline undead

  • Utente senior
  • ****
  • Post: 666
  • Respect: +113
    • Mostra profilo
  • Dispositivo Android:
    Samsung Galaxy S6
  • Play Store ID:
    DrKappa
  • Sistema operativo:
    Windows 10 64-bit, Windows 8.1 64-bit
Re:Sicurezza applicazione
« Risposta #5 il: 06 Settembre 2012, 18:26:50 CEST »
0
Lo so ma ti faccio un esempio. Io compilo una libreria nativa e devo settare il target. Se la compilo ARM7 e ARM7 con NEON che succede quando la carico da java?
Io suppongo venga selezionata tra le librerie quella compatibile o sbaglio?

Ovviamente se tu hai un x86 e non ho compilato per x86 (perchè magari ho codice assembly per ARM) la libreria non si carica.

Ma se io invece di avere una libreria ho una nativeactivity come fa a funzionare???? L'activity che viene lanciata dovrebbe essere univoca ma se io ne ho 4????

Chiedo perchè io ho sempre supposto (magari sbagliando) che le loadlibrary si possono "scegliere" la libreria ma l'activity si dichiara nel package e carica quella.

Offline iceweasel

  • Moderatore globale
  • Utente senior
  • *****
  • Post: 878
  • Respect: +147
    • Mostra profilo
  • Dispositivo Android:
    LGE P990 - Google Nexus 5
  • Sistema operativo:
    Linux Debian Sid
Re:Sicurezza applicazione
« Risposta #6 il: 06 Settembre 2012, 19:49:42 CEST »
0
Non esistono le native activity (almeno non ancora), al massimo è possibile avere dei programmi su linea di comando nativi.

Il programmatore decide con quali architetture compilare il codice C/C++. Le librerie dinamiche sono messe in directory separate in base all'architettura, il framefork Android seleziona, se presente, la libreria richiesta. Per i dettagli è tutto documentato.
adb logcat | tee /tmp/logcat | grep TAG

Offline undead

  • Utente senior
  • ****
  • Post: 666
  • Respect: +113
    • Mostra profilo
  • Dispositivo Android:
    Samsung Galaxy S6
  • Play Store ID:
    DrKappa
  • Sistema operativo:
    Windows 10 64-bit, Windows 8.1 64-bit
Re:Sicurezza applicazione
« Risposta #7 il: 07 Settembre 2012, 10:35:45 CEST »
0
Non esistono le native activity (almeno non ancora), al massimo è possibile avere dei programmi su linea di comando nativi.
NativeActivity | Android Developers
??

Citazione
Il programmatore decide con quali architetture compilare il codice C/C++. Le librerie dinamiche sono messe in directory separate in base all'architettura, il framefork Android seleziona, se presente, la libreria richiesta. Per i dettagli è tutto documentato.
Si quello che mi ricordavo/supponevo per le librerie.

Offline iceweasel

  • Moderatore globale
  • Utente senior
  • *****
  • Post: 878
  • Respect: +147
    • Mostra profilo
  • Dispositivo Android:
    LGE P990 - Google Nexus 5
  • Sistema operativo:
    Linux Debian Sid
Re:Sicurezza applicazione
« Risposta #8 il: 07 Settembre 2012, 12:52:02 CEST »
0
NativeActivity | Android Developers
??

Si è vero, un mio errore credevo non ancora possibile, è stato aggiunto dal API 9, mi era sfuggito, il bello che ho compilato l'esempio presente nel NDK senza notare l'assenza della parte in Java.

E' possibile creare native activity (senza una riga di codice Java), la gestione della grafica è affidata alle OpenGL-ES.

In realtà ho esaminato i sorgenti di Android il codice Java esiste. Il codice nativo è una shared library, non è un eseguile ELF,  non c'è il "main" classico del C/C++ ma c'è "android_main" con parametri diversi. Activity Java è presente nel frameword di Android e non distribuita insieme al file .apk,  si chiama appunto "android.app.NativeActivity" e vuole un parametro via meta dati col nome della libreria nativa principale.

Codice: [Seleziona]
<activity android:name="android.app.NativeActivity">
      <meta-data android:name="android.app.lib_name" android:value="native-activity" />
...
</activity>

Non mi risulta possibile creare una vera native activity senza utilizzare un oggetto Java instanziato in qualche modo per interfacciarsi al framework Java di Android.
adb logcat | tee /tmp/logcat | grep TAG

Offline undead

  • Utente senior
  • ****
  • Post: 666
  • Respect: +113
    • Mostra profilo
  • Dispositivo Android:
    Samsung Galaxy S6
  • Play Store ID:
    DrKappa
  • Sistema operativo:
    Windows 10 64-bit, Windows 8.1 64-bit
Re:Sicurezza applicazione
« Risposta #9 il: 07 Settembre 2012, 12:56:31 CEST »
0
Ok questo ha molto più senso, infatti se non si passasse da un elemento che carica la libreria/modulo non si potrebbe assicurare la compatibilità con più CPU.

Offline topix93

  • Utente junior
  • **
  • Post: 84
  • Respect: +1
    • Google+
    • Mostra profilo
  • Dispositivo Android:
    LG Optimus ONE
  • Sistema operativo:
    Windows 7 Professional 64 bit, Ubuntu 11.04
Re:Sicurezza applicazione
« Risposta #10 il: 21 Settembre 2012, 16:08:05 CEST »
0
proguard non offusca quasi niente... c'è un modo piu semplice rispetto alle native activity per offuscare il codice?