Malware Detection via Call Graph Reconstruction

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current malware analysis in sandboxes is hindered by armoring techniques used by malware, which prevent the detection of API traces, leading to poorer malware detection rates due to reduced API call identification.

Innovation Solution

A security platform that performs both dynamic and static malware analyses, generating a call graph to identify exits or forced kills of the software program, and combines these results to detect API traces that would have been logged without armoring, thereby improving malware detection.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If dynamic malware analysis is performed in a sandbox, then API traces can be logged to identify malicious behavior, but malware armoring techniques prevent the software program from executing fully, reducing API trace identification

Engineering Contradiction:

Improvemalware detection accuracyVSAvoidAPI traces

Core Design Contradiction:

Measurement precisionVSLoss of information

Solution Approach 1:

The system performs preliminary actions by generating a call graph from static analysis before dynamic execution. This call graph预先 identifies potential API calls and control flow paths, allowing the system to reconstruct what API traces would have occurred even when malware armoring prevents actual execution. The static analysis phase prepares the groundwork for compensating for lost dynamic traces.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The call graph serves as an intermediary structure that bridges static and dynamic analysis. It captures the intended control flow and API call relationships from static analysis, then uses this intermediate representation to infer missing API traces when dynamic analysis is blocked by armoring techniques. The call graph mediates between the incomplete dynamic execution and the need for comprehensive API trace identification.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Reliability

If malware detects sandbox execution and exits the program, then armoring protection is maintained, but API traces indicating malicious behavior are not logged

Engineering Contradiction:

Improvearmoring protection effectivenessVSAvoidAPI traces

Core Design Contradiction:

ReliabilityVSLoss of information

Solution Approach 1:

The system performs preliminary static analysis to generate a call graph that maps out the software program's intended execution path and API calls before dynamic analysis begins. This preliminary structure allows the system to infer what API traces would have been generated even when the program exits early due to sandbox detection. The call graph preserves information about malicious behavior that would otherwise be lost.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The system converts the harmful effect of early program termination into a benefit by using static analysis to reconstruct the intended API trace sequence. Instead of viewing the early exit as a complete loss of information, the system uses the call graph to infer what APIs would have been called, transforming the armoring-induced truncation into an opportunity to apply static analysis techniques that reveal the malware's intended malicious behavior.

Inventive Principle:

Principle #22Blessing in disguise (Convert harm into benefit)

3Productivity

If only dynamic malware analysis is performed, then real execution behavior is captured, but armoring techniques cause the program to exit early, reducing detection effectiveness

Engineering Contradiction:

Improvemalware analysis speedVSAvoidmalware detection accuracy

Core Design Contradiction:

ProductivityVSMeasurement precision

Solution Approach 1:

The system merges static analysis and dynamic analysis into a unified malware detection framework. Static analysis generates a call graph that captures the software program's intended control flow and API calls, while dynamic analysis captures actual execution behavior. By combining these two approaches, the system compensates for the limitations of each: static analysis provides information about intended behavior when dynamic execution is blocked, while dynamic analysis validates actual runtime behavior when execution proceeds.

Inventive Principle:

Principle #5Merging (Combining)

Solution Approach 2:

The system performs preliminary static analysis to generate a call graph before conducting dynamic analysis. This preliminary call graph serves as a reference model that guides and enhances the dynamic analysis phase. When dynamic analysis is truncated by armoring, the preliminary call graph provides the missing information needed to maintain high detection accuracy without sacrificing analysis speed.

Inventive Principle:

Principle #10Preliminary action

Data Source

PatentUS10997291B2Extending dynamic detection of malware using static and dynamic malware analyses

Publication Date: 2021.05.04 JUNIPER NETWORKS INC

AI summary

A device receives a software program, performs a dynamic malware analysis of the software program to generate dynamic malware analysis results, and generates a call graph based on the dynamic malware analysis of the software program. The device utilizes, during the dynamic malware analysis of the software program, the call graph to identify an exit of the software program and/or a forced kill of the software program, and performs a static malware analysis of the software program based on identifying the exit of the software program and/or the forced kill of the software program. The device generates static malware analysis results based on performing the static malware analysis of the software program, and combines the dynamic malware analysis results and the static malware analysis results to generate combined malware analysis results. The device performs one or more actions based on the combined malware analysis results.