-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No support for LUA extraction #24
Comments
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. |
Haven't tested the dumping, but I have tested the viewing. Working fine for me. Great work. |
I will close this for now, feel free to ping me if you have any other issue 😉 |
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:
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.
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:
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/
The text was updated successfully, but these errors were encountered: