Java Hook Code Execution via Imposter Main Class

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing techniques for injecting code into JAVA applications prior to execution, such as 'hooking,' face issues with loading the original Main class, accessing its members, and maintaining the ClassLoader hierarchy, leading to errors like LinkageError and IllegalAccessError, and require modifying the command line or JVM settings, which can be restrictive and environment-dependent.

Innovation Solution

The method involves creating a new ClassLoader hierarchy by placing an Imposter Main class in the ExtClassLoader's classpath, executing hook code, and then loading the original Main class using a new AppClassLoader, making the Imposter Main class invisible and restoring the original ClassLoader references using JAVA reflection, thus avoiding the need to edit the command line and maintaining a clean ClassLoader structure.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Extent of automation

If an Imposter Main class is placed in the ExtClassLoader's classpath to execute hook code before the original Main class, then code injection is achieved, but the original Main class cannot be loaded and ClassLoader hierarchy is altered

Engineering Contradiction:

Improvecode injection capabilityVSAvoidoriginal Main class loading

Core Design Contradiction:

Extent of automationVSReliability

Solution Approach 1:

The patent introduces a Launcher class as an intermediary that manages the ClassLoader hierarchy. This Launcher class acts as a mediator between the Imposter Main class and the original Main class, coordinating their loading and execution while preserving the integrity of the original ClassLoader structure. The Launcher class ensures that both classes can coexist and be properly loaded without conflicts.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the class loading process into distinct phases managed by different ClassLoaders. The ExtClassLoader loads the Imposter Main class, while a separate AppClassLoader is created and configured to load the original Main class. This segmentation allows independent management of each class's loading process, avoiding interference between them.

Inventive Principle:

Principle #1Segmentation

2Reliability

If a new ClassLoader is created to load the original Main class, then loading issues are resolved, but the original ClassLoader hierarchy is completely altered

Engineering Contradiction:

Improveoriginal Main class loadingVSAvoidClassLoader hierarchy structure

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements a nested ClassLoader structure where the AppClassLoader is created as a child of the ExtClassLoader. This nesting allows the AppClassLoader to access classes loaded by the ExtClassLoader while maintaining its own independent class loading capabilities. The nested structure preserves the hierarchical relationship and avoids complete alteration of the original ClassLoader hierarchy.

Inventive Principle:

Principle #7Nested doll (Nesting)

Solution Approach 2:

The patent performs preliminary configuration of the ClassLoader hierarchy before loading the original Main class. The Launcher class pre-configures the AppClassLoader with the necessary classpath and parent relationships, ensuring that when the original Main class is loaded, the ClassLoader hierarchy is already properly established and will not be altered during the loading process.

Inventive Principle:

Principle #10Preliminary action

3Ease of operation

If the Imposter Main class is made visible to the original Main class, then class access is simplified, but the original Main class may access classes it should not

Engineering Contradiction:

Improveclass accessVSAvoidclass access control

Core Design Contradiction:

Ease of operationVSReliability

Solution Approach 1:

The patent applies local quality by making the Imposter Main class visible only to specific components that require it, rather than making it universally visible. The Launcher class controls the visibility and access permissions, ensuring that the Imposter Main class is accessible only where necessary for hook execution, while maintaining access control for the original Main class.

Inventive Principle:

Principle #3Local quality

4Extent of automation

If command line or JVM settings are modified to inject code, then hooking is achieved, but the solution becomes restrictive and environment-dependent

Engineering Contradiction:

Improvecode injection capabilityVSAvoidenvironment compatibility

Core Design Contradiction:

Extent of automationVSAdaptability or versatility

Solution Approach 1:

The patent implements self-service by enabling the Launcher class to automatically detect and adapt to different JVM environments and configurations. The system performs self-configuration based on the runtime environment, eliminating the need for manual command line or JVM setting modifications. This allows the code injection mechanism to work across various environments without being restrictive or environment-dependent.

Inventive Principle:

Principle #25Self-service

Data Source

PatentUS8745598B2Running injected code prior to execution of an application

Publication Date: 2014.06.03 BMC HELIX ISRAEL LTD

AI summary

A technique provides a hook that executes prior to a software application that is invisible to the software application. In an object-oriented execution environment, an imposter main class is loaded instead of the application main class. The imposter main class then manipulates the object-oriented execution environment to load the application main class without requiring knowledge of the application main class other than its name, and without requiring a change to the command line for the application.