Hacking Bricked :(

  • Thread starter Thread starter royant1
  • Start date Start date
  • Views Views 11,634
  • Replies Replies 87
You can't get the otp from emunand. after you "brick" emunand by downgrading, you "fix" the nand and flash it to sysnand in order to get otp.
 
Ok, downgrade emu first just so if it fails it's a whole lot easier to recover from? I thought the idea was so you could extract otp directly from the emunand (which should have the otp as well?)

Yes. You downgrade, check downgrade then flash it, take otp, and flash back to 9.2

U cant take it from a 2.1 emunand for a number of reasons. The main one is that only up to 2.x the system had a flaw where the OTP would not be cleared from ram after being read, thats why we can get it. Because of that the actual system needs to be on 2.1 or it will auto-erase it milliseconds into boot, much before any code can be executed and is locked forever until the console is powered off again.
 
  • Like
Reactions: Graham182
I assume you should dump the OTP a couple of times though, right?

No need for it. U just assure it has the right size (256kb if correctly remember it)

U need to make sure it is right or it will brick during a9lh installation, but as everything else, is just a matter of following directions.
 
I assume you should dump the OTP a couple of times though, right?
Why? The OTP Helper has a validator. If the file (for me) was 256 bytes it should be fine and it was. Plus the OTPHelper said it was valid.
 
You can't extract the OTP from EmuNAND, in fact, there is no CFW that can load a 2.1 EmuNAND. It's just for safety, to make sure the downgrade process goes smoothly, since it doesn't always and a failed downgrade is a brick.

That was just a misunderstanding on my part about what the otphelper actually does, by reading the guide I thought, even though a cfw couldn't access the 2.1 emu, that otphelper was able to set it up to extract the otp.bin from it. I see now you go into otphelper twice, one to make sysnand 2.1 from the successful 2.1 emu, and a 2nd time to extract the otp. Never mind me, quietly going mad :P
 
Why? The OTP Helper has a validator. If the file (for me) was 256 bytes it should be fine and it was. Plus the OTPHelper said it was valid.

Oh, okay. When I did my O3DS there was no OTPHelper. I dumped the OTP 2 times and compared the hashes. This sounds much more convenient now.
 
Oh, okay. When I did my O3DS there was no OTPHelper. I dumped the OTP 2 times and compared the hashes. This sounds much more convenient now.
Sure is! Thanks to the guide by Plailect and the OTPHelper from d0k3 its much easier. I waited actually until OTP got easier to dump before I did it. Since I had no real use for it.

EDIT: all and all, it just took about 1hr to do my OTP. But I read and read before I did the steps so maybe 2 hours total.
 
Hey guys, all gone well until:

Copying EmuNAND data to SysNAND
Make sure you have restored EmuNAND from emuNAND_original.bin before doing this

  1. Go to "EmuNAND Options" then "Partition Dump...
"SD is not formatted for EmuNand" (and thus failed)
Also in the main menu it shows the SD size " & no emunand"

I did follow the guide and restored emunand (and sysnand)..

Any advice?


....

I tried to load emunand9 from the HBL menu (via sysnand) but it just gives me a red screen at the bottom and kicks me back to HBL menu.. Same happens when i try to select OTP Helper or Decrypt9 via HBL menu...

L+R at boot loads decrypt9, so i guess im not totally screwed?

Help
 
Last edited by LuigiXL,
Hm... I'll travel trough Web to find a solution ; ) hoprfully... xD

Is ur sd card ejected?
If not unnount and then miunt ur sf card again
 
Last edited by V0LT!GE,
  • Like
Reactions: LuigiXL
"SD is not formatted for EmuNand" (and thus failed)
Also in the main menu it shows the SD size " & no emunand"

That's unusual. This would imply the SD card has suddenly lost it's emunand partition - which could only happen if you deleted the partition with decrypt9 or reformatted the SD card.

If you still have an emunand backup, use decrypt9 to create another emunand partition and restore your backup to it and proceed with the remaining steps.
 
That's unusual. This would imply the SD card has suddenly lost it's emunand partition - which could only happen if you deleted the partition with decrypt9 or reformatted the SD card.

If you still have an emunand backup, use decrypt9 to create another emunand partition and restore your backup to it and proceed with the remaining steps.

Thanks, oddly Emunand9 detects i have RedNAND, but my Decrypt9 does not.. I am using the latest version, should i try an earlier one? or should i try the option to "convert rednand to emunand" in emunand9?
 
Thanks, oddly Emunand9 detects i have RedNAND, but my Decrypt9 does not.. I am using the latest version, should i try an earlier one? or should i try the option to "convert rednand to emunand" in emunand9?
You need to use a later version of Decrypt9WIP than the most recently released one to have RedNAND support. There should be a test build linked somewhere in its thread or you can compile it yourself.

If you are just doing NAND backup/restore type operations, just use EmuNAND9 as it works with it fine.
 

Site & Scene News

Popular threads in this forum