Network License Verification for Android & iOS Automation Scripts: Device Fingerprint + Heartbeat Fault Tolerance

How do you charge for scripts and stop freeloaders? Every script author faces this reality. The old local registration code approach — “compute a code, hand it to the user” — stopped working long ago: a cracker can patch one comparison to bypass it, license keys replicate endlessly, and the author earns nothing while staring helplessly.

Network license verification + card-key system is the mainstream licensing approach in the phone automation script industry: licenses bind to devices, heartbeats keep validating, and cloud variables are controllable remotely. And it is not Android-only — Apple iOS scripts (Center and Offline editions) are supported too, with all three platforms sharing one platform. This article explains the whole picture: platform-side configuration, script-side integration, the differences between Android and iOS, and how fault tolerance and anti-crack are designed.

1. Architecture: Authorization in the Cloud, Validation in the Script

The core idea of network verification: the license state lives on the server, not in the script.

User enters license → script requests binding → server validates and records the device
        ↓
Script runs normally with continuous heartbeats (built in, no extra calls)
        ↓
Expired / disabled / different device → server rejects → script reports error

• Authorization validation: whether a license is valid and bound to the current device is decided by the server;
• Continuous heartbeat: not “validate once and done” — the script keeps communicating while running, so a disabled license takes effect immediately;
• Script security validation: optional checks on package name and APK/script fingerprints to prevent re-shelling and tampering — a differentiator versus most network verification platforms on the market.

Supported platforms at a glance

Platform	Minimum version (direct function calls)	Notes
Android	EC Android 9.13.0+	No SDK integration; call ecNetCard functions directly
iOS Center	iOS Center 6.12.0+	Below this version, download the network verification SDK and integrate manually
iOS Offline	iOS Offline 3.1.0+	Same; SDK integration below this version

All three platforms share the same user center (uc.ieasyclick.com), the same ecNetCard functions, and the same license system — one licensing solution covering Android and Apple scripts.

2. Platform-Side Setup: Three Steps in the User Center

Log in to the user center (uc.ieasyclick.com); the core operations live in three modules.

2.1 Software list: create a “software” first, get the appid

Adding a software gives you the appid and secret — the parameters ecNetCard.netCardInit needs to initialize the license.

Options to notice when creating a software:

Option	Description
Software type	Choose Android or iOS — a wrong choice may fail parameter matching
Verify APK fingerprint	Whether to verify the apk file (upload the apk in the script list first)
Verify script fingerprint	Whether to verify the .iec script (upload the iec first)
Heartbeat error count	Fault tolerance for heartbeat requests; errors are reported only after the threshold is reached
License verification error count	Fault tolerance for license validation, prevents false positives
Script verification error count	Fault tolerance for script-file validation
Enable verification	Master switch for the whole software; set to No during development
Status	When disabled, all licenses fail and scripts receive the error

Advice: keep APK fingerprint and script fingerprint verification off during development (no files uploaded yet). Keep your packaged apk and iec files; upload and enable verification later if you find a crack or want to disable a script.

2.2 Script list: register your .iec files

The script list registers a record for each compiled .iec file:

Field	Description
Software version	Script version info, e.g. 1.0
Package name	Android only; fill in the packaged APK package name — filling it enables verification, and a package-name mismatch stops the script
APK fingerprint	MD5 of the apk; filling it verifies the apk file
Script fingerprint	MD5 of the .iec file; filling it verifies the .iec file

Fill in only one of package name, APK fingerprint, or script fingerprint. Uploads do not store your files — only MD5s are computed. Network verification also works without creating a script record.

2.3 License management: generate and batch-operate

License management generates network verification cards, supporting one device per card and multiple devices per card:

Field	Description
Generate count	How many cards to generate at once
Valid days	License validity days; the clock starts at first device binding — no usage, no countdown
Unbind password	Required to unbind a device; without it, unbinding needs no password
Kick-off feature	On multi-device cards, a newly requesting device automatically disconnects the first bound device

Two batch operations are especially useful:

• Batch add time: extend selected licenses without the customer rebinding;
• Batch add online slots: increase the device capacity of selected licenses without rebinding.

3. Script-Side Integration: ecNetCard in Practice (Android / iOS)

Core flow, four steps: initialize → bind → validate → run. The Android example below:

function main() {
    // Custom device ID (optional, EC Android 11.21.0+, max 32 chars)
    ecNetCard.setDeviceId("123")

    let appId = "sjfjvkpw"        // from the user center admin panel
    let appSecret = "ykjscxcs"    // from the user center admin panel
    let cardNo = "cbwolrftnw"     // the license the user purchased

    // 1. Initialize the license
    let inited = ecNetCard.netCardInit(appId, appSecret)
    logd("inited card => " + JSON.stringify(inited));

    // 2. Bind the license
    let bind = ecNetCard.netCardBind(cardNo)
    let bindResult = false;
    if (bind != null && bind != undefined && bind["code"] == 0) {
        logd("License bound successfully")
        logd("Days left: " + bind['data']['leftDays'])
        logd("Activated at: " + bind['data']['startTime'])
        logd("Expires at: " + bind['data']['expireTime'])
        bindResult = true;
    } else {
        logd("License binding failed: " + (bind == null ? "no return value" : bind["msg"]))
    }

    if (!bindResult) {
        return // binding failed, stop the script
    }

    // 3. Get a cloud variable (string or JS code)
    let user_ageJson = ecNetCard.netCardGetCloudVar("user_age")
    logd("Cloud variable value => " + user_ageJson['data'])

    // 4. Run your business logic...
    while (true) {
        sleep(1000)
    }
}

main();

The difference for Apple iOS scripts: the calling pattern is identical — the only difference is that netCardInit takes a third parameter, deviceIdType:

// iOS Center / iOS Offline
// deviceIdType: 1 = use the device id, 2 = use ecid (iOS Center 6.29.0+, iOS Offline 3.9.0+)
let inited = ecNetCard.netCardInit(appId, appSecret, "2")

Note (iOS Offline): if you initialize via online network mode, deviceIdType must be 1, or initialization may fail.

3.1 Function reference

Function	Purpose
netCardInit(appId, appSecret, deviceIdType?)	Initialize the license; Android has no third parameter, iOS accepts deviceIdType (1=device id, 2=ecid)
netCardBind(cardNo)	Bind the license; code=0 means success, data holds days left / activation / expiry
netCardGetCloudVar(name)	Get a cloud variable
netCardUpdateCloudVar(name, value)	Update a cloud variable (requires “remote modify” enabled in the admin panel)
netCardUnbind(cardNo, password)	Unbind the license (can also be done in the admin panel)
setDeviceId(deviceId)	Custom device ID (Android 11.21.0+, max 32 chars)

Heartbeat verification is built into the license — no extra calls. After binding succeeds, the script keeps heartbeating with the server while running; disabled, expired, or mismatched licenses respond in real time. Whether using the built-in or SDK version, the calling pattern is the same — all functions are prefixed with ecNetCard.

4. Cloud Variables: The “Remote Kill Switch” After a Crack

Cloud variables are a critical piece of this system: set a variable in the cloud, fetch it dynamically while the script runs. It can be a plain string or a snippet of JS code — the script retrieves it and executes it via eval.

// Get a cloud variable
let configJson = ecNetCard.netCardGetCloudVar("auth_config")
// If the content is JS code, execute it with eval
eval(configJson['data'])

Why it matters:

• Dynamic switches: change one value in the admin panel, and every deployed script changes behavior instantly;
• Remote hot-fix: keep critical logic in the cloud; when a crack is found, replace the code so the script stops or enters a “please purchase” state;
• Staged rollout: deliver different configs to different users as needed.

When a crack is discovered, replace the remote code and stop the script immediately — the most direct “one-click damage control” in the official anti-crack recommendations.

5. Hot-Update Management: Licensing and Updates in One Place

The network verification platform ships with hot-update management, connected to Alibaba Cloud OSS:

1. Configure OSS: create a user in Alibaba Cloud RAM for AccessKeyId / AccessKeySecret, grant AliyunOSSFullAccess, and fill the values into the platform’s OSS configuration; if the bucket has permission issues, create the bucket manually and enable public read;
2. Upload scripts: add a script and upload the .iec file (version as an integer) — it uploads to OSS automatically and generates a download URL and MD5;
3. Set the hot-update URL: copy it from the software list and paste it into the script’s update.json.

There are two update URLs: the new one supports EC Android 9.31.0+ and iOS Offline 3.17.0+, with encrypted communication; the old one exists for compatibility with older versions and is unencrypted. To block the old URL, set “hot-update compatibility” to new-only in the software list.

6. Summary

The network license system, at its core, turns script commercialization into infrastructure — and one solution covers both Android and Apple:

• Cross-platform: Android / iOS Center / iOS Offline share one platform, one set of ecNetCard functions, and one license system;
• Licensing: licenses bind to devices with continuous heartbeats; license state is controllable on the server in real time;
• Fault tolerance: triple thresholds for heartbeat / license / script, so network jitter does not kill legitimate users;
• Anti-crack: triple checks of package name + APK fingerprint + .iec fingerprint, combined with obfuscation and remote cloud-variable kill switches;
• Operations: batch add time, batch add online slots — extend and expand without rebinding;
• Updates: hot-update management built in; authorization and distribution on one platform.

For authors who depend on scripts for a living, network verification is not optional — it is the gate that turns a script from “a piece of work” into “a product”. Whether your scripts run on Android or Apple, install it, and you finally hold the fate of your own code.