Hacking Does Otp Less have a higher chance of becoming bricks?

[65754]

Is otpless simple and does not extract otp and is it recommended to use it?

 

[HyperT]

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

 

[proflayton123]

Personally I recommend following the bible guide https://3ds.guide

 

[Sketchy1]

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.

 

[gkoelho]

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.

 

[proflayton123]

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

 

[The Catboy]

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.

 

[Deleted User]

The Radom brick ain't worth it.

 

[Mikemk]

MCU bricks are not restorable

It doesn't brick the MCU, it corrupts the NAND

 

[proflayton123]

It doesn't brick the MCU, it corrupts the NAND

Well a hardmod but without nand backups which are valid it's paper weight

 

[Mikemk]

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.

 

[proflayton123]

No, only the firm is invalid. I don't know how, but the firm0/1 can be replaced without decrypting.

Source? Ideally..

It appears Dec9 can decrypt the FIRM0/1 partitions

 

[The Real Jdbye]

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.

 

[Cuphat]

Well a hardmod but without nand backups which are valid it's paper weight

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.

 

[Sketchy1]

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.

So if it was hard to replecate... It was random because you had to get lucky to do it purposely

 

[naddel81]

Bricks from the OTP/2.1 method are rare - outside of user error

wait- there are 2.1 bricks that are NOT based on user error?

 

[HyperT]

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

 

[naddel81]

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?

 

[Ryccardo]

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

 

[HyperT]

but 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]