Hacking The status of Gateway and A9LH

[liomajor]

I only want it that way because I have a couple of young kids that will be using GW mode 100% of the time.

I would still be able to launch it after bringing up homebrew menu through CIA or something though right after it booted?

You can do this by swapping stage 2 files, but don't delete one, it has to be all 3 for installation.

Select /a9hl/Decrpyt9.bin

Select would interfere with luma3ds.

To all who want different button combos, please rethink if a bootmanager would help instead.

Most combos are restricted depending on 2ds / old3DS or new3DS. Try Start + A on new3ds

this way is exactly the same, but i install from a9lh instead of install from homebrew menu?
so the files on the sd card are the same etc? or, when installing from a9lh i don't need my otp on the sd or something?

and, to uninstall this, we would simply reinstall a9lh?

Homebrew Menu aka Launcher will only install IF there is no a9lh present, updating only works using the provided arm9loaderhax.bin.

To undo the installation, either start decrypt9 / emunand9 and install a backup nand.bin or use unedited safea9lhinstaller with your own stage 1/2 files.

 

[driverdis]

haha thanks, my request still stands though, willing to donate few £ or $?
This way i don't need a CFW, just stock SYS Nand and EmuNand to play with

with A9LH, it is CFW/GW (once FIRM protection works) or nothing. stock has no FIRM protection so A9LH gets removed on a O3DS and a N3DS bricks.

 

[metaljay]

You can do this by swapping stage 2 files, but don't delete one, it has to be all 3 for installation.



Select would interfere with luma3ds.

.

I Don't want Luma3ds though, my goal is default GW Emunand, then press any button to go to Decrypt9, and another button to go to a completely stock SYS NAND

Is this doable?

 

[cearp]

@liomajor cool. this is all in the firm partitons right, not the that big fat16 partiton with all the system apps etc?
so i could simply make a backup of that and restore that alone, yes?

 

[driverdis]

I Don't want Luma3ds though, my goal is default GW Emunand, then press any button to go to Decrypt9, and another button to go to a completely stock SYS NAND

Is this doable?

completely stock SysNAND (NOPE, FIRM needs to be patched among other things)
{BEST BET: Use a minimalist A9LH CFW}
GW as default: Yes
boot decrypt9: Yes

 

[liomajor]

I Don't want Luma3ds though, my goal is default GW Emunand, then press any button to go to Decrypt9, and another button to go to a completely stock SYS NAND

Is this doable?

Doable yes, but i suggest using bootctr9 and to swap stages.

@liomajor cool. this is all in the firm partitons right, not the that big fat16 partiton with all the system apps etc?
so i could simply make a backup of that and restore that alone, yes?

Yes, its inside nand and a backup will include this.

 

[driverdis]

Snip, posting messed up

 

[izy]

with A9LH, it is CFW/GW (once FIRM protection works) or nothing. stock has no FIRM protection so A9LH gets removed on a O3DS and a N3DS bricks.

gateway already said they have no plans for Sysnand CFW so they are most likely never gonna do Firm Prot

 

[Kazuma77]

I Don't want Luma3ds though, my goal is default GW Emunand, then press any button to go to Decrypt9, and another button to go to a completely stock SYS NAND

Is this doable?

Everything except the completely stock SysNAND. The closest you'll get to that on A9LH is running Cakes without patches (I'd recommend the firm protection even on that). You'll have to use CBM9 if you want a boot manager on one of the hotkeys is the only thing. BootCTR9 probably won't work (unless you change the delay from 1000 to 3000, that might give you enough time to hit a button). So just make Cakes your "arm9loaderhax.bin" and Decrypt9 your "a9lh/arm9loaderhax.bin" files. Enable the firm patches on the Cakes menu and set it to boot automatically. Closest thing to a stock SysNAND, as I said.

gateway already said they have no plans for Sysnand CFW so they are most likely never gonna do Firm Prot

But they already have -- in all previous versions. So until a new firmware forces an update from 3.7.1, we have it.

You can do this by swapping stage 2 files, but don't delete one, it has to be all 3 for installation.



Select would interfere with luma3ds.

To all who want different button combos, please rethink if a bootmanager would help instead.

Most combos are restricted depending on 2ds / old3DS or new3DS. Try Start + A on new3ds



Homebrew Menu aka Launcher will only install IF there is no a9lh present, updating only works using the provided arm9loaderhax.bin.

To undo the installation, either start decrypt9 / emunand9 and install a backup nand.bin or use unedited safea9lhinstaller with your own stage 1/2 files.

I was about to say, select will mess Luma up. Then again, looks like that's not something he actually wants. I'd say A & B, start & B, and start & A should satisfy most people's needs. If you don't mind creating them. I completely understand where this train is going, and why you can't take infinite requests for an infinite amount of configurations.

 

[satelman]

For thoose who had no problem using the former Stage 1 don't need to update, red screen > pwr off, plz try the updated Stage 1

Hi, @liomajor, one last request:

Could you create again the simplified alternate stage 1 for A instead of X + Y, and B instead of X + A, but with your latest update for Samsung+Toshiba, please?

 

[driverdis]

nothing to do...two red screen then shutdown i have the wrong nand ((

you should update again, Samsung NANDs are now working with the latest files @liomajor released.

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

But they already have -- in all previous versions. So until a new firmware forces an update from 3.7.1, we have it.

We have it in EmuNAND, has anyone (with a hardmod) confirmed FIRM update blocking works on SysNAND while on
3.7.1?

EDIT: @ Gateway: I see what you are doing here, releasing files that only work on Toshiba NANDs. You wanted this to happen to leach off of people here on GBATemp so they can get the job done for you.

 

[Kazuma77]

you should update again, Samsung NANDs are now working with the latest files @liomajor released.

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



We have it in EmuNAND, has anyone (with a hardmod) confirmed FIRM update blocking works on SysNAND while on
3.7.1?

EDIT: @ gateway I see what you are doing here, releasing files that only work on Toshiba NANDs. You wanted this to happen to leach off of people here on @gbatemp so they can get the job done for you.

It's my understanding this is why updating from a ROM bricks in GW SysNAND mode, and why they were considering removing the feature. So glad they didn't, now it has a use -- getting out of GW A9LH. And now we can use 4.0a to update systems to 9.2 instead of rxTools. Or even run the Smash 9.2 update (it probably just became the safest update method for people that own GW cards actually -- you can always do a full 9.2 update using SysUpdater in EmuNAND later).

 

[xfcrowman]

Thanks again @liomajor, @Kazuma77, and everyone else that helped. It's great to have both luma and GW booting with A9LH, and I doubt that Gateway would have ever released something that permitted this.

Cheers

 

[Kazuma77]

Thanks again @liomajor, @Kazuma77, and everyone else that helped. It's great to have both luma and GW booting with A9LH, and I doubt that Gateway would have ever released something that permitted this.

Cheers

Well, all I did was compile some payloads using the modified main.c that liomajor gave us. I give all the credit to liomajor.

 

[driverdis]

Thanks again @liomajor, @Kazuma77, and everyone else that helped. It's great to have both luma and GW booting with A9LH, and I doubt that Gateway would have ever released something that permitted this.

Cheers

This is what I am afraid of, for 4.0 stable, Gateway can always put brick code and/or modify Launcher.dat to not work with this method of loading Launcher.dat

it would be just like Gateway to brick users of this A9LH loading method and claim that it was because people used an unstable version or their loader and that the final version (which would conveniently not work with this) would have not bricked their console.

 

[Kazuma77]

EDIT: @ Gateway: I see what you are doing here, releasing files that only work on Toshiba NANDs. You wanted this to happen to leach off of people here on GBATemp so they can get the job done for you.

Not quite. Gateway's version of A9LH worked with both. They have a working stage 1 payload. It was something missing from existing implementations of stage 1. I'm thinking it may have something to do with the size of GW's stage 2 payload, actually.

 

[urherenow]

The Firm0 and FIRM1 were already up on a certain iso site before you did all of that. You could have just grabbed them instead of installing GW A9LH yourself. Oh well. I saw the first offset you mentioned. Hadn't got around to comparing FIRM1s though. It's weird that the difference ends at F0F64 though -- that to F1FFF are all overwritten with "00" on mine (and they had something there before).

When I started, I had no idea if the firms needed to be decrypted first, so it didn't matter to me to look. And, I did my checking the RIGHT WAY. I had compared a dump from after using the payloads here (That worked on only Toshiba NANDs) to the very same firms with GW on top of it. This way, F0F64 not only has data on both my dumps, but it is the exact SAME data. I think it's something the original payloads here did and you were comparing a gw firm with a stock firm. (and since @liomajor got the whole thing working, well... you do the math)

OK, just got around to comparing FIRM1s. There is a difference between 0x000F2000 and 0x000FFFFF that urherenow failed to mention. Actually, I'm seeing it on FIRM0 as well.
Yes, otp.bin is the only other thing you should need.

Are you sure? I thought it wasn't actually required once you had a9lh installed (but mine is still on my cards since I have plenty of space anyway)

@liomajor, My research did help get this done, right? Would you mind posting a quick explanation of what the issue was and also post the new source so I can build my own with A launching Launcher.dat? PM is fine if you don't want to make it public.

 

[liomajor]

Not quite. Gateway's version of A9LH worked with both. They have a working stage 1 payload. It was something missing from existing implementations of stage 1. I'm thinking it may have something to do with the size of GW's stage 2 payload, actually.

No, my guess is that its partly detecting memorycard as for what i dated back > starting without doesn't turn off your console > we can live with it.

 

[Kazuma77]

When I started, I had no idea if the firms needed to be decrypted first, so it didn't matter to me to look. And, I did my checking the RIGHT WAY. I had compared a dump from after using the payloads here (That worked on only Toshiba NANDs) to the very same firms with GW on top of it. This way, F0F64 not only has data on both my dumps, but it is the exact SAME data. I think it's something the original payloads here did and you were comparing a gw firm with a stock firm. (and since @liomajor got the whole thing working, well... you do the math)


Are you sure? I thought it wasn't actually required once you had a9lh installed (but mine is still on my cards since I have plenty of space anyway)

@liomajor, My research did help get this done, right? Would you mind posting a quick explanation of what the issue was and also post the new source so I can build my own with A launching Launcher.dat? PM is fine if you don't want to make it public.

Actually, I found it most useful to compare present A9LH to GW A9LH. Non-A9LH had too much different. The F0760 to F0F63 range was completely different on mine too. Actually, encrypted, F0F760 to FFFFF were all different, but encrypted, I could see that F0F64 to F1FFF were being overwritten by "00" in GW, and thus, probably were irrelevant. F2000 to FFFFF still showed a difference, on both FIRM0 and FIRM1.

I've heard it depends on whether you are switching builds or whatnot. It doesn't hurt to just leave it, the "firm" files (actually N3DS NATIVE_FIRM 9.0 and 10.2, not actual firm partitions), and the secret sector on there though, just in case.

 

[Roomsaver]

So why would I ever use GW A9LH if regular A9LH is way better?