Can we go back to using N3DS OTP?

[mysterypaint]

The community has at least one otpless brick daily in the past week, and I feel that the 2.1 otp method was much more consistent and could have avoided such a brick.

pbanj claims to have unbricked an otpless system, gave the NAND and xorpads to TuxSH and AuroraWright, and found no signs of a cause for the brick.

[Lawdayo]

That is exactly what I thought. The (un)safea9lhinstaller caused so many bricks (including me). But the OTP method was safer than the OTPless one. Moreover, on the guide it is not written that we could use the N3DS to do the 2.1.0 ctrtransfer step. It would be more clear to say that we can either do the 2.1.0 crtransfer with the N3DS without a risk of brickn, or do the OTPless method for the N3DS, with a risk of brick. That is just my opinion

[Plailect]

No. 2.1.0 on the New 3DS was much more unsafe.

MCU bricking was fairly common, where as your stat (which I guess was retrieved from thin air) of a brick per day caused by the OTPless method would still be less than 0.065% of daily installs.

I calculate the number of installs by looking at the unique non-bounced traffic of the Installing arm9loaderhax page.

Here are some stats for that page on November 17th (which is by all metrics a very average day for traffic stats):

( 1 / 1538 ) * 100 ≈ 0.065 %

[pbanj]

we have had 3 or 4 today come to the server

[mysterypaint]

If I may ask, how does a non-bounce statistic prove actual values for otpless installs? Some of those users are O3DS, some finished the guide on that page, and others come directly to the chatroom for advice.

How many times have you seen an N3DS brick from a 2.1 otp install that wasn't just user error? I can't recall a single N3DS 2.1 otp install that failed because of an unexpected issue like otpless has been doing for many users we've seen since it was recommended in the guide.

I'm not relying only on statistics: I'm helping people directly and seeing them brick firsthand each time they attempt otpless.

[mysterypaint]

We had another otpless brick today... Can we please go back to the 2.1 otp method?

[ihaveamac]

the difference is that bricks on 2.1 New 3DS are mostly caused by user error. unless there's another I don't know of, they only happen by using sleep mode. other than that, there are hardly that many risks being on 2.1.

on the other hand, otpless bricks are random and nobody seems to know what is causing them, or how to fix them. and we seem to be getting one or two a day on Discord.

I would consider moving back to the 2.1 method, or at least make it the recommended option or something. otpless so far has turned out to be more risky than originally thought.

[pixel-stuck]

@ihaveamac random bricks on 2.1 were also occurring, and we still aren't sure why those were happening (we had several users who bricked without entering sleep mode). Honestly, I think OTPless bricks are down to implementation, I've never liked the way safea9lhinstaller did OTPless. I'd recommend we try using SciresM's unsafea9lhinstaller in the guide, and see if we have similar issues. If not, then we know that the problem is down to implementation

[ihaveamac]

weird, because I've never heard of these random bricks on 2.1, only the ones caused by sleep mode. were these with using ctrtransfer, or the really old method that used rednand?

well if that's the case, then let's try out unsafea9lhinstaller and see how many bricks happen then. if the same thing occurs though, then I still think the 2.1 method should be used in the mean time.

[pixel-stuck]

Yeah, we had several people who came into IRC with random 2.1 bricks.... Also, keep in mind that the 2.1 ctrtransfer method wasn't around long (the random bricks happened before and after) so there wasn't much data gathered for that in terms of safety. Anyways, reasonably, we try out unsafea9lhinstaller (which, afaik, has never had a brick, though that may just be due to the small number who used it) see what happens then, and if we still are getting lots of bricks, then I suppose ctrtransfer is our best option

[Lawdayo]

I just did the installation of the hax with OTP and 2.1 ctr transfer on my New 3DS. It worked like a charm.

[Plailect]

I'll reopen this and keep an eye on the issue.

[AuroraWright]

I don't really think it's down to the implementation, as I had a lot of people run a memory tester for FCRAM and ARM9 memory, which they did for hours in some cases (with a rate of a reboot every 2 seconds on average) and no report of memory corruption was reported. On top of that, I simulated a FCRAM memory corruption environment using a different reboot method and the code always executed after reboot, even if it crashed or installed garbage to FIRM0; while these bricks have a consistent failure in getting code execution again after the reboot (which could be noticed from the fact the screens never came back in bricks with previous SAI versions).

It's either a bug in CakeBrah which causes memory corruption before the reboot (and so the "UnsafeA9LHInstaller" method would work around it) or something that wasn't taken into account in the code 10.0 arm9bin "decrypts" to. I excluded timing failures in taking over ARM11, screen init failures and the like by putting them after the install ends in the latest version.

[Plailect]

As far as I can tell, SafeA9LHInstaller v2.6.6 seems to have fixed these bricks. I've seen no reports of any so far.

[pbanj]

Ya we have yet to see any on the discord either. So fingers crossed boys

[pbanj]

just had someone brick with 2.6.7

[james-d-elliott]

Are we getting them to test SD after these bricks? Pretty important in my opinion to exclude other possible causes. I'm fairly sure if you don't have all of the correct files it wont start the install - if that's incorrect we probably need archives with their SD contents too.

[Margen67]

Have they tested their SD cards with something like h2testw?

[pbanj]

All the ones I've fixed I haven't changed a thing from what the user has done. I just flash the nand backup and run the installer. It has worked every time, so I doubt the SD card is to blame. A few of the people have run the test before doing anything because the guide mentions that it can cause issues. Nothing like watching someone go from someone you're helping to your customer right before your eyes. Even when that person has done everything correctly.

[pbanj]

kind of a dumb idea but maybe menuhax is the issue. every time i have done and install i use either freakyforms or browserhax and i never have an issue. I know different entry points can cause the downgrade to not want to work so maybe its the same case with this. every system I've gotten in to unbrick has had menuhax shit with more than one payload so it wasn't just for the initial downgrade to 9.2. when I was trying to get my system to brick before I got my hands on nand dumps to pass a long I couldn't get it to brick and I was using browserhax. maybe tell them to not reinstall menuhax once on 9.2 and to use browserhax to get into decrypt9 and then safea9lhinstaller and see if the bricks go away.

[AuroraWright]

My testing is done on a clean 9.2 NAND (freshly formatted) and freakyhax. And I've never had a brick either.

[KittenWizard]

Maybe you guys are onto something about the issue possibly being menuhax, particularly following the Homebrew Launcher (Browser) path in The Guide.

EDIT: Just noticed this thread which is curious.

Checking the menuhax github it looks like maybe this type of thing happened during the process SafeA9LHInstaller?

• https://github.com/yellows8/3ds_homemenuhax/issues/225
• https://github.com/yellows8/3ds_homemenuhax/issues/205

If this is the reason for all the recent OTPless bricks, its probably a good idea to notify menuhax dev and suggest a warning on The Guide?

Personal Disclaimer: I am just chiming in, trying to help everyone toward a possible next step. I'm waiting on figuring this all out before I proceed to this step in my n3DSxl install.

[FrozenChen]

Thats different, the exploit menuhax uses in 9.2 is not the same as the one used in 11.0(firmware described in the issues). The one used in 9.2 is called themehax and the one used in 11.0 is called sdiconhax they not the same since themehax is a theme based exploit while sdiconhax is based icon cache based exploit(correct me if im wrong on this)so the problem is not related

[pbanj]

maybe for the sake of ruling it out @Plailect can change it over to tell them not to reinstall menuhax and to just use browserhax once on 9.2 and we can see if the bricks go away. if they do then we know it is something to do with menuhax, if not then it has to be something else.

[Plailect]

Menuhax is entirely unrelated. I'd give it a 0% chance that this arm11 based entrypoint is even remotely relevant to the arm9 based OTPless install...

[pbanj]

ya i set up a poll and the menuhax theory is deff out https://docs.google.com/forms/d/1CULiFocACpleQC5_oOdQTfk2NmxyL6laz59lNoqLT30/viewanalytics

[twig]

@AuroraWright could it be due to people using outdated versions of hax?

ie. old menuhax, exploits, etc

[rsubtil]

@twig AFAIK when you install exploits, you install a specific exploit for a specific version, so there's no such thing as outdated versions of hax.

[prusswan]

even if the issue is related to menuhax, surely it should not bear the responsibility for a more intrusive sysnand hack

not necessarily outdated hax, but some versions of hax may simply be incompatible with each other, even different versions/variants of the a9lh installers. Just not possible to test all the combinations exhaustively

[pbanj]

after looking at the poll results menuhax has nothing to do with it https://docs.google.com/forms/d/1CULiFocACpleQC5_oOdQTfk2NmxyL6laz59lNoqLT30/viewanalytics

[Plailect]

https://github.com/Plailect/Guide/commit/fb0a11cc7a6c7b292fd7ede9af30a963c8e610f1

Removed until this can be sorted.

[pbanj]

The more I do otpless the more I'm starting to think it might be something the user caused. I'm still using it to do systems as they are already hardmodded, so if it bricks its a 5 min fix. I have still yet to have one brick on me.