Software Integrity Validation Network for Malware Detection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing software systems face challenges in detecting and removing malware, as malicious code can prevent the replacement of compromised files, leading to undetected malware persistence even after new software versions are installed.

Innovation Solution

A method involving a network of functions within a software system where each function validates and verifies others using stored hashes and versions, with a manifest cryptographically signed, to ensure integrity and detect tampering, promoting the renewal of components.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If individual files are compared with known malware signatures to detect malware, then detection capability is improved, but the system becomes vulnerable to undetected malware that modifies files without leaving recognizable signatures

Engineering Contradiction:
Improvemalware detection capabilityVSAvoidundetected malware persistence
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The system performs preliminary integrity verification by storing hashes of legitimate file versions and comparing them against current file hashes before malware can execute or modify functionality. This preliminary check detects tampering before the malware's harmful effects manifest.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system implements feedback mechanisms where functions verify the integrity of other functions through hash comparison, creating a chain of trust. When a function detects that another function has been modified, it provides feedback to alert the user and prevent execution of compromised code.

Inventive Principle:
Principle #23Feedback

2Reliability

If files are replaced or updated to remove malware, then malware removal is improved, but the process is defeated when malware monitors and overwrites replacement files

Engineering Contradiction:
Improvemalware removal effectivenessVSAvoidfile replacement process
Core Design Contradiction:
ReliabilityVSEase of manufacture

Solution Approach 1:

The system performs preliminary integrity checks on files before replacement occurs. By verifying file hashes against stored legitimate versions, the system can identify compromised files before attempting replacement, preventing the malware from monitoring and overwriting the replacement process.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system introduces an intermediary verification layer using hash comparison between the malware-protected system and a trusted reference state. This intermediary mechanism allows the system to detect tampering without directly confronting the malware, enabling safe file replacement by first identifying which files need replacement based on hash mismatches.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If the system checks integrity of software components, then detection of tampering is improved, but the complexity of the system increases

Engineering Contradiction:
Improveintegrity verification capabilityVSAvoidsoftware system structure
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system segments the integrity verification task into individual function-level checks. Each function stores its own hash and version information, and verifies other functions independently. This segmentation allows the complex integrity checking to be distributed across multiple simple, independent verification operations rather than requiring a single complex system-wide check.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system creates copies of integrity information (hashes and versions) within each function and in a centralized manifest. These copies serve as reference data that enables verification without requiring constant access to the original trusted state, reducing the complexity of maintaining and updating the verification system.

Inventive Principle:
Principle #26Copying

4Reliability

If new versions of software are installed to update compromised files, then malware removal is improved, but the infected file prevents installation of new versions

Engineering Contradiction:
Improvesoftware update capabilityVSAvoidsoftware installation process
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The system performs preliminary integrity verification before allowing software updates. By checking file hashes against stored legitimate versions, the system can identify which files are compromised and prevent updates from being installed on infected systems, alerting the user instead to manually replace specific files or seek assistance.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system provides feedback to users when integrity checks detect compromised files. This feedback mechanism informs users that their system is infected and cannot be updated through normal means, guiding them to alternative remediation steps such as manual file replacement or contacting support, thereby maintaining update capability while addressing the infection issue.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS8266691B2Renewable integrity rooted system
Publication Date: 2012.09.11 MICROSOFT TECHNOLOGY LICENSING LLC
  • US8266691B2 patent drawing
  • US8266691B2 patent drawing
  • US8266691B2 patent drawing

AI summary

A method of validating software is disclosed. The method may include receiving, at a first function, a first hash and a first version. The first function may validate a second function according to the first hash and first version. The second function may receive a second hash and a second version, and the second function may validate a third function according to the second hash and second version. The first version and first hash may be stored within the first function, for example. The first version and first hash may be stored within a manifest, for example.In another embodiment, a method of validating software may include storing a plurality of functions and storing a version and hash for each function. Each function may be verified according to the respective version and hash, and each function may verify at least one other function.