Question

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

Answer 1

不，单独使用CONSTANT_Class_info条目来发现对其他类/接口的依赖是不正确的。如果您正在解析您信任的输入文件或者可以容忍不正确的信息，那么除了一个角落情况外，您可以解析常量池。要获得有关任意输入的精确信息，您需要解析整个类文件。（我假设依赖＆＃34;依赖＆＃34;你的意思是那些加载或链接类的类或接口可能导致异常，如JVMS chapter 5中所述。这不包括通过{获得的类{1}}或其他反思手段。）

考虑以下课程。

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不会作为CONSTANT_Class_info条目出现在常量池中。它确实出现在identity的方法描述符中（条目＃12）。字段描述符还可以引用不显示为CONSTANT_Class_info条目的类。因此，要仅从常量池中查找所有依赖项，您需要查看所有UTF8条目。

极端情况：CONSTANT_String_info条目可能存在一些UTF8条目。将合并重复的UTF8条目，因此一个UTF8条目可能是方法描述符，字符串文字或两者。如果你只是解析常量池，你必须忍受这种歧义（可能是通过过度激发并将其视为依赖）。

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

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

这就是我想到的最重要的事情。一个聪明的攻击者通过细齿梳子通过JVMS可能会找到更多的地方来添加看起来使用但不是常数池的条目。如果您在攻击者面前需要准确的信息，则需要解析整个类文件并了解JVM将如何使用它。

Answer 2

请参阅JVMS 4.2, The Internal Form of FQ Class and Interface Names。

Nutshell：类结构指向UTF8条目。

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

FWIW，要小心依赖此信息来确定依赖关系，因为类可以动态加载，但可能根本不会出现。

classfiles常量池中缺少类

2 个答案: