Since we have the DSi Common Key, shouldn't we be able to in theory install custom code on our 3DS's NAND assuming the DSi is decrypted that far?? I'm pretty sure it would require a DSi exploit to do, but still, would it even be possible??
I'm not entirely sure why you're drawing the connection between the DSi and the 3DS when there really isn't any evidence that the encryption used is the same. To the contrary, according to 3dsbrew, most of the mechanisms are completely different in comparison. Moreover, even if you HAD DSi-level access, the application would still run in the sandboxed mode, so how exactly is that better than the current DS-Mode?
We *can* write into a *very small* partition of the 3DS's NAND, even in the sandbox, however that part of it just holds DS-compatible user information (presumably, as accessing these freeze the console when accessed after that part of the memory has been altered). The restriction comes from above and no "Mode" other than "3DS Mode" is going to help here.
DSi common key doesn't allow you to write to NAND on a DSi, let alone the DSi portion of NAND on the 3DS, which is sandboxed anyway. As WiiBricker pointed out, literally all it does is allow you to decrypt content off NUS. He was less correct in implying that it would be more use with an exploit available. That's not really true. With an exploit, you load unsigned, unencrypted code. So you don't need the key for that. As for writing to NAND, pretty sure Nintendo will have learnt their lesson from the Wii and require everything being written to NAND to be signed (the lesson learned being that checks would be more thorough and, y'know, working) as well as encrypted, so again the common key on it's own isn't enough to do that, even with an exploit.
What the common key could potentially be helpful for would be helping to create an exploit by allowing investigation of decrypted code etc.
This is all in reference to DSi. On 3DS, the DSi section is of course sandboxed, so even if you were to achieve all this is wouldn't really be too useful.
Actually it has all to do with the topic, because he appears mislead that this is talking about currentl flash carts and exploits they're not using (as the DSTwo is using the standard send fake headers to boot technique while the iEvo is the only one using any DSi-mode exploit), Sifjar was pointing out this thread was more for softmodding the systems, not editing flash carts.