Java: risultato strano dopo la decompilazione

Question

Ho un file jar strano, contiene una classe che quando uso JD Decompiler, che mostrano un segmento come questo:

public final void a(ak aa) {
    this.jdField_a_of_type_Ak = aa;
}

public final void a(cn ccn) {
  this.jdField_a_of_type_Cn = ccn;
}

public final cN a() {
  return this.jdField_a_of_type_CN;
}

public final void a() {
  super.b();
}

public final boolean a() {
    return this.jdField_a_of_type_Boolean;
}

Mi chiedo solo perché una / un compilatore / obfuscator prodotto può un codice di classe di byte del genere, voglio dire la firma del metodo. Sapeva nessuno un obfuscator può fare questo?

Answer 1

@Joachim Sauer sottolinea giustamente : la JVM specifica pose meno vincoli overloading dei metodi nel bytecode rispetto ai JLS fa su programmi Java.

JVM Specification (paragrafo 4.6 , Metodi) :

  

Non ci sono due metodi in un unico file di classe può avere lo stesso nome e descrittore (§4.3.3).

E un descrittore di metodo include il tipo di ritorno: ( 4.3.3 Metodo descrittori )

  

MethodDescriptor:
  ( ParameterDescriptor* ) ReturnDescriptor

I metodi che hai citato nella tua domanda hanno tutti i descrittori distinti, in modo che siano a posto:

public final void a(ak aa)     ->     (Lsomepkg1/ak;)V
public final void a(cn ccn)    ->     (Lsomepkg2/ccn;)V
public final cN a()            ->     ()Lsomepkg3/cN;
public final void a()          ->     ()V
public final boolean a()       ->     ()Z

Questa è abilmente sfruttata da obfuscators. Un bytecode-programma valido non ha più un programma Java "corrispondente direttamente". ProGuard fa questo per esempio. Ecco un frammento da loro manuale:

  

-overloadaggressively
  Specifica di applicare sovraccarico aggressivo, mentre offuscando. campi e metodi multipli possono quindi ottenere gli stessi nomi, finché i loro argomenti e tipi di ritorno sono diversi (non solo i loro argomenti) .

Ci sono altre tecniche simili utilizzando per esempio l'istruzione bytecode jsr o utilizzando identificatori di variabili che sono parole riservate del linguaggio Java. Qui è una pagina web messa in vendita di alcune tecniche.

---

Per rispondere alla ovvia follow-up domanda:? Come funziona il know JVM quale metodo chiamata al call-sito

I invoke-istruzioni che richiedono di specificare un riferimento a una firma del metodo completo, (compreso il tipo di ritorno del metodo) che deve essere chiamato.

Answer 2

I supporti Java bytecode costrutti che non sono validi nel codice sorgente di Java. Obfuscators sfruttano questo fatto modificando bytecode utilizzare tali costrutti (pur dando lo stesso risultato del bytecode non-offuscato).

Answer 3

... Un obfuscator produce i nomi dei metodi / firme come questo, perché questo è il suo lavoro. Qualsiasi obfuscator dovrebbe lavorare per questo scopo.

Answer 4

La classe è stata compilata senza informazioni di debug (almeno informazioni variabile locale è mancante) e offuscato in seguito.

Una strategia di base è quella di sostituire offuscamento (quasi) tutto il pacchetto, di classe e methodnames da nuovi, nomi senza senso, in modo che non si può capire il codice decompilato.

strategie supplementari sono offuscando corde e aggiungendo costrutti bytecode che non può essere decompilato al codice Java.

sarà ancora in grado di creare una sorgente Java equivalente per il file di classe offuscato ma solo con grande sforzo.