You could compile a test file with a standard Lua 5.2 build and look at the header. 1B 4C 75 61 52 00 01 04 08 04 08 00 19 93 0D 0A 1A 0A 1B 4C 75 61 is the version-agnostic "magic number" for compiled Lua. 52 indicates Lua 5.2. 00 is format which is always 0 for standard Lua implementations 01 is the endianness byte (0 or 1) 04 is int size 08 is size_t size 04 is instruction size 08 is Lua number size (indicating 64-bit double precision floating point or 64-bit long integer depending on integrality...
version string
Fix for broken upvalue names in stripped chunks
I tried applying the changes described here: https://sourceforge.net/p/unluac/discussion/general/thread/3b18b88f8e/?limit=25#effa and then rebuilt unluac, but it still doesn’t work. java -jar unluac-custom.jar --opmap opmap.txt script1.luac Exception in thread "main" java.lang.IllegalStateException: The input chunk reports an invalid code for lua number integrality: 4 at unluac.parse.LHeaderType.parse_number_integrality(LHeaderType.java:193) at unluac.parse.LHeaderType52.parse_main(LHeaderType.java:383)...
I tried applying the changes described here: https://sourceforge.net/p/unluac/discussion/general/thread/3b18b88f8e/?limit=25#effa and then rebuilt unluac, but it still doesn’t work. java -jar unluac-custom.jar --opmap opmap.txt script1.luac Exception in thread "main" java.lang.IllegalStateException: The input chunk reports an invalid code for lua number integrality: 4 at unluac.parse.LHeaderType.parse_number_integrality(LHeaderType.java:193) at unluac.parse.LHeaderType52.parse_main(LHeaderType.java:383)...
My question is, I see you always mentioning things that need fixing, like 'opmap', but can I debug to find the solution myself? I'm just looking at the files with some combination of a hex editor, unluac disassembler, and unluac in a Java debugger. This is a parsing failure (failing in Main.file_to_function before Decompiler.print or whatever), so there's some concrete difference between the file and a "correct" Lua file. If it's close enough, it's just guesswork/inference. You were on the right...
My question is, I see you always mentioning things that need fixing, like 'opmap', but can I debug to find the solution myself? I'm just looking at the files with some combination of a hex editor, unluac disassembler, and unluac in a Java debugger. This is a parsing failure (failing in Main.file_to_function before Decompiler.print or whatever), so there's some concrete difference between the file and a "correct" Lua file. If it's close enough, it's just guesswork/inference. You were on the right...
I'm using the latest unluac (2025_10_19) Here is the output: Exception in thread "main" java.lang.IllegalStateException: The input chunk reports an invalid code for lua number integrality: 4 at unluac.parse.LHeaderType.parse_number_integrality(LHeaderType.java:193) at unluac.parse.LHeaderType52.parse_main(LHeaderType.java:383) at unluac.parse.LHeaderType.parse(LHeaderType.java:67) at unluac.parse.BHeader.<init>(BHeader.java:98) at unluac.Main.file_to_function(Main.java:186) at unluac.Main.main(Main.java:93)...
I'm using the latest unluac (2025_10_19) Here is the output: Exception in thread "main" java.lang.IllegalStateException: The input chunk reports an invalid code for lua number integrality: 4 at unluac.parse.LHeaderType.parse_number_integrality(LHeaderType.java:193) at unluac.parse.LHeaderType52.parse_main(LHeaderType.java:383) at unluac.parse.LHeaderType.parse(LHeaderType.java:67) at unluac.parse.BHeader.<init>(BHeader.java:98) at unluac.Main.file_to_function(Main.java:186) at unluac.Main.main(Main.java:93)...
I'm using the latest unluac (2025_10_19) Here is the output: Exception in thread "main" java.lang.IllegalStateException: The input chunk reports an invalid code for lua number integrality: 4 at unluac.parse.LHeaderType.parse_number_integrality(LHeaderType.java:193) at unluac.parse.LHeaderType52.parse_main(LHeaderType.java:383) at unluac.parse.LHeaderType.parse(LHeaderType.java:67) at unluac.parse.BHeader.<init>(BHeader.java:98) at unluac.Main.file_to_function(Main.java:186) at unluac.Main.main(Main.java:93)...
There's an extra byte in the header. Not sure why, could be for non-interoperability / indicating other non-standard behavior, etc. If you remove it, unluac can parse. Without more context hard to give specific advice, maybe remove it with a hex editor or write a preprocessing script or something. Your file starts like this: 1B 4C 75 61 80 54 If you remove the 0x80, then it will work: 1B 4C 75 61 54 But also, the file is using a non-standard opmap (--opmap). I decoded the ops used in this file for...
i tried old and new version but still not work Exception in thread "main" java.lang.IllegalStateException at unluac.Version.<init>(Version.java:312) at unluac.Version.getVersion(Version.java:18) at unluac.parse.BHeader.<init>(BHeader.java:92) at unluac.Main.file_to_function(Main.java:186) at unluac.Main.main(Main.java:93)
We got it, Thank get the source and rebuild by the opmap
I try to decompile use old and new version don't work, how can i do?
Currently, you can --disassemble and the first line should be .version 5.1. Probably at some point I will add comments to the decompilation with certain metadata. Gotos from decompiling versions before 5.2 happen as a fallback when working with debug-stripped code. As unluac doesn't properly support these yet, its poor understanding of which registers are temporary can lead to situations where decompiling without gotos is impossible -- gotos are used as an alternative to failure (since it might still...
Hi there. When I decompile a file that is lua 5.1 it ends up with goto functions which came in 5.2 - How can I tell the version the decompiled code should have?
Hello, I found out that unluac didn't feature a way to perform a bulk decompilation and keep the folder structure to then mirror it in the output folder, so i asked ChatGPT to make me a batch file and with some tweaking, it worked quite well so i'm sharing it, it may help many people. Tested on a game that used compiled chunk as .lua and it did decompile 4k scripts in a few minutes with a HDD, the batch file is commented and only need minimal change. It is spawning an instance of unluac for each...
Hello, I found out that unluac didn't feature a way to perform a bulk decompilation and keep the folder structure, so i asked ChatGPT to make me a batch file and with some tweaking, it worked quite well so i'm sharing it, it may help many people. Tested on a game that used compiled chunk as .lua and it did decompiled 4k scripts in a few minutes with a HDD, the batch file is commented and only need minimal change. It is spawning an instance of unluac for each .lua files found, I found out that it...
Yeah, unluac doesn't support this case. It should be easy to add it. I might make it an option flag because I think there are ambiguous cases (vararg, no params, 1 upvalue is the environment table for 5.2 plus). There's no canonical way to output it, but I guess I'll probably make an outer chunk that returns an anonymous function and declares any necessary upvalues.
Hi tehtmi, I’ve been experimenting with dumping and decompiling Lua functions, and I had a question about parameter recovery in unluac. Im dumping the bytecode of functions with following code: local function dump_func(func) if type(func) ~= "function" then return end local func_id = tostring(func):match("function: (.+)") local bytecode = string.dump(func) local filename = func_id .. ".luac" local file = assert(io.open("temp/" .. filename, "wb")) file:write(bytecode) file:close() return filename...
Also run tests in Lua 5.4.8
Heuristic to avoid backward jump as 'always loop' if it introduces more needed gotos
Refinements of if/goto handling for 5.4.3+ (Lua changeset ab1aca94e83d2eff1605ea1854df023c814cef21)
There were some other related issues. Should be fixed with the newer version (2025_10_20) With the Lua 5.4.8 compiler, some of the goto tests also failed, seems like an unrelated issue, but I haven't tried to look for the compiler change yet. Maybe not such an impediment to decompilation (doesn't crash, and is maybe equivalent code, just not round-trip-identical).
version string
Fix remaining variable scope issues from 5.4.5+
Some refactoring of close/scope handling / fix repeat break target with jmp-style close
Probably fixed in the new version. This was broken due to the fix for this bug in Lua 5.4.4 (and earlier Lua 5.4 versions). Your code is compiled with Lua 5.4.5+. Unluac may still need some more testing with up-to-date Lua 5.4, but I have fixed the immediate problem (unluac failing fast due to unexpected variable scope in debug info).
Fix for Lua 5.4.5+, generic for implicit variable scope doesn't include close
Hello tehtmi, I'm currently working on a game that uses Lua 5.4. Some files are decompiled, but there are also a lot of files that encounter the given and expected error. Do you have a solution for this type of problem ? given: 10 16 expected: 10 15 Exception in thread "main" java.lang.IllegalStateException at unluac.decompile.Registers.setInternalLoopVariable(Registers.java:167) at unluac.decompile.block.TForBlock.handleVariableDeclarations(TForBlock.java:118) at unluac.decompile.ControlFlowHandler.find_fixed_blocks(ControlFlowHandler.java:582)...
can we contact with what'sApp or email pls?
Unluac can be used if you produce a valid standard Lua bytecode file. If it's non-standard you might be able to normalize it by preprocessing or modify unluac to accept that format (or using built-in unluac options to deal with a small number of common non-standard variations). If the bytecode instructions themselves have been obfuscated, unluac's compiler is unlikely to work well, as it is designed to be used only on the output of the PUC-Rio Lua compiler. In that case, you could still use unluac's...
this is original file
i have obfuscated lua file, then i tried to deobf it and got vm code. Can i somehow get it readable with unluac? Or it's impossible? Want to somehow change private values to patch addon for new version (author not support addon anymore)
Sorry, should be fixed by changeset b86466bd1b73 This is just the fallback when upvalue name resolution fails. There was some refactoring to track certain name info earlier related to another bug, and it broke the way things were handled for 5.0/5.1 stripped chunks since they store their upvalue info in a weird place.
Fix new issue processing upvalue names in 5.0/5.1 stripped chunks
A little more validation; pending refactor
Initial setup for useful decompiler errors... (opcode validation)
Hi, I came across a problem that was seemingly fixed back in 2021: https://sourceforge.net/p/unluac/discussion/general/thread/f1b200b0a1/?limit=25#fb14 I have a script that defines functions such as math.max, math.min, etc. at the top as locals, but when they are called in functions later, they are incorrectly decompiled as "UPVALUEx". This only happens on the newest version I compiled, when I tried the 2021_03_19b version or even the latest 2023 version in unstable, it works as it should (I was...
Local variable information is stripped, but line numbers are not which confuses unluac's heuristic for detecting debug info. Use --nodebug(and there is no debug info, natch).
Hi, i tried to decompile this lua file but got this error, other tool https://luadec.metaworm.site/ works, so i assume opcodes are standard Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because "upvalue.name" is null at unluac.decompile.expression.TableReference.isUpvalueOf(TableReference.java:40) at unluac.decompile.expression.TableReference.print(TableReference.java:52) at unluac.decompile.expression.FunctionCall.print(FunctionCall.java:80) at...
Hi everyone, I'm happy to share a small project I've been working on: an Android app that brings unluac to mobile devices. The app's goal is simple: to make it easier to decompile Lua scripts on the go, using your phone's storage. This is a straightforward port, focusing on core functionality. You can select a Lua file from your device and get the decompiled output quickly. The project is open source, and you can find the repository here:only52607/unluac-mobile Any feedback or suggestions are welcome!...
Thank you very much it work
Looks the same as this. Non-standard op encoding. You can use --opmap and pass this opmap file: .op 0 band .op 1 bxor .op 2 bor .op 3 shr .op 4 shl .op 5 bnot .op 6 unm .op 7 len .op 8 not .op 9 jmp .op 10 concat .op 11 lt .op 12 eq .op 13 test .op 14 le .op 15 call .op 16 testset .op 17 return .op 18 tailcall .op 19 forprep .op 20 forloop .op 21 tforcall .op 22 tforloop .op 23 closure .op 24 setlist .op 25 extraarg .op 26 loadk .op 27 move .op 28 loadbool .op 30 getupval .op 31 loadnil .op 32 gettable...
Hi, i try to decompile this lua 5.3 file but got this error Exception in thread "main" java.lang.IllegalStateException at unluac.decompile.Op.jumpField(Op.java:217) at unluac.decompile.Code.target(Code.java:142) at unluac.decompile.ControlFlowHandler.process_condition(ControlFlowHandler.java:318) at unluac.decompile.ControlFlowHandler.find_branches(ControlFlowHandler.java:352) at unluac.decompile.ControlFlowHandler.process(ControlFlowHandler.java:118) at unluac.decompile.Decompiler.decompile(Decompiler.java:136)...
Thank you for the advice, I've finished the opcode mapping and you were right with your first suggestion, all opcodes that used RK were affected. Making Maxstack 300 has fixed the remaining problems and it all decompiles successfully. Thank you so much for your help.
Constant offset of RK constants in Lua 5.0, I would usually think this: https://sourceforge.net/p/unluac/discussion/general/thread/aa013ce7d8/?limit=25#f606 That would affect all RK constants (not all constants -- some don't use RK, like in loadk -- only parameters that can be either register or constant are RK). If it's specifically settable only, you might need to modify the main decoding switch statement in Decompiler.java (which might be sufficient), or if e.g. it's all RKB or something like...
Thank you very much for replying and for your help. --opmap together with --disassemble is really useful and working well to find the opcode remapping. If I may, could I ask another question? Unluac with disassemble is giving me this for settable: .constant k0 "r" .constant k1 "g" .constant k2 "b" .constant k3 "a" .line 16 newtable r4 0 0 .line 17 settable r4 k50 r0 ; k50 out of range .line 18 settable r4 k51 r1 ; k51 out of range .line 19 settable r4 k52 r2 ; k52 out of range .line 20 settable r4...
Thank you very much for replying and for your help. --opmap together with --disassemble is really useful and working well to find the opcode remapping. If I may, could I ask another question? Unluac with disassemble isgivine me this for settable: .constant k0 "r" .constant k1 "g" .constant k2 "b" .constant k3 "a" .line 16 newtable r4 0 0 .line 17 settable r4 k50 r0 ; k50 out of range .line 18 settable r4 k51 r1 ; k51 out of range .line 19 settable r4 k52 r2 ; k52 out of range .line 20 settable r4...
Thank you very much for replying and for your help. --opmap together with --disassemble is really useful and working well to find the opcode remapping. If I may, could I ask another question? Unluac with disassemble isgivine me this for settable: .constant k0 "r" .constant k1 "g" .constant k2 "b" .constant k3 "a" .line 16 newtable r4 0 0 .line 17 settable r4 k50 r0 ; k50 out of range .line 18 settable r4 k51 r1 ; k51 out of range .line 19 settable r4 k52 r2 ; k52 out of range .line 20 settable r4...
You can use an 'opmap' file with unluac's --opmap parameter to tell it how to interpret the opcodes. It is a text file with lines like .op 0 add .op 1 sub .op 7 mul You should be able to disassemble (--disassemble) even without the correct opmap. Sometimes I use an empty or partially filled opmap file so the disassembly will list the opcodes of unknown operations. If you have enough familiarity with Lua bytecode, it is generally possible to figure out which opcode encodes each operation. The more...
Hi, the tool cant decompile these lua 5.0 files. I suspect that the opcodes have been messed with. In {other cases} they {...} added dummy null opcodes as follows: {redacted} I really appreciate all the work you've done on this tool, its been really helpful. If you are able please could you have a look at these files and see if the opcodes have been shuffled or adjusted. Thank you. {files redacted}
Hi, the tool cant decompile these lua 5.0 files. I suspect that the opcodes have been messed with. In {other cases} they {...} added dummy null opcodes as follows: {redacted} I really appreciate all the work you've done on this tool, its been really helpful. If you are able please could you have a look at these files and see if the opcodes have been shuffled or adjusted. Thank you.
Hi, the tool cant decompile these lua 5.0 files. I suspect that the opcodes have been messed with. In {other} games by this developer they {...} added dummy null opcodes as follows: {redacted} I really appreciate all the work you've done on this tool, its been really helpful. If you are able please could you have a look at these files and see if the opcodes have been shuffled or adjusted. Thank you.
You can use an 'opmap' file with unluac's --opmap parameter to tell it how to interpret the opcodes. It is a text file with lines like .op 0 add .op 1 sub .op 7 mul You should be able to disassemble (--disassemble) even without the correct opmap. Sometimes I use an empty or partially filled opmap file so the disassembly will list the opcodes of unknown operations. If you have enough familiarity with Lua bytecode, it is generally possible to figure out which opcode encodes each operation. (I you like,...
Hi, the tool cant decompile these lua 5.0 files. I suspect that the opcodes have been messed with. In later games by this developer they switched to lua 5.1 and 5.2, there they added dummy null opcodes as follows: const char *const luaP_opnames[NUM_OPCODES+1] = { NULL, "MOVE", "LOADK", "LOADBOOL", "LOADNIL", "GETUPVAL", "GETGLOBAL", "GETTABLE", NULL, "SETGLOBAL", "SETUPVAL", "SETTABLE", "NEWTABLE", NULL, "SELF", NULL, "ADD", "SUB", "MUL", "DIV", "MOD", "POW", "UNM", "NOT", "LEN", "CONCAT", NULL,...
Hi, the tool cant decompile these lua 5 files. I suspect that the opcodes have been messed with. In later games by this developer they switched to lua 5.1 and 5.2, there they added dummy null opcodes as follows: const char *const luaP_opnames[NUM_OPCODES+1] = { NULL, "MOVE", "LOADK", "LOADBOOL", "LOADNIL", "GETUPVAL", "GETGLOBAL", "GETTABLE", NULL, "SETGLOBAL", "SETUPVAL", "SETTABLE", "NEWTABLE", NULL, "SELF", NULL, "ADD", "SUB", "MUL", "DIV", "MOD", "POW", "UNM", "NOT", "LEN", "CONCAT", NULL, "JMP",...
Tested with unluac_2023_12_24.jar and manually compiled snapshot from the latest Hg Code commit (bda008aa963b6bc4ce4bb289c9122c84480a4ff6). Minimal reproducible example. https://luac.nl/s/174cc3c013a77f25ab11700c6e9 for i = 1, 10 do local function f() local a = i end if a then break end end This code compiled by the official 64-bit luac compiler v5.4.3 produces the following error. > java -jar unluac_2023_12_24.jar output.luac given: 4 11 expected: 4 12 Exception in thread "main" java.lang.IllegalStateException...
Hi. I have also run into the same issue. This is not because it's encrypted, it's because it's a HavocScript, not a regular LuaC. https://ubm-twvideo01.s3.amazonaws.com/o1/vault/gdc2011/slides/Malcolm_Tyrrell_Programming_EfficientLuaScripting.pdf You will need a different decompiler. They're all over Github. Just look for HavocScript Decompiler.
Hi. I have also run into the same issue. This is not because it's encrypted, it's because it's a HavocScript, not a regular LuaC. You will need a different decompiler. They're all over Github. Just look for HavocScript Decompiler.
It looks encrypted which I can't/won't help with. I'm happy to comment on the Lua part. First 5 bytes are part of the normal Lua 5.4 header, then three bytes I don't recognize 30 01 01 (normal Lua 5.4 has a "format" byte here, always zero by default and always just one byte; purpose I believe is to cleanly prevent interoperability when changed). Then 25 bytes of what looks like the rest of the standard Lua 5.4 header (ending with 28 77 40). After that would be the header for the first main function...
I am getting the following error, when i try to decompile a file which is i think localization file. Exception in thread "main" java.lang.IllegalStateException: The input chunk reports a non-standard lua format: 48 at unluac.parse.LHeaderType.parse_format(LHeaderType.java:87) at unluac.parse.LHeaderType54.parse_main(LHeaderType.java:460) at unluac.parse.LHeaderType.parse(LHeaderType.java:67) at unluac.parse.BHeader.<init>(BHeader.java:98) at unluac.Main.file_to_function(Main.java:186) at unluac....
Thank it work :D
Use --rawstring. I also strongly suggest --output. By default unluac only uses ASCII as this is the least likely to cause issues with text IO streams or text editors. Lua strings can contain arbitrary binary data, and the Lua compiler will accept this raw data regardless of any text encoding -- a file may, if it chooses, mix and match between various text encodings and non-text binary data. By default unluac will escape everything -- this leads to a correct source file, but it can be less human-readable...
As the title suggests, some data gets transformed into different characters when I use unluac.jar. Is there any way to fix this? ★★★RandomFateMacro★★★ -> \226\152\133\226\152\133\226\152\133RandomFateMacro\226\152\133\226\152\133\226\152\133 CHR_衛星Bさん -> CHR_\229\174\157\231\174\177
Thanks bro, I cleaned my older java and installed it again and unluac worked perfectly. I really appreciate your work in lua decompilation. Thanks again for making such good decompiler.
You're not getting to the point of even running my code. I'm not doing anything special, just command line java -jar unluac.jar yourfile. I don't know of any reason why Java 17 wouldn't work -- I tried with the Java 19 I already had on my machine and it worked fine (and it also worked with the Java 1.8 I normally use for testing and which I compile against rather than a newer version for greater compatibility). I can't explain the behavior you're seeing, and I'm not sure there's anything much I can...
what do you mean did you decompiled this script if yes please can you tell how and what do I need to install. I use java 17.
Ah, this has nothing to do with the file. I think it is your Java version. I think you need Java 8+ (AKA java -version 1.8).
I tried unluac-vf but it also not work it gives error -- Exception in thread "main" java.lang.UnsupportedClassVersionError: unluac/Main : Unsupported major.minor version 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361)...
Thanks for the reply but I already tried newer version of unluac in unstable library but it didn't work. It gives same error as older one
Maybe you are using an old version of unluac. May as well use the latest from the Unstable folder (yes, it probably shouldn't be called that, sorry), that should be the default download anyway. Unluac works, but the files have debugging info stripped. Unluac isn't designed for these, so it will do its best, but the output is generally pretty verbose, and probably a little untrustworthy (and you won't get exactly the same thing back like you usually do with non-stripped files in unluac (modulo line...
Hi, I tried to decompile script of lua 5.0.3 decompiled using luac version 5.0.3. I used luadec, chunkspy and unluac. But for luadec some can decompiled but some are not I used luadec version 0.6. For chunkspy it can't decompile but it can only dissemble the script. Finally I tried unluac but header error occurs. Can someone help to decompile it. any help will be appreciated. thanks in advance. I attached some three scripts.
Okay, sorry for the delay. I didn't try to decode the strings/constants or other stuff, just what was needed for parsing, so I was missing context, so I'm not sure which math op is which -- these are just guesses (I used the order in the original opmap which is maybe plausible since it's not exactly mixed up). Also, I can't distinguish lt vs le without context. You may need to reshuffle these as needed (although unluac will still decompile if these things are wrong). There's also some missing ops...
Okay, sorry for the delay. I didn't try to decode the strings/constants or other stuff, just what was needed for parsing, so I was missing context, so I'm not sure which math op is which -- these are just guesses (I used the order in the original opmap which is maybe plausible since it's not exactly mixed up). Also, I can't distinguish lt vs le without context. You may need to reshuffle these as needed (although unluac will still decompile if these things are wrong). There's also a bit of other weird...
Thank you very much, I'll look into what you reccomended and see if it helps!
I will work on it. I've been sick the last couple of days, and haven't felt like I could concentrate on it. Just wanted to let you know I'm not ignoring you.
The local variable names simply aren't there. It is not a matter of unluac, you cannot get local variable names from this file. As you found, this "TEMP" error happens when unluac's heuristic for detecting debug-stripped files fails (here, as is usually the case, there is line number info but no variable info). As unluac doesn't use line number info anyway (except for this heuristic), you lose nothing by using --nodebug -- that is the best unluac can do. It's not great because unluac was not designed...
Hi, I have so called engine file that is used by other files in Lua 5.1 and I need to recompile it in 5.3.5 Lua. This file as far as I am aware was compiled by some user in trading community and shared with them. Also when I tried just to start this file, Lua gave an error that there's a bad header in precompiled chunk, not sure if this is connected to the error I'm getting. Anyway, when I try to decompile the file I immediately get this: Exception in thread "main" java.lang.IllegalStateException:...
I managed to decrypt xors on the Lua file, but was surprised that wasn't enough to decompile it properly. I'm not experienced with bytecode Lua reverse engineering, please help me with the opcodes if possible. I attached some other files to analyze. Thanks you very much for the infos!
It is a non-standard format the is encrypted/obfuscated. I think it is the same as this thread. My policy is to not break encryption, but I'll make some comments. The unluac parser will break from wrong list lengths or unknown constant/type enum mappings. These cause the issues for this file. It looks like there is a bug/inconsistency in where the transformation is applied which causes debug info for some functions to be encrypted and others not -- I think this is understood via a global encryption...
Hi, I tried decompile some lua files but got this error: Exception in thread "main" java.lang.RuntimeException: unmapped type code 33 at unluac.parse.LConstantType.parse(LConstantType.java:23) at unluac.parse.LConstantType.parse(LConstantType.java:1) at unluac.parse.BObjectType$1.run(BObjectType.java:48) at unluac.parse.BInteger.iterate(BInteger.java:117) at unluac.parse.BObjectType.parseList(BObjectType.java:44) at unluac.parse.BObjectType.parseList(BObjectType.java:39) at unluac.parse.BObjectType.parseList(BObjectType.java:19)...
Yes, you have non ASCII UTF-8 identifiers. The standard Lua compiler won't accept them, as it uses isalpha / isalnum which will use the standard C locale definition (which means just ASCII identifiers). You can compile your own Lua (5.1) compiler with a patch that will accept these identifiers. Not sure what the most elegant method is, but you can do a simple hack like editing llex.c to replace its usage of isalpha / isalnum with these implementations: static int patch_isalnum(int c) { return c >=...
Yes, you have non ASCII UTF-8 identifiers. The standard Lua compiler won't accept them, as it uses isalpha / isalnum which will use the standard C locale definition (which means just ASCII identifiers). You can compile your own Lua (5.1) compiler with a patch that will accept these identifiers. Not sure what the most elegant method is, but you can do a simple hack like editing llex.c to replace its usage of isalpha / isalnum with these implementations: static int patch_isalnum(int c) { return c >=...
Decompiling works fine, but errors occur when recompiling. It seems like the issue is caused by function names not being in English. Is there a solution for this?
Reverted f940270e8dad since the excess C can be encoded as extra data now
Disassembler preserves data in unused ops
New assembler syntax for overriding operand values (intended for unused fields/garbage)
Assembler can encode default (missing) ops
Assembler errors include line number
Yeah, interesting. I still think this is a really silly way to implement this feature... It looks like just ++ and +=, but different ops for the target being local vs table member vs upvalue (and by the opmap pattern, we could guess maybe there are tabup versions as well but I didn't bother implementing those yet), although not all combinations are observed. Patch and build decompiling via ++and +=, but it would be easy to convert to normal Lua too (although, frankly, probably easy to do by hand...
Yeah, interesting. I still think this is a really silly way to implement this feature... It looks like just ++ and +=, but different ops for the target being local vs table member vs upvalue (and by the opmap pattern, we could guess maybe there are tabup versions as well but I didn't bother implementing those yet), although not all combinations are observed. Patch and build decompiling via ++and +=, but it would be easy to convert to normal Lua too (although, frankly, probably easy to do by hand...
Some are non-standard ops. For example op34 is an increment operation, like C's ++. I think there's also a +=. I can write a patch to unluac for at least some of these (haven't finished looking), but I thought I'd ask what semantics would be most useful for you? I could decompile using custom operators (probably matching C's where possible; -- couldn't be used if that comes up...) which represents the binary more precisely (and I think is most likely to be the original semantics), but then can't...
Some are non-standard ops. For example op34 is an increment operation, like C's ++. I think there's also a +=. I can write a patch to unluac for at least some of these (haven't finished looking), but I thought I'd ask what semantics would be most useful for you? I could decompile using custom operators (probably matching C's where possible) which represents the binary more precisely (and I think is most likely to be the original semantics), but then can't be compiled by a normal Lua compiler; or...
Hi, I've uploaded an archive where all missing opcodes are located, the names indicate which opcode they are and their number. I also added files with a lot of bnot opcodes. Thanks for the work you have done.
I think it's mostly okay. I switched lt and le (still hard to tell apart). bnot is a wild guess. It seems like it is either a meta-op invocation which I have found no context for in which case it is probably still unary, so bnot or I suppose unm by process of elimination, maybe taking the address or returning an ID; or I guess maybe it could be a custom op; or I'm just blanking on something, but it doesn't seem like there's many options (it almost certainly writes to register A, and is almost certainly...
I think it's mostly okay. I switched lt and le (still hard to tell apart). bnot is a wild guess. It seems like it is either a meta-op invocation which I have found no context for in which case it is probably still unary, so bnot or I suppose unm by process of elimination, maybe taking the address or returning an ID; or I guess maybe it could be a custom op; or I'm just blanking on something, but it doesn't seem like there's many options (it almost certainly writes to register A, and is almost certainly...