Third-Party Software Control via Auxiliary Offset Data
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional methods fail to readily retrieve and distribute necessary information for modifying or monitoring the behavior of third-party installed software components, especially when such information is unintentionally hidden or unrecoverable, leading to difficulties in patching and configuring software components in different execution environments.
Innovation Solution
A system and method that generates auxiliary information, such as timestamps, CRC, access control information, and function address offsets, to control the operation of installed components, allowing for patching and monitoring, using a control program that operates in the operating system space and utilizes debug files like pdb files to derive necessary offset addresses.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of information
If conventional reverse assembly methods are used to determine offset addresses, then some information can be recovered, but the process is complex, time-consuming, and may violate copyright or license terms
Solution Approach 1:
The patent applies preliminary action by embedding auxiliary information (including offset addresses and function identifiers) into the executable code during the compilation or linking phase. This allows the information to be readily available during runtime without requiring complex reverse assembly processes, thus resolving the contradiction between information retrieval and process complexity.
Solution Approach 2:
The patent introduces an intermediary mechanism - a control program that operates in operating system space and uses auxiliary information to retrieve offset addresses and control third-party components. This intermediary avoids direct reverse assembly of copyrighted code while still enabling the necessary information retrieval, thus resolving the copyright and complexity issues.
2Ease of operation
If auto-configuration mechanisms are used to configure software components, then configuration is automated, but virtual environment runtime objects and properties may not be recognized
Solution Approach 1:
The control program acts as an intermediary between auto-configuration mechanisms and virtual environment runtime objects. It uses auxiliary information to identify and configure virtual environment-specific objects and properties that standard auto-configuration mechanisms cannot recognize, thus maintaining both automation and adaptability.
Solution Approach 2:
The patent changes parameters by using version-specific auxiliary information that adapts to different virtual environment configurations. This allows the system to maintain automated configuration while adapting to various virtual environment objects and properties through parameter adjustments based on the auxiliary information.
3Adaptability or versatility
If third-party components are installed by users, then software flexibility is improved, but behavior supervision and patching become difficult
Solution Approach 1:
The patent applies preliminary action by embedding auxiliary information (including function identifiers and offset addresses) into third-party components during compilation. This allows supervision and patching mechanisms to easily retrieve and control component behavior without complex analysis, thus resolving the contradiction between installation flexibility and ease of supervision.
Data Source
AI summary
A method of controlling operation of an installed component includes generating auxiliary information relating to the installed component in user space; launching a control program in operating system space for controlling operation of the installed component; and controlling, from the operating system space, the operation of the installed component using the auxiliary information. The installed component can be an operating system component running in a Virtual Private Server, or a component of third party software. The auxiliary information can be, e.g., time stamps, CRC, access control information, function names, function address offsets and function parameter passing information derived from the debug file. The controlling step can patch the installed component. The patch can be version-specific to the installed component. The controlling step can monitor behavior of the installed component. The auxiliary information can be generated based on a debug file/pdb file.