2011-10-07 4 views
5

Mi è stato fornito un codice fornitore di terze parti non supportato in un file jar da un cliente e sto cercando di eseguirne il reverse engineering per implementare di nuovo lo stesso protocollo utilizzato per connettersi a un server.istruzioni Goto nel codice scompattato che causa problemi

L'ho decompilato e una delle classi sembra contenere etichette e istruzioni goto. Il mio compilatore sta facendo un salto in questo perché, a quanto ho capito, goto non è supportato in Java.

non posso postare il tutto il codice a causa di problemi IP ma qui è l'essenza di esso (ho messo gli errori del compilatore nei commenti):

private void methodName(InputType input) 
     throws ConfigurationException 
    { 
    // initialization code here 
_L2: 
    String x; // The compiler is complaining that "String cannot be resolved to a variable" here 
    String y; // This line is fine though... 
    // Some Code here 

    x = <SOME VALUE> // Compiler complains about "x cannot be resolved to a variable" 
    y = <ANOTHER VALUE> // Compiler is fine with this. 

    // Some more code 
    if(true) goto _L2; else goto _L1 // Multiple issues here see following lines. 
    // Syntax error on token "goto", throw expected 
    // _L2 cannot be resolved to a variable 
    // Syntax error on token "goto", { expected 
    // Syntax error on token "goto", { expected 

_L1: // Syntax error on token "goto", { expected 
     local; // local cannot be resolved to a variable 

     // Some more code 

     JVM INSTR ret 12; // Multiple issues here see following lines. 
     // JVM INSTR ret 12; 
     // Syntax error on token "ret", = expected 

     return; 
    } 

Capisco che le linee seguite da due punti sono etichette, ma non capisco cosa sta andando storto qui.

La linea con il goto sta testando per vero quindi ho potuto solo rimuovere le etichette come sono irrilevante in questa sede, ma non capisco che cosa significa questa linea:

local; 

O questo:

JVM INSTR ret 12; 

Qualsiasi assistenza interpretativa sarebbe più apprezzata.

+1

Se il decompilatore dichiara di convertire il codice byte JVM in Java, ma il codice che emette non è Java valido, non è un bug nel decompilatore? – Raedwald

+0

picky note: fare attenzione con il codice del fornitore di terze parti di reverse engineering - e anche pubblicare su di esso - potrebbe non essere consentito dal venditore:/ – Christian

+0

Penso di aver offuscato il codice il più possibile ... –

risposta

4

Quale decompilatore stai usando? Provane un altro, potrebbe produrre un codice migliore. Ho avuto una buona esperienza con JD-GUI. Escluso questo, guarda il bytecode.

+0

Grazie decompilato usando JD -GUI e sembra a posto. Stavo usando DJ-Decompiler http://members.fortunecity.com/neshkov/dj.html –

2

Per essere onesti, con questo tipo di problemi è meglio guardare direttamente i bytecode. Prova javap -c sul file di classe e guarda cosa succede realmente all'interno di quel metodo.

6

Quello che state vedendo sono artefatti del codice byte, che il vostro decompilatore non ha potuto gestire correttamente, come sembra. Per exmaple

_L2: 
    String x; 
    String y; 

    ... 

    if(true) goto _L2; else goto _L1; 
_L1: 

avrebbe potuto essere qualcosa di simile a

do { 
    String x; 
    String y; 

    ... 

} while (true); 

ma il decompilatore non era in grado (o non ha fatto caso tentativo) di mettere queste parti correttamente insieme. Allo stesso modo, il

JVM INSTR ret 12 

sembra essere un rendering per qualche codice operativo, che il decompilatore non ha capito correttamente. Non ho idea di cosa potrebbe essere lo local.