Luigi Auriemma

Hi aluigi!
I want to mod Order of War rts game. Sethioz told me I can unpack files with your quickBMS, I am having a problem though - unpacking works fine only on some .pkg files (i.e. models and units) meanwhile if I try to unpack data from game.pkg and data.pkg files unpacked files are unusuable... I need to unpack these files since small officer portraits are located there as I suspect... and I need to replace them with custom made-ones. Do these files require different script to be unpacked properly or are they protected in some way? But there is another problem I have which is more important...is there a way to repack altered/replaced files? This is essential for modding process. Thanks in advance!

if the files are extracted but their content is "garbage" it means that has been used a different XOR key.

now I check if I can find the other possible key in the demo of both OFW and OFW Challenge but I doubt.

anyway no, I don't have a way to repack the files

Ok, I realized you don't do packing just unpacking/extracting from other forums on the web. If u find a way to unpack data and game.pkg please post it (yes prob a different key as you said). Thanks, btw quickbms is great program...

maybe I will work on this tomorrow but sincerely don't know.
for the moment I have seen the problem you describe with Challenge and even an error with another pkg file of the other game... so lot of job

aluigi your XOR key for this game is wrong/unnecessary. I have played a bit with the game files and have found parts with hex editor which are unencrypted in modles.pkg file by referencing files quickbms extracted. I simply copy/pasted hex-code to blank files and they were functional thus unencrypted. Later I deleted Xor key from your scripts and these files were extracted normally as I suspected. Thus XOR you wrote there is not necessary for these files and wrong for the data & game.pkg I was talking about earlier...

the xor key is used only if a particular field of the pkg file is set, so depends by the pkg file (but I wasn't 100% sure about that field).

script updated, it was only a stupid error I did in the script passing the xor key as C hexadecimal instead as a sequence of numbers :)
now works with both challenge (pkg 5) and the original order of war (pkg 4)

would be cool to support also the other older packages (1 to 3) but I don't know if exist games that use them

Nice work, Luigi everything works now. Thank you!

Hi again, could you please explain to me this line in your bms script? What is the encription key in here?



Second, are there any programs which will encript hex data when you enter the key you want? You see I have modded the extracted images and now need to put them back in. When unecrypted this is possible with hex editor but now I need to encript the file back... I know that key is used on whole .pkg file but I think can find the part it begins with by comparing unencrypted and encripted files in hex editor... so I just need to understand how does this type of encryption work?

p.s. sorry if this question is noobish but my knowledge on the subjects is rudimentary

edit: nevermind I got it... convert to binary and xor encript... it's easy, al the same if you know a good encryption converter please post it, because doing it manually is pointless

that code in the bms script means that if the file is real (because the pkg archives contain also references to files that are NOT stored in them and are tagget with the OFFSET 0xffffffff) then check if the archive is encrypted and extract the file.

if you need to encrypt a file you can just use quickbms and the following script:

thanks, you saved the day again... i was trying to do the same thing with xvi32 script... i got this far if i write a command like this:

BITXOR 5c
BITXOR 7b
.
.
.
BITXOR fb
BITXOR 4d
BITXOR b6
BITXOR c3

It get the job done for first 50 chars but I don't know how to tell it repeat that command again from the beginning to the end of file... is that possible? could you shed some light on this...

i will use your script anyways because it allows you to encrypt multiple files at once....

I have checked the syntax of xvi32 but I don't see instructions for repeating the operations in loop till the end of the file

Luigi I am interested if you now more on how pkg5 files work? I understand that first comes the data and at the end file names and directory paths, but I don't know how program knows where one file ends and other begins... that info must be in there somewhere also but can't find it. This would make my work after I finish much more easily distributed.... I doubt many people will try to hex the files into it themselves since it's a tedious job to do.

sincerely don't remember that format, anyway with the archives is needed ever at least to know the size of each file for their extraction and optionally their offset because in some archives they are concatenated and so in some rare file formats you have only the sizes.

OK, here is the data I gathered for so can u take a look a tell me what do you think:

FILES INFO:
campaign_ger start: 7DB3EE7 end: 7DCBB36

campaign_usa start 7DCBB37 end: 7DE3786

file size in hex: 17C4F

HEX DATA:



Parts in red come after raw data. Last 4 hex place signify end of pkg file, 00-00-00-FF-FF-FF-FF-FF-FF-FF-FF sequences are spacers and folder locations are obvious. So offsets and sizes must be the rest of the stuff but can't figure out how it works

I also noticed that before Campaign_ger folder locationand after gui/uimain/frontpages/newcampaign/. and 00-00-00 strings equals to 12 hex places which could be size plus offset of the dds files (5+7). same stuff occurs before campaign_usa folder location string.

So basically this would be strings to alter if i want to change size of file:

_ger:E7-3E-DB-07-50-7C-01-00-A8-CC-2B-26
_usa:37-BB-DC-07-50-7C-01-00-E4-D0-A0-34

you can see the middle 5 number are the same - these must be for size since these files have the same size, but I don't understand exactly how these numbers correspond to actual file sizes..

edit:

I have just realized that first 4 numbers represent file begining position in reverse:

in _ger E7-3E-DB-07 actually means position 7DB3EE7

and next 4 number are relative position or files size in hex in reverse + 1

in _ger 50-7C-01-00 means file size in hex 00017C50, and when 1 is subtracted you get actual size of 17C4F,

i'll go and test it now, but still don't know what last 4 nubers would mean?

it could be a crc, because for sure it's not a timestamp

new info, disregard last post:

PKG 5 FILE STRUCTURE

notes: - I was using xvi32 hex-editor
- parts of code with word meaning will be shown as text and the rest as hex codes
- empty spaces are used instead of 00 hex code which comes after every letter in text

Description:
------------
"P K G _ F I L E _ V E R S I O N : 0 0 0 5 "


Raw data:
---------
Note: Here come the hex codes of data without spacings with or without XOR encryption and uncompressed.

Start:
------
Note: This is probably command for core folder creation i.e. data

->At the beggining of non-data part of the file there is a 18 places log hex code.
->First 12 places are always the same:

12 00 00 00 FF FF FF FF FF FF FF FF ?? ?? ?? ?? 2E 00

where 12 in hex number for relative position of first subfolder from beggining of start, FF are probably disabled places for actual file positions (see files). 2E 00 means ". " .

Folders and subfolders:
-----------------------
->Before folder path comes 16 places long hex string:

NN NN NN NN FF FF FF FF FF FF FF FF ?? ?? ?? ??

where NN is relative position of next subfolder from beggining of this one written in hex in reverse.

->After the hex-string comes folder path:

i.e. "g u i / u i m a i n / . "

Files:
-----
->Before file path comes 16 places long hex string:

NN NN NN NN AA AA AA AA RR RR RR RR ?? ?? ?? ??

where NN represent relative position of next file path from beggining of this one in reverse in hex code, AA represents absolute position of file beggining written in reverse in hex code and RR represents relative position of next file beggining written in reverse in hex code.

->File path:

i.e. "g u i / u i m a i n / w h i t e . d d s "

End:
----
->At the end of pkg file come 12 position long hex string:

EE EE EE EE SS SS SS SS 13 0X 00 00

where SS represents absolute position of start written in reverse in hex code and EE represents relative position of end from start position written in reverse in hex code.

Last 4 position determine wheater or not XOR decryption is needed for raw data. In pkg with encypted data X is 1 so then decryption is enabled and in pkg file with non-encrypted data X is 0 so decryption is disabled.


I still didn't figure out what ?? places represent, maybe that crc you mentioned. It' values go way outside range of file if look as an absolute or relative position within hex file. also I have a question if this is known also would it be possible to make a quick bms script that would do the packing for these kind of files?

Edit:


Test for ?crc? stringz:

data_p1: 21 C1 CA A3 - start
67 5E D0 A3, 32 69 D5 A3, C1 69 DC A3 - next 3 subfolder lines

effects_p1: 7C A8 98 A9 - start
F4 B8 9E A9, A8 BD A2 A9, 5D B7 A8 A9 - next 3 subfolder lines

ok I have written down that SUPPOSED CRC STRINGS DOWN, (f%&$ng CAPS sorry) and it seems that they change in some kind of growing order...

Edit: it seems that these lines don't matter since I made working new pkg without altering them

wow long post :)
so, in conclusion, it's all solved right?

yes, it's solved, I can now make pkg files on my own.

but still i wonder would it be possible for you to write quickbms script which would do this operations from data in my previous post so I don't need to add every file manually with hex editor, it takes me around 5-8 mins per file and there are more then 100 of them I want to insert, and it gets even more time consuming when I need to test changes in-game) ? it would save me a lot of time.. thanks

p.s. also I wonder do you know how to program in lua? I have a problem with gui remake and would need someone to check out my work to find where did I screw up. I know it's relatively simple language but I have never worked with it before.