Homebrew [WIP] twlnf, DSi NAND File ... thing ... testers with hardmod wanted

[Deleted member 424658]

Could you add some kind of whitelist flasher?

Pretty sure the scripting feature is meant for stuff like that.

 

[nocash123]

eMMC CID: bc57ba08f030363532435d4d4e01f300

The known CIDs should look as so:

  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

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.

 

[Jhynjhiruu]

The known CIDs should look as so:

  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

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.

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?

 

[smf]

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?

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.

 

[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.

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!

 

[JimmyZ]

The known CIDs should look as so:

  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

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.

His eMMC actually is in a different size, so naturally it would be a new part number, this is really a rare case.

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.

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.

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?

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.

 

[Jhynjhiruu]

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.

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?

 

[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?

Yes it's no use to you. I'm still expecting that apology for fat finger.

 

[Jhynjhiruu]

Yes it's no use to you. I'm still expecting that apology for fat finger.

Wait what?

 

[JimmyZ]

Wait what?

Nothing.

 

[dsigamerxl]

this project sure is going good as the days pass by

 

[nocash123]

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?

 

[Jhynjhiruu]

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?

The one that I supplied is correct.

 

[nocash123]

The one that I supplied is correct.

You have supplied two different CIDs. One is (hopefully) correct. The other one isn't correct.

 

[Jhynjhiruu]

You have supplied two different CIDs. One is (hopefully) correct. The other one isn't correct.

The one that wasn't an output from TWLnf's error screen.

 

[JimmyZ]

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?

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:

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

this curious case:

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

 

[ThisIsDaAccount]

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?

 

[nocash123]

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):

  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?

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.

Never heard of. Do you have more info on that?

 

[ThisIsDaAccount]

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):

  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

 

[JimmyZ]

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):

  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?

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.

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

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