Secured values
Secured values are constant values of your application that are erased from your software and can only be recovered after the software passes several integrity check challenges.
Our platform offers three types of secured values.
Preemptive secured values: Any value that is required before the user inserts a valid license in the program.
Active secured values: Any value that is required after the user inserts a valid license in the program.
Managed value: Values inserted and managed by Codeguard automatically.
Secured values vs Constant encryption
Secured values are significantly more difficult to dump and reverse engineer than standard constant obfuscation. This is because secured values require the connection to pass through a series of authentication challenges before being able to retrieve the values, making it impossible for an attacker to access them ahead of time.
Additionally, secured values are not stored on disk, making them inaccessible to attackers without connecting to our servers.
In comparison, standard obfuscation requires that values remain in the file for decryption during the program execution, making them relatively easy to dump and reverse engineer.
If security against reverse engineering is a top priority, secured values are the way to go as they significantly increase the skill level required for an attacker to successfully dump and reverse engineer the values.
Security Considerations.
Keeping business-sensitive values within client-side applications is not recommended, even with protections in place.
Credentials such as those for remote servers, emails, and others should be stored on the server side and not present in client files.
Although secured values provide a high level of security against analysis and de-obfuscation attacks, it is still possible for attackers to locate the values in the memory which could lead to data leak.
Setting up secured values
Securing an insolated preemptive value
After compilation and the application being processed by our nodes; the decompilation would look as follows:
Securing an insolated preemptive value
After compilation and the application being processed by our nodes; the decompilation would look as follows:
Securing the values of a class where the user hasn't yet logged in
Securing the values of a class with preemptive values while excluding one value.
After compilation and the application being processed by our nodes; the decompilation would look as follows:
Last updated