Linker Load-Time Security Transformations

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing methods for protecting software from tampering require rebuilding software modules whenever security decisions change or diverse instances need to be created, which is expensive and time-consuming, and do not effectively address differential attacks.

Innovation Solution

A software linker or loader that applies security transformations at build-time or load-time using pseudo-random number generators to randomize memory image relocations, select diverse code instances, and perform late-binding of constants, allowing for the creation of diverse and secure executable or dynamic-library instances without recompiling.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If security transformations are applied at compile-time by re-building software modules, then security protection is improved, but build-time cost and complexity increase

Engineering Contradiction:
Improvesecurity protectionVSAvoidbuild-time cost
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

Security transformations are applied in advance at compile-time to generate transformed object-code, but the actual security parameters and transformations are deferred to link-time. This preliminary action prepares the code structure while leaving security customization for later, avoiding repeated full rebuilds when security decisions change.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The software module is segmented into transformed object-code (compiled once) and security parameters (configured at link-time). This separation allows the compiled code to be reused while only the linking step needs to be repeated for different security configurations, reducing build-time cost.

Inventive Principle:
Principle #1Segmentation

2Speed

If deterministic memory layout is used by traditional linkers, then runtime performance is optimized, but security against attacks is reduced

Engineering Contradiction:
Improveruntime performanceVSAvoidsecurity protection
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The linker generates diverse memory layouts dynamically at link-time based on random seeds, rather than using a fixed deterministic layout. This dynamic approach ensures that each linked executable has a unique memory arrangement, preventing attacks that rely on predictable section locations while still allowing the linker to optimize layout for runtime performance within each instance.

Inventive Principle:
Principle #15Dynamics

3Reliability

If security transformations are applied to source code, then protection from reverse engineering is improved, but flexibility to revisit security decisions is reduced

Engineering Contradiction:
Improveprotection from reverse engineeringVSAvoidflexibility to revisit security decisions
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

Source code is pre-transformed with security measures, but the specific transformation parameters are not finalized until link-time. This allows security decisions to be revisited and modified at link-time without requiring source code changes or re-compilation, combining strong initial protection with flexible later adjustment.

Inventive Principle:
Principle #10Preliminary action

4Reliability

If diverse instances of software modules are created, then resistance to differential attacks is improved, but build-time cost increases

Engineering Contradiction:
Improveresistance to differential attacksVSAvoidbuild-time efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The software is segmented into a common transformed object-code base and variable security parameters. Multiple diverse instances are created by linking the same object-code with different security parameters and random seeds, avoiding the need to re-compile and enabling efficient generation of diverse instances.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Instead of creating entirely separate compiled instances for diversity, the system creates copies of the transformed object-code and applies different link-time transformations (memory layouts, symbol resolutions, constant bindings) to generate diverse instances efficiently.

Inventive Principle:
Principle #26Copying

Data Source

PatentEP2553570B1Method for linking and loading to protect applications
Publication Date: 2018.08.15 IRDETO BV
  • EP2553570B1 patent drawingFigure 1
  • EP2553570B1 patent drawingFigure 2
  • EP2553570B1 patent drawingFigure 3

AI summary

A linker or loader, and associated method, is described, whereby the application of security transformations to object-code modules can be deferred until link or load-time, through, for example, memory relocation, selection from diverse instances of a module, and late-binding of constants. This provides several benefits over conventional source-to-source security transformations. These deferred security transformations can be applied in a very light-weight manner and create many opportunities for diversity in the resulting executable program, enhancing security, while at the same time minimizing the impact on execution performance and correctness, and reducing the complexity of debugging.