As mentioned in it, this is StreamFab's underlying ChromeCDM API and cached keys API, which was used in their software before version 6.1.8.1. Similar leaks occurred previously. For example, see: GitHub - Owner03/Streamfab-DVDFab-Chrome-API. Around September 2022, StreamFab started encrypting the responses of their API.
There are two parts to the API:
1. ChromeCDM API
- - This is the API StreamFab uses for extracting content keys for new or previously not downloaded content. After content is downloaded once, they cache (save) the corresponding content keys on their server.
2. Cached keys API
- - This is the API StreamFab uses for retrieving the keys of already cached content when users need to download content that was previously downloaded by another user.
Most people went after StreamFab's ChromeCDM API since 2022. Initially, they did not bother decrypting the API responses when it was first implemented because StreamFab accidentally leaked the entire ChromeCDM they were using due to a lack of heir server side security. See: . It took StreamFab months to notice and close this leak, despite many users informing them via email and support.
After noticing this and the previous API leak, StreamFab began encrypting API responses as I mentioned before. Since people already had the ChromeCDM from the above server side files leak, people did not bother decrypting the responses until the 2022 December 10 revocation happened. Just two days after StreamFab added the ChromeCDM version which they newly cracked at that time to their API and resolved the DRM issue, people became interested and managed to decrypt the API responses, gaining access to ChromeCDM version 4.10.2557.0 via StreamFab's API.
Using the term "access" is somewhat misleading, as people heavily abused StreamFab's API until January 25, 2024. StreamFab did not change their encryption from 2022 until the recent January 25th revocation. The FabModKey.exe included in the API leak mentioned by 1binary0 was shared privately among many people. At least 1,000 people were using StreamFab's API, directly or indirectly and they were milking the ChromeCDM.
People used it in extensions, automated scripts, and other tools to extract content keys and download videos. Some even sold it to others for around $100. There were at least 20 different proxy/reproxy APIs of StreamFab's API created by people, which existed until January 25 of this year. I think using all of these, atleast 10 million content keys were extracted by people through StreamFab's API. That means atleast 40 million requests should have been sent to StreamFab servers by other people. (I will explain how it got multiplied by 4 later)
I am unsure if StreamFab was aware of this situation, but they did not change their encryption at all until the January 25 revocation.
However, starting from version 6.1.8.1, StreamFab changed the encryption process of the API responses after they added the ChromeCDM version 4.10.2710.0 to their API. It has only been 5 days since StreamFab introduced this, but multiple people I know have already managed to decrypt the new API responses by breaking StreamFab's newest API encryption system. They were able to reverse it in just one day.
It is only a matter of time until the fate of the previous API befalls this version too. People WILL abuse it. If someone from StreamFab is reading this, I think you need to take the security of your API more seriously, even if you care about it only slightly.
Some of my recommendations are as follows:
- The new API consists of only two requests: one for getting the license request challenge and one for getting the encrypted content key response. This change is very unwise and only makes the job of API abusers easier. The previous API consisted of four requests: one for getting the fake challenge from one endpoint, modifying the fake challenge with wv_cvt from another endpoint, modifying the license response with wv_cvt from another endpoint, and finally getting the encrypted keys response from another endpoint. In the previous API, extracting one content key required four requests and took 16 to 20 seconds. (This is why the requests for getting one key multiplied by 4) There were no bypasses or ways to speed it up, which frustrated abusers. Now, one can extract a content key in just 6 seconds, as only two requests are needed. (The uc_v2 request is not needed at all; its necessity can be easily bypassed.) In my opinion, this change does not benefit a real StreamFab user because the time to get one key is unnoticeable when using the software. However, it is noticeable when someone uses the API directly and will continue to frustrate API abusers. So, bring back the four-request method if possible. (Do not encrypt all four requests' responses because decrypting four requests client-side is unnecessary and will exhaust a normal StreamFab user's CPU. Only encrypt the last two as you did before.)
- Change the response encryption method with every update, even slightly. This is the best thing to do, as it will frustrate API abusers who will have to reverse the software each time. With VMprotect enabled, it will be hard and exhausting to do every time. Try to increase the obfuscation method more and combine AES, XOR, and other encryption methods each time. As you, StreamFab, break Google's ChromeCDM encryption each time they introduce a new version, you have to understand that people are going to break your API response encryption each time you introduce a new one. You can't stop it. However, what you can do is make it harder to crack and make it frustrating to use even if they crack it.
VeiledCipher
To add to this, another recommendation of mine is as follows:- The API does not cache a successfully extracted key itself. It relies on the client software to send the request for caching the keys after they are extracted. The abusers of the API did not send this cache keys request to the StreamFab servers after extracting the content keys using the StreamFab API. You can see this if you look at the code of the API leak which is posted above by 1binary0. So when people abuse your API, you get absolutely no benefit at all. Just the traffic on your server increases very heavily. So my recommendation is that you should cache the keys yourself from your server-side after a successful key extraction. Also, remember that it is really dangerous to cache the keys from the client side because if someone wants, they can fill your database with a bunch of wrong keys.
You have worked hard for cracking the ChromeCDM. If you even care about it at least slightly, you should stop giving the chance for the API abusers to use it this much easily. Also, as I mentioned earlier, people have already cracked the new encryption of the API and are using it freely, sharing it with many others. It won't be long until people start to abuse it just like the last version!
