Nasconde la mia app per desktop Java all'interno di una VM il modo migliore per proteggere il mio codice sorgente Java?

Question

Nasconde la mia app per desktop Java all'interno di una VM il modo migliore per proteggere il mio codice sorgente Java?

#1 da (3 voti)

0

Ho bisogno di distribuire un'applicazione desktop Java all'utente. Sto osservando diversi modi per proteggere il mio codice sorgente dal reverse engineering.

Un metodo è quello di distribuire una Macchina Virtuale (dice Linux) contenente l'app in esecuzione all'interno di quella VM, e rendere l'utente root di quella avente una password di ad es. 50 caratteri. Lo svantaggio è che la dimensione del download della mia app è troppo grande (alcuni Gigas). E la prossima domanda è: un utente malintenzionato può leggere il mio codice Java da un'immagine di disco VDI?

Un altro metodo è Ahead of Time (AOT) che compila in nativo. ExcelsiorJet sembra essere lo strumento migliore per questo, tuttavia non è gratuito. L'offuscamento del codice sorgente NON è sufficiente, dal momento che quelli che vogliono leggere il codice sorgente sono quelli che vogliono principalmente preoccuparsi del flusso di informazioni e della struttura dei dati. Questo eccellente articolo spiega di più su AOT e offuscamento. Ora la domanda è: usando ExcelsiorJet per compilare in modo nativo, il mio codice nativo è relativamente sicuro dal reverse engineering?

Ancora un altro modo: ad es. usa C ++ per scrivere il codice più sicuro per la sicurezza, compilarlo su reale nativo ed esporre la mia irrilevante fonte Java. Ma questo significa che avrò bisogno di mantenere entrambe le parti.

java source-code protection

posta Ken Po 08.08.2018 - 16:21

fonte

1 risposta

Leggi altre domande sui tag java source-code protection

Avviso che genera payload OS X con msfvenom Il mio sistema è stato attaccato o sta attaccando

score 3 · Answer 1

Questa domanda è al limite della richiesta / parere di raccomandazione del prodotto, ma proverò a rispondere alle parti che sono in argomento.

Prima di tutto, i bravi tecnici del reverse sono buoni . Con abbastanza abilità e tempo, java source, java bytecode, c ++ source e assembly nativo sono tutti equivalenti in termini di mostrare a un utente malintenzionato come funziona il tuo software.

Basandosi sul commento di @ Zymus, stai iniziando con requisiti in conflitto, che desideri:

Fornisci il codice sorgente a persone / macchine di cui non ti fidi, ma
Non vuoi che sia retroattivo.

Se il computer su cui sono seduti è in grado di capire ed eseguire il codice, allora (con abbastanza impegno) può farlo anche l'umano. Full Stop.

Quando il tuo punto di partenza è "Voglio dargli il mio codice, ma non voglio dargli il mio codice" , non mi sorprende che non trovi una soluzione .

Risposta diretta alle tue domande:

can an attacker read my Java code from inside a VDI disk image ?

Bene, il computer può leggere (ed eseguire) il codice Java da un'immagine di disco VDI? Se è così, lo può anche l'aggressore.

Obfuscating the source code is NOT enough,

Ok, siamo tornati ai requisiti in conflitto qui; l'offuscamento è l'atto di creare codice che può ancora essere gestito da una macchina, ma è difficile da comprendere per un essere umano. Dici che non è abbastanza buono: vuoi consentire al malintenzionato di eseguire il tuo codice, ma non di leggere il tuo codice. Non ha senso.

is my native code relatively safe from reverse engineering ?

Still another way: to e.g. use C++ to write the most security critical code, compile it to real native, and expose my unimportant Java source.

Perché pensi che il codice nativo sia più difficile da decodificare di Java? Certo, c'è un maggior numero di curve di apprendimento per il reverse engineering assembly con strumenti come IDA Pro rispetto al reverse-engineering java con jad, ma per un bravo reverse-engineer, lo sforzo è molto simile.

Mi piace il suggerimento di @Zymus: se ci sono bit di codice che non vuoi che l'attaccante abbia, allora non darglielo; eseguilo su un server e fornisci un'API che espone solo l'input e l'output (meno sensibile)