java - classfiles常量池中缺少类

我正在使用字节码分析来获取类文件的所有导入类（使用BCEL）。现在，当我读取常量池时，并不是所有导入的类都被称为CONSTANT_Class（请参见spec），而仅被称为CONSTANT_Utf8。现在我的问题是：我不能仅依靠常量池中的CONSTANT_Class条目来读取导入的文件吗？我真的必须查看每个条目并进行猜测，如果它是类名？在imo的每种情况下，这似乎也不是正确的。还是我必须通读整个字节码？
问候

最佳答案

不，单独使用CONSTANT_Class_info条目来发现对其他类/接口的依赖关系是不正确的。如果要解析您信任的输入文件或可以容忍不正确的信息，则只能解析常量池，只有一种例外情况。为了获得有关任意输入的精确信息，您需要解析整个类文件。（我以“依赖关系”假设是指那些类或接口，如果没有这些类或接口，则如JVMS chapter 5中所述加载或链接类可能会导致异常。这不包括通过Class.forName或其他反射方式获得的类。）

考虑以下课程。

public class Main {
    public static void main(String[] args) {
        identity(null);
    }
    public static Object identity(Foo x) {
        return x;
    }
}

javap -p -v Main.class打印：

Classfile /C:/Users/jbosboom/Documents/stackoverflow/build/classes/Main.class
  Last modified Jul 2, 2014; size 346 bytes
  MD5 checksum 2237cda2a15a58382b0fb98d6afacc7e
  Compiled from "Main.java"
public class Main
  SourceFile: "Main.java"
  minor version: 0
  major version: 52
  flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
   #1 = Methodref          #3.#17         //  java/lang/Object."<init>":()V
   #2 = Class              #18            //  Main
   #3 = Class              #19            //  java/lang/Object
   #4 = Utf8               <init>
   #5 = Utf8               ()V
   #6 = Utf8               Code
   #7 = Utf8               LineNumberTable
   #8 = Utf8               LocalVariableTable
   #9 = Utf8               this
  #10 = Utf8               LMain;
  #11 = Utf8               identity
  #12 = Utf8               (LFoo;)Ljava/lang/Object;
  #13 = Utf8               x
  #14 = Utf8               LAAA;
  #15 = Utf8               SourceFile
  #16 = Utf8               Main.java
  #17 = NameAndType        #4:#5          //  "<init>":()V
  #18 = Utf8               Main
  #19 = Utf8               java/lang/Object
  #20 = Utf8               java/lang/Thread
  #21 = Class              #20            //  java/lang/Thread
  #21 = Utf8               (LBar;)LFakename;
{
  public Main();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 6: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   LMain;

  public static java.lang.Object identity(Foo);
    descriptor: (LFoo;)Ljava/lang/Object;
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: areturn
      LineNumberTable:
        line 11: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       2     0     x   LAAA;
}

作为方法Foo的参数引用的类identity不会作为CONSTANT_Class_info条目出现在常量池中。它确实出现在identity的方法描述符中（条目＃12）。字段描述符也可以引用未显示为CONSTANT_Class_info条目的类。因此，仅从常量池中查找所有依赖项，就需要查看所有UTF8条目。

极端情况：CONSTANT_String_info条目可能引用了一些UTF8条目。重复的UTF8条目将被合并，因此一个UTF8条目可能是方法描述符，字符串文字或两者兼而有之。如果仅解析常量池，则必须忍受这种歧义（可能是过分逼近并将其视为依赖项）。

如果您相信输入是由行为良好的Java编译器在您的控制下产生的，则可以解析所有UTF8条目，并注意字符串的转折情况，并在此处停止阅读。如果您需要防御攻击者提供工具手工制作的类文件（例如，您正在编写反编译器，并且攻击者希望防止反编译），则需要解析整个类文件。以下是一些潜在问题的示例。

条目＃20列出了Main未使用的类。 JVM可能会或可能不会尝试解析此引用（JVMS 5.4允许延迟加载和急切加载）。当类存在时，无论哪种方式，都不会引发任何错误，因此，此额外的输入是无害的，但是它会使愚蠢的工具将常量池视为线程是依赖项。
条目＃21是未使用的方法描述符，它引用了两个虚拟类。由于未使用此描述符，因此不会引发任何错误，但是再次，信任常量池的工具将对其进行解析。
条目＃14是引用虚拟类的字段描述符。该条目实际上由LineNumberTable属性使用，但是JVM不会检查此调试信息，因此该引用是无害的，但可能会使工具傻瓜。
我没有关于此示例的示例，但是InnerClasses属性引用了CONSTANT_Class_info条目，并且未检查与其他类文件的一致性（根据JVMS 4.7.6，尽管是非规范性注释）。这些引用不会阻止加载或链接，但是会混淆检查常量池的工具。

这就是我想到的。聪明的攻击者可能会用细齿梳子通过JVMS，可能会找到更多位置来将条目添加到看似已使用但未使用的常量池中。如果即使在面对攻击者时也需要准确的信息，则需要分析整个类文件并了解JVM将如何使用它。