AESObfuscator实用性探讨：其对Shared Prefs的防护是否仅提升攻击门槛？
Great question—you’ve nailed the core tradeoff with client-side obfuscation tools like AESObfuscator for Android’s LVL (Licensing Verification Library). Let’s break this down clearly:
What AESObfuscator Actually Does
First, let’s confirm your understanding: it’s designed to scramble the SharedPreferences entries that LVL uses to store licensing state (last response, retry timestamps, etc.). Its primary purpose is not to provide unbreakable security—it’s a deterrent for casual threats.
Why Your Observations Are Spot-On
You’re 100% correct about its weaknesses:
- Hardcoded salt/device ID: Since these values live in the app’s dex file, anyone with basic reverse engineering skills (using tools like dex2jar or jadx) can pull them out easily. There’s no way to hide client-side secrets permanently.
- Rooted device access: A rooted user has full read/write access to the device’s storage, including SharedPreferences files. Even if the data is obfuscated, once they have the salt/device ID, decrypting the content is trivial.
Its Real Value: Raising the Attack Bar
So does it serve any purpose? Absolutely—just not as a "substantial security safeguard" (to use your phrasing):
- Blocks non-technical users: Most casual users won’t know how to decompile an app or decrypt obfuscated data. AESObfuscator stops them from manually editing SharedPreferences to bypass licensing checks (like extending retry windows or faking a valid license).
- Frustrates automated tools: Many bulk-cracking scripts rely on reading plaintext SharedPreferences. Obfuscation forces these tools to add an extra decryption step, which not all maintainers will bother implementing.
- Checks Google’s best practice box: Google recommends using AESObfuscator with LVL as a basic hygiene measure. It’s better than storing licensing data in plaintext, even if it’s not unbreakable.
What It Can’t Do
Make no mistake: AESObfuscator does not provide meaningful protection against determined attackers. A skilled reverse engineer will bypass it in minutes. For real security, you need to combine it with other measures:
- Server-side validation: Move critical licensing logic to your backend, so the client only sends device identifiers and receives a yes/no response. This makes client-side tampering irrelevant.
- Code obfuscation: Use tools like R8 or ProGuard to make reverse engineering the app’s logic harder (though not impossible).
- Root detection: Implement checks for rooted environments and restrict functionality if detected (again, this can be bypassed, but adds another layer of friction).
Final Takeaway
AESObfuscator’s role is exactly what you suspected: it’s an attack threshold raiser, not a silver bullet. It filters out the vast majority of low-effort attacks, but won’t stop a motivated hacker. Think of it like a deadbolt on a front door—it keeps out most people, but a determined thief with tools will get in eventually.
内容的提问来源于stack exchange，提问作者Russ Wheeler
