Creazione di programmi Java non retroingegnerizzabili

Question

Esiste un modo per distribuire un programma Java in un formato non retroingegnerizzabile?

So come convertire la mia applicazione in un file JAR eseguibile, ma voglio assicurarmi che il codice non possa essere retroingegnerizzato, o almeno non facilmente.

L'offuscamento del codice sorgente non conta ... rende più difficile la comprensione del codice, ma non lo nasconde.

Una domanda correlata è Come bloccare compilato Classi Java per prevenire la decompilazione?

---

Una volta completato il programma, avrei comunque accesso alla fonte originale, quindi mantenere l'applicazione non sarebbe il problema. Se l'applicazione viene distribuita, non vorrei che nessuno degli utenti fosse in grado di decompilarla. L'offuscamento non raggiunge questo obiettivo poiché gli utenti sarebbero ancora in grado di decompilarlo e, sebbene avessero difficoltà a seguire i flussi di azioni, sarebbero in grado di vedere il codice e potenzialmente estrarre informazioni da esso.

Quello che mi preoccupa è se ci sono informazioni nel codice relative all'accesso remoto. Esiste un host a cui l'applicazione si connette utilizzando un ID utente e una password forniti dall'utente. C'è un modo per nascondere l'indirizzo dell'host all'utente, se tale indirizzo si trova all'interno del codice sorgente?

Answer 1

Puoi offuscare il tuo file JAR con YGuard . Non offusca il tuo codice sorgente , ma le classi compilate, quindi non c'è problema a mantenere il codice in un secondo momento.

Se vuoi nascondere qualche stringa, puoi crittografarla, rendendo più difficile esaminarla nel codice sorgente (è ancora meglio se offuschi il file JAR).

Answer 2

La risposta breve è " No, non esiste " ;.

Il reverse engineering è un processo che non implica affatto la visualizzazione del codice . In pratica sta cercando di capire i meccanismi sottostanti e quindi di imitarli. Ad esempio, ecco come appare JScript dai laboratori MS, copiando il comportamento JavaScript di Netscape, senza avere accesso al codice. La copia era così perfetta che anche i bug venivano copiati.

Answer 3

Se sai quali piattaforme stai prendendo di mira, ottieni qualcosa che compili il tuo Java in codice nativo, come Excelsior JET o GCJ .

A parte questo, non sarai mai in grado di nascondere il codice sorgente, poiché l'utente ha sempre il tuo bytecode e può Jad esso.

Answer 4

Stai scrivendo in una lingua che ha introspezione come parte della lingua principale. Genera file .class le cui specifiche sono ampiamente note (consentendo così ad altri fornitori di produrre implementazioni in clean room di compilatori e interpreti Java).

Ciò significa che ci sono decompilatori pubblicamente disponibili. Bastano poche ricerche su Google e hai del codice Java che fa la stessa cosa della tua. Solo senza i commenti e alcuni dei nomi delle variabili (ma i nomi delle funzioni rimangono gli stessi).

In realtà, l'offuscamento è tutto ciò che puoi ottenere (anche se il codice decompilato sarà già leggermente offuscato) senza andare in C o in qualche altro linguaggio completamente compilato,

Answer 5

Non usi una lingua interpretata? Cosa stai cercando di proteggere comunque? Se è abbastanza prezioso, tutto può essere decodificato. Le possibilità che qualcuno si preoccupi abbastanza di decodificare la maggior parte dei progetti è minima. L'offuscamento fornisce almeno un ostacolo minimo.

Assicurati che la tua proprietà intellettuale (IP) sia protetta tramite altri meccanismi. Soprattutto per il codice di sicurezza, è importante che le persone siano in grado di ispezionare le implementazioni, in modo che la sicurezza sia nell'algoritmo, non nella fonte.

Answer 6

Sono tentato di chiedere perché vorresti farlo, ma lo lascerò solo ...

Il problema che vedo è che la JVM, come il CLR, deve essere in grado di comprendere il codice per poterlo compilare ed eseguirlo. Puoi renderlo più "complesso" ma dato che le specifiche per bytecode sono piuttosto ben documentate ed esistono a un livello molto più elevato rispetto a qualcosa come le specifiche dell'assemblatore x86, è improbabile che tu possa "nascondere". il flusso di processo, poiché deve essere lì perché il programma funzioni in primo luogo.

Answer 7

Non può essere fatto.

Tutto ciò che può essere compilato può essere decompilato. Il meglio che puoi fare è offuscare l'inferno.

Detto questo, ci sono alcune cose interessanti che accadono nella crittografia quantistica. In sostanza, qualsiasi tentativo di leggere il messaggio lo modifica. Non so se questo potrebbe essere applicato o meno al codice sorgente.

Answer 8

Anche se si compila il codice in linguaggio macchina nativo, ci sono tutti i tipi di programmi che ti permettono essenzialmente di decompilarlo in linguaggio assembly e seguire il flusso del processo (OlyDbg, IDA Pro).

Answer 9

Trasformalo in un servizio web. Quindi sei l'unico che può vedere il codice sorgente.

Answer 10

Non può essere fatto. Questo non è un problema Java. Qualsiasi linguaggio che può essere compilato può essere decompilato per Java, è solo più semplice.

Stai provando a mostrare a qualcuno un'immagine senza mostrarla realmente. Non è possibile. Inoltre, non puoi nascondere il tuo host anche se ti nascondi a livello di applicazione. Qualcuno può ancora afferrarlo tramite Wireshark o qualsiasi altro sniffer di rete.

Answer 11

Come qualcuno ha detto sopra, il reverse engineering potrebbe sempre decompilare il tuo eseguibile. L'unico modo per proteggere il tuo codice sorgente (o algoritmo) non è distribuire il tuo eseguibile.

separa la tua applicazione in un codice server e un'app client, nascondi la parte importante dell'algoritmo nel codice server ed eseguila in un server cloud, distribuisci semplicemente il codice client che funziona solo come data getter e mittente.

In questo modo anche il tuo codice client viene decompilato. Non stai perdendo nulla.

Ma questo sicuramente diminuirà le prestazioni e la comodità dell'utente.

Penso che questa potrebbe non essere la risposta che stai cercando, ma solo per sollevare un'idea diversa sulla protezione del codice sorgente.

Answer 12

Con qualsiasi cosa interpretata ad un certo punto, deve essere elaborata "in chiaro". La stringa verrebbe visualizzata chiara come il giorno in cui il codice viene eseguito tramite JAD. Potresti distribuire una chiave di crittografia con la tua app o eseguire una crittografia di base per crittografare le informazioni di connessione dell'host e decrittografare in fase di esecuzione ...

Ma ad un certo punto durante l'elaborazione le informazioni di connessione dell'host devono essere messe in chiaro affinché l'app possa connettersi all'host ...

Quindi puoi nasconderlo staticamente, ma non puoi nasconderlo durante il runtime se eseguono un debugger

Answer 13

Questo è impossibile. La CPU dovrà eseguire il tuo programma, ovvero il tuo programma deve essere in un formato comprensibile per una CPU. Le CPU sono molto più stupide degli umani. Ergo, se una CPU può capire il tuo programma, un umano può.

Answer 14

Avendo timore di nascondere il codice, avrei eseguito comunque ProGuard .