Hacking The status of Gateway and A9LH

[liomajor]

OK, I must be missing something. Tried it with the uploaded stage2 payload just to see if there was something wrong with mine. Still not working. Holding B is clearly trying to run the payload. But it just gives me a red screen and shuts off. Any ideas, @liomajor?

Did you copy launcher.dat to the root folder of your memory card?
Did you inject gw's stage 2 @ offset b400000 (sector 5A000)?

 

[Kazuma77]

Did you copy launcher.dat to the root folder of your memory card?
Did you inject gw's stage 2 @ offset b400000 (sector 5A000)?

Yes I did. I have no idea why it's not working. Does this only work on an N3DS? I'm about to try it on the one that's left (just bricked the AUS one though -- thought I'd use the system's original secret sector instead of Plaillect's, but I guess the sector0x96.bin GM9 dumps is not the same thing, not a good way to be finding this out).

 

[liomajor]

No, GW's Stage 2 is for everyone the same and it worked for o3ds too.

Example (includes GW's Stage 2) : http://gbatemp.net/threads/the-status-of-gateway-and-a9lh.427889/page-12#post-6381366

 

[Kazuma77]

No, GW's Stage 2 is for everyone the same and it worked for o3ds too.

Example (includes GW's Stage 2) : http://gbatemp.net/threads/the-status-of-gateway-and-a9lh.427889/page-12#post-6381366

I know the payload is the same. But I'm wondering if the O3DS needs something different in order for it to work. Because all I'm getting is a red screen and a quick shutoff.

 

[liomajor]

I know the payload is the same. But I'm wondering if the O3DS needs something different in order for it to work. Because all I'm getting is a red screen and a quick shutoff.

I only have this when either memory card or \Launcher.dat is not present. I 've tested with launcher.dat 3.7.1 and 4.0a

 

[stl25]

@liomajor would this work with @FIX94 A9LH? I currently have his fork installed.

 

[liomajor]

@liomajor would this work with @FIX94 A9LH? I currently have his fork installed.

Possible if you edit https://github.com/FIX94/arm9loaderhax/blob/master/payload_stage1/source/main.c

 

[stl25]

Thank you for your quick reply.

 

[Kazuma77]

I only have this when either memory card or \Launcher.dat is not present. I 've tested with launcher.dat 3.7.1 and 4.0a

OK, well, it does work on the N3DS. I'm trying the other O3DS now. If it works, it may be a card issue or something. That card does still have a second EmuNAND from where I ran Palatine eons ago. Still going nuts over messing up the AUS N3DS, but, I should have known better than to replace a known working file. Well, now I have to get something I've been wanting anyway -- a hard mod.

 

[Asia81]

I didn't read all your posts, so just a quick question.
I see you're speaking about a gw payload, is there a .bin available for start with Luma3DS and 11.X SysNand ?

 

[Kazuma77]

I didn't read all your posts, so just a quick question.
I see you're speaking about a gw payload, is there a .bin available for start with Luma3DS and 11.X SysNand ?

There's a stage0x5C000.bin for manual injection into your NAND dump (at the 0x5A000 position, aka 0x0B400000). It works with a modified compile of DarkSamus's A9LH. liomajor posted the modified .c file on page 5 I think it was. So far I have it working great on my N3DS XL (USA, bricked the AUS one doing something stupid), but giving a red screen and shutting off on both O3DS XLs.

You will need to compile the A9LH installer first though. It requires you to go back to 9.2, so, you'll have backup your SysNAND, restore something like SysNAND_original.bin normally, run your compiled installer via a *hax (it hangs at "exploiting arm9" about 50% of the time I might add -- you might want to temporarily replace boot.3dsx with it), restore your current NAND with "keep A9LH", then dump your SysNAND again, copy it to your PC, patch the stage 2 payload, copy it back, then restore normally. Not as time-consuming as installing A9LH, but close. Worth it when it works though.

Not as simple as I was hoping for, but, it's not really that difficult to compile. Just basically needs Python 2.7, Pycrypto, and DevKitPro ARM r45 (needs ctrulib too, but that's included in Devkit). Also, you do need a couple of decrypted firmware files, the secret sector file, and your otp.bin to compile it. With those in place though, it's just a matter of entering "make" at the command prompt, then look in "data_output" for the .3dsx file. It appears to be a complete solution. If it will run 3.7.1, it should theoretically be capable of running any GW Launcher.dat -- past, present, and future.

I only have this when either memory card or \Launcher.dat is not present. I 've tested with launcher.dat 3.7.1 and 4.0a

OK, there definitely appears to be something O3DS-related now. Red/black and Zelda both just give a red screen and shut off. N3DS works just fine though. And indeed, even 3.7.1 works. It's a beautiful thing (on my N3DS anyway). And I've tried formatting a spare card I have laying around and just putting the launcher on it. Put it in all 3 systems (it's a microSD, I used an adapter with the O3DS XLs). Got the GW menu on the N3DS XL. Got a red screen and shutdown on both O3DS XLs. That rules out the card. There's something causing it not to run on the O3DS. Maybe the issue only shows up if you try to use button B for some reason, and doesn't if you use A. Actually, the home button mapping in Safe A9LH gave me the same results. But it would only red screen every other time.

 

[satelman]

View attachment 50576
I e-mailed the GW Team. Here's to hoping they get their act together.

Completely agree about the part that says that most of us would prefer a 'hybrid' solution (GW + CFW). Thanks for letting them know.

 

[izy]

We aren't talking about old brick code. We're talking about the current a9lh alpha. It doesn't do that.

And how is this not related

 

[Maximilious]

And how is this not related

The old brick code was hard-coded by GW intentionally for fake cards. This new version is causing unintentional bricks. So there you go.

 

[urherenow]

And how is this not related

because it was a hardware issue that was already fixed (or at least figured out), genius. This version does not encrypt or write protect the nand from a hard mod.

Not related in the slightest.

 

[SpencerlyEverly]

Launcher.dat 371 works as well, did you try?

Never tried that. I might do that after school, today's the last day of school for me before summer break.

Thanks for clairifying that it works on v3.7.1!

 

[yacepi15]

View attachment 50576
I e-mailed the GW Team. Here's to hoping they get their act together.

Well done.

 

[Quantumcat]

Never tried that. I might do that after school, today's the last day of school for me before summer break.

Thanks for clairifying that it works on v3.7.1!

Summer break ... Lucky ... my fingers freeze off under my bike gloves every morning and evening :-(

 

[tony_2018]

We aren't talking about old brick code. We're talking about the current a9lh alpha. It doesn't do that.

And how is this not related

The old brick code was hard-coded by GW intentionally for fake cards. This new version is causing unintentional bricks. So there you go.

because it was a hardware issue that was already fixed (or at least figured out), genius. This version does not encrypt or write protect the nand from a hard mod.

Not related in the slightest.

OOOHHH!!! SOMEONE IN THIS THREAD JUST GOT SLAMMED!!!

@squee666 If you're that concern why not email them about it.

 

[Logan Pockrus]

Gateway's A9LH has reached the final point of testing... the beta test... which was leaked... on the same day as its announcement.... in the same time span........
ANYWAYS. The new beta has given us some insight as to what GWs implementation of A9LH will be like, albeit the implementation is downright shitty, but it'll get better, right?

Some things to clear up:
-The new update is not releasing in 48 hours. It's releasing 48 hours after the end of the beta test, which is at the end of the week.
-3DS CAN be powered on without GW Card, but it boots the GW menu

What we currently know:
-Updating sysNAND after GW A9LH will either brick the 3DS, or remove A9LH from the system.
-It's possible to have 11.0 on Gateway sysNAND while still maintaining A9LH, it requires you flash an 11.0 NAND.bin during the A9LH install process
-The downgrader is extremely unstable. Don't use it.
-N3DS has a 100% brick rate if you use only Gateway's stuff, due to them not unbricking emuNAND before flashing. (People recommend to use Plail's part of the guide for this section)
-No GBA support, although someone states that they can run GBA in sysNAND.
-DS Games and Flashcards do work in emuNAND.
-Some report that important homebrew apps such as Decrypt9WIP do not work alongside this alpha build.
-Gateway's payload does not work with other existing payloads, nor does the vice versa work.
-Users have reported that there is a screen flicker problem with the 4.0a build.
-No support for n3DSes on 8.1J, users just get a 'FATAL ERROR: no browser" message.
-n3DS can't upgrade to 10.3 while o3DS can.
-A bug has been brought to light, regarding NAND Backups.

-@liomajor has found a workaround to the single Gateway payload fiasco. Read their posts about it here:

So far, there have been bricks, the amount is unknown, but people are seemingly most successful with the A9LH setup when they use Plail's guide and GW's together. (If that made any sense).

There's an ok chance that Gateway will fix their problems, as this is a beta test however,
it is much too early to make any final judgments about this whole release.

Please inform me of what I'm missing. Will update post. (pls no memes b0ss)



p.s. sorry mods for doing this so fast....

Honestly, this sucks. Pretty damn bad. Hopefully they can fix all of their...issues.