Binary Code Segmentation for Security Risk Assessment

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing methods for security risk assessment of software applications are inefficient as they often evaluate all code within binary files, including both custom and dependency code, which can lead to increased time and complexity in identifying vulnerabilities, especially when dependency code has been altered.

Innovation Solution

A method that separates custom code from dependency code within binary files by performing signature checks and binary static analysis, using indexed repositories to identify dependency code fingerprints, and filtering out dependency code for focused security evaluation on custom code.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If all code within binary files is evaluated for security risk, then comprehensive security assessment is achieved, but time consumption and complexity increase significantly

Engineering Contradiction:
Improvesecurity assessment completenessVSAvoidassessment time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent segments the binary file code into two distinct categories: custom code and dependency code. This segmentation is achieved through signature checks and binary static analysis that identify dependency code fingerprints against indexed repositories. By dividing the assessment scope, the system evaluates only custom code for security risks while excluding known dependency code, thereby reducing assessment time while maintaining security coverage for relevant code portions.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent extracts dependency code from the binary file by performing signature checks and comparing code fingerprints against indexed repositories of known dependencies. Once extracted and identified, dependency code is filtered out from the security assessment scope. This extraction process allows the system to focus security evaluation exclusively on custom code, significantly reducing the time and computational resources required while maintaining comprehensive security assessment of the relevant code base.

Inventive Principle:
Principle #2Taking out (Extraction)

2Reliability

If dependency code is included in security evaluation, then complete code base is assessed, but complexity of identifying vulnerabilities increases

Engineering Contradiction:
Improvevulnerability identification accuracyVSAvoidanalysis complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the code base into custom and dependency portions using signature checks and binary static analysis. By creating distinct categories for different code types, the system simplifies the vulnerability identification process by applying appropriate analysis methods to each segment. Custom code receives detailed security evaluation while dependency code is handled through fingerprint matching against known repositories, reducing overall analysis complexity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent extracts and identifies dependency code by comparing binary signatures against indexed repositories of known dependencies. Once extracted, dependency code is separated from custom code, allowing the system to focus complex vulnerability analysis only on custom code portions. This extraction reduces analysis complexity by eliminating the need to apply sophisticated vulnerability detection algorithms to well-documented dependency code.

Inventive Principle:
Principle #2Taking out (Extraction)

3Productivity

If altered dependency code is treated as dependency code, then processing speed is maintained, but security risks may be missed

Engineering Contradiction:
Improveassessment efficiencyVSAvoidsecurity risk detection accuracy
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent applies different quality standards and evaluation methods to different portions of code based on their classification. Custom code receives thorough security evaluation with detailed analysis, while unaltered dependency code undergoes faster fingerprint matching. When dependency code is detected as altered through signature mismatch, it is reclassified and subjected to enhanced security evaluation appropriate for custom code, ensuring local quality control adapts to the actual state of each code segment.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent implements a feedback mechanism where the results of signature checks and fingerprint matching determine the subsequent evaluation path. If dependency code fingerprints match known repositories, the code is processed efficiently as dependency code. If mismatches are detected indicating altered code, the system provides feedback to reclassify the code as custom code and apply appropriate security evaluation, ensuring that security risks in modified dependency code are not missed while maintaining overall assessment efficiency.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP3818437B1Binary software composition analysis
Publication Date: 2023.05.10 BLACKBERRY LTD
  • EP3818437B1 patent drawingFigure 1
  • EP3818437B1 patent drawingFigure 2

AI summary

A computer includes a memory and a processor programmed to execute instructions stored in the memory. The instructions include filtering dependency code from a binary file to separate the dependency code from custom code in the binary file. The instructions further include evaluating the custom code in the binary file for a security risk.