[BUG] Switching Emunand wont work, if SD is formatted with multinand tool.

[MrTSXV]

If a sd card is formated with this tool Gbatemp 3DS Multi EmuNAND Creator. GodMode9 is not able to switch the Emunands.

GodMode9 v1.6.3 SD Card: SanDisk Extreme 64GB

Stuck on "Current Emunand offset is 0000001 Switch to next offset?" By pressing yes (A) the screen shows the screen again until you press No (B). Emunand are not switched.

LG

[MrTSXV]

Probably the offsets wont work as intended, either by GodMode or the mentioned tool.

[MrTSXV]

Luma works with it btw.

[d0k3]

It should work. We will need more details and I will need your help testing. Is it an O3DS or an N3DS? What exact settings did you use in Multi EmuNAND Creator?

Just a quick hint (please, don't do this now, I'll need you for testing) - GM9 (nightly) can now set up a Multi EmuNAND for you, and it will do so wasting as little space as possible.

[MrTSXV]

I created Nand Backups (full) with Decrypt9WIP latest release. I injected both Nand.bin files as RedNands, Decrypt9 shows the Emunand as RedNand.

Its an Old3DS

Yeah, I could do some testing for you :)

[MrTSXV]

I will now try to do it again, to confirme both nands are injected as rednands, than I will retry it with injecting both files as emunands.

[d0k3]

So, you created a Multi RedNAND consisting of 2x RedNANDs in Multi EmuNAND tool, correct?

[MrTSXV]

Yes that what I did, I will redo it to confirm it again.

[d0k3]

Okay, next question... you know how to handle a hex editor? I suggest HxD. In HxD, open your SD card (it's in Extras -> Open drive for me). Seach for "NCSD" (case sensitive), and list all offsets where it is found. After you're done redoiung your earlier tests, ofc.

[MrTSXV]

14ABD4F 14ABED2 14ABF18 14BEE8F 14C0719 14C095C 14C0C58 14C0D22 1672500 16ED1A4 16EE7FC 171EFB4 172060C 5312E68 531306C 5313270 5313D05 5314CA8 There are a lot of NCSD entries any specifically

[MrTSXV]

Okay now I formated a 128GB SD SanDisk Extreme, it seems GodMode9 is switching it sucesffuly. But the 64GB SD dont wokr even after reinjecting

[d0k3]

Okay, goddammit. Offsets look fishy. Let's try to figure out the 64GB card then.

I just need the offsets that end with "00". There have to be at least two of them, and the first one has to be at 0x300.

EDIT: You need to open the physical drive in HxD, just to be clear.

[MrTSXV]

How can I jump to this offset in HxD. Installed it the first time.

[MrTSXV]

Okay I compared it to the Nand files: 1672500 is one offset in the other one is 5313270

[MrTSXV]

strangly the last offset NCSD header or whatever is also in 531306C

[d0k3]

You're doing something wrong. What you need to do is, insert the SD card into your computer via a card reader, then access the physical drive in HxD. Screenshots below (german, sorry):

https://i.imgur.com/Dt4iJwm.png https://i.imgur.com/ee86bvg.png (you need to select your SD card here) https://i.imgur.com/1ydF7VQ.png

Hope that helps. On a RedNAND formatted card, the first offset for "NCSD" has to be 0x300.

EDIT: You may need to start HxD with administrative rights to do so. Unsure.

[MrTSXV]

Da du dein Betriebsystem auf deutsch hast, nehme ich an du sprichst deutsch.

Ja, genau das habe ich gemacht. Ich hab bereits herausgefunden, dass die Suche nach NCSD auch die GodMode9.firm und Decrypt9WIP einträge im Hex Editor anzeigt, daher so viele. Ich hab auch bereits die NAND.bin Datein nach dem NCSD durchsucht und und versucht die Header oder was auch immer das ist im Datenträger gesucht ich bekomme immer die selben Resultate. Ich weiß auch nicht wie ich zu dem Offste 0x300 springen kann. X wird nicht akzeptier weder wenn ich die Such auf HexaDecimal einstelle.

[d0k3]

Ja, deutsch verstehe ich auch. But you should write in english, so others can chime in to the discussion :). You can just scroll down. Offset 0x300 is almost at the beginning. Or, use CTRL+G. Can you do a screenshot from offsets 0x100 and 0x300 and show me?

Oh, and you don't need the 0x - that's just to show that it's a hex value. In HxD, just select hex and input 300.

[MrTSXV]

https://imgur.com/a/fWY0tiJ

[d0k3]

Don't write the 0x. Just use 300 (or 100) :).

[MrTSXV]

https://imgur.com/a/cqcpyZY

https://imgur.com/a/TBZedWU

[d0k3]

Damn. It's all zeroes from there, correct? Did you try running HxD with administrative rights (just right click the shortcut, "Run as administrator")? Besides, are you on Telegram, Discord or IRC? We can talk there, too, may be easier.

[MrTSXV]

I can start a WEB IRC client on freenode

[MrTSXV]

channel #d0k3

[d0k3]

Alright, just send me a pm then.

[d0k3]

Okay, just so that we have this documented. With the exact same settings, Multi EmuNAND Creator created the second RedNAND... ... on a 128GB SD card at 0x3B000000 ... on a 64GB SD card at 0x3BC00000

From all that I know, the first offset should be correct - I have no explanation for the second one, and no idea why Multi EmuNAND Creator should treat these two SD cards differently. Still hoping that @DarkMatterCore can shed some light.

[DarkMatterCore]

It would be useful if @MrTSXV ran the program in debug mode. It notifies each and every offset calculated before starting the injection/extraction procedure; that would greatly help me find what's wrong. Although it's odd it works fine with Luma as is.

Here's a quick debug build of the latest version: https://mega.nz/#!wUp1CQRb!QgGNDfF6dc9g6IEhUyGYyh6c4ctzXEeWJTpheuyvRqI.

@MrTSXV Please repeat the process from the very beginning (RedNAND #1 creation) for both SD cards and take a screenshot of every info window that is gonna appear. I'll take care of comparing the offsets and fixing calculations in the 3ds-multinand codebase.

[MrTSXV]

@DarkMatterCore I will do that next week, so that you can locate the problem.

LG

[d0k3]

LG is a german abbreviation, @MrTSXV :P.

Some additional info, @DarkMatterCore: It works in Luma because Luma "bruteforces" the offsets - it tries multiple offsets, searching for the NAND header. GM9 does not do that and instead assumes there is only one correct offset (depending on the formatting, compact or legacy).

So, as @MrTSXV used the compact formatting, I'm assuming that, to get the RedNAND offset of the second RedNAND, I take the end offset of the first one, round that up to the next multiple of 4MiB and add 512 byte (for the meta data). Worked in basically every case until now, until @MrTSXV came around.

Additional additional info: GM9 is designed to work with custom partitioned NANDs, thus I never hardcode offsets and instead rely on calculations such as the above.

[d0k3]

@MrTSXV - any news? This is now a coop issue with @DarkMatterCore, so I'm leaving it open until resolved.

[MrTSXV]

@d0k3

Hey :)

I am currently not at home, I was surprised by an holiday trip. I will make the testing and documentation, when I am back. I promise, I have not forgotten about it ;)!

Greetings

[d0k3]

Hey, @MrTSXV, back already? Just a friendly reminder, cause I want to close this issue. ^_^

[d0k3]

Okay, @MrTSXV seems to be mia, and I want to get rid of issues. @DarkMatterCore - maybe I can have a look at the relevant parts of the source code? Maybe I'll see something you don't.

Can you point out these relevant parts to me?

[fox8091]

@d0k3 It seems this may be relevant?

[d0k3]

Thanks @fox8091, but I'm unsure about what this does. It's better @DarkMatterCore points out the relevant pieces of code himself.

[d0k3]

Okay, moving this to @DarkMatterCore's repo. I need to clean up issues, sorry, and this one is not even a GM9 issue. Still offering help, so just reply tp the new one.

New issue: https://github.com/DarkMatterCore/3ds-multinand/issues/2