Hacking DS-Xtreme OpenSource Firmware Project

[AeroHex]

bahaha
yeah i see now,
i dont see it happening but i support it 100% now ds-x team suc* you think yeah well i think it too now.

 

[Apache Thunder]

Sorry to necro this old ass thread but there has been some relevant progress in this field. A few years back StuckPixel noticed the DLDI driver code for this cart has a 0x6000 offset to all read/write operations (or about 24577 sectors which is around 12MB of data reserved and hidden away from DLDI and USB access) when I was discussing my DS-Xtreme cart. I forget the exact details of how it came up only that I know it was him who noticed it first. It hasn't really left my mind since it came up and been hoping to see what their DLDI driver was hiding from us.

Anyways, currently it is not possible to access this region via the standard USB drivers. (maybe if you made custom ones but I'm not an x86 dev so I couldn't help with that) but the DLDI side is right up my alley. Had I known the source code to the DSX cart's DLDI driver was open source sooner, I would have done this a long time ago.

Anyways we have custom software booting direct from the cart now and not through it's launcher!

This tool can be used to access and write to the hidden region and is something I wrote myself with some assistance from lifehackerhansol:

https://github.com/ApacheThunder/dsxTool

For those worried about bricking, note that this is highly unlikely.Both the 1.1.3 and 1.1.2 updater files replace the region this tool works with so it is as easy and using the USB port to restore if something goes wrong.

lifehackerhansol by the way made a modified version of bootstrap (a component of hbmenu) for use in tandom with my tool:

https://github.com/lifehackerhansol/DSXulu

Currently the SRL header the cart uses is the only thing that appears to be missing from this hidden nand region. It looks like it's part of the FPGA firmware instead for some reason. (maybe they decided their nand was too slow for that part?)

While no progress has been made in reversing how the update.bin file or the updater works, we can effectively do 90% of what this project originally wanted.

By the way the hashes the updator uses to verify what version of cart firmware you got is a basic md5 hash over the first 0x292000 area of the hidden sector region!

Dump your hidden nand region with my tool and compute the Md5 yourself and compare with the update txt files to confirm yourself! I've already MD5 hashed the region after I put custom bootstrap on it so got my "customized" version of the cart to show up in the updater. Though of coarse I don't really have a custom update.bin to go with that. Mainly just added it so the updater can let me know if it got corrupted or not.

This means that one section of the update.bin is dedicated to the hidden region of the nand. The other to FPGA and the third to USB. (if that's handled seperate from the FPGA that is). SRL header seems baked into the FPGA firmware as it's not present in the hidden section of nand. The 1.1.3 updator seems to only bother updating this section of nand while the 1.1.2 updator does a full FPGA update along side the hidden region update. So 1.1.3 doesn't appear to contain a FPGA update different from what 1.1.2 has? The main difference only seems to be in the launcher SRL Arm binaries.

All data after the first 5264 sectors isn't updated by the 1.1.3 updator. Maybe the FPGA update updates this region. I don't know what is stored in this area besides the default skin which I did find a WinImage IMG container for.

I did not bother setting up a section for dsxTool to update the default skin container...I don't think people would care to do that if they are going to be using different firmware on this cart.

 

[SylverReZ]

Sorry to necro this old ass thread but there has been some relevant progress in this field. A few years back StuckPixel noticed the DLDI driver code for this cart has a 0x6000 offset to all read/write operations (or about 24577 sectors which is around 12MB of data reserved and hidden away from DLDI and USB access) when I was discussing my DS-Xtreme cart. I forget the exact details of how it came up only that I know it was him who noticed it first. It hasn't really left my mind since it came up and been hoping to see what their DLDI driver was hiding from us.

Anyways, currently it is not possible to access this region via the standard USB drivers. (maybe if you made custom ones but I'm not an x86 dev so I couldn't help with that) but the DLDI side is right up my alley. Had I known the source code to the DSX cart's DLDI driver was open source sooner, I would have done this a long time ago.

Anyways we have custom software booting direct from the cart now and not through it's launcher!

This tool can be used to access and write to the hidden region and is something I wrote myself with some assistance from lifehackerhansol:

https://github.com/ApacheThunder/dsxTool

For those worried about bricking, note that this is highly unlikely.Both the 1.1.3 and 1.1.2 updater files replace the region this tool works with so it is as easy and using the USB port to restore if something goes wrong.

lifehackerhansol by the way made a modified version of bootstrap (a component of hbmenu) for use in tandom with my tool:

https://github.com/lifehackerhansol/DSXulu

Currently the SRL header the cart uses is the only thing that appears to be missing from this hidden nand region. It looks like it's part of the FPGA firmware instead for some reason. (maybe they decided their nand was too slow for that part?)

While no progress has been made in reversing how the update.bin file or the updater works, we can effectively do 90% of what this project originally wanted.

By the way the hashes the updator uses to verify what version of cart firmware you got is a basic md5 hash over the first 0x292000 area of the hidden sector region!

Dump your hidden nand region with my tool and compute the Md5 yourself and compare with the update txt files to confirm yourself! I've already MD5 hashed the region after I put custom bootstrap on it so got my "customized" version of the cart to show up in the updater. Though of coarse I don't really have a custom update.bin to go with that. Mainly just added it so the updater can let me know if it got corrupted or not.

This means that one section of the update.bin is dedicated to the hidden region of the nand. The other to FPGA and the third to USB. (if that's handled seperate from the FPGA that is). SRL header seems baked into the FPGA firmware as it's not present in the hidden section of nand. The 1.1.3 updator seems to only bother updating this section of nand while the 1.1.2 updator does a full FPGA update along side the hidden region update. So 1.1.3 doesn't appear to contain a FPGA update different from what 1.1.2 has? The main difference only seems to be in the launcher SRL Arm binaries.

All data after the first 5264 sectors isn't updated by the 1.1.3 updator. Maybe the FPGA update updates this region. I don't know what is stored in this area besides the default skin which I did find a WinImage IMG container for.

I did not bother setting up a section for dsxTool to update the default skin container...I don't think people would care to do that if they are going to be using different firmware on this cart.

Another thing to mention, is that DSXulu has been re-based into nrioTool, which can be booted as an alternative menu to the default xMenu on numerous N-Card clones.

https://github.com/ApacheThunder/nrioTool