Even if you could, Google's hardware attestation API is based on checking their keys against their cloud services, and that's what banking and DRM video apps will generally be testing for going forward.
Even if you could, Google's hardware attestation API is based on checking their keys against their cloud services, and that's what banking and DRM video apps will generally be testing for going forward.
Client (validate)-> server, requires a valid signature which I cannot sign unless I have access to their private key
Client <-(SpoofedAuthSuccess) SpoofServer, is also impossible if the client requires data from a server to work properly going forward. The only thing you could attain, is to unlock the client locally if you reverse engineered it, but any data not stored locally, is impossible to get. So wrt. games, since you mentioned DRM, it might be possible to unlock the content if it is local, given a clever reverse engineering solution? Even if they encrypted the data on disk, at some point, they have to decrypt it in-memory locally.
But for server, where all validation and data is gated behind an 'authoritative' server, I guess it's just game over for unlocking anything yourself with a certificate. Even if you manage to magically solve it, they will just issue a new certificate, and quickly invalidate the old one I guess.