Runtime API Call Interception for Legacy Application Compatibility
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Legacy applications face challenges when executed on newer operating systems with stricter security restrictions, as they may not be able to access necessary APIs, leading to functionality issues or incompatibility, especially when source code modifications are not feasible due to unavailability or technical difficulties.
Innovation Solution
A learning mode is implemented to identify and intercept API calls made by legacy applications, consulting a security rules database to determine allowable calls and storing blocked calls in a runtime remediation database, which modifies or reformats these calls to allow execution within a restricted application execution environment, such as using shadow resources or remediation code.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If legacy applications are executed on newer operating systems with stricter security restrictions, then security is improved, but application compatibility deteriorates
Solution Approach 1:
The patent introduces a compatibility layer as an intermediary component between the legacy application and the restricted operating system environment. This layer intercepts API calls from the application, translates them into allowed calls, and provides shadow resources that mimic the behavior of restricted APIs, thereby enabling legacy applications to run on modern secure systems without modifying the application itself.
Solution Approach 2:
The patent creates shadow resources that are copies of restricted system resources. These shadow resources replicate the functionality of restricted APIs and files without providing direct access to the actual restricted resources. The shadow resources are indistinguishable from the real resources to the legacy application, allowing it to function normally while maintaining security restrictions.
2Adaptability or versatility
If legacy applications are modified to work on newer operating systems, then application compatibility is improved, but development resources are consumed
Solution Approach 1:
The compatibility layer performs self-service by automatically detecting and translating blocked API calls without requiring any intervention from the legacy application or its developer. The system monitors API calls, identifies those that are restricted, and automatically translates them into allowed equivalents or provides appropriate shadow resources, eliminating the need for manual modification of the application code.
3Reliability
If API calls are intercepted and modified to comply with security restrictions, then security is maintained, but system complexity increases
Solution Approach 1:
The patent segments the compatibility layer into distinct functional components: an API call interception module that captures blocked calls, a translation module that converts restricted calls into allowed equivalents, and a shadow resource provider that supplies virtual representations of restricted resources. This segmentation allows each component to be optimized independently and simplifies the overall system architecture despite the added complexity.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Application programming interface (API) calls made by an application are intercepted at runtime. A determination is made as to whether each intercepted API call is allowed or blocked by a restricted application execution environment. Each API call that is blocked by the restricted application execution environment is modified so that the API call is allowable such as, for instance, modifying the API call to execute against a shadow resource. Remediation code might also be executed at runtime to reformat the API call so that it is allowed to execute in the restricted application execution environment.