$ file -kz *
ActionObject.dat: data
AddDefine.dat: data
Addition.dat: data
Addition.dat.zip: empty
Ancestor.dat: data
Appearance.dat: data
AtkTypeData.dat: data
Augeskill.dat: data
BanNick.dat: data
BattleSound.dat: data
bookdata1.rbf: data
ChatColor.dat: data
ChatCommand.dat: data
ChatTextInfo.dat: data
Color.dat: data
DyeingColor.dat: data
effectData.dat: data
EmoteFilterData.dat: data
EtcCommand.dat: data
Exp.dat: data
GameStringTable.dat: data
Help.dat: data
HelpEvent.dat: data
item.dat: data
MapInfo.dat: data
MapItemSkill.dat: DBase 3 data file with memo(s) (1247503206 records)
MapObject.dat: data
MapToolTip.dat: data
Npc.dat: data
NpcEvent.dat: data
NpcLocation.dat: data
NpcSupplyMenu.dat: data
QuestData.dat: data
QuestStepData.dat: data
ResourceName.dat: data
ScenarioData.dat: data
ScenarioStepData.dat: data
SkillAniSeq.dat: data
skill.dat: data
SlangFilterData.dat: data
SoundInfo.dat: data
statusbywlv.dat: data
supply.dat: data
UIStringTable.dat: data
WeaponAddName.dat: data
WeaponAddNameList.dat: data
Name:
Anonymous2007-05-25 2:34 ID:41FfJ4Tp
Are they from some corean mmorpg?
Name:
Anonymous2007-05-25 3:25 ID:OdQsVsuP
You cant touch .dat file if you aintt SANDCORE PROGRAMMER
Name:
Anonymous2007-05-25 8:29 ID:qG+nhJco
Looks compressed. Upload the executable that loads them.
Comparing the files side by side in a hex editor indicates that many of the bytes remain the same in all files. This would indicate to me that some sort of XOR-based algorithm is in place and those sections that are the same will largely be 00s.
How to determine the XOR key? Well, first it is useful to determine how large it is - does it have periodicity? Picking a couple of bytes from the parts of the files that are largely the same and searching for it again in that file shows that the pattern repeats itself every 662 (decimal) bytes.
Next, I picked what looked like a relatively sparse file (i.e. when decrypted will be mostly zeroes) and ran a program on it to count the frequencies at which different bytes appear in the repeated sections of 662 bytes.
int main(int argc, char* argv[])
{
unsigned char buffer[662];
int frequencies[662*256] = {0};
int bytes_read = 0;
int i, j;
int highest_freq, highest_pos, tmp;
_setmode(_fileno(stdin), _O_BINARY);
do {
bytes_read = fread(buffer, 1, 662, stdin);
for (i=0;i<bytes_read;i++)
{
frequencies[i*256+(int)(buffer[i])]++;
}
} while(bytes_read > 0 || !feof(stdin));
One for %a in (*.dat) do datdec.exe < %a > %a.dec later and they're all decrypted. Some visual checking in the hex editor shows that it was successful.
They're not XLS files though. The data is stored in a custom format but the records are fixed size. All text appears to be Unicode and much of it is in Korean.
Name:
Anonymous2007-05-25 15:04 ID:me+NyHor
Oh yeah, also - running Sysinternals' STRINGS utility on the decrypted files gives some interesting snippets:
In UIStringTable: Copyright 2006 Gravity Co., Ltd. & Lee Myoungjin. All Rights Reserved.
In BanNick: Jormungand, Heimdall, Nidhogg, Hrungnir, ... (names from Norse mythology)
A couple of years I was surprised to discover that HSBC's business banking software stores its private data in XOR-encrypted DBF files. The key was only 14 bytes long.
Name:
Anonymous2007-05-25 16:34 ID:upVoGZUy
>>21 is actually right, though. The problem with XOR encryption is not strength but the management of keys.
Are you just doing an English translation of these data files, or actually creating one from scratch?
Name:
Anonymous2007-07-10 17:15 ID:5RHaFZBu
I simply want to translate all the korean text in the client from korean to english (I'm fluent in both languages) so that english speakers can also play this game. I have done some work translating NPC dialogs so far, but the .dats I don't know how to unpack and then repack (so that they work with the game)