Hashed Key Mechanism

[MDQrx01]

Hello MakeMKV community

I used the hashed keys feature for MakeMKV for the first time last week and had some time to think about this system.

It works very well, I can't deny that, but requiring an internet connection for the tool to download / use them is a bit counterintuitive because the BD+ and or KeyDB files can be obtained and used offline without needing the tool to go online

I audited the mechanism using a web debugging proxy and I can say its safe, quite clever and does not collect identifying information about the MakeMKV installation (with the notable exception of the operating system eg Linux / Windows / macos, the processor type eg arm64 / x86_64 and the makemkv version, and I suspect it needs these informations to serve you the correct file)

For anyone interested, I can share more details upon request.

I would like to request a method for users to be able to download / import the hashed key files manually so they don't have to make the program go online itself.

I could make a tool that does this, but seeing as how it has changed over the years I would love some feedback on this first, preferably by an admin or team member

Cheers,
MD

[uhdarchive]

Interesting audit, but you’ll likely hit a wall trying to build a scraper for those keys.

There’s a specific reason MakeMKV doesn't distribute hashed keys offline like the public keydb.cfg and keeps it server-side intentionally. By making the client phone home, the server only hands over what's needed for that specific disc. It prevents dumping the entire proprietary database in one easily analyzable (and revokable) payload that AACS LA could target.

[AstralWanderer]

I would like to request a method for users to be able to download / import the hashed key files manually so they don't have to make the program go online itself.

Seconded - I use MakeMKV on an offline system so any connectivity requirement is a no-go.

There’s a specific reason MakeMKV doesn't distribute hashed keys offline ...It prevents dumping the entire proprietary database in one easily analyzable (and revokable) payload that AACS LA could target.

Hashing is supposed to be a one-way process, so it should not be possible for anyone to identify the original data. Plus those with significant resources could still collect this data either via sustained MakeMKV usage (a "rip farm"?) or by using a proxy to spoof requests.

[MDQrx01]

Interesting audit, but you’ll likely hit a wall trying to build a scraper for those keys.

There’s a specific reason MakeMKV doesn't distribute hashed keys offline like the public keydb.cfg and keeps it server-side intentionally. By making the client phone home, the server only hands over what's needed for that specific disc. It prevents dumping the entire proprietary database in one easily analyzable (and revokable) payload that AACS LA could target.

I am not so sure about that...
Here's how the mechanism works

Step 1:
It uses DoH to query a specific, known entry in DNS, mode TXT.
DoH or DNS over HTTPS is used so no ISP / government directly sees what is being looked up.
This divulges no information about the user to MakeMKV except that the query was made
It may use Google DoH, Cloudflare DoH, Quad9 DoH or a number of others

Step 2:
It decodes the answer, which seems to be an encrypted payload that only MakeMKV knows how to decode.
This is probably done to prevent ISPs from blacklisting the location where that specific
entry in DNS is stored.
It may also contain a key blacklist, expiry information and or a number of other parameters,
but first and foremost it contains the location of the hashed-key host.

Step 3:
It downloads the hashed key file from said host (not sharing the url, but its not longer the hkdata(.)whatever(.)org/com ones)
GET https://whatever-hk-host(.)com/<sdf file name>?<param>=<param>MakeMKV_<version>_<operating system>(<architecture>-release)
(No, this is not the actual url, I want to save the admins the hassle of having to replace it)
The response from the server contains a special header (metadata) which is probably used to control updates
alongside the file

Step 4:
That's it. MakeMKV uses this to create its _private_data.tar and the update settings file

Also:
When the first GET request fails, it tries to download https://whatever-hk-host(.)com/sdf.dat.gz instead.
As it stands, that file does no longer exist so this fails by default.

What this means:
Making a tool for this to work offline is not so trivial but definitely possible.
You would ideally emulate a proxy that serves the requests instead of the real server.

This works because you can replay this entire exchange, it would not work if the MakeMKV
client had to answer a question by the server in any sort of cryptographic means.

That *would* involve messing with your systems certificate trust settings so take that
with a grain of salt; you really have to trust developers of software that needs to do this
because it'd allow you to impersonate any and all web pages / services for the device.



Note:
I admit, I have not been able to test if this is really _all_ the keys it has.
Indeed, my own _private_data.tar is larger than the one it creates here, I will have to observe this
while it actually tries to use it.

And I redacted a lot of the information here, but I can assure you that it's accurate.
I would just like to _not_ step on the admins shoes so the program
can continue working like it does currently.

To any admin seeing this, I have some improvement ideas too! Contact
me and we can discuss this.

Cheers
- MD