Hi Folks,
No, I wasn't dead
I recently noticed that shaiya discover the "i18n" paradigm, never tool late.
It also means that shStudio will soon or later only manage a very few part of the files.
I so decide to re-re-spend some time on it.
And since I have the code that close ...
1) the data.saf in a big stream resulting of the concatenation (a cat) of all files used by the client, it has no own structure since it is not packed (zipped) in any manner.
2) the data.sah contains the indexes required to parse the archive (meaning the .saf).
the header of the file is as follows:
Code:
struct sah_header {
// 51 bytes flat structure
char signature[3]; // 'SAH'
long unk1; // 0
long nbFiles; // number of all files (not including folders)
char padding[40]; // 00s
};
then, one reads recursively:
- name of current directory
- number of files in that directory (long, 32 bits)
+ for each file
- name of file (relative to the parent directory)
- offset in .saf where the file starts (__int64, 64 bits)
- file's length (long, 32 bits)
- "attributs" (long, 32 bits) can be anything, not used by clients (can store "version" info).
+ end for
- number of child directories (long, 32 bits)
{ each sub-dir is read recursively with same structure }
all string (names of files and directories) are prefixed by their length coded as a long (32 bits, Little Endian), the ZeroTerminal char. is usually included in this length; so for instance the root directory (which is usually - but not mandatory - empty) is coded as: [01 00 00 00](length) [00] "\0"
once you have found the right file name in right directory, you use the corresponding offset within the .saf to read the given size of data.
after edition, if any, you can store the file at the same offset as long as it is not bigger than its original size, you will store the new (shorter) length if required; if file is larger, a new block is added at the end of .saf and the record in .sah is updated with the new offset & length.
Quote:
|
So now im making two file data.gdh -> data.sah and data.gdf -> data.saf and well the only differents really is kind of the way the data.sah is structured and that the whole file is encrypted.
|
I definitively failed to get the point !...
If the purpose was to read the files used by a valid client and to generate files still valid for a client, use the structure above; if the point is to produce random data, you can indeed encipher the files with an unknown key or easier XOR the whole file with the current CPU temperature.
Cheers.
![[REQUEST]Source code for a data.sah/saf reader](https://www.elitepvpers.com/forum/iconimages/shaiya-private-server/request-source-code-data-sah-saf-reader_ltr.gif){kind=small}
![[DaE]Asew is offline](images/elitepvpers/statusicon/user_offline.gif){kind=small}
