Pretty sure the scripting feature is meant for stuff like that.Could you add some kind of whitelist flasher?
Pretty sure the scripting feature is meant for stuff like that.Could you add some kind of whitelist flasher?
The known CIDs should look as so:eMMC CID: bc57ba08f030363532435d4d4e01f300
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.The known CIDs should look as so:
Can you open your console and check the part number on the eMMC chip? Going by your CID, you have something else than KMAPF0000M-S998 or KLM5617EFW-B301 in there.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
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?
Yes, that's the CID that successfully decrypted my NAND. But now I can't load the HBMenu because a particular leaked system app exploit won't work!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.
His eMMC actually is in a different size, so naturally it would be a new part number, this is really a rare case.The known CIDs should look as so:
Can you open your console and check the part number on the eMMC chip? Going by your CID, you have something else than KMAPF0000M-S998 or KLM5617EFW-B301 in there.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
The fwtool branch you're using reads CID from RAM expecting it's still there, but unfortunately sometimes it's not, like your example.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.
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.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?
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?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.
Yes it's no use to you. I'm still expecting that apology for fat finger.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?
Wait what?Yes it's no use to you. I'm still expecting that apology for fat finger.
The one that I supplied is correct.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?
You have supplied two different CIDs. One is (hopefully) correct. The other one isn't correct.The one that I supplied is correct.
The one that wasn't an output from TWLnf's error screen.You have supplied two different CIDs. One is (hopefully) correct. The other one isn't correct.
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.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?
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/224
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
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?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.
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$gbaOkay, 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?
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."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?
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 5MIt 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