flashcart_core
flashcart_core copied to clipboard
ntrteam
Supercard DStwo
Hello, I have found an index page of the DStwo team. Here are all EOS and firmware updates, as well as suitable DLDI and SDK tools available.
I hope so you can work to develop a suitable NTRBoot flasher for the DStwo.
Source;; http://down.supercard.sc/download/dstwo/
@hedgeberg I assume you've already had a look at this stuff to start off with?
Yes, looked through and pulled down everything on that page a couple months back. Unfortunately none of it is of any use, as its all stuff which was publically available at one point or another afaict, so we've gotten all the use we can out of it. At this point we need 2 things to make scds2/2+ work: the crypto layer and the flash read/write commands. The only good way to get this is basically simulate everything in the ds on PC and monitor how every single bit of data is read and when. It's not simple.
@AlexS2412 those aren't "firmware files", you dumped the rom used to bypass the whitelist on the 3ds. Unfortunately this isn't terribly useful. We have everything we need file-wise for scds2p. Unless someone finds source code for the scds2/2p firmware or menu lying around, im going to have to ask you guys to stop asking "if you've seen x", because the answer is yes unless you happen to have some pretty incredible luck. I don't want to be a jerk I know everyone is just trying to be helpful and wants more things supported it's just that we've already put significant time in to this project, it's probably best to assume we know what we're doing.
Excuse me for the intrusion, but if I remember correctly ~~@yellows8~~ was doing some RE on the sc dstwo, when ntrcardhax (the old one) was initially disclosed...
Yea, I've figured that c:' sorry for the inconvenience; he/she posted some notes anyways: https://173210.github.io/ds2
If @173210 could explain some of their work that would be really helpful.
It's related #10. I was reimplemented python version ds2-makeplug and @173210 collected ds2 related projects
ds2-makeplug project support extracting ds2_firmware.dat.
because ds2+ have very interesting feature, this cart can change to gateway mode using plugin.
actually, next step require RE of MIPS binaries, but I didn't continue that. :/
Yeah, I'm unsure to what level control of the MIPS is needed to reflash the SPI flash storage, tbh. It's seeming like we might need more info than originally thought. We've got a lot of RE to do. I still have yet to test the rework of DesMuMe by @Normmatt with this thing, see if we can't get it talking with that over powersaves. If we can, we can see what's being sent where.
well, if we have the MIPS binaries, we should be able to throw them into IDA and take a good long look.
Now would be a good time to actually setup one of those collaborative IDA projects, so we can all work together on it.
I mean I really hope that isnt necessary, thats a lot of shit to deal with. That being said, if the MIPS has access to the flash, it might be easier to write code to the MIPS using the ds2 plugin system... @d3m3vilurr are you familiar with writing ds2 plugins? If so, if I could check if the MIPS has access to the SPI flash, do you think you could write code for reading it?
@hedgeberg writing plugin is looks easy, but I don't know mips asm hehe...
Well, good luck with that, it seems like a lot of work...
(dat github avatars, they looks so similar between each other :[ ...)
Take it easy! You can figure out how to deal with the system even without reversing by looking at documents carefully! DSTWO has:
- JZ4740 microprocessor. (written in the official documents)
- W25Q16CV SPI flash (I figured out just by breaking up my cart!)
It is likely to boot from the flash.
According to JZ4740 external memory controller manual, it can boot from:
- external ROM at CS3 (other documents say CS4, so I'm not really sure. Check it out with your device!),
- USB device, or
- NAND flash
W25Q16CV is not a USB device nor a NAND flash, so it is likely to be mapped to CS3.
The document also says SACR3 register at address 0x1301003C gives the address of CS3. So you should dump the value of 0x1301003C (0x13010034, 0x13010038, and 0x13010040 may also be dumped as well in case it boots up from other static memory bank).
I do not have enough time to set up my development environment so I cannot help, but why don't you challenge if you think it is easy?
@173210 we had all those details for part numbers etc already. The main question is how the SPI flash is read/controlled and whether it's mastered by the proasic chip or the MIPS processor. If it's mastered by the mips processor then the remaining setup becomes relatively simple. If it's mastered by the proasic then it's more complex. We were hoping you could clarify. The main goal rn is to be able to directly read/write to SPI over the ntr cartridge bus. Have you ever modified the SPI flash on the scds2/2p successfully?
@hedgeberg No, I have not tested at all. But I am really sure the SPI flash is controlled by the MIPS processor because the processor needs a media to boot anyway. Without the SPI flash connected to the processor, it just wouldn't work.
The main goal rn is to be able to directly read/write to SPI over the ntr cartridge bus.
Probably you cannot. The flash is under control of the processor. Just write a plugin which would run on the processor.
Have you ever modified the SPI flash on the scds2/2p successfully?
No. But I have done a experiment to control the SPI over the NTR cartridge bus from the processor. That means the interaction between the cart and DS is controlled by the processor. You may think it is too inefficient because it also suggests the cart always needs the processor powered on, but the cart actually eats the power much even if it is not used xD
Yeah, I know the card uses a lot of power. Could you send me that experiment? That sounds like it might be exactly what we need tbh.
I can say my code is useless before looking my old storages for the it. I have made it to debug when the other interface is in use, and it is the only use case. I have read code in this repository. You are trying to run a homebrew to modify the flash on DS, right? That does not work because a DSTWO plugin is a different kind of a program, and it runs on the DSTWO. DS just runs the program which is prepared by the vendor. Handling everything on DSTWO is the easiest imho.
Not quite, you missed the point a bit. This repo contains the research side of ntrboot, the actual application side is: https://github.com/kitling/ntrboot_flasher Basically, theres a factory backdoor in 3ds arm9 bootrom which we can hook using flashcarts + sighax. However, we need to overwrite the commercial rom and the blowfish key for this. It doesn't matter how we go about it, that's the end goal. Any way, no matter how, that we can provide for users to modify the SPI flash of their cart and then revert, is the first goal. Once thats done, we can toy with getting compatibility set up.
So @hedgeberg and @kitling , if you manage to crack the dstwo and make it flashable, is it also possible to write other flashcart os to the cart as well? Thatd be something kind of neat if we made a singular open source firmware for all flashcarts :3 just an idea though.
Also i picked up on something interesting. It seems that there are more than four different HWIDS just for the dstwo alone. Here are the ids from my own carts but if you dont feel like looking at the images i have compiled a list of four different HWIDS i found the DSTWO has.
ChipID : 7FFFBEBF HW Rev: 7FFFBEBF
ChipID : F7FFFA7F HW Rev : F7FFFB7F
Chip ID: FFFFFFFE HW Rev: FDF5BFFE
Chip ID: 2CBFF33C HW Rev: 2CBFF37C
Image link from my own carts (http://imgur.com/a/il1Pl )
ChipID and HW Rev for DSTwo changes every time I attempt dump flash, so I wouldn't really rely on that.
The different chipid/hwrev sounds like the cart initialization issue we had a while back, so I don't think the information is useful.
So any headway in getting it to work? @kitling i saw you were making some great progress, but i havent heard much outside of this issue on github.
@AlexS2412 First off, I am not the one who has been working on it. Unfortunately, I haven't had much time to actually work on this stuff. However, I do believe a bunch of progress has been made, even if they haven't gotten to the point of testing yet.
