Runtime Data Recovery via Hash-Based Salt Generation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing software implementations are vulnerable to static analysis and reverse engineering, allowing attackers to easily retrieve sensitive data such as function addresses and decryption keys, as all important data variables are static and easily readable.

Innovation Solution

A method involving hashing data during build-time to create a salt, which is stored and used at runtime to recover sensitive data, while ensuring the salt does not statically reveal the secret value, and using a hash function to verify the sensitive value without direct comparison.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If sensitive data is stored statically in the program, then the program can access the data during operation, but the attacker can easily retrieve the data through reverse engineering

Engineering Contradiction:
Improvedata accessibilityVSAvoiddata exposure to attacker
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The patent divides sensitive data into two segments: a hash value (stored statically) and a salt value (computed at runtime). The hash is embedded in the program while the salt is generated dynamically by hashing an image at runtime. When needed, the program combines these segments through reverse combining to recover the sensitive data. This segmentation prevents attackers from retrieving complete sensitive data through static analysis alone.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent performs preliminary hashing of an image at build time to generate the hash value, which is then embedded in the program. This preliminary action allows the runtime system to efficiently compute the salt by hashing the same image again and combining it with the embedded hash, enabling fast recovery of sensitive data without storing it directly.

Inventive Principle:
Principle #10Preliminary action

2Object-affected harmful factors

If the salt is computed at runtime, then the sensitive data is not statically revealed, but additional computation time is required

Engineering Contradiction:
Improvedata secrecyVSAvoidcomputation time
Core Design Contradiction:
Object-affected harmful factorsVSLoss of time

Solution Approach 1:

The hash value is pre-computed during build time and embedded in the program. At runtime, only the image needs to be hashed (a relatively fast operation) and combined with the embedded hash through reverse combining. This preliminary preparation significantly reduces the runtime computation burden compared to computing everything from scratch.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent uses the property that hashing the same image produces the same hash value. By embedding the pre-computed hash and copying it back through the reverse combining process, the system efficiently recovers sensitive data without requiring complex runtime computations or storing the sensitive data directly.

Inventive Principle:
Principle #26Copying

3Device complexity

If the entire software is extracted by the attacker, then all static data variables can be read, but the attacker cannot easily determine which data is sensitive without reverse engineering

Engineering Contradiction:
Improvedata analysis complexityVSAvoidsensitive data retrieval
Core Design Contradiction:
Device complexityVSLoss of information

Solution Approach 1:

The patent makes only the hash value visible in the static code, while the sensitive data remains hidden. The hash alone is meaningless without the runtime-computed salt. This local differentiation in data visibility means that even if attackers extract and analyze the entire program, they can only see the hash (which appears as random data) but cannot directly access or infer the sensitive values without executing the runtime computation.

Inventive Principle:
Principle #3Local quality

Data Source

PatentEP2831800B1Method for protecting data
Publication Date: 2020.05.06 IRDETO BV
  • EP2831800B1 patent drawingFigure 1
  • EP2831800B1 patent drawingFigure 2
  • EP2831800B1 patent drawingFigure 3

AI summary

In the present disclosure, a hash function is computed over a known image, for example, an address range in a program. The result of the hash function is known to be the same at two distinct points in time, before the program is run, i.e. signing at build-time, and during the running of the program, i.e. run time. The value that the programmer wishes to hide, i.e. the secret value, is also known at build-time. At build-time, the secret value is combined with the hash in such a way that the combining operation can be reversed at run time. This combined value, i.e. the salt, is stored along with the program. Later, at runtime, the program computes the same hash value as was computed at signing time, and does the reverse combining operation in order to reveal the secret value.