Destiny 2 Beyond Light

[Jamjardavies]

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]

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]

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]

Did someone get it to work ?

[KaneTW]

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

[KaneTW]

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]

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]

Are you sure VMProtect is used?

This should help

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

[KaneTW]

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]

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

\/ PM'd

[Syscache]

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]

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]

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]

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

[KaneTW]

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]

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]

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]

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

[spiritovod]

@KaneTW: Thanks for the info.

[Syscache]

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