[JAVA] "proteggere il codice"

[giuseppe sicari]

Esiste un modo per proteggere o quantomeno rendere incomprensibile il codice java ?
Cioè se io mi faccio un c*** così per fare un lavoro e in una JLabel metto "realizzato da Giuseppe Sicari" posso evitare che qualcuno "decompili" il bytecode ottenendo il .java e vada a sostituire la stringa cambiando l'autore?
Mi pongo questo problema perchè vorrei rendere "scaricabili" (in una sezione del mio sito) i miei programmi senza che però qualcuno li modifichi...

[unomichisiada]

L'argomento è già stato trattato ma al momento non ti so indicare il thread esatto,prova a fare una ricerca.Comunque esistono degli offuscatori che rendono difficile (o forse impossibile non so) la decompilazione del bytecode.Inoltre nel thread in cui l'argomento è stato già trattato qualcuno aveva parlato di programmi che sostituiscono tutti i nomi dei metodi e delle variabili originari con altri senza alcun valore autoesplicativo (cioè ad esempio la variabile numLines indicante evidentemente il numero di linee di qualcosa viene sostituita con a,o ancora peggio con hsksfy e roba del genere) rendendo la comprensione del codice decompilato a dir poco ardua e offrendo quindi una buona protezione.

[kateetak]

Le aziende usano spesso questi "offuscatori di codice" per proteggere il loro lavoro.
Avevo anche sentito dire che questi programmi aggiungono delle istruzioni che non fanno nulla, ad esempio aggiungono un ciclo che incrementa una variabile usata e necessaria all'interno del codice sino a 10 e poi la fanno tornare al valore reale.

Credo che sia difficile sapere cosa fanno realmente perchè sapendo esattamente come funzionano qualcuno costruirebbe il codice per recuperare il codice correttamente.

[conqueror]

controlla qui

retroguard

[abcd1000]

purtroppo però l'offuscatore non può cambiare le stringhe e quindi se nel codice c'è scritto "realizzato da Pippo" quando decompilando le classi, basta che fanno una ricerca per la suddetta stringa e la possono sostituire

[unomichisiada]

purtroppo però l'offuscatore non può cambiare le stringhe e quindi se nel codice c'è scritto "realizzato da Pippo" quando decompilando le classi, basta che fanno una ricerca per la suddetta stringa e la possono sostituire

Azz...
Comunque qualcosa ci sarà di sicuro pure per questo problema.Da questo punto di vista proteggere un eseguibile "tradizionale" è molto più semplice (anche se come al solito la protezione non è al 100%)

[abcd1000]

penso proprio di no, cmq se scopri qualcosa di nuovo postalo che sarebbe interessante

[LeleFT]

Io tempo fa avevo scaricato una applet Java che generava in automatico un'altra applet per l'accesso a pagine internet. In questa seconda applet (quella generata) c'erano salvati Nome Utente e password di tutti coloro che erano abilitati all'accesso. Quindi mi sono incuriosito: ho decompilato tale applet e, sorpresa, tutte le stringhe erano illeggibili. Il trucco? Semplice: colui che ha scritto l'applet ha scritto anche un algoritmo per criptare e decriptare le stringhe, rendendole, in questo modo, illeggibili da parte di chi avesse decompilato il bytecode.
Quindi, perchè non fai lo stesso anche tu? Invece di lasciare le stringhe in chiaro nel tuo programma, scrivi una piccola applicazione (anche solo per consolle) che prenda in input una stringa e ne dia come output la stringa codificata, poi nella tua applicazione inserisci il metodo opposto, che legga una stringa codificata e la decodifichi run-time. In questo modo puoi inserire nella tua applicazione le stringhe codificate, che verranno visualizzate correttamente solamente in fase d'esecuzione.
Certamente questo metodo non ti offre la sicurezza, però renderà sicuramente ardua la vita a chi volesse cimentarsi nel reverse ingegneering per tentare di carpirne l'algoritmo!

Ciao.

[unomichisiada]

Semplice: colui che ha scritto l'applet ha scritto anche un algoritmo per criptare e decriptare le stringhe, rendendole, in questo modo, illeggibili da parte di chi avesse decompilato il bytecode.

Ottima idea!!!