Documentation

KeeProtect documentation for protected delivery workflows

Client-facing guidance for preparing binaries, adding optional protection markers, submitting jobs, testing protected artifacts, managing internal entitlements, and opening support requests.

Overview

KeeProtect is a protected delivery portal for software vendors. It connects approved client workspaces, product records, protection configurations, protected binary jobs, protected artifact downloads, internal entitlement records, release packages, support tickets, forum knowledge, and audit history.

KeeProtect is designed for controlled binary protection and release workflows. It is not presented as a public licensing platform for customers to resell as an independent licensing service. Serial, activation, seat, and HWID records are internal controls used to operate KeeProtect-managed protected delivery.

Only upload binaries, release packages, and metadata that you own or are authorized to protect and distribute.

  1. Create or receive access to an approved KeeProtect account.
  2. Confirm that the correct plan, product, protection configs, and release channels are visible in the client area.
  3. Prepare a clean release candidate binary and add optional source markers when your plan/config supports marker-aware protection.
  4. Submit the binary from Client Area > Protection and choose the matching product and protection configuration.
  5. Track the job in Client Area > Jobs until it is protected or requires support review.
  6. Download the protected artifact, verify the SHA-256, test on a clean machine, then publish it through your release process.

Account setup

  • An approved account with the correct company, contact, and business e-mail details.
  • One active plan. Buying a new plan replaces the previous active plan for the account.
  • At least one active product workspace assigned to the account.
  • At least one active protection configuration visible to the product.
  • A valid internal entitlement record when activation, seats, HWID recovery, or release eligibility is required.

Plans control the number of active product workspaces, the number of active internal license seats, available protection profiles, release channels, billing behavior, and support priority.

StarterOne product workspace, one active seat, Stable profile.
ProMore product workspaces, one active seat, Stable, Marked, and Hardened profiles.
ResellerOne active plan with multiple assignable customer seats and invite workflows.
BusinessBusiness plans add broader product, release, support, and seat capacity according to the active plan.

Build preparation

  • Upload a release candidate, not an unstable debug build.
  • Keep source maps, private symbols, signing keys, private API keys, and customer secrets out of the uploaded artifact.
  • Do not pre-pack or pre-obfuscate the binary unless your onboarding notes say that the chosen protection config supports it.
  • Keep the build deterministic where possible so file hashes and support reproduction are easier to compare.
  • Prefer signing after protection unless your product-specific pipeline states otherwise.
  • Test the original binary before upload and the protected binary after download on a clean Windows environment.

  • Product name and target platform.
  • Application version and intended release channel.
  • Selected protection configuration name.
  • Expected startup command or smoke-test behavior, if support needs to reproduce a launch issue.
  • Original file SHA-256 when you want support to compare local and uploaded artifacts.

Source markers

Markers are optional source-level hints that identify small, sensitive regions of your code. Marker-aware protection configs can use those regions to focus stronger protection around entitlement checks, premium feature gates, update verification, anti-tamper decisions, or other high-value logic.

Use the marker SDK, header, package, or naming convention supplied during onboarding. The examples below show the intended structure only; do not invent marker APIs if your assigned config does not support them yet.

Never put secrets, signing keys, private admin URLs, payment secrets, or server-only trust decisions in client code just because that code is marked.

Place paired begin and end markers around a small decision block. Keep the protected region narrow and easy to test.

#include "KeeProtectMarkers.h"

bool ValidateAccess(const LicenseContext& ctx)
{
    KP_MARKER_BEGIN("license.validation");

    const bool signatureOk = VerifySignature(ctx.Token);
    const bool deviceOk = IsAllowedDevice(ctx.DeviceFingerprint);

    KP_MARKER_END("license.validation");

    return signatureOk && deviceOk;
}
  • Use stable marker names such as license.validation or feature.premium-gate.
  • Do not wrap an entire application entry point or a full UI screen.
  • Do not place begin and end markers in different functions, files, threads, or exception paths.

For managed applications, use the marker package supplied for your onboarding flow. Keep marker calls close to the logic they describe.

using KeeProtect.Markers;

public bool CanOpenPremiumFeature(UserSession session)
{
    KeeProtectMarker.Begin("feature.premium-gate");

    var allowed = session.HasActiveEntitlement
        && session.ReleaseChannel == "stable"
        && session.DeviceIsTrusted;

    KeeProtectMarker.End("feature.premium-gate");

    return allowed;
}

If a marker-aware config is not enabled for the product, these calls should be compiled out or left inactive according to the SDK notes supplied to your team.

Good targetsEntitlement validation, feature unlock checks, update manifest verification, release-channel gates, anti-tamper decisions.
AvoidLogging, UI labels, config parsing, large loops, entire modules, third-party library code, unrelated network retry code.
Keep names stableChanging marker names between builds makes support comparison harder.
Test each regionAfter protection, verify startup, login, protected feature access, updates, and rollback behavior.

Protection jobs

  1. Open Client Area > Protection.
  2. Select the product workspace that owns the binary.
  3. Select the protection configuration by its client-facing name.
  4. Upload the binary and confirm the selected profile.
  5. Submit the job and keep the job reference for support.

Only active configs assigned to your current plan and product should appear in the dropdown.

QueuedThe job is recorded and waiting for the protection worker.
ProcessingThe worker has claimed the job and is building the protected artifact.
ProtectedThe protected artifact is available for download and verification.
FailedThe job did not complete. Open support with the job reference and visible error.

Logs are intended to help clients and support understand the selected config, component type, preset, input file name, hash, status, and high-level processing result. Internal worker implementation details, private paths, secrets, and template internals should not be used as client-facing documentation.

Profiles and plans

StableCompatibility-first baseline for normal protected releases.
MarkedUses approved marker regions to focus protection on selected logic.
HardenedStronger profile for sensitive builds after product-specific testing.
Ultra / ProductionAdvanced or release-oriented profiles that may require onboarding, plan access, and additional validation.

  • Smoke launch the protected binary on a clean machine.
  • Verify login, entitlement checks, premium feature gates, update checks, and release-channel behavior.
  • Verify anti-virus and endpoint-security behavior for the final protected artifact.
  • Confirm updater and rollback behavior before promoting a package to customers.
  • Keep a rollback-ready unprotected reference build in your own private storage.

Internal entitlements

KeeProtect can show serial numbers, activation codes, active seats, expiration dates, update eligibility, device bindings, and status. These records support protected delivery, activation control, device recovery, billing validation, and audit history inside the KeeProtect portal.

They are not a promise that KeeProtect is a standalone licensing SaaS for resale. Treat them as KeeProtect-managed access and support records for your protected products.

Each user can receive the configured monthly free HWID reset allowance. Extra requests create a paid reset order when configured. After payment, the request can move to review and approval according to admin policy.

Request a reset only when the device was replaced, the operating system was reinstalled, or the binding no longer matches the legitimate customer device.

Reseller and eligible business plans can assign customer seats without creating a second active plan for the owner account. Existing users receive the assigned entitlement. New users receive an invite link with the assigned entitlement reserved for account creation.

Invite links are time-limited. Do not publish invite links publicly or send them to administrator accounts.

Release delivery

  • Product name and version.
  • Stable, beta, private, or configured release channel.
  • Protected artifact URL or package reference controlled by KeeProtect access rules.
  • SHA-256, size, critical flag, minimum required build, notes, and manifest metadata.
  • Smoke-test notes and rollout/rollback notes when needed.

No. Release downloads are scoped to the account, plan, product, and release channel inside Client Area > Releases. Customers should only see packages they are eligible to access.

Always verify the visible SHA-256 after download and before publishing or installing a protected artifact.

Troubleshooting

No config in dropdownConfirm the account has one active plan, an active product, and an active config allowed by the plan.
Upload rejectedCheck file type, size, product selection, account status, and whether the binary is already packed.
Job failedOpen support with the job reference, file hash, visible error, profile, and version.
Protected app fails to launchRetest with Stable, remove oversized marker regions, verify signing order, and provide a clean reproduction path.
Marker not appliedConfirm the selected config is marker-aware and marker names match the onboarding package.
Activation issueCheck internal entitlement status, expiration, device binding, and whether an HWID reset is pending.

Support payload

  • Company and contact e-mail.
  • Product name, version, platform, and release channel.
  • Protection job reference, selected config name, profile, and component type when visible.
  • Input SHA-256 and output SHA-256 when available.
  • Internal serial or activation reference when the issue is related to activation or device binding.
  • Exact error message, screenshot, and the shortest reproduction steps.
  • Whether the original unprotected build starts correctly on the same test machine.
Do not send private keys, payment secrets, admin credentials, customer passwords, or proprietary source code in tickets unless support explicitly asks for a sanitized diagnostic sample.