Software Protection via Corruption Functions and Hardware Breakpoints
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Software programs are vulnerable to attacks using hardware breakpoints, which can lead to unauthorized modification, copying, and cheating in online games, resulting in loss of intellectual property and revenue.
Innovation Solution
Incorporating corruption functions with starting locations and instructions that trigger hardware breakpoints, causing exceptions handled by a return instruction to prevent the execution of malicious code, thereby protecting the program from such attacks.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If hardware breakpoints are used for debugging, then software can be debugged and monitored, but software becomes vulnerable to unauthorized compromise and malicious attacks
Solution Approach 1:
The patent applies preliminary action by pre-configuring multiple hardware breakpoints at specific locations within the software code before execution. These breakpoints are set up in advance to monitor critical sections such as function calls, data structures, and control flow paths. When the software encounters these pre-set breakpoints during normal execution, it triggers exception handling routines that validate the breakpoint's legitimacy, thereby preventing unauthorized debugging or malicious interference while maintaining legitimate debugging capabilities.
Solution Approach 2:
The patent introduces an intermediary mechanism in the form of exception handling code that acts as a mediator between hardware breakpoints and software execution. When a breakpoint is triggered, the intermediary exception handler validates whether the breakpoint is authorized before allowing the debugging process to proceed. This intermediary layer prevents direct unauthorized access to software internals while still permitting legitimate debugging operations, thus resolving the contradiction between debugging ease and security vulnerability.
2Adaptability or versatility
If program code is made accessible to users, then software can be executed and used, but users can compromise the program to steal IP, inject malicious code or cheat
Solution Approach 1:
The patent applies preliminary anti-action by embedding protective measures directly into the executable code that preemptively counteract potential unauthorized actions. The system pre-configures hardware breakpoints at critical locations and establishes exception handling routines that detect and respond to unauthorized debugging or modification attempts before they can compromise the software. This preliminary protective framework allows the software to remain fully executable and adaptable while automatically defending against IP theft, malicious code injection, and cheating.
3Reliability
If corruption functions are inserted into the program, then protection against hardware breakpoint attacks is enhanced, but program complexity increases
Solution Approach 1:
The patent applies merging by integrating corruption function protection mechanisms directly into the existing software execution flow rather than adding separate external protection layers. The exception handling code for corruption functions is embedded within the normal program structure, and hardware breakpoints are set at existing code locations rather than requiring separate monitoring infrastructure. This merging approach enhances reliability against attacks while minimizing increases in program complexity by utilizing and extending existing code structures.
Data Source
Figure 1
Figure 2~4
AI summary
In order to protect a software program, at least one corruption function is included in the program. Also included in the program is at least one instruction that causes the program to be directed to the corruption function. An available breakpoint is then set such that, when the starting location of the corruption function is reached, an exception is generated and the handling of the exception causes the corruption function not to run. This has the effect that, if a malicious user attempts to use the available hardware breakpoint to perform unauthorized actions on the software program, the corruption function will run, and the software program will be unusable.