Since update 188 (current stage is 214) the european clients use some tailored sdata files.
Their goal is to provide sentences (name, description, and so on) in French, German, Italian, Polish and Turkish.
To do so, a folder "BinarySData" contains several
* xxxData.sdata
that comes with
xxxText_FRC.sdata, xxxText_GER.sdata, xxxText_ITA.sdata, xxxText_POL.sdata & xxxText_TUR.sdata
the first are ciphered with SEED cipher, the Text are in plain.
Quote:
|
The encryption is the same, the file format isn't.
|
actually, both are different.
the SEED key is the same, but the header of the ciphered file is (a bit) different:
for classic files, it is:
Code:
#pragma pack(push, 1)
struct sdata_header {
char signature[40];
ulong checksum;
ulong dataSize;
char padding[16];
};
#pragma pack(pop)
where the "signature" is "0001CBCEBC5B2784D3FC9A2A9DB84D1C3FEB6E99"
the 'dataSize' field contains the length of the plain data (because the SEED cipher works with 128-bits block, up to 15 padding bytes can be present at the end of the data in order to obtain a block whose length is multiple of 16 before encrypting it).
the 'padding' bytes contains 16 x 00s
with these new DBxxxData.sdata files, the header seems to be:
Code:
#pragma pack(push, 1)
struct sdata_header {
char signature[40];
ulong nullInt32; // set to 00
ulong checksum;
ulong dataSize;
char padding[12];
};
#pragma pack(pop)
since the size of plain data is not at the same location, some (all?) of the tools used to decrypt the sdata files will fail to process.
Once the decryption is fixed, the files don't directly give some new clients files (I mainly check the "DBItemData.sdata file so far).
Instead they contain a kind of database definition (hmm isn't their names DBxxx ....), for instance, the DBItemData file reads as: (dump)
Code:
..i.t.e.m.t.y.p.e..i.t.e.m.t.y.p.e.i.d..i.m.a.g.e..i.c.o.n..l.e.v.e.l..c.o.u.n.t.r.y..a.t.t.a.c.k.f.i.g.h.t.e.r..d.e.f.e.n.s.e.f
.i.g.h.t.e.r..p.a.t.r.o.l.r.o.g.u.e..s.h.o.o.t.r.o.g.u.e..a.t.t.a.c.k.m.a.g.e..d.e.f.e.n.s.e.m.a.g.e..g.r.o.w..s.t.r..d.e.x..r.e
.c..i.n.t..w.i.s..l.u.c..v.g..o.g..i.g..r.a.n.g.e..a.t.t.a.c.k.t.i.m.e..a.t.t.r.i.b..s.p.e.c.i.a.l..s.l.o.t..q.u.a.l.i.t.y..e.f.
f.e.c.t.1..e.f.f.e.c.t.2..e.f.f.e.c.t.3..e.f.f.e.c.t.4..c.o.n.s.t.h.p..c.o.n.s.t.s.p..c.o.n.s.t.m.p..c.o.n.s.t.s.t.r..c.o.n.s.t.
d.e.x..c.o.n.s.t.r.e.c..c.o.n.s.t.i.n.t..c.o.n.s.t.w.i.s..c.o.n.s.t.l.u.c..s.p.e.e.d..e.x.p..b.u.y..s.e.l.l..g.r.a.d.e..d.r.o.p.
.s.e.r.v.e.r..c.o.u.n.t..d.u.r.a.t.i.o.n..e.x.t.d.u.r.a.t.i.o.n..s.e.c.o.p.t.i.o.n..o.p.t.i.o.n.r.a.t.e..b.u.y.m.e.t.h.o.d..m.a.
x.l.e.v.e.l..w.e.a.p.o.n.p.a.r.t..d.y.e.i.n.g.t.y.p.e..a.r.g.3..a.r.g.4..u.s.e.c.o.n.t.y.p.e..u.s.e.c.o.n.v.a.r..m.o.n.e.y.t.y.p
.e..i.t.e.m.s.k.i.l.l..i.t.e.m.u.p.g.r.a.d.e..a.r.g.1.0..g.e.n.e.c.o.u.n.t..a.r.g.1.2..s.p.e.l.l.b.o.o.k.e.x.p..s.p.e.l.l.b.o.o.
k.d.u.r.a.b.i.l.i.t.y..b........................................................................................................
..........................................Óa......................................................................°.............
all these labels look like the name of the columns of the item table, they are encoded as unicode (nothing in the client files is in unicode),
they are length-prefixed but that length is Big Endian encoded (and not little endian as 100% of the client data) Edit: the lengths are coded on 1 byte.
so far, I see two possible explanations:
- only the xxxxText.sdata files are used (together with the classical items.sdata) to provide i18n'ed captions.
- or, the client uses a internal "BD reader" (instead of the old sdata parser) to recover each items; the label are then added once read from the right text file.
both possibilities offer opportunities to all of us, let just imagine the reading of the definition of the monsters, all their attacks included ...
![[Euphoria Dev Team Release] Shaiya Data File Tool v2](https://www.elitepvpers.com/forum/iconimages/shaiya-pserver-guides-releases/euphoria-dev-team-release-shaiya-data-file-tool-v2_ltr.gif){kind=small}
???
imgur.com ! lol 
