Converti JAR in JAVA

I file sorgente sono necessari quando un JAR è l’unica copia disponibile di una libreria o applicazione Java e il relativo codice deve essere ispezionato, sottoposto ad audit, modificato o ricompilato. La maggior parte dei JAR di rilascio contiene file .class compilati, quindi il recupero dei file .java richiede generalmente la decompilazione anziché una conversione diretta dei file.

Contenuto di un file JAR

Un JAR (Java Archive) è un archivio basato su ZIP utilizzato dagli sviluppatori Java, dagli strumenti di compilazione e dai fornitori di applicazioni per distribuire librerie, plugin e applicazioni. In genere contiene classi compilate, risorse, metadati delle dipendenze e META-INF/MANIFEST.MF; i JAR eseguibili possono dichiarare una classe di avvio in quel manifest.

Gli strumenti JDK, Maven, Gradle, Eclipse e IntelliJ IDEA possono creare o utilizzare JAR. Un archivio separato denominato name-sources.jar contiene spesso i file sorgente originali e dovrebbe essere utilizzato al posto della decompilazione del JAR compilato.

Cos’è un file JAVA

Non esiste un formato binario “JAVA” separato. Un file .java è codice sorgente Java in testo normale che contiene classi, interfacce, metodi, dichiarazioni di package e import. Può essere modificato e compilato con javac, purché siano disponibili le librerie necessarie e il livello di release Java richiesto.

Un JAR normalmente produce molti file sorgente. Le relative cartelle devono corrispondere ai nomi dei package: com.example.Main deve trovarsi in com/example/Main.java. Java richiede che una classe di primo livello pubblica utilizzi lo stesso nome file della classe.

Estrarre prima il codice sorgente esistente

Elencare il contenuto dell’archivio con il comando jar del JDK:

jar tf app.jar

Se l’elenco contiene file .java, estrarli in una directory di lavoro vuota:

mkdir recovered-src
cd recovered-src
jar xf ../app.jar

Se è disponibile un archivio del codice sorgente corrispondente, estrarre quello:

jar xf app-sources.jar

Non confondere risorse come .properties, file XML, immagini o definizioni dei servizi con il codice sorgente Java. Estrarle se necessarie al progetto, ma non possono essere convertite in codice .java significativo.

Decompilare le classi compilate

Se il JAR contiene solo file .class, utilizzare un decompiler Java desktop. CFR è un’opzione adatta da riga di comando e in genere gestisce il bytecode Java più recente meglio di molti decompiler meno recenti. Scaricare CFR dal sito ufficiale del progetto, quindi eseguire:

java -jar cfr.jar app.jar --outputdir recovered-src

CFR scrive i file .java recuperati in recovered-src. Per un’opzione grafica, aprire il JAR in JD-GUI e selezionare File → Save All Sources; JD-GUI crea un archivio ZIP che deve essere estratto prima di aprire i file in un IDE.

IntelliJ IDEA può visualizzare le classi decompilate per l’ispezione, ma CFR o JD-GUI sono preferibili quando è necessario un albero del codice sorgente esportabile. Per piccoli esempi pubblici e non sensibili, servizi browser come Decompiler.com possono decompilare JAR senza installazione locale; verificare i termini di conservazione e privacy prima di caricare qualsiasi contenuto.

Limiti della compilazione e del recupero

L’output decompilato non è il progetto sorgente originale. Il bytecode non conserva commenti, formattazione, la maggior parte dei nomi delle variabili locali, sorgenti dei test, script di compilazione, cronologia del controllo versione e alcune informazioni sui tipi generici. L’offuscamento può sostituire i nomi significativi con identificatori come a e b.

I file recuperati potrebbero non compilare immediatamente. Aggiungere le dipendenze originali del JAR, il codice generato, i processori di annotazioni, le risorse e le opzioni del compilatore; quindi compilare per la release Java utilizzata dalle classi originali. Una versione più recente del file di classe potrebbe richiedere un JDK più recente e un decompiler che supporti tale versione.

I JAR multi-release possono contenere implementazioni alternative delle classi in META-INF/versions/, mentre i JAR shaded possono includere dipendenze insieme al codice dell’applicazione. Esaminare la struttura dei package e il manifest prima di considerare ogni classe recuperata parte di un unico progetto sorgente.

Conservare i JAR privati, dei clienti, concessi in licenza o sensibili dal punto di vista della sicurezza su una macchina locale anziché caricarli in un decompiler online. Decompilare solo software di cui si è proprietari o che si è autorizzati a ispezionare; il codice recuperato rimane soggetto ai termini della licenza originale e del copyright.