Probabilmente è lo stesso motivo per cui non vuoi rilasciare un programma C / C ++ con i flag -g . I simboli non necessari sono probabilmente strappati via o occultati. Il sistema di compilazione potrebbe escludere alcune misure di sicurezza che renderanno il debug dell'applicazione notevolmente più semplice. Probabilmente gli script di build di Pro-guard non sono inclusi in una build di debug.
I seguenti sono diversi tipi di dati che possono essere conservati nelle build di debug a seconda della configurazione. Spero che tu possa capire perché questi potrebbero essere utili a qualcuno che cerca di decodificare la tua applicazione.
Simboli di debug
I simboli di debug sono pezzi di informazione selezionati che sono memorizzati nel binario di debug. Tutti i nomi delle funzioni, i nomi dei file, a volte anche i numeri di riga sono inclusi. In questo modo, quando un programma si arresta in modo anomalo e viene collegato un debugger, tutte queste informazioni possono essere incluse nelle tracce dello stack. Consente al programmatore di individuare la riga di codice che causa un bug. Una traccia dello stack di debug potrebbe essere simile alla seguente ( presa da questa risposta ):
Exception in thread "main" java.lang.NullPointerException
at com.example.myproject.Book.getTitle(Book.java:16)
at com.example.myproject.Author.getBookTitles(Author.java:25)
at com.example.myproject.Bootstrap.main(Bootstrap.java:14)
Un programma senza simboli di debug conoscerà solo le definizioni di libreria. Mi piace il seguente:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fd3700 (LWP 22532)]0x00007fffe10002b4 in ?? ()
(gdb) bt
#0 0x00007fffe10002b4 in ?? ()
#1 0x0000000000000202 in ?? ()
#2 0x00007fffe1000160 in ?? ()
#3 0x00007ffff66bd1a9 in execute_internal_vm_tests () at /home/bionix/Openjdk8/hotspot/src/share/vm/prims/jni.cpp:5128
#4 0x00007ffff7fd2550 in ?? ()
#5 0x00007ffff6b08bf8 in VM_Version::get_cpu_info_wrapper () at /home/bionix/Openjdk8/hotspot/src/cpu/x86/vm/vm_version_x86.cpp:395
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
ProGuard in Android
All'interno degli script di build Android (Gradle) troverai riferimenti a ProGuard. ProGuard viene utilizzato per ottimizzare, ridurre le dimensioni binarie e offuscare il codice. Poiché Java può essere completamente decompilato, Android utilizza ProGuard per offuscare il codice. Ecco un esempio di codice che è stato offuscato da ProGruard:
// Before
btnNew = changeButtonLabel(btnNew, language.getText("new"));
btnOpen = changeButtonLabel(btnOpen, language.getText("open"));
// After
d = a(d, n.a("new"));
e = a(e, n.a("open"));
Puoi visualizzare tutorial completo con link al codice sorgente.
Dalla documentazione Android linkata sopra:
ProGuard is integrated into the Android build system, so you do not
have to invoke it manually. ProGuard runs only when you build your
application in release mode, so you do not have to deal with
obfuscated code when you build your application in debug mode.
ProGuard è tecnicamente opzionale, ma quando si utilizza Android Studio è abilitato per impostazione predefinita per le build di rilascio.
Registrazione debug
Dovresti sempre avere qualche meccanismo nel codice per rimuovere i messaggi di debug dall'applicazione di rilascio. I messaggi di debug sono memorizzati come stringhe all'interno del file binario e non vengono offuscati. Il che significa che se hai un messaggio come Log.d("Key " + super_secrey_key); una persona che analizza il binario ora saprà dove viene fatto riferimento a "Key " . Ora hai fornito il contesto e un posto interessante per iniziare l'analisi.
Esistono diversi modi per rimuovere i log di debug e uno di questi è configurando ProGuard per eliminarli. Esistono anche altre librerie che puoi utilizzare oppure termina la registrazione . In entrambi i casi è importante distinguere tra debug e release per i messaggi di log.