Hey there, let's break down how to fix your app security and service protection problems step by step. You've already dealt with the frustration of cracked apps stealing your WebService credentials, so we need layered defenses here—combining app hardening on both platforms and strict service-side checks to block unauthorized access.

For Android #

• Code Obfuscation: Use R8 (the successor to ProGuard) to rename classes, methods, and variables to meaningless names. This makes reverse-engineering the APK way harder. Just make sure to keep any necessary native methods or SOAP service-related classes from being obfuscated by adding rules to your proguard-rules.pro file.
• DEX Encryption: Go beyond basic obfuscation with DEX encryption tools (commercial options like Tencent Legu or 360 Guard work, or you can build a custom solution). This encrypts your app's DEX files, so even if someone extracts the APK, they can't directly read the code without the decryption key (stored securely and only loaded at runtime).
• Anti-Debugging & Anti-Root Checks: Add checks to detect debug environments or rooted devices:
  • Call ptrace(PTRACE_TRACEME, 0, 0, 0)—if it returns an error, a debugger might be attached.
  • Scan for root-related files like /system/app/Superuser.apk or check if the app can write to restricted system directories.
• Secure Storage of Sensitive Data: Never hardcode WebService URLs, usernames, or secrets. Instead, store them in encrypted SharedPreferences or use Android Keystore to encrypt these values. You can even generate parts of the URL dynamically at runtime to avoid static detection.

For iOS #

• Code Obfuscation: Use tools like Obfuscator-LLVM to rename symbols and scramble your code. Apple's App Store does automatic obfuscation, but adding your own layer makes reverse-engineering (via tools like Hopper or IDA Pro) far more tedious.
• Anti-Debugging & Jailbreak Detection: Implement checks to block debugging and jailbroken devices:
  • Use ptrace(PT_DENY_ATTACH, 0, 0, 0)—if it fails, the app is being debugged.
  • Check for jailbreak indicators like the presence of Cydia, write access to restricted directories, or the ability to execute unsigned code.
• Secure Key Storage: Use the Keychain Services API to store sensitive credentials or keys. The Keychain is encrypted and tied to your app's bundle ID, so even on a jailbroken device, accessing these values is significantly harder than reading hardcoded strings.
• Leverage Apple's Built-in Security: Enable App Transport Security (ATS) to force all network traffic over HTTPS, and use FairPlay for content protection if you have sensitive assets. Never store sensitive data in UserDefaults—always use the Keychain instead.

Your previous static encrypted credentials failed because attackers could extract them via decompilation. Bearer tokens with embedded credentials also carry risk, so we need dynamic, context-aware authentication:

• Dynamic Temporary Token Authentication:

  • Replace static credentials with a two-step process:
    1. When your official app starts, it sends a request to a dedicated token endpoint, including proof of the app's legitimacy (detailed below).
    2. The server validates the request and issues a short-lived (e.g., 15-minute) Bearer token, tied to a specific device/app fingerprint. Use this token for all subsequent WebService calls.
  • Short expiration times limit damage if a token ever leaks.

• App Identity Verification:

  • For Android: Verify the app's package name and signature hash. When requesting a token, the app sends its package name and SHA-256 hash of its signing certificate. The server checks these against your pre-registered official values—reject mismatches.
  • For iOS: Verify the app's Bundle ID and team ID from its signing certificate. Use Apple's App Attest service to cryptographically prove the app is genuine and untampered.

• Request Signing & Anti-Replay Protection:

  • Add a signature to every WebService request. Your app and server share a secret key (never hardcode this—fetch it dynamically after initial authentication and store it in Keychain/Android Keystore).
  • For each request, the app generates a timestamp, random nonce, and signs these plus request parameters with the shared key. The server validates the signature, checks the timestamp is within a 5-minute window, and ensures the nonce hasn't been used before to block replay attacks.

• Mutual TLS (mTLS):

  • Implement mutual TLS for your WebService. Require your official app to present a client certificate when connecting. The server only accepts connections from apps with valid, pre-approved certificates—even if attackers steal a token, they won't have the certificate to make valid requests.

• Behavioral Analysis & Rate Limiting:

  • Monitor request patterns. Flag and block requests from unknown device fingerprints, unusual frequency (e.g., 100 requests/minute from one IP), or invalid parameters.
  • Add rate limiting per token/device to prevent brute-force attacks or scraping.

Security is a layered game—don't rely on just one measure. Combine app hardening to make cracking harder, and service-side checks to ensure only your official app can access your WebService. Even if attackers bypass one layer, the others will block them.

内容的提问来源于stack exchange，提问作者Kuroiteiken