Setting up the SDK

To ensure the correct functioning of the SDK. Make sure you have a gateway setup.

Examples of Complete implementation

public static void LoginCheck() {
 if(API.ValidLogin("user", "password")) { 
   LaunchApplication();
 }
 else { 
  ShowFailedLogin();
 }
}

The method LoginCheck() checks if the login is valid by calling the API method ValidLogin() with the "user" and "password" as arguments.
If the login is valid, the method LaunchApplication() is called.
If the login is invalid, the method ShowFailedLogin() is called

public sealed record UserLogin(string User, string Password);
// Check if login is valid using the CyphorSDK and the provided UserLogin object
// Note: UserLogin is not a required structure and can be adjusted to match any
// structure the customer's licensing uses
public static void LoginCheck() {
CyphorSDK.SignIn<UserLogin>(new UserLogin(user: "user", password: "password"));
}

// If the login is valid, launch the application
[CyphorSDK.AuthResult(Result = Authorization.Valid)]
public static void LaunchApplication(...) {
//
}

// If the login is invalid, show a failed login message
[CyphorSDK.AuthResult(Result = Authorization.Invalid)]
public static void ShowFailedLogin(...) {
//
}

A new record type UserLogin is defined, which takes two properties "User" and "Password" as inputs.
The method "LoginCheck" is changed to use a Cyphor SDK method "SignIn" and passing in a new instance of UserLogin.
Two new methods are defined with attributes "CyphorSDK.AuthResult" which are "LaunchApplication()" and "ShowFailedLogin()". They are used to handle the result of the "SignIn()" method.
The "LaunchApplication()" method is called when the login is valid, the "ShowFailedLogin()" method is called when the login is invalid.
The method is no longer calling the API method "ValidLogin()" but it's using the Cyphor SDK library to check if the login is valid.

The structure of the UserLogin can be adjusted to match any structure the customer's licensing uses.

The methodsLaunchApplication and ShowFailedLogin are automatically invoked by the SDK based on the signin response.

Partial implementation

The partial implementation of our tamper protection would be similar to the complete implementation described above; however, instead of handling the user's login, the tamper protection would verify the customer's session.

This approach allows for the tamper protection to be integrated into existing systems without the need for a complete overhaul of the existing licensing infrastructure.

public static void LoginCheck() {
 if(API.IsValidLogin("user", "password")) { 
   LaunchApplication();
 }
 else { 
  ShowFailedLogin();
 }
}

public sealed record SessionToken(string Token);

// Check if login is valid using the API, then verify the customer's session
// using the CyphorSDK
public static void LoginCheck() {
// Attempt to login with the provided user and password
var loginResult = API.Login("user", "password")

// Use the CyphorSDK to verify the customer's session using the returned token
CyphorSDK.SignIn<SessionToken>(new SessionToken(token: loginResult.Token));
}

// If the customer's session is valid, launch the application
[CyphorSDK.AuthResult(Result = Authorization.Valid)]
public static void LaunchApplication(...) {
//
}

// If the customer's session is invalid, show a failed login message
[CyphorSDK.AuthResult(Result = Authorization.Invalid)]
public static void ShowFailedLogin(...) {
//
}

This code uses the SessionToken structure (which can be modified to match any customer structure) to query the customer's backend and verify the validity of the customer's session.

Our servers will use the SessionToken to perform this verification with your servers.

The use of the SessionToken allows for the verification process to be performed without exposing the customer's licensing infrastructure to potential attackers. This approach ensures that the authentication process has been successful and the customer's session is valid before allowing the application to launch.

FAQ

Does the SDK require any additional hardware or software to be installed?

No, the SDK does not require any additional hardware or software to be installed. The SDK is a software-based solution that can be integrated into your application with minimal setup and configuration.

Can the SDK detect and prevent tampering in real-time?

Yes, the SDK is designed to detect and prevent tampering in real-time. It uses multiple tamper detection techniques to constantly monitor your application for any signs of modifications, and it can automatically take action to prevent or mitigate any detected tampering.

What stops attackers from removing the calls to the SDK?

Removing the calls to the authorization methods is a common concern when using our solution. However, the CodeGuard SDK is designed to prevent this type of attack by injecting numerous anti-tampering checks throughout the application.

This makes it difficult for an attacker to remove the calls to any authorization method without being detected.

Additionally, the SDK uses is obfuscated. This means that an attacker would first need to reconstruct and reverse-engineer the app to be able to remove any authorization calls, which is a very difficult and time-consuming task.

Furthermore, The SDK can store some values on the server side and validate them on runtime. An attacker would need to bypass the whole server-side validation to be able to remove the calls to the "SignIn" method.

In summary, the CodeGuard SDK is designed to make it difficult for an attacker to remove the calls to the authorization methods.

PreviousSetting up a gateway NextSecured values

Last updated 2 years ago