Got VolumeID without AACS authentication :)

[Geremia]

hahhahaah, xt5 from xboxhacker found a CDB that solves all your worries.

This does not need a patched firmware at all

http://www.ingenieria-inversa.cl/files/vid.rar

[tonyp12]

xt5 from xboxhacker found a CDB

Got any link to that post?

[arnezami]

Originally Posted by Geremia

hahhahaah, xt5 from xboxhacker found a CDB that solves all your worries.

This does not need a patched firmware at all

http://www.ingenieria-inversa.cl/files/vid.rar

You gotta be kidding!

Link doesn't work atm.

[generalnewbie]

I just wanted to thank you for clarifying this thread. I just posted an article on my blog i hope i got everything correct. Care to read it? find it here

Originally Posted by arnezami

Sure.


Yes.


We are patching the drive so when a disc is inserted it will give the Volume ID of that disc. Without the need of a special key (called a Host Private Key).


If in several weeks new discs are released this may be one of the few ways to get the Volume ID which is needed (among another Key called the Processing Key) to decrypt/backup your discs. But you don't need it now.


Have I succeeded?

Regards,

arnezami

[Geremia]

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

[FoxDisc]

Originally Posted by lightshadow

I think people would prefer to have their back ups decrypted and free from DRM, so there are no strings attached.

I won't dispute that most people would prefer to eliminate the DRM entirely. The problem is that the AACS LA is very likely to begin using the SKB system. Without delving too deeply, the SKB system is going to require more keys than current decryptions require. Disclosing those additional keys means disclosing something about who provided those keys and where they came from. That's their purpose. If you disclose the source of the keys, you make it easier to cut off that source.

In contrast, spoofing the Volume ID on the BCA by modifying the firmware would make fair use backups possible without requiring any keys. If you have the keys and can remove the DRM, then great, but this would provide an alternative when you don't have the keys.

Sometimes half a loaf is better than nothing.

[arnezami]

Originally Posted by Geremia

hahhahaah, xt5 from xboxhacker found a CDB that solves all your worries.

This does not need a patched firmware at all

http://www.ingenieria-inversa.cl/files/vid.rar

OMG. Its working !!! On my unpatched drive!!!

This is FUN!!

How on earth is this done? Some kind of exploit? Or some left over debug CDB command? That would be fun!

I've said it before but this time its really true: the Volume ID is a joke .

arnezami

[lightshadow]

Originally Posted by arnezami

OMG. Its working !!! On my unpatched drive!!!

This is FUN!!

How on earth is this done? Some kind of exploit? Or some left over debug CDB command? That would be fun!

I've said it before but this time its really true: the Volume ID is a joke .

What? What? What??? What does it do??? =) Please tell us =)

[generalnewbie]

I think the new program the VID.rar file contains the program and source code to get the volume ID without needing to patch the firmware of the HD DVD drive. It is able to get retrieve the Volume ID of the xbox 360 hd dvd drive by another method.

[Geremia]

well, near the DF 00 E2 00 00 ba ba ba ea ea ea command to dump mem, xt5 found a nice
DF 00 E3 00 sa sa sa ea ea ea bb bb tu poke ram , where sasasa is start address, eaeaea is end address, and bbbb is the 16bit value to write

Now it's posible to write to ram to let the (not patched) volumeID function to pass without being authenticated, just 2 bytes have to be written, because just 2 bytes are checked

ROM:002218DE loc_2218DE:                             ; CODE XREF: ATAPI_AD_AACS_READ_VOLUMEID+20j
ROM:002218DE                 ldi:20  #0x164, r0
ROM:002218E2                 mul     r0, r9          ; r9 = AGID, from 0 to 3
ROM:002218E4                 mov     mdl, r0
ROM:002218E6                 ldi:32  #0x60C1C8, r8   ; probably AGID related ram address
ROM:002218EC                 add     r0, r8
ROM:002218EE                 ldi:8   #4, r13
ROM:002218F0                 ld      @(r13, r8), r0
ROM:002218F2                 cmp     #0, r0
ROM:002218F4                 bne     loc_221902      ; branch if 60C1CC is not 00000000
ROM:002218F6                 ldi:32  #CDB_field_error, r12
ROM:002218FC                 call:D  @r12
ROM:002218FE                 ldi:8   #0xA, r4
ROM:00221900                 bra     loc_2219A8
ROM:00221902 ; ---------------------------------------------------------------------------
ROM:00221902
ROM:00221902 loc_221902:                             ; CODE XREF: ATAPI_AD_AACS_READ_VOLUMEID+42j
ROM:00221902                 ld      @r8, r0
ROM:00221904                 cmp     #5, r0
ROM:00221906                 beq:D   loc_22191C      ; branch if 60C1C8 is 00000005
ROM:00221908                 mov     r9, r4

this app coded by xt5 does:
enable the DF command
writes 0001 to 60C1CE and 0005 to 60C1CA
reads the volumeId
disable the DF command

[arnezami]

Originally Posted by lightshadow

What? What? What??? What does it do??? =) Please tell us =)

It gives the volume ID without patching the drive and without doing AACS auth. Meaning this drive has a HUGE security hole in it .

[lightshadow]

Originally Posted by Geremia

this app coded by xt5 does:
enable the DF command
writes 0001 to 60C1CE and 0005 to 60C1CA
reads the volumeId
disable the DF command

What a beautiful hack! No traces afterwards.

Keep up the good work =)

[arnezami]

Originally Posted by Geremia

well, near the DF 00 E2 00 00 ba ba ba ea ea ea command to dump mem, xt5 found a nice
DF 00 E3 00 sa sa sa ea ea ea bb bb tu poke ram , where sasasa is start address, eaeaea is end address, and bbbb is the 16bit value to write

Now it's posible to write to ram to let the (not patched) volumeID function to pass without being authenticated, just 2 bytes have to be written, because just 2 bytes are checked

ROM:002218DE loc_2218DE:                             ; CODE XREF: ATAPI_AD_AACS_READ_VOLUMEID+20j
ROM:002218DE                 ldi:20  #0x164, r0
ROM:002218E2                 mul     r0, r9          ; r9 = AGID, from 0 to 3
ROM:002218E4                 mov     mdl, r0
ROM:002218E6                 ldi:32  #0x60C1C8, r8   ; probably AGID related ram address
ROM:002218EC                 add     r0, r8
ROM:002218EE                 ldi:8   #4, r13
ROM:002218F0                 ld      @(r13, r8), r0
ROM:002218F2                 cmp     #0, r0
ROM:002218F4                 bne     loc_221902      ; branch if 60C1CC is not 00000000
ROM:002218F6                 ldi:32  #CDB_field_error, r12
ROM:002218FC                 call:D  @r12
ROM:002218FE                 ldi:8   #0xA, r4
ROM:00221900                 bra     loc_2219A8
ROM:00221902 ; ---------------------------------------------------------------------------
ROM:00221902
ROM:00221902 loc_221902:                             ; CODE XREF: ATAPI_AD_AACS_READ_VOLUMEID+42j
ROM:00221902                 ld      @r8, r0
ROM:00221904                 cmp     #5, r0
ROM:00221906                 beq:D   loc_22191C      ; branch if 60C1C8 is 00000005
ROM:00221908                 mov     r9, r4

this app coded by xt5 does:
enable the DF command
writes 0001 to 60C1CE and 0005 to 60C1CA
reads the volumeId
disable the DF command

Deep respect for xt5 and Geremia here. Fabulous work

[woah!]

works here aswell amazing work too all of you. i checked the key it gave me against the one aacskeys gives me and its the same.

but the drive gives me 8 bits more info at the beginning of the key:

from the drive: 00220000400026061109202157474844564D0000

from aacskeys: 400026061109202157474844564D0000


so what dumper can use a VID not VUK as its key ??

DumpHD looks for a VUK i believe.

[arnezami]

Btw: are there any Toshiba/Samsumg BD drives?

[Mug Funky]

good point on BD drives.

the availability and interoperability of HD-DVD hardware might just be giving Sony a competitive advantage it most certainly should not have... already there's been delays in HD-DVD titles but no corresponding delays in BD titles.

if i had the moolah i'd be buying up hardware and donating it to deserving hacksters sadly it seems the cleverest people have sided with HD-DVD, possibly to it's detriment.

here we see DRM turning usual market principles upside down... make a product more competitive and useful and suddenly it's at a disadvantage.

[lightshadow]

Originally Posted by FoxDisc

I won't dispute that most people would prefer to eliminate the DRM entirely. The problem is that the AACS LA is very likely to begin using the SKB system. Without delving too deeply, the SKB system is going to require more keys than current decryptions require. Disclosing those additional keys means disclosing something about who provided those keys and where they came from. That's their purpose. If you disclose the source of the keys, you make it easier to cut off that source.

Will SKB be an compatible "extension" to the AACS that we know today, or will it break the current hacks and how AACS works?

[LoloMc]

I need to buy one of those readers

Thanks guys to share

[FoxDisc]

Originally Posted by lightshadow

Will SKB be an compatible "extension" to the AACS that we know today, or will it break the current hacks and how AACS works?

A bit of both. Try reading this:
http://forum.doom9.org/showthread.ph...881#post986881

[TiCaL]

Originally Posted by arnezami

Btw: are there any Toshiba/Samsumg BD drives?

Toshiba are the one of the main supporters of HD DVD so it is very unlikely they will come out with a Blu-ray player let alone a drive.

Samsung on the other hand do have a BD Writer, although I cannot seem to find it on their website anymore (it may be outdated). It is listed here though:

SAMSUNG SH-B022
http://www.blu-ray.com/drives/

Maybe someone has this model or can get their hands on one of them.