Invisible Breakpoints via Hardware Virtualization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing debugging techniques are detectable by malware and other undesired software, preventing effective tracing and blocking of their actions, as they can read their own program code in memory to determine if they are being debugged.
Innovation Solution
A system and method for setting invisible breakpoints using hardware virtualization to split code and data views of a program's text segment, allowing breakpoints to be set on potentially disruptive instructions, making them undetectable to the guest software, and enabling monitoring of malicious behavior.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional breakpoints are set in memory, then debugging functionality is achieved, but malware can detect the breakpoint by reading its own code, causing the debugger to become detectable
Solution Approach 1:
The patent segments the code segment into two separate memory regions: a read-only code view and a writable data view. The breakpoint is placed in the data view rather than the code view, separating the debugging functionality from the code that malware reads. This segmentation allows the breakpoint to exist without being detectable by the malware's code reading operations.
Solution Approach 2:
The patent introduces an intermediary mechanism using hardware virtualization (VMX) to create a virtual breakpoint that intercepts instructions without modifying the actual code memory. The virtual breakpoint acts as a mediator between the debugger and the malware, allowing traceability while maintaining code integrity and hiding the debugger's presence from the malware.
2Object-affected harmful factors
If breakpoints are made invisible to avoid detection, then malware detection capability is improved, but debugging and tracing functionality must be implemented through complex hardware virtualization
Solution Approach 1:
The patent creates a copy of the code segment in a separate data view that can be modified without affecting the original code. This copy mechanism allows the breakpoint to be set in the data view while the original code remains intact and undetectable. The copying approach simplifies the overall system by avoiding the need for complex runtime code generation or modification.
3Object-affected harmful factors
If code is made executable but not readable to prevent malware analysis, then security is improved, but the ability to set breakpoints and monitor behavior becomes more difficult
Solution Approach 1:
The patent segments memory access rights by creating separate views: a read-only code view that prevents malware from analyzing the code, and a writable data view that allows breakpoint insertion and modification. This segmentation enables the code to remain executable but unreadable to malware while still permitting debugging operations through the data view.
Solution Approach 2:
The patent applies different quality attributes to different memory regions: the code view has read-only permissions to prevent analysis, while the data view has read-write permissions to enable breakpoint functionality. This local differentiation of memory properties allows simultaneous achievement of security and debuggability.
Data Source
AI summary
Disclosed is a system and method for setting breakpoints (BPs) that cannot be detected by code being debugged, e.g., to trap transparently at any instruction. The disclosed system and method permits execution tracing and instrumentation of binaries, including malware. The system and method can be used to analyze benign software also, e.g., software obfuscated for anti-reverse-engineering. An invisible breakpoint (IBP) is not detectable by the “guest,” the program being debugged. Hardware virtualization is used to split the code and data views of the program's text segment(s).