Processing Key, Media Key and Volume ID found!!! [Archive] - Page 7

KenD00

18th February 2007, 17:21

I would like to concentrate on making the AACS-auth (+Host Cert/private key) work.

I think you need two things to do that:

1.) A Host Certificate. This can be revoked so it won't work forever. But until they enforce bus encryption everyone can get a new one ;)

Because of that

AACS_Spec_Common_0.91_.pdf

....

12. The drive generates 160 bits random number as nonce Dn
13. The drive sends the nonce Dn generated in step 11 and the Drive Certificate to the host.

...

25. The host creates a digital signature of the concatenation of the nonce Dn received in step 12 and the point
on the elliptic curve Hv calculated in step 22.
Hsig = AACS_Sign(AACS_Hostpriv, Dn || Hv)
26. The host sends the point on the elliptic curve Hv calculated in step 22 and the digital signature Hsig created
in step 23 to the drive.
27. The drive verifies the signature of the concatenation of the nonce Dn and the point on the elliptic curve Hv.
AACS_Verify(AACS_Hostpub, Hsig , Dn || Hv)
If the verification fails, the drive shall determine the host is not compliant and shall abort the drive
authentication procedure.

you need

2.) A Host Private Key. This is hard to get because it does not travel on the bus. But, correct me if i'm wrong, i don't see a mechanism for revoking a Private Key, so this will work forever?

The rest is sending the right commands to the drive.

:rolleyes:

arnezami

18th February 2007, 17:30

I think you need two things to do that:

1.) A Host Certificate. This can be revoked so it won't work forever. But until they enforce bus encryption everyone can get a new one ;)

Because of that

you need

2.) A Host Private Key. This is hard to get because it does not travel on the bus. But, correct me if i'm wrong, i don't see a mechanism for revoking a Private Key, so this will work forever?

The rest is sending the right commands to the drive.

:rolleyes:
Basicly the Certificate "belongs to" the Private Key so if one is revoked the other is too. And you are right the Private Key is the hardest to get ;).

The_ByteMaster

18th February 2007, 18:18

That is 6 bytes that can be 0-255, does not sound to bad.

So 256*256*256*256*256*256 = 281,474,976,710,656 possible combinations.

That is 281.5 Trillion, if you can test a million key a second
it would still take 9 years !!!

...assuming you have just one single processor. But brute-force keyspace searches are almost perfectly scalable. 48 bits encryption is laughable in crypto security terms these days. Even DES which is -in theory- 56 bits (or 8 orders of magnitude more difficult in binary speak) is no challenge at all. Don't worry, if it ever comes down to "cracking" a 48 bit key, this will be done. Either by an open distributed computing effort, or by people who have more means (f.e. admins of a large office network who will let it run after hours).

clsid

18th February 2007, 18:37

Most keys only contain only letters, numbers and spaces. So instead of 256 possible values for each byte, there are only 26x2+10+1=63 values.

63^6 = 62,523,502,209

How long does it approximately take to check a single key? Or how many keys can be checked per second?

hajj_3

18th February 2007, 19:11

i was thinking about a distributed project to crack the key, my core 2 duo is overclocked to 3.7ghz, im sure that would help alot!! 2gb ddr2 ram overclocked to 1000mhz too.

arnezami

18th February 2007, 19:21

i was thinking about a distributed project to crack the key, my core 2 duo is overclocked to 3.7ghz, im sure that would help alot!! 2gb ddr2 ram overclocked to 1000mhz too.

Don't forget what the objective is: making it easier than sniffing or extracting from a Software player. A distributed project clearly is overkill for getting only one Volume ID. Lets keep some perspective here :).

jkenzie

18th February 2007, 21:24

Basicly the Certificate "belongs to" the Private Key so if one is revoked the other is too. And you are right the Private Key is the hardest to get ;).

How many bytes is the Host Private Key?

arnezami

18th February 2007, 21:28

How many bytes is the Host Private Key?

If I remember correctly that would be 40 bytes (or 320 bits if you will). All ECDSA (ellipictic curve DSA).

jkenzie

18th February 2007, 21:34

If I remember correctly that would be 40 bytes (or 320 bits if you will). All ECDSA (ellipictic curve DSA).
That’s encouraging, any way to verify if it's correct or not?

evdberg

18th February 2007, 21:40

That’s encouraging, any way to verify if it's correct or not?

Actually a plain-text-attack should work ... since we know the public key, we can try out all keys from a memory dump as private key, just like musix64 found his first titlekey. Only difference is that ECDSA is quite slow ...

KenD00

18th February 2007, 23:31

Basicly the Certificate "belongs to" the Private Key so if one is revoked the other is too.

I should have read the spec more closely, the certificate contains the Drive Public Key, so a Drive Private Key only works with its Certificate. And funny things like changing the HostID to circumvent revocation does not work because the complete Certifcate is signed with AACS_LApriv :(.

Most keys only contain only letters, numbers and spaces.

I'm sure the people at the AACS LA have internet too, so i bet they will kick all their licensees in their b*tts to not use this scheme any more.

Looking for an alternative way to get the VolumeID i asked myself what happens when i hammer the drive with VolumeID requests, using every possible AGID, when a software player performs the AACS-Authentication? Well, i've tested that and the answer is: the drive gives you the VolumeID :)!!

But depending on your software player the timing is very tricky:

Your favorite software player A:
Start the hammering, start the software player, hit "play", wait a few seconds, receive a VolumeID :)

Your favorite software player B:
Don't dare to start the hammering until you pressed "play", then, if you start too early, the player simply stops. If you start too late, you miss the present. My advice: use software player A ;)

This method should also work on Blu-Ray, you just need to change the media type code in the CDB.

I've attached a new Version of DumpVID with hammering support (no Blu-Ray support!).

:rolleyes:

arnezami

19th February 2007, 05:53

Looking for an alternative way to get the VolumeID i asked myself what happens when i hammer the drive with VolumeID requests, using every possible AGID, when a software player performs the AACS-Authentication? Well, i've tested that and the answer is: the drive gives you the VolumeID :)!!

But depending on your software player the timing is very tricky:

Your favorite software player A:
Start the hammering, start the software player, hit "play", wait a few seconds, receive a VolumeID :)

Your favorite software player B:
Don't dare to start the hammering until you pressed "play", then, if you start too early, the player simply stops. If you start too late, you miss the present. My advice: use software player A ;)

This method should also work on Blu-Ray, you just need to change the media type code in the CDB.

I've attached a new Version of DumpVID with hammering support (no Blu-Ray support!).

:rolleyes:
I love it!! :D :D :D

Maybe we can "automate" the timing somehow or see what is the difference in commands to the drive (between Player A and B) what makes it stopping from working... (how does it "feel" there is something wrong?) Maybe less hammering more "precise bombing"? Maybe some playing around with AGIDs before it all starts?

But anyway its fantastic. Its another alternative method of retrieving the Volume ID! :)

(A = PowerDVD it seems...)

Btw: now that I think about it it makes perfect sense it gives away the VolumeID: the MMC command sent to the drive doesn't contain any authentification information (like a Bus-MAC). This done by the Software Player beforehand (AACS-Auth). And the drive simply thinks you are the Player!! There is only an AGID (0-3) to try. So this will always work :) (its another fundamental flaw in the system: as long as there is no Bus encryption this should work and my drive isn't capable of Bus encryption ;), so there are thousands of people with drives not capable of Bus encryption...). This may become the easiest way (apart from the Host Private Key) of getting the VID in the future because it happens outside the Player and doesn't install or change a (detectable) service or driver.

Cool.

arnezami

PS. Not so important but good to know: the cds dumping doesn't work on W2K: it seems to always hang on that OS (and requires a hard reset of the system to shut it down). In XP it also takes one or two seconds (which is long for 64kb) but it does work (well give zeros that is: this is probably the most meaningless command they invented, or does it work after AACS-auth? or after some special secret AACS-auth?).

HyperHacker

19th February 2007, 10:18

The player could detect this program just as it could detect a driver, however, it wouldn't be exceptionally difficult to prevent it from doing either.

I suspect the reason the player reacts poorly is simply because the drive is having two "conversations" at once, and so the player isn't getting the replies it's expecting because some of them are replies to this program. Or, perhaps once the drive has given the volume ID it won't give it again, so the player doesn't get a copy.

Could the program not sniff to tell when the player is communicating, so it knows when to start hammering? Or have a button/command line which automatically starts the player, delays however long, and starts hammering (or vice-versa)?

Geremia

20th February 2007, 00:36

Hi all

first, congrats to all, very interesting reading here :)

just got an xbox360 dvd drive and started playing a little.

firmware: actually unable to know what cpu inside the main big chip, it'a unnamed, no brand, no model number...actually unable to deassemble. If any good firmware hackers out here, pm me to help find the main cpu.

just sniffed usb trafic between drive and powerdvd 7.2, unfortunally the authentication can not be reproduced, because every time i send the same host certificate challenge, i receive different drive certificate challenge and different drive key, then if i send the host key it returns error, so i suppose anydvd has the host private key (i've not sniffed anydvd, are you sure it asks aacs authenitcation to the drive?)
Sniffed drive keys and drive certificate challenge data are not present in firmware, at least not in clear, so i guess the drive has something like a master private key (i'm not cripto specialist, i'm not specialist in nothing, just hobbyst).

I'm using plscsi to send cdb commands, it's nice.

here some example of using plscsi:

plscsi.exe -v -x "A4 00 00 00 00 00 00 02 00 10 00 00" -i x8 // request Authentication Grant ID
plscsi.exe -v -x "A3 00 00 00 00 00 00 02 00 74 01 00" -o x74 -f hostchal1.bin // send host certificate challenge
plscsi.exe -v -x "A4 00 00 00 00 00 00 02 00 74 01 00" -i x74 // request drive certificate challenge
plscsi.exe -v -x "A4 00 00 00 00 00 00 02 00 54 02 00" -i x54 // request drive key
plscsi.exe -v -x "A3 00 00 00 00 00 00 02 00 54 02 00" -o x54 -f hostkey1.bin // send host key

plscsi.exe -v -x "AD 00 00 00 00 00 00 03 00 50 00 00" -i x50 // read BCA

About control data zone, it's hidden from the simple "read" cdb command, the drive forbid you to read negative LBA sectors.

Read command accept positive LBA sectors, LBA sector 0 is PSN (phisical sector number) 30000, so you can't read control data zone that is PSN 2F200-2FDFF, unless you hack the firmware to skip the LBA positive check.
I don't know what Kend00 have tried, anyway the read disc structure - (15h) read Copyright data section works, but output all zeroes :(, at least for kingkong, miami vice and the bourne supremacy.

plscsi.exe -v -x "AD 00 00 00 00 00 00 15 F8 04 00 00" -i xF804 -t CDS.bin

P.S.
i've tried to send read disc structure - read volume ID cdb command when powerdvd plays, but i was not luck.
plscsi.exe -v -x "AD 00 00 00 00 00 00 80 00 24 00 00" -i x24
It seems that the drive does not accept repetition of authentication procedure steps, in fact powerdvd repeats the procedure 3-4 times.
For procedure i mean:
- clear AGID
-request an AGID
-send host certificate challenge
-request drive certificate challenge
- request drive key
- send host key
- read disc structure, volume id (format code 80h) (btw, it seems to not read other stuff here, like pre recorded media serial number or MKB in the leadin)

Geremia

20th February 2007, 15:21

ops, i made some mistake, i'm just learnin on the way :)

The returned drive cetificate is always the same, it's the Nonce that changes everytime ( a random number), and Nonce is necessary for the next step, report key - drive key, but this is not the drive public key(which is inside the previous challenge), it's a signed (with drive private key) info for the host to calculate the bus key.

Anydvd must know the powerdvd private key to be able to sign the send key - drive key cdb command (and also must have the helliptic curve of whatever it is)

Into firmware, there is no visible drive ID or drive public key

KenD00

20th February 2007, 16:14

the cds dumping doesn't work on W2K: it seems to always hang on that OS (and requires a hard reset of the system to shut it down). In XP it also takes one or two seconds (which is long for 64kb) but it does work (well give zeros that is: this is probably the most meaningless command they invented, or does it work after AACS-auth? or after some special secret AACS-auth?).

Perhaps the second half of the VolumeID is stored like SafeDisc or SecuROM store their "digital signatures", corrupt a few sectors here and there. Maybe because of that it takes so long to read this area, any maybe because of that the storage method is described in the confidental part of the spec ;).

@arnezami, HyperHacker
This timing stuff depends on the player and maybe on the system, now only one software player makes trouble, maybe this "feature" will spread. These ideas like monitoring the player, prevent the detection of the prog, are beyond my knowledge, also i was looking for a more independend way to get the VID, i discovered this method by accident when probing fancy ideas. I won't go further this way and will concentrate on my "use of keys" application, not the "get of keys" way.

:rolleyes:

jqr

20th February 2007, 17:10

Congratulations :-)

And yes, there is demand ;-)

:thanks:

Well I was just reading this thread when I was linking to a blog post I wrote and I thought I might mention I have actually made an attempt to explain the subset-difference algorithm here (http://www.jquirke.com.au/index.php/2007/02/12/aacss-subset-cover-scheme-explained/). Hope it is of at least some help.

arnezami

20th February 2007, 18:27

Well I was just reading this thread when I was linking to a blog post I wrote and I thought I might mention I have actually made an attempt to explain the subset-difference algorithm here (http://www.jquirke.com.au/index.php/2007/02/12/aacss-subset-cover-scheme-explained/). Hope it is of at least some help.

Thanks :) I will read it.

Here you can read my explanation:

Understanding AACS (including Subset-Difference) (http://forum.doom9.org/showthread.php?t=122363)

Regards,

arnezami

Geremia

20th February 2007, 20:28

Perhaps the second half of the VolumeID is stored like SafeDisc or SecuROM store their "digital signatures", corrupt a few sectors here and there. Maybe because of that it takes so long to read this area, any maybe because of that the storage method is described in the confidental part of the spec ;).

// Allocation length for the return buffer, the maximum is 63488
sptd_sb.sptd.Cdb[8] = 0xF8;
sptd_sb.sptd.Cdb[9] = 0x02;
// No AGID
sptd_sb.sptd.Cdb[10] = 0;
// Control is 0, don't know whats this for
sptd_sb.sptd.Cdb[11] = 0;
// Zero the rest of the structure
sptd_sb.sptd.Cdb[12] = 0;
sptd_sb.sptd.Cdb[13] = 0;
sptd_sb.sptd.Cdb[14] = 0;
sptd_sb.sptd.Cdb[15] = 0;

ZeroMemory(data_buf, 63492);
ZeroMemory(sptd_sb.SenseBuf, MAX_SENSE_LEN);

If i'm not wrong, you send cdb command to retrieve FB02h bytes (including response header) but you expect FB04h (63492) bytes back
The correct value for the cdb is FB04 because you will have 4bytes oh header (2 bytes of lenght + 2bytes reserved)

plscsi.exe -v -x "AD 00 00 00 00 00 00 15 F8 04 00 00" -i xF804 -t dump.bin

these sectors are readable, because you don't get sense error, but presumibly the drive firmware doesn't output any data for us unauthenticated people.
The maximum data to retrieve is 63488=31 sectors, so the last sector is out, but even if you read it, it's the same all zeroes.

Geremia

20th February 2007, 21:06

awhitehead

20th February 2007, 22:38

I am providing these for four different movies: Full Metal Jacket, Rambo I, Rambo II and Rambo III.

Volume ID for Full Metal Jacket is:

TransferBufferMDL = 83b06f88
00000000: 00 22 00 00 40 00 46 55 4c 4c 4d 45 54 41 4c 4a
00000010: 41 43 00 00 xx xx xx xx xx xx xx xx xx xx xx xx
00000020: xx xx xx xx
UrbLink = 00000000
[56868 ms]

For Rambo movies VIDs and VUKs are here:
http://forum.doom9.org/showpost.php?p=955567&postcount=191

sectors.rar file contains the .bin files corresponding to the following session (My drive is also on letter I: (and plscsi -w seems to agree)):

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Administrator>cd Desktop

C:\Documents and Settings\Administrator\Desktop>set PLSCSI=\\.\I:

C:\Documents and Settings\Administrator\Desktop>plscsi.exe -v -x "AD 00 00 00 00 00 00 1
5 08 04 00 00" -i x804 -t FULLMETAL.bin
x 00000000 AD 00 00:00:00:00 00 15:08:04:00 00 .. .. .. .. "-@@@@@@UHD@@"
x 00000000 F8:02:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "xB@@@@@@@@@@@@@@"
x 00000010 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 000007F0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000800 00:00:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "@@@@"
// 0 = plscsi.main exit int

C:\Documents and Settings\Administrator\Desktop>plscsi.exe -v -x "AD 00 00 00 00 00 00 1
5 08 04 00 00" -i x804 -t RAMBO3.bin
x 00000000 AD 00 00:00:00:00 00 15:08:04:00 00 .. .. .. .. "-@@@@@@UHD@@"
x 00000000 F8:02:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "xB@@@@@@@@@@@@@@"
x 00000010 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 000007F0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000800 00:00:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "@@@@"
// 0 = plscsi.main exit int

C:\Documents and Settings\Administrator\Desktop>plscsi.exe -v -x "AD 00 00 00 00 00 00 1
5 08 04 00 00" -i x804 -t RAMBO2.bin
x 00000000 AD 00 00:00:00:00 00 15:08:04:00 00 .. .. .. .. "-@@@@@@UHD@@"
x 00000000 F8:02:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "xB@@@@@@@@@@@@@@"
x 00000010 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 000007F0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000800 00:00:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "@@@@"
// 0 = plscsi.main exit int

C:\Documents and Settings\Administrator\Desktop>plscsi.exe -v -x "AD 00 00 00 00 00 00 1
5 08 04 00 00" -i x804 -t RAMBO1.bin
x 00000000 AD 00 00:00:00:00 00 15:08:04:00 00 .. .. .. .. "-@@@@@@UHD@@"
x 00000000 F8:02:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "xB@@@@@@@@@@@@@@"
x 00000010 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 000007F0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000800 00:00:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "@@@@"
// 0 = plscsi.main exit int

C:\Documents and Settings\Administrator\Desktop>

Looking at the resulting .bin files in winhex, I see that with exception of the two bytes at the beginning of .bin files, the files are full of nulls.

Geremia

21st February 2007, 01:18

thanks

so, the second half of the volume id is not in that sectors, or better, not in the data portion of that sectors, maybe it's in what CPR_MAI field is for dvd-rom secotrs (6bytes of data before the 2048 data bytes), but i don't know the phisical structure of hd-dvd (does anyone has the not public hd-dvd phisical book?), and anyway an hacked firmware is needed for a raw reading.

HyperHacker

21st February 2007, 02:10

Read command accept positive LBA sectors, LBA sector 0 is PSN (phisical sector number) 30000, so you can't read control data zone that is PSN 2F200-2FDFF, unless you hack the firmware to skip the LBA positive check.
Is there a way you could exploit integer overflow? E.g. attempt to read sector 0x10002F200?

frogman

21st February 2007, 07:31

Hey, just sniffed my 3 movie, all from universal pictures
kingkong
the bourne supremacy
miami vice

in sniff dump, the volumeID has first 8 bytes 40 00 date and time, the next 8 bytes are 00 20 20 20 20 20 00 00

all the movie has copyright data section all zeroes, maybe it's ok like this, the second part is filled with 20 because no data in the CDS

Can anyone try to read control data segment from a movie that has a complete 16byte volume ID?

just the first sector should be enought

get plscsi here http://members.aol.com/plscsi/2002/09/22/win/plscsi.exe

Here's what I got. xbox 360 hd external drive with King Kong usa in F: Drive

plscsi.exe -v -x "AD 00 00 00 00 00 00 15 08 04 00 00" -i x804 -t CDS.bin
x 00000000 AD 00 00:00:00:00 00 15:08:04:00 00 .. .. .. .. "-@@@@@@UHD@@"
x 00000000 F8:02:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "xB@@@@@@@@@@@@@@"
x 00000010 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 000007F0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000800 00:00:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "@@@@"
// 0 = plscsi.main exit int

Hope this helps.

KenD00

21st February 2007, 16:55

If i'm not wrong, you send cdb command to retrieve FB02h bytes (including response header) but you expect FB04h (63492) bytes back

Yeah, indeed, im missing 2 bytes. Well, two zeros more or less ... ;)

all the movie has copyright data section all zeroes, maybe it's ok like this, the second part is filled with 20 because no data in the CDS

Can anyone try to read control data segment from a movie that has a complete 16byte volume ID?

Your VolumeID is complete, its missing nothing.

Is there a way you could exploit integer overflow?
As far as i know LBA is unsigned so there is no way.

I think enough people have proven that you only get zeros from the Copyright Data Section, no need for more proofs.
So there seems to be no way to get the second half of the VID directly off the disc without a hacked firmware, but why you want to read the sectors raw, why don't modify the drive to give it away without beeing authentified ;)?

:rolleyes:

Deity11

21st February 2007, 18:19

The Matador 10/19/2006 20:41
Hex: 40 00 ba be 00 00 00 00 00 00 00 00 00 1c 00 00

This one I don't know. So far only one found of this kind. We could try 256 different values in the last byte. Don't know.

Maybe it's just the 28th release?

Geremia

21st February 2007, 20:16

but why you want to read the sectors raw, why don't modify the drive to give it away without beeing authentified ;)?

hehehe, yes it's for sure the easyest way in theory, problem actually is to know what cpu is inside the main chip.

evdberg

21st February 2007, 21:09

I think enough people have proven that you only get zeros from the Copyright Data Section, no need for more proofs.

Actually, as I already wrote earlier, the function just fails without sense error. The zeros are there because the buffer is cleared before calling the function.

mb2696

22nd February 2007, 01:35

Babel 12/19/06 21:54:12
Vid: 40 00 20 06 12 19 05 35 00 20 20 20 20 20 00 00

The "20 06 12 19" is clearly the date, but I'm not sure what to make of the "05 35 00"

Punqtured

22nd February 2007, 13:49

Babel 12/19/06 21:54:12
Vid: 40 00 20 06 12 19 05 35 00 20 20 20 20 20 00 00

The "20 06 12 19" is clearly the date, but I'm not sure what to make of the "05 35 00"

Most likely, it's just the time of creation, like some of the others reported.

mb2696

22nd February 2007, 15:29

Most likely, it's just the time of creation, like some of the others reported.

Time of file creation is 21:54:12. Is there another time involved?

mb2696

22nd February 2007, 18:43

Four Brothers
05/15/2006 - 18:46:24
vid: 40 00 05 15 20 06 03 50 00 20 20 20 20 20 00 00

Note that Four Brothers and Babel are both Paramount titles, and that the vids are pretty similar.

40 00 YY YY MM DD 05 35 00 20 20 20 20 20 00 00 - babel

40 00 MM DD YY YY 03 50 00 20 20 20 20 20 00 00 - four bros

Those three bytes seem simple but i dont see a pattern, as they don't appear to be file creation times:

18:46:24 - babel
21:54:12 - four bros

>>>If anyone has any other Paramount titles, please post the VIDs and lets see if we can figure out this scheme.

lightshadow

22nd February 2007, 18:56

firmware: actually unable to know what cpu inside the main big chip, it'a unnamed, no brand, no model number...actually unable to deassemble. If any good firmware hackers out here, pm me to help find the main cpu.
If I recall correct then the XBox360 firmware hack all started by people posted photos of their drives PCB's where the chips could be seen.

Perhaps it would be a good idea to do there same here? There might be someone that can regonize the chip either based on the number of pins, or commen used components used in conjuction with that chip?

mb2696

22nd February 2007, 19:35

there are 2 barcodes near the inner hub of the disc. is this the "burst cutting area"? Could those two be the "prerecorded serial number" and first half of the VID?

KenD00

22nd February 2007, 23:46

Actually, as I already wrote earlier, the function just fails without sense error. The zeros are there because the buffer is cleared before calling the function.

But i do not get all zero, the first two bytes contain the correct Disc Structure Data Length. For a test, i initialized the whole buffer with 0xFF, and again, the same result, correct Disc Structure Data Length, the rest all zero.
Also the here posted results show the correct Disc Structure Data Length.

:rolleyes:

lightshadow

23rd February 2007, 05:14

there are 2 barcodes near the inner hub of the disc. is this the "burst cutting area"? Could those two be the "prerecorded serial number" and first half of the VID?
This reminds me of a disc layout image from the XBox360 firmware hack, where the different sections of the DVD was labeled.

The original thread is here (http://www.xboxhacker.net/index.php?topic=76.0), (42 pages of how the firmware was hacked), but I can't find this image right now=(

At this (http://wiki.free60.org/DVD) wiki there are the bar code of the XBox DVD. The reason they tried cover up the inner DVD section was to test if the disc contained any important information there. E.g. in our case, this could be the VID that was hidden there?

There was made a wiki of all the facts and speculations, and I think it is this one (http://wiki.free60.org/Documentation), or atleast part of it.

One of the things that speeded the XBox360 firmware hack a great deal up, was that the model numbers on the chip could be looked up, and deassembing could be done.

It seams that they have read the thread in great detail, and learned that removing this information would cause trouble.

The thread contains a lot of "I hope they didn't do that, because that would make it harder" and "why didn't they do that, because that would make it harder".

Taking in consideration that they removed the chip model numbers, I bet searching for the above techniques, will pay off. Depending on how you read it, it is either a guide on how to hacked the firmware or a guide on how to make your next firmware better.

Also, seaching for patents helped out hacking the firmware a lot, as a patent is more or less the specifiation. Google have just opened a patent search engine (http://www.google.com/ptshp), but I don't know if it is complete?

So if you ask me, these issues have to be resolved:

Post photos of PCB's, chips and surrounding components
Search for HD-DVD and Blue-Ray related patents.
Read the XBox360 firmware hack thread and find all "i hope they didn't..." and "why didn't they..."
Make a wiki with facts and speculations, so nothing is lost or forgotten.
Test if the inner section of the discs hold important information, be putting tape on it.

arnezami

5th March 2007, 21:38

Looking for an alternative way to get the VolumeID i asked myself what happens when i hammer the drive with VolumeID requests, using every possible AGID, when a software player performs the AACS-Authentication? Well, i've tested that and the answer is: the drive gives you the VolumeID :)!!

But depending on your software player the timing is very tricky:

Your favorite software player A:
Start the hammering, start the software player, hit "play", wait a few seconds, receive a VolumeID :)

Your favorite software player B:
Don't dare to start the hammering until you pressed "play", then, if you start too early, the player simply stops. If you start too late, you miss the present. My advice: use software player A ;)

This method should also work on Blu-Ray, you just need to change the media type code in the CDB.

I've attached a new Version of DumpVID with hammering support (no Blu-Ray support!).

:rolleyes:
I've build on KenD00's work and am now able to reliably extract a Volume ID from the drive using any Software Player without the need of the found Host Private Key.

It first involves some tweaking by the user (but the proggy each try gives advise on what to do: setting the time earlier or later). But once setup it will work perfectly. And it requires no sniffing. It uses the moment the AGID is allocated by the Software Player as a pretty precise time marker.

This technique uses the huge hole in AACS: no bus encryption. This allows us to pretend to be the Software Player at the exact right time. And I don't think they can plug this hole now since so many drives (without the capability to bus encrypt) are already sold.

They really f**ked up here :D. They should have waited longer and finished the job properly. Shame on them.

I will probably release the (now still experimental) program to do this in the future. Possibly combined with my other proggy that uses the now found Host Private Key. This technique can be used as a "fall-back position" in the case the found HPK gets revoked.

Oh yes. We really are busting AACS. Piece by piece. :)

In my mind the whole Drive-Host protection (Chapter 4 common AACS specs) is toast.

Regards,

arnezami

HyperHacker

5th March 2007, 22:25

OK, some people were wondering about barcodes and burst cutting areas, so here's an image that should help clarify. This is a Gamecube disc but other discs will be similar; Gamecube discs are only mini DVDs really.

The "barcode" is printed on the inner ring. This is, as best I know, not readable by any drive. It serves only to identify the disc and probably contains the same info as the text around it or a serial number.

The "burst cutting area" can be seen on the innermost section of the data area. This is phsyically pressed into the disc. Some drives can read this, but to write it requires very expensive disc pressing equipment. This could indeed hold things like volume ID.

ATARI Vampire

5th March 2007, 22:31

I will probably release the (now still experimental) program to do this in the future. Possibly combined with my other proggy that uses the now found Host Private Key.

I'd love to play around with this code. Please do release it. Thanks.

arnezami

6th March 2007, 06:48

ShadowFlare

6th March 2007, 09:22

Well here is something to play with. :)

fetchvid.exe (http://www.sendspace.com/file/als4m9)

For me it works with WinDVD (which is the most sensitive I believe) and the Xbox 360 HD DVD. My sweet spot is a time value between 390 and 420. I usually set it at 410 which works perfectly (btw time is measured in nr of AGID retrieval attempts counted from the moment the player accesses the drive).

Just try it and play with it a bit.

Remember: this program does not use the private key. It just "watches" the drive carefully and then pretends to be the software player.

It works for HD DVD only atm.

Screenshot:

http://img129.imageshack.us/img129/4074/fetchvidhd3.png

Regards,

arnezami

PS. This is experimental programming. There could be bugs in it.

So, theoretically your program could automatically find the correct value, only telling the user when to open the player to play and when to reopen the player to try again. It could do it by the same process you performed manually, but automatically changing to different values instead.

Once the value is found, it could be saved for later use, correct? Or would this value possibly change on the same computer and drive depending on factors such as the quality of the disc, etc.?