Security

Understanding

STOVE Security SDK is a security service that detects tampering/hacking attempts on game apps and protects key memory data.
It consists of the STOVE Mobile Security SDK for mobile (Android/iOS) environments and the STOVE PC Security SDK for PC (Windows) environments.

SDK Types

The two SDKs differ in their provided environments and detection methods, so you must choose the SDK that fits your game platform.

Key Security Features

The core security features that both SDKs provide in common are as follows.

Additional Detection Features

• Mobile SDK STOVE Mobile Security SDK provides additional detection features specialized for mobile environments.

  Feature	Description
  Native-file encryption	Supports encrypting Native files (.so, etc.) in the Android environment. Supports encryption for game engines such as Unreal Engine and Unity
  Malicious-environment detection	Detects malicious execution environments such as Rooting/Jailbreak, Security Folder (Samsung Secure Folder), and Dual App (Parallel Space)
  Emulator-environment detection	Detects whether the App is running in an Emulator environment
  Macro (Auto Clicker) detection	Detects unintended Touch automation in the game (SDK 2.7.0 or higher)
  VPN-environment detection	Detects whether the device is connected to a VPN
  USB/Wifi Debugging-setting detection	Detects whether the USB/Wifi Debugging connection setting in developer options is Enabled
  Key-data encryption	Encrypts Asset Files used by the app and decrypts them in real time when used (SDK 2.6.0 or higher). Encrypts/decrypts in real time the Files used (created) in real time during app execution
  Packet-hijacking detection (planned)	Detects a packet-hijacking environment via whether a Proxy is set

• PC SDK STOVE PC Security SDK provides additional detection features specialized for PC environments.

  Feature	Description
  DLL-integrity monitoring	Monitors in real time whether a DLL is forcibly Detached (Unloaded) or damaged by external programs or aggressive debuggers/manipulation tools. Continuously checks normal-load status against the configured "target DLL list"
  Driver-integrity monitoring	Detects attempts to run/stop/unload our driver, which operates in kernel mode, by external processes or tools. Detects when a driver is forcibly unloaded externally or the service state is manipulated
  Macro/automation detection	Collects the user's input data (including mouse, keyboard, and touch input) and sends it to the server for analysis. Uses an optimized data format for efficient transmission

Support Scope

Requesting SDK Use

To receive the STOVE Mobile Security SDK and PC Security SDK,
contact the Publishing Tech Team (sgs_gsd_t@smilegate.com), and after the app-specific config file is created, the Sample and Plugin will be delivered to you.

Integration Guide

Service Architecture

The overall service architecture of the security SDK is as follows.

• Game Client Through the Security Module, call getChecksum() to generate integrity data and deliver it to the Game Server along with the Token.
• Game Server Deliver the received Checksum and Token to the Security Server to verify integrity.
• Security Server The Token Server verifies the Token and records the verification result (Checksum Verification Result) in the Log Server.
• CDN Update the security SDK through Module Management.
• Actor Manage abusers through Abuser Management and Checksum Management.

App-tampering detection results are verified on the security server and then provided via a real-time dashboard, allowing the game operator to manually sanction users.

App Integrity Verification

This is a REST API server for verifying the Checksum Data generated by the client security module.
Per the Security Server firewall policy, the Live server allows free data communication with no ACL policy,
while the Sandbox Server operates with an ACL policy applied by the Game Server's IP.

• The integrity-verification API doesn't return the verification result in real time; the server only receives the data, and the result is always returned as success. Whether tampering occurred is checked using the logs.
• Even if this API call fails (connect, etc.), it must be handled asynchronously so as not to affect game play.
• We recommend including ChecksumData in the game's important protocols (game entry, lobby movement, etc.) by default so the protocol can't be bypassed.
• If you deliver ChecksumData from the Client via a separate protocol, the game server must, after a certain time, confirm that the ChecksumData was delivered correctly and record a log (to identify users bypassing the security SDK).

• Main Request Body parameter composition
  • packageName (game package name)
  • gameVersion (game version)
  • userInfo (user info)
  • checksumData (the checksum value received from the client)

Security Variables

The STOVE Security SDK V2 security-variable module provides security variables that protect the game's key data loaded in memory.
By applying security variables, you can neutralize malicious searching and manipulation of the game code's key memory.

The supported variable types have the same meaning as ordinary data types and are defined automatically once you include GvtWrapper.h.
The application order consists of two steps: adding the SDK module, then integrating the API.

Security-Setting Status Lookup

This is an API for looking up the account-security-setting status of a STOVE service user.
You can check the user's account-security-setting status, such as login blocking, OTP setting, and whether a designated PC is used.
Based on the looked-up security-setting info, you can implement in-game security-status icons, benefits by security level, and feature-control logic.

• Basic info: GET /v1.0/security/setting
• Host: http://api.onstove.com/auth-secure (LIVE) / http://api.gate8.com/auth-secure (SANDBOX)

Management Page

The Security SDK management page (Manager) is a dashboard for monitoring detection logs and integrity data.
The access paths per environment and the account-request method are as follows.

The management page uses the same URL for both Mobile / PC SDK environments, and charts and logs are shown separately per the environment selected at game registration.

• Dashboard The dashboard is a screen that visualizes detection results by selecting game, platform, and period. The default retention period is up to 1 month, and the default period setting is 7Days.

  Filter	Description
  ① Select game	Select one of the games the user registered
  ② Select Platform	Select Android, iOS, or Both per game (Mobile environment only)
  ③ Select period	Sets the period shown for daily detection counts, daily integrity-verification failures, user detection rankings, and daily visitor counts (excluding the real-time detection count). Default 7Days

The 5 charts provided by the dashboard are as follows.

• Log Monitor A menu for detailed lookup of detection logs by selecting game and period and entering search conditions. Supports running/saving saved search conditions and Activate Column settings (item order/visibility).

  Menu	Description
  ① Select game	Select one of the games the user registered
  ② Enter search conditions	Enter search conditions for the items to look up (see the search syntax below)
  ③ Select period	Sets the period shown in the chart (excluding the real-time detection count). Default 7Days
  ④ Search logs	Searches logs with the conditions entered in ②
  ⑤ Run a saved search condition	Shows the list of search conditions saved via ⑥, and selecting from the list quickly enters the condition
  ⑥ Save a search condition	Saves the search condition performed in ②
  ⑦ Activate Column	Sets the order and visibility of items shown on screen. Check a checkbox to show that item; set the order by mouse drag & drop

Enter search conditions in key=value form, and you can express various conditions by combining the and / or operators and double quotes.

Verifying SDK Execution

You can check whether the SDK module was applied correctly in the Log Monitor menu of the management page.

1. Access the management page and enter the Log Monitor menu
2. Select the game (e.g., stove_mgs2)
3. Set the period and click the Query button
4. Check the columns: date_occur_time, msg, user_info, game_ver, dcv, etc.

You can check the logs of SDK execution this way, and various other logs can also be looked up on the same screen.

Development

Mobile Security SDK

Prerequisites

Before integrating the Mobile Security SDK, check and prepare the items below in advance.

Development Flow

The client ↔ server operation flow of the Mobile Security SDK is as follows. The structure is that the client generates integrity data, which is then delivered to the security server via the game server.

The flow is broadly divided into four steps.

1. Initialization (SUI) : Pass the user identifier issued after STOVE login to the SDK to set the security SDK's user info. : This info is included when sending the Detection Log and Error Log.
2. Scan start (Start) : Enter the game version (versionName) to run the SDK update and Scan features. : After the call, the SDK starts tampering detection in the background.
3. Integrity-data generation (GCS) : Calling GCS about 2 seconds after the Start call returns integrity data (ChecksumData). : This data must be included in the game's important protocols (game entry, lobby entry, etc.) and sent to the game server.
4. Server-side verification : The game server delivers the received ChecksumData to the integrity-verification API Server (/api/checksums/verify). : The response is always returned as success, and the actual detection result is checked via the security server's Log.

Troubleshooting

Cases frequently encountered during integration and the recommended handling.

Sample Code

The core call parts of the SDK-application flow for each platform.

// 1. Create the SDK instance
private static RHNativeWrapper rhNativeWrapper = new RHNativeWrapper();

// 2. Initialize the SDK (pass the user identifier issued after Stove SDK login)
void startSecuritySDK() {
    rhNativeWrapper.SUI("Stove SDK user identifier");

    // Enter the versionName from AndroidManifest.xml
    PackageInfo pi = getPackageManager().getPackageInfo(getPackageName(), 0);
    rhNativeWrapper.Start(this, getApplicationContext().getAssets(), pi.versionName, null);
}

// 3. Generate integrity data (call about 2 seconds after Start)
String getChecksumData() {
    return rhNativeWrapper.GCS();
}

// 4. App-lifecycle integration
@Override
protected void onPause() {
    super.onPause();
    rhNativeWrapper.Pause();
}

@Override
protected void onResume() {
    super.onResume();
    rhNativeWrapper.Resume();
}

// 5. User touch data (SDK 2.7.0+, Macro detection)
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
    rhNativeWrapper.STE(event);
    return super.dispatchTouchEvent(event);
}

Packaging (Android)

Prerequisites

To apply the security SDK to the Android build output, Packaging via RHAPKTool is required.

Development Flow

Packaging works in two steps: configuring packaging.ini and running packaging.bat.

1. Configure packaging.ini : Set paths/options per the [config], [package], [apksign], [filesize], and [assetencrypt] sections. : Enter the game-engine type (Native / Unity3D / Unreal / Cocos2d), keystore, signing options, file-size check, whether to encrypt assets, etc.
2. Run packaging.bat : Perform Repackaging with the rhapktool -package .\packaging.ini command. : Signing is handled automatically in the order zipAlign → apksigner.
3. Confirm Packaging applied : Confirm that the assets/sdata folder is created inside the resulting APK and the security SDK files are added.
4. Checksum registration (management page) : Upload the packaged file via Drag & Drop in the Security SDK menu of the management page and perform Registration.

Troubleshooting

Sample Code

[config]
;0 = apk, 1 = unity, 2 = unreal4, 3 = coco2
type=1

input=C:\Release\app-live-release.apk
manifest_file=AndroidManifest.xml
smali_jar=smali-2.5.2.jar
baksmali_jar=baksmali-2.5.2.jar
java_bin=C:\Program Files\Android\jdk\microsoft_dist_openjdk_1.8.0.25\bin\java.exe
backup=1

[package]
OriAPKPath=C:\Release\app-live-release-rh.apk
NewAPKPath=C:\Release\app-live-release-pack.apk
SecurityPath=C:\Release\securitymodule

;0[APK Mode], 1[AAB Mode]
PackagindMode=0
MinSdkVersion=19

[apksign]
Use=1
KeyStorePath=C:\keystore\keystore.jks
keyStorePass=hohoho
KeyAliasName=Testkey
KeyAliasPass=!a1s2d3f4g5
AdtToolPath=C:\Users\user\AppData\Local\Android\Sdk\build-tools\30.0.2

[filesize]
Use=1
filename001=.so
filename002=.dex
filename003=AndroidManifest.xml

[assetencrypt]
Use=0
filename001=test/text.txt
filename002=test/text.xml
filename003=test/test100.dat

PC Security SDK

The PC Security SDK is applied in 3 steps: add the SDK module → client integration → Server integration.

• Add the SDK module : Download and apply the PC Security SDK per your development environment (Windows Native / Unreal Engine / Unity3D)
• Client integration : Integrate the APIs provided by the STOVE PC Security SDK into the Game Client. : Since the PC Security SDK is standalone, you can selectively apply only the features you need
• Server integration : Server-side REST API integration to deliver the App integrity data generated by the Client to the Security Server

Prerequisites

Before integrating the PC Security SDK, check the items below.

• Folder-structure example The DLL and .SPSS folder can be placed at any relative path from the game exe, but they must be located together in the same folder. A typical folder-structure example is as follows.
  text

  GameProject/
  ├── build/
  │   ├── Game.exe
  │   └── data/                       ← folder name is free
  │       ├── RHCoreSDK.dll
  │       └── .SPSS/                  ← must be in the same folder as the DLL
  │           ├── xxxx
  │           └── xxxx
  ├── pc_security_sdk/
  │   ├── RHCoreSDK.dll
  │   └── .SPSS/
  │       ├── xxxx
  │       └── xxxx
  ├── source/
  └── header/
      └── RHCoreSDKWrapper.h
  

• SDK-module-addition steps per environment The steps to add the SDK module per development environment are as follows. The API-integration call order (Initialize → SUI → Start → GCS → Shutdown) is the same in all environments.

  Environment	Steps
  Windows Native	1. Add RHCoreSDKWrapper.h to the project source tree and use it via #include 2. Place the RHCoreSDK.dll + .SPSS folder at a path relative to the game exe (e.g., data/) 3. Modify RHCoreSDKWrapper.h's RHCORESDKDLLPATH macro to match the actual path (e.g., .\\data\\RHCoreSDK.dll)
  Unreal Engine	1. Copy the StoveSecuritySDKPlugin folder from the delivered security SDK into the project's Plugins folder 2. Close and restart Unreal Editor → in the "Missing Modules" dialog, select "Yes" to auto-rebuild 3. Refresh the Visual Studio project (File → Refresh Visual Studio Project) 4. Check in Solution Explorer whether Plugins/StoveSecuritySDKPlugin is included
  Unity3D	1. Unity menu: select Assets → Import Package → Custom Package... 2. Select the delivered StovePCSecuritySDK.unitypackage file and import all files 3. After import, check the folders: Assets/Editor, Assets/Plugins/Windows/x86_64/RHCoreSDK.dll, Assets/Scripts, Assets/Stove/SDK/Security

Development Flow

The PC Security SDK has the same call flow in the Visual Studio, Unreal, and Unity environments.

The meaning of each call step is as follows.

1. Initialize : Initialization for API use. Receives the security SDK DLL path and loads it. : Call Initialize and Shutdown only once each.
2. SUI : Pass the user identifier to the SDK to include user info in the Detection Log and Error Log. : Don't enter info that directly identifies the user, such as login ID or email.
3. Start : Enter the game version and package name to initialize the SDK and start the Scan. : We recommend calling it early in the game-loading stage.
4. GCS (Generate Checksum) : Generates and returns the App's integrity data. : Call it about 2 seconds after the Start call, and only once. : You don't need to call it again when returning to the start screen after the game ends.
5. Shutdown : Finalizes API use and performs cleanup.

Troubleshooting

Sample Code

#include "RHCoreSDKWrapper.h"

// At game start
if (!RHCoreSDK::Initialize()) {
    MessageBox(hWnd, L"RHCoreSDK.dll load failed", L"Error", MB_OK | MB_ICONERROR);
    // Handle SDK load failure
}

std::string user_info    = "tester";
std::string game_version = "5.0.0";
std::string game_package_name = "com.stove.mobilegamesecurity";

// Set user info
RHCoreSDK::SUI(user_info.c_str());

// Start the security SDK
RHCoreSDK::Start(game_version.c_str(), game_package_name.c_str());

// Generate integrity data then send to the server (about 2 seconds after Start, at game entry/lobby movement)
const char* checksum = RHCoreSDK::GCS();
// → include the checksum in the game protocol and send it to the game server

// At game exit
RHCoreSDK::Shutdown();

Security Variables (Ghost Variable) V2

Prerequisites

The security-variable V2 module is a separate module that protects key data in the memory area and can be used together with the security SDK.

• Add the SDK module (per environment) Include the per-platform library file in the project and add the wrapper file to the applying source.

  Environment	Steps
  Android Native	Place the per-ABI libGvt.so in the jniLibs (or equivalent) directory, and add the wrapper file to the applying source
  iOS	Add Gvt.framework to the project and import the wrapper file
  Windows Native	Place Gvt.dll at a path relative to the game exe, and add the wrapper file to the project
  Unity	1. Copy library into the Assets\Plugins folder (create it if absent) 2. Add GvtWrapper.cs to the source 3. When using the security-variable OFF option: enter NO_USING_GHOST_VAR_TYPE in [File] → [Build Settings] → [Player Settings] → [Other Settings] → [Scripting Define Symbols]

Development Flow

Applying security-variable V2 consists of two steps.

1. Add the SDK module Include the per-platform library file and wrapper file in the project.
2. API integration (Option Interface) After setting the SDK's operation options via the Option Interface functions, use the security variables in your code like ordinary data types.

• The 4 Option Interfaces

  Function	Role
  NO_USING_GHOST_VAR_TYPE	A macro that turns OFF the security-variable module's variable-protection feature. Apply it with #define NO_USING_GHOST_VAR_TYPE. On Unity, set it in Scripting Define Symbols
  SetSwapLinkNum	A function that sets the number of variable stores. A value between 3 and 100 can be set; if not set, the default is used
  SetMemRolling	A function that reallocates variable-store memory. If not set, the default is used
  SetModEventCallbackObj	A function that calls the game code's Callback when variable-value tampering is detected. If not set, no event occurs even when tampering is detected

• When explicit casting is needed When using security-variable objects, explicit casting is needed in the following three cases.

  ① When used with a string-output format

  cpp

  printf("gUInt = %d\n", (int)gUInt);
  

  ② When using an operator after a constant value

  cpp

  CGwInt gnInt;
  gnInt = 100;
  int nTemp = 5 + (int)gnInt;
  

  ③ Conversion between security-variable objects of different types

  cpp

  CGwInt gnInt;
  gnInt = 100;
  
  CGwShort gnShort;
  gnShort = (short)gnInt;
  

  {.is-info}

Troubleshooting

Sample Code

#include "GvtWrapper.h"

class CGhostVarModHandler : public IGvtModEventHandler
{
public:
    CGhostVarModHandler() {};
    virtual ~CGhostVarModHandler() {};

public:
    void ModEventCallback(G_DOUBLE a_dOrg, G_DOUBLE a_dMod)
    {
        printf("[*modified-callback*] org = %f, mod = %f \n", a_dOrg, a_dMod);
    }
};

void GvtInit()
{
    if (!CGvtWrapper::_LoadLib())
    {
        printf("fail to load lib");
        return;
    }

    static CGhostVarModHandler GhostVarModHandler;
    CGvtWrapper::_SetModEventCallbackObj(&GhostVarModHandler);
    CGvtWrapper::_SetSwapLinkNum(50);
}

Frequently Asked Questions