... this shiny new function is apparently only ever used to encrypt the S/N and IMEI values from above, using the random string from step 3 as a key. which then, of course, is sent in the same request as the encrypted value?? they're essentially sending key || AES-GCM(SHA256(key), data), which is a cool way to spend ~76 bytes doing a cryptographic NOP

a similar thing applies to the ECDSA signatures: yes, they're proving ownership of the public key by including a signature over some values, but from what i can tell, this key is never used again?

we're generating expensive elliptic curve points, enrolling them into the AndroidKeyStore, serializing the public key into base64, generating a signature to prove to the server that we control the private key — and then we just pour it all down the drain?

to be clear: i don't think this is exploitable, which is why i'm talking about it here. simplifying these NOPs still yields a secure-ish looking protocol. but still 😳
9/x