[PLEASE DELETE]

[Guest]

[PLEASE DELETE]

Edited March 11 by AlphaTwentyThree
[PLEASE DELETE]

[h3x3r]

Unpack is possible, but repack will be pain in ass. There is table which has some values but they are somehow converted or manipulated in a way which doesn't make any sense to me.

Compression is oodle.

Here's guessed struct.

//------------------------------------------------
//--- 010 Editor v14.0 Binary Template
//
//      File: 
//   Authors: 
//   Version: 
//   Purpose: 
//  Category: 
// File Mask: 
//  ID Bytes: 
//   History: 
//------------------------------------------------
LittleEndian();OutputPaneClear();

local uint32 i,j,k;

struct HEADER {
    char Magic[4];
    uint16 Flag,Version;
    uint32 Unknown_0,Unknown_1,Unknown_2,Unknown_3;
    uint32 FileSize,Unknown_4;
    uint64 FileHASH64;
}Header;
FSeek(1928);

struct INFO {
    uint32 Files,Unknown_0,BaseOffset,Unknown_3;
    uint32 DataSize,Unknown_4,FilesTmp,Unknown_5;
    uint32 TableOffset,Unknown_6,Unknown_7;
}Info;

FSeek(Info.TableOffset);

struct TABLE {
    uint64 NameHASH64;
    uint32 Offset,Size;// These values are most probably modified by something
}Table[Info.Files]<optimize=false>;

I checked first file at BaseOffset and it has another 44 bytes header describing something + compressed size/decompressed size

[Guest]

Will take a look later on and try to convert that into QuickBMS, thanks!

[h3x3r]

Or you can do it by a dirty way. But i think you won't be able to reimport. Also qbms doesn't have oodle compressor so you must compress it manually with external compressor.

comtype oodle
get BaseFileName basename

for
	findloc BaseOffset string "\x00\x00\x01\x00\x00\x00\x01\x0E"
	goto BaseOffset
	getdstring Dummy 0x8
	get ZSize long
	get Size long
	getdstring Dummy 0xC
	savepos Offset
	string Name p= "%s/0x%08x.dat" BaseFileName Offset
	clog Name Offset ZSize Size
next

 

[Guest]

Hm, something is off, it only extracts parts of the files. Here are snippets from the start and end of a larger file, there's a list at the end sorted by CRC it seems.

xsub.7z

Edited February 28, 2024 by AlphaTwentyThree

[h3x3r]

Yeah i noticed it. That table is only for files compressed with oddle. There are also another files with different comp algo.

[DKDave]

In the TABLE struct, where you have Offset, Size - the second value is the Offset which needs to be multiplied by 0x80 to get the correct value.  The first value is the total size of the data - bit 0 is a flag for compression, and the rest needs to be shifted right by 1 to get the total size.

For compressed files, the 0x2c header for each file seems to start with 0x1df0, then the 8-byte hash value from the file table, ZSIZE at 0x18, SIZE at 0x1c, relative offset to compressed data at 0x20.

The uncompressed files seem a bit more random, they start with a table of offsets, but no item count.

 

 

[Guest]

Oh damn, thanks for the info - I'll check it out later this week for sure. 🙂