Auto Repairing Vulnerable Code Fragments via Binary-Source Mapping

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional methods for auto-repairing software vulnerabilities rely on test suites or deep learning models, which are either dependent on extensive testing, require comprehensive datasets, or generate multiple candidate patches, necessitating manual verification and being susceptible to encoding issues.

Innovation Solution

A processor-implemented method that detects vulnerable code fragments using predefined rules, creates a mapping between binary and source code, and applies functional ordered auto repair rules to generate unique, safe code fragments without requiring a test suite or dataset, thereby eliminating the need for manual verification.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If test driven approaches are used for auto correction, then vulnerability detection accuracy is improved, but dependency on test suite and manual test case creation increases

Engineering Contradiction:
Improvevulnerability detection accuracyVSAvoidtest suite dependency
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent introduces a mapping module as an intermediary between binary code and source code, enabling vulnerability detection without direct test suite involvement. The mapping module translates binary vulnerability indicators to source code locations, allowing automated repair while eliminating the need for manual test case creation and fault localization strategies.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent replaces the mechanical test-driven approach with a rule-based automated system. Instead of relying on test cases to drive the repair process, the system uses predefined vulnerability detection rules and functional ordered auto repair rules to automatically identify and fix vulnerabilities, substituting manual testing mechanics with automated rule-based mechanics.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

2Ease of operation

If deep learning based approaches are used, then test suite requirement is eliminated, but comprehensive dataset and preprocessing complexity are required

Engineering Contradiction:
Improvetest suite requirementVSAvoiddataset preprocessing complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent uses lightweight, rule-based vulnerability detection and repair mechanisms instead of heavy deep learning models. The approach employs simple, disposable rules that can be applied directly to code without requiring extensive training datasets or complex preprocessing pipelines, achieving effectiveness with minimal overhead.

Inventive Principle:
Principle #27Cheap short-living objects (Disposable)

Solution Approach 2:

The patent segments the vulnerability repair process into distinct modular components: vulnerability detection module, mapping module, and auto repair module. Each module operates independently with clear inputs and outputs, eliminating the need for comprehensive datasets while maintaining operational simplicity through modular rule-based processing.

Inventive Principle:
Principle #1Segmentation

3Reliability

If deep learning models generate multiple candidate patches, then vulnerability repair coverage is improved, but manual verification burden increases

Engineering Contradiction:
Improvevulnerability repair coverageVSAvoidmanual verification time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent implements self-service automated verification through the functional ordered auto repair module. The system automatically verifies repair correctness by checking functional ordering constraints and consistency with vulnerability detection rules, eliminating the need for manual verification of candidate patches while maintaining comprehensive repair coverage.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent incorporates feedback mechanisms where the auto repair module continuously verifies generated patches against the mapping information and vulnerability detection rules. The system provides immediate feedback on patch correctness and automatically iterates to generate unique, verified patches without manual intervention, ensuring high repair coverage with zero manual verification time.

Inventive Principle:
Principle #23Feedback

4Manufacturing precision

If functional ordered auto repair rules are applied, then unique patch generation is achieved, but rule application complexity increases

Engineering Contradiction:
Improvepatch uniquenessVSAvoidrule application complexity
Core Design Contradiction:
Manufacturing precisionVSDevice complexity

Solution Approach 1:

The patent applies functional ordered auto repair rules that transform vulnerable code by changing specific parameters such as function call orders, variable assignments, and control flow structures. These parameter changes are systematically applied based on the mapping information, ensuring unique patch generation while keeping rule application complexity manageable through structured transformation templates.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentEP4386601B1System and method for auto repairing vulnerable code program fragments of a software
Publication Date: 2025.01.01 TATA CONSULTANCY SERVICES LTD
  • EP4386601B1 patent drawingFigure 1
  • EP4386601B1 patent drawingFigure 2
  • EP4386601B1 patent drawingFigure 3

AI summary

This disclosure provides system and method for auto repairing vulnerable code program fragments of a software. The present disclosure addresses problems of conventional approaches which are dependent on test cases. In the present disclosure, vulnerabilities in an input application are identified and repaired. First, a plurality of vulnerability detection rules is executed against an application in binary form (i.e., input application) and a plurality of vulnerable code fragments are identified. Post identification of the plurality of vulnerable code fragments, a mapping is created from the application in binary form to its source code files. Post mapping, paths capturing different application functionalities are extracted. Subsequently, a plurality of vulnerable source code program fragments is extracted and auto repair rules are applied on entire application functionality. As a result of execution of the auto repair rules, the plurality of vulnerable source code program fragments is replaced with safe code fragments.