Gateway already had EmuNAND work on New3DS.so finally n3ds got nand emulation?
Gateway already had EmuNAND work on New3DS.so finally n3ds got nand emulation?
Err what? What does 9.6+ emunand on n3DS have to do with MSET?. There's a very obvious reason why 9.6 emunand for n3DS uses new encryption keys for arm9 binary. You have to find an exploit in arm9 (and presumably in arm11 too) to retrieve them. That or perhaps a hardware based ram dumper. But there isn't many with the skills or financial fortitude to try that.
MSET entry point is a separate issue from 9.6+ emunand on n3DS.
so finally n3ds got nand emulation? so how do you get a cia manager installed on emunand?
ninjhax -> FBI -> install FBI CIA on sysnand -> create emunand with FBI??
or old way on injecting FBI on H&S by XOR padding the emunand so wimimage can be used and FBI can be injected on the H&S??
there's no need for keys if you can just let the n3ds arm9 loader run, then dump the decrypted RAM - all from software, no hw trickery required. there's public code
actually I never own a n3ds so I was just kind of curious, never new gateway supported emunand on n3dsGateway already had EmuNAND work on New3DS.
that makes clears it up!, thanks!Install FBI/BBM/DM to Sysnand using Pasta. Format emunand will bring all those cia installers with. Load ReiNAND to enter emuNAND and profit.
One problem with that. Arm9 is where the keys live. Arm9 ram is not accessible to anything on arm11. Aka, you can't dump decrypted arm9 ram using exploited games or exploited system menu. You have to exploit Arm9 itself. So no it won't work like that. You either have to attack the hardware, or find an exploit on 9.6+ arm9 (and by proxy arm11 too)
Not exactly "free" either. You still need a Cubic Ninja game.actually I never own a n3ds so I was just kind of curious, never new gateway supported emunand on n3ds
maybe I worded it wrongly, I probably meant for free solution like cfw
as i said, there's public code to do just that. you pwn arm9, you load a 9.6+ fw from sd, map it into RAM, let arm9 loader run and then return to your custom arm9 code just before the ninty firmware loads in order to dump/modify RAM.
How to not keep up with the scene, doing no research and telling opinion as facts: the post: the experience: /b/ on GBAtemp: on Iceas i said, there's public code to do just that. you pwn arm9, you load a 9.6+ fw from sd, map it into RAM, let arm9 loader run and then return to your custom arm9 code just before the ninty firmware loads in order to dump/modify RAM.
I explained this earlier.as i said, there's public code to do just that. you pwn arm9, you load a 9.6+ fw from sd, map it into RAM, let arm9 loader run and then return to your custom arm9 code just before the ninty firmware loads in order to dump/modify RAM.
We don't know the new keys. So you can't tell the bootloader the correct keys to load the new arm9.
So you're just wasting your time. The only solution is to attack the hardware or find an exploit for new arm9 to gain the possibility of dumping the keys.
Remind me how I'm going to decrypt the arm9 kernel if the key to do that is completely different as of 9.6, based on a part of memory completely disabled after the first boot, and also wiped as of 9.6. It's like trying to decrypt 7.x games on 4.5 without the key. You either have to boot 9.6 to have the keys initialized (and an ARM9 exploit to use them) or the key itself. Neither are likely.where's your creativity? you already have arm9 code execution, you can modify the arm9 loader to your likings and you know what the decrypted arm9 code looks like (more or less).
Remind me how I'm going to decrypt the arm9 kernel if the key to do that is completely different as of 9.6, based on a part of memory completely disabled after the first boot, and also wiped as of 9.6.
The problem with your idea of an attack vector is you completely disregard the idea that some keys are only initialized once at startup from sources we cannot access. You can't redo something designed to run once, unless something stupid happens like the lack of clearing keyslot 0x11.you seem to be questioning my understanding of the issue while i'm questioning your attack vector.
The problem with your idea of an attack vector is you completely disregard the idea that some keys are only initialized once at startup from sources we cannot access. You can't redo something designed to run once, unless something stupid happens like the lack of clearing keyslot 0x11.
Orz, you two. Happy "discussion". I know that you really like it to happen, but what you told is just "funny" for me. Sorry if i assult you.you're making assumptions about what you think my idea of an attack vector is
It is said that 0x11 key leaked, but i highly doubt that. Any proof for proving it fake or real, heard?The problem with your idea of an attack vector is you completely disregard the idea that some keys are only initialized once at startup from sources we cannot access. You can't redo something designed to run once, unless something stupid happens like the lack of clearing keyslot 0x11.
search google for ryanrocks462 twitterOrz, you two. Happy "discussion". I know that you really like it to happen, but what you told is just "funny" for me. Sorry if i assult you.
It is said that 0x11 key leaked, but i highly doubt that. Any proof for proving it fake or real, heard?