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

[arnezami]

MODERATOR NOTE: arnezami is apparently no longer active in maintaining this software. New versions can be found here:

http://forum.doom9.org/showthread.php?p=1186415#post1186415

Thank you, arnezami, for your pioneering work!

Original contents of this post follow...

----------------------------------------

Finally.

Here is my program that gives a list of all keys used for aacs decryption for one disc. Currently I'm too tired to go into this deeply but I need people to test this. Especially the Blu-ray owners: I have no Blu-ray burner/player so I'm "flying blind" when it comes to programming stuff for Blu-ray. I think I've read the Blu-ray specs right and hope it all works. But it really has to be tested.

Anyway. As promised the program itself: aacskeys.exe v0.2.5 (http://www.sendspace.com/file/3e8bzt) (fixed for Blu-ray now :))

Go here for the new v0.2.8 version (http://forum.doom9.org/showthread.php?p=1018060#post1018060).

Its still in the early stages of development so there are probably some bugs in it.

Here is a screenshot (King Kong):

http://img110.imageshack.us/img110/4728/aacskeyspicfu1.jpg

Thats gotta put a smile on your face :D :D

Keep in mind there are three types of views now: normal (n), verbose (v) and sensitive (s). But you'll figure it out ;).

When I iron some things out I will release the source (of course) but this will take at least a couple of days (maybe next week). There are still a couple of things to do (Hk, VID MAC, BK, TKFMAC, Device Keys etc). But I want it to work first and there is where you guys come in :).

So if you can test if it works please do. Any feedback is welcome.

Thanks already :thanks:

Regards,

arnezami

[Pelican9]

It works.
Or these are burned-in values... :)
Processing key: 09F911029D74E35BD84156C5635688C0
Encrypted C-value: 6D02CAC67B1A7E95C216EFD4C92809CF
Corresponding uv: 00000001

Decrypted C-value: 074E1FC88FB9B780A225CAA23BC3DB57
Media key: 074E1FC88FB9B780A225CAA23BC3DB56

Encrypted verification data: 87B8A2B7C10B9FADF8C4361E238659E5
Decr verif data should be: 0123456789ABCDEF
Decrypted verification data: 0123456789ABCDEF0A9BE086140F5A60

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): ########################################
########################################

Bus key (BK): ################################

Volume ID: 40000918200608410020202020200000
Voluem ID MAC: ################################

Volume Unique Key: 802F78B1B20D1183638D84E1A96D6EDD
Title Key File MAC: 399FE6A364D623541418E3805D1ED790

Encrypted Title Key 1: 30F8DC87B137A1607C7F2A731FF7B6BC
Encrypted Title Key 2: B5183BDC3335A1EBC8E517B6611A1CBA
Encrypted Title Key 3: A625BDC656E9D5EDE040A07B9FB8D7B1
Encrypted Title Key 4: F5ACB8900A639E85B4133933E74A92E7
Encrypted Title Key 5: 635B440099BFAB97911ABBBC4B1F25A7
Encrypted Title Key 6: 9EB5C32E0AFB0B3A4A906CB360CE57A0
Encrypted Title Key 7: 21258E976BECFF0090E371058DDDE695
Encrypted Title Key 8: E49D4100A52DB01F7F605768DB4000F2

Decrypted Title Key 1: 7D743D3C92652CC16B66D9CB87F6D132
Decrypted Title Key 2: 70B71C6E767E213AEB7456985BAAD8A4
Decrypted Title Key 3: 4BC362995030035312A5B6030D76C817
Decrypted Title Key 4: A019B5101E904A700A44F056B7EB3579
Decrypted Title Key 5: 896AB02D3D77554EABCE3CCE931DA39D
Decrypted Title Key 6: BEC07637E9C4EFA1F70FED6891DB277B
Decrypted Title Key 7: 1DC0D276F2C5B9FCFDE1414C5002BAAB
Decrypted Title Key 8: BC7EB577D1936818AEB9241F024DE681

[fakker]

confirmed working....

Batman Begins UK HD-DVD - 15/09/06
Here is the output given after using verbose mode:
C:\>aacskeys d v
Processing key: 09F911029D74E35BD84156C5635688C0
Encrypted C-value: C8ADC9F88E38FB152FCD5E68291C4C60
Corresponding uv: 00000001

Decrypted C-value: B0A84A4838821346834751E1E9D33B44
Media key: B0A84A4838821346834751E1E9D33B45

Encrypted verification data: 8D960C0952C0A6260AD3FDD236DF015B
Decr verif data should be: 0123456789ABCDEF
Decrypted verification data: 0123456789ABCDEF143F000821C02F93

AGID: 00

Host certificate from: Power DVD 7.1
Host certificate (Hcert): 0200005CFFFF0000000C00006E3DEB67
FAA8E30878767BA6EB2A9B415385AD11
31E9A5DD2AB808B364FF15885BAC4909
F8029FCF76F688A54FBDA03F6D9332EF
12DA85880A4D9CBB79D8602E
Host Private Key (Hpriv): 4737676058D7029452514F0AB186DC4C
Host Nonce (Hn): 2923BE84E16CD6AE529049F1F1BBE9EB

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

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

Host key (Hk): 00000000000000000000000000000000
Host key point (Hv): 8E9B0E3CF41FA7DA3A829F604122EA4E
7570CE0BB9061A66FAF92C4A7D98ACC1
Host key signature (Hsig): ################################
################################

Bus key (BK): ################################

Volume ID: 400009061209091557474844564D0000
Voluem ID MAC: ################################

Volume Unique Key: F66308D9151653672AB7D75A01DC3F7E
Title Key File MAC: 40746D614A37CE2EAC331A5939D3E238

Encrypted Title Key 1: A51DACA264BC206442AD767237E02130
Encrypted Title Key 2: A57046224AE96E17D7F2F8878E914B0A
Encrypted Title Key 3: BD21A78EADF40081516133E925066C19
Encrypted Title Key 4: 34970BF350A7342F579C7187365D3771
Encrypted Title Key 5: 872E9B67DA39B10BF8C10796F82A394D

Decrypted Title Key 1: 2D9CF93FA5F221C2135DDB06AE4F3EA5
Decrypted Title Key 2: 8B6922BEBDE8B48A25021E75F1B7B597
Decrypted Title Key 3: 4F32342FB377E0FE8A9C1166A51F3B8E
Decrypted Title Key 4: F3419DE7F77AC83E0230A3E2A7833059
Decrypted Title Key 5: 04AF9217B59BA527663CD968BDD701DB

Sorry if it looks a mess... Either way there were 64 encrypted and decrypted keys... I will not paste all of those as we get the drift. :eek:

Again, as many have already said - thanks a lot for all of your efforts, and in releasing this long awaited tool. :thanks:

[mrazzido]

i try it on bluray , House of Wax EUR / GER


when i read the keys from memory ( windvd )

i get these



CPS Unit Key : 9329A4976FE297AF4475BDAD13119A4F

Volume Unique Key : 83AD82670F99F9F9A64D05B0501CF20D




with your tool i get

http://img474.imageshack.us/img474/7059/hghta3.png

[mrazzido]

second test

on click EUR / GER


winddvd memory



CPS Unit Key : 05BAFE2DD84C0781C6CE09714726FED9

Volume Unique Key : 5928C17E732E17FCC896401715556D07



tool

http://img393.imageshack.us/img393/5159/vsvsvms3.png

[arnezami]

second test

on click EUR / GER


winddvd memory



CPS Unit Key : 05BAFE2DD84C0781C6CE09714726FED9

Volume Unique Key : 5928C17E732E17FCC896401715556D07



tool

Ok. There is clearly a problem with the retrieval of the Volume ID here (its all 0's) . Which is also the hardest to test for me.

Can you tell me if any of the sensitive data: Dv/Dsig/Dn/Dcert/VID MAC are also all 0's (don't post them just tell if some of them they are all 0's and if so which ones)

And are these file names on your disc(s):

G:\AACS\Unit_Key_RO.inf
G:\AACS\MKB_RO.inf

Because it seems to have problems opening the Title Key file (error on top).

I'm pretty sure the MKB file is working since the Media Key is verified.

[mrazzido]

yeah these files on the disc.


http://img183.imageshack.us/img183/1518/vsvsvsvsbm5.png

[arnezami]

Ah. I think I see the problem.

Try this one: aacskeys.exe (http://www.sendspace.com/file/8ltp8b)

[mrazzido]

works

test it on click


http://www.directupload.net/images/070311/rXH8PKd3.jpg

[arnezami]

works

test it on click




Perfect :D

Now it works for BluRay too.

[mrazzido]

second test of how / ger/eur

http://www.directupload.net/images/070312/zdJK8kZo.jpg






great work :-)

[bourke]

How do you find the 'hash' value used in programs like BackupHDDVD? Is that something that could be added to the output?

[mrazzido]

sometimes ago i burned a CRYPTED movie on BD-RE

when i try the tool

C:\Dokumente und Einstellungen\Administrator>aacskeys g n
Processing key: 09F911029D74E35BD84156C5635688C0
Media key: 853EC6162030F7F7EF1B61265BE30A68
Volume ID: 00000000000000000000000000000000
Volume Unique Key: 378A39F68C5FDABE94D0621BDBC4481D
Decrypted Unit Key 1: 8AF9B2644339E90931DA68DB96AA06AA

[arnezami]

How do you find the 'hash' value used in programs like BackupHDDVD? Is that something that could be added to the output?

Yeah. Still have to do that. :)

Very practical indeed.

[arnezami]

i sometimes ago i burned a CRYPTED movie on BD-RE

when i try the tool

Interesting. Volume ID is all 0's with rewritables. That sort of makes sense though. But does it give a Volume ID MAC (when doing the sensitive view). Or is that one all 0's too? If it all 0's then Players can probably not be fooled by putting encrypted movies on rewritables (even after re-encrypting the title keys). But if the Volume ID MAC is anything other than 0's then its going to be interesting to see what we can do with rewritables...

[bourke]

No hurry either - we all appreciate this (whole AACS caper) must have used up a lot of your time already :-)

I'm actually more waiting on the lads doing those evo demux/authoring tools (which are coming nicely) - then if they include your code they can have a very nice 1080p to 720p (~8Gb) conversion tool indeed :-)

[mrazzido]

Interesting. But does it give a Volume ID MAC (when doing the sensitive view). Or is that one all 0's too? If it all 0's then Players can probably not be fooled by putting encrypted movies on rewritables (even after re-encrypting the title keys). But if the Volume ID MAC is anything other than 0's then its going to be interesting to see what we can do with rewritables...





i try all 0's :-/

[blutach]

@arnezami

A huge thank you for this. Thread stuck.

Regards

[xyz987]

Excellent!!!

:thanks:

[vudoodoodoo]

Nice. Thank you!

[woodspire]

Please compile your program in Java so I can test it on my PS3 linux !

Still can't compile properly the iscsi application to mount the blu-ray drive in windows, but it's coming ...

[blutach]

@woodspire - I have had enough of people ignoring the policy on requests. Strike issued.

Regards

[HyperHacker]

Excellent work, I can't test it myself but it looks great. Just thinking though you should add an ASCII view of the volume ID, as those seem to be ASCII fairly often. :)

[guile]

GREAT WORK!!!! I have tested on SEVERAL BLu Ray discs and it is working on all of them (at least producing what appears to be working keys). I can't confirm the keys are valid without title hash (unless I'm missing something).

[Electrox3d]

GREAT WORK!!!! I have tested on SEVERAL BLu Ray discs and it is working on all of them (at least producing what appears to be working keys). I can't confirm the keys are valid without title hash (unless I'm missing something).

Yeah, thats the final question I have too... where's the Title hash? Is this not possible to get via software?

If this is a program revealing all AACS Key's needed to decrypt, does that mean it is hidden somewhere in the output?

Thanks, great job!

[KenD00]

The title hash is the SHA-1 hash value from the file AACS\CPSUnit00001.cci off the disc. There are many programs which can calculate a SHA-1 hash, e.g. HexWorkshop or WinHEX. Btw., this identifier is not very well chosen, there are already titles which have the same title hash. This is because this file does not contain information that is unique per title, it contains Copyright Control Information. If two discs have the same number of titles and use the same copy-rights (things like Image Constraint Token and so on) they will produce the same title hash.

Therefor, when BluRay support is included into DumpHD it will use the SHA-1 hash of the file AACS\Unit_Key_RO.inf as title hash.

:rolleyes:

[arnezami]

The title hash is the SHA-1 hash value from the file AACS\CPSUnit00001.cci off the disc. There are many programs which can calculate a SHA-1 hash, e.g. HexWorkshop or WinHEX. Btw., this identifier is not very well chosen, there are already titles which have the same title hash. This is because this file does not contain information that is unique per title, it contains Copyright Control Information. If two discs have the same number of titles and use the same copy-rights (things like Image Constraint Token and so on) they will produce the same title hash.

Therefor, when BluRay support is included into DumpHD it will use the SHA-1 hash of the file AACS\Unit_Key_RO.inf as title hash.

:rolleyes:
That sounds like a really good idea. I always assumed Muslix64 hashed the Unit_Key_RO.inf. But looking at it more closely its pretty obvious now we get duplicate hash values (there isn't much info in the cci info to begin with).

Theoretically the Unit Key files could be the same for some discs aswell. But I don't know if they would actually do that (different vuks with the same unit key file lead to different unit keys, so they could do this since there is no tkfmac).

Anyway. If you're going to do this then I will do the same with my program aacskeys: hashing the title key file for HD DVDs and hashing the Unit Key file for blu-ray discs. So our programs will be compatible that way. :)

What should we do if there are multiple title key file btw? (for hd dvd only I believe)

Is there a specific file format you're going to use? Or plain pipe separated? I thought about using ";" or "//" or something as comment markers at the beginning of each comment line (at the beginning of the file). Maybe also column names. I like to keep it really basic and simple though ;).

Regards,

arnezami

[lightshadow]

First of all, fantastic work to all that have contributed to make this program happen =)

Regaring the source, I can understand that you want to wait a while before releasing it. But the problem is, if Doom9 gets closed in the meantime, the source is not released =(

So what if you made a rar/gpg encrypted archive of the source available, and when you feel it is ready we get the passphrase? =)

The advantage is that if Doom9 should get closed, it is easier to make a passphrase slip, so someone can make a Slashdot story, that THE passphrase have slipped and it is ####, rather than having to release the soruce. =)

Another advantage is, that if you tell the passphrase to a few trusted secret people, and you should go silent, the passphrase is still out there, and you haven't released it after you have gone silent. Someone else have, and it could be anybody. Who knows who you can trust these days? =)

Ps. It would be fun if the passphrase was 4737676058d7029452514f0ab186dc4cca8c578f . Just of the irony =)

[arnezami]

First of all, fantastic work to all that have contributed to make this program happen =)

Regaring the source, I can understand that you want to wait a while before releasing it. But the problem is, if Doom9 gets closed in the meantime, the source is not released =(

So what if you made a rar/gpg encrypted archive of the source available, and when you feel it is ready we get the passphrase? =)

The advantage is that if Doom9 should get closed, it is easier to make a passphrase slip, so someone can make a Slashdot story, that THE passphrase have slipped and it is ####, rather than having to release the soruce. =)

Another advantage is, that if you tell the passphrase to a few trusted secret people, and you should go silent, the passphrase is still out there, and you haven't released it after you have gone silent. Someone else have, and it could be anybody. Who knows who you can trust these days? =)

Ps. It would be fun if the passphrase was 4737676058d7029452514f0ab186dc4cca8c578f . Just of the irony =)

Well ok then. For me not yet releasing the source is not about being secretive but about being proper. What I've learned about open source is that its not just about releasing the source but making it understandable and easely useable and giving credit to all that should be given credit to. I haven't had the time to do that properly. But if you instist and really want it (the raw version that is) I will release the source of the current version.

Here is is: source (http://www.sendspace.com/file/4x8imn). You need openssl for this to work.

This is not an "official" release. This is just for those who want to play around with it.

Regards,

arnezami

[nincollector]

does this only work for power dvd 7.1 or will it work with all software players i.e 7.2 and above?

[mrazzido]

the info is that the key is from power dvd 7.1

you can decrypt the movie with backuphddvd / bluray

and play fine with windvd or power dvd 6 hd or bd edition

[jh87]

I tried it on a bluray iso copied from PS3. I got the processing key, which is the one we all know. I also got the media key but then the program aborted with message saying "all AGIDs in use".
Then I tried it on the PS3 linux with the original movie for the above ISO, then I got the "permission denied" message.
So I guess it is no go if I don't have a BD drive connected to my PC, right? Sorry for the newb question.

[arnezami]

Could somebody try to compile this on linux (PS3 or PC).

aacskeys multi platform source (http://www.sendspace.com/file/7rvzff). (linux + windows)

This version should compile both on windows as on linux. But I haven't tested it yet on linux. Please keep me informed of any problems and/or solutions.

The instructions are almost the the same as for aacsauth:

INSTALL

You need openssl 0.9.8
Compile with gcc -o aacskeys -lcrypto ioctl.c ecdsa.c mmc.c aes.c aacsauth.c

There may be some warnings. But hopefully it compiles for linux now (not tested yet).

USAGE

Type something like ./aacskeys /dev/scd0 v
/dev/scd0 is the device file of your drive

Regards,

arnezami

PS. The PS3 uses a hypervisor which might prevent it from getting the volume id at all. And mounted ISOs can't handle the mmc commands properly.
PPS. The old source should't work on linux unless adapted of course :).

[ebsi]

This one compiles now on linux. Still untested on PS3.
http://www.sendspace.com/file/x9nmjq

[KenD00]

Theoretically the Unit Key files could be the same for some discs aswell. But I don't know if they would actually do that (different vuks with the same unit key file lead to different unit keys, so they could do this since there is no tkfmac).

Hmm, thats a point that i have missed. Since title keys are random, this could happen by chance, but how big is this probability? Maybe a second file should be used in addition to create the title hash? I'm open for ideas.

What should we do if there are multiple title key file btw? (for hd dvd only I believe)

For HD-DVD Advanced Content the VTKF000.AACS is still a good choice, for HD-DVD Standard Content i use the only present TKF VTKF.AACS.

Is there a specific file format you're going to use?

For now, the database format is not nice, but sufficient enough. For BluRay i will only change the key entries to be consistent with the HD-DVD format (i will store both keys in one db), that is adding a key type flag (V = VUK, U = CPS Unit Key) and numbering the CPS Unit Keys like the Title Keys. When its time for Sequence Keys i think we should think about a new format, the current one can only store one key type per entry, for Sequence Keys you would need two lines, with redundancy of the movie name and so on, thats not so nice.

:rolleyes:

[arnezami]

This one compiles now on linux. Still untested on PS3.
http://www.sendspace.com/file/x9nmjq

Thanks for helping to get it to work on linux. Have you tested it on PC (running linux)? HD DVD or Blu-ray? Or did you only compile it.

Also you added this to the aacskeys.h:

#if !defined(linux)
int send_cmd(drive_handle h, unsigned char *cmd, unsigned char *buf, size_t send, size_t recv);
#endif


So the definition of send_cmd will not be available for linux. But how can this work since mmc.c needs it? Did it give an error and if so which one?

Thanks.

People own a PS3 could try to compile it on their PS3 and see what happens... (i'm quite curious) :)

Regards,

arnezami

[arnezami]

Hmm, thats a point that i have missed. Since title keys are random, this could happen by chance, but how big is this probability? Maybe a second file should be used in addition to create the title hash? I'm open for ideas.
The chance of this happening by pure chance is zero. They really would have to do this intentionally (but it would be a little silly for them to do this). So (for now) I think it would be a good idea to use the Unit Key file: its also equivalent to the Title Key file (for HD DVD). So it would all make more sense.

For HD-DVD Advanced Content the VTKF000.AACS is still a good choice, for HD-DVD Standard Content i use the only present TKF VTKF.AACS.

Yeah. That should work fine.

For now, the database format is not nice, but sufficient enough. For BluRay i will only change the key entries to be consistent with the HD-DVD format (i will store both keys in one db), that is adding a key type flag (V = VUK, U = CPS Unit Key) and numbering the CPS Unit Keys like the Title Keys.

Sounds good. Especially the V/U differentiation. Blu-rays are bound to get more Unit keys per disc.

When its time for Sequence Keys i think we should think about a new format, the current one can only store one key type per entry, for Sequence Keys you would need two lines, with redundancy of the movie name and so on, thats not so nice.
I'm probably also creating my own kinds of files for Device/Processing keys and Host Certificates/Private Keys (probably using the some kind of format). Which would also include corresponding uv values and MKB versions and Software player name+versions. But your program will not need these files/keys (until that is you implement the mkb processing and aacsauth stuff aswell).

Regards,

arnezami

[00dwan]

People own a PS3 could try to compile it on their PS3 and see what happens... (i'm quite curious) :)

Regards,

arnezami

I have a ps3 and want to test it (actually I need it to work for something I'm trying to do: http://forum.doom9.org/showthread.php?t=123355), but I'm a linux n00b so I would need very clear instructions.

[fakker]

I have a ps3 and want to test it (actually I need it to work for something I'm trying to do: http://forum.doom9.org/showthread.php?t=123355), but I'm a linux n00b so I would need very clear instructions.

INSTALL

You need openssl 0.9.8
Compile with gcc -o aacskeys -lcrypto ioctl.c ecdsa.c mmc.c aes.c aacsauth.c

There may be some warnings. But hopefully it compiles for linux now (not tested yet).

USAGE

Type something like ./aacskeys /dev/scd0 v
/dev/scd0 is the device file of your drive

[dirio49]

here I tried in gentoo, and it compiles,But cannot test no HDDVd or BlUray disk nor drives :)

gcc -o aacskeys -lcrypto ioctl.c ecdsa.c mmc.c aes.c aacskeys.c
ecdsa.c: In function 'aacs_set_cert':
ecdsa.c:29: warning: initialization discards qualifiers from pointer target type
ecdsa.c: In function 'aacs_sign':
ecdsa.c:67: warning: comparison between pointer and integer

[woodspire]

Done under PS3 with Yellow Dog Linux 5. I have modified the ioctl.c file to match both send_cmd header. (I add unsigned to the linux header function). So now, I don't get the error between ioctl.c and aacskeys.h

But still get these errors. Seems that openssl can't get correctly installed. Don't know why. openssl ppc version (not ppc64). It seems it install itself in /usr/local/ssl/include instead of the default path.

If I run openssl, it says it's version 0.9.8a 11 october 2005
But I compiled 0.9.8e

Please someone with C compilation knowledge (I so much love perl, so such compilation problem) compile a binary for linux-ppc or linux-ppc64. Staticly linked would be better I think.

Here is the output from the gcc command:

gcc -o aacskeys -lcrypto -I/usr/local/ssl/include ioctl.c ecdsa.c mmc.c aes.c aacskeys.c
ecdsa.c: In function ‘aacs_set_cert’:
ecdsa.c:29: warning: initialization discards qualifiers from pointer target type
ecdsa.c: In function ‘aacs_sign’:
ecdsa.c:67: warning: comparison between pointer and integer
aes.c:62:2: warning: no newline at end of file
aacskeys.c: In function ‘main’:
aacskeys.c:555: warning: comparison is always false due to limited range of data type
/tmp/ccIwRoTT.o: In function `aacs_key':
ecdsa.c:(.text+0x14): undefined reference to `EC_KEY_new'
ecdsa.c:(.text+0x4c): undefined reference to `EC_KEY_set_group'
ecdsa.c:(.text+0x6c): undefined reference to `EC_KEY_free'
/tmp/ccIwRoTT.o: In function `aacs_set_cert':
ecdsa.c:(.text+0xd0): undefined reference to `EC_KEY_get0_group'
ecdsa.c:(.text+0x190): undefined reference to `EC_POINT_new'
ecdsa.c:(.text+0x1c8): undefined reference to `EC_POINT_set_affine_coordinates_GFp'
ecdsa.c:(.text+0x1fc): undefined reference to `EC_KEY_set_public_key'
/tmp/ccIwRoTT.o: In function `aacs_sign':
ecdsa.c:(.text+0x2cc): undefined reference to `EC_KEY_set_private_key'
ecdsa.c:(.text+0x2dc): undefined reference to `EVP_ecdsa'
ecdsa.c:(.text+0x34c): undefined reference to `ECDSA_do_sign'
ecdsa.c:(.text+0x3c4): undefined reference to `ECDSA_SIG_free'
ecdsa.c:(.text+0x3d8): undefined reference to `EC_KEY_free'
/tmp/ccIwRoTT.o: In function `aacs_verify':
ecdsa.c:(.text+0x458): undefined reference to `EVP_ecdsa'
ecdsa.c:(.text+0x4b4): undefined reference to `ECDSA_SIG_new'
ecdsa.c:(.text+0x534): undefined reference to `ECDSA_do_verify'
ecdsa.c:(.text+0x550): undefined reference to `ECDSA_SIG_free'
ecdsa.c:(.text+0x564): undefined reference to `EC_KEY_free'
/tmp/ccIwRoTT.o: In function `aacs_group':
ecdsa.c:(.text+0x828): undefined reference to `EC_GROUP_new_curve_GFp'
ecdsa.c:(.text+0x864): undefined reference to `EC_POINT_new'
ecdsa.c:(.text+0x918): undefined reference to `EC_POINT_set_affine_coordinates_GF2m'
ecdsa.c:(.text+0x9bc): undefined reference to `EC_GROUP_set_generator'
ecdsa.c:(.text+0xa04): undefined reference to `EC_GROUP_free'
ecdsa.c:(.text+0xa20): undefined reference to `EC_POINT_free'
collect2: ld returned 1 exit status

[00dwan]

I couldn't get aacskeys working on ps3 linux. I had similar errors as the ones stated above.

I just tried running aacskeys from windows xp(qemu) on the ps3 and I get the "All AGIDs are in use, aborting." message. Same thing happened when I used a daemon-tools mounted iso on my normal windows xp computer.

[woodspire]

If someone could compile and correctly execute the iscsi-target on the ps3, we could access the blu-ray from windows with the iscsi-initiator:

iscsi-initiator: http://www.microsoft.com/downloads/details.aspx?FamilyID=12cb3c1a-15d6-4585-b385-befd1319f825&DisplayLang=en

iscsi-target: http://iscsitarget.sourceforge.net/

Watch out, I think openssl needs to be compile in ppc64.

For my part, iscsi-target compiles correctly. It's when I run it that the're an error in /var/log/messages

For all the linux guru, please help us!

[lightshadow]

If I run openssl, it says it's version 0.9.8a 11 october 2005
But I compiled 0.9.8e

This sounds like the openssl that ships with your distribution is located in /usr/ where your compiled is located in /usr/local

For the rpm installed openssl you can check that by
rpm -qa|grep -i openssl|xargs rpm -ql

For the openssl you compiled, try check the --PREFIX by
./configure --help
in your unpacked openssl directory, and see what the PREFIX variable is set to. Changing it to /usr will replace your rpm installed openssl.

[woodspire]

recompile openssl with --prefix=/usr

Now the default openssl is 0.9.8e

Remove the -I/usr/local/ssl/include part

But still same error. Check in the /usr/include/openssl/evp.h and the function EVP_ecdsa is well defined. Why can't the compiler find it ?

[arnezami]

Ok. It looks like ebsi has managed to compile and run aacskeys on the PS3. It looks like his Dv/Dsig values are all zero. As far as I can see he has also added a mount point variable (to make a distinction between the device file where mmc commands are send to and the mountpoint to find the MKB/UnitKey files I guess). So my source probably requires some more tweaking for linux.

Can somebody else confirm this? I wonder if Dcert is returned by the drive (don't post it we just need to know if its not all 0's).

[ebsi]

http://www.sendspace.com/file/d3aava
In the archive you also find a PS3 linux binary.
It's compiled on Ubuntu Edgy for PPC.
For mounting the a BD disk this patch :
http://sourceforge.net/tracker/index.php?func=detail&aid=1671912&group_id=295&atid=300295
is needed.

To use it you must mount the BD disk. For example:
mount /dev/scd0 /media/cdrom
./aacskeys /dev/scd0 /media/cdrom s

Dv, Disg, HK and BK are empty.

[arnezami]

http://www.sendspace.com/file/d3aava
In the archive you also find a PS3 linux binary.
It's compiled on Ubuntu Edgy for PPC.
For mounting the a BD disk this patch :
http://sourceforge.net/tracker/index.php?func=detail&aid=1671912&group_id=295&atid=300295
is needed.

To use it you must mount the BD disk. For example:
mount /dev/scd0 /media/cdrom
./aacskeys /dev/scd0 /media/cdrom s

Dv, Disg, HK and BK are empty.

Ok. I now understand that you do get the Dcert and Dn which means the mmc command are working on the PS3.

There are some things we can do to see what is the problem with retrieving the Dsig and Dv.

(1) There is an (small) error in the report key and send key command.

This is what report_key should look like:

int report_key(drive_handle h, unsigned char * buffer, char agid, char key_format, short length, unsigned char bluray) {
unsigned char cmd[CDROM_PACKET_SIZE];
memset(cmd, 0, CDROM_PACKET_SIZE);

cmd[0] = REPORT_KEY;
cmd[1] = 0;
cmd[7] = 0x02;
cmd[8] = (length>>8)&0xff;
cmd[9] = (length)&0xff;
cmd[10] = agid<<6|(key_format&0x3f);

memset(buf, 0, length);

if(send_cmd(h, cmd, buf, 0, length) >= 0)
return 0;
else
return -1;
}


This is what send_key should look like:

int send_key(drive_handle h, unsigned char *buffer, char agid, char key_format, short length, unsigned char bluray) {
unsigned char cmd[CDROM_PACKET_SIZE];
memset(cmd, 0, CDROM_PACKET_SIZE);

cmd[0] = SEND_KEY;
cmd[1] = 0;
cmd[7] = 0x02;
cmd[8] = (length>>8)&0xff;
cmd[9] = (length)&0xff;
cmd[10] = agid<<6|(key_format&0x3f);

if(send_cmd(h, cmd, buf, length, 0) >= 0)
return 0;
else
return -1;
}


The read_vid should stay the same (with the bluray var).

(2) There could be a problem with timing or the agid being invalid (after the drive cert has been recieved).

This is unlikely but we could check if the agid is still in use after retrieving the drive cert. We do this by trying to obtain an agid just after we have done the report_drive_cert_chal. If its -1 then the agid is still in use (as it should be). But if its 0 then the agid has been dropped by the drive. Alternatively we could try to wait a little before asking the drive for the Dv/Dsig (or ask many times).

(3) We should try to compile and run this program on a PC linux system.

When using either a Bluray drive or a HD DVD drive on a linux PC (not the PS3) we can see what works. If this is working (on a PC) then the PS3 hypervisor is probably giving us trouble (or the distro/processor whatever). If it doesn't work for linux PC (or maybe only bluray) then we have to solve that first.

(4) We should make sure we get better error messages

When the report_drive_key is executed it gives back all 0's. But this can be due to several reasons. We could change this function to give us a little more info on what happened (by check the resulting value of course)

int report_drive_key(drive_handle h, char agid, unsigned char *point, unsigned char *signature, unsigned char bluray) {
if(report_key(h, buf, agid, 2, 84, bluray))
return -2;

if(buf[0] != 0 || buf[1] != 0x52)
return -1;

memcpy(point, buf+4, 40);
memcpy(signature, buf+44, 40);

return 0;
}
A return value of -2 would mean that the report_key function failed (and therefore the send_cmd function). With a return value of -1 we know that the drive has actually returned something (but not something beginning with 00 52). Maybe there is also a way to get sense data from the commands send. I don't know how to do this for linux ioctl.

Of course somebody has to do some precise debugging to see where the problem lies.

(5) We should compile and try aacsauth

We have working source code (for linux) in aacsauth (http://forum.doom9.org/showthread.php?t=122969). We could use this for trying to see what works. When we add the following in the read_vid of jx6bpm's source it should work for bluray:

int read_vid(drive_handle h, char agid, char *vid, char *mac) {
char cmd[CDROM_PACKET_SIZE];
memset(cmd, 0, CDROM_PACKET_SIZE);

cmd[0] = 0xad;
cmd[1] = 1;
cmd[7] = 0x80;
cmd[8] = 0;
cmd[9] = 36;
cmd[10] = (agid<<6)&0xc0;

if(send_cmd(h, cmd, buf, 0, 36) < 0)
return -1;

memcpy(vid, buf+4, 16);
memcpy(mac, buf+20, 16);

return 0;
}

(6) We may have to fill in vendor specific information

The report key command (aswell as the other commands) say that byte 11 is somewhat vendor specific:

http://img152.imageshack.us/img152/7964/reportxd8.jpg

Currently we set this entire byte to 0. I don't know if this is a problem (since the Dcert is working it wouldn't make sense this is the reason the Dv isn't retrieved). And what is NACA, flag and link?

There is also the question if this is correct:

cmd[8] = (length>>8)&0xff;
cmd[9] = (length)&0xff;


Maybe its better to use an unsigned char for length (and only use byte 9) to avoid potential problems regarding endian encoding? Since the (allocation) length is never going to exceed 255 anyway.

We could also do a GET CONFIGURATION command and see what comes out of that.

Hopefully we will find out soon what is going on here. The fact that the PS3 is actually returning the Dcert is very positive news because it means that the mmc commands are not blocked :).

Regards,

arnezami

[Electrox3d]

boy am I lost now! I thought I was getting it, then whammo!

OK, so I hope this question falls into this thread:
If the program reveals all AACS Keys needed to decrypt, then how do I get the SHA1 hash? I believe that is needed to decrypt?

In the following example of the BD movie Click, I don't know how to get the 40 character string prior to the "=Click" name. I DO know how to get the 32 character string following the "|00/00/00|".

F40F9413E223031170483DEBD0495F5D64F41392=Click |00/00/00|C1F8540A04E9405FED346872CD125990
....^ I can not figure out how to get this string.................................^ I do know how to get this one. (Its just the CPS key)

So, does this program help in revealing that 40-character string?

Thanks!

[woodspire]

The hash is the sha1 hash of the AACS/CPUnit00001.cci file.

under linux, type: openssl sha1 CPUnit00001.cci

Under windows, down an utility to calculate sha1 hash of file

Maybe this could help: http://www.codeproject.com/cs/files/dt_file_hasher.asp

or try this: http://hashtab.beeblebrox-org.qarchive.org/

You could also have looked in the backupblurayv21.zip source. Under src/shared/utils.java, the hashFile function explain how it's done.

And the src/main/BackupBluRay.java show which file is hashed.

[woodspire]

Same problem has ebsi.

Can't compile right now the binary for aacskeys (openssl problem stated above) but the binary provided by ebsi is working.

Dv, Dsig, Hk and BK all zero.

Dcert not zero.

Actually, no other info are zero except the 4 above.

Get a volume Unique Key for talladega nights:

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

Decrypted C-value: 31143BED2A2E4A23A546A708267DDC7C
Media key: 31143BED2A2E4A23A546A708267DDC7D

Encrypted verification data: B385A42078219980710627B27BF7C541
Decr verif data should be: 0123456789ABCDEF
Decrypted verification data: 0123456789ABCDEF682370557C3E243C

AGID: FF

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: 8E9B0E3CF41FA7DA3A829F604122EA4E
Voluem ID MAC: ################################

Volume Unique Key: 3104B2690FA032CD8849139B2D518D0F
Encrypted Unit Key 1: 819CCCE5F7FCF2C8F30FD559F0DDCA0E

Decrypted Unit Key 1: 23403F01F9FD3023ADDF2698C12E7C03


But not the correct one: 243302819492872FB60BF20BCCE28531

It's my way to check if the application is working.

Can't make the change to the source code because can't compile but can run any binary you provide, if you want to debug (woodspire@hotmail.com)

P.S. I have a strange copy of "The Prestige" that can't be decrypt with the key provided in this forum. Hopping to correct the problem and be able to provide it to everybody after testing it.

[Electrox3d]

The hash is the sha1 hash of the AACS/CPUnit00001.cci file.

under linux, type: openssl sha1 CPUnit00001.cci

Under windows, down an utility to calculate sha1 hash of file

Maybe this could help: http://www.codeproject.com/cs/files/dt_file_hasher.asp

or try this: http://hashtab.beeblebrox-org.qarchive.org/

You could also have looked in the backupblurayv21.zip source. Under src/shared/utils.java, the hashFile function explain how it's done.

And the src/main/BackupBluRay.java show which file is hashed.


:devil: This is the first time it was clearly put to me what needed to be done to get this Hash... The software you linked wouldn't work based on some kind of .NET security, but a program called Pinpoint Hash by Pinpoint Laboratories pulled up that exact code! I was like :eek: then :confused: then :devil:

Thanks!

[arnezami]

:devil: This is the first time it was clearly put to me what needed to be done to get this Hash... The software you linked wouldn't work based on some kind of .NET security, but a program called Pinpoint Hash by Pinpoint Laboratories pulled up that exact code! I was like :eek: then :confused: then :devil:

Thanks!

Yes. I this has been discussed. Firstly: the aacskeys program is in progress and it isn't finished. Earlier in this thread I said I would include the sha1 hash at some time. Secondly: KenD00 and I agreed the wrong file is currently hashed which is likely to give us duplicate values for different movies and we agreed to change it to the Unit Key file. We even discussed the file format and the possibility of the Unit Key files being the same for different movies. Its all in this thread.

Sorry for not being more clear about this. But there is a time for building and programming stuff and there is a time for explaining stuff. Usually in that order ;).

Regards,

arnezami

[arnezami]

Same problem has ebsi.

Can't compile right now the binary for aacskeys (openssl problem stated above) but the binary provided by ebsi is working.

Dv, Dsig, Hk and BK all zero.

Dcert not zero.

Actually, no other info are zero except the 4 above.

Get a volume Unique Key for talladega nights:

...

It's my way to check if the application is working.

Can't make the change to the source code because can't compile but can run any binary you provide, if you want to debug (woodspire@hotmail.com)

P.S. I have a strange copy of "The Prestige" that can't be decrypt with the key provided in this forum. Hopping to correct the problem and be able to provide it to everybody after testing it.
Thanks for testing. This is interesting (and stange). It actually gives back a Volume ID (although its the wrong one).

In this post (http://forum.doom9.org/showthread.php?p=953582#post953582) the Volume ID for Talladega Nights The Ballad of Ricky Bobby was posted:

7f 58 3c b4 6c 30 99 e5 c8 99 44 08 07 f7 41 4b

I'm assuming thats the same movie. But since it gives back something it may be an encrypted Volume ID (possibly some special PS3 encryption?).** Can somebody look at their Dcert and see if the drive as Bus Key capable. As I explained earlier how to see this: look for 01 00 00 5c in there. The red value is zero if the drive is not capable of bus encryption.

There is another thing we should try. I now suspect the Dv/Dsig is not empty at all its just not copied to the appropiate buffers (because it contains something strange).

In order to test this you could remove the following code from the report_drive_key function:

int report_drive_key(drive_handle h, char agid, unsigned char *point, unsigned char *signature, unsigned char bluray) {
if(report_key(h, buf, agid, 2, 84, bluray))
return -1;

if(buf[0] != 0 || buf[1] != 0x52)
return -1;

memcpy(point, buf+4, 40);
memcpy(signature, buf+44, 40);

return 0;
}


so it would look like this:

int report_drive_key(drive_handle h, char agid, unsigned char *point, unsigned char *signature, unsigned char bluray) {
if(report_key(h, buf, agid, 2, 84, bluray))
return -1;

memcpy(point, buf+4, 40);
memcpy(signature, buf+44, 40);

return 0;
}


If it then gives any data I would be very interested in what that data is. Would the first two values be close to 0x00 0x52? It wouldn't be working according to specs btw...


[edit] Ooh wait. The agid is wrong! Huh?! There is something wrong there. It should never be FF. Ah. Ok. The check has been removed by ebsi. This explains why its acting up. No agid means no go. Although it doesn't help us yet. Will try to figure out how to proceed.



arnezami

** It may be wise/healthy paranoia to remove everything from this "Volume ID" and all stuff below that (until we know what it is).

[HyperHacker]

FYI, "Voluem ID MAC" is spelled wrong.

[arnezami]

Ok. I've completely stripped aacskeys into aacstiny.

It now doesn't need openssl. So more people can compile and help us.

It doesn't do much. Its just a test program. It gives more information about what is going with the drive so please try this and report back to us (careful: it dumps buffers so I've sort of marked potential sensitive data but if you don't trust yourself just desribe what you see)

Here is part of what I see on my PC:

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: 0006000000000000
AGID: 00

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

Sending report key command: A40000000000000200740100
CAREFUL SENSITIVE: Returning buffer from report drive challenge command: 00720000xxxxxxx

http://rapidshare.com/files/21107374/aacstiny.rar.html

(sorry sendspace is down atm)

Instructions:

INSTALL

Compile with gcc -o aacstiny ioctl.c mmc.c aacstiny.c

There may be some warning. But hopefully it compiles for linux now (not tested yet).

USAGE

mount /dev/scd0 /media/cdrom (this may not be needed but well doesn't hurt I guess)
./aacstiny /dev/scd0 s
/dev/scd0 is the device file of your drive

Good luck :).

arnezami

PS. On a sidenote: since AACS auth is only implemented on "PC-based systems" its also possible the PS3 doesn't support it at all. If this is the case then I have no idea how the PS3 gets its volume ids. I highly doubt though this is the case.

[woodspire]

Can somebody look at their Dcert and see if the drive as Bus Key capable. As I explained earlier how to see this: look for 01 00 00 5c in there. The red value is zero if the drive is not capable of bus encryption.


The only '5C' is at the start of my Dcert. Here how it starts:

0200005CFFFF00 ...

So, it seems that it's not capable of bus encryption.

And it doesn't begin with '01' but with '02'.

Also, if no bus encryption is supported, isn't that a nice thing to have... no encryption ???

[lightshadow]

I can't compile aacstiny Linux. The latter is a bit more verbose.
~/bdownload/aacstiny$ gcc -o aacstiny ioctl.c mmc.c aacstiny.c
aacstiny.c: In function ‘main’:
aacstiny.c:245: error: ‘EXIT_SUCCESS’ undeclared (first use in this function)
aacstiny.c:245: error: (Each undeclared identifier is reported only once
aacstiny.c:245: error: for each function it appears in.)
~/bdownload/aacstiny$ gcc -Wall -O2 -o aacstiny ioctl.c mmc.c aacstiny.c
ioctl.c: In function ‘close_drive’:
ioctl.c:167: warning: implicit declaration of function ‘close’
aacstiny.c:40: warning: return type defaults to ‘int’
aacstiny.c:83: warning: return type defaults to ‘int’
aacstiny.c: In function ‘main’:
aacstiny.c:193: warning: pointer targets in passing argument 1 of ‘output_key’ differ in signedness
aacstiny.c:245: error: ‘EXIT_SUCCESS’ undeclared (first use in this function)
aacstiny.c:245: error: (Each undeclared identifier is reported only once
aacstiny.c:245: error: for each function it appears in.)
aacstiny.c:239: warning: label ‘err’ defined but not used
~/bdownload/aacstiny$

[honai]

The hash is the sha1 hash of the AACS/CPUnit00001.cci file.

under linux, type: openssl sha1 CPUnit00001.cci

Under windows, down an utility to calculate sha1 hash of file

Under Windows I'd recommend the HashTab shell extension:

http://www.beeblebrox.org/hashtab/

Might also come in handy for other uses, like comparing if two files are identical, or when you want to release some software on a public server.

[arnezami]

I can't compile aacstiny Linux. The latter is a bit more verbose.
~/bdownload/aacstiny$ gcc -o aacstiny ioctl.c mmc.c aacstiny.c
aacstiny.c: In function ‘main’:
aacstiny.c:245: error: ‘EXIT_SUCCESS’ undeclared (first use in this function)
aacstiny.c:245: error: (Each undeclared identifier is reported only once
aacstiny.c:245: error: for each function it appears in.)
~/bdownload/aacstiny$ gcc -Wall -O2 -o aacstiny ioctl.c mmc.c aacstiny.c
ioctl.c: In function ‘close_drive’:
ioctl.c:167: warning: implicit declaration of function ‘close’
aacstiny.c:40: warning: return type defaults to ‘int’
aacstiny.c:83: warning: return type defaults to ‘int’
aacstiny.c: In function ‘main’:
aacstiny.c:193: warning: pointer targets in passing argument 1 of ‘output_key’ differ in signedness
aacstiny.c:245: error: ‘EXIT_SUCCESS’ undeclared (first use in this function)
aacstiny.c:245: error: (Each undeclared identifier is reported only once
aacstiny.c:245: error: for each function it appears in.)
aacstiny.c:239: warning: label ‘err’ defined but not used
~/bdownload/aacstiny$

Just change EXIT_SUCCESS into 0 (as in zero).

Or download this one: http://www.sendspace.com/file/tutjhl

Regards,

arnezami

[arnezami]

Can somebody look at their Dcert and see if the drive as Bus Key capable. As I explained earlier how to see this: look for 01 00 00 5c in there. The red value is zero if the drive is not capable of bus encryption.


The only '5C' is at the start of my Dcert. Here how it starts:

0200005CFFFF00 ...

So, it seems that it's not capable of bus encryption.

And it doesn't begin with '01' but with '02'.

Also, if no bus encryption is supported, isn't that a nice thing to have... no encryption ???
Hmm. Are you absolutely sure this is the shown Dcert value and not the Hcert? Because Hcerts begin with 0200005C while Dcerts begin with 0100005C. In other words: are the Dcert and Hcert the same for you?

This could in fact be the case because the buffer isn't cleaned up between the two and the agid isn't working (so the drive doesn't overwrite the buffer with new info). This would also mean that while the Dsig looks like its filled its not filled by the drive (which would make sense if there is no agid btw)

We need to test this (agid stuff) with aacstiny (http://www.sendspace.com/file/tutjhl) first.

[lightshadow]

Just change EXIT_SUCCESS into 0 (as in zero).

Or download this one: http://www.sendspace.com/file/tutjhl

Thanks.

Here is a Makefile for the Linux users that features "make" "make clean" "make install".

The file must be called "Makefile" with capital 'M'.
# Top-level Makefile for aacstiny

CC = gcc

CFLAGS=-Wall -O2

.SUFFIXES: .o .c .h

OBJS = aacstiny.o ioctl.o mmc.o
EXE = aacstiny

.c.o:
$(CC) $(CFLAGS) -c $<

$(EXE): $(OBJS)
$(CC) -o $@ $(OBJS)

all: clean $(EXE)

clean:
-rm -f *.o $(EXE)

install:
cp $(EXE) /usr/local/bin


Example:
~/tr/aacstiny$ make
gcc -Wall -O2 -c aacstiny.c
aacstiny.c:40: warning: return type defaults to ‘int’
aacstiny.c:83: warning: return type defaults to ‘int’
aacstiny.c: In function ‘main’:
aacstiny.c:193: warning: pointer targets in passing argument 1 of ‘output_key’ differ in signedness
aacstiny.c:239: warning: label ‘err’ defined but not used
aacstiny.c: In function ‘output_text’:
aacstiny.c:97: warning: control reaches end of non-void function
aacstiny.c: In function ‘output_key’:
aacstiny.c:80: warning: control reaches end of non-void function
gcc -Wall -O2 -c ioctl.c
ioctl.c: In function ‘close_drive’:
ioctl.c:167: warning: implicit declaration of function ‘close’
gcc -Wall -O2 -c mmc.c
gcc -o aacstiny aacstiny.o ioctl.o mmc.o
~/tr/aacstiny$

[woodspire]

Hmm. Are you absolutely sure this is the shown Dcert value and not the Hcert? Because Hcerts begin with 0200005C while Dcerts begin with 0100005C. In other words: are the Dcert and Hcert the same for you?

This could in fact be the case because the buffer isn't cleaned up between the two and the agid isn't working (so the drive doesn't overwrite the buffer with new info). This would also mean that while the Dsig looks like its filled its not filled by the drive (which would make sense if there is no agid btw)

We need to test this (agid stuff) with aacstiny (http://www.sendspace.com/file/tutjhl) first.

Yes, Dcert and Hcert identical.

here is the output from aacstiny:

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: 0000000000000000
All AGIDs in use, aborting. AGID: -1

[arnezami]

Yes, Dcert and Hcert identical.

here is the output from aacstiny:

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: 0000000000000000
All AGIDs in use, aborting. AGID: -1
Ok. This looks like the PS3 is doesn't even know what to do with an AGID request. The buffer is simply not written to at all.

I'm starting to believe the PS3 does not use the AACS-auth system (or we can't use it). Which means:

1) We can go directly for an (encrypted?) Volume ID (but what to use as AGID?). Skipping the AACS auth process. This is unlikely to be that simple. But what was that Volume ID we got earlier: was that also a buffer fluke? We have to test this seperately.
2) We simply don't know how to extract a Volume ID from the PS3. And somehow have to sniff the (hardware) bus in order to see how its retrieved.
3) The hypervisor is blocking the AGID mmc command. We would have to break the hypervisor or (maybe) hack the drive firmware. Or maybe better: try to install the drive into a PC (with no hypervisor) and see if we can get the Volume ID.

Of course we could still do something wrong. But seeing the response from aacstiny above (which is really simple) I don't think we've done anything wrong here. Somebody check this please.

Can somebody test aacskeys or aacstiny on a PC linux system (HD DVD or Blu-ray). This would confirm the program is working and that its the PS3 acting up. We really need to know this for certain.

Regards,

arnezami

[woodspire]

Anybody tested the aacstiny apps under linux x86 or x86-64 ?

Maybe the problem of aacstiny and aacskeys is that x86 processor are little-endian and PPC are either Big-endian or Bi-endian...

http://en.wikipedia.org/wiki/Endian

Don't know if it applies but I know that we are playing with registry, memory addresses...


Edit: Esay way to test under linux x86:

- download ubuntu livecd iso
- run
- compile aacstiny
- run

Also, there is two other ways to test aacstiny:

1- user yellow dog linux under a PowerPC G5 Mac.
Problem: not lot of people got a ppc mac, with a blu-ray drive, with linux as the OS ...

2- run linux on ps3... load linux only in memory (hardware detection, shell ans aacstiny)
- disconnect the hard drive (serial ata, so hot plug)
- plug serial ata blu-ray or ide blu-ray with converter in place of the hard drive
- detect the blu-ray drive (rerun the hardware detection)
- run aacstiny

(so no need to open the ps3, so the warranty is kept)

Usefulness: maybe the hypervisor only filter the command on the blu-ray serial ata channel, and not on the harddrive
We could be able to know if the restriction is on the hypervisor or in the blu-ray firmware (because the external blu-ray will have already been tested in windows and report no problem).

If you got any other suggestion, be my guest.

[awhitehead]

Anybody tested the aacstiny apps under linux x86 or x86-64 ?

Maybe the problem of aacstiny and aacskeys is that x86 processor are little-endian and PPC are either Big-endian or Bi-endian...

http://en.wikipedia.org/wiki/Endian

Don't know if it applies but I know that we are playing with registry, memory addresses...


Edit: Esay way to test under linux x86:


Endinanness might be an issue if you are packing data into structures, or reading data from structures.

There is an easy way to check for host system endianness:

#include <stdio.h>
union foo
{
char p[4];
int k;
};

int main()
{
int j;
union foo bar;
printf("Bigendian platform (ie Mac OS X PPC) would return \"abcd\"\n");
printf("Littleendian platform (ie Linux x86) would return \"dcba\"\n");
printf("Your platform returned ");
bar.k = 0x61626364;
for(j=0; j<4 ; j++)
{
printf("%c",bar.p[j]);
}

printf("\n");
return 0;

}

(save the above into file, compile using gcc -o foo foo.c )

however we already do know that PlayStation uses a PowerPC based CPU that is bigendian, while PCs are littleendian.


NAME
htonl, htons, ntohl, ntohs -- convert values between host and network
byte order

LIBRARY
Standard C Library (libc, -lc)


At this popint it might make sense to sprinkle htonl() and friends liberally through the aacstiny source.

Sorry, I don't have a PS3, so most I can do is theorise.

[arnezami]

Anybody tested the aacstiny apps under linux x86 or x86-64 ?

Maybe the problem of aacstiny and aacskeys is that x86 processor are little-endian and PPC are either Big-endian or Bi-endian...

http://en.wikipedia.org/wiki/Endian

Don't know if it applies but I know that we are playing with registry, memory addresses...


Edit: Esay way to test under linux x86:

- download ubuntu livecd iso
- run
- compile aacstiny
- run

Also, there is two other ways to test aacstiny:

1- user yellow dog linux under a PowerPC G5 Mac.
Problem: not lot of people got a ppc mac, with a blu-ray drive, with linux as the OS ...

2- run linux on ps3... load linux only in memory (hardware detection, shell ans aacstiny)
- disconnect the hard drive (serial ata, so hot plug)
- plug serial ata blu-ray or ide blu-ray with converter in place of the hard drive
- detect the blu-ray drive (rerun the hardware detection)
- run aacstiny

(so no need to open the ps3, so the warranty is kept)

Usefulness: maybe the hypervisor only filter the command on the blu-ray serial ata channel, and not on the harddrive
We could be able to know if the restriction is on the hypervisor or in the blu-ray firmware (because the external blu-ray will have already been tested in windows and report no problem).

If you got any other suggestion, be my guest.
Some good ideas to test whats going on with the PS3. :)

We indeed need to know where exactly the problem lies.

(btw is there a live cd available with kernel 2.6.20 with udf 2.5 support?)

I have been distracted a bit by the sequence key issue/development etc. But I'm also thinking about some test programs to see whats going on regarding the PS3: making a very simple mmc commmand actually work would be confirmation we are doing something right ;).

I'm not so sure endianess playes a role anymore: the agid request command is printed above and is (and should be) the same for any system (btw: I used a simple "for loop" to print it). So I don't think this is the problem. The commands sent are according to specs. The result is not.

Sending report key command: A40000000000000200080000
Returning buffer from report agid command: 0000000000000000

But I'm not claiming to be a linux/PS3 expert ;).

arnezami

[woodspire]

Endinanness might be an issue if you are packing data into structures, or reading data from structures.

There is an easy way to check for host system endianness:

#include <stdio.h>
union foo
{
char p[4];
int k;
};

int main()
{
int j;
union foo bar;
printf("Bigendian platform (ie Mac OS X PPC) would return \"abcd\"\n");
printf("Littleendian platform (ie Linux x86) would return \"dcba\"\n");
printf("Your platform returned ");
bar.k = 0x61626364;
for(j=0; j<4 ; j++)
{
printf("%c",bar.p[j]);
}

printf("\n");
return 0;

}

(save the above into file, compile using gcc -o foo foo.c )

however we already do know that PlayStation uses a PowerPC based CPU that is bigendian, while PCs are littleendian.



At this popint it might make sense to sprinkle htonl() and friends liberally through the aacstiny source.

Sorry, I don't have a PS3, so most I can do is theorise.


The result was: ABCD.

So the PS3 is big endian.

[arnezami]

Since we are possibly dealing with the hypervisor I think this might be useful:

http://wiki.ps2dev.org/ps3:hypervisor (discussion here (http://forums.ps2dev.org/viewtopic.php?t=7859))

It deals with hypervisor commands. I guess the ioctl function we use should at some point use the hypervisor commands to access the drive. Whether this is fully implemented or whether the right commands are available (mmc stuff) is a question I cannot anwser.

But maybe somebody else can go into this more deeply. Figure out whats going on.

Btw: on this page (http://moss.csc.ncsu.edu/~mueller/cluster/ps3/doc/LinuxKernelOverview.html) you can read about the ioctl commands being blocked :

Since the BD drive is basically ATAPI device, Linux can issue ATAPI commands by ioctl. Some of ATAPI commands have been rejected by the hypervisor call because of security issues.

Just in case you were wondering why I think the hypervisor is bugging us :)

arnezami

[edit]This looks like the command we are talking about: http://wiki.ps2dev.org/ps3:hypervisor:lv1_storage_send_device_command

[arnezami]

Hmmm. Might this be the problem:
These hypervisor calls consist of simple straightforward methods: open, close, read, write, ioctl.Most of all methods are asynchronous, that is, methods will return immediately after call, and then the caller must wait for its completion via other method. These completions are notified by virtualized interrupts.As in: we have to do something more than just call, but wait for the interupt (or simply wait some time) and do another call and get the info we need? Anyone have any ideas on what that other call would be? Or is it simply doing it twice??

[edit]Hmmm. It seems there is a lv1_tag (- tag to identify operation?) given back by the lv1_storage_send_device_command (http://wiki.ps2dev.org/ps3:hypervisor:lv1_storage_send_device_command) which probably has to be used when using the lv1_storage_get_async_status and lv1_storage_check_async_status methods. But the latter don't give a buffer pointer so I'm starting to believe we simply might have to wait a little longer and take another look at our buffer...

[arnezami]

Ok. Compile and run this one on the PS3 and see what happens. If you only get a bunch of zeroes (including the last ones) then timing is unlikely to be the issue...

aacstiny (http://www.sendspace.com/file/c5yphl) (with some buffer waiting stuff)

arnezami

PS. Just for the record: you really do need kernel 2.6.20 but I guess you have that.

[woodspire]

Ok. Compile and run this one on the PS3 and see what happens. If you only get a bunch of zeroes (including the last ones) then timing is unlikely to be the issue...

aacstiny (http://www.sendspace.com/file/c5yphl) (with some buffer waiting stuff)

arnezami

PS. Just for the record: you really do need kernel 2.6.20 but I guess you have that.


Doesn't use kernel 2.6.20 because I can't compile it. (not lot of experience compiling linux kernel however)...

With kernel 2.6.16 with ntfs and udf 2.5 patch here are the results:


- without a blu-ray disk:

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: 0FFD9F8000000000
0FFD9F8000000000


And the last line repeat itself until I hit ctrl-c.

With Casino royale:


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: 0000000000000000
0000000000000000


And the last line repeat itself also. Maybe the 2.6.20 kernel will return something different. If someone has been able to compile it, even without the udf 2.5 patch, please post a detail procedure, so I can redo the test.

[arnezami]

Ok. Has anybody been able to run any program released here with the 2.6.20 kernel on the PS3? The 2.6.20 enables PS3 support (including some hypervisor stuff). I don't think all that is in the udf patch alone. So until somebody is capable of compiling the (important parts of the) kernel I don't think its useful to go on trying and testing programs with the PS3. Although I'm really not sure (this is not my thing).

What needs to be done (not by me) is this: somebody with a PS3 and some programming/linux experience should make sure at least one ioctl command works properly on the PS3. Until then I'm going to concentrate on something else.

arnezami

@woodspire: please don't use ctrl-c. It will stop after 200 tries and will give a little bit more info after that. The non-zero value with tray no disc is interesting though (although probably trash). Please let it run longer too.

[woodspire]

First of all, I read somewhere that kernel 2.6.20 cannot boot yet on the PS3.

The only kernel that I can use are provided by YDL because they contain sony patches. (kernel 2.6.16 and 2.6.17)

I was able to compile the 2.6.17 kernel but it didn't boot up the PS3.

With the kernel 2.6.16, I was able to recompile it with the udf 2.5 patch and it can boot.

Secondly, I did 6 test with the accstiny program.

2th and 6th were without a disk.
All the other tests were with a disk (casino royale)
results:

1-
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
0FF6F2400FEC0F40
...
All AGIDs in use, aborting. AGID: -1


2-
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: 100F507000000000
100F507000000000
...
All AGIDs in use, aborting. AGID: -1


3-
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: 0000000000000000
0000000000000000
...
All AGIDs in use, aborting. AGID: -1

4-
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
0FF6F2400FEC0F40
...
All AGIDs in use, aborting. AGID: -1

5-
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: 100F507000000000
100F507000000000
...
All AGIDs in use, aborting. AGID: -1

6-
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: 0FFD9F8000000000
0FFD9F8000000000
...
All AGIDs in use, aborting. AGID: -1

Has you can see, the results are strange. Doesn't seems to be working.

Also, The PS3 boots with kboot. After this boot, we can select the kernel we want to run.

Maybe we should run a "sony patch free" kernel just to check. (anybody been able to boot kernel 2.6.20 on a PS3 ?)

Kboot is provided in a 25 meg zip file by sony.
I have never see a linux install process on the PS3 without it but I'm pretty sure that on any normal PC, either grub or lilo are used, not kboot.

[arnezami]

Slightly improved version. It now properly cleans the buffer before sending it to the drive:

http://www.sendspace.com/file/e8uo8w

[woodspire]

Slightly improved version. It now properly cleans the buffer before sending it to the drive:

http://www.sendspace.com/file/e8uo8w

Same inconsistent results.

[PepsiLee2001]

Dear arnezami,

I got a BDAV blu-ray disc (not BDMV) with AACS protection.

But the file structure of the disc is different from BDMV.

The file structure is shown as below (three files only)

X:\AACS\MKB_RW.info

X:\AACS\AACS_av\CPSUnit00001.cci
X:\AACS\AACS_av\Unit_Key.RW.inf

Is possible the next version of aacskey.exe can get CPSUnitkey for BDAV disc?

[PepsiLee2001]

Dear All,

I try to complie aacskey.exe, but some errors was happened.

error message:

ioctl.c:8:25: my_ntddscsi.h: No such file or directory
ioctl.c:9:17: sam.h: No such file or directory

ioctl.c:12: parse error before "sptd_sb"
ioctl.c:12: warning: data definition has no type or storage class
ioctl.c: In function `send_cmd':
ioctl.c:95: request for member `sptd' in something not a structure or union
ioctl.c:95: `SCSI_PASS_THROUGH_DIRECT' undeclared (first use in this function)
ioctl.c:95: (Each undeclared identifier is reported only once
ioctl.c:95: for each function it appears in.)
ioctl.c:96: request for member `sptd' in something not a structure or union
ioctl.c:97: request for member `sptd' in something not a structure or union
ioctl.c:98: request for member `sptd' in something not a structure or union
ioctl.c:99: request for member `sptd' in something not a structure or union
ioctl.c:100: request for member `sptd' in something not a structure or union
ioctl.c:100: `MAX_SENSE_LEN' undeclared (first use in this function)
ioctl.c:103: request for member `sptd' in something not a structure or union
ioctl.c:103: `SCSI_IOCTL_DATA_OUT' undeclared (first use in this function)
ioctl.c:104: request for member `sptd' in something not a structure or union
ioctl.c:106: request for member `sptd' in something not a structure or union
ioctl.c:106: `SCSI_IOCTL_DATA_IN' undeclared (first use in this function)
ioctl.c:107: request for member `sptd' in something not a structure or union
ioctl.c:110: request for member `sptd' in something not a structure or union
ioctl.c:110: `SCSI_IOCTL_DATA_UNSPECIFIED' undeclared (first use in this function)
ioctl.c:111: request for member `sptd' in something not a structure or union
ioctl.c:114: request for member `sptd' in something not a structure or union
ioctl.c:115: request for member `sptd' in something not a structure or union
ioctl.c:116: request for member `sptd' in something not a structure or union
ioctl.c:119: request for member `sptd' in something not a structure or union
ioctl.c:121: request for member `SenseBuf' in something not a structure or union
ioctl.c:125: `IOCTL_SCSI_PASS_THROUGH_DIRECT' undeclared (first use in this function)


where can I get the files(my_ntddscsi.h and sam.h)?

[arnezami]

Dear All,

I try to complie aacskey.exe, but some errors was happened.

error message:


where can I get the files(my_ntddscsi.h and sam.h)?

Sorry. My bad. In the post I first released the source (http://forum.doom9.org/showthread.php?p=969481#post969481) the extra three .h files (you need for compiling under windows) were still in the rar. So you can take my_ntddscsi.h, sam.h and spc.h from this old rar ;)

Later on I want to release the source properly. Including new features and compatabilities.

BTW: PepsiLee2001 and I just checked whether the Processing Key works for an encrypted BDAV disc: it does :D. So we can already get the Media Key...

arnezami

[dirio49]

Later on I want to release the source properly. Including new features and compatabilities.
arnezami

Thank you :)

[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

[arnezami]

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]

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.

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]

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]

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]

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]

so is this a result of a key revoke?

[Fahzuu]

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]

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]

For mb2696.

These questions aren't answered yet:

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.

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 (http://forum.doom9.org/attachment.php?attachmentid=6824&d=1171837753) (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 :D. (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]

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]

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:

[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]

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]

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]

IBM Cell BE Software Development Kit 2.1 is out with Linux kernel to 2.6.20, http://www6.software.ibm.com/sdfdl/1v2/regs2/awadmin/cellsw/Xa.2/Xb.bCxnaYZiaXdlJSEfHwej7ZthLvSZss8BC7HE_Sc/Xc.CellSDK21.iso/Xd./Xf.Ltr./Xg.3819903/Xi.cellsw/XY.regsrvs/XZ.uwvNY90x6fvw1vHmT0-h0agjD5I/CellSDK21.iso

Best regards!

[mb2696]

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 (http://forum.doom9.org/attachment.php?attachmentid=6824&d=1171837753) (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 :D. (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 th