Godmode9: Decrypting N3DS firm on O3DS

[Ammako]

I need to decrypt a N3DS firm, but I don't own a N3DS. I figured that I should be able to decrypt just fine on O3DS, as long as I had aeskeydb.bin in support folder, however that doesn't seem to be the case.

Is this something that I'm doing wrong, or is something actually broken? This is a clean encrypted CIA from the CDN.

[TurdPooCharger]

11.9.0-42U(Full)_n3DS.zip
MD5: acad95441a72be396cc8b0464257ee07

0004013820000002.cia
CRC32: 0E2D4DC7

[Ammako]

My cia is fine, and I don't know why I should be concerned about the md5 of a 11.9 firmware pack.

[TurdPooCharger]

[Ammako]

Just because it works for you doesn't really help to solve the problem. But this does confirm that it's supposed to work, but something's causing it not to.

[TurdPooCharger]

Find that package and try decrypting on that specific copy of the n3DS native .firm.

The o2DS setup.

• GodMode9 v1.9.0
• No aeskeydb.bin in support folder nor [S:] SYSNAND VIRTUAL.
• 0004013820000002.cia → CIA checker tool → Ticket/TMD: legit/legit and Verification: passed.

[Ammako]

Ok, well this is another problem entirely. Understandably, you are thinking that the firm is decrypting properly, since gm9 is saying the decryption was successful. That is not the case however, N3DS firm has an additional layer of encryption on the arm9 which is not being decrypted here. Decrypting this requires certain N3DS-specific keys, which you are supposed to be able to provide on O3DS via support files, but this does not work.

[TurdPooCharger]

Your observation of decryption difference is absolutely correct.

Mismatching regions.

• 0xB0-CF (32 bytes. Some sort of sha-256 hash?)
• 0x69A00-69A0F (16 bytes, cmac?)
• 0x69A60-69A6F (16 bytes, cmac?)
• 0x6A200-onwards (does not look decrypted for o2DS dump version)

[TurdPooCharger]

Yup, that makes two. For the o2DS, when I put aeskeydb.bin in the support folder and try the Decrypt file (0:/gm9/out) on the image mounted .../exefs/.firm, I get the Decryption failed error.

When mounting the Copy to gm9:/out .firm, these are missing on the o2DS:

• 0004013000003000.Process9.app
• arm9dec.bin

All other contained *.app and *.bin match in hashes compared to the n3DSXL.

[d0k3]

An O3DS should be able to fully decrypt a N3DS NATIVE_FIRM. I'll need to check. Will need help testing that.

[d0k3]

Oh well, you found an old one there. That could never have worked. Try this one, I'm pretty sure this fixes it:
https://f.secretalgorithm.com/14QqON/godmode9.firm

[Ammako]

Yeah, it didn't even work in D9 either lol.

And yep, that works perfectly. Thanks!

[Ammako]

Nevermind, there is still one issue. Only the first attempt at decryption works, any subsequent decryption is incorrect. So if you needed to decrypt multiple ones, you have to power off and power back on before decrypting each next one, otherwise you don't get proper decryption for all but the first one.

[d0k3]

Looking into this (ooops).

[TurdPooCharger]

For the next test build, I'll be on standby to compare decryption outputs between my n3DSXL and o2DS.

[d0k3]

Okay, can't reproduce anything here. I need more info. Is there an error message on the second attempt? What's the difference between the correctly decrypted one and the incorrectly decrypted one? What do I have to do exactly to make it fail?

[Ammako]

No error message.

Using 11.12 firm as the example, with a CIA from 3DNUS (CRC32 22E5DD11), at minimum you can do this:

• Mount CIA;
• Decrypt .firm from exefs;
• Going over to gm9/out folder, I rename .firm to 37.firm;
• Go back into the mounted CIA (don't need to unmount or remount);
• Decrypt .firm from exefs again;
• Go back to gm9/out folder, SHA-256 for both don't match, and only the original (37.firm) is properly decrypted.

Of course, decrypting the same thing twice in a row is pointless, in my case I was decrypting a few different versions one after the other, so I ran into that issue.

If it means anything, the output is different from previous commits (different checksum), and it only fails "once", in the sense that each decryption past the first one fails in the exact same way.

In case it matters, O2DS, fb3ds 1.2, GM9 running from firm1

[d0k3]

Dammit, still can't reproduce. I'll need to know the actual differences. Can you check in HxD (or any other tool) and show me?

[Ammako]

That's weird as hell. I'll try on a few other systems, and another SD, and see if it's only on my specific ones that it breaks.

Which parts of the file do you want to see? Is the top ~0x200 bytes fine?

[d0k3]

I just need to know where the first difference happens.

[Ammako]

Is it normal for 0xB0-0xCF and 0x69A60-0x69A6F in a decrypted firm to be different depending on which 3DS I did the decryption on?

Either way, it doesn't seem to matter which unit I do the decryption on, both decrypt fine on first decryption, and then fail on subsequent ones. The results are different on each though, way more than just the 3 lines from above.

Not counting those 3 lines, this is where the first differences happen:

The data there is also different depending on which 3DS I use to decrypt, if it matters:

[Ammako]

I've also tried a different SD, the results are identical.

[TurdPooCharger]

[d0k3]

Thanks! I hope I can do something about that tomorrow. I still don't really have a clue

[Ammako]

It's very weird that I seem to be the only one for whom this happens, and that others can't reproduce it. It can't be my console either, since all 3 of mine do the same thing.

Either way, this is not very urgent, I was able to get everything I needed done despite the problem. I just figured it'd be worth bringing it up so that whatever the problem is could be figured out (and fixed, if it turns out to be a gm9 issue.)

[d0k3]

I don't have an O3DS to test, @Ammako. I just made GM9 work like it ran from an O3DS (possibly not completely, tho).

@TurdPooCharger - do these issues persist from the first attempt of decryption?

[Ammako]

If it helps, every decryption after the first happens slightly faster.

[TurdPooCharger]

@TurdPooCharger - do these issues persist from the first attempt of decryption?

[d0k3]

Can I see the borked (purple) arm9dec.bin? A screenshot of the hex view is enough (I think). What does "can not dump" mean?

[TurdPooCharger]

Can I see the borked (purple) arm9dec.bin? A screenshot of the hex view is enough (I think).

arm9dec.bin (FCC7CA92)

What does "can not dump" mean?

https://user-images.githubusercontent.com/43770697/68094016-1a22fd80-fe6a-11e9-8acf-b02ae98e591e.png

[d0k3]

Okay, guess what? Another bug hid behind the first one. How could this ever work? :^)

Anyways, I think I got it handled now, here's a test build:
https://f.secretalgorithm.com/nIHGD/godmode9.firm

[Ammako]

Decryption fails entirely with this one, actually.

[TurdPooCharger]

I'll see if there are hash differences between my n3DSXL and niece's n3DS when decrypting/dumping the .firm and its various *.app and *.bin files. Maybe there's a console unique decryption that's at play. I should see her later today to borrow the n3DS.

Advance notice in case fixing this bug takes longer than expected. Come this Thanksgiving (Thurs Nov 28th), I will no longer have the o2DS as it's being gifted to my nephew.

[TurdPooCharger]

[d0k3]

Dammit! I'll have this handled later.

[d0k3]

Okay, we'll officially resort to more brutish methods.

https://f.secretalgorithm.com/Y4SSP/godmode9.firm
This build is plastered with ShowPrompts and will tell you the reason why decryption failed. I may be able to handle it after I know your output.

Note: this will only check full FIRM decryption. If we got one handled, we'll also have the other one handled.

[Ammako]

I don't know what you've changed, but this one just... works.

[d0k3]

Ughhhhhh!!!!!!! 🤯

(this shouldn't work, it should give you an error message)

(let's wait for @TurdPooCharger's test)

[Ammako]

The output is different from before, different checksum (probably the same differences as before), but the arm9 binary is properly decrypted each time.

Just to be sure, I'll do some more thorough comparisons between now, and before. Just in case something's not decrypting properly, or something. idk.

[Ammako]

No, the only differences between this one and the properly decrypted one from before, is the same three 0x10 lines that are different.

[d0k3]

Can you give me a short reminder? Only 3 blocks of 0x10 bytes are different? Where are they located?

[Ammako]

0xB0-0xCF and 0x69A60-0x69A6F

[d0k3]

0xB0-0xCF and 0x69A60-0x69A6F

Okay, that helps a bit. Ignore 0xB0...0xCF, that's just the SHA hash of section2 (which is correct). The real change is in 0x69A60...0x69A6F (a probably wrongly decrypted keyX0x16 in the A9L header). Is this different on every attempt (= not only subsequent attempts after the first)?

[Ammako]

It's not different on every attempt, but it does change depending on which specific 3DS I use to do the decryption.

[d0k3]

Okay, just so I don't get this wrong... you say, while those bytes are different on every 3DS attempted, everything else is correctly decrypted?

[Ammako]

I'm fairly certain that is the case.

[d0k3]

Okay, here's another brutish attempt.

https://f.secretalgorithm.com/Vi3kY/godmode9.firm
This one will show you the key used for decryption. It has to be identical on each and every attempt, no matter which 3DS. It should be enough to compare the first few bytes.

[Ammako]

Okay nevermind, with that build (and I assume the previous one, since the hashes match), the output is identical on each 3DS. I hadn't actually checked with the previous build, since it seemed to have fixed the main issue.

[TurdPooCharger]

Edit - At the bottom red box section, the one on the right is New 3DS XL /GodMode9 v1.9.0.

[d0k3]

Okay. This is not solved, but it's definitely undefined behavior. We'll need to check what really happened there.

[d0k3]

Okay, I know you read about this a few times, but I think I got it nailed now.

https://f.secretalgorithm.com/koI6r/godmode9.firm
@Ammako and @TurdPooCharger - can you both try this one? And no, this wasn't undefined behaviour. Just @d0k3 f*ing up.

[Ammako]

Looks good to me.

[TurdPooCharger]

:+1:

[d0k3]

Okay, one down. Thanks, both of you. @Ammako and @TurdPooCharger !