|
TheSpecialist
|
 |
« Reply #720 on: January 18, 2006, 11:20:01 PM » |
|
Groepaz fixed an important bug in his MN103 IDA plugin, if you're using it, download the new version (see software thread)
|
|
|
|
|
Logged
|
|
|
|
|
SiliconIce
|
|
« Reply #721 on: January 18, 2006, 11:55:01 PM » |
|
I have forked the large post from the X-S forums and related comments to a new thread to keep this thread on topic since it's long already! Feel free to discuss the DVD relevant aspects here in this thread, but other topics in that thread. The forked thread is here: http://www.xboxhacker.net/index.php?option=com_smf&Itemid=33&topic=229.0 |
|
|
|
|
Logged
|
-- SiliconIce
|
|
|
|
xordef
|
|
« Reply #722 on: January 19, 2006, 03:40:24 AM » |
|
Hi,
Let's pretend that:
1) At factory, all components in an Xbox 360 are programmed with symmetric keys unique for that box
2) The keys are unique per component, and are there simply to complicate the manufacturing of general mod chips - not necessarily meant to be secret in themselves
3) The key for the dvd-rom is stored in the flash
From the above we get the possibility to create modchips. We can change the dvd flash into one that fakes all the necessary data to get the Xbox 360 into thinking the disc in the drive is authentic. Please note (some misunderstand this) - this is a very basic hack and gives us absolutely nothing with respect to running unsigned code/homwbrew. It will however allow pirating of games, which some might have an interest in.
However, this procedure is complicated. It needs to be done per dvd-rom, per box, and requires some skill. It will not blossom into a huge mod market, and Microsoft most certainly knows this. The unique key stops us from creating a single modchip replacing/changing the data sent from the dvd.
If there's a possibility to write and/or read to the dvd flash from the actual bus we can create a self learning modchip though. At first use it will simply send the commands to read out the flash - extract the key and it can then perform man in the middle attacks. If there are commands to write to the flash it can then do the same as the first and complicated method above.
If there are no commands to write/read to the flash from the bus the vector is closed - and that's why the information in the now forked thread is highly relevant, since it indeed claims that the dvd flash (at least the key) is written to using ATAPI commands over the bus. Usually, if you can write you can read as well (for verification) - and it's possible that there's a hole left open that way.
If so, expect it to be closed in future firmwares.
(Of course, you can always attach the self learning chip to the actual flash chip in the dvd ... )
|
|
|
|
|
Logged
|
|
|
|
|
Tiros
|
|
« Reply #723 on: January 19, 2006, 12:56:00 PM » |
|
Once the unlocker exposes the correct drive size (cmd 25), windows still can't see the filesystem.
Is it beccause of the FS format, or because it doesn't know the size has changed, or both?
|
|
|
|
|
Logged
|
|
|
|
|
TheSpecialist
|
|
« Reply #724 on: January 19, 2006, 01:01:11 PM » |
|
Once the unlocker exposes the correct drive size (cmd 25), windows still can't see the filesystem.
Is it beccause of the FS format, or because it doesn't know the size has changed, or both?
XBOX Filesystem is completely different, so there's no way windows explorer can read it. See the link in my 'article' on xbox game discs on this site (main page/articles/dvd rom) for info about the XBOX filesystem. Basically, you have to read LBA sector 20h to find a pointer to the sector containing the root directory structure. I've already upgraded my unlocker to read the xbox files system (I wanted to see if the placeholders were in 'between' files). I could now pretty easily upgrade it to dump all files, but I've some other priorities right now  Still SO much work to do and so little time ...  *EDIT* Oops, I forgot to 'publish' the article, it should work now. I think it's a good idea to summarize as much as info as possible in 'articles', so that we can copy that directly into the Wiki when it's ready. |
|
|
|
« Last Edit: January 19, 2006, 01:41:05 PM by TheSpecialist »
|
Logged
|
|
|
|
|
Geremia
|
|
« Reply #725 on: January 19, 2006, 02:59:13 PM » |
|
btw...xiso v1.1.5 is already able to read out files directly from an unlocked samsung drive
|
|
|
|
|
Logged
|
|
|
|
|
jumba
|
|
« Reply #726 on: January 20, 2006, 12:19:08 AM » |
|
2. From all drive swaping experiments so far, the result are NGs. Unless we can get good news from Darkfly, we may face the fact that each drive has its own key or serial which married with the 360 it came with. That will mean a general firmware modification will not be feasible. We have to find feasible way to extract the key/serial of each drive then put it into each one's modified firmware. Besides that, there are so many models. So eventually maybe a firmware modification for commercial DVD drive will be necessary. On the other hand, if we modify the commercial DVD burner's firmware, then everyone can use this approcah because the drive is commercial.
There is another alternative if the handshake permits it. There has been speculation of a virgin drive state which causes the unique serial to be flashed the first time the console sees the "new" drive. Flashing routines inside the firmware may support this theory. One approach would be to try to replicate that state in a custom firmware (yes, still one per drive manufacturer). If the handshake sends the console serial to the drive to get checked, the drive could flash it and everything would be ok. Or alternately just return whatever the console sends and ignore the serial cooked into the firmware. If the algorithm is less naive (I assume this is the case) then extract+burn may be the only viable route. The drive is a fairly basic bit of electronics. All the checking would be done in the xbox all the console would need to is request the S/N. A lock and unlock disc would need to be made like the one for the xb1 HD. |
|
|
|
|
Logged
|
|
|
|
|
Gael360
|
|
« Reply #727 on: January 20, 2006, 02:57:37 AM » |
|
Only thing I'm uncertain of are the function of the security placeholders. I'm going to do some experiments tonight that hopefully will reveal some insights on this subject Note that this is XBOX1 of course, hehe, but will hopefully reveal very interesting info ... I made a test on the Xbox360 filesystem : I read/parse the entire filesystem, and at every file/folder I find, I use the offset address and size to know which sectors are used by this file/folder. For every sector in use, i write a byte on a 'map file', which has 3567872 bytes for the 3567872 sectors of the XDVDFS session (1783936 on layer0 and 1783936 on layer1). After parsing some games raw dump, I found that the only 'non used by file/folder' sectors are at the beginning and the end of the session. But every sector between this two zones is used by a file or a folder. So I really think there is NO security placeholders on the Xbox360 DVDs. Do you agree ? |
|
|
|
|
Logged
|
|
|
|
|
MacDennis
|
|
« Reply #728 on: January 20, 2006, 03:50:03 AM » |
|
The drive is a fairly basic bit of electronics. All the checking would be done in the xbox all the console would need to is request the S/N. A lock and unlock disc would need to be made like the one for the xb1 HD.
It doesn't need to do this. And there isn't a serial number stored in the drive to begin with. The shared 'secret' key is known by both console and drive, they both know this key otherwise they can't communicate with each other. It isn't exchanged! The key is used in an AES routine to encrypt/decrypt communication between console and drive related to authentication of a x360 disc. This information has been mentioned several times in this thread. And now for some new information, encryption is *only* used when a x360 disc is being *authenticated* on a x360 console. Encryption is *not* used when a xbox1 disc is authenticated on a x360 console. And just for the record, knowing this key does not allow you to magically run unsigned code or a backup disc. Encryption is only being used to obfusctate the real underlying authentication procedure. It's simply another layer of protection. Nothing more, nothing less. Ofcourse some kind of 'x360 setup disc / tool' must exist. Such a tool could simply write a new dvd-rom secret key to both console and dvd-rom. This is not some kind of public/private key scheme, there's only one (shared) 128-bit key being used by console and dvd-rom. Probably other keys are used for other parts of the console. And no, you can't brute force this key. There are two ways to read your key at this moment. a. dump your own firmware b. log access to your own firmware Please try to stay on topic people, this (technical) thread is all about hacking DVD firmware, not about dumping games or creating ISO's. |
|
|
|
« Last Edit: January 20, 2006, 04:53:32 AM by MacDennis »
|
Logged
|
|
|
|
|
wildje
|
|
« Reply #729 on: January 20, 2006, 03:52:25 AM » |
|
Only thing I'm uncertain of are the function of the security placeholders. I'm going to do some experiments tonight that hopefully will reveal some insights on this subject Note that this is XBOX1 of course, hehe, but will hopefully reveal very interesting info ... I made a test on the Xbox360 filesystem : I read/parse the entire filesystem, and at every file/folder I find, I use the offset address and size to know which sectors are used by this file/folder. For every sector in use, i write a byte on a 'map file', which has 3567872 bytes for the 3567872 sectors of the XDVDFS session (1783936 on layer0 and 1783936 on layer1). After parsing some games raw dump, I found that the only 'non used by file/folder' sectors are at the beginning and the end of the session. But every sector between this two zones is used by a file or a folder. So I really think there is NO security placeholders on the Xbox360 DVDs. Do you agree ? My interpretation would be either no security placeholders OR the location of the holders are variable thus different on every dvd OR the placeholders are outside of your read area. |
|
|
|
« Last Edit: January 20, 2006, 06:25:21 AM by wildje »
|
Logged
|
|
|
|
|
MacDennis
|
|
« Reply #730 on: January 20, 2006, 04:45:08 AM » |
|
So I really think there is NO security placeholders on the Xbox360 DVDs. Do you agree ?
Interesting .. Well, look at this post about a x360 dvd layout structure: http://www.xboxhacker.net/index.php?option=com_smf&Itemid=33&topic=76.760This layout also confirms your findings. There are no dummy / garbage / security / placeholder sectors in between files. It has already been proven that xbox1 discs do have these sectors. The following needs to be done. Do a raw sector dump (not filesystem parsing) of a x360 disc by using the swap method as explain in this post: http://forums.xbox-scene.com/index.php?showtopic=470638. Best would be to use a tool like CloneCD. I really would like to know if CloneCD reports any bad sectors in the data zones of layer 0 and layer 1. And we also don't know what the small ring is for on x360 discs, the small ring between the video partition and the game partition: http://www.free60.org/wiki/DVDOnly x360 discs have it, not xbox1 discs. It's possible that security placeholder data has been moved to this ring. Regarding the XBOX1 drive firmware, it doesn't seem to contain any routines which use/read the security placeholders. It doesn't actually need to because they are just 'normal' sectors which can be read with the standard read (0x28) command. But these placeholders do seem to contain important information. It is now assumed that the XBOX1 placeholders are a 'backup security plan' in case the first protection would be broken. XBE's could check these placeholders. Maybe it's related to the new 'media check' used on the newer XBOX1 discs from 2004 and on. Anyone have any information regarding this new media check? Gael, nice work regarding your tools. Great to see tools like this being shared with the community! |
|
|
|
|
Logged
|
|
|
|
|
jumba
|
|
« Reply #731 on: January 20, 2006, 06:22:56 AM » |
|
The drive is a fairly basic bit of electronics. All the checking would be done in the xbox all the console would need to is request the S/N. A lock and unlock disc would need to be made like the one for the xb1 HD.
It doesn't need to do this. And there isn't a serial number stored in the drive to begin with. The shared 'secret' key is known by both console and drive, they both know this key otherwise they can't communicate with each other. It isn't exchanged! The key is used in an AES routine to encrypt/decrypt communication between console and drive related to authentication of a x360 disc. This information has been mentioned several times in this thread. And now for some new information, encryption is *only* used when a x360 disc is being *authenticated* on a x360 console. Encryption is *not* used when a xbox1 disc is authenticated on a x360 console. And just for the record, knowing this key does not allow you to magically run unsigned code or a backup disc. Encryption is only being used to obfusctate the real underlying authentication procedure. It's simply another layer of protection. Nothing more, nothing less. Ofcourse some kind of 'x360 setup disc / tool' must exist. Such a tool could simply write a new dvd-rom secret key to both console and dvd-rom. This is not some kind of public/private key scheme, there's only one (shared) 128-bit key being used by console and dvd-rom. Probably other keys are used for other parts of the console. And no, you can't brute force this key. There are two ways to read your key at this moment. a. dump your own firmware b. log access to your own firmware Please try to stay on topic people, this (technical) thread is all about hacking DVD firmware, not about dumping games or creating ISO's. The only bank0 seems to contain data @ 401A'h to 4029'h so the the assumption this is the unique key! The RE code shows no direct reference to this data field. Please supply details how this is used |
|
|
|
|
Logged
|
|
|
|
|
Gael360
|
|
« Reply #732 on: January 20, 2006, 06:27:04 AM » |
|
The following needs to be done. Do a raw sector dump (not filesystem parsing) of a x360 disc by using the swap method as explain in this post: http://forums.xbox-scene.com/index.php?showtopic=470638. Best would be to use a tool like CloneCD. I really would like to know if CloneCD reports any bad sectors in the data zones of layer 0 and layer 1. And we also don't know what the small ring is for on x360 discs, the small ring between the video partition and the game partition: http://www.free60.org/wiki/DVDOnly x360 discs have it, not xbox1 discs. It's possible that security placeholder data has been moved to this ring. Sorry for being a little bit off topic... For the bad sectors I already found them : starting at LBA 19408 for 1072 sectors (so until 20479). This is the small ring you can see on x360 discs. So to list the entire disc : LBA0 to LBA19407 : TOC and video session LBA19408 to LBA20479 : bad sectors (visible ring) LBA20480 to LBA129823 : not sure, fake lead out I think LBA129824 to LBA1913759 : XDVDFS session on layer0 (129824 = 0x01FB20...). The size is 1783936 sectors LBA1913760 to LBA3697696 : XDVDFS session on layer1. The size is 1783936 sectors For not hijacking this thread, we can discuss about raw dumps here : http://www.xboxhacker.net/forums/index.php?topic=224.0 |
|
|
|
|
Logged
|
|
|
|
|
MacDennis
|
|
« Reply #733 on: January 20, 2006, 06:57:42 AM » |
|
The only bank0 seems to contain data @ 401A'h to 4029'h so the the assumption this is the unique key! The RE code shows no direct reference to this data field. Please supply details how this is used
Unique key is at offset 0x401A - 0x4029 in the Toshiba/Samsung firmware. Encryption is used only in x360 mode. And encryption seems to be only used in the following commands / opcodes: - READ DVD STRUCTURE - 0xAD
- MODE SELECT - 0x55
- MODE SENSE - 0x5A
You first have to find the handlers in the firmware for these opcodes and work from there .. It's also a good idea to find the location of the AES encryption/decryption routines. Freely available AES implementations might help you find the AES routines. The routines can be as small as around 1000 bytes if written in assembly. http://www.iaik.tu-graz.ac.at/research/krypto/AES/old/%7Erijmen/rijndael/ |
|
|
|
« Last Edit: January 20, 2006, 07:49:51 AM by MacDennis »
|
Logged
|
|
|
|
|
FuzzyLogic
|
|
« Reply #734 on: January 20, 2006, 07:25:44 AM » |
|
Unique key is at offset 0x401A - 0x4029 in the Toshiba/Samsung firmware.
At the HL firmware the 16 byte key is stored at 0x4F00-0x04F0F. at offset 0x4F80-0x4F87 another 6 bytes are different to the posted HL3120L fimware. |
|
|
|
|
Logged
|
|
|
|
|
TheSpecialist
|
|
« Reply #735 on: January 20, 2006, 08:55:10 AM » |
|
Unique key is at offset 0x401A - 0x4029 in the Toshiba/Samsung firmware.
At the HL firmware the 16 byte key is stored at 0x4F00-0x04F0F. at offset 0x4F80-0x4F87 another 6 bytes are different to the posted HL3120L fimware. I've put all information I could think of, related to the encryption, in one article. You can edit/update this info. I think it's a good idea to start summarizing relevant info like this into articles, so we can copy the info into the wiki once it's ready. Siliconice is working on it. Everybody is free to update articles, so if you have new relevant info or feel I have made a mistake, please feel free to update/modify the article. |
|
|
|
« Last Edit: January 20, 2006, 10:01:33 AM by TheSpecialist »
|
Logged
|
|
|
|
|
TheSpecialist
|
|
« Reply #736 on: January 20, 2006, 08:59:23 AM » |
|
Sorry for being a little bit off topic...
For the bad sectors I already found them : starting at LBA 19408 for 1072 sectors (so until 20479). This is the small ring you can see on x360 discs.
So to list the entire disc :
LBA0 to LBA19407 : TOC and video session
LBA19408 to LBA20479 : bad sectors (visible ring)
LBA20480 to LBA129823 : not sure, fake lead out I think
LBA129824 to LBA1913759 : XDVDFS session on layer0 (129824 = 0x01FB20...). The size is 1783936 sectors
LBA1913760 to LBA3697696 : XDVDFS session on layer1. The size is 1783936 sectors
Hi Gael, congrats on your nice tool Yes, i think your findings may very well be correct. Original xbox file system's security placeholders were really frustrating to developers since they could not optimize disc layout. I think that's why m$ may have chosen to put the placeholders area into the beginning of the disc for the 360. BTW, I think it's a good idea to only refer to PSN's and not LBA's, since LBA's can have several meanings for the XBOX of course (depending on the partition that's referred to). |
|
|
|
« Last Edit: January 20, 2006, 11:29:15 AM by TheSpecialist »
|
Logged
|
|
|
|
fghjj
Newbie
Posts: 4
|
|
« Reply #737 on: January 20, 2006, 11:44:27 AM » |
|
I tried reading as much as I could, but it's a long thread.
-If we can modify the Toshiba/Samsung/Hitachi-LG firmware (no signature or integrity check done? some free bytes where we can inject code?)
-If the XDVDFS is located on areas burnable for normal dvd-writers
Would it be possible to hijack drive functionality _after_ the authentication procedure? So you can authenticate with any retail disc, and then have it spin down and insert a backup disc _before_ default.xex is loaded (or the FS info is read)? Or would the x360 BIOS see this as a non functional drive because a timeout is reached? I understand this isn't your average x86 assembly though.
|
|
|
|
|
Logged
|
|
|
|
|
TheSpecialist
|
|
« Reply #738 on: January 20, 2006, 11:49:10 AM » |
|
I tried reading as much as I could, but it's a long thread.
-If we can modify the Toshiba/Samsung/Hitachi-LG firmware (no signature or integrity check done? some free bytes where we can inject code?)
-If the XDVDFS is located on areas burnable for normal dvd-writers
Would it be possible to hijack drive functionality _after_ the authentication procedure? So you can authenticate with any retail disc, and then have it spin down and insert a backup disc _before_ default.xex is loaded (or the FS info is read)? Or would the x360 BIOS see this as a non functional drive because a timeout is reached? I understand this isn't your average x86 assembly though.
Still nobody that tried flashing the 360's drive, so it's still uncertain about signatures, but it seems highly unlikely. Somebody told me he's going to try to flash his 360 FW this weekend, so, hopefully we'll know more about this soon There's more than enough free space in the FW's for some code 'extension' by the way About hotswapping disc: you can't eject the tray, since kernel will reset the 'authentication' bit at an eject. So, you'd have to open your drive, stop disc spinning once the control data block has been read, just before it's going to read the filesystem. I think this is pretty much impossible So, basically, forget about any PS2-like disc swapping trick |
|
|
|
« Last Edit: January 20, 2006, 12:16:54 PM by TheSpecialist »
|
Logged
|
|
|
|
|
darkfly
|
|
« Reply #739 on: January 20, 2006, 12:05:48 PM » |
|
I have flashed the firmware of my drive, but the only thing that I changed was the key region which I blanked out with all FF. Obviously the drive did not work after that. Do you have any areas you want me to attempt to modify which would affect the hash, I wouldn't think the key area would be part of the signature due to its random nature.
|
|
|
|
|
Logged
|
|
|
|
|
