Panda support? about decrypt9wip HOT 39 CLOSED

panda = devkit AFAIK
different keys, same hardware

from decrypt9wip.

The three decrypt options: shallow only decrypts the titlekey encryption and leaves NCCH crypto intact, deep decrypts everything and cxi only decrypts the first content. The last one, cxi is required because team GW is too lazy to patch anything but the first content signature, and a fully decrypted CIA is not installable via GW.

The encryptor processes only NCCH and does not apply titlekey crypto. Applying titlekey crypto does not make sense in this context, cause we can't fix the sigs at this point anymore anyways, and having it or not having it makes no difference.

Also, there should be no need to reencrypt for retail - just install the decryoted one. Encryption is required only for (system) titles to be installed to NAND.

The 'power button' issue can't have to do with the crypto, must be separate from it. As long as you got no errors, the hashes are verified after the decryption, and they verified fine.

I'll see about making this more convenient (the partially failed initialization does not make much sense in the context of devkits).

I'll close this now, but feel free to reopen or open a new issue once a N3DS type devkit is available.

from decrypt9wip.

I guess I need more info. Is there a chance you can provide me with the D9 logfile of a Panda unit and additional info?

Also, there is one thing you could try - provide it with the slot0x25keyX.bin, slot0x18keyX.bin, slot0x1BkeyX.bin, slot0x05keyY.bin files (or an aeskeydb.bin that contains all the data).

And, more info from me... if the checks for slots 0x25 / 0x18 / 0x1B fail, you only get a partial fail in the initialization, meaning you can still continue. If that check fails, that means you can't decrypt NCCHs with 7x / Secure3 / Secure4 crypto. So, that's not the problem here. Panda units may have a different crypto in the NAND, too, but it should be easy to work around that, given I have more information.

from decrypt9wip.

Well like i said, i've done 7.x crypto before with older versions of D9 on panda. keyscrambler and all that is the same. The only difference is the keys, and I can't obtain the 7.x key with what i have. But in any case, im running 7.1.1 sdk on my panda, so i have the key already set. and heres whats in the log
http://pastebin.com/wQ4ZY9Hf

from decrypt9wip.

Okay... I need to try and understand this. I see this is a O3DS unit (are there N3DS Panda units?). Are you using the most recent build? And, what is the entrypoint (I see it is not A9LH). Thing is, if keys 0x25 / 0x18 / 0x1B are not recognized as already set up or 'manually' set up, they won't work correcty, at least not for decrypting retail stuff.

There is a flag in the NCCH header (I can provide you with more info) that needs to be set so that stuff is decrypted using the system fixed key, but that does not work in conjunction with 7x crypto.

Is what you're saying that panda units use different keys for slots 0x25 / 0x18 / 0x1B? In that case I wonder how there can be nothing in the NCCH headers to show us that this is the case (ie that NCCH usingh different keys).

from decrypt9wip.

Okay, I guess I finally understand the problem. Panda units do actually use different keys (for 0x2C / 0x25, others are out of question), right? I can add in a simple define so you can force the key detection to work regardless, I don't want to enable this for everyone.

from decrypt9wip.

Well I have o3ds panda, yea. And N3DS panda exists.. Panda for all models exist. They are basically the closest thing to retail. I was easily able to get mset working on mine, so i use cakehax. Just about everything is similar to retail except the keys are different, and some titles are slightly different. Thats why i suggested maybe detecting both sets of keys that bootrom sets (assuming the common theory is correct in that bootrom has both dev and retail keys). Its up to you what to do, lol.

from decrypt9wip.

Considering it now. Maybe I'll also do a clean solution.

Can you provide me with this data for the keys?
https://github.com/d0k3/Decrypt9WIP/blob/master/source/decryptor/keys.c#L167-L178
(key SHA-256s)

https://github.com/d0k3/Decrypt9WIP/blob/master/source/decryptor/keys.c#L274-L276
(key XORpads, keyY = CTR = 0)

You may not be able to get that data for keys 0x18 / 0x1B, unsure.

from decrypt9wip.

xorpads will be easy, Sha256, not so much, lol
i would need panda n3ds decrypted nand keys in order to recover 7.x key

from decrypt9wip.

Fixing this would be nice. :)

from decrypt9wip.

Okay, sorry, I lost track of this. Can you provide the XORpads for keyX 0x25 / 0x18 / 0x1B, and in addition, 0x2C? 0x18 shouldn't work on O3DS, though, and 0x1B should be pretty much impossible, unless I am missing something. What about keyY 0x05 (again, N3DS thing), is that identical with regular units (helps if you know)? Also, can you think of any way to detect a Panda unit from ARM9? If not, I'd just use the 0x2C XORpad for this, but that would be somewhat inconvenient.

from decrypt9wip.

Well, 0x18 and 0x1B are unobtainable from O3DS. I'm not able to give xorpads yet, as my panda hasn't arrived yet. And one way to check retail vs. dev is the value in UNITINFO. If we can find out how ARM9 reads that.. I know it does because this: https://www.3dbrew.org/wiki/Configuration_Memory#0x1FF80015

from decrypt9wip.

Okay, good. Then I'll at least see about some easy way for you to override this. Will take some time, though.

from decrypt9wip.

Alright. Thanks!

from decrypt9wip.

Dirty fix, in the meantime:
https://github.com/d0k3/Decrypt9WIP/blob/master/source/decryptor/keys.c#L271

Change this to always return 0. Will break A9LH support. I'll come up with a proper fix later.

from decrypt9wip.

Okay, take a look at this commit: 23fb80a

In short, only make that little change in 'common.h' and you're good to go. This is only a little better than the dirty fix I suggested above, but it is our best bet until we have the XORpads.

XORpads are not easy to do. They are created for slots 0x25 / 0x18 / 0x1B by setting ctr & keyY to all zero, and I only need 16 bytes. The 0x1B XORpad can only done on units >= 9.6.

Maybe there is no way to get this properly fixed until someone reverse engineers those keys for Panda units, too.

from decrypt9wip.

Why do we need to have the keys exactly? the sha256 of the key? why do that when you can verify keys by encrypting zeros?

from decrypt9wip.

Yup, as I said, XORpads are alright. With Panda O3DS units, we just have no way of getting the XORpads for 0x18 / 0x1B. 0x1B is only available starting 9.6, so that will be a special problem.

Reverse engineering the keys would be useful to be able to decrypt anything on anything, but we will not be able to reverse engineer 0x2C anyways, so that may be out of question anyways.

from decrypt9wip.

Okay, here's that special NCCHinfo.bin file:
https://up1.ca/#8u5j1nPFS3gxgWml52Lhdg

Use this on a Panda unit, to generate the XORpads required for somewhat proper Panda unit support. Of the resulting 4 files, I only need the first 16 byte of each, but you can also give me the full thing. And, if you generate these XORpads and provide them, let me know the type of your Panda unit (O3DS/N3DS).

from decrypt9wip.

Ran on my o3ds(CTR) panda. with firmware equivalent to about 7.1 retail. So 0x2C and 0x25 should be fine, not entirely sure about the other two, but..

0x2C: 29 B5 5D 9F 61 AC D2 28 22 23 FB 57 DD 50 8A F5
0x25: BC 83 7C C9 99 C8 80 9E 8A DE 4A FA AA 72 08 28
0x18: D8 45 81 96 BB 53 DB 6E FB 7D FD 74 37 B6 0A 38
0x1B: D8 45 81 96 BB 53 DB 6E FB 7D FD 74 37 B6 0A 38

actually, yea looking at those last two, they are most likely cleared lol.

from decrypt9wip.

Thanks, this will already help, and we can look after the last two ones later! Will do a clean implementation, then get back.

from decrypt9wip.

Don<t understand the diff between panda hardware and a O3ds.... What is it?

from decrypt9wip.

Should be properly implemented (no workaround required anymore) in cc838fc

Also, Panda units are now properly recognized - see first line in 'System Info'. @Reisyukaku & @fox8091 - could you test this? Test build available from here:
https://up1.ca/#4JxHZVpPTN0y7DVx4wYkOA

Note: Initialization is still 'partially failed', because we're missing the 0x18 and 0x1B slots. These will be added once we have them (if they ever get relevant).

from decrypt9wip.

It works on my newer CXIs =)
just fails on CIAs.. "Verification failed" on verifying decrypted content.
iirc, i've decrypted dev CIAs in the past but idk.

from decrypt9wip.

I didn't change anything in there... Maybe common keys are different on Panda units, too? That would be a possible explanation. In that case it has never worked, tough, and for it to work, common keys have to be REd

from decrypt9wip.

well i know both common keys for system and 'eshop' for dev.. its the same ones in retail proc9 i think.. they are common keyYs i think, but they can be used to decrypt and dev CIA.. its odd.

from decrypt9wip.

Are they identical with those?
https://github.com/d0k3/Decrypt9WIP/blob/master/source/decryptor/titlekey.c#L11-L18

Not matching common keys are the only reason I can think of right now for CIAs not decrypting. A log of a failed decrypt can help limit the possible causes, too.

from decrypt9wip.

Nope, these are the keys i use
https://github.com/profi200/Project_CTR/blob/master/makerom/pki/dev.h#L23-L24

from decrypt9wip.

Okay, that's the issue then. Proper support coming up, and I'll leave this open until it works.

from decrypt9wip.

Okay... could you test this build?
https://up1.ca/#pL1qHX8wtmcZ48leZgvpuQ
(or compile from source)

CIA decryption should now be fixed.

from decrypt9wip.

hmm .. doesnt seem to be working on Nfp/Noft stuff.

from decrypt9wip.

Tbh, I had to use Google, NFP -> Amiibo stuff? And, NOFT?

Anyways, as I'm using dev unit commonkeys as a swap in replacement, it is possible that some stuff that worked before now no more does. Can you provide me with a log ('Decrypt9.log') of some failed attempts?

Also... is there something else that can decrypt those CIAs?

from decrypt9wip.

http://pastebin.com/cUDk1SXU

Im not sure how you do the common key decryption, but fwiw, i use ctrtool to do it and it works. Might be clues there idk :\

from decrypt9wip.

Okay, problem was a mixup... for retail units, we have the common keyY, for Panda units we have the normalKeys. Should be fixed now (not committed yet). Can you try this test build?
https://up1.ca/#X_ROnuAVGEINxcROrOXfvQ

from decrypt9wip.

Ah yea that makes sense. Also now it fails at recalculating TMD hashes for all.. making progress though :p

from decrypt9wip.

Blind coding is hard... -___-

Anyways, recalculating TMD hashes can't fail, the actual error is earlier (f.e. in NCCH decryption) (and yes, I need to rework the error messages for that).

If you extract the contents from these CIAs with ctrtool, then use D9WIP to decrypt, it works, right? Can you provide me with a log of the failed CIA decryption, so that I see where the actual error happens?

from decrypt9wip.

Hah, yea. Remote testing is always fun :p
Anyways, yea CXIs decrypt fine.
http://pastebin.com/HfC7GjhR

from decrypt9wip.

Okay, something went wrong with the last test build. The issue in that log is still failed CIA Titlekey decryption (= not NCCH decryption), which should have been already fixed. I did now test on my retail N3DS (devkit titlekey crypto can be done on retail units, too) with some devsdk titles, and everything looks fine.

You can either compile from source (master), or use this testbuild to try:
https://up1.ca/#y-Bdkj77Hu-MoR3XE-np_g

If something should go wrong again, I have now at least improved the CIA decryptor error messages.

from decrypt9wip.

Ayy, no errors, lol. So it seems to work. Only thing is i tried to decrypt on dev and encrypt on retail (im still not sure the difference between the multiple decryptions and why theres only one encrypt) but even though they install on retail now, i get that 'power button' error.. I dont think that has to do with the crypto tho.. probably an exheader thing or something. not sure.

from decrypt9wip.