Hacking Emunand with A9LH

[Deleted-236924]

Hi, I wish to switch over to arm9loaderhax, but I want to keep running emunand and keep sysnand untouched on 9.2 (I wanna be as safe as possible.)

I've read plenty of things over the past few hours. Supposedly possible to get arm9loaderhax to have cfw coldboot from power on, being able to unbrick without hardmod, all that good stuff, and it was said that coldbooting emunand cfw was pretty much just as fast as booting sysnand cfw, which is great.

I want to just be able to update emunand and keep sysnand on 9.2; that way, if a future 3DS system update manages to break arm9loaderhax, well, I'm just running emunand anyway, so if something breaks, I revert to previous emunand firmware version until a fix is found or something. Sounds simple enough and safe enough to me, because I've read there could be multiple ways to break arm9loaderhax when updating sysnand, and it could possibly be broken by Nintendo at some point, so I don't really want to take any risks.

But the guides I was able to find are all about running sysnand cfw on coldboot, nothing about being able to just carry on running emunand. It's really unclear how I would have to proceed to just have arm9loaderhax boot an emunand cfw while completely ignoring sysnand (which would only be there for purposes of hosting arm9loaderhax and booting emunand automatically, so it'd never be seen again.)

How do? Halp pls
Several hours of reading and searching did not answer my questions.

 

[Rohul1997]

After installing arm9loaderhax, use Aureinand and you should be good to go. It will automatically boot into emunand

 

[Omegapsy]

Follow plailect's guide but dont convert over to sysnand and don't set aureinand to boot into sysnand (dont set the sysnand patches) and you should be fine.

 

[Deleted-236924]

Okay, guess that was easier than I thought it'd be, and my question was a bit dumb.
Thanks for the replies.

 

[VinsCool]

Holy shit, long time no see Ammako!

 

[Deleted-236924]

Also uh, does AuReiNand have some way for me to tell if I'm in emunand or sysnand?

It is a fork of ReiNand, so it may still have the "Rei" Ver. String (I think ReiNand had that yeah?) but I've got this feeling, that it may just do the same thing on sysnand cfw, which wouldn't really help.

Last thing I want to do is accidentally mess up my sysnand by doing things thinking that I'm on emunand when I'm actually on sysnand, you see. Can never be cautious enough.

 

[Grumpsta]

Also uh, does AuReiNand have some way for me to tell if I'm in emunand or sysnand?

It is a fork of ReiNand, so it may still have the "Rei" Ver. String (I think ReiNand had that yeah?) but I've got this feeling, that it may just do the same thing on sysnand cfw, which wouldn't really help.

Last thing I want to do is accidentally mess up my sysnand by doing things thinking that I'm on emunand when I'm actually on sysnand, you see. Can never be cautious enough.

How did you configure your boot for Aureinand? If its default, holding nothing, will launch sysNAND. Holding L would launch emuNAND. The Rei Ver String is a known issue in ReiNAND, which AureiNAND is built from. I'm not sure if the developer of AureiNAND intend to fix this, as ReiNAND is the same way. The nice thing about a9lh is actually booting into a CFW sysNAND. Most users will use this and actually delete the emuNAND partition off their SD. If a9lh is good to go for you, you will want to dump your new sysNAND. Anytime you brick your console, you can now load Decrpyt9 right on power up and restore your healthy image. Just remember if you use an old sysNAND file, this will completely remove a9lh all together.

 

[Sukid]

If you want to make absolutely sure, install Cakes and explicitly configure it to boot sysNAND. (enable emunand unchecked, block writes to firm0/firm1 checked). Cakes is easy enough to configure to work with a9lh, it's in the default boot config even. Change your theme in sysnand or add folders that explicitly identify sysnand as sysnand. That way when you boot AuReiNand again and you don't see any of that you know you're in emunand.

It is cool how with a9lh you don't necessarily need an emunand anymore but it kind of scares me, so I'm with you.

 

[Cuphat]

Also uh, does AuReiNand have some way for me to tell if I'm in emunand or sysnand?

It is a fork of ReiNand, so it may still have the "Rei" Ver. String (I think ReiNand had that yeah?) but I've got this feeling, that it may just do the same thing on sysnand cfw, which wouldn't really help.

Last thing I want to do is accidentally mess up my sysnand by doing things thinking that I'm on emunand when I'm actually on sysnand, you see. Can never be cautious enough.

It doesn't, but keep in mind that even if you boot it into sysNAND you're still in the same CFW environment (so if it changed the "Ver", it'd be changed in both).

If you want to differentiate them, use different themes or something. I assume your NANDs are unlinked.

 

[Deleted-236924]

If you want to make absolutely sure, install Cakes and explicitly configure it to boot sysNAND. (enable emunand unchecked, block writes to firm0/firm1 checked). Cakes is easy enough to configure to work with a9lh, it's in the default boot config even. Change your theme in sysnand or add folders that explicitly identify sysnand as sysnand. That way when you boot AuReiNand again and you don't see any of that you know you're in emunand.

It is cool how with a9lh you don't necessarily need an emunand anymore but it kind of scares me, so I'm with you.

I will never understand why so many advocate the use of sysnand directly; emunand is such an amazing piece of work.

Running off sysnand still has the same risks as before... you're messing with sysnand directly, you never know when you may mess up your firm partitions somehow, or you never know when Nintendo firmware updates might find a way to mess it up and render a9lh unusable.

With emunand... you boot directly into emunand, and you have absolutely no chance of booting into your sysnand somehow and having it update somehow. It's there but it's like it's never used other than the first firm partitions for booting into your emunand. Then you can mess with emunand as much as you want, if you screw something up, oh well, restore a backup and there you go.
~1GB of space on the SD card isn't really that much of a sacrifice. Bigger SD cards are so cheap nowadays. If you're still stuck with a 2GB or 4GB... upgrade to a 32 or at least a 16, honestly.

That being said, would I be able to just keep my emunand exactly as used by rxTools right now? Or do I absolutely have to do some fancy file injection from that emunand to a brand new one to get everything back, like what people do for transferring their emunand stuff directly to sysnand?
Cause, if I can do that, I can just restore that emunand after I'm done with setting up a9lh, and I'll know that I'm in emunand because I'll have all my games and everything which sysnand never had and never will have.

 

[CrispyYoshi]

That being said, would I be able to just keep my emunand exactly as used by rxTools right now? Or do I absolutely have to do some fancy file injection from that emunand to a brand new one to get everything back, like what people do for transferring their emunand stuff directly to sysnand?
Cause, if I can do that, I can just restore that emunand after I'm done with setting up a9lh, and I'll know that I'm in emunand because I'll have all my games and everything which sysnand never had and never will have.

You can continue to use the same emunand, but Aureinand is the preferred CFW to coldboot a9lh with for emunand: It supports a9lh, relies on the same emunand as rxtools, isn't as bulky, and allows NTR stacking as it boots.

 

[Deleted-236924]

This is amazing!

Done it on my spare 3DS first, just in case. I don't wanna risk screwing up my XL. It works really well and it's amazing.
btw it doesn't seem to show any "Rei." Ver. string, but I know it's booting into emunand because it has everything my emunand had.

One last question. If I do this and I use emunand, let's say I wanted to install GBA VC or DSiWare. Those originally required you to install on both sysnand and emunand if you wanted to run them from emunand. Is that still required? Or does simply running from emunand work with AuReiNand + A9LH?

I don't really care all that much about GBA VC, and the only DSiWare I'll probably ever install is Four Swords Anniversary Edition. I had that installed before, on both sysnand and emunand, but I don't quite remember whether or not I actually had it installed on my 9.2.0 nand backup that I restored after getting my otp.bin
Four Swords seems to work, though. So, either it doesn't need to be installed to sysnand anymore, or I already had it installed on my sysnand backup.

If I do still need to install to both sysnand + emunand, is there a way to manually set it so I can access sysnand again for purposes of installing GBA VC or DSiWare?

Not all that much of a problem for now, because I don't care about any GBA VC or any DSiWare other than Zelda FS, which I can take precautions and make sure I have it installed to sysnand before installing A9LH. But, just in case, if I ever change my mind on that, or if anyone else does want to run GBA VC or DSiWare, it would be a good thing to know.

 

[CrispyYoshi]

This is amazing!

Done it on my spare 3DS first, just in case. I don't wanna risk screwing up my XL. It works really well and it's amazing.
btw it doesn't seem to show any "Rei." Ver. string, but I know it's booting into emunand because it has everything my emunand had.

One last question. If I do this and I use emunand, let's say I wanted to install GBA VC or DSiWare. Those originally required you to install on both sysnand and emunand if you wanted to run them from emunand. Is that still required? Or does simply running from emunand work with AuReiNand + A9LH?

I don't really care all that much about GBA VC, and the only DSiWare I'll probably ever install is Four Swords Anniversary Edition. I had that installed before, on both sysnand and emunand, but I don't quite remember whether or not I actually had it installed on my 9.2.0 nand backup that I restored after getting my otp.bin
Four Swords seems to work, though. So, either it doesn't need to be installed to sysnand anymore, or I already had it installed on my sysnand backup.

If I do still need to install to both sysnand + emunand, is there a way to manually set it so I can access sysnand again for purposes of installing GBA VC or DSiWare?

Not all that much of a problem for now, because I don't care about any GBA VC or any DSiWare other than Zelda FS, which I can take precautions and make sure I have it installed to sysnand before installing A9LH. But, just in case, if I ever change my mind on that, or if anyone else does want to run GBA VC or DSiWare, it would be a good thing to know.

I believe if you're using Aureinand, holding R will boot you into sysnand cfw. Otherwise, you could just move your emunand to your sysnand, but I don't recommend it for the same reasons you stated earlier in this thread.

 

[Deleted-236924]

Yeah, I actually accidentally figured out that holding R on startup would boot to sysnand. That's convenient.

But, this brings one last question. Info was a bit all over the place about this, but AuReiNand has protection against overwriting the firm partitions if you attempt to do a system update on sysnand, right?

So if someone does indeed get into sysnand by holding R, then updates it through system settings, let's say it bricks because a future 3DS firmware breaks with A9LH. The firm partitions would still be there, and one could simply hold L+R on boot to restore an earlier sysnand backup, right?

(Or, alternatively, even if sysnand is bricked in that manner, A9LH is still present on the firm partitions, so emunand would still be able to boot, right?)

Basically, the only way it can break, is if you specifically do something and mess with sysnand system files with Decrypt9 or something and break your firm partitions where A9LH is installed?

 

[Cuphat]

I will never understand why so many advocate the use of sysnand directly; emunand is such an amazing piece of work.

Running off sysnand still has the same risks as before... you're messing with sysnand directly, you never know when you may mess up your firm partitions somehow, or you never know when Nintendo firmware updates might find a way to mess it up and render a9lh unusable.

With emunand... you boot directly into emunand, and you have absolutely no chance of booting into your sysnand somehow and having it update somehow. It's there but it's like it's never used other than the first firm partitions for booting into your emunand. Then you can mess with emunand as much as you want, if you screw something up, oh well, restore a backup and there you go.

I believe the current logic is that if Nintendo finds a way to bypass the FIRM protection patch, it would also bypass the EmuNAND patch and you're screwed either way. And so long as you don't mess with A9LH itself (which most CFWs would protect you from), you can otherwise brick sysNAND all you want and it would still be recoverable the same way: just restore a backup and it's like nothing happened.

That all being said, there isn't too much downsides to running emuNAND, at least as long as you don't play much GBA VC.

 

[Deleted-236924]

I believe the current logic is that if Nintendo finds a way to bypass the FIRM protection patch, it would also bypass the EmuNAND patch and you're screwed either way. And so long as you don't mess with A9LH itself (which most CFWs would protect you from), you can otherwise brick sysNAND all you want and it would still be recoverable the same way: just restore a backup and it's like nothing happened.

That all being said, there isn't too much downsides to running emuNAND, at least as long as you don't play much GBA VC.

The emunand patch, as in, the patch that makes the system load emunand?

In that case, remaining on sysnand 9.2 or lower would guarantee that system updates could never really break you, because your sysnand itself would have to be updated for anything to really break. The firm protection patch is stored on sysnand, and the thing that makes the 3DS load nand off the SD card is also on sysnand, so any changes to emunand should never affect it.

But right now... all the patches are loaded and applied shortly after pressing the power on button, right before sysnand can even load. We already get complete access to everything right at power on, so I'm not sure if there's anything Nintendo can do to break an emunand. If they do manage to break it, we have complete access, devs can figure it out, bypass it, and then we can once again run latest FW emunand. Maybe they could break the firm protection patches and break our A9LH, but that would require updating sysnand itself.

Worst case scenario we would end up with a problem similar to N3DS being unable to use emunand above 9.5 back then. We'd still be able to just run whichever is the highest FW version we can run, and we have workarounds for everything that require a higher FW version. Update emunand, it bricks, no big deal just restore a backup (or format a new emunand + update it to latest working.)

But yeah, I guess this still isn't 100% safe, because it would still be possible to update sysnand, which could possibly break everything. But IMO, this is wayyyyy better than just having menuhax.