This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=14445

Jamjardavies, posted Tue Nov 17, 2020 9:53 am (60357)

---

Hi all,

So Destiny 2 just had a DLC update and they've changed the packages format and encryption. Wondering if anyone here has worked out the encryption part?

I've almost worked out the package structure fully, but unable to test without getting the encryption keys, which is where I fall down.

Any one know how to find these?

KaneTW, posted Wed Nov 18, 2020 11:57 pm (60414)

---

I've ripped the new decryption key (4A A4 72 9D E2 1A C6 EC 17 6B ED 2D 98 F9 B1 9B) and the 0x26 in the nonce generation algorithm changed to 0x35. However it still doesn't work and statically analyzing that part of the code is a pain. I suspect some of the extra data added in the new package format is used for decryption.

E: Looks like they're writing to the location the key is stored in but part of the key data is dynamic. IDA doesn't track where the control-flow comes from in that segment and I don't want to attach a debugger.

Jamjardavies, posted Tue Nov 24, 2020 10:25 am (60566)

---

Thanks for the reply.

Do you know what the location of the key changes to, and does it seem like it changes per package, or per block of data?

Might be possible to work out how they populate the decryption key from the packages.

Syscache, posted Fri Nov 27, 2020 3:51 pm (60667)

---

Did someone get it to work ?

KaneTW, posted Fri Nov 27, 2020 4:17 pm (60673)

---

I haven't. Need to set up a burner VM so I can attach a debugger.

KaneTW, posted Sat Nov 28, 2020 5:50 pm (60723)

---

Debugging was a failure (I'm not experienced enough at dynamic analysis to circumvent the anti-debugging tricks used) but I managed to extract a better PE dump. I think I might have more details in the future, let's see.

KaneTW, posted Mon Nov 30, 2020 11:28 am (60779)

---

Meh. Seemed like they used bcrypt.dll for decryption at first but it never gets called. There's a statically linked libtomcrypt but I can't set a breakpoint for above reasons, and I don't see any static reference to any of its functions (but that doesn't mean anything).

I'm sure I'm missing something; maybe I need to properly break VMProtect and just circumvent their anti-debugging shenanigans, then breakpoint on the function where they load packages.

If anyone wants to give it a try, I can send you the unpacked .exe.

Ekey, posted Mon Nov 30, 2020 11:36 am (60780)

---

Are you sure VMProtect is used?

This should help

https://github.com/can1357/NoVmp
https://github.com/can1357/vmpdump

KaneTW, posted Mon Nov 30, 2020 11:40 am (60781)

---

Fairly sure. There's a .vmp0 section, and afaik only VMProtect uses that. Not sure which version.

NoVMP didn't work, tried that earlier. Will give vmpdump a shot.

KaneTW, posted Mon Nov 30, 2020 2:45 pm (60785)

---

Fails as well. It goes on for a fair while but then an assertion fails and it crashes.

\/ PM'd

Syscache, posted Mon Nov 30, 2020 3:35 pm (60786)

---

KaneTW wrote:

Meh. Seemed like they used bcrypt.dll for decryption at first but it never gets called. There's a statically linked libtomcrypt but I can't set a breakpoint for above reasons, and I don't see any static reference to any of its functions (but that doesn't mean anything).

I'm sure I'm missing something; maybe I need to properly break VMProtect and just circumvent their anti-debugging shenanigans, then breakpoint on the function where they load packages.

If anyone wants to give it a try, I can send you the unpacked .exe.

Can you send me the .exe

KaneTW, posted Tue Dec 01, 2020 4:10 pm (60825)

---

Some progress. The decryption key changes once you log in. After you log in, it becomes D6 2A B2 C1 0C C0 1B C5 35 DB 7B 86 55 C7 DC 3B.

KaneTW, posted Tue Dec 01, 2020 4:22 pm (60826)

---

Yep, that works. Make sure to change the 0x26 in the nonce generation to 0x35 and you got it.

For future reference, let it fully connect (you'll see once procmon shows unencrypted packages being loaded) and check the location that, before connecting, shows 4A A4 72 .... It'll have the new key.

spiritovod, posted Tue Dec 01, 2020 6:09 pm (60829)

---

Is not the key the same as before? viewtopic.php?f=9&t=4823&start=40#p35963

KaneTW, posted Tue Dec 01, 2020 6:35 pm (60831)

---

Huh. Yes, it is. I think the only thing that changed then was nonce generation and they either obfuscated the key or made it something you only get via network; there were no writes to the key location in older versions.

spiritovod, posted Tue Dec 01, 2020 7:37 pm (60835)

---

What about the second key then? Original script was using two keys (depending on packages) and "xmath TMP1 "TMP1 ^ 0x26"" in "nonce" part. I just don't have the game installed at the moment, so it would be nice if you could clarify that.

KaneTW, posted Tue Dec 01, 2020 7:43 pm (60836)

---

I'm not sure if the second key is used at all anymore, but setting it to 3A 4A 5D 36 73 A6 60 58 7E 63 E6 76 E4 08 92 B5 didn't throw any errors during a whole game decode. (That's from the code path if the alt key flag is set, where it chooses between the D6... key and this one)

KaneTW, posted Tue Dec 01, 2020 9:04 pm (60840)

---

Confirmed that 3A 4A... is the correct alt key.

spiritovod, posted Tue Dec 01, 2020 9:10 pm (60841)

---

@KaneTW: Thanks for the info.

Syscache, posted Thu Dec 03, 2020 5:34 pm (60885)

---

I used the tool from Ginsor to extract all pkg files. These are all .bin files. How can I find out what kind of files they are and convert them into the right format

Edit:

All audio files seem to end with 135C0 and are easy to convert with ww2ogg.
I am mainly interested in image files.

Thanks to kanetw for sharing his work

Jamjardavies, posted Mon Dec 07, 2020 9:30 am (60955)

---

Ah perfect! So I've converted my code and some packages (or some blocks) doesn't seem to decode correctly, so I need to investigate more.

Edit: Seems like I'm unable to read the

Quote:

sr_sandbox_0105

package, but I'm able to read a few of the other packages, so I might have one of the keys wrong.

Edit 2: I think I found the issue!

Syscache, posted Wed Dec 09, 2020 8:13 am (60995)

---

Jamjardavies wrote:

Ah perfect! So I've converted my code and some packages (or some blocks) doesn't seem to decode correctly, so I need to investigate more.

Edit: Seems like I'm unable to read the

Quote:

sr_sandbox_0105

package, but I'm able to read a few of the other packages, so I might have one of the keys wrong.



Edit 2: I think I found the issue!

What was the issue

Jamjardavies, posted Tue Dec 15, 2020 5:35 am (61118)

---

I forgot to update where the Patch ID was found in the header, once I updated that it all opened.

Anyone know how to decode the mesh data? I've found the indices, and the vertex data, but there seems to be too much (sometimes too little) data for just position and UV. Also the data doesn't look like standard floats.

I've managed to get full texture loading now, and have fully decoded the headers etc.