Hacking Permanent Custom Firmware?

[dubbz82]

I'm hoping that eventually someone works out an easier way to dump OTP (or at least a different way) because as of right now, I don't believe arm9loaderhax is viable at all on a 2ds, because of the semi bricking it'd cause at the system setup (or do you need to go through this to dump the OTP?) because of the 3d slider stuff...

 

[Apache Thunder]

Downgrading to 1.0 does not usually result in resetting the system. So 1.0/2.0 won't brick a 2DS. As long as you don't attempt to do a system format, it will work. o3DS's are easier to dump OTP on since you don't have to do any encryption changes to CTR_NAND to make it work.

2DS may have some top screen display issues on 1.x firmware. But it will be useable for dumping OTP at least.

 

[dubbz82]

I'll probably still wait for it to be idiot proofed (and ideally for some more development to be done with it, since this could theoretically lead to something similar to bootmii on the wii) before I start messing with it, on grounds that my system's not hardmodded, and it doesn't seem like you can do a whole lot with it (yet)

 

[izy]

cause you could have sysnand cfw+ emunand cfw so even if you remove your SD you still have CFW features, maybe integrated update blocking making sysnand 100% immune to updates


but yeah there isnt too much to be gained by sysnand cfw (which is why nobody is really too fussed about arm9loaderhax)

unless something goes wrong and you brick your Device GG, which would then require hardware mods to fix.

At least with the psp 1000-2000 series they had Pandora battery which bypassed boot and you could flash back CFW or OFW after a brick.
3000 and GO doesnt have this but they have emunand basically but the standby isnt as good

Also psp 1000-2000 had recovery menu which you could boot Update.pbp from directly and restore the system.
they basically came with inbuilt hard mod, you could backup system files directly from flash and edit them, if they failed to work you could restore them

Besides the PSP Permanent CFW was more secure than 3DS we had so much more access to the system for customisability and a larger safety net, the amount of system files we can safely edit is immense.

3DS has emunand its safe non intrusive and can be recovered from without any device hard mods and since the device has a great standby its pretty much permanent.
Why take the risk on sysnand when you can virtually have everything on emunand which is 1000% safer.

+ the fact you get better read and write speeds on SD cards than you do with the onboard sysnand which is most likely a Class 4 card soldered onboard

 

[The Catboy]

Coldbooting into emuNAND is really the best way to have a "permanent" CFW. Not to mention safer because it's unlikely to do permanent damage if you brick your emuNAND.

 

[Apache Thunder]

Well because Arm9LoaderHax needs a nand mod, that negates the "safety" of having emunand. Because if you break something on sysnand, you can just restore a backup....Because you have a nand mod.

 

[hobbledehoy899]

Coldbooting into emuNAND is really the best way to have a "permanent" CFW. Not to mention safer because it's unlikely to do permanent damage if you brick your emuNAND.

Fixed it.

 

[The Catboy]

Fixed it.

Auto-correct is a dink.
Thanks though

 

[hobbledehoy899]

Auto-correct is a dink.
Thanks though

You are welcome.

 

[Ripper00420]

unless something goes wrong and you brick your Device GG, which would then require hardware mods to fix.

At least with the psp 1000-2000 series they had Pandora battery which bypassed boot and you could flash back CFW or OFW after a brick.
3000 and GO doesnt have this but they have emunand basically but the standby isnt as good

Also psp 1000-2000 had recovery menu which you could boot Update.pbp from directly and restore the system.
they basically came with inbuilt hard mod, you could backup system files directly from flash and edit them, if they failed to work you could restore them

Besides the PSP Permanent CFW was more secure than 3DS we had so much more access to the system for customisability and a larger safety net, the amount of system files we can safely edit is immense.

3DS has emunand its safe non intrusive and can be recovered from without any device hard mods and since the device has a great standby its pretty much permanent.
Why take the risk on sysnand when you can virtually have everything on emunand which is 1000% safer.

+ the fact you get better read and write speeds on SD cards than you do with the onboard sysnand which is most likely a Class 4 card soldered onboard

Here here sir with my 95mb read and write speeds, and I was just curious...lol

 

[tivu100]

This is pretty much perma CFW:

https://github.com/delebile/arm9loaderhax/

You need to dump OTP on your console before you can use it though. Not for the faint of heart. Nand mod required!

But it does allow for sig patched 10.5 sysnand! You can modify system titles and do what ever you want pretty much. Because Arm9LoaderHax occurs very early in the boot process, you have a lot of freedom with what you can do with it.

So downgrade to <3.0 will surely cause brick for non-hard mod 3DS? Or due to the fear of bricking, it's not recommended?

 

[dubbz82]

So downgrade to <3.0 will surely cause brick for non-hard mod 3DS? Or due to the fear of bricking, it's not recommended?

I'd guess it's probably more so the second one, particularly since it's not exactly what I'd classify as well tested at this point.

It would be cool if this eventually gets proven to be viable and (at least relatively) bug free, because it could really open some doors for cool stuff.

 

[TecXero]

With HomeMenuHax, it autoboots, anyway, into EmuNAND with CFW. Honestly, I prefer EmuNAND, it's a lot safer and gives you access to everything. Sure, CFW was nice on the PSP, but having to wait for a CFW update when a new OFW came out and possible bricks, I think EmuNAND is a bit of a better evolution on the idea. Sure, bricks weren't that bad with the PSP, just dig out the jigkick battery, but with the 3DS it's simply restore a previous dump. The only thing that would be nice on the 3DS end is better bootrate with HomeMenuHax and maybe boot times, but they're very minor complaints that I don't expect to happen.

 

[tivu100]

I'd guess it's probably more so the second one, particularly since it's not exactly what I'd classify as well tested at this point.

It would be cool if this eventually gets proven to be viable and (at least relatively) bug free, because it could really open some doors for cool stuff.

How about downgrading EMUNAND instead? Hasnot EMUNAND the same OPT as SYSNAND or what?

 

[BADDINOROX99]

I think it's as good as it gets we already have the ability to coldboot into Emunand..as it is I see I bunch of people screwing that up and creating new threads Evey other day asking for help about the same thing and flood these forums with spam..I just risked bricking today just to see if I can uninstall preistalled software on my Emunand (it worked by the way) but if I would have screwed up my Emunand I would have just restored my back up or started over from scratch most people don't have the patience to read through every thread to find an answer to their problems they just create threads and spam and take away priority to actual development threads,in my opinion if this is doable its just spam waiting to hit thease forums

 

[dubbz82]

How about downgrading EMUNAND instead? Hasnot EMUNAND the same OPT as SYSNAND or what?

that's actually a REALLY interesting thought...and yeah that'd be a hell of a lot safer.

 

[Apache Thunder]

OTP is a register. It's not stored on NAND. The secret 200 byte keystore is on NAND (perhaps you got the two mixed up?).

OTP is not on emunand and wouldn't yield anything. Plus OTP is already locked by the time you firmlaunch a 1.0 emunand. So it would not have worked from the start even if OTP was on NAND for some reason.

 

[Vappy]

How about downgrading EMUNAND instead? Hasnot EMUNAND the same OPT as SYSNAND or what?

The OTP is already read-protected by the time you can start emuNAND, and doing a firmlaunch doesn't deprotect it.

 

[dubbz82]

OTP is a register. It's not stored on NAND. The secret 200 byte keystore is on NAND (perhaps you got the two mixed up?).

OTP is not on emunand and wouldn't yield anything. Plus OTP is already locked by the time you firmlaunch a 1.0 emunand. So it would not have worked from the start even if OTP was on NAND for some reason.

That bites, but thanks for clarification.

 

[tivu100]

Saw 2.1.0-4U on that site (lats post of the thread). Anyone can verify it's the correct one?

How to make the key into bin file?