Got VolumeID without AACS authentication :) - Page 2

Geremia · 6th April 2007, 12:31

This will help in concluding if the patched firmware is safe:

- desolder the falsh
- read it with external programmer, compare with original MC08 firmware
- solder it back
- flash by software the patched firmware i can provide
- desolder the flash
-read it again and compare with the original dump to see if any other region changes except the few bytes patched.

Consider that i can do it myself as soon as i've time, probably tomorrow.

From the assembler side, an help could be in finding a vendor specific CDB that can dump firmware by software.
On xboxhacker thread there are info about the CDB table with relative function address.

btw, here is the original SD-S802A MC08 firmware with part 3, 6 and 7 blanked, like the buffalo SD-H802A fw upgrade.
http://www.sendspace.com/file/sleyls
don't flash this (atm), but use only for dissassembling or comparing with your own flash dump.

arnezami · 6th April 2007, 13:11

Just a little update: I'm currently analyzing the checksum functions etc and I'm making progress.

Things I've figured out:

The function starting at 002F0CA6 first cancels the XOR effects of the first 32 bits value in the fw part (so this is literally at 00000000 for the first fw part) and the 16 bytes at the end of the fw part. Its as if it did a 4-column XOR with these (total of 20 bytes) values zeroed out. This is to then recalculate the 16 bytes checksum values at the end of the fw.
The function 002F0A44 re-calculates the actual 16 byte checksum values and has the 4 column XORs as input. The output of this function should be the 16 bytes value stored in the uploaded fw. So the only thing we need is this function which generates the right checksum data. It uses the data ToshibaSamsungST + random 16 bytes (from its current fw) and appears to do a hash (at 002F01B2) with 10 rounds on it (possibly RIPEMD-160). The fact that it gets these value from its current fw is probably because it won't (accidentally) overwrite a different type of firmware on its flash (which is good for us). This function also combines the 4 column XORs (byte-wise) including some bit shifting etc.
The 32 bit value at the beginning of a checksummed fw part is the "SUM-correction-value": it makes sure the SUM will be 0. This should be added at the last moment if we would do our own checksum calculations. Essentially this correction value is not part of the XOR checksum.

This whole checksum algo starts to make more and more sense to me now. I'm not there yet but its promising.

arnezami

Geremia · 6th April 2007, 13:58

hehhe, i got lost there with all that clearing of column xors.

Code:

ROM:002F0AC4                 ldi:8   #0xCF, r9
ROM:002F0AC6                 extsb   r9
ROM:002F0AC8                 add     r14, r9         ; r9 = (r14, 0xCF)
ROM:002F0ACA                 ldi:8   #0, r4
ROM:002F0ACC                 mov     r9, r5
ROM:002F0ACE                 ldi:32  #CP_r4_to_@r5_till_r5plus_r6minus1, r12
ROM:002F0AD4                 call:D  @r12            ; clears from (r14, 0xCF) to (r14, 0xDE)
ROM:002F0AD4                                         ; column1 xors are at DC, is partially cleared, remain last byte
......
.......
ROM:002F01C8                 ldi:8   #0xD4, r0
ROM:002F01CA                 extsb   r0
ROM:002F01CC                 add     r14, r0         ; r0 = (r14, 0xD4)
ROM:002F01CE                 st      r0, @(r14, 0xFC)
ROM:002F01D0                 mov     r9, r4
ROM:002F01D2                 ld      @(r14, 0xFC), r5
ROM:002F01D4                 call:D  CP_@r4_to_@r5_r6len ; copy the cleared area (r14, 0xCF) to (r14, 0xD4), 0x10len
ROM:002F01D4                                         ; column xors area was from DC to EB, now cleared till E3 ?!?!

then bite rotation and other stuff, i got enought and thinked that a workaround was maybe easyer than recheck my dissassembling.

I'm sure that arnezami will figure it out clearly

FoxDisc · 6th April 2007, 14:06

Quote:

Originally Posted by arnezami

I'm currently analyzing the checksum functions etc....The function starting at 002F0CA6 ...

Are you using Ida Pro? If so, what processor do you tell Ida to use for decompiling?

arnezami · 6th April 2007, 14:07

Quote:

Originally Posted by Geremia

but this trick is quite frustrating for huge code changes, patch must be done with the less bit changes possible, so maybe i'll try to modify the bootloader (with this compensation trick) to skip the sum check but leave the xor check, this way the fw integrity will be guaranteed aswell and the xor calculation could be adjusted with easy.

As far as I understand the checksum functions this is a pretty good idea. Only 16 bytes of unused space would be needed to make sure the 4 columns will keep the same XOR. I don't think changing the last 16 bytes of a fw part themselves would be wise.

Maybe the best and easiest way to do this is change this:

Code:

002F0DB0 MOV	R7,R4

into this:

Code:

002F0DB0 LDI:8	#$00,R4

If i'm correct (and you would really have to check this, I haven't given this much thought

) this would make sure the SUM will always be 0 (also at intermediate points (within the fw part) but that doesn't matter I believe) while keeping the XOR calculations intact.

This function is used both at booting and before flashing (correct?) so there will be no discrepancies (like being able to flash but not being able to boot anymore).

Does this make sense?

Regards,

arnezami

PS.

Quote:

I'm sure that arnezami will figure it out clearly

I'm not sure of that myself yet. Also some time contraints here... (don't count on it soon)

Pelican9 · 6th April 2007, 16:09

Quote:

Originally Posted by FoxDisc

Are you using Ida Pro? If so, what processor do you tell Ida to use for decompiling?

Arnezami said Fujitsu FR 32-bit family (but it isn't work for me).

awhitehead · 6th April 2007, 16:27

Quote:

Originally Posted by Pelican9

Arnezami said Fujitsu FR 32-bit family (but it isn't work for me).

Read the thread on the xboxhacker! It is Fujitsu FR 32 family.

You don't need to byteswap this particular firmware file before you disassemble it.

In the thread on xboxhacker, I give link to source code of FR disassembler. It's not as nice as IDA Pro (primarily no automatic commenting and function tracing), however it works and it is free.

Code:

hostname:~/src/firmware/SD-S802A/tmp$ ./disfr 
Binary file to disassemble : SD-S802A-MC08_nokey.bin
Offset : 0x00200000
TBR register value [FFC00]: 
Swap bytes order (y/N) ? N
Done.
hostname:~/src/firmware/SD-S802A/tmp$ less SD-S802A-MC08_nokey.bin.txt

Code:

[...]
002F0AC2 A444                 ADD       #$04,R4
002F0AC4 CCF9                 LDI:8     #$CF,R9
002F0AC6 9789                 EXTSB     R9
002F0AC8 A6E9                 ADD       R14,R9
002F0ACA C004                 LDI:8     #$00,R4
002F0ACC 8B95                 MOV       R9,R5
002F0ACE 9F8C 002F 0198       LDI:32    #$002F0198,R12
002F0AD4 9F1C                 CALL:D    @R12
002F0AD6 C106                 LDI:8     #$10,R6
002F0AD8 CBFA                 LDI:8     #$BF,R10
002F0ADA 978A                 EXTSB     R10
[...]

The results are consistent to what Geremia posted from IDA Pro:

Quote:

Originally Posted by Geremia

Code:

ROM:002F0AC4                 ldi:8   #0xCF, r9
ROM:002F0AC6                 extsb   r9
ROM:002F0AC8                 add     r14, r9         ; r9 = (r14, 0xCF)
ROM:002F0ACA                 ldi:8   #0, r4
ROM:002F0ACC                 mov     r9, r5
ROM:002F0ACE                 ldi:32  #CP_r4_to_@r5_till_r5plus_r6minus1, r12
ROM:002F0AD4                 call:D  @r12            ; clears from (r14, 0xCF) to (r14, 0xDE)
ROM:002F0AD4                                         ; column1 xors are at DC, is partially cleared, remain last byte
......
.......
ROM:002F01C8                 ldi:8   #0xD4, r0
ROM:002F01CA                 extsb   r0
ROM:002F01CC                 add     r14, r0         ; r0 = (r14, 0xD4)
ROM:002F01CE                 st      r0, @(r14, 0xFC)
ROM:002F01D0                 mov     r9, r4
ROM:002F01D2                 ld      @(r14, 0xFC), r5
ROM:002F01D4                 call:D  CP_@r4_to_@r5_r6len ; copy the cleared area (r14, 0xCF) to (r14, 0xD4), 0x10len
ROM:002F01D4                                         ; column xors area was from DC to EB, now cleared till E3 ?!?!

Hope this helps.

Pelican9 · 6th April 2007, 16:41

Quote:

Originally Posted by awhitehead

Read the thread on the xboxhacker! It is Fujitsu FR 32 family.

You don't need to byteswap this particular firmware file before you disassemble it.

In the thread on xboxhacker, I give link to source code of FR disassembler. It's not as nice as IDA Pro (primarily no automatic commenting and function tracing), however it works and it is free.

I've read the all thread.
disfr isn't work on my xp. ("The system cannot execute the specified program.")
IDA pro work, but the file (SD-H802A.bin) has wrong byte order.

awhitehead · 6th April 2007, 17:11

Quote:

Originally Posted by Pelican9

but the file (SD-H802A.bin) has wrong byte order.

I slapped together a quick byteswapper for that purpose earlier in that thread. Link to source code

Someone else built distfr for Windows in this post. Maybe that will work for you.

It's probably obvious by now that I don't have a readily available Windows system to build on (And probably won't have until I figure out how to install Parallels on AppleTV, but that's a subject of a different post in a different forum). If it helps at all, I believe that any of the things that I write in C are compilable under Windows using either cygwin or mingw, if not using the more mainstream development tools.

Pelican9 · 6th April 2007, 17:45

Quote:

Originally Posted by awhitehead

I slapped together a quick byteswapper for that purpose earlier in that thread. Link to source code

Someone else built distfr for Windows in this post. Maybe that will work for you.

It's probably obvious by now that I don't have a readily available Windows system to build on (And probably won't have until I figure out how to install Parallels on AppleTV, but that's a subject of a different post in a different forum). If it helps at all, I believe that any of the things that I write in C are compilable under Windows using either cygwin or mingw, if not using the more mainstream development tools.

Thanks!
I've just written a swapper too. :-)
That windows build was which didn't work.

Geremia · 6th April 2007, 19:20

Quote:

Originally Posted by arnezami

.

Maybe the best and easiest way to do this is change this:

Code:

002F0DB0 MOV	R7,R4

into this:

Code:

002F0DB0 LDI:8	#$00,R4

If i'm correct (and you would really have to check this, I haven't given this much thought

) this would make sure the SUM will always be 0 (also at intermediate points (within the fw part) but that doesn't matter I believe) while keeping the XOR calculations intact.

This function is used both at booting and before flashing (correct?) so there will be no discrepancies (like being able to flash but not being able to boot anymore).

Does this make sense?

Yes, it's called both from the 3B 05 writebuffer and the bootloader booting sequence, a patch like you suggest whould work, i'll test this night.
At booting, only fwpart 1,2 and 4 will pass trought this function, while at flashing only part 1, 2, 4 and 5.

About dissassembling, the fw is byteswapped only in the flashrom if you read with external programmer.
If you got fw from my link or from the buffato SD-H802A, it does not need byteswapping, it's ok like this, and it's how the CPU sees it.

The CPU works in bigendian scheme, and the flash is mapped at address 0x200000.
I'm using IDApro set to FR 32bit family, CPU FR65E but it should be the same if you set FR50 or FR30. Just make sure to load the bin in ROM at address 0x200000

arnezami · 6th April 2007, 19:27

Quote:

Originally Posted by Geremia

Yes, it's called both from the 3B 05 writebuffer and the bootloader booting sequence, a patch like you suggest whould work, i'll test this night.
At booting, only fwpart 1,2 and 4 will pass trought this function, while at flashing only part 1, 2, 4 and 5.

You probably already know this but this means you (and everybody else who wants to do this) first have to do the patch disabling the SUM checking (using bit compensation). And only after that can you do another flash without being concerned about the SUM. So at least two flashes for a VID hack.

Right?

arnezami

Geremia · 6th April 2007, 20:26

Yes, i was too curious and i've tried already (my girlfriend can wait

)

modified the bootloader on an original fw, xors and sums compensated, flashed without errors.

then made a fw with this patched bootloader and a patched mainFW where only xors were correct, sum was wrong. Flashed, got error.

Ths was weird, so i made an original fw with a modified bootloader which had sum and xor not correct, to see if it give error.
Surprise, no flashing errors, this means that the bootloader is not checked and not flashed !?!?!
This is why my first bootloader patch of some days ago didn't work...the patch was probably correct, the problem is that the bootloader is not flashed

i've to take a look at the 3B 05 writebuffer comand, maybe the bootloader has another way to be flashed.

bcrabl · 7th April 2007, 11:13

By being able to modify the firmware, is it now possible to do backups from a genuine HD-DVD to a HD-DVD-Recordable without the need to find any of the private/proseccing keys from the software application?

I mean a hack like the original xbox360 hack. Read all the "unreadable" portions of the disc and write them at specific section of the recorable disk. Then direct the drive to read those specific bytes and make "software player" think that everything is like a normal situation.

arnezami · 7th April 2007, 11:33

Quote:

Originally Posted by bcrabl

By being able to modify the firmware, is it now possible to do backups from a genuine HD-DVD to a HD-DVD-Recordable without the need to find any of the private/proseccing keys from the software application?

I mean a hack like the original xbox360 hack. Read all the "unreadable" portions of the disc and write them at specific section of the recorable disk. Then direct the drive to read those specific bytes and make "software player" think that everything is like a normal situation.

Yes. This is (in principle) possible. Although its an awful lot of work.

What would be needed is to let the drive detect that is has a recordable inside. If so the Volume ID retrieval command should get its Volume ID from a different place (a place on the recordable we assigned ourselves to let the Volume ID be stored). In addition we would have to make sure the software player sees the recordable as a prerecorded disc (there may be checks to see this).

But looking at Geremia's last post we can't overwrite the bootloader itself so there is still quite a lot of work to do in order to do these kinds of complex changes to the drive. Not being able to overwrite the bootloader also limits our ability to "stealthen" the patched fw.

But if it all works it would mean that an (encrypted) recordable movie would work on all software players and would even play on the xbox 360 itself. I'm not sure if its possible now (or if it will stay possible in the future) to play unecrypted movies on the xbox 360. But if not this would be the solution to that too. All without knowing any of the AACS Keys (Device/Processing/Media/Vuk/Host Private keys etc.)

. Thats pretty spectacular...

In essence this is a kind of "bit-by-bit copy" attack (with only a slightly difference to the orginal disc)

This would be a cool project

. If some people stick their heads together (possibly at xboxhacker since xbox 360 owners would greatly benefit from this and they have already done this with the dvd player) this could be done in reasonable time I think.

But this does not allow you to do anything with the video/audio on the disc (like demux/recompress whatever). Its just for backup and playback.

Does that answer your question?

Regards,

arnezami

Btw: I think I now know enough to recalculate the 16 byte checksum values

. More on that later...
[edit] Hmmmm. Maybe not

. Looks like I really need to go into the Hash function (or identify it). Damn it.

lightshadow · 7th April 2007, 12:17

Quote:

Originally Posted by arnezami

But looking at Geremia's last post we can't overwrite the bootloader itself so there is still quite a lot of work to do in order to do these kinds of complex changes to the drive. Not being able to overwrite the bootloader also limits our ability to "stealthen" the patched fw.

Wouldn't it be very likely that the fw/boot loader could flashed?

I mean; M$ could benefit from such feature when your fw patch is released =)

When you connect a hacked XBox to XBoxLive, it gets revoked. Isn't that done in the firmware?

arnezami · 7th April 2007, 13:17

Ah. Stupid me. Its not a "normal" Hash function: its AES!

Or AES-G or AES-H or something...

Well it pretty much gotta be...

AES has 10 rounds too.

Duh.

Still not sure of course but this makes a lot more sense.

arnezami · 7th April 2007, 13:56

This seems to be way the 16 byte checksum is calculated for each fw part (if I didn't make any mistakes

):

The "Rand 16 bytes" are the ones right after the ToshSams string (in the current fw).

The "XOR columns" is the endresult of XOR-ing the columns of an fw part without the SUM correction value (the first 4 bytes of the fw part) and without the (proposed) checksum values themselves (the last 16 bytes of the fw part).

The output should be the same as the 16 bytes at the end of the fw part. If not the flashing will fail.

Still trying to figure out what hash/one-way function is used and how it is used.

Regards,

arnezami

Geremia · 7th April 2007, 14:32

with a criptographic specialist like you, we are all in good hope

BTW, i'm tracing a vendor specific CDB, it smells of "memory space dump", hope to be on the right track.

keep up the good work!

awhitehead · 7th April 2007, 16:01

Quote:

Originally Posted by arnezami

I'm not sure if its possible now (or if it will stay possible in the future) to play unecrypted movies on the xbox 360.

I might be misinterpreting what you mean by "unencrypted", however this post on AVSforum by President of R&B Films indicates that none of their HD-DVDs use AACS due to costs. In practical means that means "Chronos".

In addition I can think of a couple other commercially pressed HD-DVD disks that were reported to not utilize AACS: "Running Scared" in Germany, and "Nature's Colors".

To the best of my knowledge, these titles are currently playable by Xbox 360 with an HD-DVD add-on.

6th April 2007, 12:31	#21 \| Link
Geremia Registered User Join Date: Feb 2007 Posts: 71	This will help in concluding if the patched firmware is safe: - desolder the falsh - read it with external programmer, compare with original MC08 firmware - solder it back - flash by software the patched firmware i can provide - desolder the flash -read it again and compare with the original dump to see if any other region changes except the few bytes patched. Consider that i can do it myself as soon as i've time, probably tomorrow. From the assembler side, an help could be in finding a vendor specific CDB that can dump firmware by software. On xboxhacker thread there are info about the CDB table with relative function address. btw, here is the original SD-S802A MC08 firmware with part 3, 6 and 7 blanked, like the buffalo SD-H802A fw upgrade. http://www.sendspace.com/file/sleyls don't flash this (atm), but use only for dissassembling or comparing with your own flash dump. Last edited by Geremia; 6th April 2007 at 13:02.

6th April 2007, 13:11	#22 \| Link
arnezami Registered User Join Date: Sep 2006 Posts: 390	Just a little update: I'm currently analyzing the checksum functions etc and I'm making progress. Things I've figured out: The function starting at 002F0CA6 first cancels the XOR effects of the first 32 bits value in the fw part (so this is literally at 00000000 for the first fw part) and the 16 bytes at the end of the fw part. Its as if it did a 4-column XOR with these (total of 20 bytes) values zeroed out. This is to then recalculate the 16 bytes checksum values at the end of the fw. The function 002F0A44 re-calculates the actual 16 byte checksum values and has the 4 column XORs as input. The output of this function should be the 16 bytes value stored in the uploaded fw. So the only thing we need is this function which generates the right checksum data. It uses the data ToshibaSamsungST + random 16 bytes (from its current fw) and appears to do a hash (at 002F01B2) with 10 rounds on it (possibly RIPEMD-160). The fact that it gets these value from its current fw is probably because it won't (accidentally) overwrite a different type of firmware on its flash (which is good for us). This function also combines the 4 column XORs (byte-wise) including some bit shifting etc. The 32 bit value at the beginning of a checksummed fw part is the "SUM-correction-value": it makes sure the SUM will be 0. This should be added at the last moment if we would do our own checksum calculations. Essentially this correction value is not part of the XOR checksum. This whole checksum algo starts to make more and more sense to me now. I'm not there yet but its promising. arnezami Last edited by arnezami; 6th April 2007 at 13:31.

7th April 2007, 13:56	#38 \| Link
arnezami Registered User Join Date: Sep 2006 Posts: 390	This seems to be way the 16 byte checksum is calculated for each fw part (if I didn't make any mistakes ): The "Rand 16 bytes" are the ones right after the ToshSams string (in the current fw). The "XOR columns" is the endresult of XOR-ing the columns of an fw part without the SUM correction value (the first 4 bytes of the fw part) and without the (proposed) checksum values themselves (the last 16 bytes of the fw part). The output should be the same as the 16 bytes at the end of the fw part. If not the flashing will fail. Still trying to figure out what hash/one-way function is used and how it is used. Regards, arnezami Last edited by arnezami; 7th April 2007 at 14:16.

6th April 2007, 20:26	#33 \| Link
Geremia Registered User Join Date: Feb 2007 Posts: 71	Yes, i was too curious and i've tried already (my girlfriend can wait ) modified the bootloader on an original fw, xors and sums compensated, flashed without errors. then made a fw with this patched bootloader and a patched mainFW where only xors were correct, sum was wrong. Flashed, got error. Ths was weird, so i made an original fw with a modified bootloader which had sum and xor not correct, to see if it give error. Surprise, no flashing errors, this means that the bootloader is not checked and not flashed !?!?! This is why my first bootloader patch of some days ago didn't work...the patch was probably correct, the problem is that the bootloader is not flashed i've to take a look at the 3B 05 writebuffer comand, maybe the bootloader has another way to be flashed.

7th April 2007, 11:13	#34 \| Link
bcrabl Registered User Join Date: Feb 2007 Posts: 49	By being able to modify the firmware, is it now possible to do backups from a genuine HD-DVD to a HD-DVD-Recordable without the need to find any of the private/proseccing keys from the software application? I mean a hack like the original xbox360 hack. Read all the "unreadable" portions of the disc and write them at specific section of the recorable disk. Then direct the drive to read those specific bytes and make "software player" think that everything is like a normal situation.

7th April 2007, 13:17	#37 \| Link
arnezami Registered User Join Date: Sep 2006 Posts: 390	Ah. Stupid me. Its not a "normal" Hash function: its AES! Or AES-G or AES-H or something... Well it pretty much gotta be... AES has 10 rounds too. Duh. Still not sure of course but this makes a lot more sense.

7th April 2007, 14:32	#39 \| Link
Geremia Registered User Join Date: Feb 2007 Posts: 71	with a criptographic specialist like you, we are all in good hope BTW, i'm tracing a vendor specific CDB, it smells of "memory space dump", hope to be on the right track. keep up the good work!