R4isdhchk: Add support for r4isdhc.hk (AKA r4igold.cc)

[EleventhSign]

First, rename r4igold.cc to r4isdhchk.cpp since this is the cart I have and have fully tested. The two carts may be similar in terms of both hardware and software, but I'll stick with the cart that I know this will work. Second, finally a working dump, restore and ntrboot inject for this cart. This means that this should now be fully supported! Tested on revisions 5.06, 7.00 and 7.07 of the R4 Dual Core (r4isdhc.hk) cart.

[angelsl]

Code looks okay at a glance. Thanks for still working on this so long after the hype died!

[kitlith]

There seem to be some odd indentation issues (at a guess, a spaces vs tabs issue that wasn't visible in your editor).

You also seem to be making sure that the code running is for the 5.06 revision. Any particular reason to choose that revision instead of some other revision? (I'm guessing that that revision allows access to all of flash while the other revision doesn't?)

Other than that, lgtm!

[EleventhSign]

Weird, it looked perfect on Notepad++. Indentation v2 should fix it (got rid of tabs altogether and just used spaces).

Revision 5.06 allows the entire B9S firm body to be saved at 0x30000 (ROM's 8000h) perfectly, but not on 7.00/7.07 at 0x40000. If I do that and dump the ROM with GM9, I get some weird sequence of data somewhere at the beginning which is definitely not part of B9S firm. I am suspecting that area is also used by the cart for something else. I am still looking (deeply) at the disassembled headers stuckpixel gave me before to see where and how the cart does it, (and possibly remap ntrboot requirements to one area/block of the flash, so far it's the main data area and the secure area remapping that are giving me the pain) but for now this is the easier method to achieve it.

[kitlith]

just rewrite the firmware (header) so that it's better and we understand it perfectly! /s

anyway, I think I get that, though now I have another question. When does the rewritten firmware take effect? Like, immediately after it's finished being written? After a reset of the cartridge? When do you change sw_rev to match? You should probably make a note in the logs that you're modifying the firmware as well.

I should have mentioned this the first time -- is there any particular reason why decrypt and encrypt's names were swapped? it doesn't really matter too much -- it just seems odd to 'encrypt in order to get raw flash'.

As for the indentation -- the project uses 4-wide spaces (in most places). If you used tabs, you probably have them set to look 4 spaces wide, but on github they appear to be 8 spaces wide. (which is the default in a lot of cases elsewhere too?) (basically I'm not surprised)

[EleventhSign]

The new header takes effect only after the cart has been reinitialized. So the sw_Rev (along with everything else like the mapping and the usable cart commands that are only available to that version) will remain until the cart is rebooted.

About the swap, my basis was the result of hardware dumping of the flash. I won't see the characters SPONGEBOB at 0x11100 until i "decrypt" the contents. Basically, the cart decrypts the contents for us, but in order to have a 1:1 with the flash, we "re-encrypt" it. And I think normally you don't decrypt and then store to a memory, but rather encrypt then store. Anyway that's just my opinion.

[kitlith]

huh. I didn't realize that it was encrypted on flash, and then transparently decrypted with commands. though I may have known the former awhile back.

decrypting and then writing to storage is a real possibility on some of these carts because they want to obfuscate the commercial rom in their updater but have easy access to it on flash. i.e. the encryption is to obfuscate the updater, not the flash. (I think one of the commands on the ak2i (noted as 'writeCommercialRom' somewhere) does transparent decryption of data while writing)

[EleventhSign]

Oh ok, so that happens. Anyway I can swap back the encryption/decryption in the code if needed. About the log you mentioned, I will add a LOG_INFO message there stating so.

[kitlith]

nah, you don't need to swap it back.

[d3m3vilurr]

i have a question. why rename filename?

[EleventhSign]

To match the name of the cart that I have. It's the one that I have tested and can say with absolute certainty will work with. This and the r4igold.cc may be similar and may work on the latter, but I couldn't say for sure and guarantee it's compatibility because I don't have it to test it.

[d3m3vilurr]

so, you should make new file instead rename. possibility of no more compatible old carts means just break changes. rename file is also weird. for example, another hacker makes new pr for supporting new similar carts, and they name is r4iblahblah.com. should we rename this? maybe we can find better name, like just r4igold_family

[EleventhSign]

Are we good with having 2 files there that will likely be targeting the same cart? I think one of the other will be deleted anyway, one way or another. And later end up with having just one. About the name, this probably will support a third one (R4iTT 3DS from R4itt.net), and these 3 carts don't have a common name other than having "R4" in them. Unlike the ones from r4isdhc.com, they can't be grouped as a family. I think 1 will have to be chosen while the others will have to be listed as "compatible".

[d3m3vilurr]

nah. I meant just you should split them in PR until passing test. btw you right. we don't want to split similar cart, so someone who one of reviewers also suggest to merge and name. I also agree, it's not a one family, I just said semantic thing. so probably compatibile is right, but also we don't know very first cart between r4itt, r4igold.cc and r4isdhc.hk. so I want remain original name for historical reason and want to add _comp or _compatible postfix if we choose rename.

and actual diff is https://github.com/EleventhSign/flashcart_core/compare/1342f55...EleventhSign:master changes in injectNtrBoot will occur breaking and we need to test that like your said. erase_cmd changed. is this fix a bug?

[EleventhSign]

Yes, it was a fix, otherwise the cart will only erase the first 64k (0x0) of the flash every time we issue the erase command.

[kitlith]

I mean technically, @d3m3vilurr , the original name is r4isdhc_dualcore.cpp, because that was what I originally looked at an updater for, before changing it to r4igoldcc.cpp because... i think there were "ri4sdhc dualcore"s that weren't the same cart. Also, there's no breaking changes being made here because it didn't work to start with.

I wish we had a better way to name these things, but it's not worth bikeshedding the exact name unless we had a better overall way to name things. maybe we could have a menu item for every supported cart and then it wouldn't matter in a user facing manner.

I'm inclined to merge as-is, make a pre-release of ntrboot_flasher, have people with r4igold.cc carts test, and so on. Sound good?

[d3m3vilurr]

but already you know, commit history is also important, file rename (include moving directory) makes it harder. now only can view https://github.com/ntrteam/flashcart_core/commits/master/devices/r4igoldcc.cpp but real is https://github.com/ntrteam/flashcart_core/commits/master/devices/r4sdhc_dualcore.cpp

so, if we can find good name, it should apply now. but if we can't, we should hold current filename. it's more benefit. also each committers and contributors want to change that file name when make the pr and push the commit, it looks madness..

anyway, beta testing sounds good. :p

[kitlith]

Alright, so, I finally got around to building it.

ntrboot_flasher_r4isdhc_r4igoldcc_test.zip

i'd appreciate if you tested it first as... my environment was a bit rusty, but it should be good.

[EleventhSign]

Yup, other than having the long file names created at backup (0_o just realized I didn't have a short name in the code), this one's good to go for pre-release (I think). Tested and worked on the 3 revisions.

[EleventhSign]

No tester, so I guess we can go ahead and release this as is then :-P Okay, this will probably be my last commit on this since this cart is pretty much end game for me (I have completed all the hacks I've originally planned for this cart). It's been fun. See ya!

[kitlith]

Yeah, I agree that I should just merge and call it good.

Though, I just have one more question, since you modified the stuff with different firmwares again: should we be telling the user to reinit the cart before attempting to flash if the firmware was modified?

[kitlith]

Ohhhhhh, I get it now.

We always have full access to flash, but stuff is in different locations depending on version. The remapping takes affect after a cart reset, and never affected flashing (other than "we'd need to flash to different locations")

[EleventhSign]

No need to re init the cart since the patching of the header happens together with the injection of ntrboot. In summary, everything is memcpy'd into block_0 i.e. patched header, firm, blowfish, and game header. Everything needed for ntrboot is now in this 64k block which will be flashed to the first chunk of the spi (offset 0x0). This means only this chunk is restored/erased/written, speeding up both inject and restore process.

(Made some mistakes about the offsets for blowfish and main data area remapping, but just in the comments, code is good. I'll fix that up if there are no more other edits to be done.)

[yva96]

Any News On This Card #129 Also Tried with r4isdhk option Stil didn't work

I can help you if Needed

[kitlith]

@yva96 Either your card is this card: in which case it's bricked and you're outta luck without a hardware flasher, -- or it's not this card, which means there's no news because this PR is unrelated to other cards.

ahem

@EleventhSign the way you made that work is really cool, and an awesome workaround to the issue of different mappings between carts. I approve.

[EleventhSign]

Cool. In that case, I'll fix the comments now :wink:

[handsomematt]

All issues seem resolved, will merge and tag.