Why do you think so? AFAIK the dev team plans to release at some point, but when is yet unsure. There has been a lot of discussion recently because some people are unhappy with seeing teasers all the time and not having anything to install on their 3DS consoles. Maybe that's what you meant?So... The KARL3DS public release has been canceled? That's really sad
It seems that we won't ever see those HB only CFW we hoped for :/
I don't trust NTR or Roxas to achieve this...
Me too! NTR is good and all but without firmware spoofing you can't really play the newer games.To be honest, I don't really care about commercial ROM loading at all. I have a N3DS, and would simply like a way to have an EmuNAND setup, spoof firmware so that I can play the newer games without having to update (I know I can spoof firmware to get into the eShop, but I'd like to play games like Xenoblade without updating), and be able to still open the Homebrew Launcher. I don't mind if I can't install .cia homebrew, I don't mind if I can't load ROMs with it, I just would like those three features without having to buy a Gateway, since I'm a penniless college student.
Correct me if I'm wrong but what I understood is:
It allows you to run your own code from RAM after a soft-reboot (not possible from cold reboot).
Basically, you need to write your execution code (ie. exploit code) into ARM9's RAM area, and trigger a reboot (that reboot has be done by means of creating an 'error' intentionally).
Triggering a reboot is possible in such a way that bootrom doesn't get a chance to change the location of hardcoded point of the place where your code will be.
If you are successful in executing your code from ARM9's RAM, that means you are the 'first' to run the code ie. the bootrom didn't get the chance (I think it's called preboot ARM9 execution).
From there on you have raw/full access to hardware; you can make a code to extract the bootrom itself (note: bootrom is hardcoded/read-only), study the bootrom code, and make your custom bootrom, etc.
Note that bootrom is hardcoded into the cpu, meaning that you cannot rewrite it with your custom bootrom code (correct me if I'm wrong), so 'might' always have to run the exploit code after a cold boot (unless we sign the complete custom firmware somehow).
Which is why we might have time to write exploit code into ARM9's RAM and trigger a reboot BEFORE bootrom sets the point to point to itself.That's probably right, but it also says "While the bootrom does set them up to point to itself at some point during boot, it does not do so immediately."
I think that it might not need to be a reboot to trigger the exploit, but instead it says that the bootrom doesn't immediately trigger code as soon as you power on. I may be COMPLETELY wrong, but seems to me that you can jump in code before the bootrom is able to write to it's ram or something without the need of setting up command pre-reboot.
Which is why we might have time to write exploit code into ARM9's RAM and trigger a reboot BEFORE bootrom sets the point to point to itself.