Fairyland Online (Lager Network Technologies) - .adf resource format

Hello everyone,

I’m looking for some help with deciphering/extracting the ADF files from the game Fairyland Online. I’ve attached some files for anyone who would like to investigate them, as well as the game executable in case it is needed for analysis.

The specific file I’m interested in is mouse.adf, as I believe it may contain the game’s mouse cursors.

Any help in figuring out the structure of these files or extracting their contents would be greatly appreciated.

Thank you very much in advance to everyone who takes the time to help!

----

Extract the mouse cursor sprites from the client of "Fairyland Online" (aka

King of Kings 3 engine, developer: Lager Network Technologies). The cursors

live in a loose file: data\mouse.adf

I've fully reverse engineered the sibling container format (.lpq, the big

multi-entry archives) by disassembling Fairyland.exe with Ghidra, but the

single-resource .adf format is resisting the last step (LZO decompression of

the pixel payload). Posting my findings in case someone here has already

documented this engine, or can spot what I'm missing.

Tools used: Ghidra 12.1.3 (headless, scripted in Java), objdump, pefile,

capstone, liblzo2 via Python ctypes, python-lzo.

PART 1 - .lpq FORMAT (SOLVED, for reference / context)

--------------------------------------------------------

Magic: "LPQ\x1a" (dword 0x1A51504C) + dword 0x20 (constant)

Header struct at file offset 0x08, 40 (0x28) bytes:

struct+0x00 (file 0x08): total file size

struct+0x04 (file 0x0c): constant 0x1000000

struct+0x08 (file 0x10): approx. total decompressed size

struct+0x0c (file 0x14): flags (bit 0x02 = directory is XOR-"encrypted")

struct+0x10 (file 0x18): seek_pos -> file offset where the directory table

(ring buffer) starts

struct+0x14 (file 0x1c): number of entries to read in this pass

struct+0x18 (file 0x20): read position within the ring buffer

struct+0x24 (file 0x2c): ring buffer capacity (total slots)

Directory table: `capacity` slots of 28 (0x1c) bytes each, located at

`seek_pos`. If the "encrypted" flag is set, the whole block that gets read

(count*28 bytes) is passed through this XOR-chain cipher (found by

decompiling FUN_0059dcc0 in Fairyland.exe):

prev = 0x55555555 # seed / IV

for each little-endian dword D in the block, in order:

original = D # the still-"encrypted" value

D = original XOR prev

prev = original # chains on the ENCRYPTED value,

# not the decrypted one

Each decrypted directory entry (7 dwords / 28 bytes):

[0] absolute file offset of the compressed resource

[1] compressed size

[2] decompressed size

[3] flag (=1 for valid entries)

[4] small value, purpose unknown (not needed for extraction)

[5],[6] constants copied from the header, ignore

Payload at [0..1]: standard **LZO1X** stream (lzo1x_decompress_safe from

liblzo2 works out of the box, no extra transform needed). Decompresses

directly to a completely standard Windows BMP (BITMAPINFOHEADER etc, nothing

proprietary in the pixel data itself).

There's usually a special entry called "(listfile)" (real filenames,

newline-separated) whose compressed data sits immediately BEFORE seek_pos.

Verified against real files: 207/207 entries extracted correctly from a UI

archive, and 10991/10992 from a much bigger model archive (the 1 failure was

the expected "(patchlist)" metadata entry, not a real asset).

PART 2 - .adf FORMAT (WHERE I'M STUCK)

----------------------------------------

These are small, standalone, single-or-few-resource files (as opposed to the

big multi-thousand-entry .lpq archives). Confirmed samples analyzed:

nui_char_05.adf, mouse.adf, nfui001_00.adf, nsys004.adf, nsys014.adf,

nsys032.adf.

Magic: "FGF300" (6 bytes), then 2 more bytes.

Right after the magic, there's a run of bytes that LOOKS like padding

(0x55 55 55 55 ...) up to file offset 0x46. This is NOT raw padding - I

confirmed it decrypts cleanly to all-zero bytes using the exact same

XOR-chain cipher as the .lpq directory (seed 0x55555555, dword-aligned,

chained on the previous *encrypted* dword, running continuously from file

offset 0). This is a strong indicator the whole file uses the same cipher

primitive as .lpq.

At file offset 0x46 (uint16): a record count (1 for single-image files, 3

for nui_char_05.adf which has 3 sub-images, etc).

Following that: one variable-length record per image. In every sample, the

record contains (readable in RAW/plaintext form, i.e. NOT XOR-encrypted -

decrypting this region actually destroys it):

- a constant 4-byte marker: 4c 0f 1d 70

- a "dimension-ish" field (varies)

- alpha/flag dword: ff 00 00 00

- COMPRESSED SIZE (dword)

- ASCII marker "LrtJ" (4c 72 74 4a)

- DECOMPRESSED SIZE (dword)

- flag dword: 01 00 00 00

Example values (comp_size / decomp_size, both plausible and self-consistent

with file size):

nfui001_00.adf: 3315 / 3084 (single 2407-byte file)

nsys014.adf: 3825 / 3598

nsys032.adf: 7140 / 6939

nsys004.adf: 15045 / 14906 (first of 3 records)

Right after the record, the payload begins with one byte followed

immediately by the ASCII bytes "BM" (Windows bitmap signature) - e.g.

`f9 42 4d ...`. This strongly suggests the leading byte is meant to be

interpreted as the LZO1X literal-run opcode (0xf9 = 249; per LZO1X's

first-command rule, byte-17=232, i.e. "copy the next 232 bytes literally") -

and indeed, "BM" plus a nice chunk of following bytes decode perfectly clean

this way.

THE PROBLEM:

Feeding this straight into lzo1x_decompress_safe (liblzo2), with or without

re-applying the XOR-chain to the payload itself, always fails with

LZO_E_LOOKBEHIND_OVERRUN (-6) shortly after that initial literal run - in

two different files it fails at EXACTLY the same output length (235 bytes),

which smells like the 232-byte literal-run "success" is a coincidence

(copying raw bytes verbatim doesn't validate anything) rather than proof the

stream is genuinely stock LZO1X from that point on.

Byte right after the literal run in nsys014.adf is 0x73, which under

standard LZO1X opcode rules (0x40-0x7F range) should decode as a perfectly

valid short match (length 5, small distance) - yet the safe decompressor

rejects it as looking behind the start of the output buffer. I don't know if

that's because:

a) it's genuinely not LZO1X past the literal run (different variant, or

scrambled/substituted somehow), or

b) there's some other per-chunk transform I'm missing, or

c) my offset/alignment for where the "true" stream starts is still off by

a few bytes despite the clean "BM" landmark.

Static tracing dead end: I found the file-open helper used by the .lpq

loader (a wrapper resembling CreateFileA, at 0x005953f0 in this exe build)

and enumerated ALL its callers - there are exactly two: the confirmed .lpq

loader (FUN_0059e1d0), and one more (FUN_0059de50) which turned out to be a

*generic* container loader that hard-checks for magic "LPQ\x1a" - so it's

not what parses "FGF300" files despite superficially similar structure.

Tracing outward from the "data\\mouse.adf" string literal itself leads into

a huge, generic startup/init function (FUN_004024b0) that fans out into

hundreds of subsystems, impractical to fully trace via static xref-chasing

alone without an interactive decompiler session.

WHAT WOULD HELP

----------------

- Anyone who has already documented Lager Network Technologies' .adf format

(King of Kings 3 uses the same engine/format family, so KoK3 tooling /

threads would likely apply directly).

- A sanity check on whether the payload after the small record header really

is LZO1X, or something else (custom LZ variant / substitution box applied

before or after LZO / etc).

- Anyone comfortable doing live/dynamic analysis (x64dbg or similar) who

could set a breakpoint on the file read for data\\mouse.adf and step

through to the real decompression call - that would settle this in

minutes versus my current blind static guessing.

Happy to share the exe, sample .adf files, my Ghidra scripts, or the Python

XOR-chain implementation on request. Thanks in advance for any pointers.

APPENDIX - XOR-chain reference implementation (Python)

---------------------------------------------------------

def dexor_chain(data: bytes, seed: int = 0x55555555) -> bytes:

import struct

n = len(data) // 4

out = bytearray(data[:n * 4])

prev = seed

for i in range(n):

cur = struct.unpack_from("<I", out, i * 4)[0]

dec = cur ^ prev

struct.pack_into("<I", out, i * 4, dec)

prev = cur # chains on the RAW/encrypted dword

return bytes(out)

(Confirmed correct against the .lpq directory table and against the .adf

zero-padding region; it's the .adf payload's exact transform - if any -

that's still unresolved.)

Fairyland adf files.zip