Storyyeller / Krakatau

Java decompiler, assembler, and disassembler
GNU General Public License v3.0
1.95k stars 220 forks source link

Error in handling of new opcode #104

Closed samczsun closed 7 years ago

samczsun commented 7 years ago

This one's slightly strange. If I provide an semi-illegal descriptor to the new opcode, like this:

.version 52 0 
.class public super proof 
.super java/lang/Object 

.method public static main : ([Ljava/lang/String;)V 
    .code stack 10 locals 10
        getstatic java/lang/System out Ljava/io/PrintStream;
        new Ljava/lang/String;
        dup
        invokespecial Ljava/lang/String; <init> ()V
        invokevirtual java/io/PrintStream println (Ljava/lang/Object;)V
        return
    .end code 
.end method 
.end class 

The JVM will run it under standard settings (rejecting it under -Xverify:all). However, Krakatau fails with this error:

   // Traceback (most recent call last):
    //   File "java\javaclass.py", line 37, in _getMethod
    //     graph = cb(method) if method.code is not None else None
    //   File "decompile.py", line 61, in makeGraph
    //     s.abstractInterpert()
    //   File "ssa\graph.py", line 263, in abstractInterpert
    //     inputs = [UCs[var] for var in op.params]
    // KeyError: Var @0x5869a40L

Similarly, the putstatic opcode seems to handle the malformed types by inserting the literal into the code.

putstatic Ljava/lang/System; out Ljava/io/PrintStream;

causes

Ljava.lang.System;.out = somevalue;

to be emitted.

putfield aborts decompilation by raising a ClassLoaderError

A super class of Ljava/lang/Object; causes a similar output to putstatic

Storyyeller commented 7 years ago

Interesting, it looks like I'll have to do more testing there to see what the JVM actually accepts.