crypto-recon-har

name	crypto-recon-har
description	Reads and analyzes HAR (HTTP Archive) files from browser DevTools intercept. Extracts real API endpoints, actual signatures, request/response structure, and auth tokens. Natural entry point before crypto-recon-building — provides real data instead of guesses.

Crypto Recon — HAR File Analyzer

Purpose

HAR files are the ground truth. They contain every HTTP request the browser made — real endpoint URLs, real request bodies with real signatures, real headers, real tokens. Reading a HAR file eliminates all guesswork from crypto-recon-building and provides ready-to-use test vectors for crypto-recon-debugging.

When to Use

• User says "ini file HAR nya", "saya capture dari DevTools", "ini intercept nya"
• User provides a .har file path
• User wants to build a flow but has captured traffic first
• After crypto-recon-orchestrator finds signing logic — HAR confirms it with real data

How to Get a HAR File (for user reference)

Browser DevTools → Network tab
→ Lakukan aksi di web (login, register, bet, dll.)
→ Klik kanan di Network tab → "Save all as HAR with content"
→ Save as [domain].har
→ Kasih path ke Claude

Also works with:

• Burp Suite export → "Save items" → HAR format
• mitmproxy: mitmdump -w output.har
• Charles Proxy: File → Export Session → HAR

Phase 1: Parse the HAR

Run:

python tools/parse_har.py <har_file> [--domain <domain>]

This reads the HAR JSON and extracts all entries.

HAR structure:

{
  "log": {
    "entries": [
      {
        "request": {
          "method": "POST",
          "url": "https://domain/api/user/login",
          "headers": [{"name": "X-Sign", "value": "A1B2C3..."}],
          "postData": {
            "mimeType": "application/json",
            "text": "{\"username\":\"test\",\"signature\":\"A1B2C3\",\"random\":\"uuid\",\"timestamp\":1748123456}"
          }
        },
        "response": {
          "status": 200,
          "content": {
            "text": "{\"code\":0,\"data\":{\"token\":\"eyJhb...\",\"userId\":12345}}"
          }
        }
      }
    ]
  }
}

Phase 2: Filter & Classify Requests

Skip static assets — only keep API calls:

Keep:

• Content-Type: application/json requests
• URLs containing /api/, /v1/, /v2/, /user/, /auth/
• POST/PUT/PATCH requests with body
• Any request with crypto-relevant headers

Skip:

• .js, .css, .png, .ico, .woff responses
• Preflight OPTIONS requests
• CDN/analytics/tracking URLs (google, facebook, sentry, etc.)

For each kept request, classify:

LOGIN       → URL contains: login, signin, auth/token
REGISTER    → URL contains: register, signup, create
BET/GAME    → URL contains: bet, game, lottery, spin
WITHDRAW    → URL contains: withdraw, cashout
RECHARGE    → URL contains: recharge, deposit, topup
USER_INFO   → URL contains: user/info, profile, me
REFRESH     → URL contains: refresh, token/renew
OTHER       → everything else

Phase 3: Extract Crypto Evidence

For each API request, extract crypto-relevant data:

From Request Body

Parse JSON body and look for:

CRYPTO_FIELDS = {
    "signature", "sign", "sig", "_sign",
    "random", "nonce", "rand", "_nonce",
    "timestamp", "ts", "t", "_t",
    "token", "accessToken", "access_token",
    "encrypted", "encData", "enc_data",
    "hash", "_hash",
}

Also look for fields that are clearly crypto output:

• 32-char hex string → likely MD5 signature
• 64-char hex string → likely SHA256
• Long base64 string → likely encrypted payload or JWT
• UUID format → nonce

From Request Headers

CRYPTO_HEADERS = {
    "Authorization", "X-Token", "X-Auth-Token",
    "X-Sign", "X-Signature", "X-Request-Sign",
    "X-Nonce", "X-Timestamp", "X-Access-Token",
    "X-Api-Key", "X-App-Key",
}

From Response Body

RESPONSE_TOKENS = {
    "token", "accessToken", "access_token",
    "refreshToken", "refresh_token",
    "sessionId", "session_id",
    "userId", "user_id",
}

Phase 4: Build Test Vectors

For EACH signing request found, extract a test vector:

TEST VECTOR — POST /api/user/login
================================
Input (request body, excluding signature fields):
  {
    "username": "testuser123",
    "password": "encryptedXXX",
    "deviceId": "abc123"
  }

Crypto fields sent:
  random:    "a7f3b2c1d4e5f6a7b8c9d0e1f2a3b4c5"
  timestamp: 1748123456
  signature: "A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6"

Auth headers:
  X-Token: (none at login)

Response tokens:
  token:   "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
  userId:  12345
  expires: 86400

Save all test vectors to: output/[domain]/har/test-vectors.json

These vectors are used directly by crypto-recon-debugging for verification.

Phase 5: Build Request Catalog

Create a complete API map from the HAR:

# API Catalog — [domain]
Source: [harfile].har
Captured: [N] requests, [N] unique endpoints

## Endpoints Found

### POST /api/user/login
- Auth required: No
- Signing: Yes (signature + random + timestamp in body)
- Crypto fields: signature (32-char MD5), random (UUID hex), timestamp (unix seconds)
- Response: token, userId, expires

### POST /api/user/register
- Auth required: No
- Signing: Yes
- Extra fields: username, password (encrypted?), phone, referralCode
- Response: userId, token

### POST /api/game/bet
- Auth required: Yes (X-Token header)
- Signing: Yes
- Extra fields: gameId, betAmount, betType, period
- Response: betId, result

### GET /api/user/info
- Auth required: Yes (Authorization: Bearer)
- Signing: Yes (signature in query params)
- Response: userId, balance, level

## Token Flow
1. POST /api/user/login → get token
2. All subsequent requests: X-Token: {token}
3. Token refresh: POST /api/token/refresh with refreshToken

## Signature Pattern (observed from real traffic)
Fields in signature: random, timestamp, username, gameId (NOT: signature, token)
Format: MD5 of JSON.stringify(sorted_fields) → uppercase → 32 chars

Save to: output/[domain]/har/api-catalog.md

Phase 6: Handoff to Building

After HAR analysis, automatically offer to invoke crypto-recon-building:

HAR Analysis Complete
=====================
File:       [domain].har
Requests:   47 total, 18 API calls
Endpoints:  8 unique

Signing found in: 6 endpoints
Auth flow:  Login → token → all requests

Test vectors saved: output/[domain]/har/test-vectors.json
API catalog saved:  output/[domain]/har/api-catalog.md

Ready to build. This HAR gives us:
  ✓ Real endpoint URLs (no guessing)
  ✓ Exact field names in requests
  ✓ Known-good signatures for testing
  ✓ Full auth token flow

Invoke crypto-recon-building now with this HAR data?

If user says yes → invoke crypto-recon-building, passing:

• har/api-catalog.md as the endpoint source
• har/test-vectors.json as verification reference
• Reconstructed crypto functions from final/reconstruct_*.py

Integration Points

With crypto-recon-debugging

HAR test vectors become the "ground truth" reference:

From HAR: input={...} → expected_signature="A1B2C3..."
Test our function: generate_sign_params(input) → got="A1B2C3..."
Match: YES → crypto correct

With crypto-recon-building

HAR catalog replaces ALL placeholder URLs and field names:

# Before HAR: guessing
def api_login(session, username, password):
    url = BASE_URL + "/api/user/login"  # ← guessed
    payload = {"username": username, "password": password}  # ← guessed fields

# After HAR: exact
def api_login(session, username, password):
    url = BASE_URL + "/api/user/login"  # ← confirmed from HAR
    payload = {
        "username": username,           # ← from HAR
        "password": encrypt_password(password),  # ← confirmed encrypted
        "deviceId": get_device_id(),    # ← from HAR, was missing before!
    }

With crypto-recon-orchestrator

If user provides HAR alongside URL analysis:

• HAR provides endpoint list → focus JS analysis on those endpoints' signing logic
• HAR provides real signatures → immediate test vector for verification

Output Files

output/[domain]/har/
├── api-catalog.md          ← all endpoints, auth flow, patterns
├── test-vectors.json       ← input→output pairs for each signing request
├── raw-requests.json       ← full parsed requests (for reference)
└── tokens-found.json       ← all tokens/keys found in responses