I made a new feature that spoofs media DRM id

dj5

I created a custom system service that provides a single function to generate a unique media DRM ID per user per app—similar to how the Android ID functions. Here’s how it works:

The function retrieves the Android ID of the calling user and the package name.
It concatenates these two strings and computes a SHA-256 hash.
From the resulting hash, it extracts the first 32 characters.
The getPropertyByteArray function of MediaDrm is modified to call this custom function, convert the resulting string into a byte array, and return this spoofed value instead of the original one.

This approach ensures that each user/profile receives a consistent but unique media DRM ID for each app. If the Android ID or package name changes, the DRM ID updates accordingly; otherwise, it remains stable for that user/app combination.

Demo Video
I prepared a demo video to illustrate the functionality:

In the first part, you can see the Owner, Demo1, and Demo2 profiles using the pre-installed “devcheck” app, each showing a different DRM ID.
In the later parts (Demo4 and Demo5), I installed the same app from the internet to demonstrate that the modification works with both pre-installed and non-altered apps.
Finally, the video shows that after removing and reinstalling the app, the DRM ID remains consistent (as long as the Android ID and package name are unchanged), which is the expected behavior.

Tell me what you think about it in the comments.

ryrona

dj5 Tell me what you think about it in the comments.

You are leaking the user ID and package name to the remote server. I doubt the actual Media DRM functionality does that. This would mean the remote server can now detect if you are using an unofficial client app instead of the official one, and can detect which of your user profiles you are running the app in. Plain hashing is not enough to conceal this, since both user ID and package name are really low entropy, so it can be brute-force searched.

You need to add a (possibly persistent) high entropy random string too as input to the hashing to conceal this. Unless I misremember, there are specific ways to do that that are provably secure.

Joy69

This is

dj5
This is amazing. So many ppl have been trying to do this to ensure privacy and help prevent apps from tracking you. As far as I know this was the last major identifier that apps were still able to use in graphene to directly and consistently monitor users.

How exactly did you do this? Is there a guide that someone, like me, can follow to duplicate this?

dj5

ryrona
I am trying to prevent app developers from uniquely identifying users. On this website, you can see the code that retrieves the media DRM ID:
https://stackoverflow.com/questions/64509905/how-to-get-unique-id-in-android-q-that-must-be-same-while-uninstalling-and-inst
Now, when app developers attempt to uniquely identify you using this code, they will receive different IDs that vary across users.

ryrona

dj5

It sounded to me like you do:

MediaDrmID = SHA256(userid + package_name)

I was pointing out that this leaks a lot of information MediaDRM IDs usually don't. Especially if userid always is 0, 1, 2, .. and package_name is any of the known clients for that service, it would be easy for the remote end to calculate all possible hashes, and thus being able to detect userid and package_name, essentially reversing the hash.

I instead suggested you do something like this to prevent that, essentially salting the hashes:

MediaDrmID = SHA256(random_persistent_key + userid + package_name)

But I didn't know ANDROID_ID was a thing. If that one already has high enough entropy, that might be enough. Seems unclear from the documentation I found whether it even is random at all though, but I guess you know.

dj5

ryrona

I'm not sure which server you're referring to? The app developer already knows the package name because they created the app, and they also have access to a lot of information about your phone. All the details shown in the video—such as the phone model for example—are all available to any app without requiring any permissions. My focus was solely on modifying the DRM ID that remains constant, which allows any app to identify you.

ryrona

dj5 I'm not sure which server you're referring to?

MediaDRM is used to deliver encrypted video or audio data to prevent unauthorized copying or saving of that video or audio data. For example NetFlix would use it so people cannot copy their movies. My understanding is that the app that fetches the MediaDRM ID sends this to whatever server that is supposed to send video or audio data (e.g NetFlix server in my example), so that that server can attest the security level provided by the MediaDRM implementation of your device, and can learn about the encryption key to encrypt media with. This is the server I mean. Of course they cannot send any media data at all to your device if you provide a faked MediaDRM ID, but this is more to prevent other apps from abusing this MediaDRM functionality to uniquely fingerprint you. The MediaDRM ID is still sent to a server owned by that app for fingerprinting purposes in that case.

They do not need to know which user profile you are running the app in, yet, maybe you are now leaking that information to them. Likewise, if they still permit access to their service if you supply a fake MediaDRM ID, which is likely if they only use it for fingerprinting but do not verify it, you don't want to leak the package name either, since maybe you are using an unofficial client, not the official one provided by the service, and you don't want them to know about that.

That was my thinking.

hemlockiv

ryrona Of course they cannot send any media data at all to your device if you provide a faked MediaDRM ID,

Do we know this for a fact? Are MediaDRMs any 32-char numerical string, or is there an issue of only "known good" strings being accepted? (AFAIK mediaDRM strings can be blacklisted, which is the purpose for preventing copyright abuse, and I've also read elsewhere that the strings are not unique between devices; multiple devices may have the same mediaDRM, which makes me suspect there's only a subset of known good strings.)

In any case, this sort of feature seems like it would need a "whitelist mode" to give apps access to the real device mediaDRM, and/or the ability to write a custom string per app. (Realistically, the string should be generated per package signature; otherwise this is a fingerprinter in and of itself, if for example Meta notices that the Facebook, Messenger, and Instagram apps you have installed and signed-in on the same device are all sending different mediaDRMs..)

thmf

Since the thread has 'Development' tag this seems to be relevant:
https://github.com/GrapheneOS/os-issue-tracker/issues?q=is%3Aissue%20MediaDRM%20

ignoramous

Joy69 As far as I know this was the last major identifier that apps were still able to use in graphene to directly and consistently monitor users.

Not to down play the concern or anything but I feel compelled to point out that Media DRM ID seems like the "last major identifier" precisely because folks haven't bothered looking for other ways to fingerprint a device as long as this one exists.

VMs (by the way of AVF) may still offer a way out (but even then, a bunch of fingerprinting vectors may continue to exist, ie vectors outside the control of the VM): https://discuss.grapheneos.org/d/19484-unique-drm-id/10

In short, imo, identity isolation among apps / across profiles (in face of a determined adversary) while using the same device is a self-defeating proposition.

ryrona

hemlockiv Do we know this for a fact?

The remote server need a key to encrypt the DRM protected data to, and a cryptographically signed attestation of the security level for that key, ie, what hardware it is protected in and the decoding will be done by, or if software. I don't know for certain whether this is the data that is sent as part of the MediaDRM ID, or how it is coded there, but that is exactly the kind of data the remote server must be prevented from obtaining.

I suppose it is possible to generate a valid MediaDRM ID for a key protected only by software, and this would avoid any privacy concerns as can be local to every app instance and not tied to any hardware in any sense at all, while still allowing to receive streamed content. I am able to receive 720p video from NetFlix this way on a Linux installation running inside a virtual machine, and thus definitely do not have any hardware DRM support. But they refuse to send anything better than 720p at low quality unless they have a MediaDRM ID for a hardware protected key.

hemlockiv AFAIK mediaDRM strings can be blacklisted, which is the purpose for preventing copyright abuse

Yes, useful if the hardware attestation can be circumvented due to firmware bugs.

hemlockiv and I've also read elsewhere that the strings are not unique between devices; multiple devices may have the same mediaDRM, which makes me suspect there's only a subset of known good strings.

If I remember correctly, on Pixel phones, there is actually a unique MediaDRM ID per app and factory reset cycle. So the remote server should not be able to know the exact key. I know the regular attestation functionality on Pixel phones, the same primary key is provisioned to a batch of 1000 devices or so, for some anonymity. On top of that new keys can be created per app, and signed by a Google server after having provided an attestation they are protected the same as a specific primary key. I don't know if this is what is done for the MediaDRM solution too.

Actually, I don't know any technical details about the MediaDRM solution at all. Just generally how it work on a high level.

hemlockiv if for example Meta notices that the Facebook, Messenger, and Instagram apps you have installed and signed-in on the same device are all sending different mediaDRMs.

That should already be the case for real MediaDRMs IDs, that they are different per app.