Death Stranding (PS4)

[wunk]

Lookin good

I got some C++ code up here too
https://github.com/Wunkolo/DecimaTools

Mind slapping a license on that project? I'm planning on rewriting ProjectZeroDawn to C++ when the PC port releases and I'd love to have a C++ point of reference.

Sure! It's just MIT

Great job! Do you looked code for decrypt files data? Seems MD5 is involved in decryption and there other key (salt) are used

Code: Select all

static unsigned long lpSalt2[4] = {
       0x6C084A37, 0x7E159D95, 0x3D5AF7E8, 0x18AA7D3F};

or

Code: Select all

static unsigned char lpSalt2[16] = {
       0x37, 0x4A, 0x08, 0x6C, 0x95, 0x9D, 0x15, 0x7E,
       0xE8, 0xF7, 0x5A, 0x3D, 0x3F, 0x7D, 0xAA, 0x18};

As you wish

Still digging in slowly! Haven't been able to take this on full-time but I'm still digging in with the intent of possibly re-encrypting and re-packaging these files at some point.

[Ekey]

The files are approximately decrypting as follows:

1) For each chunk you need to get first 16 bytes of block table

Code: Select all

byte[] lpBlockTableData = Copy here blablabla

PS: Screen from block table of file 7017f9bb9d52fc1c4433599203cc51b1.bin

2) Now we need to get murmur3 hash from this

Code: Select all

var lpMur3Hash = MurMur3_GetHash(lpBlockTableData, 16);

3) Necessary to mix hash with second key (salt):

Code: Select all

for (Int32 i = 0; i < 16; i++)
{
    lpMixedKey[i] = lpMur3Hash[i] ^= lpSalt2[i];
}

4) Now we need to get MD5 hash of MurMur3 hash

Code: Select all

var lpMD5Hash = MD5_GetHash(lpMur3Hash);

5) Decrypting data by provided by MD5 hash (probably lpMixedKey using at the end, until I figured it out -> if dwSomeDataSize....)

Code: Select all

Int32 dwEncryptedSize = dwChunkSize >> 4;
Int32 dwSomeDataSize = dwChunkSize & 0xF;

if (dwEncryptedSize)
{
    for (Int32 i = 0; i < dwEncryptedSize; i++)
    {
        lpBuffer[i] ^= lpMD5Hash[i % 16];
    }
}

if ( dwSomeDataSize )
{
    __asm { vpxor   xmm0, xmm0, xmm0 }
    Var38 = 7;
    Var39 = (unsigned int)dwSomeDataSize;
    do
    {
	_RDX = 1i64 << (Var38 & 0x3F);
	if ( Var38 & 0x40 )
        _RDX = 0i64;
	Var38 += 8;
	__asm
	{
		vmovq   xmm1, rdx
		vpinsrq xmm1, xmm1, rcx, 1
		vpor    xmm0, xmm1, xmm0
	}
	--Var39;
    }
    while ( Var39 );
    _R10 = 2 * dwChunkSize;
    __asm
    {
	//lpMixedKey???
	vmovdqu xmm2, xmmword ptr [rsi+r10*8]
	vpxor   xmm1, xmm3, xmm2
	vpblendvb xmm1, xmm2, xmm1, xmm0
	vmovdqu xmmword ptr [rsi+r10*8], xmm1
    }
}

Code: Select all

goto 1);

The information is not yet complete but it is the basis of encryption, maybe I missed something else, anyway, I’ll supplement it later

[wunk]

5) Decrypting data by provided by MD5 hash (probably lpMixedKey using at the end, until I figured it out -> if dwSomeDataSize....)

Code: Select all

Int32 dwEncryptedSize = dwChunkSize >> 4;
Int32 dwSomeDataSize = dwChunkSize & 0xF;

if (dwEncryptedSize)
{
    for (Int32 j = 0; j < dwEncryptedSize; i++)
    {
        lpBuffer[i] ^= lpMD5Hash[i % 16];
    }
}

if ( dwSomeDataSize )
{
    __asm { vpxor   xmm0, xmm0, xmm0 }
    Var38 = 7;
    Var39 = (unsigned int)dwSomeDataSize;
    do
    {
	_RDX = 1i64 << (Var38 & 0x3F);
	if ( Var38 & 0x40 )
        _RDX = 0i64;
	Var38 += 8;
	__asm
	{
		vmovq   xmm1, rdx
		vpinsrq xmm1, xmm1, rcx, 1
		vpor    xmm0, xmm1, xmm0
	}
	--Var39;
    }
    while ( Var39 );
    _R10 = 2 * dwChunkSize;
    __asm
    {
	//lpMixedKey???
	vmovdqu xmm2, xmmword ptr [rsi+r10*8]
	vpxor   xmm1, xmm3, xmm2
	vpblendvb xmm1, xmm2, xmm1, xmm0
	vmovdqu xmmword ptr [rsi+r10*8], xmm1
    }
}

`dwSomeDataSize` looks like it's just handling unaligned data while `dwEncryptedSize` is handling aligned data(groups of 16).
That `vpblendvb`looks like it's doing some byte-level blending between the xor-ed unaligned data and the salted hash before writing it out to the chunk(Picks bytes between registers depending using another byte, the equivalent of a byte-level conditional write, c = x&0x80 ? a:b). That `vpinsrq` loop looks like it's just pushing a bit value(x = 0b111ul << i%64) on the lower 64 bits of the 128 bit register and a rcx into the upper 64 bits before doing a `^=` and then blending it later. Not sure what rcx is in this case.

Got an exe offset or signature or something for this function so I can take a look?

[Ekey]

`dwSomeDataSize` looks like it's just handling unaligned data while `dwEncryptedSize` is handling aligned data(groups of 16).
That `vpblendvb`looks like it's doing some byte-level blending between the xor-ed unaligned data and the salted hash before writing it out to the chunk(Picks bytes between registers depending using another byte, the equivalent of a byte-level conditional write, c = x&0x80 ? a:b). That `vpinsrq` loop looks like it's just pushing a single-bit value(x = 0b111ul << i%64) on the lower 64 bits of the 128 bit register and a rcx into the upper 64 bits before doing a `^=` and then blending it later. Not sure what rcx is in this case.

rcx is always zero

Got an exe offset or signature or something for this function so I can take a look?

Yeah sure, for current patch 1.01 address is 00000001416D1C90.

[wunk]

Still digging in. That routine is a bit of a tangle and the IDA decompiler is missing out on entire registers since it cant make sense of some of the higher-level intents of the SSE and AVX simd. RCX isnt always zero but rather RDX and RCX are ultimately going to become the upper and lower halfs of xmm1 and are generated differently based on some conditional moves.

It looks like that routine just generates the mask register(setting the upper 7th bit in each byte), Loads in the 16 bytes of cipher-text(likely padded with 00s), xors it with the hash like before, and then uses the mask register for byte-blending between the previously xor-ed value, and the mask register again before writing it back to plain-text. My SIMD/HPC programming experience is paying off



Rather than recreate this mask-generation code though, xmm0 can be made entirely ahead of time. This code is only run on unaligned data and so all 15 possible mask registers can be made like this.

Code: Select all

from ctypes import *

CurShift = 7
Mask128 = 0
for x in range(16):
    Mask = c_uint64(1 << (CurShift % 64)).value
    MaskLo = Mask
    MaskHi = 0
    if CurShift & 0b01000000: MaskLo, MaskHi = MaskHi, MaskLo
    CurShift += 8
    Mask128 |= (MaskHi << 64 | MaskLo)
    print(format(x,'3') + ": " + format(Mask128, '0128b'))

And these values can be

Code: Select all

  0: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000
  1: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000010000000
  2: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000001000000010000000
  3: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000100000001000000010000000
  4: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000010000000100000001000000010000000
  5: 00000000000000000000000000000000000000000000000000000000000000000000000000000000100000001000000010000000100000001000000010000000
  6: 00000000000000000000000000000000000000000000000000000000000000000000000010000000100000001000000010000000100000001000000010000000
  7: 00000000000000000000000000000000000000000000000000000000000000001000000010000000100000001000000010000000100000001000000010000000
  8: 00000000000000000000000000000000000000000000000000000000100000001000000010000000100000001000000010000000100000001000000010000000
  9: 00000000000000000000000000000000000000000000000010000000100000001000000010000000100000001000000010000000100000001000000010000000
 10: 00000000000000000000000000000000000000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000
 11: 00000000000000000000000000000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000
 12: 00000000000000000000000010000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000
 13: 00000000000000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000
 14: 00000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000
 15: 10000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000

When you collapse this logic though, it seems like the un-aligned xors are quite literally just doing partial xors(n-bytes of unaligned data is just the first n-bytes of the mixed-hash being xored against it) and then using the byte-blending to preserve whatever un-aligned data is within that 16-byte window. You can pretty safely assume that it is just a full xor for aligned and unaligned data.

I don't have my code base up to the point to where it even has to decrypt these chunks to verify a working implementation. And I won't be able to look at this full-time but I can give it an afternoon every now and then and share notes while I update my code base

[JayK]

Thanks for the work you two have been doing on decryption, and for keeping things open as well. I've updated an old repo I had based on your findings. I didn't implement that new information about unaligned data, but some things seem to be decrypting correctly. file 0 of 7017f9bb9d52fc1c4433599203cc51b1 looks to be the prefetch file.

source code and files at https://github.com/Jayveer/Decima-Explo ... es/tag/1.5 if anyone wants to try it.

[Ekey]

@JayK - Good job! Here is a list of archives with a description, if anyone is interested

Code: Select all

40fb866e44aec444200cdb0c384cf5a5.bin - Area00
6fb69851f3279ea051f48ee6c98c73fe.bin - Area00_English
225bb34815aa3e89f155ba2515570cb2.bin - Area00_French
e72aac57de9918c67eaf3d5102c8acb8.bin - Area00_Spanish
84e35fcf5de2ba16cc1ee893ba4dc56c.bin - Area00_German
6fcdd0390579931aa1c93da879e28d82.bin - Area00_Italian
553cfe4d8b9fe4769e534e703bfb9732.bin - Area00_Portuguese
2709afee4cac7fc87a04bd2b6c1c5882.bin - Area00_Russian
f573fbfdff7eb1fa271f382e24503f82.bin - Area00_Polish
f3a2ab17a7c17470623d3e842224841f.bin - Area00_Japanese
4411fbe7b81d872e8517abf67e932280.bin - Area00_LATAMSP
6cafab4876800a73ab36290c76730f68.bin - Area00_LATAMPOR
8761c9be94b95d7197c850a230bb05aa.bin - Area00_Greek
1a472f28ea1537dd3cb911fd1e18f2af.bin - Area01_English
f77b66dc12e3085afdf2ccee9e3bddb8.bin - Area01_French
55a0f2ad6fd854eb46eda325ebd3fdfe.bin - Area01_Spanish
88c5cf29d347a6f0007199554279573e.bin - Area01_German
a53083d2a39c921b2fbfc520216f17d7.bin - Area01_Italian
4c7518f562e8cfc65349f261cb4a4935.bin - Area01_Portuguese
4e5bed8e41d7417c889b2284f33c35f0.bin - Area01_Russian
110d9add046eec4d23810f2fa9565924.bin - Area01_Polish
eb8cd08d682978a9b9112d7c8f54de21.bin - Area01_Japanese
f7b4c4ff1b831d3adf6fa1952a978767.bin - Area01_LATAMSP
c172307816383537bd4703897044f6c5.bin - Area01_LATAMPOR
f26fd3ec3d943dd6aaff93a45a8025c2.bin - Area01_Greek
c0306eef15c4b5122ab61a834f80d743.bin - Area02
9abda4bd99f4fa01951fd153775e7e8d.bin - Area02_English
69e57bab4b0e47d007bab3b3fcca6dc5.bin - Area02_French
e8b2c1ef002e12ddfb73977afa1955a7.bin - Area02_Spanish
b11ab76d7450f70cd80f46037963e22f.bin - Area02_German
47a882f8b80bfb6954d92201251744bf.bin - Area02_Italian
7eb2acb7d14889097248e156637e95a1.bin - Area02_Portuguese
0404fe2210c6609046c1c08bf2ea7c8a.bin - Area02_Russian
cb4196d63aaed195c987dfb47bbfadf5.bin - Area02_Polish
2c8aaa03cef19c1d7d4d14f8b29c7197.bin - Area02_Japanese
dae3bdff0b5583a91ff40d98d3bf73a3.bin - Area02_LATAMSP
13cf568657bcfb893b6b97b5e81f4ae3.bin - Area02_LATAMPOR
e084898e7d0371f8cd9688cd303841f5.bin - Area02_Greek
dc847b243b638c5ce539d4be7ff48007.bin - Area04
8d60c6e8d6ce70496107e588205a3054.bin - Area04_English
f0f467ec1b144337ef804ab0dc1a633e.bin - Area04_French
20dec5c29481cc1d3e21dec2b289e8e9.bin - Area04_Spanish
a64d5675363bcfae85f36b39faafba5d.bin - Area04_German
0a5d8e4999a0dc48da7b66c8b8251c42.bin - Area04_Italian
adc5401f627e7d6b1e23afe75e06fe4c.bin - Area04_Portuguese
0a58238b82416a35c9e3dc3b3a6e825c.bin - Area04_Russian
3430babbf55916a937a8757da75199c7.bin - Area04_Polish
237d41a6888266372a7c9100526dfeb9.bin - Area04_Japanese
7ff527fda0571c79839bb8aa9c3db648.bin - Area04_LATAMSP
ea97cfbec2be98a216a6450faf9710b0.bin - Area04_LATAMPOR
a610c95e0690047924d1afbb824d0250.bin - Area04_Greek
477e458b2c825633499874678a2b9ea5.bin - Beach01
f70387b309fdda4e66a9d1808815252d.bin - Beach01_English
c4c4d7253d00afff7e7859822e967f05.bin - Beach01_French
0a7a707a3e247348d81931fa45ad28b3.bin - Beach01_Spanish
f829e168029598d8ceea4f4d01e54378.bin - Beach01_German
8a290e232dd8d4c727cf2da3fadd5c5b.bin - Beach01_Italian
1c3b38583613deb87f5b4e9ff1dd94c4.bin - Beach01_Portuguese
f7f21580058bd1b925180851f3969070.bin - Beach01_Russian
4d8d31832be4055295b9e619cf315740.bin - Beach01_Polish
c28838ba40cb2165ee8dd703a8cdb0e3.bin - Beach01_Japanese
c2dc1b0259864bcf814b4cd81cd917d4.bin - Beach01_LATAMSP
dc915927c83cb738ae87857742e4c774.bin - Beach01_LATAMPOR
10b8dcebcce8280dac2f30f0a57cba2a.bin - Beach01_Greek
7017f9bb9d52fc1c4433599203cc51b1.bin - Initial
a694c2e00b87cd761ee2a25b09a49ea7.bin - Initial_English
a5dcec9b54e1586b097e5c49a07429c5.bin - Initial_French
a1cc3eee3d405a5613916e1297641289.bin - Initial_Spanish
3cd22bf810430d77b7fff991a4b81551.bin - Initial_German
dbef71d6d372f7c6bdaf3717c119b519.bin - Initial_Italian
c920bcebb78902bf6ac6c447eab9fb41.bin - Initial_Portuguese
d8f0b887a3642eca5ada40e8cdff07db.bin - Initial_Russian
54d23a724866aa2d6025ebb2a688c968.bin - Initial_Polish
4bb8707b549628feb844fbf8d0c85327.bin - Initial_Japanese
cf44457b965b72abb6ee66bdddd60b3a.bin - Initial_LATAMSP
94d6a62c9fb7a869754f0d6bc19f81e7.bin - Initial_LATAMPOR
8ebc24104a70f5f1b13eb04d175614b2.bin - Initial_Greek
59b95a781c9170b0d13773766e27ad90.bin - Patch
3460515fd6d930b689143a8b9a51a060.bin - Remainder
17881513a7e2a728ccd2ae7301dc9054.bin - Remainder_English
d9ae8d6654a7ceca64c8dc18952d3209.bin - Remainder_French
e33dd8b96035b2f7e547aed5fbfdf8e5.bin - Remainder_Spanish
a6b263ffdda8aca7fb8decba961b8097.bin - Remainder_German
e8276e34701d2a6664c9a29d20062f9c.bin - Remainder_Italian
9eb0941601e90d4b6c81d62b48959786.bin - Remainder_Portuguese
fa24bd744dbf75e81308c45581f49817.bin - Remainder_Russian
be25f0823739852892e4b6179818e715.bin - Remainder_Polish
17fa480245a3a67a1e5ecc246cee719d.bin - Remainder_Japanese
b52dacb981213ed55cb3be42bea80258.bin - Remainder_LATAMSP
dbcebbf108d0da62acee516ab446ccd0.bin - Remainder_LATAMPOR
fee239d94dfcb9a257cd4d15fe0a7d21.bin - Remainder_Greek
968bf82f34e2b499687c901a888e633a.bin - Warrior01
4707c0dea95bdf7b38ed0d838965e0e6.bin - Warrior01_English
b70fa685f46ec3f4b8a19b53f666b69f.bin - Warrior01_French
fb4e818aa0dc2f8f791fe518a8910337.bin - Warrior01_Spanish
3523588f0825ad5f54013b6031361d3b.bin - Warrior01_German
26d92e4a0d5e060ba1879de2d02f5fc2.bin - Warrior01_Italian
b20229b7199ba8c81854d513f764e2c9.bin - Warrior01_Portuguese
fb5160bf0cda8b0bca124d04d51de62c.bin - Warrior01_Russian
68d7fcb76bb55037ebbffbd01bcb2b08.bin - Warrior01_Polish
c9d841287e962d3d54123652828ebd00.bin - Warrior01_Japanese
44108381064a698eb7376aee4bc1478d.bin - Warrior01_LATAMSP
d0218c32efbff643a19603a31efcc3c2.bin - Warrior01_LATAMPOR
8d73fa4af178fe81ae95d0cb8c7fc606.bin - Warrior01_Greek
fcd4b5918cea9a220c0da171bb60c214.bin - Warrior02
7ccfce87d9887adf1689fbd07df4200a.bin - Warrior02_English
46485581ea66e58e27b5040b40257bce.bin - Warrior02_French
80022ad18cf34441da2e8e8557d524df.bin - Warrior02_Spanish
aa828c35c790d250cdc765ab9b8e6050.bin - Warrior02_German
6a562dc4e089db4b922573066a7ec884.bin - Warrior02_Italian
2b4203d8d2cf539bada40ff7fbe734fc.bin - Warrior02_Portuguese
cd336bf6b36bab5527c3b3609093abe7.bin - Warrior02_Russian
e9ea778cf34ee584e523e958bfcf8f81.bin - Warrior02_Polish
50023cc2d26d8242720e71676ceac967.bin - Warrior02_Japanese
9392f016b4dba2cfec41607e0a9e2250.bin - Warrior02_LATAMSP
da0346efdd0d2b8eb3c067c93ffdbf33.bin - Warrior02_LATAMPOR
343d88e2515bfd702fd34962f63c1d45.bin - Warrior02_Greek
a53f66da5938a089f06b8a0c07c97f18.bin - Warrior03
93a37de4096fad67e0c99100775cce42.bin - Warrior03_English
064bff9f859fb5a0bd74f0a486e133ab.bin - Warrior03_French
32c38c240a31c6452f47836177ee46b9.bin - Warrior03_Spanish
3c040baec191e5117685af0bf4e2c312.bin - Warrior03_German
9652986d6bacd063df6cbb252ef828ee.bin - Warrior03_Italian
9ac69cf07935e12ebc4a10a5a846d5cf.bin - Warrior03_Portuguese
1bb90bd3941536ce94002ae82a953f6b.bin - Warrior03_Russian
54106a2ec29dfb15584b5c104c05b219.bin - Warrior03_Polish
b0720c4389202911af7e64531d973a00.bin - Warrior03_Japanese
49a78b888f6a86fbb68a50b115ee77c4.bin - Warrior03_LATAMSP
138969409f16e44df28d7fbcb87a5909.bin - Warrior03_LATAMPOR
819f5249d44b19c7e4bff600b89a1a32.bin - Warrior03_Greek

Yup, 7017f9bb9d52fc1c4433599203cc51b1.bin is a initial archive which, contains of all entry list (with id 0) and apparently for this it is always loaded first. I did not find a list in other files

[JayK]

Looking into it more, it looks as if that other decryption path is hit once it starts reading above 0x80000000 (for example once the compressed offset is above that)
EDIT: Nevermind, false alarm. Was just an fseek problem.

[devilsnake88]

Something interesting is to see PC and PS4 versions of 3D models or textures files are not the same.
Here is a sample:
https://cdn.discordapp.com/attachments/ ... weapon.zip

[Espio]

Any progress on exctracting videos from movies.mpk file?

[JayK]

Any progress on exctracting videos from movies.mpk file?

The decryption used on the mpk files is the same for the header and info, the salt is different this time { 0x833237C3, 0xBA5CD4B6, 0x3371A06B, 0xAEA7EDB2 }; 0x04 of header is the 4 bytes which replace the first 4 bytes of the salt this time round with 1 pass for decryption. 0x08, 0x0C are both used to replace the first 4 bytes of the salt for each pass respectively. Haven't found the subroutine for where the decryption of the rest of the data is done yet.

Edit: Ok, quite close to figuring out the movie decryption, it's mostly similar to the main file decryption, the differences being that there is an xmm blend this time before the xor salt, which blends against a value from EBP. It was 0 in the example I was debugging the first time it hit the function, 2 the second, 1 the third.So I'l have to see what it actually resolves to to say this is figured out completely (at a guess it could be the current iteration). The xor salt this time is { 0xCE857276, 0x9ACC40E8, 0x8242DBD6, 0xCF703987 } after the md5 hash it xor's a fixed number of times (0x10000 as it's 0x10 bytes a time thats 0x100000 bytes). Not sure how it handles alignment considering this loop is rigid, may just pad bytes up to that in the last few passes. I'd probably have to step out of this function a bit to resolve the last few unknowns, I'll add it to my source once it's done.

Edit2: EBP did turn out to be the current iteration of the function so that it is what gets blended with the result of the murmurhash func, the rest is pretty much the same and thats all their is to the movie decryption. I've added an implementation of it to the tool I posted above.

[JayK]

Edit2: EBP did turn out to be the current iteration of the function so that is what gets blended with the result of the murmurhash func, the rest is pretty much the same and that's all there is to the movie decryption. I've added an implementation of it to the tool I posted above.

[Espio]

Thanks for info and research. Could you please upload binary with movie extraction support? If not on GH, then here. Thanks in advance!

[JayK]

Thanks for info and research. Could you please upload binary with movie extraction support? If not on GH, then here. Thanks in advance!

I already linked it a few posts above, but here it is again
https://github.com/Jayveer/Decima-Explo ... es/tag/1.5

[Azetlor]

Is it possible to extract the game's music using this tool? Does anyone know where the music is located?