#Dark souls 3 save game editor full#
#Dark souls 3 save game editor software#

The hash function looks like this, but I couldn't confirm it with some test cases yet. See: BinderTool Issue #3 Decrypting BDT5 filesД«esides exporting all the static file names I could find in the executable I haven't worked on recreating the file name dictionary. The data after offset 78 can then be decompressed with zlib All the data after offset 80 is then decrypted with the AES key a second time All the data after offset 78 is processed two times by some unknown algorithm that is related to zlib Decrypted with the AES key found in the DataX.bhd file The data that is read from the DataX.bdt files is: If the file size of an entry is 0 (DCX files), then the game loads the first 48 byte to determine how much of the data has to be read.ДCX encryption is a bit overkill. bhd files use the BHD4 format (which at least contains unicode filenames).Д 10 Editor typedefs of the AES key and the SHA Hash structs look like this: The DataX.bhd files use the BHD5 format while the other.

Дata0.bhd isn't even used by the game and the decryption key is probably not even included in it. bnd.dcx file which contains the following. I can also share some of my findings you didn't write about yet.Дata0.bdt is just a single. Most of this I've put together myself, but I'd be lying if I said I did it all without some indirect help from Atvaark (author of BinderTool). Nyxo wrote:As far as I know, this is pretty much everything anybody has figured out so far.

#Dark souls 3 save game editor software#

For all we know at this time, perhaps FROM Software has put further encryption on their internal file entries as well. BHD/.BDT, etc.) may or may not work immediately.

#Dark souls 3 save game editor full#

Once these 2 issues are resolved, we'll have full unpacking of all of the main archives available, however internal archives (such as. This is going to be an ongoing process, as there's no simple way to just get all of the filenames. I believe the compressed data may be further encrypted, but I'm not 100% sure on this - I'm conducting further research into this at the moment.ДЄlso worth noting is that there is no complete filename lookup dictionary available yet. However, decompression fails with various internal errors. Decryption seems to work fine (it generates a valid DCX header, all the way up until, and including, the 2 byte header for the GZipBlob). The current (rather large) issue that both my DS3Explore, and Atvaark's BinderTool exhibit is that while the encryption and compression data above is correct when used individually, any entry (this is most of them!) that is both encrypted AND compressed don't seem to work exactly as described above. This GZipBlob is why some of you have had luck getting some files out of the archives, but it'll only work for compressed, non-encrypted, files.ДЄs far as I know, this is pretty much everything anybody has figured out so far. The DCX compression hasn't changed much since Dark Souls 1 - it's basically a custom (Big-Endian!) header around a gzipped blob: Decryption must always happen before decompression. If the entry has a 0 DataSize (whether encrypted or not), it's DCX compressed. (This is because the form of AES encrypting used requires data to be padded to a certain size) After decrypting, the data can be truncated to the entry's DataSize. The size of the bytes that need decrypting is the entry's BdtSize. If an entry has an AESKeyOffset defined, it's data in the.

Ulong ArchiveSize //Doesn't match up perfectly? There may be padding at the endД®ntryStruct Entry.Entrењњount] SPrintf(ret, '%d Entries', bs.Entrењњount) String ReadBucketStruct(BucketStruct &bs) Quad DataSize //Sometimes 0 (is compressed)Д«yte SaltedHash //Not actual size, just marking first byte Quad AesKeyOffset //Sometimes 0 (no encryption), 0x10 bytes each String ReadStringStruct(StringStruct &ss)