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.Is otpless simple and does not extract otp and is it recommended to use it?
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.
It doesn't brick the MCU, it corrupts the NANDMCU bricks are not restorable
It doesn't brick the MCU, it corrupts the NAND
No, only the firm is invalid. I don't know how, but the firm0/1 can be replaced without decrypting.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.
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.No, only the firm is invalid. I don't know how, but the firm0/1 can be replaced without decrypting.
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.Well a hardmod but without nand backups which are valid it's paper weight
So if it was hard to replecate... It was random because you had to get lucky to do it purposelyIt'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.
Bricks from the OTP/2.1 method are rare - outside of 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 sincewait- there are 2.1 bricks that are NOT based on user error?
but nfirm is untouched after a9lh install, isnt it?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
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 itbut nfirm is untouched after a9lh install, isnt it?
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]but nfirm is untouched after a9lh install, isnt it?