Hacking [IDEA] Launch a minimal CFW (like SaltFW) if no arm9loaderhax binary is found on SD

[xXDungeon_CrawlerXx]

Can't wait for a working AL9H-load-payload-from-NAND Release D:

 

[Zan']

This would be nice to have for when you need to send a broken 3DS with a9lh to Nintendo for repairs.
It only needs firm protection for when they try to update it.

I'd guess they'd be smart enough that your console is/was modded though.
I don't think they'd let A9LH slip.

 

[Pokéidiot]

Not tested, but isn't there a limmit to the size of the payload?

- Left windows is the A9LH folder for my O3DS to use with SafeA9LHInstaller
- Right windows is a test A9LH folder for my O3DS to use with SafeA9LHInstaller

(This is just done, to show the size difference and to ask if it wouldn't be a problem)
(No i'm not gonna try that, since my test system is in repair for a hardmod and nand recovery)

I hardcoded the thing into stage2, so the payload gets bigger (obviously).
And I can't test it by myself because I don't have a hardmod.

--------------------- MERGED ---------------------------

Also, SafeA9LHInstaller has a stage2 payload size limit, but you can recompile it to extend this limit.

 

[yifan_lu]

Yellows8 has already done most of the hard work
https://github.com/yellows8/bootldr9_rawdevice
https://github.com/yellows8/unprotboot9_sdmmc

 

[Zan']

I hardcoded the thing into stage2, so the payload gets bigger (obviously).
And I can't test it by myself because I don't have a hardmod.

--------------------- MERGED ---------------------------

Also, SafeA9LHInstaller has a stage2 payload limit, but you can recompile it to extend this limit.

It might have this limit for a reason though. To not overwrite important things or extend the max size.

I don't see why you are trying to throw everything into the stage2. I liked the CTRNand Idea.
You would mostly run it like you were before but have your payload be on the NAND chip instead of the SD card. The NAND chip has tons of unused space which can be used. And it wouldn't be to bad to update either, as it does't need reinstalling A9LH for every update.

 

[dubbz82]

Some users say that has no problems with having A9LH limitations with SD card (because you always need it).
Imagine if you took your 3DS to school and forgot the SD card in your laptop (or computer, etc) sending a game to it. But you took with you a flashcard in this case. Then you shutdown your 3DS (to save battery or for whatever reason) and the SD card isn't in it. And it doesn't boot.

*Gulp* You'd have to actually focus on what you're supposed to be focusing on anyways. Even if it was somewhere other than school, as long as you realize what's going on with it, it's not the end the world, and I'd write it off as a lesson learned, personally.

 

[driverdis]

The problem with a hardcoded binary is that everytime you might need to change the payload (update reasons) you would have to reinstall A9LH, am I wrong?

I guess the main purpose of this is to allow the 3DS to run a minimal CFW like SaltFW when the SD Card is out rather than the 3DS not booting at all. This would allow all DS Carts (and most 3DS Carts) to run should someone end up with no SD Card for any reason.

This would also be great for people that want to use their 3DS is a Pokemon Tournament where there is a chance of the 3DS being checked for CFW and the best bet to detect A9LH users is to remove the SD Card and boot.
If SaltFW booted when no SD Card was in, this would make the console appear to be normal and not A9LH'd.

 

[Deleted User]

TWL firm is used as DS support right. Could we not sacrifice DS play and use it as a code-storage nand? POint to it and load SD if inserted, load nand with paches/firmprotect without an sd?

 

[driverdis]

TWL firm is used as DS support right. Could we not sacrifice DS play and use it as a code-storage nand? POint to it and load SD if inserted, load nand with paches/firmprotect without an sd?

I think it would be possible to store the payload in TWL_NAND without losing DS Support, it is a far better idea than installing it to the CTR_NAND where it can get overwritten for any reason by an update or system format.
An update or system format (at least when formatted via TinyFormat) does not touch the TWL_NAND partition at all.

 

[Deleted User]

I think it would be possible to store the payload in TWL_NAND without losing DS Support, it is a far better idea than installing it to the CTR_NAND where it can get overwritten for any reason by an update or system format.
An update or system format (at least when formatted via TinyFormat) does not touch the TWL_NAND partition at all.

We can even protect TWL-Nand at boot aswell. Double win

 

[phalk]

The main problem, which is mounting anything at stage2 must be solved for that.

 

[Vondosaurusrex]

The main problem, which is mounting anything at stage2 must be solved for that.

I think someone mentioned earlier that Luma3ds mounts the FIRM at boot (for patching), so if it's possible to look at how that works maybe we have a solution...?

 

[dubbz82]

An update or system format (at least when formatted via TinyFormat) does not touch the TWL_NAND partition at all.

There's no reason they COULDN'T start pushing out TWL updates...though it'd be largely pointless to do so.

 

[Deleted User]

I think @Shadowhand is working on this... Hopefully

 

[Shadowhand]

His method, if I'm not mistaken, aims to more or less be a variant of this, except stage 2 is the CFW. If we can figure out how to mount the NAND properly during stage 2, it'd be a lot safer to instead pull in the CFW from there like how Luma loads FIRM from NAND as well, since you can always use Godmode9 or FBI to change your CFW out or update it. If your CFW is in stage 2 like ShadowNAND or this, you have to reinstall A9LH every time there's any sort of an update, and that goes without saying that there's some risk involved. I know Salt and other minimal CFWs aren't updated much, but there's always a chance they might need future updates if Nintendo throws us a curve-ball, so making the CFW itself easily updateable should be a primary goal if this idea is to work out, if you ask me.

One problem with writing an actual file to CTRNAND (using it as storage), you can fragment CTRNAND and cause actual proper bricks.
Doing what you said was my initial idea, but I've been told over and over again that this is a horrible idea.

--------------------- MERGED ---------------------------

My stage2 source, along with a precompiled binary.
If I was you, I wouldn't test without a hardmod.

https://mega.nz/#!sA0WASBT!4gBHxtCaXR4ZCYhJ2Wqgz3S8-4m5sdN8EgI_6ksvAIc

Install this first: https://github.com/RShadowhand/ShadowNAND

Then you can install your stage2 payloads safely without bricking. Simply boot safe_mode.bin using DPAD_DOWN. (Don't forget to install alt_stage2 too, and use https://github.com/RShadowhand/SafeA9LHInstaller to install)

 

[xXDungeon_CrawlerXx]

Can't wait for a working version for everyone

 

[daxtsu]

One problem with writing an actual file to CTRNAND (using it as storage), you can fragment CTRNAND and cause actual proper bricks.
Doing what you said was my initial idea, but I've been told over and over again that this is a horrible idea.

If that's out, then could we not examine how much unused space there is in a typical NAND (being out of the boundaries of CTRNAND's free space/max size, of course) and install our own small FAT12 or FAT16 partition somewhere? If a common place could be agreed on, then I'd think support for it could easily be added to tools like GM9.

 

[xXDungeon_CrawlerXx]

If that's out, then could we not examine how much unused space there is in a typical NAND (being out of the boundaries of CTRNAND's free space/max size, of course) and install our own small FAT12 or FAT16 partition somewhere? If a common place could be agreed on, then I'd think support for it could easily be added to tools like GM9.

our own FAT16 Partition would be awesome. I guess CTRNAND contains enough space for that

 

[daxtsu]

our own FAT16 Partition would be awesome. I guess CTRNAND contains enough space for that

No, this alternate idea is to stay away from CTRNAND and just go somehere else that's unused. If we can find a small place (maybe a megabyte or two at max?) that more or less won't ever be used by any FIRM, then I don't see why we can't drop a small partition there.

Basically, the ideal setup (for me at least) would allow us to have a filesystem for much easier and safer updating than needing to change out A9LH or any of its stages.

 

[Zan']

No, this alternate idea is to stay away from CTRNAND and just go somehere else that's unused. If we can find a small place (maybe a megabyte or two at max?) that more or less won't ever be used by any FIRM, then I don't see why we can't drop a small partition there.

Well that's what I was saying first.
Chipsizes differ on the Systems though.
o3DS has either 943MB or 956MB. (It needs a little less than 942MB.
N3DS has 1240MB or 1888MB (it needs around 1238MB)

Giving each about 1MB spare to create a new filesystem in the end.
If it is aligned to the end it would be possible to basically have a "autofind" based on first byte of the new partition.