Can a Real Device L3 CDM Crack VdoCipher DRM? Seeking Advice

[iamstupidbastardok_]

Hello everyone!

First of all, I want to thank this forum because I've been researching a lot about DRM, CDM, and related technologies, and this is the only place where I've found useful information on these topics.

I’ve been working on a Proof of Concept (POC) using the DRM service from Bitmovin (you can check it out here: https://bitmovin.com/demos/drm/), and I was able to easily extract the encryption keys using an L3 CDM I found here in the forum. This CDM comes from an Android phone emulated in Android Studio, and I used it with this DRM service.

Thanks to this repository and wiki from FoxRefire (https://github.com/FoxRefire/wvg), I was able to understand a lot of the details of the process. I want to give proper credit because it helped me a lot in understanding the differences between AVD (Android Virtual Device) CDMs and physical device CDMs. I’ve also read in the forum that some license servers like VdoCipher or Amazon block access to AVDs, so you have to use a physical device for the CDM to work properly on those services.

---

My Question:

Here’s the question I’d like to ask, and I would really appreciate any guidance or advice:

If I manage to dump the CDM from a real physical device, will it work for a website using a DRM service like VdoCipher?

To provide some context, the L1 CDM runs in the processor’s (at the hardware level), which makes it extremely secure. While in the past some people were able to obtain the CDM through processor exploits, nowadays the only CDMs that can be dumped are L3 CDMs from physical devices (as mentioned in the forum).

My specific question is whether the L3 CDM from a real physical device would be accepted by VdoCipher, as my goal is to use this CDM for the decryption process on DRM-enabled websites that use it.

---

What I've done so far:

To help better understand what I’ve achieved so far, I’ll share a video of how I’ve interpreted the entire process. In the video, I use the most powerful tool I’ve found to interact with the MPD, download all the video, audio, and subtitle segments, decrypt them one by one, and then merge everything using FFmpeg.

I’ll attach the video of the entire process for you to see how I’ve done it. I’d appreciate it if you could tell me whether my logic is correct and if the process I’m following is the right one.

---

About my experience with the paid extension and closed-source code:

I also want to mention that I’ve been recommended a paid extension from a guy named Zane Wasley, but honestly, I would never pay for a closed-source extension, nor would I use an external CDM. I prefer to support open-source projects like [WidevineProxy2](https://github.com/DevLARLEY/WidevineProxy2), which are developed by people in the community like DevLARLEY (he’s a genius!). I also support open-source initiatives like Shakapackager, FFmpeg, m4decrypt, and other open-source projects that benefit us all.

---

To summarize:

- My main question: If I make the effort to dump an L3 CDM from a real device, will it be accepted by VdoCipher to decrypt content on their platform?
- I’m attaching the video so you can see if my process is correct.
- I would never pay for a closed-source extension, and I prefer to support open-source projects that help everyone.

---

Additional request:

If anyone has a real L3 CDM in their possession, please reach out to me via private message. I’d like to send you the link to the website where I want to test it, and it would be great if you could let me know if you're able to extract the keys using the sample video that’s already available. The process is essentially the same, but it’s done in a way that I can understand, which is why I’m asking for an explanation of the process that aligns with how I’m using it in the video.

Thanks everyone!

[larley]

VdoCipher is probably the worst service you could deal with because they're a license service provider, meaning that they run their own license servers and therefore have the ability to block access of specifc devices (aka. "revoke") to their servers. They're pretty paranoid about their security and just sending a single malformed request could lead to you losing access to their servers for at least 5 days.
I suggest you firstly try to use WidevineProxy2 so you can be sure that in the case of an unsuccessful license acquisition your device is the problem and not the script.
With that being said, there's still a small chance your device won't work, because VdoCipher doesn't accept 100% of devices due to their way of figuring out whether a device is actually "physical" (there isn't an official way like some flag in the client id, but I remember other people suspecting that they might be using the build_info key in the client_info field).
There've also been additional reports that there are multiple security stages that require additional information in the request (the video will fail with "Please open in android app": https://forum.videohelp.com/threads/416316-%5BRelease%5D-WidevineProxy2-Extension-Bypa...e2#post2755354).

[iamstupidbastardok_]

VdoCipher is probably the worst service you could deal with because they're a license service provider, meaning that they run their own license servers and therefore have the ability to block access of specifc devices (aka. "revoke") to their servers. They're pretty paranoid about their security and just sending a single malformed request could lead to you losing access to their servers for at least 5 days.
I suggest you firstly try to use WidevineProxy2 so you can be sure that in the case of an unsuccessful license acquisition your device is the problem and not the script.
With that being said, there's still a small chance your device won't work, because VdoCipher doesn't accept 100% of devices due to their way of figuring out whether a device is actually "physical" (there isn't an official way like some flag in the client id, but I remember other people suspecting that they might be using the build_info key in the client_info field).
There've also been additional reports that there are multiple security stages that require additional information in the request (the video will fail with "Please open in android app": https://forum.videohelp.com/threads/416316-%5BRelease%5D-WidevineProxy2-Extension-Bypa...e2#post2755354).

Hi Larley,

I'm glad you replied, as I was hoping to get in touch with you to see if we can collaborate on this VdoCipher issue. So far, I’ve managed to obtain three different CDMs, but I’m encountering the following errors:

1. Domain not allowed
2. Device not authorized
3. Please open in Android app

It would be incredibly helpful to understand what each of these messages means and why they occur. I’ve reviewed the VdoCipher documentation, but I still don’t have a clear understanding of the reasons behind these errors.

I have the CDMs if you’d like me to share them with you. We could discuss this further on Telegram or any other platform you prefer, or I can send you the CDMs via private message so you can work with them directly.

Here’s what I plan to do on my end:

1. Set up a proxy using BurpSuite to analyze all the requests made by the VdoCipher page when it loads.
2. Identify the key requests, headers, how the token is obtained, and how the data is encoded.
3. Using this information, I’ll build a Python client with Selenium and set up a proxy using the mitm library in Python to capture and modify the requests. My goal is to replace the binary data, such as the challenge, with my own fake CDM.

If none of this works, something critical must be missing, as it seems unlikely that the real device CDMs wouldn’t be accepted. We’re likely overlooking something important.

On your side, your extension is amazing—I assume it also acts as a proxy and modifies the requests using the CDM provided to it. However, it seems there’s still something missing when it comes to VdoCipher.

I hope we can collaborate and work together on this issue.

---

Additional Concerns Regarding WidevineProxy2 and VdoCipher

I understand the reasoning behind using WidevineProxy2 first to determine if the issue is with the device rather than the script itself. However, I have some additional questions:

1. Why use WidevineProxy2 at all for VdoCipher if it doesn't guarantee key extraction?

Even when using a real, genuine CDM, WidevineProxy2 may still fail to retrieve decryption keys. If that's the case, what additional insight does it provide for VdoCipher specifically?

2. What does WidevineProxy2 offer that makes it a necessary first step?

If WidevineProxy2 fails, does it conclusively mean that the device is the issue, or could it also indicate additional server-side security mechanisms blocking the request?

What unique advantage does it bring before moving to a custom script?

3. How can we determine when a CDM is not valid using WidevineProxy2?

What specific error message or response should we look for when using WidevineProxy2 to confirm that a CDM is not accepted by VdoCipher?

Are there cases where the extension fails but the CDM is actually valid?

4. Why does using WidevineProxy2 prevent bans?

Since VdoCipher is known to ban devices for malformed requests, does WidevineProxy2 have any built-in protection against triggering these bans?

Is it safer to use it compared to testing with a custom script from the start?

Given VdoCipher’s strict security measures, I’d like to understand whether WidevineProxy2 is a reliable first step or just a general test with limited relevance for troubleshooting VdoCipher specifically.

[larley]

WidevineProxy2 modifies the challenge right after leaving EME, which means that any additional security mechanisms (for example an HMAC signature) will use the challenge generated by WidevineProxy2. When I said that license acquisition might still fail, I just meant that VdoCipher's license servers might not accept any CDM from an actual physical device as their version of "physical".
In case of a license request being unsuccessful, the CDM will always be the problem, whether it's because of an insufficient security level, wrong device type (Android/Chrome) or the device not being "physical". All of this is evaluated server-side.
Websites might or might not display an error, it really depends. VdoCipher will show "Error 2104: Device not supported" when you try to use an "emulated" device.
I'm not sure what all of the malformed requests are that will get your device blacklisted, but I do know that you definitely can't send such requests with WidevineProxy2. Using a custom script is much riskier, but can still work just as well. You just have to know what you're doing - one wrong request and there goes your CDM.
It should be completely fine to use WidevineProxy2 as the first step to see whether your device gets accepted.