you got so close! if you compared the values you wrote out against the ascii code for each letter ('A' == 0x41) then you might have caught on to the fact the values follow a simple pattern: 'A' (ascii 41) xor E2 == A3 'B' (ascii 42) xor E1 == A3 here is a bms script which can convert the nkr files t...

i downloaded a version of pandemonium and the charles.exe program has the 'nikkiface' and 'goonking' pkg offsets and data sizes hardcoded into them. edit the bitmap data (24-bit at least) is converted to 16-bit: uccc ccbb bbba aaaa ^ unused a = byte 1 b = byte 2 c = byte 3 a bit of bit-shifting can ...

edit Links to the new PMANG open-beta!

http://file.nowcdn.co.kr/down/NeowizGam ... 070418.exe
http://file.nowcdn.co.kr/down/NeowizGam ... 70418_1.7Z

so after nearly a month of idle progress, i've got something that has dumped the filesystem for me. i've had to think about to how to package it for XeNTaX, so I'm using aluigi's self-described 'lame patcher' - http://aluigi.org/mytoolz.htm#lpatch you need to read the instructions, and make sure you...

is this the same format used in combat arms??

tiny status update, but I will find time to work on the new clients.

only the initial scrambling has changed (same filelist formats, compression algos)

if you skip the blank data (~1024 bytes) your image shifts into view again
also, http://honyaku-subs.ru/forums/viewtopic.php?f=17&t=213

this is a KLF file which seems to contain KLP files. KLP files contain a small chunk of compressed data and a footer, which looks like it contains JPEG data. here is a quick n dirty http://aluigi.org/quickbms.htm script to dump this JPEG footer data: # script to dump tail data from KPF files idstrin...

the filenames are stored in a binary tree, which i didn't bother writing up for quickbms

instead i wrote up a c version, attached, which dumps with filenames source included

it does look like your script has been compiled down to bytecode which means you will never get a full conversion back to your sourcecode. and looking at the complexity of the asc language from your sample, it would indeed be very demanding to reverse it back into a human-readable state. not for me :]

i tried to automate this a little w a little luck: /stallage/stallkeeper_baitan/stallkeeper_baitan01.kfm /npc_pk/npc_pk.kfm /test_npc/daiji01.kf after the 4 character bytes is an offset from the name pointer which continues the string - but these 8 byte structures are themselves in some sort of orde...

this is a standard zip format with a custom comment field for the raw MD5 hash of the file.

when you repack the zip you need to add the comment field:
followed by the 16-byte md5 hash

i'm not sure if any zip programs allow you to do this automatically though

not going any further but the parts (unordered - ignore the filenames) can be read like: goto -4 get PNUM long get POS asize math TMP = PNUM math TMP *= 13 math TMP += 4 math POS -= TMP goto POS for i = 0 < PNUM # 13 byte header getdstring MISC 5 # options? get PNTR long get SIZE long string NAME p=...

file not found