So why exactly wouldn't SSSpwn work with "backups"?

twilight princess save hack was also just an exploit in user landmode, that didn't stop others from thinking bigger. sure this would not be enough by itself, but might it be enough to see further? what hardware can be accessed what's limited? for as i remember correct for the wii it was started with twilight princess exploit, homebrew channel, (additional dvd options, removed later by Nintendo ,) installed patched drivers. then restarted the whole system... this was still for as far as i know the same exploit...

 

to get back to the op's question, what exactly is stopping us from using this exploit as a launching point to use the recently done CFW here:

http://gbatemp.net/threads/4-x-only-cia-cfw-complete-guide.373532/

of course, this would be limited to people with 4.x firmwares, but what is stopping us from using that payload (or a variant based on it) to setup a CFW? shouldn't the ability to launch homebrew be sufficient to begin executing the ROP chain? is there something about that which makes the gateway (or similar card) necessary as opposed to using ssspwn as our launching point?

 

in theory it's not impossible to use this exploit as an entry point to kernel privilege ,and with the right hands! everything is possible .

 

recently he also said that something along the line that game isnt really the big news worthy thing behind the exploit or so.

EDIT:

 

For my opinion is better try a emunand via ninjaxx. I have another question. .. is possible use another game? ?? Like Wii? ?

 

There's two separate topics at hand, and more than two conversations in this thread, so here's my take:

- Running cubic, and Ninjhax, using a flashcart/backups.
Assuming that the flashcart does not actively (e.g., Gateway method) exploit a vulnerability on the system software, and works by passively emulating the CARD interface (like an ODDE, I believe current-gen flashcarts do this now) to provide a 1:1 image of the selected ROM to the system, and that it can run on your current firmware, it should theoretically be capable of bootstrapping Ninjhax.
This configuration is, however, NOT SUPPORTED. The configurations used by flashcarts to load code is not as predictable and constant as a factory-pressed copy of Cubic Ninja.
"Unpredictable" is not one of those words you want to hear when you have bits of code jumping all over RAM in lock-step, in order to get a file off the SD card and jump to its code. You may crash, burn and lose all your Streetpass puzzle pieces and be very grumpy, and smealum sure doesn't want to hear people complaining about how they wasted money on a piracy device in order to illegally run a game on their system "for legitimate purposes", just to find that their 3DS had become some Negative Space Wedgie and turned entirely to antimatter, eviscerating a thirty-mile radius of its first three states of matter.
Or perhaps he does. I don't judge.
Was that too harsh? Your 3DS will likely crash, and refuse to run anything properly, let alone Ninjhax, and you will not be helped if it's because you didn't follow instructions and use the proper materials.
At that point, all you can do is hope SAFE_MODE_FIRM is still accessible, and do the requisite three-finger salute to get into forced-software-update mode.
Furthermore, smealum et. al, could decide to implement anti-piracy which checks timings of CARD accesses, looks for signatures of flashcart use, etc., and refuses to bootstrap the launcher file on the SD card once exploited. It depends on how far, and how actively, they're willing to take the anti-piracy commitment.

- Bootstrapping and running 3DS game code in arm11 mode through homebrew.
I'm not going to outright say that it's not possible for all games.
However, I can't reasonably see piracy being a feasible goal with the current hax, until someone breaks into the kernel and overrides the permissions granted to Cubic Ninja.
We're at the stage in development, where a crafty fellow with a pair of Twiizers would easily blow the 3DS wide open, but until then, we're loading rudimentary emulators and games of Tetris and PONG (or Minecraft in this case) through Twilight Princess (or Cubic Ninja, in this case).

As far as I can tell, there is little to no active anti-piracy method in the current hax, so as to interfere as little as possible with true ARM11 development on 3DS and New3DS.
The entire premise of anti-piracy in the current loader/bootstrap method is based on the fact that it's not capable of doing so directly.

Even if you took the bootable executable and data regions from the NCCH of a valid 3DS application/game binary, and transformed it into a .3dsx executable (which is trivial, but not exactly useful), how would it access any of its game data? It would be looking over the CARD interface.
And what's on the CARD? Cubic Ninja.
The only game you can (possibly successfully) bootstrap in this manner, is Cubic Ninja itself.

"But siro!" you may ask. "How do Wii ISO loaders do it? Couldn't we do the same thing?"
Wii's system, and security architecture is vastly different, and so are its hacks and piracy. As simple as installing Homebrew Channel, a patched IOS and a USB loader may seem from the outside in, the setup is actually quite complex. Even excusing that it completely breaks the chain-of-trust entitled by the Wii's secure coprocessor (MCP, ARM, IOS or "Starlet"), the various loaders don't simply chain to the DOL image in the disc's bootsector.
The ability to load pirated games on the Wii depends on intercepting and emulating system calls and redirecting them to different storage areas.
It was very naive at first, simply patching disc reads to a fixed region on an SD card. Very soon after, a rudimentary FAT driver was written to allow <2GB SD cards to load .iso files. The rest is history, and with the release of IOS58's EHCI/UHCI USB2.0 modules, USB loading from NTFS filesystems became feasible, and soon, the recommended method of piracy.
tl;dr: It is a lot easier on the Wii, because, since the chain-of-trust is broken, system calls in the IOS running on MCP/Starlet can be rewritten with custom IOS calls.

On the 3DS, we don't have this freedom, and we're starting at square zero.
The methods required to properly run games on the homebrew launcher, involve modifying the game code and changing every file access call before it's run. This can be very unpredictable (we all know how much I love that word) and worse, unstable. It'd be very difficult to know that every context to change a file access call is appropriate to intercept and modify on the loaded executable.
You could parse and modify the executable file, statically, either ahead-of-time or on load. This is the most feasible method of redirecting the filesystem access, but it's not exactly transparent to the game program or the user.
You could also theoretically emulate the code on-board, running all code through a simple switch which falls through if the operation does not correspond to a CARD access, and JIT-modify the requisite filesystem calls as the program executes, but this can be painfully slow (especially with the limited memory of the 3DS).
You can also parse all the code through an outboard emulator, and rewrite the bits related to CARD access... but that requires at least a rudimentary amount of knowledge in compiler theory and virtual machines.

Aside from this, we have to wait until we have access to the kernel, so that we can intercept said calls from the API cleanly, without modifying the game code or emulating the calls.

Furthermore, it is not possible for games which require additional permissions on top of those granted to Cubic Ninja by the system.
Those games will halt with an error, crash, or encounter otherwise unpredictable (there's that word again...) behavior which could certainly cause damage.

tl;dr: The way to go about doing this, would be very difficult, and involve patching read/write accesses to save data and game files, and emulation or proper handling of capabilities (like DLC, or internet access) which Cubic Ninja does not take permission for.

Also, if a game makes use of modules and SDK features which are newer than, or not used in, Cubic Ninja, they may not work properly.

Verdict:
Running Cubic Ninja on a flashcart to load Ninjhax? Possible, but not supported, and very specific.
Your card needs to pass through a 1:1 representation of the game image without using exploits on the system to bypass protections related to loading games. It should appear as transparently to the system as possible, as a Cubic Ninja game cartridge, with no extra bells and whistles (same savedata space, same ROM size without padding or null blocks, and so on).
I'm not sure any current flashcart qualifies, but first-gen carts (MT-Card, Gateway) certainly do not.

Running game backups through Ninjhax? Not yet possible, and certainly not worth the effort. Unstable, unpredictable game-patching techniques would be required, which will only work with very few games, and break most other games.
It would only be worth pursuing once a good vulnerability is discovered in the permissions system, system menu, or NATIVE_FIRM/kernel.

 

I'm running Ninjhax through Gateway with no issues. Some people are having issues?

 

I'm not saying it's not possible, just that it's not supported, and for most people, not the preferred method to run hax and homebrew from square one.
If you have a Gateway card, chances are that there will be better and easier ways to load Ninjhax-based homebrew (3dsx format) that don't require pirating a copy of Cubic Ninja.
Like for instance, a version of the hbmenu transformed to a .3ds CCI-NCCH container file, something that can easily be done, and distributed (since it doesn't require any copyrighted code).

 

The only issue is GW doesn't have access to the stuff required for audio (IIRC). Also, I own a copy of cubic ninja which is being used on my brother's 3ds. Making a rip of it and throwing it on my Gateway isn't too illegal, we don't run the game at the same time.

 

The info on ninjhax website is outdated. You can't run any unsigned code on Gateway's red cart, true. But since GW Omega v2.6 you can run anything when you pack it into a CIA and install it on the emunand.

 

This is also the case. However, I'm not sure I want to repack homebrew every build ^^

 

That should be the creator's responsibility. Really it's not really hard work for them to add a line to a batch file.

 

Calling the current emulators rudimentary is probably a bit insulting tbh. They may be unfinished, but what they do is very impressive and a shitload of work has gone into them.

 

This process seems little odd, If a similure server was using same process but a game maybe .CIA are what they use in format..., you're 3ds firmware version , scan QR code , then the download should be done in the same way , Filter-ed through you're 3ds Key encryption code on the SD and system , it should appear as normal as present .
Just a though't , with you're better ideas ?