2011-10-07 6 views
5

Un cliente me ha proporcionado un antiguo código de proveedor externo no compatible en un archivo jar y estoy intentando realizar una ingeniería inversa para volver a implementar el mismo protocolo que usé para conectar a un servidor.Ir a declaraciones en el código decompilado causando problemas

Lo he descompilado y una de las clases parece tener etiquetas y declaraciones goto. Mi compilador está haciendo un siseo al respecto porque, según tengo entendido, goto no es compatible con Java.

no puedo publicar el todo el código, debido a cuestiones de propiedad intelectual, pero aquí está el quid de la cuestión (He puesto los errores de compilación en los comentarios):

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; 
    } 

entiendo que las líneas seguidas por dos puntos están las etiquetas, pero no entiendo qué está mal aquí.

la línea con el Goto está probando para cierto por lo que sólo se pudo quitar las etiquetas, ya que son irrelevantes aquí, pero no entiendo lo que significa esta línea:

local; 

O esto:

JVM INSTR ret 12; 

Cualquier ayuda interpretando esto sería muy apreciada.

+1

Si su decompilador pretende convertir el bytecode de JVM en Java, pero el código que está produciendo no es Java válido, ¿no es eso un error en su descompilador? – Raedwald

+0

nota quisquillosa: tenga cuidado con el código de proveedor de terceros de ingeniería inversa, e incluso publíquelo; puede que el proveedor no lo permita:/ – Christian

+0

Creo que he ocultado el código tanto como sea posible ... –

Respuesta

4

¿Qué decompilador está utilizando? Pruebe con otro, podría producir un mejor código. Tuve una muy buena experiencia con JD-GUI. Salvo eso, mira el bytecode.

+0

Gracias descompilé usando JD -GUI y se ve bien. Estaba usando DJ-Decompiler http://members.fortunecity.com/neshkov/dj.html –

2

Para ser honesto, con este tipo de problemas puede que sea mejor que vea directamente los códigos de bytes. Pruebe javap -c en el archivo de clase y vea qué sucede realmente dentro de ese método.

6

Lo que está viendo son artefactos del código de bytes, que su decompilador no pudo manejar correctamente, como parece. Para exmaple

_L2: 
    String x; 
    String y; 

    ... 

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

podría haber sido algo así como

do { 
    String x; 
    String y; 

    ... 

} while (true); 

pero el decompilador no pudo (o no hizo caso de intento) para reconstruir estas piezas correctamente juntos. Del mismo modo, el

JVM INSTR ret 12 

parece ser una representación de algunos opcode, que el decompilador no entendió correctamente. No tengo ni idea de qué podría ser el local.

Cuestiones relacionadas