Hacking [WIP] open source Kernel access on 3DS

[-LuCas-]

try installing the latest ninjhax at http://smealum.net/ninjhax/remember to uninstall the old version by deleting the save files from your game

I'm using the starter.zip downloaded about an hour ago

 

[Stoned]

I'm using the starter.zip downloaded about an hour ago

Yes
Delete Saved Data: On the main menu, press [L]+[R]+X+Y and you'll be prompted to delete the saved data.

And Than Scan This Qr Code v1.1 for 4.5.0-8E

http://picload.org/view/cwillww/qr_code.png.html

 

[Xenon Hacks]

Yes
Delete Saved Data: On the main menu, press [L]+[R]+X+Y and you'll be prompted to delete the saved data.

And Than Scan This Qr Code v1.1 for 4.5.0-8E

http://picload.org/view/cwillww/qr_code.png.html

let me fix that for you

 

[Apache Thunder]

Ok I really hope someone can patch out VerifyRsaSha256 with this at some point. Looks like my friend code from my bricked 3DS (which I sold to someone and has since been unbricked) is derived from the movable.sed. Because of this I would have to modify part of the KeyY string stored inside the file to allow it to work on my current console. But doing so breaks the file signature (since this file unfortunately must be signed) and any attempt to modify it will brick emunand.

So much for my "manual" system transfer. I would have liked to restore my original SD content, but my FC was the main motivation for this. But even that is out of my reach right now. The "data" folder in the NAND FAT16 partition is encrypted using a key found inside the movable.sed FYI.

 

[motezazer]

Ok I really hope someone can patch out VerifyRsaSha256 with this at some point. Looks like my friend code from my bricked 3DS (which I sold to someone and has since been unbricked) is derived from the movable.sed. Because of this I would have to modify part of the KeyY string stored inside the file to allow it to work on my current console. But doing so breaks the file signature (since this file unfortunately must be signed) and any attempt to modify it will brick emunand.

So much for my "manual" system transfer. I would have liked to restore my original SD content, but my FC was the main motivation for this. But even that is out of my reach right now. The "data" folder in the NAND FAT16 partition is encrypted using a key found inside the movable.sed FYI.

No, Friend Code is derived from a FriendCodeSeed which is initialized by bootrom and stored in ARM9 memory.
So you'll need to patch the FriendCodeSeed with firmlaunchhax.

EDIT : And no, data under "data" folder isn't encrypted with a key from movable.sed, it's only authenticated

 

[Apache Thunder]

Yeah I've been trying to pin down where the FC is stored. I had thought at one point it was the LocalFriendCodeSeed_B file in the rw directory. But copying over the file untouched from my other 3DS dump doesn't change it. (doesn't brick it either. Boots up emunand fine. But FC doesn't change)

I still believe it's the movable.sed file. Because where else would it be? Emunand is already known to be able to have it's own friend code. I looked at the LocalFriendCodeSeed_B file in an older emunand image that had a different friend code and it appears identical. The only change I see is the movable.sed file. Unless the friend code is stored in the firm0 partition?

If it's in the firm0 partition, I can use rxTools to inject the dumped file from my bricked 3DS dump. But the dump I had him decrypt for me is 9.2. So using a 9.2 firm0 partition on a 9.5 emunand might cause an issue. (but they are pretty close together and don't change encryption schemes so I don't foresee a problem).

If the FC was initialized by Bootrom and emunand firm0 partition can't change it (because it would already have been initialized by bootrom from sysnand's firm0 partition), then explain to me how my emunand has a different friend code then my sysnand right now.

EDIT:

Injected the firm0/firm1 partitions from my 9.2 dump from the other 3DS and emunand still boots. But my FC remains unchanged. It's not stored there. What you're saying doesn't pan out. Being able to modify the movable.sed and also copying over the LocalFriendCode_B file should change the FC. Not sure why the g. Because this is what would happen in a system transfer. Emunand is also able to have different FC from sysnand. So it's not an issue involving the bootrom. Because "FriendCodeSeed" that bootrom reads can be transferred during a system transfer. So something on the NAND image has to store this information. The only places that could be is firm0/firm1 partition. TWL_FIRM (but lol why the ***K would it be there? ), or the CTR_NAND partitions. There's also the AGB_FIRM and the TWL photo partition. But I can rule those out as well because FC being in those partitions doesn't make sense.

Firm0/Firm1 contain the Arm11/Arm9 binaries. Don't appear to contain any unique console data because if it did, my FC would change or would at least see my current movable.sed/data folder combination get invalidated when I injected one from a different console. But that's not what happens. In fact nothing happens aside from being able to have a 9.2 firm partition on a 9.5 nand image.

The pages on 3DBrew about the movable.sed/LocalFriendCodeSeed_B files mention the friend code get command you mentioned also happens to retreive. But I would assume bootrom access movable.sed during start-up to initialize the friend code seed.

The keyY string in the movable.sed is "hashed" with SHA256 according to 3DBrew. Perhaps this means I can't simply change just part of the string. I was to assume it contained a separate key for the SD/nand data folder authentication and the other was used for friend code seed (and perhaps the contents of the dbs folder? The site also mentions that uses something separate from data folder authentication)

This crap is confusing.

Simply copying the entire partition over doesn't work. (same brick issue. So the movable.sed has to be altered by the system in some way to let the data work on the new console. That's the roadblock I'm at right now.

 

[motezazer]

FriendCodeSeed is initialized by bootrom. Perhaps the seed is xored or whatever with movable.sed keyY to form the actual code.
An hint : only half of movable.sed key is signed !

 

[Apache Thunder]

Yeah 3D brew suggested that the KeyY section and beyond wasn't signed. Or at least how the descryption of the RSA signature section of the file on 3DBrew words things on what data range the signature applies to.

So if it it's hashed/xored based on the current console, it's not something I can change by hand in a hex-editor it seems and I can't just copy the file over unmodified. I get the same result. (bricked emunand).

I do recall that deleting movable.sed and contents of data folder in that image from the bricked 3DS and use that as my emunand for my 3DS XL does allow it to boot. So I definitely know it has to be the movable.sed that's preventing me from booting it with my old SD/data/friend code data.

My bet is if someone can reverse engineer what the system transfer module actually does during the system transfer so we can figure out what happens to correctly alter the movable.sed file when it's copied over to the new console. If that can be resolved, we can restore content from an old image/bricked console.

At the moment, even if I had physical access to the old 3DS which is no longer bricked, I probably wouldn't be able to system transfer it now because I've already caused Nintendo to manually transfer my NNID to my 3DS XL.

Perhaps if I delete the save game data in the sysdata folder on NAND for the NNID module which could in theory manually unlink NNID from the image without destroying the the rest of the information like a system format typically does. But the process to do that is kinda complicated and would be a bit too much to ask for the guy I sold the 3DS to. Besides I would either have to buy it back from him or send my XL to him to have him do it. But I have no plans to really do it that way.


I do plan on sending the XL to him to have the NAND mod repaired as it was partially DOA on arrival. But I'm pretty much done trying to restore my FC data at this point.

 

[motezazer]

HALF of KeyY section isn't signed. The other half is signed.
And movable.sed KeyY is used for computing AES-MAC for NAND extdata. So you'll need to recreate the new AES-MAC for all your NAND extdata.

 

[Apache Thunder]

The issue is I have no clue which half is the one that would be signed then. And I can't program, so I would have no way of "recreating" the new AES-MAC...whatever the ***k that is.

 

[173210]

Freezing at "executing ARM11 kernel code" means it successed!
It call ARM9 under ARM11 kernel code, and ARM9 enters endless loop.
Well, so we got it!

 

[motezazer]

Freezing at "executing ARM11 kernel code" means it successed!
It call ARM9 under ARM11 kernel code, and ARM9 enters endless loop.
Well, so we got it!

Now we need an explicit winning message.
Because it could also mean that memchunkhax failed...

 

[173210]

But Alpha 5 somtimes crashed at the same point. I'll make a better proof-of-concept.

 

[AlbertoSONIC]

Freezing at "executing ARM11 kernel code" means it successed!
It call ARM9 under ARM11 kernel code, and ARM9 enters endless loop.
Well, so we got it!

That's good! If you need someone to write the GUI, i'm here!

 

[williamcesar2]

get this guy onboard /\

 

[Cindakil]

Freezing at "executing ARM11 kernel code" means it successed!
It call ARM9 under ARM11 kernel code, and ARM9 enters endless loop.
Well, so we got it!

Thay sounds great!!!!

What will be the nexts steps?

 

[motezazer]

SD access from ARM9, I think.

 

[SaagiBols]

I think Oska is bothering ''KARL's users'' it's pathetic !!! Look at KARL thread !

nope:} its more like karl is hostile towards OSKA, talking about it like its useless garbage that will never achieve anything, and sh*t...

 

[reprep]

I would like to see both KARL and OSKA in action. No need to compare them or blame one another. I am leaning a bit towards OSKA though as for the only reason that it is Open Source.

 

[173210]

Thay sounds great!!!!

What will be the nexts steps?

ARM9 has VRAM access. I'll add a function to show something on screen.