[英]Google IAP returns short purchase token for verification
I have implemented server-side verification Google IAP purchase tokens. 我已经实施了服务器端验证Google IAP购买令牌。 My mobile app send me this token as get it from Google.
我的移动应用程序将此令牌发送给我,因为它来自Google。
A regular token looks like 常规令牌看起来像
minodojglppganfbiedlabed.AO-J1OyNtpooSraUdtKlZ_9gYs0o20ZF_0ryTNACmvaaaG5EwPX0hPruUdGbE3XejoXYCYzJA2xjjAxrDLFhmu9WC4fvTDNL-RDXCWjlHKpzLOigxCr1QhScXR8uXtX8R94iV6MmMHqD
but sometimes I get a short token like this 但有时我会得到一个像这样的短标记
korpimulxmslxissnschtkdb
When I verify this token via Google Play Developer API: https://www.googleapis.com/androidpublisher/v2/applications/packageName/purchases/subscriptions/subscriptionId/tokens/token , for the short token I get a 404 error. 当我通过Google Play Developer API验证此令牌时: https : //www.googleapis.com/androidpublisher/v2/applications/packageName/purchases/subscriptions/subscriptionId/tokens/token ,对于短令牌,我收到404错误。
Where is the problem? 问题出在哪儿? Is it possible that this short token represents real transactions?
这个短令牌可能代表真实交易吗?
I have been receiving these same invalid tokens in our app with no idea of the reason for a while. 我一直在我们的应用程序中收到这些相同的无效令牌,不知道原因有一段时间。 The tokens have come in various formats, including 24 alpha characters (eg.
glvnqnpjqslcagyimgxeuybk
), 15 digits (eg. 781871156762279
, see this question ), and even tokens of proper length that have a slightly different format from valid ones (eg. xdavcuvdnniwwrhwemleqjdz.rSQozm...
see this question ). 令牌有各种格式,包括24个字母字符(例如
glvnqnpjqslcagyimgxeuybk
),15位数字(例如781871156762279
, 请参阅此问题 ),甚至是适当长度的标记,其格式与有效格式略有不同(例如xdavcuvdnniwwrhwemleqjdz.rSQozm...
看到这个问题 )。
These are the error messages I have received from the in-app billing API for these various tokens at one time or another: 以下是我从应用内结算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."
The answer given by Marc Greenstock gave me an idea to try to reproduce the issue. Marc Greenstock给出的答案给了我一个尝试重现这个问题的想法。
I tested two apps that claim to hack in-app purchases: Freedom , and Lucky Patcher , on a rooted device. 我测试了两个声称在应用程序内购买的应用程序: Freedom和Lucky Patcher ,在root设备上。 The former did not work: though it detected that our app can make purchases, when I tried to make a fake one it told me that "this app's purchases cannot be faked".
前者不起作用:虽然它发现我们的应用程序可以购买,当我试图制作一个假的时,它告诉我“这个应用程序的购买不能伪造”。 The latter one did work after some fiddling, however, and generated a short purchase token exactly as in the question.
然而,后者在一些摆弄之后确实起作用,并且产生了与问题完全相同的短购买令牌。 When I tried to verify the token via the in-app billing API , I received the same exact "invalid token" message as before.
当我尝试通过应用内结算API验证令牌时,我收到了与以前完全相同的“无效令牌”消息。
I also started logging the root status of devices generating invalid tokens using this method . 我还开始使用此方法记录生成无效令牌的设备的根状态。 While this is not proof of anything, the fact that nearly all invalid tokens originated from rooted devices made me suspect foul play.
虽然这不是任何事情的证据,但几乎所有无效令牌都来自有根设备的事实让我怀疑犯规。
I believe the attack works as follows. 我相信攻击的工作原理如下。 Anyone who knows more about this please chime in!
任何了解此事的人都请加入!
Intent
which is meant for the legitimate service Intent
,该意图用于合法服务 Did you end up solving this? 你最终解决了这个问题吗?
The only reason I can suggest is that the token was generated by an In-app Purchase Cracker like the "Freedom in-app purchases for Android" app that can be installed on rooted devices. 我可以建议的唯一原因是令牌是由应用内购买破解程序生成的,例如可以安装在有根设备上的“自由应用内购买Android”应用程序。
I'm interested to see if you have received a short token for any test purchases that you have made yourself. 我很想知道您是否收到了自己进行的任何测试购买的简短令牌。
Another indication that the token is fake is format of the orderId that you get after purchase on the app. 令牌是假的另一个指示是您在应用程序上购买后获得的orderId的格式。
If it doesn't follow the format indicated in the Administering In-app Billing docs then it's most likely a fraudulent purchase. 如果它不遵循管理应用内结算文档中指示的格式,则很可能是欺诈性购买。
I've found a partial mitigation that works works with some fake IAP providers: recheck the digital signature manually. 我发现部分缓解适用于一些假的IAP提供商: 手动重新检查数字签名。 Whatever the IAP simulator does, they don't have a copy of Google's private RSA key.
无论IAP模拟器做什么,他们都没有Google私有RSA密钥的副本。 I've rolled my own signature check, and it catches at least some of those fake transactions.
我推出了自己的签名支票,它至少捕获了一些假交易。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.