Log in

View Full Version : UHD BD and VUK


edo1080
30th August 2017, 08:56
PowerDVD 17 requires an internet connection anytime a new UHD BD is inserted into the player to load something from the server (While Standalone players don't).

Has anyone tried to wireshark the traffic and log it to see what is exchanged?

I have no full UHD PC setup ready yet, but I'll do it in a near future

candela
30th August 2017, 09:37
The traffic will be encrypted, multiple times, and Wireshark will show you nothing. You might be able to remove HTTPs encryption with a proxy if PowerDVD doesn't properly verify their certificates. Then you will be faced with another encryption which would require disassembly of PowerDVD. And most likely they are not sending any key that can directly be used to decrypt the disc.

Efforts are better focused on normal Bluray, growing the public key database (while it's still possible), getting a working BD+ solution in VLC (using cached tables) and updating/making tools (e.g. aacskeys). These things that are actually in reach

edo1080
30th August 2017, 10:00
OK, but the question still stands: why they do need an internet connection only the 1st time a new UHD BD is inserted?

I've succesfully decrypted https traffic with wireshark in the past, of course if that traffic is an encrypted stream it would require a PowerDVD disassembilng as you said (which could be worth the effort in any case). I'm sure the use UHD BD AACS 2.0 protection on PC does involve SGX of course, but I wonder if also the info sent over internet connection plays a role in it.

Anyhow someone has succesfully decrypted UHD BDs already, so it's doable... A post for key database for UHD BD like the one you mean for standard blu-rays would be very useful, but unfortunately the ones who succesfully decrypted UHD BDs either aren't thinking about it or don't want to share the info about finding UHD BD VUK.

Please look at this old story:

https://www.theregister.co.uk/2017/03/07/eggheads_slip_a_note_under_intels_door_sgx_can_leak_crypto_keys/

this one is also a possible starting point to work on it:

https://github.com/m1ghtym0/sgx-timing


Modded SGX driver is the only way IMHO to achieve it.

I find it's incredible while a lot of people is still working on standard BD decryption none is working on UHD ones... This forum has always been very active on that topics, but nothing on UHD BD, even if it has been done and so it's a topic worth to spend time on.

candela
30th August 2017, 10:38
They may get the info needed to decrypt and then cache it for later use. Possibly it was mandated by AACS to get a license for a PC player.

And for the ripped 4K discs. Perhaps the decrypted streams were extracted without knowing the actual keys. Or they were retrieved from a source before they were encrypted. Or revealing the method would close the security hole immediately. It seems only a few discs were made available, so it's likely not a foolproof method.

If it would take a reasonable amount of effort, it think commercial rippers like Redfox, DVDFab, MakeMKV, etc. would already have implemented it to get a significant advantage over their competitors.

But if you understand these SGX attacks and can apply them, by all means give it a try and report back :) But I doubt you will get much help here, considering the almost complete lack of interest for the things I mentioned which are a piece of cake compared to what you want

edo1080
30th August 2017, 10:49
Possibly it was mandated by AACS to get a license for a PC player

I agree and it's exactly what I expected

revealing the method would close the security hole immediately

IMHO this is the main reason why they don't reveal it; someone has put over the internet a story about faulty/exploited keys, which seems unlikely to me: what "faulty key" should mean? The UHD BD are mastered with authoring programs, they don't fail creating discs as you know for sure!

give it a try and report back

Will do for sure, there's a lack of documentation about the whole UHD BD story... Maybe I won't be able to discover anything as you expect (and you're probably right! ;) ) but any further little info to share I could find and results of tries will be reported here for users.