cer*_*kjn 32 android in-app-purchase in-app-billing google-play
我已经实施了服务器端验证Google IAP购买令牌.我的移动应用程序将此令牌发送给我,因为它来自Google.
常规令牌看起来像
minodojglppganfbiedlabed.AO-J1OyNtpooSraUdtKlZ_9gYs0o20ZF_0ryTNACmvaaaG5EwPX0hPruUdGbE3XejoXYCYzJA2xjjAxrDLFhmu9WC4fvTDNL-RDXCWjlHKpzLOigxCr1QhScXR8uXtX8R94iV6MmMHqD
但有时我会得到一个像这样的短标记
korpimulxmslxissnschtkdb
当我通过Google Play Developer API验证此令牌时:https://www.googleapis.com/androidpublisher/v2/applications/packageName/purchases/subscriptions/subscriptionId/tokens/token,对于短令牌,我收到404错误.
问题出在哪儿?这个短令牌可能代表真实交易吗?
sav*_*nto 43
我一直在我们的应用程序中收到这些相同的无效令牌,不知道原因有一段时间.令牌有各种格式,包括24个字母字符(例如glvnqnpjqslcagyimgxeuybk),15个数字(例如781871156762279,看到这个问题),甚至是适当长度的标记,其格式与有效格式略有不同(例如,xdavcuvdnniwwrhwemleqjdz.rSQozm... 请参阅此问题) .
以下是我从应用内结算API收到的针对这些不同令牌的错误消息:
"code": 404, "message": "The purchase token was not found.""code": 400, "message": "Invalid Value""code": 400, "message": "Your request is invalid for this subscription purchase."Marc Greenstock给出的答案给了我一个想法,试图重现这个问题.
我测试了两个声称在应用程序内购买的应用程序:Freedom和Lucky Patcher,在root设备上.前者不起作用:虽然它发现我们的应用程序可以购买,当我试图制作一个假的时,它告诉我"这个应用程序的购买不能伪造".然而,后者在一些摆弄之后确实起作用,并且产生了与问题完全相同的短购买令牌.当我尝试通过应用内结算API验证令牌时,我收到了与以前完全相同的"无效令牌"消息.
我还开始使用此方法记录生成无效令牌的设备的根状态.虽然这不是任何事情的证据,但几乎所有无效令牌都来自有根设备的事实让我怀疑犯规.
我相信攻击的工作原理如下.任何了解此事的人都请加入!
Intent| 归档时间: |
|
| 查看次数: |
8862 次 |
| 最近记录: |