What's in the signedData parameter of the ILicenseResultListener.verifyLicense object?
On Google Play on Android has a service to check the license com.android.vending.licensing.ILicensingService
. It supports a callback interface ILicenseResultListener
. It has a method verifyLicense
with three parameters. For a paid app downloaded from Google Play, what's in the second signedData
, please?
And this is why I'm interested.
source to share
The answer is in android-sdk-windows \ extras \ google \ market_licensing \ library \ src \ com \ google \ android \ vending \ licensing \ ResponseData.java in the parse () method.
The signedData string is a sequence of 6 fields separated by | characters, optionally followed by a colon and a name = value association (for example, a query string). For example:
0|17|com.acme.myapp|1|AAAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHH==|1480563297411:GR=10&VT=1480570457760>=1481088857760
This comes from a paid app.
6 fields in the first section:
- Response code (int) - presumably the same as the first parameter
verifyLicense
- Nonce (int) - Comes directly from the call
checkLicense
- Package name
- Version code
- User ID with comment "Application-specific user ID"
- Timestamp (long) - not sure what. Definitely not a purchase; repeat run returns a different, later value. This is probably a license check.
The UserID appears to be Base64 encoded. Which user identifies this and how? The license holder, one of the license owners believes; but how? Decoding yields a byte array with a length of 25 bytes.
For the downloaded app, the main fields are all there is. There is additional data for the store purchased by the application. The meaning of the additional data fields can be found here . In particular, the following additional fields appear with a newly purchased app:
- GR - maximum number of attempts
- VT - time stamp of the license validity; indicates when the license needs to be rechecked
- GT - timestamp of the time period
As far as the UserID is concerned, I ran some tests. I have three cases:
- Side-loading package A
- Package A, downloaded for a fee from Play
- Package B downloaded for free from Play (by the same user)
In all three cases, the first 5 bytes of the decoded UserID match, the rest do not. Therefore, neither the unique part of the package nor the unique part of the user can be easily identified in the UserID. It is noteworthy that the remainder is 20 bytes - maybe an MD5 hash. UserID is definitely not a string in any reasonable encoding, nor does it look like a binary integer structure. Apparently the random bit pattern points to either the hash or the cyphertext. The latter is unlikely.
source to share