Client_id failing to generate

[spookyahell]

Related to #1 in the way that it's the same kind of issue, both client id and private key not being stored.
OEM version: 16

I added a few constants to OEM_CRYPTO_API because it was complaining they were unreferenced.
'jkcwonus', 'aetaggoc', 'phodrrtx',

Here are some more details:

2024-09-23 02:38:29 [I] Core: SDK API: 30
2024-09-23 02:38:29 [I] Core: ABI CPU: armeabi-v7a

The verbose output seems to suggest the jkcwonus is the important one needed.

2024-09-23 02:26:53 [D] Script: [*] LoadDeviceRSAKey: jkcwonus
2024-09-23 02:26:53 [D] Cdm: Receive private key:

often times it won't even perform getDeviceID...

2024-09-23 02:28:19 [D] Script: [-] onLeave: GetDeviceID
2024-09-23 02:28:19 [D] Cdm: Failed to set client ID: Error parsing message

And of course the fact that Widevine process has changed happens, almost every time removes the hooking.

And then sometimes it also will throw

2024-09-23 02:42:42 [W] Core: Library not found: libwvdrmengine.so
2024-09-23 02:42:42 [E] Core: unable to find process with pid 1318

[hyugogirubato]

When using KeyDive, it is not actually necessary to manually add constants for known functions. You will just receive a message suggesting that it would be good to report them to the developer so they can be added later to speed up the process. This is not a blocking issue.

Regarding the GetDeviceID parsing error, this is a known issue that I currently cannot debug because I don’t have the necessary hardware to reproduce the bug. However, in your case, this is not really the source of your error.

Messages stating that the script can't find .so libraries are not very important at this stage; they are mainly to give a status of what the script is checking (e.g., liboemcrypto.so).

The Widevine process changing is "sometimes" normal behavior when using the script, especially when the liboemcrypto.so library is present on the device (this is intentional to disable L1).

Regarding YOUR issue, which I have encountered in very rare cases, there is a solution, but it requires an additional step. Specifically, the device_id of your device is not being retrieved/intercepted, so you will need to extract it from an unencrypted challenge.

To do this, you should follow a similar process as described for the OFFLINE mode.

1. Run the script (to trigger a clear challenge).
2. Intercept the network using HTTP Toolkit.
3. Use the DRM test APK mentioned in the documentation or available here (recommended).
4. Save the raw challenge data in a file (e.g., .dat).
5. Re-run the script, passing the challenge as an argument, so the script will automatically parse the client_id.
6. Restart a DRM process (with the APK, for example).
7. The dump should execute correctly (linking the private key to the device_id).

In summary: you need to extract the challenge via MITM and pass it as an argument to the script to resolve your issue. Errors that are not displayed as errors (other than the process change) are not blocking or important.

If you have any questions, feel free to contact me on Discord for live debugging via TeamViewer.