Separate names with a comma.
Discussion in '3DS - Flashcards & Custom Firmwares' started by 65754, Jan 14, 2017.
Is otpless simple and does not extract otp and is it recommended to use it?
No. It still has something unknown causing a random brick. [pretty sure its a fundamental issue]
Bricks from the OTP/2.1 method are rare - outside of user error
Personally I recommend following the bible guide https://3ds.guide
otp dosent exactly have a higher brick chance, its just otp-less caused inexplainable bricks that were completley randomized, so even if you followed to the T, you could still brick anyway. but you shouldnt worry about/use it, it was removed from the guide.
It's not random and itsn't inexplicable, it's just very hard to replicate. Its some form of corruption on ram/fcram during the mcureboot(soft reboot). Otpless works because its hash is stored in ram and due to an oversight it its not cleared during the mcureboot and then it's used to install the the exploit to firm0\firm1. Bricks occur when the hash gets corrupted and you install trash data to the firm therefore bricking it.
MCU bricks are not restorable
This was heavily debated before the results are mixed. It's not the brick rate that is the issue, it's the fact that what causes the bricks is unknown.
The Radom brick ain't worth it.
It doesn't brick the MCU, it corrupts the NAND
Well a hardmod but without nand backups which are valid it's paper weight
No, only the firm is invalid. I don't know how, but the firm0/1 can be replaced without decrypting.
It appears Dec9 can decrypt the FIRM0/1 partitions
Only if you know the original (decrypted) data that was written into firm0/firm1, and since it's corrupted garbage data, the chances of that being the case are slim.
Until sighax, anyway. If you are doing anything remotely questionable to the NAND and you don't have a full working backup, you honestly deserve a brick if something does happen.
2.1 ctrtransfer to get the OTP can still end in a brick, but those are almost always caused by user error, whereas OTPless bricks are essentially just luck of the draw.
So if it was hard to replecate... It was random because you had to get lucky to do it purposely
wait- there are 2.1 bricks that are NOT based on user error?
Sort of depends on your definition of user error, but anything that messes with nfirm can brick. i.e. hardware defect [3ds or sdcard] could lead to using faulty otp.bin or a9lh payload, so if you'd class those as user-error or not. And although the cause of the rare softbricks from downloading [without formatting first] has been identified and fixed [save data from a system app] there may have been 1 since
but nfirm is untouched after a9lh install, isnt it?
The copy on ctrnand (used by firmware.bin-less CFWs) is untouched, but once you have A9LH installed it doesn't matter as you can just use software to change it
The copy in the kernel partitions is changed (with a n3ds kernel used for secondary exploit), it's called A9LH for a reason
BTW, if this topic is remotely inspired by my speedrun, I did make a nand backup (years ago) lol
Yea. Once a9lh is added to the nfirm in that second or two, your virtually brick-proof. Any actual hard-bricks occur in that 1-2 seconds. [Other than 2.1 n3ds sleep mode I guess]