Skip to content

Internals

episode edited this page Nov 28, 2024 · 1 revision

When preventing reverse engineering, having a great understanding of the VM's internals is crucial. This section delves into the inner workings of the JVM.

Class File Structure

.class files are the cornerstone of Java's "write once, run anywhere" philosophy. It's a binary file containing bytecode that the JVM can execute.

Field Type Description
Magic Number u4 Always 0xCAFEBABE, identifies a valid .class file.
Version Info u2, u2 Minor version (u2), followed by major version (u2), indicating the class file format version (e.g., Java 17 uses major version 61).
Constant Pool u2 + cp_info[] Constant pool count (u2), followed by a variable-sized array of constant pool entries. These include strings, method/field references, class names, etc.
Access Flags u2 Indicates if the class is public, final, abstract, etc. (e.g., 0x0021 for a public super class).
This Class u2 Index into the constant pool, referring to the CONSTANT_Class_info representing the fully qualified name of this class.
Super Class u2 Index into the constant pool, referring to the CONSTANT_Class_info representing the fully qualified name of the superclass (0 for java.lang.Object).
Interfaces Count u2 The number of interfaces implemented by this class, followed by an array of u2 indices pointing to CONSTANT_Class_info entries.
Fields Count u2 The number of fields declared by this class, followed by field entries containing access flags, a name index, a descriptor index, and attributes.
Methods Count u2 The number of methods declared by this class, followed by method entries containing access flags, a name index, a descriptor index, and attributes (like Code).
Attributes Count u2 The number of class-level attributes, followed by variable-sized attributes, including SourceFile, InnerClasses, Deprecated, and others.

ClassLoader

The ClassLoader is a crucial component of the JVM, responsible for loading Java classes and interfaces into the JVM Runtime environment

ClassLoader Hierarchy

  1. Bootstrap ClassLoader:
    • Written in native code (C++)
    • Loads core Java classes from rt.jar
    • Parent of all other ClassLoaders
    • Not visible to Java code (null in Java)
  2. Extension ClassLoader:
    • Loads classes from ext directory
    • Child of Bootstrap ClassLoader
  3. Application ClassLoader:
    • Loads classes from application classpath
    • Child of Extension ClassLoader
    • Default loader for application classes

Class Loading Process

  1. Loading:
    • Reads .class file
    • Generates binary data
    • Creates a Class object
  2. Linking: a. Verification:
    • Ensures bytecode is valid and adheres to JVM specifications
    • Checks for memory and stack overflow issues b. Preparation:
    • Allocates memory for class variables
    • Initializes fields to default vqlues c. Resolution:
    • Replaces symbolic references with direct references
  3. Initialization:
    • Executes static initializers and initializes static fields

Delegation Model

ClassLoaders follow the delegation principle:

  1. Check if class is already loaded
  2. If not, delegate to parent ClassLoader
  3. If parent fails, attempt to load the class itself

This ensures a hierarchical approach to class loading.