obfuscators solito semplicemente cambiano classi, metodi e nomi campi di nomi che non hanno alcun significato. Quindi, se hai "ScoreCalculator.computeScore (Player p, Match m)" finisci con "A.zk (F f, R r)". Questo è simile a ciò che il compilatore Uglify o Closure fa per javascript, tranne che in javascript è per ridurre la lunghezza della sorgente.
E 'possibile capire ciò che il metodo fa in ogni caso, è solo più difficile.
Aslo, Java utilizza l'associazione tardiva (come DLL o SO file). Quindi, le chiamate che vanno fuori dal tuo codice (come i pacchetti java.util, java.lang etc ..) non possono essere offuscate. Inoltre, se il tuo codice ha bisogno di ricevere chiamate dall'esterno (un tipico esempio, registra un listener su un pulsante), quel codice non può essere offuscato. Lo stesso accade per una DLL, in cui è possibile vedere chiaramente il nome del metodo che deve essere chiamato modulo all'esterno della DLL e chiama ad altre DLL.
Tuttavia, la mappatura tra un determinato codice sorgente e il codice compilato non è necessariamente uno a uno. I compilatori C più vecchi utilizzavano lo stesso codice operativo per una determinata direttiva sorgente, quindi i decompilatori erano molto efficaci. Quindi i compilatori C hanno aggiunto molte ottimizzazioni al codice operativo risultante e queste ottimizzazioni hanno reso il decompilatore in gran parte inefficace [1]
Java non ha mai implementato (molte) ottimizzazioni in fase di compilazione, perché per funzionare su piattaforme diverse (ivi compresi diversi dispositivi Android), Java ha deciso di applicare seri ottimizzazioni in un secondo momento, in fase di esecuzione, in base alle proprietà dell'architettura e dell'hardware del dispositivo in esecuzione (questo è ciò che "HotSpot" è per lo più su [2]).
I buoni offuscatori solitamente riordinano anche le istruzioni del codice, o ne inseriscono alcune inutili, o applicano anticipatamente alcune ottimizzazioni per rendere i decompilatori incapaci (o meno) di derivare il codice sorgente in modo così semplice.
Questa tecnica è inutile quando si tratta di persone che possono leggere bytecode, come qualsiasi possibile C offuscamento è inutile se una persona può leggere il codice assembler.
Come molti software di cracking dimostrano, reverse engineering è sempre possibile, anche con C o altri laguages, anche su firmware (pensare firmware iPhone), causare il client il codice è in esecuzione su è sempre attendibile, e può sempre essere manomesso con.
Se si dispone di molto mission critical codice, qualcosa che vale un sacco di soldi che qualcun altro potrebbe rubare, io suggerirei di farlo funzionare lato server, o convalidarlo lato server in qualche modo.
LOL! Non hai applicato proguard al tuo apk? Se la risposta è no, questa è la tua risposta! :) – t0mm13b
Ho usato Proguard e ho modificato il file project.properties prima di rel, facilitando la mia app. Devo dire che i nomi delle classi non sono il mio originale, ma tutti i nomi dei metodi sembrano originali. Cioè invertire la mia app è facile, perché sono cambiati solo i nomi delle classi. EDIT: Sembra anche che i nomi dei metodi statici siano cambiati. Ma invertire questo è difficilmente una scienza missilistica. –
Puoi pubblicare il tuo proguard.cfg? E avete controllato [esempi] (http://proguard.sourceforge.net/index.html#manual/examples.html) – t0mm13b