FindVUK tool - get VUK of all Blurays supported by DVDfab applications - Page 45

MrPenguin · 12th March 2025, 17:49

Quote:

Originally Posted by Toad King

The "validated" entry in the keydb is incorrect and does not work. I'm trying to update it to the correct keys.

OK, that's weird because I though FindVUK 1.79 wouldn't do that...

mick0 · 12th March 2025, 18:27

Quote:

Originally Posted by Toad King

The "validated" entry in the keydb is incorrect and does not work. I'm trying to update it to the correct keys.

FWIW the current entry for this disc has been mark both "validated" and "unknown" status in the database.

Code:

<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
  <FileType>BlurayMetaXML</FileType>
  <DiscId Date="2020.02.12">A6F5AC52B2EDC7BA254CAD6D491799EEC1EADC03</DiscId>
  <DiscType>UHD</DiscType>
  <VolumeId/>
  <MediaKey/>
  <VolumeUniqueKey/>
  <Validated>1</Validated>
  <VolumeLabel>BAD_BOYS_FOR_LIFE</VolumeLabel>
  <BDplus>0</BDplus>
  <BusEncryptionEnabled>1</BusEncryptionEnabled>
  <MKBrev>68</MKBrev>
  <MainPlaylist/>
  <UnitKeys>
    <UnitKey Nr="1" Status="unknown">F81FFC84B05A73FEE1AF02E2403D3762</UnitKey>
  </UnitKeys>
  <EncryptedValues>
    <UnitKeysENC>
      <UnitKey Nr="1">4831785627C690A0C350C93D2F569AA8</UnitKey>
    </UnitKeysENC>
  </EncryptedValues>
  <MetaTitles>
    <MetaTitle Language="eng">Bad Boys for Life - 4K Ultra HD</MetaTitle>
  </MetaTitles>
  <Hashes>
    <Hash Type="MD5" File="MKB_RO.inf" Size="5242880">02FFEE0285F49144CBE8D5388425DB8E</Hash>
    <Hash Type="MD5" File="Unit_Key_RO.inf" Size="65536">17D66594B45B5C4C43FFB0293788E2D3</Hash>
  </Hashes>
  <Application>FindVUK 1.79</Application>
  <VolumeSize>58874855424</VolumeSize>
</Bluray>

There is also another upload for this disc that has been marked fully validated. I suppose these are the correct keys for this title?

Code:

<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
  <FileType>BlurayMetaXML</FileType>
  <DiscId Date="2020.02.12">A6F5AC52B2EDC7BA254CAD6D491799EEC1EADC03</DiscId>
  <DiscType>UHD</DiscType>
  <VolumeId>A7BB091D19F7C0B3A1880CC4BDE007BE</VolumeId>
  <MediaKey>864BFC8833D4A106DE6ACD240AEB9CF8</MediaKey>
  <VolumeUniqueKey>C2B9CEAC8512D8C9E00912D89FBC51EC</VolumeUniqueKey>
  <Validated>1</Validated>
  <VolumeLabel>BAD_BOYS_FOR_LIFE</VolumeLabel>
  <BDplus>0</BDplus>
  <BusEncryptionEnabled>1</BusEncryptionEnabled>
  <MKBrev>68</MKBrev>
  <MainPlaylist/>
  <UnitKeys>
    <UnitKey Nr="1" Status="valid">452519DA5B47634BE7D925E06B91F64F</UnitKey>
  </UnitKeys>
  <EncryptedValues>
    <UnitKeysENC>
      <UnitKey Nr="1">4831785627C690A0C350C93D2F569AA8</UnitKey>
    </UnitKeysENC>
  </EncryptedValues>
  <MetaTitles>
    <MetaTitle Language="eng">Bad Boys for Life - 4K Ultra HD</MetaTitle>
  </MetaTitles>
  <Hashes>
    <Hash Type="MD5" File="MKB_RO.inf" Size="5242880">02FFEE0285F49144CBE8D5388425DB8E</Hash>
    <Hash Type="MD5" File="Unit_Key_RO.inf" Size="65536">17D66594B45B5C4C43FFB0293788E2D3</Hash>
  </Hashes>
  <Application>FindVUK 1.79</Application>
  <VolumeSize>58874855424</VolumeSize>
</Bluray>

TTide · 12th March 2025, 22:40

Code:

There is also another upload for this disc that has been marked fully validated. I suppose these are the correct keys for this title?

I thought AACSv2 Discs couldn't be watched on free software players.

https://forum.doom9.org/showthread.p...40#post1997540

SamuriHL · 12th March 2025, 23:42

Quote:

Originally Posted by TTide

I thought AACSv2 Discs couldn't be watched on free software players.

https://forum.doom9.org/showthread.p...40#post1997540

Sure they can. They just need aacslib and a keydb entry. What we don't have is a processing/device key to decrypt the mediakey. But if you have the unit keys, any free player that supports the keydb can play it. If a processing/device key ever becomes available (unlikely but you never know) then the aacslib would in theory be able to do the whole decryption. Yes, there's host certs and all that to contend with but with LibreDrive, that could be bypassed.

Toad King · 13th March 2025, 00:04

Quote:

Originally Posted by mick0

FWIW the current entry for this disc has been mark both "validated" and "unknown" status in the database.

Code:

<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
  <FileType>BlurayMetaXML</FileType>
  <DiscId Date="2020.02.12">A6F5AC52B2EDC7BA254CAD6D491799EEC1EADC03</DiscId>
  <DiscType>UHD</DiscType>
  <VolumeId/>
  <MediaKey/>
  <VolumeUniqueKey/>
  <Validated>1</Validated>
  <VolumeLabel>BAD_BOYS_FOR_LIFE</VolumeLabel>
  <BDplus>0</BDplus>
  <BusEncryptionEnabled>1</BusEncryptionEnabled>
  <MKBrev>68</MKBrev>
  <MainPlaylist/>
  <UnitKeys>
    <UnitKey Nr="1" Status="unknown">F81FFC84B05A73FEE1AF02E2403D3762</UnitKey>
  </UnitKeys>
  <EncryptedValues>
    <UnitKeysENC>
      <UnitKey Nr="1">4831785627C690A0C350C93D2F569AA8</UnitKey>
    </UnitKeysENC>
  </EncryptedValues>
  <MetaTitles>
    <MetaTitle Language="eng">Bad Boys for Life - 4K Ultra HD</MetaTitle>
  </MetaTitles>
  <Hashes>
    <Hash Type="MD5" File="MKB_RO.inf" Size="5242880">02FFEE0285F49144CBE8D5388425DB8E</Hash>
    <Hash Type="MD5" File="Unit_Key_RO.inf" Size="65536">17D66594B45B5C4C43FFB0293788E2D3</Hash>
  </Hashes>
  <Application>FindVUK 1.79</Application>
  <VolumeSize>58874855424</VolumeSize>
</Bluray>

There is also another upload for this disc that has been marked fully validated. I suppose these are the correct keys for this title?

Code:

<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
  <FileType>BlurayMetaXML</FileType>
  <DiscId Date="2020.02.12">A6F5AC52B2EDC7BA254CAD6D491799EEC1EADC03</DiscId>
  <DiscType>UHD</DiscType>
  <VolumeId>A7BB091D19F7C0B3A1880CC4BDE007BE</VolumeId>
  <MediaKey>864BFC8833D4A106DE6ACD240AEB9CF8</MediaKey>
  <VolumeUniqueKey>C2B9CEAC8512D8C9E00912D89FBC51EC</VolumeUniqueKey>
  <Validated>1</Validated>
  <VolumeLabel>BAD_BOYS_FOR_LIFE</VolumeLabel>
  <BDplus>0</BDplus>
  <BusEncryptionEnabled>1</BusEncryptionEnabled>
  <MKBrev>68</MKBrev>
  <MainPlaylist/>
  <UnitKeys>
    <UnitKey Nr="1" Status="valid">452519DA5B47634BE7D925E06B91F64F</UnitKey>
  </UnitKeys>
  <EncryptedValues>
    <UnitKeysENC>
      <UnitKey Nr="1">4831785627C690A0C350C93D2F569AA8</UnitKey>
    </UnitKeysENC>
  </EncryptedValues>
  <MetaTitles>
    <MetaTitle Language="eng">Bad Boys for Life - 4K Ultra HD</MetaTitle>
  </MetaTitles>
  <Hashes>
    <Hash Type="MD5" File="MKB_RO.inf" Size="5242880">02FFEE0285F49144CBE8D5388425DB8E</Hash>
    <Hash Type="MD5" File="Unit_Key_RO.inf" Size="65536">17D66594B45B5C4C43FFB0293788E2D3</Hash>
  </Hashes>
  <Application>FindVUK 1.79</Application>
  <VolumeSize>58874855424</VolumeSize>
</Bluray>

Yes, that second entry has the correct keys. I guess the generated keydb file is only grabbing that first entry and not the second one for some reason. (How can a key be validated if the unit key status is unknown?)

Also how are you getting these individual entries for the DB from? I assume there's some other API for getting this extra data.

mick0 · 13th March 2025, 00:40

Quote:

Originally Posted by Toad King

Also how are you getting these individual entries for the DB from? I assume there's some other API for getting this extra data.

It's all public information, see the "Online DB - BlurayMeta Archive" link in this post.

MrPenguin · 13th March 2025, 12:22

Quote:

Originally Posted by SamuriHL

If a processing/device key ever becomes available (unlikely but you never know) then the aacslib would in theory be able to do the whole decryption.

To be fair, any AACSv2 processing/device key would be revoked as soon as it became publicly available. So I seriously doubt this will happen unless the key could be replaced quickly and easily.

Personally, I'd quite like an AACSv2 host certificate because that would allow me to disable bus encryption on my Pioneer XD08U drive that doesn't support LibreDrive.

SamuriHL · 13th March 2025, 13:55

I agree that it's highly unlikely we'll ever see a device/processing key for aacs 2.x.

That's true, a valid host cert would negate bus encryption and would make findvuk easier, as well. Maybe that'd allow dvdfab to finally support pio drives, as well.

Sent from my SM-S938U1 using Tapatalk

nalor · 14th March 2025, 22:38

Quote:

Originally Posted by MrPenguin

OK, that's weird because I though FindVUK 1.79 wouldn't do that...

This is definitely strange - need to check that.

coricopat · 15th March 2025, 00:43

@nalor ...maybe if you're at it and have some time, perhaps you could check/consider the following:

a) On some mediums, when using FindVUK from Linux via Wine, the VolumeLabel field contains a traling 0x1F, which causes the submission to fail.
Perhaps FindVUK could strip that (or any control characters) off

b) The same medium would give different values for VolumeSize on at least Windows 10 and Linux (via wine).
I've checked it a while ago and it seemed Linux' value was more correct and if I remember correctly, Windows 11 even calculates it now how Linux does (but not sure about that9.

Not sure how you determine the value,... maybe one could instead sum up all the file sizes?
That should be portable, but OTOH require to read all file sizes (which may take a while)... and also invalidate all current entries.

So... no idea what one should do, if anything at all.

Cheers.

nalor · 17th March 2025, 23:47

Quote:

Originally Posted by coricopat

@nalor ...maybe if you're at it and have some time, perhaps you could check/consider the following:

a) On some mediums, when using FindVUK from Linux via Wine, the VolumeLabel field contains a traling 0x1F, which causes the submission to fail.
Perhaps FindVUK could strip that (or any control characters) off

b) The same medium would give different values for VolumeSize on at least Windows 10 and Linux (via wine).
I've checked it a while ago and it seemed Linux' value was more correct and if I remember correctly, Windows 11 even calculates it now how Linux does (but not sure about that9.

Not sure how you determine the value,... maybe one could instead sum up all the file sizes?
That should be portable, but OTOH require to read all file sizes (which may take a while)... and also invalidate all current entries.

So... no idea what one should do, if anything at all.

Cheers.

(a) is (hopefully) already fixed in my local code for a long time, just missed to create a new release.

(b) sum of filesizes would not be right as e.g. on 3D discs sectors are referenced by multiple files so the sum of all files is greater than the actual disc.
Currently I'm using a windows api: GetDiskFreeSpaceEx

And in general I think I found the bug with the validate=true although there are no validated unit keys - I missed to return the correct result in case validation failed for a bus encrypted disc - very likely due to a wrong RDK.

Try to release a fixed 1.80 tomorrow.

SamuriHL · 17th March 2025, 23:54

Any chance while you're in there you can add a switch to validatedisc to process one disc only and then exit? It would help me immensely but understand if you don't want that or don't have time. Thanks!

Toad King · 18th March 2025, 01:51

Quote:

Originally Posted by nalor

(b) sum of filesizes would not be right as e.g. on 3D discs sectors are referenced by multiple files so the sum of all files is greater than the actual disc.
Currently I'm using a windows api: GetDiskFreeSpaceEx

Not sure how Windows works obviously but in Wine that API calls statfs/fstatfs under the hood which looks correct.

Looking at the docs for GetDiscFreeSpaceEx it looks like it can return a smaller value based on whether the whole disc is "available to the user" or not. It might be more accurate to use something like IOCTL_DISK_GET_LENGTH_INFO or IOCTL_DISK_GET_DRIVE_GEOMETRY_EX, although it looks like some of those might not be implemented in Wine so it may need a fallback.

coricopat · 18th March 2025, 02:00

See my earlier post here, which explains - if I'm correct - how Windows (10 only?) and Linux count the UDF size differently.

Windows seems to include the actual "data area" (PSPACE) + all leading parts of the "partitions"... Linux only take the PSPACE.

nalor · 18th March 2025, 22:33

Published FindVUK 1.81 (I noticed I already created an 1.80 back in september 2024 which only fixes the volumename problem in wine).

nalor · 18th March 2025, 22:46

Quote:

Originally Posted by SamuriHL

Any chance while you're in there you can add a switch to validatedisc to process one disc only and then exit? It would help me immensely but understand if you don't want that or don't have time. Thanks!

Have you tried the ini-switch "ExitAfterprocessing" ? I'd expect that it already does what you need... in case it does not, let me know and I'll fix it.

Toad King · 18th March 2025, 22:58

Quote:

Originally Posted by nalor

Published FindVUK 1.81 (I noticed I already created an 1.80 back in september 2024 which only fixes the volumename problem in wine).

It seems to work. (it errors out and doesn't send anything when validating on the incorrect info.) I think the DB entry for 0xA6F5AC52B2EDC7BA254CAD6D491799EEC1EADC03 still has to be fixed manually since I still can't upload the correct keys to it still.

Also, is it possible to implement the changes from this post in a future release? It'll help auto-ejecting work under Wine: https://forum.doom9.org/showthread.p...16#post2009416

SamuriHL · 18th March 2025, 23:38

Quote:

Originally Posted by nalor

Have you tried the ini-switch "ExitAfterprocessing" ? I'd expect that it already does what you need... in case it does not, let me know and I'll fix it.

I have not as I didn't know about that one. I'll give it a try thanks!

nalor · 18th March 2025, 23:40

Quote:

Originally Posted by Toad King

I put in the correct keys and did that and it validates but the wrong keys are still in the download.

Please try again - I've changed the entry in the db to "validated=0" - so I think a new validation should result in an update.

There are 11 more entries that look strange .. will check tomorrow in detail.

SamuriHL · 18th March 2025, 23:44

Quote:

Originally Posted by nalor

Have you tried the ini-switch "ExitAfterprocessing" ? I'd expect that it already does what you need... in case it does not, let me know and I'll fix it.

Quote:

Originally Posted by SamuriHL

I have not as I didn't know about that one. I'll give it a try thanks!

Looks like I already had that set and it doesn't seem to take affect for validatedisc unless I'm doing something wrong. (So apparently I did know about it last time I updated the ini file LOL)

EDIT: This is what happens with that set in the ini after it ejects the disc (which is also set to not eject):

Code:

18:50:55 - AACS folder on disc in drive >g< is not accessible - keep waiting for disc to appear (abort with ESC)

12th March 2025, 22:40	#883 \| Link
TTide Registered User Join Date: Jul 2014 Posts: 29	Code: There is also another upload for this disc that has been marked fully validated. I suppose these are the correct keys for this title? I thought AACSv2 Discs couldn't be watched on free software players. https://forum.doom9.org/showthread.p...40#post1997540

13th March 2025, 13:55	#888 \| Link
SamuriHL Registered User Join Date: May 2004 Posts: 5,471	I agree that it's highly unlikely we'll ever see a device/processing key for aacs 2.x. That's true, a valid host cert would negate bus encryption and would make findvuk easier, as well. Maybe that'd allow dvdfab to finally support pio drives, as well. Sent from my SM-S938U1 using Tapatalk __________________ HTPC: Windows 11, AMD 5900X, RTX 3080, Pioneer Elite VSX-LX303, LG G2 77" OLED

17th March 2025, 23:54	#892 \| Link
SamuriHL Registered User Join Date: May 2004 Posts: 5,471	Any chance while you're in there you can add a switch to validatedisc to process one disc only and then exit? It would help me immensely but understand if you don't want that or don't have time. Thanks! __________________ HTPC: Windows 11, AMD 5900X, RTX 3080, Pioneer Elite VSX-LX303, LG G2 77" OLED

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

15th March 2025, 00:43	#890 \| Link
coricopat Registered User Join Date: Jan 2024 Posts: 54	@nalor ...maybe if you're at it and have some time, perhaps you could check/consider the following: a) On some mediums, when using FindVUK from Linux via Wine, the VolumeLabel field contains a traling 0x1F, which causes the submission to fail. Perhaps FindVUK could strip that (or any control characters) off b) The same medium would give different values for VolumeSize on at least Windows 10 and Linux (via wine). I've checked it a while ago and it seemed Linux' value was more correct and if I remember correctly, Windows 11 even calculates it now how Linux does (but not sure about that9. Not sure how you determine the value,... maybe one could instead sum up all the file sizes? That should be portable, but OTOH require to read all file sizes (which may take a while)... and also invalidate all current entries. So... no idea what one should do, if anything at all. Cheers.

18th March 2025, 02:00	#894 \| Link
coricopat Registered User Join Date: Jan 2024 Posts: 54	See my earlier post here, which explains - if I'm correct - how Windows (10 only?) and Linux count the UDF size differently. Windows seems to include the actual "data area" (PSPACE) + all leading parts of the "partitions"... Linux only take the PSPACE.

18th March 2025, 22:33	#895 \| Link
nalor Registered User Join Date: Dec 2013 Posts: 526	Published FindVUK 1.81 (I noticed I already created an 1.80 back in september 2024 which only fixes the volumename problem in wine).