- 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.
