AACS Keys - A program revealing all AACS Keys needed to decrypt (HD DVD and Blu-ray) - Page 5

mb2696 · 29th March 2007, 04:58

what does it mean if the volume id is reported as a string of zeroes? i've been having trouble getting "National Geographic - Relentless Enemies" to work.

any ideas?

thanks

arnezami · 29th March 2007, 05:44

Quote:

Originally Posted by mb2696

what does it mean if the volume id is reported as a string of zeroes? i've been having trouble getting "National Geographic - Relentless Enemies" to work.

any ideas?

thanks

Is it a BD or HD DVD?
What drive do you have?
What operating system?
Are other discs (still) working? Or do you only have one?
Do you get a Media Key and is the decr verif ok?
Do you get a Dcert (in sensitive mode)?
Have you tried any of the vuk keyfinder programs?
Have you tried sniffing the volume id?

A screenshot/copy-paste using the program in verbose mode would also be helpful.

arnezami

mb2696 · 29th March 2007, 13:32

it is an hd dvd, xbox 360 addon, win xp pro. other discs are working.

when i try to play the disc directly in powerdvd 7.1, it goes into file mode and plays the evo files in sequence. I get no error about system compliance, despite having DVI w/o HDCP (normally get an error). it is only black video and no audio however. eventually it frezees (doens't crash, just locks up).

anydvd hd is also unable to allow playback and reports the disc as NOT AACS protected.

below is the verbose output of aacskeys for this disc.

Code:

Processing key:               09F911029D74E35BD84156C5635688C0
Encrypted C-value:            C990975CBD4ADDB666DD661AFE0A1FAC
Corresponding uv:             00000001

Decrypted C-value:            A0BC2B16A2AD64D1A3C20FAE26681C0B
Media key:                    A0BC2B16A2AD64D1A3C20FAE26681C0A

Encrypted verification data:  B87D991B8B5E6CF11273D29EB3F5784B
Decr verif data should be:    0123456789ABCDEF
Decrypted verification data:  0123456789ABCDEFD904126F3088DD12

AGID:                         00

Host certificate from:        Power DVD 7.1
Host certificate (Hcert):     0200005CFFFF0000000C00006E3DEB679B9A16AD
                              FAA8E30878767BA6EB2A9B415385AD1181B4446C
                              31E9A5DD2AB808B364FF15885BAC490964318C9B
                              F8029FCF76F688A54FBDA03F6D9332EF04E5A613
                              12DA85880A4D9CBB79D8602E
Host Private Key (Hpriv):     4737676058D7029452514F0AB186DC4CCA8C578F
Host Nonce (Hn):              2923BE84E16CD6AE529049F1F1BBE9EBB3A6DB3C

Drive certificate (Dcert):    ########################################
                              ########################################
                              ########################################
                              ########################################
                              ########################
Drive Nonce (Dn):             ########################################

Drive key point (Dv):         ########################################
                              ########################################
Drive key signature (Dsig):   ########################################
                              ########################################

Host key (Hk):                0000000000000000000000000000000000000000
Host key point (Hv):          8E9B0E3CF41FA7DA3A829F604122EA4ED5261AA4
                              7570CE0BB9061A66FAF92C4A7D98ACC171CBF19B
Host key signature (Hsig):    ########################################
                              ########################################

Drive signature wrong/error
Bus key (BK):                 ################################

Volume ID:                    00000000000000000000000000000000
Voluem ID MAC:                ################################

Volume Unique Key:            DF467CB369CCBC93D6792BED0098E966
Title Key File MAC:           6E11DD594198CF674FBE74B9664EE80F

Encrypted Title Key 1:        DE6785635AF17AE449571F763937684F
Encrypted Title Key 2:        853D0D63B9BD4990814009CAC2C9BCC4
Encrypted Title Key 3:        067BEE3D57983E426D2F0FF1FDE74DF9
Encrypted Title Key 4:        4891A8FEA46663CBAAFD2C23C99C9225
Encrypted Title Key 5:        2D7B7F1CA6F7D37D69AD8C496AD47A38
Encrypted Title Key 6:        A009ADFCDC5989747B4C8BF28E69AC79
Encrypted Title Key 7:        AAD29F9598BD98812BA3FCC6181A93F5
Encrypted Title Key 8:        B6402AD20F5028BBDBC681EDF2DF28D5
Encrypted Title Key 9:        62F94819A15A8D4D37DCAA0FFC62EF12
Encrypted Title Key 10:       59ABE1644D98ED1E334094E1D826C18C
Encrypted Title Key 11:       B98F04EA86D87701D07A3326374AC793
Encrypted Title Key 12:       964A86CC899551F8138C5920ED9052E4
Encrypted Title Key 13:       0823DC62F0B707D1B4DA1574ECECCA2D
Encrypted Title Key 14:       4494BC773EABC6468175905FD7DE1481
Encrypted Title Key 15:       0DD6DB058BD26DF882168BAEE60D187E
Encrypted Title Key 16:       5F19D4CF2A464ED428832291D44BE38F
Encrypted Title Key 17:       E614648A79686D557814910F8B0F920C
Encrypted Title Key 18:       737D94F443D1953DD4EAB4D23DBFB497
Encrypted Title Key 19:       8924F90DBBCA432CFD67215D222BB016
Encrypted Title Key 20:       12685674EF40155416D5A4B944644664
Encrypted Title Key 21:       FE36FFB973DC916A55FDF7962083C5C8
Encrypted Title Key 22:       04B3B15B96AAEB8ED837C77C9D9C159F
Encrypted Title Key 23:       D29FD7212E78B144E38E1D5563B8FD04
Encrypted Title Key 24:       4B6FA66D8A4CD64CA7E85EF37F871405
Encrypted Title Key 25:       5E5E430478DCCB60A58E9AEC11D3996E
Encrypted Title Key 26:       A4770F6477551BF428EB2691DE4D323D
Encrypted Title Key 27:       F91905AB75F121470AEF780FA26FD2F2
Encrypted Title Key 28:       4E7D7D69C2E0BE12B0845CA16BCF0A09
Encrypted Title Key 29:       006B89CDF5A7955A38DB8D27163B0A14
Encrypted Title Key 30:       ECC3BF960ECA00A37F3EB574A2879C43
Encrypted Title Key 31:       AEBCA11C64856AB841AC6C948CBCF348
Encrypted Title Key 32:       8E2AA7BF0C908DAA121CFAFB81F76358
Encrypted Title Key 33:       AB91207C4915A9EBDFBC1E8AE7CDBFFB
Encrypted Title Key 34:       8CBE0199CB8A826145B962DEAB65727D
Encrypted Title Key 35:       31C27F2C84D4E54E834BC7F9C27FF766
Encrypted Title Key 36:       939DB5093D5256B372B1FF8882D7A991
Encrypted Title Key 37:       900C2E111807C8C363B20A7F02D3103C
Encrypted Title Key 38:       FF3715A4C288505034D1B423251C539F
Encrypted Title Key 39:       320A49E010897E2A13DE4EFC23553877
Encrypted Title Key 40:       78E5939F220D37F4FF2D5CAC529D3BF1
Encrypted Title Key 41:       12E7CD9E71284D36324B70FDC63BEB96
Encrypted Title Key 42:       652C70408C93D766950FD88444088B2D
Encrypted Title Key 43:       46B20498D6B3B61066B93D07EA47D7FC
Encrypted Title Key 44:       5FEC3D236700190DCD7B9A3CBF2EECCB
Encrypted Title Key 45:       C5C8B3C739BD57E1DC6AC86C09A41395
Encrypted Title Key 46:       A64BCE20A6078988828B4D901BF47E1F
Encrypted Title Key 47:       31D8DDC4C8F43620B73BCC005D668D9F
Encrypted Title Key 48:       C3471E12EDA8B2E0D69FC3BB9F9A5D90
Encrypted Title Key 49:       99525C1EEE31123BF1A5C50C03512D14
Encrypted Title Key 50:       2194F56FC616A9807534DDFF802B600A
Encrypted Title Key 51:       48CDCD7C390D7D28F77A00CBC0527CE7
Encrypted Title Key 52:       912233A518C7C002CEE0105A0CD84CF3
Encrypted Title Key 53:       91322B3E8B6F031185BDD64E92B759F8
Encrypted Title Key 54:       C1803CDD727E626491A666FC03A4067B
Encrypted Title Key 55:       D2604E141DE6BEDE1486659243B00506
Encrypted Title Key 56:       37FB50CB9AC163F6D529CE5051B315E8
Encrypted Title Key 57:       D3881422187B9E2D9B5F3CBB999241F1
Encrypted Title Key 58:       7A3D46993C90F86621CD341FD6E19092
Encrypted Title Key 59:       D499AB49241EF4D8785D168BC3D07374
Encrypted Title Key 60:       5CF021DF6B7A7B272CF6BED1584094B6
Encrypted Title Key 61:       52ED5C5A71557A2EDACFCE35A370F9B6
Encrypted Title Key 62:       7E4A9004DCEC9CFE5A5F68E4C7BF3A7F
Encrypted Title Key 63:       926AAB3E041408F67D6C1999AAC2498A
Encrypted Title Key 64:       5384523CCFD947C0D736913335A41858

Decrypted Title Key 1:        DE5E4DB4B7365B7CFD91107FECC3D54A
Decrypted Title Key 2:        3EFF30EB5D509F7C44BE60C1C27E1E72
Decrypted Title Key 3:        C1471F2BFA77F714D134D1E35893577E
Decrypted Title Key 4:        CBE9384603931E1E5F462B0A2183C8F5
Decrypted Title Key 5:        12193E2D72EBF288C49C4F6646AE62E4
Decrypted Title Key 6:        5453B697EB25A7EFADC42D9DCF7F73D8
Decrypted Title Key 7:        31405D51FE8961FBFBC69E94447E3BDF
Decrypted Title Key 8:        B206367595727DE08CDA953F5B7966AC
Decrypted Title Key 9:        7099AB7C4D4D990F7D591E4166982F9E
Decrypted Title Key 10:       0A8D1F30E159231EF6CB7122AD628F3F
Decrypted Title Key 11:       400E59ED5B89ECAE4AA4197CF6857512
Decrypted Title Key 12:       84349904F473A88C4C5B5F61490439D1
Decrypted Title Key 13:       4F123A0754FB0AD1D63DE8ED1AA82BF8
Decrypted Title Key 14:       80029EF555C975713E5CC8B0A3868D33
Decrypted Title Key 15:       51FC3529176E79CEE4C74CECA09A07F9
Decrypted Title Key 16:       B2B8A7F2E3DEFA0FDEC84642AD893290
Decrypted Title Key 17:       DBB7516E551F78DDF554659D37281FC8
Decrypted Title Key 18:       2CDBFD80C54FD887B7EFDB98CBCD4CBE
Decrypted Title Key 19:       2177CDE40DEE61129EA12FD54243A6B6
Decrypted Title Key 20:       6C6633AFA44320321ABA8D770E259722
Decrypted Title Key 21:       1124310E7C2C871B0E4C3C2DDF75ECF5
Decrypted Title Key 22:       862818A2915A8E540C086AE6D70D5DFF
Decrypted Title Key 23:       E60C4F2E0C8E2E17172EA58A6B4162BD
Decrypted Title Key 24:       6C9EF06F097A1860639F9CF67E744ED3
Decrypted Title Key 25:       666F2D6F9CACD4E8048C8B49CEE4D60F
Decrypted Title Key 26:       13DB98AD715160D50BB1630E1FE89D04
Decrypted Title Key 27:       F241BC19E54FDE26D747AC749F122424
Decrypted Title Key 28:       C8F699ACAD06B72D8FAA6A46D2F0E6D4
Decrypted Title Key 29:       22FAF62B92C3B097D1BC0C27F215F5BF
Decrypted Title Key 30:       28843CFB1B949AA7277BE3E5749A799A
Decrypted Title Key 31:       1FC715148F71B37D5F3D4DC8727172DF
Decrypted Title Key 32:       83E2A13D2F8198A23AA93E3ED644446A
Decrypted Title Key 33:       5E53A9C2BE85FA02965810833B1C9DBC
Decrypted Title Key 34:       DE3F36220642162B321292E51CC5EE8D
Decrypted Title Key 35:       FF0DFC1F529572F6FD5C3775A90C4810
Decrypted Title Key 36:       E37B6BEF8883EE30131DD7E64F306A8E
Decrypted Title Key 37:       0737C851B2358E157A1C8C664F3D7A05
Decrypted Title Key 38:       35A772F991B84DCD0DDFAECA0D2FF9B8
Decrypted Title Key 39:       D718824549DA46144DC015D16FB43A89
Decrypted Title Key 40:       A009CC503749A69F0295657C831E1A62
Decrypted Title Key 41:       63B0072B377303237A66011A93A90EA7
Decrypted Title Key 42:       CF1201B14B3CA0CE33AF640B5D8BD82E
Decrypted Title Key 43:       85E693F3BC809AA9B3B9018AEA88E926
Decrypted Title Key 44:       43FDE24CFC9A1F997D55A90EBCF7BC22
Decrypted Title Key 45:       E4A3A04555291F3D03AC9304DF063B12
Decrypted Title Key 46:       B761955930A726F44D556D7C8B80E999
Decrypted Title Key 47:       28B8A94901440D6465233993ACF5379A
Decrypted Title Key 48:       2D6889616F041831732B3B5521000D6D
Decrypted Title Key 49:       48E0498B6264AE80098DAE292C1A9AE9
Decrypted Title Key 50:       89E2B5BC8C2D08F69BDC0C359DB92258
Decrypted Title Key 51:       F83036CB4E28D4BB1244D1A6CB141EB3
Decrypted Title Key 52:       F43281CFCD726738D793B1B13CBED822
Decrypted Title Key 53:       22433445DC3B4591DE12C789073DF379
Decrypted Title Key 54:       5DB6F0B0A3E55A97F42E58A74B88B767
Decrypted Title Key 55:       B8AD884889124A8EE386644410AB42BA
Decrypted Title Key 56:       5711C77BCBFB7F08B414DF23B066083B
Decrypted Title Key 57:       89F4A2EA4F836DE4CA448600D6A07CE1
Decrypted Title Key 58:       910AEF1F7FCBDD97B3BC1613FDA828E7
Decrypted Title Key 59:       A934E626EDE578F2BD216564E25A07A3
Decrypted Title Key 60:       E0C8ED9E39802EEE779BF6035FF2C209
Decrypted Title Key 61:       A760D11F6AED68E3A392760626CF66EA
Decrypted Title Key 62:       D963E8BF655DD550AA06FEB9E5F18092
Decrypted Title Key 63:       0D2E8E0B142C13B79121A786BB139CCC
Decrypted Title Key 64:       664BE38CC25FBA5CAA58D9C9FC0F15BC

arcsyn · 29th March 2007, 21:44

Forgive me for being an idiot, but will this tool still work if there is a new set of AACS keys coming out next much?

Will this tool still give us the information needed to make backups, or does this program rely on something they can revoke?

dirio49 · 30th March 2007, 02:21

I think if they change the key, then a new version of the tool will have to be compiled with the new keys. But first we have to find the new key

SBeaver · 30th March 2007, 20:14

Quote:

Originally Posted by dirio49

I think if they change the key, then a new version of the tool will have to be compiled with the new keys. But first we have to find the new key

It would probably be best to keep this key secret until all the delayed releases start flowing, otherwise they will just change it again.
I'm guessing all software players to date will be pulled and they will force upgrades on everyone, or at least a patch that makes them more secure.
I believe it's all the better that they get this change out ASAP so that they rush it and hopefully make mistakes.
Change the keys, gives us BD+, do it all.
Then they have played all their cards and have nothing left to fall back on.

mb2696 · 30th March 2007, 21:36

so is this a result of a key revoke?

Fahzuu · 30th March 2007, 23:46

Quote:

Originally Posted by mb2696

when i try to play the disc directly in powerdvd 7.1, it goes into file mode and plays the evo files in sequence. I get no error about system compliance, despite having DVI w/o HDCP (normally get an error). it is only black video and no audio however. eventually it frezees (doens't crash, just locks up).

anydvd hd is also unable to allow playback and reports the disc as NOT AACS protected.

I have a similar effect with another disc - checked the communication over the bus, the drive in fact reports the disc to be not AACS protected, even though it is.
Probably a mastering error and that's why PowerDVD is unable to decrypt - because it doesn't even try, it just blindly plays the encrypted video data...

mb2696 · 30th March 2007, 23:51

Quote:

Originally Posted by Fahzuu

I have a similar effect with another disc - checked the communication over the bus, the drive in fact reports the disc to be not AACS protected, even though it is.
Probably a mastering error and that's why PowerDVD is unable to decrypt - because it doesn't even try, it just blindly plays the encrypted video data...

hmmm...others are able to play it on standalone players. if it's a mastering error wouldn't it affect all discs?

arnezami · 31st March 2007, 08:05

For mb2696.

These questions aren't answered yet:

Quote:

Originally Posted by arnezami

Do you get a Dcert (in sensitive mode)?
Have you tried any of the vuk keyfinder programs?
Have you tried sniffing the volume id?

Other questions:

- What MKB version is on it? My MKBROM starts with 1000000C000410030000000121000034 (using WinHex). Meaning my MKB version is 1 and the length of the HRL is 34h. If any of this is different then its important.
- Does it play with any software player on any other PC system? Does your disc (not similar discs) work on standalones? Do similar discs (same title) work on your PC?
- Have you tried to demux the files to see if it contains streams or whatever? Using the original files on the disc.
- Are you absolutely sure your other discs/movies are still working? And does aacskeys give volume ids for these movies?
- Is it by any chance a recordable? Be sure.

Quote:

Originally Posted by mb2696

hmmm...others are able to play it on standalone players. if it's a mastering error wouldn't it affect all discs?

What do you mean by "it"? Your disc or a similar disc? It is possible your disc is damaged/badly pressed somehow so the volume id cannot be retrieved. In that case if we can find somebody with the same title then he could retrieve the VUK and you might be able to decrypt it. Alternatively we could quess the volume id (tricky but maybe possible

).

The strange thing is there is a "Drive signature wrong/error" in your report. This means the drive either doesn't see the need for AACS-Auth (as in: its a recordable or non-encrypted/damaged disc) or it has revoked the Hcert (of PowerDVD 7.1). But if it has revoked it then other discs shouldn't work either anymore. Unless your drive "forgets" it (which strangely would in itself be great).

Anyway. Something doesn't seem to add up here

.

[edit] Just had an idea. Use KenD00's dumpvid (the exe is in the Release dir). It will dump the bca (Burst Cutting Area) of the disc and this should reveal half of the Volume ID

. (you don't have to do the hammering stuff btw). We will know much more when we have that.

Regards,

arnezami

PS. A Dcert starts with 01. If not then its garbadge data.
PPS. There is another possibility: they didn't want this title to be playable on a PC. Hmmm.....

arnezami · 31st March 2007, 08:06

Quote:

Originally Posted by Fahzuu

I have a similar effect with another disc - checked the communication over the bus, the drive in fact reports the disc to be not AACS protected, even though it is.
Probably a mastering error and that's why PowerDVD is unable to decrypt - because it doesn't even try, it just blindly plays the encrypted video data...

Which movie? Release date? How did you see it was not being identified as AACS protected using the bus?

Jedi_Vader20 · 1st April 2007, 08:28

Running Yellow Dog 5.0 PS3 on my PAL PlayStation3, Firmware 1.60.

Under both kernel 2.6.16 and the same with the UDF 2.50 patch, I get the following output when attempting to run the most recent posted aacstiny in the thread:

Code:

[root@playstation3 aacstiny]# ./aacstiny /dev/cdrom
Sending report key command: A40000000000000200003F00
Invalidation AGID 0. Result: 0
Sending report key command: A40000000000000200007F00
Invalidation AGID 1. Result: 0
Sending report key command: A4000000000000020000BF00
Invalidation AGID 2. Result: 0
Sending report key command: A4000000000000020000FF00
Invalidation AGID 3. Result: 0
Sending report key command: A40000000000000200080000
Returning buffer from report agid command: 0FF6F2400FEC0F40
All AGIDs in use, aborting. AGID: -1

aacstiny compiled with no warnings or errors. The movie I'm attempting this against is xXx, PAL release Blu-Ray.

Boing99 · 1st April 2007, 21:53

I ran some very similar tests on my PS3 a few weeks ago and can comment on some of the results posted here.

First some preliminaries:

2.6.16 is the correct kernel to use, as it contains Sony's own drivers and modifications. 2.6.20 is an (incomplete) effort by the regular kernel maintainers to merge those changes back into the regular kernel source tree and integrate them with existing drivers. That effort is still work in progress and the kernel does not boot on PS3 yet.

The UDF-2.5 patch is completely unrelated to any PS3 changes or drivers and not needed if all you want to do is send SCSI commands to the drive (to extract volume ids etc.). It IS needed if you want to mount a Blu-ray volume to get access to the files on it, for decryption. Without the patch you can simply send SCSI commands directly to the underlying device. For most setups (including PS3) that is "/dev/sr0".

Now about my actual tests, run on Gentoo (not YDL), using a 64-bit kernel and userland:

I used SG_IO instead of CDROM_SEND_PACKET in the ioctl. I am not sure this made a difference, but it seems to me that SG_IO is a lower-level request closer to the ATAPI layer, with better diagnostics and it may arguably have a better chance of not having its data modified or misinterpreted by the CD-ROM driver layer.

The first thing I tried is sending ordinary SCSI commands to the drive to ensure that the ATAPI transport through the Hypervisor works correctly. INQUIRY works fine and returns meaningful results, as does GET_CONFIGURATION, so we know the ATAPI layer works. This also very likely rules out any problems regarding sync vs. async I/O, timing, buffer management, Hypervisor API access etc.

Interesting info here: The "Vendor info" and "Identification" fields in INQUIRY return "PS-SYSTEM <serial number>". I think this is fairly unusual because typically, even for standalones, those fields report the OEM manufacturer of the drive. For example the X-Box-360 HD drive simply returns "TOSHIBA <something>". I might have expected "SONY" here, but not "PS-SYSTEM". The "PS-SYSTEM" response to me suggests that either Sony used a special drive built in-house exclusively for the PS3, without any intent to ever use it in standalone Blu-ray players (probably unlikely), or that the Hypervisor intercepted INQUIRY and responded on behalf of the drive. If it is the latter then it's bad news because it would suggest that the Hypervisor does filter SCSI commands one by one, which would explain the problems with AACS commands.

Next I tried the usual AACS SCSI commands, and all of them returned driver_status=7 (hard error) and sense_key=5 (ILLEGAL_REQUEST). That seemed strange to me at first (the part about this being reported in driver_status instead of host_status), because the driver is supposed to handle different SCSI commands transparently. The explanation is in the Sony driver in the kernel sources. ps3pf_storage.c contains a table of supported SCSI commands, and maps them to Hypervisor calls. Except for REQUEST_SENSE, READ and WRITE, which have their own handling, probably for optimization purposes, all other listed commands are forwarded to the same single Hypervisor call. Commands not in the table generate the above-mentioned error. Of course AACS commands were not in the list...

So I added A3, A4 and AD to the list and in the process noticed that the PS3 ATAPI layer does not support 12-byte SCSI commands, only 6-byte, 10-byte and CDDA-FRAME-RAW, so I ended up adding support for 12-byte commands, too, since that is the format of AACS commands. Three small changes and a kernel recompilation and reboot later...

The AACS commands still fail: now driver_status is 0 (ok), but host_status=7 (error) and, strangely enough, I get a zero-ed out sense buffer.

I am not sure what to make of this. The empty sense buffer seems strange and suggests that the problem is probably not with the drive, but more likely either with using 12-byte SCSI commands through the Hypervisor (which it might not support) or with the Hypervisor blocking the request explicitly and not even bothering to set its sense buffer properly. Add to that the fact that REQUEST_SENSE is treated differently in the driver than other commands (which may well account for the empty sense buffer here), and this whole problem more and more looks like a Hypervisor issue to me -- meaning, the Hypervisor probably blocks these requests intentionally, without any chance to bypass this in a Linux kernel.

The next step would be to add diagnostic code in the driver around the Hypervisor calls to try and get more meaningful error codes out of the Hypervisor than just an empty sense buffer, and to log them... I probably won't have the time to dig into this deeper any time soon though.

arnezami · 1st April 2007, 22:16

Very much thanks Boing99. Thats quite enlightning information. Thats worth an awful lot

.

It seems now though (more likely than ever) that a Hypervisor hack is needed to ever retrieve Volume IDs from a PS3.

arnezami

dito · 2nd April 2007, 00:26

IBM Cell BE Software Development Kit 2.1 is out with Linux kernel to 2.6.20, http://www6.software.ibm.com/sdfdl/1.../CellSDK21.iso

Best regards!

mb2696 · 2nd April 2007, 04:41

Quote:

Originally Posted by arnezami

For mb2696.

These questions aren't answered yet:

Other questions:

- What MKB version is on it? My MKBROM starts with 1000000C000410030000000121000034 (using WinHex). Meaning my MKB version is 1 and the length of the HRL is 34h. If any of this is different then its important.
- Does it play with any software player on any other PC system? Does your disc (not similar discs) work on standalones? Do similar discs (same title) work on your PC?
- Have you tried to demux the files to see if it contains streams or whatever? Using the original files on the disc.
- Are you absolutely sure your other discs/movies are still working? And does aacskeys give volume ids for these movies?
- Is it by any chance a recordable? Be sure.

What do you mean by "it"? Your disc or a similar disc? It is possible your disc is damaged/badly pressed somehow so the volume id cannot be retrieved. In that case if we can find somebody with the same title then he could retrieve the VUK and you might be able to decrypt it. Alternatively we could quess the volume id (tricky but maybe possible

).

The strange thing is there is a "Drive signature wrong/error" in your report. This means the drive either doesn't see the need for AACS-Auth (as in: its a recordable or non-encrypted/damaged disc) or it has revoked the Hcert (of PowerDVD 7.1). But if it has revoked it then other discs shouldn't work either anymore. Unless your drive "forgets" it (which strangely would in itself be great).

Anyway. Something doesn't seem to add up here

.

[edit] Just had an idea. Use KenD00's dumpvid (the exe is in the Release dir). It will dump the bca (Burst Cutting Area) of the disc and this should reveal half of the Volume ID

. (you don't have to do the hammering stuff btw). We will know much more when we have that.

Regards,

arnezami

PS. A Dcert starts with 01. If not then its garbadge data.
PPS. There is another possibility: they didn't want this title to be playable on a PC. Hmmm.....

-In sensitive mode, the Dcert is reported as a string of zeros (but not for other discs).

-i am not able to get a vuk by any means

-the mkb ver is the same "1000000C000410030000000121000034"

-i don't have a standalone to test my disc on. i'm getting a replacement disc to see if it's bad

-its definitely not recordable

-i'm sure my other discs are working now

-evo demux reports a vc-1, dd+, and subpicture stream when reading the feature evo

-here is the result of dumpvid:

Code:

DumpVID 0.3 by KenD00

Drive type is recognised as CDROM/DVD.

Sending SPC1 Test Unit CDB6 command..done.
Returned good status.

Reading BCA...
Reading Copyright Data Section...
Sense data, key:ASC:ASCQ: 05:30:02
Aborting process.
Dump failed from drive h:

arnezami · 2nd April 2007, 05:58

Quote:

Originally Posted by mb2696

-In sensitive mode, the Dcert is reported as a string of zeros (but not for other discs).

-i am not able to get a vuk by any means

-the mkb ver is the same "1000000C000410030000000121000034"

-i don't have a standalone to test my disc on. i'm getting a replacement disc to see if it's bad

-its definitely not recordable

-i'm sure my other discs are working now

-evo demux reports a vc-1, dd+, and subpicture stream when reading the feature evo

-here is the result of dumpvid:

Code:

DumpVID 0.3 by KenD00

Drive type is recognised as CDROM/DVD.

Sending SPC1 Test Unit CDB6 command..done.
Returned good status.

Reading BCA...
Reading Copyright Data Section...
Sense data, key:ASC:ASCQ: 05:30:02
Aborting process.
Dump failed from drive h:

Ok. No new MKB version and no different Host Revocation List means nothing is revoked here. The files are not (completely) corrupted since demuxer still sees streams (i'm not sure if this means its not encrypted, you would have to try to play any of the demuxed files).

Did the dumpvid create a bca.bin file btw? And if so is there anything in it?

It sounds to me like this disc is either damaged or badly made or was created in such a way it won't play on a PC based system. Or for some reason you drive can't handle it.

Anyway I will be interested to know if the replacement works.

Regards,

arnezami

HyperHacker · 2nd April 2007, 07:18

Quote:

Originally Posted by mb2696

its definitely not recordable[/CODE]

Are you sure? It could be a fake or something.

mb2696 · 2nd April 2007, 14:54

Quote:

Originally Posted by HyperHacker

Are you sure? It could be a fake or something.

i bought it from amazon.com, i doubt it

it also has a barcode on the inner hub

mb2696 · 2nd April 2007, 14:58

Quote:

Originally Posted by arnezami

...

Did the dumpvid create a bca.bin file btw? And if so is there anything in it?

...

Here's the entire contents of the bca.bin:

Code:

10011104481200001002100840000115
20072036000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
000000000000000000000000

30th March 2007, 02:21	#85 \| Link
dirio49 JuSt a PoWer uSEr Join Date: Mar 2005 Location: None of your Business Posts: 288	I think if they change the key, then a new version of the tool will have to be compiled with the new keys. But first we have to find the new key __________________ Birthdays are good. Statistics show that the people who have the most live the longest.

1st April 2007, 08:28	#92 \| Link
Jedi_Vader20 Registered User Join Date: May 2004 Location: Brisbane, Australia Posts: 4	Running Yellow Dog 5.0 PS3 on my PAL PlayStation3, Firmware 1.60. Under both kernel 2.6.16 and the same with the UDF 2.50 patch, I get the following output when attempting to run the most recent posted aacstiny in the thread: Code: [root@playstation3 aacstiny]# ./aacstiny /dev/cdrom Sending report key command: A40000000000000200003F00 Invalidation AGID 0. Result: 0 Sending report key command: A40000000000000200007F00 Invalidation AGID 1. Result: 0 Sending report key command: A4000000000000020000BF00 Invalidation AGID 2. Result: 0 Sending report key command: A4000000000000020000FF00 Invalidation AGID 3. Result: 0 Sending report key command: A40000000000000200080000 Returning buffer from report agid command: 0FF6F2400FEC0F40 All AGIDs in use, aborting. AGID: -1 aacstiny compiled with no warnings or errors. The movie I'm attempting this against is xXx, PAL release Blu-Ray. __________________ >.> <.< shrug Last edited by Jedi_Vader20; 1st April 2007 at 08:31. Reason: Forgot information.*

2nd April 2007, 00:26	#95 \| Link
dito Registered User Join Date: Jun 2005 Posts: 12	newer linux kernel for PS3 IBM Cell BE Software Development Kit 2.1 is out with Linux kernel to 2.6.20, http://www6.software.ibm.com/sdfdl/1.../CellSDK21.iso Best regards!

29th March 2007, 04:58	#81 \| Link
mb2696 Registered User Join Date: Jan 2007 Posts: 39	what does it mean if the volume id is reported as a string of zeroes? i've been having trouble getting "National Geographic - Relentless Enemies" to work. any ideas? thanks

29th March 2007, 21:44	#84 \| Link
arcsyn Registered User Join Date: Feb 2007 Posts: 1	Forgive me for being an idiot, but will this tool still work if there is a new set of AACS keys coming out next much? Will this tool still give us the information needed to make backups, or does this program rely on something they can revoke?

30th March 2007, 21:36	#87 \| Link
mb2696 Registered User Join Date: Jan 2007 Posts: 39	so is this a result of a key revoke?

1st April 2007, 21:53	#93 \| Link
Boing99 Registered User Join Date: Mar 2007 Posts: 6	I ran some very similar tests on my PS3 a few weeks ago and can comment on some of the results posted here. First some preliminaries: 2.6.16 is the correct kernel to use, as it contains Sony's own drivers and modifications. 2.6.20 is an (incomplete) effort by the regular kernel maintainers to merge those changes back into the regular kernel source tree and integrate them with existing drivers. That effort is still work in progress and the kernel does not boot on PS3 yet. The UDF-2.5 patch is completely unrelated to any PS3 changes or drivers and not needed if all you want to do is send SCSI commands to the drive (to extract volume ids etc.). It IS needed if you want to mount a Blu-ray volume to get access to the files on it, for decryption. Without the patch you can simply send SCSI commands directly to the underlying device. For most setups (including PS3) that is "/dev/sr0". Now about my actual tests, run on Gentoo (not YDL), using a 64-bit kernel and userland: I used SG_IO instead of CDROM_SEND_PACKET in the ioctl. I am not sure this made a difference, but it seems to me that SG_IO is a lower-level request closer to the ATAPI layer, with better diagnostics and it may arguably have a better chance of not having its data modified or misinterpreted by the CD-ROM driver layer. The first thing I tried is sending ordinary SCSI commands to the drive to ensure that the ATAPI transport through the Hypervisor works correctly. INQUIRY works fine and returns meaningful results, as does GET_CONFIGURATION, so we know the ATAPI layer works. This also very likely rules out any problems regarding sync vs. async I/O, timing, buffer management, Hypervisor API access etc. Interesting info here: The "Vendor info" and "Identification" fields in INQUIRY return "PS-SYSTEM <serial number>". I think this is fairly unusual because typically, even for standalones, those fields report the OEM manufacturer of the drive. For example the X-Box-360 HD drive simply returns "TOSHIBA <something>". I might have expected "SONY" here, but not "PS-SYSTEM". The "PS-SYSTEM" response to me suggests that either Sony used a special drive built in-house exclusively for the PS3, without any intent to ever use it in standalone Blu-ray players (probably unlikely), or that the Hypervisor intercepted INQUIRY and responded on behalf of the drive. If it is the latter then it's bad news because it would suggest that the Hypervisor does filter SCSI commands one by one, which would explain the problems with AACS commands. Next I tried the usual AACS SCSI commands, and all of them returned driver_status=7 (hard error) and sense_key=5 (ILLEGAL_REQUEST). That seemed strange to me at first (the part about this being reported in driver_status instead of host_status), because the driver is supposed to handle different SCSI commands transparently. The explanation is in the Sony driver in the kernel sources. ps3pf_storage.c contains a table of supported SCSI commands, and maps them to Hypervisor calls. Except for REQUEST_SENSE, READ and WRITE, which have their own handling, probably for optimization purposes, all other listed commands are forwarded to the same single Hypervisor call. Commands not in the table generate the above-mentioned error. Of course AACS commands were not in the list... So I added A3, A4 and AD to the list and in the process noticed that the PS3 ATAPI layer does not support 12-byte SCSI commands, only 6-byte, 10-byte and CDDA-FRAME-RAW, so I ended up adding support for 12-byte commands, too, since that is the format of AACS commands. Three small changes and a kernel recompilation and reboot later... The AACS commands still fail: now driver_status is 0 (ok), but host_status=7 (error) and, strangely enough, I get a zero-ed out sense buffer. I am not sure what to make of this. The empty sense buffer seems strange and suggests that the problem is probably not with the drive, but more likely either with using 12-byte SCSI commands through the Hypervisor (which it might not support) or with the Hypervisor blocking the request explicitly and not even bothering to set its sense buffer properly. Add to that the fact that REQUEST_SENSE is treated differently in the driver than other commands (which may well account for the empty sense buffer here), and this whole problem more and more looks like a Hypervisor issue to me -- meaning, the Hypervisor probably blocks these requests intentionally, without any chance to bypass this in a Linux kernel. The next step would be to add diagnostic code in the driver around the Hypervisor calls to try and get more meaningful error codes out of the Hypervisor than just an empty sense buffer, and to log them... I probably won't have the time to dig into this deeper any time soon though.

1st April 2007, 22:16	#94 \| Link
arnezami Registered User Join Date: Sep 2006 Posts: 390	Very much thanks Boing99. Thats quite enlightning information. Thats worth an awful lot . It seems now though (more likely than ever) that a Hypervisor hack is needed to ever retrieve Volume IDs from a PS3. arnezami