No support for LUA extraction

[mechpaul]

I'm currently working on my own python unpacker and my program crashed when reading a certain file. I wanted to collaborate with you on my findings since I see your unpacker doesn't support it, really.

I would write this myself, but it would require an overhaul in some areas, so instead I'll just tell you how to do it.

GMS/Etc.wz/Script/BattleScene.lua

This entire file looks like: 01 80 6C 10 01 00

A few interesting things to notes:

1. 99.99% of the time, you're extracting a 0x73 as the first byte to extract a Property. However, this time the first byte is 0x01. The 0x01 implies a reference to a previous string, but there are no previous strings (as it's the first byte). Finally, a 0x01 backreference should be followed by a signed 32 bit integer, but this one is followed by a PackedInt. These issues will cause a parser to fail.

2. The is a string which must be decrypted using only the KMS AES stream (IV = [B9 7D 63 E9]). Do not use the ASCII traditional (0xAA + i) over the KMS stream. You use only the KMS AES stream to decrypt it. The decryption churns out a LUA file which has Latin and Japanese text. These LUA files break a lot of parsers because they assume that the same AESIV will be used everywhere in the file, and that is no longer the case.

I have some logic which you can use to work with such files that won't cause string errors:

• If the filePath ends in .lua, extract this 0x01 file type specially in whatever dumpString function you have by checking for the .lua file extension there.
• If there's a 0x01 back-reference but it's the first byte of the file, use the alternate logic for parsing a 0x01 byte. This works best if you have access to a binarystream.peek() function

Finally, you can see a thread at RageZone where they discuss these files. Code snippets are provided: https://forum.ragezone.com/f941/wzimage-nodes-1115819/

[lastbattle]

staging branch, doing a bit more testing right now. https://github.com/lastbattle/Harepacker-resurrected/commit/211a745ce9f3b4fcdc4f26146e2297cec63cd597 https://github.com/lastbattle/Harepacker-resurrected/commit/49c11bf58e11b99eedbe5dbf3f227d7058aa96c2

Fixed that, do test it for me! As I'm only working with v188 GMS (lots of issue doing a full dump on the latest version of GMS still)

Update: I think I broke the loading of some .wz in the midst of that, brb fixed. https://github.com/lastbattle/Harepacker-resurrected/commit/7a8de082f0dbf1fc66a98071347fa9d4e423a618

[gilmatok]

Since when does GMS have Lua files inside the WZ files?

[lastbattle]

Since when does GMS have Lua files inside the WZ files?

No idea until this, it seems that the same .lua file found on GMS is missing in other localisations of MapleStory.

I am using v188 as a reference.

@mechpaul try pulling the latest commit at the staging branch, just tested and it dumps XMLs Etc.wz fine.

[mechpaul]

Haven't tested the dumping, but I have tested the viewing. Working fine for me. Great work.

[lastbattle]

I will close this for now, feel free to ping me if you have any other issue 😉