Hacking Questions about removing CFW.

[AriaNights]

I’m asking not because I actually want to remove CFW per se — moreso because the threads on it and responses caught my attention, and I want to sate my curiosity without bricking my poor 3DS.

Assuming someone had to remove CFW from a n3DS, does anyone know why it tends to brick nds mode? I’ve sort of been able to catch on to why it bricks 3DS mode (home screen/theme manipulation, region changes, non-official .cia files/bad tickets, etc) but the DS mode problems make me legitimately curious as to what happened.

Of course, stock firmware is bound to act up if modified by CFW anyways, if that CFW is removed. And if this is a repeat thread, my apologies for clogging things up! Even so, I’d want to know if there’s any answers to this, or where I could find those answers.

Thank you!

 

[The Catboy]

Chances are the reason any part of the OFW bricks is due to previous medications to that part and doing a dirty uninstall of the CFW. If someone just removes their entrypoint and CFW, but doesn't revert any of the other changes back to stock, then chances are high something is going to break as a result. This is actually why it's highly recommended to have a clean version of your NAND backed up if you ever plan to revert back to stock.

 

[AriaNights]

Chances are the reason any part of the OFW bricks is due to previous medications to that part and doing a dirty uninstall of the CFW. If someone just removes their entrypoint and CFW, but doesn't revert any of the other changes back to stock, then chances are high something is going to break as a result. This is actually why it's highly recommended to have a clean version of your NAND backed up if you ever plan to revert back to stock.

I see! For an NDS mode to brick, then, would it relate to having something that made heavy use of it (like TwiLight Menu/other nds emus), that weren’t properly removed previous to the CFW being uninstalled?

I’d suppose if you removed everything properly, /then/ removed the CFW, it’d function generally fine. Is there any firm answer as to why common CFW entrypoints seem to stop working after reverting to stock? I recall noting that a few different methods of loading CFW stop functioning afterwards, though I can’t exactly remember which ones (I think seedminer was one of them, though I imagine you’d know better than I). Is there something in the CFW that accidentally patches those methods, or is it still blurry?

Again, thanks for answering my questions! The more I look into this stuff, the more interesting it gets.

 

[lilyuwuu]

The DSiWare Management menu becomes inaccessible for Bannerbomb3-based methods when custom DSiWare like TWiLightMenu++ aren't removed. A lot of people didn't uninstall it before because it would only show up in FBI (not in Data Management).

These days, especially with the checks on the Uninstall CFW guide, nothing should break. If something does, assuming you're not bricked, browserhax can usually reinstall cfw, even if keyboard is broken because of custom keyboard left installed.

 

[AriaNights]

The DSiWare Management menu becomes inaccessible for Bannerbomb3-based methods when custom DSiWare like TWiLightMenu++ aren't removed. A lot of people didn't uninstall it before because it would only show up in FBI (not in Data Management).

These days, especially with the checks on the Uninstall CFW guide, nothing should break. If something does, assuming you're not bricked, browserhax can usually reinstall cfw, even if keyboard is broken because of custom keyboard left installed.

Interesting! Thank you for the knowledge — I was wondering why things did brick the way they did, since (at least at first) I wasn’t sure exactly /how/ this stuff happened. Like, I had my theories, but I pretty much just started figuring this out, lmao.

Thanks for appeasing my curiosity!