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

[arnezami]

MODERATOR NOTE: arnezami and KenD00 are apparently no longer active in maintaining this software. New versions can be found at cyberside (http://cyberside.net.ee/ripping/BD_DeviceKeys/).

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.