lol
Give me a complete update err downgrade pack for 2.x or 1.0 E and I'll add it.Any plans on providing an option to generate CTR NAND xorpad on an n3DS that uses o3DS keyslot? I recall one has to use a modified version of Decrypt9 to do that. For those downgrading to 1.x/2.x for OTP dumping, having this in the same version of Decrypt9 would be more convenient.
haha Sure it would only be a small addition.
No idea. no idea why everyone is being so secretive with the whole process either, it's like trying to get blood from a stone just to get a tiny bit of info.Well I wish I could. But I have a USA console and the n3DS I'm getting will be USA as well.
I wish there was an MSET payload for OTP dumping on 1.x. Curious as to why that isn't a thing yet. MSET exploit exists on 1.0 last I checked.
Only thing i need to mess with arm9loaderhax is that damn otp lol and of course i can't downgrade because the 2.0E pack is apparently incomplete and it bricked my o3ds earlier haha Nothing but a nand restore didn't fix, but still.
Yeah i wish i downloaded all the old firmwares before nin took em off the servers, just never got around to it.Yeah. I do know that TWL underwent some major changes in 2.0. (hence why 1.0 TWL_FIRM won't boot on a 2.x or higher console). So I guess the MSET exploit behaves different enough to be more challenging to write ROP for. I don't think there is even a 2.x spider exploit that does it. Then again I haven't been able to find a USA 2.x firmware pack that includes the browser so even if there was I'd have a hard time using it.
Actually, looking through the source this looks extremely easy... Have a menu option that modifies a variable (we'll call it forceo3dskeyslot for now) then just take and starting here https://github.com/d0k3/Decrypt9WIP/blob/master/source/decryptor/nand.c#L323 in the if statement do thisAny plans on providing an option to generate CTR NAND xorpad on an n3DS using o3DS keyslot? I recall one has to use a modified version of Decrypt9 to do that. For those downgrading to 1.x/2.x for OTP dumping, having this in the same version of Decrypt9 would be more convenient.
if (GetUnitPlatform() == PLATFORM_3DS | forceo3dskeyslot == 1) {
keyslot = 0x4;
if (GetUnitPlatform() == PLATFORM_3DS){
nand_size = 758;
} else {
nand_size = 1055;
}
} else {
keyslot = 0x5;
nand_size = 1055;
}
@d0k3 not sure if this is appropriate for D9 (it is in IMO, but I'll let you decide what happens). Since arm9loaderhax has an implementation now, people might need a way to get their OTP area dumped. Since apparently the gateway browser exploit works on 2.x a user could boot D9 through the launcher.dat (after downgrading to 2.x) dump the OTP and then return to whatever firmware they want so they can use a9lh... all that said, it may not even be possible to dump the OTP using C (might need some ASM, not sure) still, I think it'd be cool to have and afaict D9 would be the first ever homebrew to implement it (I've scoured for a few days and my google-fu isn't turning anything up) and it'd make it that much more useful in general
EDIT: just got my answer: ASM isn't needed, apparently it's really really simple... My main worry was most people mentioned using Cubic Ninja (which I don't have and don't plan on getting anytime soon) so it looks like we'll be all set
Had a look, and it doesn't sound too difficult. Source code would be great, though (didnt find anything)! Is the OTP area console unique (I guess it is)? OTP dumping doesn't seem to even need decryption and if I got that right it only makes sense on 2.x and only via the GW launcher.dat. If that's the case a one trick tool would possibly make more sense than adding this to Decrypt9.
Any plans on providing an option to generate CTR NAND xorpad on an n3DS using o3DS keyslot? I recall one has to use a modified version of Decrypt9 to do that. For those downgrading to 1.x/2.x for OTP dumping, having this in the same version of Decrypt9 would be more convenient.
Oh well, I guess now enough people have asked. I'll build this into Decrypt9. OTP dumping, though, will need some more information about that and then think about it.
It's easy actually... Some people showed in the arm9loaderhax thread (you can check the link Shadowtrance pointed me to above) there was some code to dump it (one line really, aside from the menu option) and it'll be useful, it doesn't need to be decrypted, it's needed to further decrypt some things... Which is why I say it makes sense for D9. Also I was thinking maybe have the OTP menu option only appear if the system version is <3.0
I think this is everything there is to the OTP dumper (why is the size either 0x100 or 0x108, btw?). Very easy. We can't have a variable menu though. The current menu code does not allow it, and you also need to think about the themed version
.
YES! THINK OF THEMED VERSION PEOPLE!!!!I think this is everything there is to the OTP dumper (why is the size either 0x100 or 0x108, btw?). Very easy. We can't have a variable menu though. The current menu code does not allow it, and you also need to think about the themed version
Yep that's it... dazzozo showed a slightly different way on IRC, but that's the basic idea... Also, damn didn't think about a that stuff for the menuI think this is everything there is to the OTP dumper (why is the size either 0x100 or 0x108, btw?). Very easy. We can't have a variable menu though. The current menu code does not allow it, and you also need to think about the themed version
Where's my "don't like button" ??... Also, damn didn't think about a that stuff for the menu
The extra 8 bytes is twl stuff.I think this is everything there is to the OTP dumper (why is the size either 0x100 or 0x108, btw?). Very easy. We can't have a variable menu though. The current menu code does not allow it, and you also need to think about the themed version
Alright, the option to create slot 0x4 CTRNAND xorpads is now in Decrypt9WIP, but you will need to compile from source (which I assume everyone dabbling around with that dangerous stuff knows how to do).
