Hacking Otpless a9lh Brick strikes again!!

[dudemo]

If I downgrade a brand new 3DS (10.7, hasn't been booted once), should I format it before proceeding? Also:

1)If I format it, will I lose any pre-installed games? (with no NNID linked)
2)Should I do a SysNAND backup before attempting to downgrade? (through Gateway)
3)If I system transfer a 11.2 O3DS to a 10.7 N3DS, will it override the N3DS version? (Will it update to 11.2?)
4)If I system transfer, will the target console receive all the software that the original console had? Or do I need to change the microSDs later?

Yes, you should format it. Not doing so may cause a partial downgrade which could actually force you to use the recovery menu to update. You do NOT want that.

1. Yes. It will erase all data, saves, and preinstalled games. Without a NNID, you will lose the preinstalled game.

2. Don't do a sysNAND backup with Gateway. They're done differently than how Decrypt9/Hourglass9 do it and will be unusable in either homebrew app. (I think, but don't quote me!)

3. No. It will only transfer games, data, and NNID. Firmware will not change. This is why we can use a hacked 3ds (even one on 11.2) to system transfer a DSiWare game with a hacked save file and downgrade consoles on 11.0-11.2.

4. It will not receive all SD data. It will, however, transfer the Nintendo 3DS folder. This can be quite large if you have a lot of games installed. I suggest buying a new SD card and copying the data over or using the card from the source 3ds.

 

[gamesquest1]

That's because at the moment there have been two attempts to make the OTPless process more stable, so that means it's currently not as stable as the developer may want and that probably indicates there will be another update to make it more stable too. So it might be better to wait.

tbh we got lucky to even have these 2 amazing methods, and sure the dev may want to hit that 100% safe goal, but they can't help it if the 3DS has a reboot issue occasionally no matter how much they try, i think people should just do what they feel comfortable with, if you don't want to take that 0.1% chance of bricking stick with menuhax and emunand, but i honestly dont see things getting much simpler than they are right now

Yes, you should format it. Not doing so may cause a partial downgrade which could actually force you to use the recovery menu to update. You do NOT want that.

1. Yes. It will erase all data, saves, and preinstalled games. Without a NNID, you will lose the preinstalled game.

2. Don't do a sysNAND backup with Gateway. They're done differently than how Decrypt9/Hourglass9 do it and will be unusable in either homebrew app. (I think, but don't quote me!)

1. if you have no NNID linked then you will keep your pre-installed game, it will be transferred to the other console like nomal (this only applies on genuinely pre-installed games, not if you installed the legit cia files that were taken from pre-installed bundles)

2. gateway backups are fine, although there is no reason to go out of your way to use the gateway nand tools and public methods create a hash to verify the nand dump against to prevent users accidentally restoring a corrupt nand backup (sorry for quoting you on it )

 

[ScienceBETCH]

I never implied that I was mad, i'm actualy quite calm about it, The only point of this post was so people know that there is/(hopefully was), a chance of brick, sure, in the original post I probably sounded a litle frustrated, but that was a couple hours after the brick happend.

and when i mean that I'm not gonna use the otpless method for a very long time, i'ts actually because I really am scared risking another brick, not because I was saying "f**k this s**t and all".

i wouldn't be mad at the developers, i think its absolutely amazing what they did in this last year.

Well this wasnt for you actually. I made this to warn people and for the whole hacking community itself. I hope everbody sees that post. Also what got me flamed was this:

@Altairseven My New too was bricked thanks Plailect and her guide for "OTPless" (Thanks Plailect): https://github.com/Plailect/Guide/issues/621

So we are good

 

[Aurora Wright]

It seems there's random (and very rare) ARM9 memory corruption in between the reboot at play. The latest release should mitigate this since the majority of the code (all except for two opcodes) was moved to ITCM (which shouldn't corrupt).

 

[Altairseven]

It seems there's random (and very rare) ARM9 memory corruption in between the reboot at play. The latest release should mitigate this since the majority of the code (all except for two opcodes) was moved to ITCM (which shouldn't corrupt).

yeah, i read about it in the latest release changelog, hope it works, thanks for your hard work.

 

[rubycrow]

It seems there's random (and very rare) ARM9 memory corruption in between the reboot at play. The latest release should mitigate this since the majority of the code (all except for two opcodes) was moved to ITCM (which shouldn't corrupt).

Installed on a N3DSXL yesterday with no problem using v2.6.2 release, thank you for your hard work!

 

[gamesquest1]

that's good to hear hopefully that will be the end of the random bricks, unfortunately we won't really know unless it does brick but it seemed to be about 1-2 a week with the old builds so I guess if there are no new random bricks in the next couple of weeks then hopefully that will be the last of them

 

[Keizel]

Well this wasnt for you actually. I made this to warn people and for the whole hacking community itself. I hope everbody sees that post. Also what got me flamed was this:

So we are good

You helps a lot

 

[naddel81]

I feel for you guys. So glad I decided to stay on EmuNand.

 

[Arkansaw]

The OTP portion is the most risky part, even more so than the downgrade to 9.2, which is why I say that people are downplaying the risks of a9lh either out of ignorance or malice.

 

[Selver]

... However, you cannot attribute to a bad solder if you successfully wrote to the nand up to 100%. In that case, it is most probable that you have made a bad nand dump.

Actually, bad solder can crack and become an intermittent connection. An intermittent CLK can (depending on the reader and firmware) result in specific data corruptions (last N bytes repeated per read command). See this post for some details.

Here's source to a utility to merge multiple dumps from a hardmod with a flaky reader/CLK line:

https://github.com/Selver-gba/MergeImages ​

Specifically, the DetermineSectorState() function checks for end-of-read repeated values, which is a common corruption, and can happen on any sector.

 

[Red_Alive]

what does optless install mean ?

 

[Quantumcat]

The OTP portion is the most risky part, even more so than the downgrade to 9.2, which is why I say that people are downplaying the risks of a9lh either out of ignorance or malice.

No it's not - the downgrade to 9.2 involves having no NAND backup and only using an arm11 exploit, while on 9.2 you have everything at your disposal plus a NAND backup of anything does go wrong.

Edit: not to mention the "downgrade" to 2.1 is now a CTR transfer instead of a full normal downgrade - even safer!

This is what you're saying:
Say two people want to climb a mountain. It involves climbing up sheer cliffs with no harness or anything. Then you get 9/10 of the way up but you can't see the view yet. For some reason, there is a cable car/ski lift thing that carries you the last 1/10 of the way right to the top.
One person says (this is you): "The cable could snap! The operator could be drunk! I'm going to stay here." The other says, "are you crazy? You just risked life and limb to only *nearly* climb a mountain? And you could get all the rewards just by taking a super safe cable car the rest of the way?" And he goes to the top and enjoys the magnificent views over the whole Alps while the other guy just gets to look at rocks and shrubs.

 

[Arkansaw]

I dispute that the ctr_transfer is safer. Maybe it is safe or maybe it is not. But the step itself involves greater risk compared to downgrading a series of titles

In fact it is due to ctr_transfer, that I do not recommend a9lh for o3ds systems, unless it can be done at the usual 4.x to 9.x sysnand

 

[Glyptofane]

What's apparent, and now finally admitted, is that the process is, or at least was more dangerous and prone to bricking than the old, long method. At least we have acknowledgement and the attempt made to hopefully fix it now.

 

[Altairseven]

Well, I'm am very happy to report that I succesfully performed the hardmod and managed to unbrick the N3DS without any mayor issue.

I also created the firm1firm0 xorpad, and i'll send them alongside the bricked nand dump to @Aurora Wright as soon as they finish uploading.

 

[gkoelho]

Well, otpless al9h installation is the only thing that can go wrong as it depends on HASH stored on ram, so its just expected. You bricked on the only step possible, accept it.

 

[Quantumcat]

I dispute that the ctr_transfer is safer. Maybe it is safe or maybe it is not. But the step itself involves greater risk compared to downgrading a series of titles

In fact it is due to ctr_transfer, that I do not recommend a9lh for o3ds systems, unless it can be done at the usual 4.x to 9.x sysnand

No..... installing a bunch of titles means uninstalling one before installing the replacement. If the process stops when you've uninstalled a title but not installed its replacement, you'll brick, or have a console with some functions broken.

Whereas the CTR transfer is an atomic operation (I believe, not 100% sure), in that either the process finishes, or doesn't happen at all. There's no limbo halfway state that can cause a brick. Not to mention that important console data is dumped first and it only has to write on part of your NAND not the whole thing like a full downgrade.

 

[Selver]

Well, I'm am very happy to report that I succesfully performed the hardmod and managed to unbrick the N3DS without any mayor issue.

I also created the firm1firm0 xorpad, and i'll send them alongside the bricked nand dump to @Aurora Wright as soon as they finish uploading.

Altairseven, can you let us know the results of any investigation that @Aurora Wright does? It'd be very interesting to understand where any problems may lie.

 

[FruitsEve]

It seems there's random (and very rare) ARM9 memory corruption in between the reboot at play. The latest release should mitigate this since the majority of the code (all except for two opcodes) was moved to ITCM (which shouldn't corrupt).

Well it seems it didnt fix the issue, a user in an unnamed discord got a brick on the newest version 2.6.4 poor guy hope that doesnt happen to me when my SuMo XL comes. Thanx for your hard work Aurora, hope you get to the bottom of this.