Android应用安全咨询：防IMEI篡改刷取免费积分方案

这种靠Root设备篡改IMEI刷免费积分的情况确实挺头疼的，结合Android生态的现状（确实没有绝对唯一的设备标识），给你整理几个从设备识别、风控到后端加固的可行方案，组合起来用能大幅提高攻击者的成本：

一、多维度设备特征组合，放弃单一IMEI依赖 #

不要把鸡蛋放在一个篮子里，组合多个难篡改的设备特征生成唯一标识，同时处理好权限问题（Android 10+对IMEI这类敏感权限限制很严）：

• 组合以下特征：
  • 安卓ID（Settings.Secure.ANDROID_ID）：重置系统会变，但搭配其他特征能提升唯一性
  • 设备硬件指纹（Build.FINGERPRINT）：包含设备型号、系统版本、厂商签名等信息，篡改难度极高
  • 序列号（Build.SERIAL）：部分设备可用，注意Android 8.0+需要READ_PHONE_STATE权限，部分厂商可能返回固定值，需做兼容
  • 应用私有存储的自定义UUID：首次启动生成并存在getFilesDir()下，Root用户可能删除，但结合后端备份能找回
• 生成唯一标识：把这些特征拼接后用SHA-256哈希算法生成固定长度的标识，后端只存这个哈希值，避免单个特征被篡改后绕过校验

二、Root检测+高风险设备拦截 #

先把明显的Root设备拦在门外，或者限制其权限：

• 基础Root检测：
  • 检查/system/bin/su、/system/xbin/su这类常见Root文件是否存在
  • 尝试执行su命令并捕获异常，判断是否能获取Root权限
  • 检查应用是否被安装在外部存储（Root用户常通过挂载篡改应用文件）
• 增强型风控：用Google Play Protect的SafetyNet Attestation API，它能检测设备是否Root、是否刷了自定义ROM、是否被篡改过系统，后端验证返回的校验结果，高风险设备直接限制积分领取权限（注意这个API需要联网，部分地区可能需要做兼容）

三、账号+行为维度的风控加固 #

从用户和行为入手，增加刷号的成本：

• 手机号绑定强化：
  • 每个手机号必须接收验证码验证，且30天内最多绑定2-3台设备，超过触发人工审核
  • 同一手机号短时间内频繁更换设备绑定？直接拦截积分发放
• 行为模式分析：
  • 后端记录每个用户的领取时间、设备标识、IP地址，建立简单的风控规则：比如同一IP1小时内有5台以上设备领积分、设备更换频率每周超过2次、凌晨批量领取，这些情况直接标记为风险账号，暂停发放
• 可选实名认证：要求用户完成身份证+人脸验证，毕竟实名信息没法批量伪造，能大幅降低刷号动机

四、后端逻辑锁死漏洞 #

前端再怎么防，后端的校验才是最后一道防线：

• 请求签名校验：应用和后端交互时，用HMAC算法对请求参数+密钥生成签名，后端验证签名一致性，篡改参数的请求直接拒绝
• 积分发放幂等性：后端给每个账号+月份做唯一标记，不管收到多少次领取请求，每月只发一次积分，避免重复领取
• 设备变更预警：同一手机号对应的设备标识变更时，强制要求再次验证手机号验证码，验证通过才允许继续领积分

五、替代IMEI的更可靠标识方案 #

如果不想碰敏感权限，可以试试这些方案：

• Firebase安装ID（FID）：每个应用安装实例对应唯一ID，卸载重装会变，但正常用户同一设备同一应用的ID稳定，结合账号体系能识别同一用户的不同安装实例，Root用户要篡改得卸载重装，结合手机号绑定的话成本很高
• 后端持久化标识：首次启动生成UUID，存在本地私有目录的同时备份到后端，下次启动如果本地标识丢失，从后端同步回来，避免Root用户删除本地文件后绕过校验

最后说句实在的，没有绝对完美的防篡改方案，最好是多种方案组合使用，而且要定期更新风控规则，跟上攻击者的新手段。

内容的提问来源于stack exchange，提问作者Amira Elsayed Ismail