I'm trying to extract pakchunk14-Switch.pak from Borderlands 3 Ultimate Edition (Switch) for a fan translation project.
Confirmed so far:
- The AES key I have (UUoXdq2EdP+HPkZDcmvn55pGmbgCoKnlfZ434yIXhVU=, base64) is 100% correct — successfully decrypts the mount point and full file list in the index, readable as plain text
- Pak version = 6 (DeleteRecords)
- The footer is shorter than spec — missing the bEncryptedIndex/EncryptionKeyGuid fields that version 6 should normally have
The problem:
- Tried repak, unpak, and QuickBMS (unreal_tournament_4.bms, both v0.4.25 and v0.4.26c) — none of them can extract it, even with the correct key
- Measured the raw bytes from the unencrypted per-file duplicate header (embedded before each file's data) and found records are only ~38 bytes (.uasset) or 18 bytes (.uexp) — much shorter than the standard FPakEntry struct (Offset/Size/UncompressedSize as int64 + 20-byte Hash should be 45+ bytes minimum)
- Partially decrypted actual file data and found the C1832A9E magic tag for .uasset plus LegacyFileVersion = -7, confirming the decryption direction is correct, but I can't pin down the exact field/chunk boundaries
Relevant precedent:
Found a similar case with the Dragon Quest 11 Demo (UE 4.18.3, pak version 4), where the compression method flag was deliberately obfuscated (0x3 for Oodle misread as Zlib by UnrealPak because it only checks 0x3 & 0x1 == 1), and the Oodle table byte order was flipped specifically to break QuickBMS/UnrealPak detection (ref: gbatemp.net thread 546613). Wondering if BL3 Switch uses a similar deliberate obfuscation trick, possibly done by Panic Button (the studio that did the Switch port).
Main questions:
1. Have you seen Borderlands 3 Switch (or other Panic Button ports) use a shortened/custom FPakEntry like this before?
2. Is there an existing QuickBMS script or tool that already supports this format?
3. If not, is there a general pattern Panic Button tends to use across their other ports that I could compare against?
Confirmed so far:
- The AES key I have (UUoXdq2EdP+HPkZDcmvn55pGmbgCoKnlfZ434yIXhVU=, base64) is 100% correct — successfully decrypts the mount point and full file list in the index, readable as plain text
- Pak version = 6 (DeleteRecords)
- The footer is shorter than spec — missing the bEncryptedIndex/EncryptionKeyGuid fields that version 6 should normally have
The problem:
- Tried repak, unpak, and QuickBMS (unreal_tournament_4.bms, both v0.4.25 and v0.4.26c) — none of them can extract it, even with the correct key
- Measured the raw bytes from the unencrypted per-file duplicate header (embedded before each file's data) and found records are only ~38 bytes (.uasset) or 18 bytes (.uexp) — much shorter than the standard FPakEntry struct (Offset/Size/UncompressedSize as int64 + 20-byte Hash should be 45+ bytes minimum)
- Partially decrypted actual file data and found the C1832A9E magic tag for .uasset plus LegacyFileVersion = -7, confirming the decryption direction is correct, but I can't pin down the exact field/chunk boundaries
Relevant precedent:
Found a similar case with the Dragon Quest 11 Demo (UE 4.18.3, pak version 4), where the compression method flag was deliberately obfuscated (0x3 for Oodle misread as Zlib by UnrealPak because it only checks 0x3 & 0x1 == 1), and the Oodle table byte order was flipped specifically to break QuickBMS/UnrealPak detection (ref: gbatemp.net thread 546613). Wondering if BL3 Switch uses a similar deliberate obfuscation trick, possibly done by Panic Button (the studio that did the Switch port).
Main questions:
1. Have you seen Borderlands 3 Switch (or other Panic Button ports) use a shortened/custom FPakEntry like this before?
2. Is there an existing QuickBMS script or tool that already supports this format?
3. If not, is there a general pattern Panic Button tends to use across their other ports that I could compare against?
