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
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
Xdqwerty:
something about ea reverse engineering the genesis so they could make their games there+1 -
-
@
BakerMan:
if they get permission from 4j (the studio who helped put minecraft on consoles), they could put the console edition tutorial worlds in the game, as seeds+1
and i mean all of them (if not, maybe a few highlights, like TU1, TU31, and TU69) -
-
-
-
-
