D
Deleted User
Guest
Proceeded with the otpless at your own risk.If you want the best installation experience I sudjest uninstalling menuhax once you are in the homebrew launcher then proceed with the guide and launch decrypt9.Keeping menuhax uninstalled during decrypt9 increases the success rate I think.
Last edited by ,
I wouldn't risk if it I were you. I installed A9LH on my N3DS, and a few others, when ctrtransfers were the standard and nothing ever went wrong. Just note that SafeA9LHInstaller might glitch out and won't display anything during installation. This is ok. Just don't close your 3DS when on 2.1, or you will get permanently bricked.
Please elaborate, at what point is decrypt9 used?
I'll take your word for it, I am not really in a rush so yeah. Thanks
Quite a bit. It's used to downgrade to 9.2 if you're not on it already, then to 2.1, then to upgrade back to 9.2 (provided you don't have an EmuNAND dump to flash over SysNAND, in which case you use D9 to do so).
Last edited by Joom,
D
Deleted User
Guest
In this part of the guide right here https://3ds.guide/homebrew-launcher-(no-browser) since you are on a new3ds it tells you several ways to launch the homebrew launcher with ds cart exploits,but what you can do is use menuhax instead if you don't have a cart exploit game,then uninstall menuhax once you are in the hombrewlauncher.You then of course proceed to the decrypt9 section where it tells you what files need to be in you're 3ds before launching decrypt9.Be Shure to read everything first though.
Last edited by ,
- Joined
- Jan 11, 2016
- Messages
- 6,032
- Trophies
- 1
- Age
- 24
- Location
- 日本
- Website
- www.facebook.com
- XP
- 3,212
- Country
Personally doing the not OTPLess is a lot safer in a sense with reports of people bricking but down to the user whether they want to or not
I myself made use of the OTPless solution.
Was watching the thread the whole time, back when it was first released, and nobody got bricked, so I figured that even though it being called UnsafeA9LHinstaller, that I'd be fine. Already backed up my NAND so worst case scenario I'd have to get a hardmod.
Long story short, use the guide if you want to be extra safe, use OTPLess if you want to be done in 10 seconds flat.
Sent from my iPhone using Tapatalk
Was watching the thread the whole time, back when it was first released, and nobody got bricked, so I figured that even though it being called UnsafeA9LHinstaller, that I'd be fine. Already backed up my NAND so worst case scenario I'd have to get a hardmod.
Long story short, use the guide if you want to be extra safe, use OTPLess if you want to be done in 10 seconds flat.
Sent from my iPhone using Tapatalk
I've done quite a lot of otpless a9lh installs (maybe around 40 by now) and no single brick, however IMHO, it only saves me maybe 10mins of installation. And 2.1 downgrade isn't as hard as it used to be anymore. I say go for non-otpless.
Sent from my SM-G935F using Tapatalk
Sent from my SM-G935F using Tapatalk
I don't even believe that 1 single report of bricks was real and was made by a bunch of people who very clearly didn't want or like otpless when it first came out. And it was impossible for any dev and any person purposely trying to recreate this "bug" to have it happen.
I still hack 3ds and to this day use otpless, obviously do what you want but I never saw one video of someone running safearm9installer and bricking just reports from "new" users. It's very fishy to me
I still hack 3ds and to this day use otpless, obviously do what you want but I never saw one video of someone running safearm9installer and bricking just reports from "new" users. It's very fishy to me
There is no reason for another one of these threads. If you are in doubt, just go with the guide.
I completely agree that it's all user error. Look at any "did you get [X] hacked successfully" poll taken for any system that can be modded and you will see north of 1% failure rate on every single system.
People don't read carefully, don't fully understand what or why they're doing something, and then they brick and blame others.
I did the OTP-less install of Luma and a9lh on my first try, working around a partial downgrade failure because I read and re-read multiple guides on how to do it.
Last edited by DavidBowman,
It's actually a very rare MCU brick. This is why devs haven't been able to reproduce it because it's totally random and there's like a 1/1000 chance of it happening. That's still too much of a risk regardless of how miniscule the chances are, though, and this is why it was removed from the guide.
Yup. They tried using ITCM instead of ARM9 mem, tried adding wait-timers into the MCU portion, but still some people randomly brick. Just like Joom said, devs cannot reproduce otherwise they'd be able to fix it.
As I said in the beginning to OP, if OP is scared of OTPLess, then don't do it.
--------------------- MERGED ---------------------------
For the poll sure. For OTPLess installs, no.
No? It's not a MCU brick. For some reason you just don't get code execution again after the soft reboot. You can't recover a MCU brick with an hardmod.
Last edited by Aurora Wright,
I done the OTP less on a N3DS of a mate of mine a few days back.
I haven't done any transfer or other thing to retain save data.
Just transfered the DSiware to the N3DS, hacked it and installed everything on a freshly formatted NAND.
Haven't received any problems what so ever.
I haven't done any transfer or other thing to retain save data.
Just transfered the DSiware to the N3DS, hacked it and installed everything on a freshly formatted NAND.
Haven't received any problems what so ever.
I know you can't. And I'm going by what was said in #Cakey last night, so that's where that misinformation came from.
Has there been any proof? Anecdotal reports aren't good enough for proof, especially when that user's skill level is unknown. I'm honestly asking, not arguing.
The reason I refuse to believe that this isn't just user error sans proof is because I do software QA for a living, and even on my team there are people who are professionally certified (multiple levels too) for this work through the ISTQB/ASTQB who miss things in the software documentation (I'm not claiming I'm above this). I closed two erroneously-reported defects today alone because the coworker (she holds certifications) who reported them did not understand the intended behavior. She didn't read carefully enough which led her to run "unsuccessful" tests.
Last edited by DavidBowman,
Similar threads
