[100% Completed] e^N-gine application/game data.pak

[thebads]

Platform: Windows
Game engine: "e^N-gine"
Games/Apps/Projects using it: Car Jacker 2 (And reskin Crazy Drive Away), WarChess (and reskin Chess vs. the Axis of Evil), Dolphin3D Screensaver, DIVER: DEEP WATER ADVENTURES

I'm attaching Dolphin3D files since it's the smallest, plus other games can read that data too

Here's some probably interesting things about file/engine:
* Can't find any text data or file headers via hex editor
* Audio as in sound effects, music can be heard if you opened it using Raw Data like via Audacity under various parameters, playback speeds
* It's possible to "poke" files inside pak (because game has limited built in console)
* Game tries to read local files first, and then reads data.pak (procmon will show what game is trying to load)
* You can execute external Lua (Lua 4) scripts, could be helpful?
* Using cheat engine, game seems to leaks contents of pak file? (as in file paths, not much of file data though)
* EXE has mentions of inflate, deflate, unzip libraries, seems to be vc6

Could someone do me lil favor?
I know time can be costly, I'm willing to pay/gift some game if anything.
There is particular .pak file from obscure game engine.
And yes, something like all in one watto game extractor wont open it.
I've tried making my own extractor but i'm not yet on that skill level and it's already a bit more than 2 years of me trying on my own.
I have collected few games/projects using same PAK stuff (it's possible to load each other pak files in other games), so there's many samples of exe and paks, the smallest sample is screensaver thingy (Dolphin3D).

I mainly want to mod, tinker, even cross over assets from one game to another.
To do that I really need a way to extract files (file reimporter or pak creator isn't a priority, although builddatapak.bat on car jacker 2 could be a hint)

I'm providing already extracted game files, game install media/sources, IDA decompile for carjacker and dolpins3d exe
https://drive.google.com/drive/folders/ ... sp=sharing
(if there's need I could upload it somewhere else too)

[AlphaTwentyThree]

Gave the pak file from Car Jacker 2 a look. I on my side have no idea how to extract it.

[AlphaTwentyThree]

Well, not entirely true: there's a TOC at 0x78220a1 with 0x4ab entries consisting of CRC, OFFSET and SIZE. The problem is that the offset seems to be the decompressed offset.
Take a look

Code: Select all

goto 0x78220a1
for i = 0 < 0x4ab
   getDstring CRC 0x10
   get UNK long
   getDstring DUMMY 0x6c
   get OFFSET long
   get SIZE long
   get ZERO long
   get ZSIZE long
   print "%OFFSET% %SIZE% %ZSIZE%"
next i

[aluigi]

Weird format indeed.
My only note is that I think that 0x10+4+0x6c is an obfuscated filename of 0x80 bytes.

There are no information about any possible compression moreover because I don't think there is any compression based on some patterns and long sequences of zeroes.
The offset remains a mistery, based on the pattern of the first file, the second should start at 0xc02c, 3rd at 0x18058 and so on while the table is:

Code: Select all

  offset   filesize   filename
--------------------------------------
  00000000 33112      00000000.dat
  00008158 33112      00000001.dat
  000201b0 33112      00000002.dat
  00048009 33112      00000003.dat
  00060061 33112      00000004.dat
  000681b9 33112      00000005.dat
  00080310 33112      00000006.dat
  000a8268 33112      00000007.dat
  000c02c0 33112      00000008.dat
  000c8319 33112      00000009.dat
  000e0371 33112      0000000a.dat
  001082c9 33112      0000000b.dat
  00120420 33112      0000000c.dat
  00128578 33112      0000000d.dat
  001405d0 33112      0000000e.dat
  00168429 33112      0000000f.dat
  00180481 33112      00000010.dat
  001885d9 33112      00000011.dat
  001a0730 33112      00000012.dat
  001c8688 33112      00000013.dat
  001e06e0 33112      00000014.dat
  001e8739 33112      00000015.dat
  00200791 33112      00000016.dat
  002286e9 33112      00000017.dat
  00240840 33112      00000018.dat
  00248998 33112      00000019.dat
  002609f0 57497      0000001a.dat
  0026eb88 664        0000001b.dat
  0026ed21 664        0000001c.dat
  0026efb9 57049      0000001d.dat
  0028ce91 2202       0000001e.dat
  0028d82a 436869     0000001f.dat
  002e83af 195672     00000020.dat
  00328006 273496     00000021.dat
  0036ac5e 271448     00000022.dat
  003ad0b6 442613     00000023.dat
  004093aa 43745      00000024.dat
  00423e8a 284576     00000025.dat
  0046952b 10977      00000026.dat
  0046c10b 524376     00000027.dat
  004ec163 10977      00000028.dat
  004eed43 10977      00000029.dat
  00501823 10977      0000002a.dat
  00504403 10977      0000002b.dat
  005070e2 10977      0000002c.dat
  00509cc2 737        0000002d.dat
  0050a0a2 524289     0000002e.dat
  0058a0a3 174817     0000002f.dat
  005a4d83 524289     00000030.dat

Code: Select all

goto -4
savepos TMP
get FILES signed_long
if FILES < 0
    math FILES n FILES
endif
xmath INFO_OFF "TMP - (FILES * 0x90)"
goto INFO_OFF
for i = 0 < FILES
    getdstring NAME 0x80
    get OFFSET long
    get SIZE long
    get ZERO long
    get ZSIZE long  # same as SIZE
    log "" OFFSET SIZE
next i

[AlphaTwentyThree]

Oh, didn't catch that signed value at the end.

Maybe one should add that the script doesn't work of course as the offsets differ from the actual ones.

[thebads]

Hmm. Sorry to necrobump, I guess it might be worth it to repost this elsewhere (like xentax) since this game archive is a weird one...
Thanks for your time...?

[Ekey]

Filenames obfuscated with simple algorithm

Code: Select all

public static Byte[] Decrypt(Byte[] lpBuffer)
{
    for (Int32 i = 0; i < lpBuffer.Length; i++)
    {
        lpBuffer[i] = (Byte)(lpBuffer[i] >> 1 | lpBuffer[i] << 7);
    }

    return lpBuffer;
}

Last DWORD value in PAK > (in my case > 0xFFFFFB9E for Crazy Drive Away game)

Code: Select all

VALUE = ~VALUE;
VALUE *= 144;
VALUE -= 4;

And you must get offset to table from end

[aluigi]

I still don't understand.

For the filenames we can use this patch in the script:

Code: Select all

    encryption math "r 1"
    filecrypt 1
    getdstring NAME 0x80
    filecrypt 0
    encryption "" ""

The last DWORD is just a negative number of files in my tests, using that formula with the ~ I get wrong results here with the sample.

And there is still the big problem of the table referencing a different content or an uncompressed content because the table says that the PAK archive should be about 0x487625 bytes while it's 0x31c2d5.

[Ekey]

Examples:

data.pak

Code: Select all

UInt32 dwPakSize = 94615847
UInt32 dwTableSize = 0xFFFFFB9E;

dwTableSize = ~dwTableSize; // 1122
dwTableSize *= 144; // 161568

UInt32 dwTableOffset = dwPakSize - dwTableSize - 4; //94454275

hawaii-data.pak

Code: Select all

UInt32 dwPakSize = 3261141
UInt32 dwTableSize = 0xFFFFFFCF;

dwTableSize = ~dwTableSize; // 49
dwTableSize *= 144; // 7056

UInt32 dwTableOffset = dwPakSize - dwTableSize - 4; //3254081

All table offsets are correct, idk what the problem btw: some files data also obfuscated with same algorithm

[thebads]

Yup, I'm currently tinkering (maybe for a hour at this point), same algorithm for path-file names seems to apply bc can see text contents
(part of builddatapak.bat which contains move data.pak to ../bin ) also localization text for missions.
I could be wrong on this one, There seems to also be some EXE / PE data inside? (MZ and "run in DOS")

[thebads]

Ekey seems to have posted here something but deleted... (something about file size being x 2 on quickbms 0.11 probably being bug, 83 vs 43 bytes)
Anyways Ig at this point I can only wait for (near-)final bms script or custom extractor and start trying it out on other paks.
Seems like we're about 80% complete on figuring out this data format.

Also It could be possible maybe game archive itself is a bit badly made (game programming is credited to one person, basically small indie studio).
Perhaps hacky detection, to use different parameters depending on file could be a workaround if needed idk.

[aluigi]

@thebads
You are correct, the "shift" obfuscation is applied to the whole table and data content, not just the filename.
Here is the script that perfectly dumps everything:

*edit* link to the script:
http://aluigi.org/bms/en_gine_pak.bms

And no, there is no bug in quickbms. The "~" symbol is used in programming languages for describing the "complement", in short "number ^ -1" while in this case it's clearly a negative:
0xFFFFFB9E ^ -1 = 1121
0 - 0xFFFFFB9E =1122

[Ekey]

I deleted the post because I decided to test one theory that was confirmed. Entry table also obfuscated. Anyway, here is my solution

Edited: viewtopic.php?p=69485#p69485

[thebads]

Welp hold on. For datamining its ok but extracted data still wont work
Tried both Ekey and aluigi script.
* Music OGG, Sounds Wav won't play. For Wav sounds like blasted, incorrectly (audacity, VLC, ffmpeg), not full lenght
* Textures - Blueish tint. Not all will load (Paint.net). Semi transparent. a bit striped?
* Lua scripts wont run, animations will be broken

same for Crazy Drive away and Car jacker 2 files

[Ekey]

Okay, try this one

Code: Select all

set MEMORY_FILE10 string "
void decrypt(unsigned char* lpBuffer, int dwSize)
{
  for (int i = 0; i < dwSize; i++)
  {
     lpBuffer[i] = lpBuffer[i] >> 1 | lpBuffer[i] << 7;
  }
}
"

goto -4
savepos TMP
get FILES signed_long

if FILES < 0
    math FILES n FILES
endif

xmath TABLE_SIZE "FILES * 0x90"
xmath INFO_OFF "TMP - (FILES * 0x90)"
goto INFO_OFF

log MEMORY_FILE INFO_OFF TABLE_SIZE
calldll MEMORY_FILE10 "decrypt" "tcc" RET MEMORY_FILE TABLE_SIZE

for i = 0 < FILES
    getdstring NAME 0x80 MEMORY_FILE
    get OFFSET long MEMORY_FILE
    get SIZE long MEMORY_FILE
    get ZERO long MEMORY_FILE
    get ZSIZE long MEMORY_FILE  # same as SIZE
   
    log MEMORY_FILE2 OFFSET SIZE
    calldll MEMORY_FILE10 "decrypt" "tcc" RET MEMORY_FILE2 SIZE
    log NAME 0 SIZE MEMORY_FILE2
next i

[thebads]

10/10 everything works! Thank you! ❤️

[Ekey]

Code: Select all

encryption math "r 1"

Does not works properly.

[aluigi]

I guess it's caused by the math command which is focused on 32bit numbers even when the command uses 8bits like in this case, not really a bug because math doesn't know the size of the input and can't set the bounds for the rotation.

Anyway I didn't pay attention to the documentation of quickbms because there is a "rotate" encryption that perfectly works: encryption rotate 1
The script:
http://aluigi.org/bms/en_gine_pak.bms

Any info about the compression?
Do we have any samples that use compression?

[Ekey]

I didn't see any compression, probably it simply does not exist ¯\_(ツ)_/¯

[thebads]

This is everything (all games using this game engine thingy) I've tracked down so far.
The only next steps would be to try reimporter / use BMS script to create pak, 3d model file import/export, Lua 4 decompiler (CFluaDC does work, output is promising but won't execute due to most decompilations bc of syntax error), Animations (ALF) file tools, Particle systems, and whatever other filetypes can be found in those games but that seems will be for another day, still me as newbie probably won't be able to figure out on my own.

Thank you all for help