Google IAP gibt ein kurzes Kauftoken zur Überprüfung zurück

Ich habe die gleichen ungültigen Token in unserer App erhalten, ohne den Grund für eine Weile zu kennen. Die Token sind in verschiedenen Formaten erhältlich, darunter 24 alphanumerische Zeichen (z. B. glvnqnpjqslcagyimgxeuybk), 15 Ziffern (z. B. 781871156762279, siehe diese Frage ) und sogar Token mit der richtigen Länge, die ein etwas anderes Format als die gültigen haben (z. B. xdavcuvdnniwwrhwemleqjdz.rSQozm...siehe diese Frage ).

Dies sind die Fehlermeldungen, die ich von der In-App-Abrechnungs-API für diese verschiedenen Token zu der einen oder anderen Zeit erhalten habe:

• "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."

Die Antwort von Marc Greenstock gab mir eine Idee, um zu versuchen, das Problem zu reproduzieren.

Betrügerische Einkäufe tätigen

Ich habe zwei Apps getestet, die behaupten, In-App-Käufe zu hacken: Freedom und Lucky Patcher , auf einem gerooteten Gerät. Ersteres hat nicht funktioniert: Obwohl festgestellt wurde, dass unsere App Einkäufe tätigen kann, wurde mir beim Versuch, eine Fälschung zu erstellen, mitgeteilt, dass "die Einkäufe dieser App nicht gefälscht werden können". Letzteres funktionierte jedoch nach einigem Hin und Her und erzeugte genau wie in der Frage einen kurzen Kauf-Token. Als ich versuchte, das Token über die In-App-Abrechnungs-API zu verifizieren, erhielt ich dieselbe exakte Meldung "Ungültiges Token" wie zuvor.

Ich habe auch damit begonnen, den Root-Status von Geräten zu protokollieren, die ungültige Token generieren, und zwar mit diese Methode . Dies ist zwar kein Beweis für irgendetwas, aber die Tatsache, dass fast alle ungültigen Token von gerooteten Geräten stammten, ließ mich verdächtigen, dass sie schlecht gespielt haben.

Der Angriff

Ich glaube, der Angriff funktioniert wie folgt. Wer mehr darüber weiß, meldet sich bitte!

• Der Benutzer installiert eine der Hacking-Apps, die angeblich kostenlose In-App-Käufe auf einem gerooteten Gerät tätigen
• Die Hacking-App patcht entweder den legitimen In-App-Abrechnungsdienst auf dem Gerät oder emuliert ihn
• Während eines Kaufvorgangs fängt die Hacking-App das Kauf Intent ab, das für den legitimen Service bestimmt ist
• Die Hacking-App verarbeitet die Kaufanfrage und generiert eine Antwort auf die gleiche Weise wie der legitime Service, aber die Kaufanfrage erreicht niemals die Google-Server
• Eine App, die sich auf die lokale Token-Validierung stützt, fordert Käufe beim In-App-Abrechnungsservice an. Diese Anfrage wird auch von der Hacking-App abgefangen, die behauptet, dass der Kauf gültig ist
• Eine App, die sich auf die Server Token-Validierung stützt, sendet das Kauf-Token an einen Server, der die In-App-Abrechnungs-API aufruft, die dies noch nie getan hat das Token gesehen und gibt daher eine "ungültige Token" -Antwort zurück

Minderung

• Apps, die sich ausschließlich auf den In-App-Abrechnungsdienst verlassen, sind anfällig ! Die Kaufbestätigungsanfragen und werden von derselben betrügerischen App abgefangen. Es gibt keine Verteidigung.
• Apps, die auf einem Server-Backend basieren, sollten das Kauf-Token an das Backend senden, um es über die Publisher-API zu überprüfen. Diese Apps dürfen den Benutzer nicht mit dem Kauf belasten , bis das Back-End dies überprüft und ein positives Ergebnis an die App zurückgibt. Das Backend sollte wahrscheinlich den Sicherheitsempfehlungen für die In-App-Abrechnung folgen. Diese Apps sind wahrscheinlich sicherer vor betrügerischen Einkäufen, obwohl sie viele ungültige Einkäufe generieren.
• Ich glaube nicht, dass es sicher ist, sich auf die Länge oder das Format des Tokens, die Bestellnummer oder andere Daten zu verlassen, um die Gültigkeit des Kaufs zu bestimmen. Diese Token sind wahrscheinlich nur fehlerhaft, weil sie ein vorheriges Format emuliert haben. Vermutlich werden die Autoren der Hacking-App irgendwann eine Version veröffentlichen, um jedes von Google gewünschte Format zu emulieren. Die einzige sichere Möglichkeit besteht darin, den Kauf über die In-App-Abrechnungs-API auf einem Gerät zu überprüfen, das Sie steuern, d. H. ein Server.