反编译及修改后的APK发起的请求是否会被Firebase App Check允许？

我来帮你拆解这两个关于Firebase App Check的问题，这其实涉及到它核心的验证逻辑：

问题1：反编译的APK发起的请求是否会被允许？ #

取决于反编译后的APK是否保留了原应用的签名信息。Firebase App Check（尤其是搭配Android的SafetyNet/App Attest时）核心校验的是应用签名的合法性——只要反编译后的APK依然使用原应用的签名密钥进行签名，那它发起的请求就能通过验证。毕竟反编译只是读取APK的内容，没有改变签名的话，App Check无法区分这是原APK还是反编译后的副本。

但如果反编译过程中丢失了原签名，或者没有用原密钥重新签名，那请求肯定会被拒绝，因为App Check后台已经绑定了原应用的签名指纹。

问题2：修改源代码后重新打包的APK能否通过验证？ #

同样分两种情况：

• 如果修改后用原应用的签名密钥重新签名：这种情况下，App Check的基础签名验证会通过。不过如果你的App Check配置了更严格的校验（比如SafetyNet的完整性验证），SafetyNet可能会检测到APK的代码被篡改，进而导致App Check拒绝请求。
• 如果修改后用新的签名密钥签名：这种情况100%会被拒绝，因为App Check后台只认可你预先配置的原应用签名指纹，新签名不在白名单内。

额外补充一句：Firebase App Check是用来提高攻击门槛的防护手段，不是绝对的安全屏障。如果攻击者获取到了原应用的签名密钥，那他们确实可以修改代码后用原签名打包，绕过基础的App Check验证——但这种情况属于密钥泄露，已经是更严重的安全问题，需要优先解决密钥的保护问题。

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