Executable File Malware Detection via Emulated and Real Trace Comparison

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current methods for detecting malware in executable files are inadequate, as they rely on manual screening, can miss new constructs, and are susceptible to code obfuscation and evasion techniques, leading to delayed detection and potential false positives in reputation-based systems.

Innovation Solution

A method that involves receiving a behavior profile of an executable file from an emulated environment, installing it on a real device, generating a second behavior profile, and comparing the two to determine malign or non-malign behavior, with the option to cease execution and query the user if deviations are found.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If automated screening tools are used to detect malware, then detection speed is improved, but new malware constructs may remain undetected

Engineering Contradiction:
Improvedetection speedVSAvoiddetection accuracy
Core Design Contradiction:
ProductivityVSMeasurement precision

Solution Approach 1:

The patent performs static analysis on the executable file before dynamic execution to extract anticipated behavior profiles. This preliminary action creates a reference framework that guides subsequent dynamic analysis, enabling faster detection while maintaining accuracy by comparing actual runtime behavior against pre-established expectations.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system transitions from static code analysis to dynamic runtime behavior monitoring. By observing the executable's actual execution trace, system calls, and runtime characteristics, the system adapts to new malware constructs that may not be detectable through static signature matching alone.

Inventive Principle:
Principle #15Dynamics

2Reliability

If code obfuscation is used to protect applications, then security against piracy is improved, but malware functions become hidden and undetectable

Engineering Contradiction:
Improveprotection against piracyVSAvoidmalware detection difficulty
Core Design Contradiction:
ReliabilityVSDifficulty of detecting and measuring

Solution Approach 1:

The patent introduces behavior profiles as an intermediary layer between the obfuscated code and the detection system. Instead of attempting to analyze the obfuscated code directly, the system monitors the runtime behavior manifestations of the code, which reveal malicious intentions regardless of obfuscation techniques applied to the source code.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system changes the detection approach from analyzing code appearance (which can be obfuscated) to analyzing behavioral characteristics. By monitoring system calls, execution patterns, and runtime properties, the detection system sees through obfuscation by focusing on the functional 'color' or behavior of the code rather than its syntactic appearance.

Inventive Principle:
Principle #32Color changes

3Adaptability or versatility

If malware is designed to evade detection by behaving properly in detection environments, then evasion success is improved, but detection reliability deteriorates

Engineering Contradiction:
Improveevasion capabilityVSAvoiddetection reliability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent performs both static analysis and dynamic runtime monitoring, going beyond the partial approach of using only one method. By combining pre-execution behavior profile extraction with runtime trace comparison, the system over-compensates for evasion techniques that might succeed against single-method detection approaches.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The system establishes a feedback loop where the observed runtime behavior is continuously compared against the anticipated behavior profile. When deviations are detected, the system can respond by blocking execution or alerting the user, creating a closed-loop detection system that adapts to evasive behaviors.

Inventive Principle:
Principle #23Feedback

4Reliability

If reputation-based systems are used for application screening, then user feedback can prevent malware spread, but detection is slow and susceptible to false opinions

Engineering Contradiction:
Improvemalware prevention capabilityVSAvoiddetection delay
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs automated static and dynamic analysis before the application is widely distributed, creating behavior profiles in advance. This preliminary detection action eliminates the time delay inherent in reputation-based systems that rely on user feedback after malware has already spread.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP2873023B1Technique for determining a malign or non-malign behavior of an executable file
Publication Date: 2020.02.26 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • EP2873023B1 patent drawingFigure 1
  • EP2873023B1 patent drawingFigure 2
  • EP2873023B1 patent drawingFigure 3

AI summary

A technique for determining a malign or non-malign behavior of an executable file is disclosed. In a first method aspect, the method comprises the steps of first acquiring a first behavior profile of the executable file, the first behavior profile comprising a first observable execution trace of the executable file from an emulated environment, second acquiring a second behavior profile of the executable file, the second behavior profile comprising a second observable execution trace of the executable file from a real environment, and comparing the first and second observable execution traces so as to determine the malign or non-malign behavior of the executable file. In another method aspect, the method comprises the steps of receiving a trigger condition, collecting, responsive to the trigger condition, first and second behavior profiles of the executable file from first and second one of two or more file-execution devices, the first and second behavior profiles comprising first and second observable execution traces of the executable file, and the first and second observable execution traces being non-mapped to the first and second file- execution device, respectively.