Hacking Can we install and run DSiWare in SysNAND using Gateway?

[cearp]

Thank you. Once last question, though slightly off-topic: why did you make the flashcardtimewarp.cia a broken cia? Couldn't you just have made a cia of the DS Flashcard Whitelist title from an older system firmware version? Or would that not be as effective?

well i had to edit/'break' the tmd because i had to change the version number of the cia to a high number (i just maxed it) - because otherwise it would not install over the current one in your 3ds so i just took the first ds whitelist, and changed the version number to the maximum it can be, very simple

 

[apoptygma]

I still don't understand - does the flashcardtimewarp.cia have a valid ticket? If it doesn't, why doesn't it need one?

AFAIK - It doesn't need one because that file (the whitelist) wasn't signed, unlike most binaries in sysnand.

 

[cearp]

AFAIK - It doesn't need one because that file (the whitelist) wasn't signed, unlike most binaries in sysnand.

it does need one (i'm pretty sure)

 

[Apache Thunder]

The DS Cart white list is a system title. I don't think system titles (or at least most of them) need tickets. That doesn't mean they aren't signed though. Not entirely sure why the white list cia can work on unmodified sysnand.

In actuality, I think the modification broke the file. The installed title doesn't pass sig checks so the 3DS ignores it. (since the 3DS doesn't need this file to boot, it doesn't result in a brick)

This results in a non functional white list file. So I'm guessing that results in it allowing all DS carts to boot. (except for really old flashcarts like original R4 as that one doesn't pass basic sanity checks elsewhere in TWL_FIRM).

However if it does indeed not require a sig check, I could bet someone could write custom code in the file overwriting the original white list to cause a buffer overflow or some other code to exploit something and could be a means of a permanently installed ROP chain. But I'm just thinking out loud at this point.

Which gets me to thinking. I wonder if someone tried to write a Launcher.dat file from Gateway or some other exploit they use most often to the root of the fat16 partition and re-encrypted and injected it back into NAND. Because the file is encrypted properly with the rest of the file system, it doesn't cause a brick.

Also because the file isn't used by any of the existing system titles the 3DS effectively doesn't know that it's there (thus it doesn't matter if it's "signed" or not as it's not an executable file the system recognizes).

It's just an extra file that isn't normally accessed by anything. (like having an extra txt file in a folder somewhere. The system doesn't really care that it's there since it isn't normally executable and isn't accessed by the system during bootup/normal operation). As long as it's presence doesn't brake the encryption of the filesystem it's injected into, all should be fine.

Then modify the browser/MSETT rop chain to access it from NAND instead of the SD card.

In the end it would probably be pointless to do, but would be an interesting experiment.

 

[cearp]

The DS Cart white list is a system title. I don't think system titles (or at least most of them) need tickets. That doesn't mean they aren't signed though. Not entirely sure why the white list cia can work on unmodified sysnand.

they need tickets, that is why the ticket.db contains the system titles, and if you delete it the 3ds will not boot.
the whitelist is stored in the twl partition, we do not have public access to that

 

[Hammyface]

If it has something to do with the system booting into DS/DSi mode, I am surprised a hack for DSiware has never been figured out by use of a DStwo or other type flashcart.