Astonishingly, the private keys were 4, 56, 66, 115, 155, 156, 230, 237.
exploiting compromised certificates requires an active adversary-in-the-middle attack, meaning the attacker must act as a proxy between two TLS parties and receive encrypted traffic, decrypt it, reencrypt it, and send it to the other party. Such capabilities, in some cases, are usually limited to only the most well-resourced attackers. People with control of a local network—at a coffee shop, university, or other organization—face much less of a challenge.
https://emudhra.we-have-a-problem.com/
Can I use this to MITM the connection of a proprietary Android app that only runs on a device with Google Play Protect (a form of remote attestation)? And then reverse engineer the API?
Assuming that the device hasn't been updated yet, yeah, this is what it allows you to do.
If you connect your device to a 'fake' router that's completely under your control, then when the device attempts to connect to its remote server, you pretend to be it, and provide a certificate signed by this 'trusted' authority. Device will accept it. Make another connection to the real remote server. Decrypt what the device sends you, and send it on to the remote server; it'll believe that you're the android device, and respond with a message that you can decrypt, store, reencrypt with your fake key, and send it to the device. Repeat.
You'll only be able to impersonate the API until the keys are revoked by an update. That's maybe not so useful. However, any other connection that can be MITM'd and include other personal information - your bank card details, say - can be read, too.
Depends. If the app uses cert pinning it will only trust the cert baked into it.