1

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

4

2 回答 2

3

不，单独使用 CONSTANT_Class_info 条目来发现对其他类/接口的依赖是不正确的。如果您正在解析您信任的输入文件或可以容忍不正确的信息，您可以只解析常量池，除了一种极端情况。要获得有关任意输入的精确信息，您需要解析整个类文件。（我假设“依赖项”是指那些没有加载或链接类可能导致异常的类或接口，如JVMS 第 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 条目。

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

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

  • 条目 #20 命名了一个未被使用的类Main。JVM 可能会或可能不会尝试解析此引用（JVMS 5.4允许延迟加载和急切加载）。由于类存在，无论哪种方式，都不会引发错误，因此这个额外的条目是无害的，但它会欺骗查看常量池的工具，使其认为 Thread 是一个依赖项。
  • 条目 #21 是一个未使用的方法描述符，引用了两个虚构的类。由于未使用此描述符，因此不会引发错误，但同样，信任常量池的工具将解析它。
  • 条目#14 是一个引用虚构类的字段描述符。这个条目实际上是由 LineNumberTable 属性使用的，但是这个调试信息没有被 JVM 检查，所以引用是无害的，但可能会欺骗工具。
  • 我没有这个例子，但 InnerClasses 属性指的是 CONSTANT_Class_info 条目，并且不检查与其他类文件的一致性（根据JVMS 4.7.6，尽管在非规范性注释中）。这些引用不会阻止加载或链接，但会混淆检查常量池的工具。

这就是我想到的。一个聪明的攻击者使用细齿梳通过 JVMS 可能会找到更多的地方来将条目添加到看起来使用但没有使用的常量池中。如果即使面对攻击者也需要精确的信息，则需要解析整个类文件并了解 JVM 将如何使用它。

于 2014-07-03T02:16:22.567 回答
0

请参阅JVMS 4.2，FQ 类和接口名称的内部形式。

简而言之：类结构指向 UTF8 条目。

（或者您是说并非所有引用的类都由类和名称条目表示？）

FWIW，请注意不要仅依赖此信息来确定依赖关系，因为类可以动态加载并且可能根本不会出现。

于 2012-01-04T15:38:04.253 回答