• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

UHD Feature Request - verify M2TS hashes

The AACS pre-recorded video book specification, here: https://www.aacsla.com/specifications/AACS_Spec_BD_Prerecorded_Final_0_953.pdf
specifies that the checksums included in the content certificate are of the *encrypted* data (after bus encryption is removed). If you're validating the *decrypted* data in AnyDVD, then something is wrong - the checksums will not match. I've attached a proof of concept Python program which demonstrates this. Run it against a protected ISO. It didn't work for me on Windows when I tried it, but it does on Linux. It supports both AACS 1.0 and 2.0.
 

Attachments

  • aacs_validator.txt
    7.1 KB · Views: 23
See section 2.3.2.1 of the AACS Blu-ray Disc Pre-recorded Book specification, quoted here:
A Hash Value for each Hash Unit of the Clip AV stream file is calculated using the SHA-1 hashing function as
defined in the equation below. If the data is encrypted, the encrypted data itself is used as the input to the
hashing function, so that the Licensed Player need not decrypt the data before calculating a Hash Value. The
stored Hash Value is the least significant 64 bits of the result for the SHA-1 hashing function.
 
Is there any log or marking that you got a good rip? ... or how is an "bad" rip reported?
 
Is there any log or marking that you got a good rip? ... or how is an "bad" rip reported?
Similar to a normal read error, if 10 retries didn't help: Message box, "Retry, Continue, Cancel".
 
The AACS pre-recorded video book specification, here: https://www.aacsla.com/specifications/AACS_Spec_BD_Prerecorded_Final_0_953.pdf
specifies that the checksums included in the content certificate are of the *encrypted* data (after bus encryption is removed). If you're validating the *decrypted* data in AnyDVD, then something is wrong - the checksums will not match. I've attached a proof of concept Python program which demonstrates this. Run it against a protected ISO. It didn't work for me on Windows when I tried it, but it does on Linux. It supports both AACS 1.0 and 2.0.
Nice, but it doesn't help for the normal case (deprotection by the driver).
 
I don't know how you've done the decryption internally. The point is that you can validate the checksums on a protected iso too.
 
.... And I think in my years of using AnyDVD I've never had a single bad rip.

I did a compare using 8.2.4.6 with a UHD rip done only last week, and the main M2TS was different. Double checked with a 2nd rip using 8.2.4.6 - So, It does happen (I guess in many cases we may just not know or notice rip errors).
 
Oh I'm not saying it's not happening, I've just never noticed any playback problems. In my eyes that then counts as a successful backup.

Sent from my Nexus 6P with Tapatalk
 
Last edited:
True - I also did not notice any issues with ripping BD, but when I started on UHD then the story changed.
 
I don't know how you've done the decryption internally. The point is that you can validate the checksums on a protected iso too.
As a real-time and random-access (!!!) decrypter, the decryption and remastering is done in real-time (!!!) in the driver - far, far away from the use mode application.
Adding hash checking to the driver would be challenging. Let me think about it.
 
FYI - I don't know how DeUHD does it but It will report ripping errors (I presume) at the driver level as you can use a any front end to rip (eg JRiver Media Center) but it will report errors when ripping and JRiver when then error out as well.
 
As a real-time and random-access (!!!) decrypter, the decryption and remastering is done in real-time (!!!) in the driver - far, far away from the use mode application.
Adding hash checking to the driver would be challenging. Let me think about it.
Ah, I can see how that might be a problem. Presumably you could translate the (filename+offset) values into start/end sectors, since each hash unit is a fixed length, then send them plus the truncated checksum to the driver via an ioctl or similar. Probably it isn't necessary to verify these checksums for random access, only during backups if that simplifies things.
 
Back
Top