Pretty sure the scripting feature is meant for stuff like that.
The known CIDs should look as so:
Code:
MY ss ss ss ss 03 4D 30 30 46 50 41 00 00 15 00 ;DSi CID KMAPF0000M-S998
MY ss ss ss ss 32 57 37 31 36 35 4D 00 01 15 00 ;DSi CID KLM5617EFW-B301
MY ss ss ss ss 03 47 31 30 43 4D 4D 00 01 11 00 ;3DS CID
Technically yes I can open it but as it's actually someone else's I'd rather not. If I can get that exploit to work (I restored a previous NAND) I can run some more tests, but it's being annoying.
My CID according to fwTool (hexedited out of CID.bin) is BC 57 BA 08 F0 30 36 35 32 43 4D 4D 4E 01 FE 00, so it looks like the CID is what's wrong. Does TWLnf support loading the CID from a file?
Last edited by Jhynjhiruu,
Have you dumped nand and decrypted it with the CID that fwtool reported?
Because fwtool got my CID wrong when I launched it with sudokuhax and DSi homebrew channel, when I switched to using hbmenu 1.6 it got my CID correct.
Accurately dumping the CID appears to be kinda hard, allowing it to be supplied in a file does seem to be a good idea.
Last edited by smf,
His eMMC actually is in a different size, so naturally it would be a new part number, this is really a rare case.
The fwtool branch you're using reads CID from RAM expecting it's still there, but unfortunately sometimes it's not, like your example.
But fwtool origin and twlnf uses libnds to read CID directly from eMMC registers, nothing is more accurate than this.
CID in your transcript: bc57ba08f030363532435d4d4e01f300, that's only two characters off, and accidentally both errors 4->5 and e->3 they are adjacent on the keyboard.
On the other hand, by interpreting your transcript, twlnf actually did decrypt the MBR successfully since it passed the boot signature check, and the bootstrap check, but it failed the partition table white list.
So later I speculated you gave me the wrong dump, but in fact it's the CID, because your transcript is not verbatim.
Well, I can decrypt your MBR now, looks like it has a significantly larger 3rd partition(5.71MB versus normally 0.20 MB), but the first two partitions are identical. I guess I should loosen the check.
update: https://github.com/Jimmy-Z/twlnf/releases/tag/0.3.1a @Jhynjhiruu this should work for your case but you should NOT use direct NAND mount due to clumsiness.
Last edited by JimmyZ,
Hmm. So really, there isn't a lot of point in using it at all, because direct NAND mount is kinda the only benefit to using it - or am I completely mistaken?
I would like to add the CID for that eMCC chip to gbatek, but I am confused...
Which is the correct CID, the one ending with FE 00 or the one with F3 00?
It seems bigger than 240MB, but what is the exact total capacity for all partitions (plus bootarea etc)?
The boot info (at offset 200h) and bootcode (at 800h and up) is same as on all other DSi's?
The MBR (at offset 0) has different sizes for 1st & 3rd (and 2nd?) partition? And accordingly 2nd/3rd are located at higher offsets?
The chip part number & maker should be visible when just removing the bottom cover. With matching screwdrivers it should be no big issue to get there & to reassemble the console after reading/photographing the part number.
Btw. where are the CIDs from? I assume one of them comes from a file exported to SD card? And the other was read by software running on the console? Using GET_CID or ALL_GET_CID command? The latter might be a bit unrealiable as isn't intended for reading the CID by software.
Another thing that might unreliable is reading the CID (and actual data sectors) with wrong timings or wrong voltages. For such cases, it would be interesting to dump the OCR, CSD, and EXT_CSD registers.
And apropos fat fingers... is it really confirmed that there different CIDs reported by different programs? Or was it just a typo when typing up the CID manually?
Which is the correct CID, the one ending with FE 00 or the one with F3 00?
It seems bigger than 240MB, but what is the exact total capacity for all partitions (plus bootarea etc)?
The boot info (at offset 200h) and bootcode (at 800h and up) is same as on all other DSi's?
The MBR (at offset 0) has different sizes for 1st & 3rd (and 2nd?) partition? And accordingly 2nd/3rd are located at higher offsets?
The chip part number & maker should be visible when just removing the bottom cover. With matching screwdrivers it should be no big issue to get there & to reassemble the console after reading/photographing the part number.
Btw. where are the CIDs from? I assume one of them comes from a file exported to SD card? And the other was read by software running on the console? Using GET_CID or ALL_GET_CID command? The latter might be a bit unrealiable as isn't intended for reading the CID by software.
Another thing that might unreliable is reading the CID (and actual data sectors) with wrong timings or wrong voltages. For such cases, it would be interesting to dump the OCR, CSD, and EXT_CSD registers.
And apropos fat fingers... is it really confirmed that there different CIDs reported by different programs? Or was it just a typo when typing up the CID manually?
There is only one CID, and the one produced by fat fingers. 4-5 could have been caused by a single bit flip, then 3-e needs 3 bit flips, but they're both adjacent on keyboard, coincidence? and again twlnf didn't complain about boot signature and bootstrap so the CID it got was correct.
1st and 2nd partition are identical, 3rd is larger(and at a lower offset).
Mostly I'm just repeating myself.
usual partition table on a DSi:
Code:
status: 00, type: 06, offset: 0x00000877, length: 0x00066f89(205.94 MB)
C/H/S: 4/3/24 - 59/15/224
status: 00, type: 06, offset: 0x0006784d, length: 0x000105b3(32.71 MB)
C/H/S: 60/2/206 - 190/15/224
status: 00, type: 01, offset: 0x00077e5d, length: 0x000001a3(0.20 MB)
C/H/S: 191/2/222 - 191/15/224this curious case:
Code:
status: 00, type: 06, offset: 0x00000877, length: 0x00066f89(205.94 MB)
C/H/S: 4/3/24 - 59/15/224
status: 00, type: 06, offset: 0x0006784d, length: 0x000105b3(32.71 MB)
C/H/S: 60/2/206 - 190/15/224
status: 00, type: 01, offset: 0x00077e5b, length: 0x00002da5(5.71 MB)
C/H/S: 191/2/220 - 213/15/224
Last edited by JimmyZ,
This tool is looking great! Has nand mounting on 0.3.1a been tested yet? If it has, I'll try to fit it into https://dsiguide.me.
Also, just as a heads up, there's an edge case in tmd installation where even if the DSi NAND has enough open space for the DSiWare, the newly installed app will cause the maximum amount of DSiWare blocks allowed by the launcher to be exceeded, causing a brick. Does TWLnf take that into account?
Also, just as a heads up, there's an edge case in tmd installation where even if the DSi NAND has enough open space for the DSiWare, the newly installed app will cause the maximum amount of DSiWare blocks allowed by the launcher to be exceeded, causing a brick. Does TWLnf take that into account?
Okay, I am giving up on the two CIDs, knowing that one of the two CIDs is correct doesn't really help, and knowing that the one that is not in the error screen is correct or incorrect... that's too much for me, sorry. I am just adding both to gbatek (hoping that somebody will solve that nonsense someday):
Code:
BC 57 BA 08 F0 30 36 35 32 43 4D 4D 4E 01 FE 00 ;DSi blurb ;\one is correct?
BC 57 BA 08 F0 30 36 35 32 43 5D 4D 4E 01 F3 00 ;DSi blurb ;/other is typo?Never heard of. Do you have more info on that?
It happened to me a couple of times. If you look at systems settings Data Management, it says you have an X amount of blocks left for dsiware installation. If you use osfmount to add files for a dsiware that exceeds that amount of blocks, it will cause the launcher to not load when the DSi is turned on. That behavior is also emulated in no$gba
The one in his error screen transcript(bc57ba08f030363532435d4d4e01f300) is incorrect, that's why I say "So later I speculated you gave me the wrong dump, but in fact it's the CID, because your transcript is not verbatim."
the later one he provided, "BC 57 BA 08 F0 30 36 35 32 43 4D 4D 4E 01 FE 00", is correct.
This is the first time I've heard this, how's that calculated? if it's just reserving a fixed amount of space, TWLnf currently has it set at 5M
https://github.com/Jimmy-Z/twlnf/blob/master/arm9/source/main.c#L19
Similar threads
-
@
Sicklyboy:
@TwoSpikedHands, I'll preface this with the fact that I know nothing about the game, but, I think it depends on what your goals are. Are you trying to make a definitive version of the game? You may want to refocus your efforts on the EU version then. Or, are you trying to make a better US version? In which case, the only way to make a better US version is to keep on plugging away at that one
-
@
Sicklyboy:
I'm not familiar with the technicalities of the differences between the two versions, but I'm wondering if at least some of those differences are things that you could port over to the US version in your patch without having to include copyrighted assets from the EU version
-
@
TwoSpikedHands:
@Sicklyboy I am wanting to fully change the game and bend it to my will lol. I would like to eventually have the ability to add more characters, enemies, even have a completely different story if i wanted. I already have the ability to change the tilemaps in the US version, so I can basically make my own map and warp to it in game - so I'm pretty far into it! -
@
TwoSpikedHands:
I really would like to make a hack that I would enjoy playing, and maybe other people would too. swapping to the EU version would also mean my US friends could not legally play it
-
@
TwoSpikedHands:
I am definitely considering porting over some of the EU features without using the actual ROM itself, tbh that would probably be the best way to go about it... but i'm sad that the voice acting is so.... not good on the US version. May not be a way around that though
-
-
@
The Real Jdbye:
@TwoSpikedHands just switch, all the knowledge you learned still applies and most of the code and assets should be the same anyway -
@
The Real Jdbye:
and realistically they wouldn't
be able to play it legally anyway since they need a ROM and they probably don't have the means to dump it themselves -
-
-
-
-
@
Karma177:
do y'all think having an sd card that has a write speed of 700kb/s is a bad idea?
trying to restore emunand rn but it's taking ages... (also when I finished the first time hekate decided to delete all my fucking files
) -
-
-
-
@
Karma177:
@The Real Jdbye it hasn't given me any error trying to write things on it so I don't really think it's faulty (pasted 40/50gb+ folders and no write errors)
-
-
@
DinohScene:
when SD cards/microSD write speeds drop below a meg a sec, they're usually on the verge of dying+1 -
-
-
-
-
@
TwoSpikedHands:
@The Real Jdbye, I considered that, but i'll have to wait until i can get the eu version in the mail lol
-
I @ I-need-help-with-wup-wiiu:i need help with nusspli failed downloads, can someone respond to my thread? pretty please
I
@
I-need-help-with-wup-wiiu:
i need help with nusspli failed downloads, can someone respond to my thread? pretty please