Automated Daily Check-in System for Arknights Endfield: Architecture and Implementation

Abstract#

This article presents the design and implementation of akef-checkin, an automated daily check-in system for Arknights Endfield (SKport platform). The system employs a full OAuth 2.0 authorization flow with HMAC-SHA256 request signing to authenticate against Hypergryph and SKport APIs, eliminating the need for manual token refresh. Deployed as a serverless workflow via GitHub Actions, the system executes daily at 16:00 UTC with multi-account support and Discord webhook notifications. We detail the cryptographic signing mechanism, the four-step authentication pipeline, and the deployment architecture.

1 Introduction#

Daily check-in systems for live-service games typically require authenticated API requests to claim rewards. The Arknights Endfield platform (operated by SKport/Hypergryph)¹² implements a multi-layer authentication scheme involving:

1. Long-lived account token (ACCOUNT_TOKEN) — stored by user, valid for weeks to months
2. Short-lived OAuth code — obtained via POST /user/oauth2/v2/grant
3. Session credential (cred) — generated via POST /user/auth/generate_cred_by_code
4. Signing token (signToken) — retrieved via GET /auth/refresh
5. Game role identifier — resolved via GET /game/player/binding

Traditional approaches store short-lived tokens, requiring frequent manual updates. Our system regenerates all transient credentials on every execution using only the long-lived ACCOUNT_TOKEN, achieving zero-maintenance operation³.

2 System Architecture#

2.1 High-Level Overview#

The system comprises four modular components:

2.2 Execution Pipeline#

flowchart TD
    A[Start: Read SKPORT_TOKENS] --> B{For each account}
    B --> C[Step 1: Get OAuth Code]
    C --> D[Step 2: Generate Cred]
    D --> E[Step 3: Get Sign Token]
    E --> F[Step 4: Get Game Role]
    F --> G[Sign Attendance Request]
    G --> H[POST /game/endfield/attendance]
    H --> I{Response Code}
    I -->|0| J[Success: Parse Rewards]
    I -->|1001, 10001| K[Already Signed In]
    I -->|10002| L[Token Expired]
    I -->|Other| M[Failure: Log Error]
    J --> N[Aggregate Result]
    K --> N
    L --> N
    M --> N
    N --> O{More Accounts?}
    O -->|Yes| B
    O -->|No| P[Send Discord Webhook]
    P --> Q[Exit]
    
    style A fill:#f97316,color:#fff
    style Q fill:#22c55e,color:#fff
    style J fill:#3b82f6,color:#fff
    style K fill:#3b82f6,color:#fff
    style L fill:#f97316,color:#fff
    style M fill:#ef4444,color:#fff

3 Authentication Flow#

3.1 Sequence Diagram#

The complete authentication sequence involves two identity providers: Hypergryph (as.gryphline.com) for OAuth grant and SKport (zonai.skport.com) for game-specific credentials.

sequenceDiagram
    participant Script
    participant Gryphline as as.gryphline.com
    participant SKport as zonai.skport.com

    Script->>Gryphline: POST /user/oauth2/v2/grant<br/>{token: ACCOUNT_TOKEN, appCode, type: 0}
    Gryphline-->>Script: {code: "oauth_code"} (one-time use)

    Script->>SKport: POST /web/v1/user/auth/generate_cred_by_code<br/>{code: oauth_code, kind: 1}
    SKport-->>Script: {cred: "session_credential", token: "..."}

    Script->>SKport: GET /web/v1/auth/refresh<br/>(cred, timestamp, platform, vName)
    SKport-->>Script: {token: "sign_token"}

    Script->>SKport: GET /api/v1/game/player/binding<br/>(cred + signed request)
    SKport-->>Script: {list: [{appCode: "endfield", bindingList: [...]}]}

    Script->>SKport: POST /web/v1/game/endfield/attendance<br/>(cred + gameRole + signed request)
    SKport-->>Script: {code: 0, data: {signInCount, awardIds, resourceInfoMap}}

3.2 Cryptographic Signing (V2)#

All signed requests use the V2 signature algorithm: HMAC-SHA256 followed by MD5.

export function generateSignV2(
    path: string,
    timestamp: string,
    platform: string,
    vName: string,
    salt: string
): string {
    const headerJson = JSON.stringify({ platform, timestamp, dId: "", vName });
    const s = `${path}${timestamp}${headerJson}`;
    const hmac = crypto.createHmac("sha256", salt).update(s).digest("hex");
    return crypto.createHash("md5").update(hmac).digest("hex");
}

Mathematical formulation:

Where:

• $\parallel$ denotes string concatenation
• $\text{salt} = \text{signToken}$ (per-session secret)
• $\text{path}$ = API endpoint path (e.g., /web/v1/game/endfield/attendance)
• $\text{timestamp}$ = Unix epoch seconds as string

3.3 Request Structure#

Each signed request includes the following headers:

4 Implementation Details#

4.1 Multi-Account Processing#

The entry point processes accounts sequentially with a 2-second delay between requests to avoid rate limiting:

for (let i = 0; i < accounts.length; i++) {
    const account = accounts[i];
    const result = await performCheckin(account);
    results.push(result);

    if (i < accounts.length - 1) {
        await new Promise(resolve => setTimeout(resolve, 2000));
    }
}

4.2 Response Parsing#

On successful check-in (HTTP 200, code === 0), the response contains reward information:

interface AttendanceResponse {
    code: number;
    message?: string;
    data?: {
        signInCount?: number;
        awardIds?: Array<{ id: string }>;
        resourceInfoMap?: Record<string, { name: string; count: number }>;
    };
}

Rewards are mapped by awardIds → resourceInfoMap and formatted as ItemName xCount.

4.3 Error Handling#

The system categorizes responses into four classes:

5 Deployment Architecture#

5.1 GitHub Actions Workflow#

The system runs serverlessly via GitHub Actions⁴ on ubuntu-latest with Bun runtime:

name: Endfield Auto Check-in

on:
  schedule:
    - cron: '0 16 * * *'  # Daily at 16:00 UTC (00:00 WIB)
  workflow_dispatch:

jobs:
  checkin:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v1
        with:
          bun-version: latest
      - run: bun run src/index.ts
        env:
          SKPORT_TOKENS: ${{ secrets.SKPORT_TOKENS }}
          DISCORD_WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK_URL }}

Schedule interpretation:

• 0 16 * * * → Minute 0, Hour 16 (UTC) → Midnight WIB (UTC+7)
• workflow_dispatch enables manual triggering via GitHub UI

5.2 Secrets Management#

Two repository secrets are required:

Account object schema:

{
  "accountToken": "string (from Network tab)",
  "accountName": "string (display name)",
  "language": "string (optional, default: en)"
}

6 Token Acquisition Procedure#

The ACCOUNT_TOKEN is not visible in browser cookies. It must be extracted from the OAuth grant request:

1. Navigate to https://game.skport.com/endfield/sign-in while logged in
2. Open DevTools (F12) → Network tab
3. Filter for grant
4. Reload page (F5)
5. Select POST https://as.gryphline.com/user/oauth2/v2/grant
6. Open Payload tab (not Response)
7. Copy token value from JSON body:

   {
     "token": "ACCOUNT_TOKEN_HERE",
     "appCode": "6eb76d4e13aa36e6",
     "type": 0
   }

   json

7 Local Development#

7.1 Prerequisites#

• Bun ↗ v1.0+

7.2 Configuration#

cp .env.example .env
# Edit .env with your ACCOUNT_TOKEN

7.3 Execution#

bun run start

Expected output:

Starting Arknights Endfield Auto Check-in...

Processing check-in for account: MyAccount...
  [1/4] Getting OAuth code...
  [2/4] Generating cred...
  [3/4] Getting sign token...
  [4/4] Getting player binding (game role)...
  Auth complete! Game role: 3_12345678_9

**Endfield:** Check-in for `MyAccount`
✅ Success!
 Day: 15
 Rewards: Credit x1000, Synthetic Fuel x5

Sending webhook to Discord...
Done!

8 Security Analysis#

8.1 Threat Model#

8.2 Cryptographic Properties#

The V2 signature⁵ provides:

• Integrity: Any modification to path, timestamp, or headers invalidates signature
• Replay resistance: Timestamp inclusion limits window to ~1 second (server-side validation)
• Key separation: signToken derived per-session, not reusable across accounts

8.3 Operational Security#

• No persistent storage of credentials
• All secrets injected via GitHub Actions encrypted secrets
• Network requests use HTTPS with certificate validation (default in fetch)
• User-Agent mimics legitimate browser (Firefox 147)

9 Related Work#

Our approach differs by eliminating token caching entirely — every execution performs a fresh OAuth grant, trading ~3 extra HTTP requests for zero-maintenance operation.

10 Conclusion#

The akef-checkin system demonstrates a practical application of OAuth 2.0 and request signing for game automation. Key contributions:

1. Zero-maintenance authentication — single long-lived token generates all ephemeral credentials
2. Cryptographically sound signing — HMAC-SHA256 + MD5 V2 algorithm with per-session keys
3. Serverless deployment — GitHub Actions cron with Bun runtime, no infrastructure management
4. Multi-account support — sequential processing with rate-limit awareness
5. Observability — structured logging and Discord notifications

Future work includes: exponential backoff for transient failures, Prometheus metrics export, and support for additional SKport game titles.

Appendix A: API Endpoint Reference#

Appendix B: Type Definitions#

interface AccountConfig {
    accountToken: string;
    accountName: string;
    language?: string;
}

interface AuthResult {
    cred: string;
    signToken: string;
    gameRole: string;
}

interface ResourceInfo {
    name: string;
    count: number;
}

interface AttendanceData {
    signInCount?: number;
    awardIds?: Array<{ id: string }>;
    resourceInfoMap?: Record<string, ResourceInfo>;
}

References#

This article documents the akef-checkin repository as of version 1.0.0. Source code available at the project repository.