Activity for tehtmi
-
tehtmi committed [938947] on Hg Code
5.5 named vararg support
-
Opmap (mostly just using the patterns compared to the default opmap, not checked closely, but decompiles at least): .op 0 add .op 1 sub .op 2 mul .op 3 mod .op 4 pow .op 5 div .op 6 idiv .op 7 band .op 8 bor .op 9 bxor .op 10 shl .op 11 shr .op 12 unm .op 13 bnot .op 14 not .op 15 len .op 16 concat .op 17 move .op 18 loadk .op 19 loadkx .op 20 loadbool .op 21 loadnil .op 22 getupval .op 23 gettabup .op 24 gettable .op 25 settabup .op 26 setupval .op 27 settable .op 28 newtable .op 29 self .op 30...
-
I just remembered, someone has posted code like this before: https://sourceforge.net/p/unluac/discussion/general/thread/ef8a1e0455/?limit=25#5607 I had cleaner handling of the line number change, but otherwise I think I said about the same thing.
-
Non-standard binary format. Line numbers in debug info are only 1 byte each (looks like maybe delta encoded, but unluac doesn't care what the line numbers are anyway). Right after that there is another list. I didn't look at it much, but seems like entries are 8 bytes (probably two 4-byte ints). This quick patch will let unluac parse (and thus --disassemble): # HG changeset patch # User tehtmi # Date 1769420022 28800 # Mon Jan 26 01:33:42 2026 -0800 # Node ID ffffffffffffffffffffffffffffffffffffffff...
-
Fix local _ENV not doing syntax sugar
-
Very initial 5.5 global support (global assignment check forces global keyword)
-
shli / shri swapped in 5.5
-
Some changes for 5.5 dead closes
-
5.5 disassembly
-
First pass on Lua 5.5 support
-
The file looks encrypted maybe. Visual inspection looks like there are some patterns (so maybe poor encryption), but it's not close to being Lua bytecode. My policy is I won't break encryption. You might find someone else, or do it yourself. (If you have the host application that uses this file, reverse engineering it could help you find out how it decrypts or otherwise reads the file.) If you still have problems after decrypting, then I can help.
-
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
-
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...
-
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...
-
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...
-
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.
-
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
-
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...
-
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)
-
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).
-
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...
-
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...
-
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,...
-
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...
-
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...
-
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...
-
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).
-
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...
-
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...
-
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...
-
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...
-
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 >=...
-
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...
-
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...
-
Yes, looks like you are almost there. I didn't check everything in global.dis, but the other files look reasonable, and if it's working and gives reasonable results it should be right or pretty close. OP60 is not OP46 is testset The strings in StringError.dis look okay to me. "^C%S+" is a Lua pattern. It looks like the ops missing from the table are loadkx, vararg, and setupval. loadkx is almost never used, there would have to be so many constants that loadk wouldn't work. vararg must appear and...
-
Yes, of course. It's fine to try on your own, and I am happy to give pointers, but it often depends on knowing a lot about Lua bytecode to begin with which is pretty specialized knowledge.
-
Yes, I can determine the opcodes, although since I am just working from context, certain things (like various math ops or comparison ops) can be hard to tell apart and mistakes are possible. By this method, I can only determine the ops that actually appear in the file or files I have, so other files which use other ops still won't work until the missing ops are added. If you want to send me more, that's usually fine. Another option would be to try to reverse engineer the host application and determine...
-
1. Non-standard header prevents parsing. Insert byte (hex) 08 between offset 0C and offset 0D (containing 04 04). Or; modify unluac to expect this header. diff -r 9cfa7b28ab36 src/unluac/parse/LHeaderType.java --- a/src/unluac/parse/LHeaderType.java Fri Dec 27 14:54:51 2024 -0800 +++ b/src/unluac/parse/LHeaderType.java Thu Feb 27 23:29:24 2025 -0800 @@ -418,7 +418,8 @@ parse_format(buffer, header, s); parse_tail(buffer, header, s); parse_int_size(buffer, header, s); - parse_size_t_size(buffer, header,...
-
1. Non-standard header prevents parsing. Insert byte (hex) 08 between offset 0C and offset 0D (containing 04 04). Or; modify unluac to expect this header. diff -r 9cfa7b28ab36 src/unluac/parse/LHeaderType.java --- a/src/unluac/parse/LHeaderType.java Fri Dec 27 14:54:51 2024 -0800 +++ b/src/unluac/parse/LHeaderType.java Thu Feb 27 23:29:24 2025 -0800 @@ -418,7 +418,8 @@ parse_format(buffer, header, s); parse_tail(buffer, header, s); parse_int_size(buffer, header, s); - parse_size_t_size(buffer, header,...
-
Non-standard header prevents parsing. Insert byte (hex) 08 between offset 0C and offset 0D (containing 04 04). Or; modify unluac to expect this header. diff -r 9cfa7b28ab36 src/unluac/parse/LHeaderType.java --- a/src/unluac/parse/LHeaderType.java Fri Dec 27 14:54:51 2024 -0800 +++ b/src/unluac/parse/LHeaderType.java Thu Feb 27 23:29:24 2025 -0800 @@ -418,7 +418,8 @@ parse_format(buffer, header, s); parse_tail(buffer, header, s); parse_int_size(buffer, header, s); - parse_size_t_size(buffer, header,...
-
hello, I tried to decompile a .lua binary file but I failed because of size_of_Instruction. I understand your program doesn't support 0x08 bytes? Source of compiled lua file: https://github.com/Tencent/UnLua.
-
hello, I tried to decompile a .lua binary file but I failed because of size_of_Instruction. I understand your program doesn't support 0x08 bytes? Source of compiled lua file: https://github.com/Tencent/UnLua.
-
Non-standard header prevents parsing. Insert byte (hex) 08 between offset 0C and offset 0D (containing 04 04). Or; modify unluac to expect this header. diff -r 9cfa7b28ab36 src/unluac/parse/LHeaderType.java --- a/src/unluac/parse/LHeaderType.java Fri Dec 27 14:54:51 2024 -0800 +++ b/src/unluac/parse/LHeaderType.java Thu Feb 27 23:29:24 2025 -0800 @@ -418,7 +418,8 @@ parse_format(buffer, header, s); parse_tail(buffer, header, s); parse_int_size(buffer, header, s); - parse_size_t_size(buffer, header,...
-
Disassembly is not meant to be transformed into Lua source code. You can transform it back into compiled binary, or read/process it as is -- it is more difficult to understand than source code, but easier than binary. It can be especially helpful in cases where normal decompilation isn't working for some reason or another. If you want source code, don't disassemble. The jump addresses look wrong in the disassembly provided. If you got that from unluac-custom.jar, you shouldn't use it, just use normal...
-
This looks like an encrypted MTA file. Previous discussions about MTA here and here. Unluac doesn't support MTA's encryption or obfuscation. I don't deal with decryption. But, there are other tools, and Unluac can maybe provide some help if it is given a decrypted file and if it is given the proper modifications; but a stripped file will still be stripped. Also, I haven't looked at MTA stuff forever, so I have no idea if anything is up-to-date.
-
I think it should be if bCounterRunning then if true or bSkipClose then --... end end Let me know if you think that doesn't match. Non-branching conditional is another way of getting a naked jump, probably more common that repeat break. Unluac knows about it and will generate it sometimes, but I think actually it isn't considered for conditional combining which would be the only way for it to end up in an 'or' expression. It might be a pain since unluac's current order of operations would make this...
-
Sure.
-
Same caveats. In particular, pow seemed a little bit weird in aaa, shr was a little weird in bbb and bor could easily be bxor in either case IIRC. (Bitwise stuff can be a little tricky, especially since it isn't used much.) aaa .op 0 gettable .op 1 return .op 2 test .op 3 call .op 4 band .op 5 add .op 6 lt .op 7 concat .op 8 forloop .op 9 testset .op 10 jmp .op 11 settabup .op 12 idiv .op 13 newtable .op 14 setupval .op 15 closure .op 16 pow .op 17 loadk .op 20 move .op 21 loadbool .op 22 bor .op...
-
Non-standard bytecode op encoding. You can use unluac's --opmap feature -- give this parameter and an opmap file name on the command line. You need to know the ops. I decoded the ops used in this file for you. It looks pretty organized, so you may just be able to guess others (maybe look at the standard ops in 5.3 lopcodes.h for reference). .op 0 move .op 1 self .op 2 add .op 3 sub .op 4 mul .op 6 pow .op 7 div .op 14 unm .op 18 concat .op 19 jmp .op 20 eq .op 21 lt .op 22 le .op 23 test .op 24 testset...
-
Check for shadowed globals recursively
-
For 5.2, local functions can always be used because explicit _ENV can bypass shadowed declarations.
-
Fix issue with function syntax sugar for local declarations: in 5.0 and 5.1
-
Fix for with nodebug
-
I don't know why you thought you should use the rko300 version, but these files seem to work fine with the normal version of unluac (the latest/default version is 2023_12_24 from the "Unstable" folder in downloads), so try using that. Unluac supports Lua 5.0. rko300 will probably only work for files with no constants -- it is only supposed to be used with files compiled for a custom Lua implementation -- if you actually needed it, that would be strange if that Lua implementation also accepted these...
-
I mean, as I said before unluac is fundamentally not designed to handle debug stripped files. The unluac-vf approach can be improved but it is also fundamentally limited -- a preprocessing pass won't be interacting with control flow operations. Also, I haven't set up a good way to test debug stripped files. That said, you've given a very simple example. I can make it more aggressive about flagging temporaries, but it might break stuff. There's some stuff for tracking 1-read+1-write as a temp candidate,...
-
I mean, as I said before unluac is fundamentally not designed to handle debug stripped files. The unluac-vf approach can be improved but it is also fundamentally limited -- a preprocessing pass won't be interacting with control flow operations. Also, I haven't set up a good way to test debug stripped files. That said, you've given a very simple example. I can make it more aggressive about flagging temporaries, but it might break stuff. There's some stuff for tracking 1-read+1-write as a temp candidate,...
-
I don't know what you did, that seems like a weird place to get a parse error if you were doing what I said, but I attached what worked for me.
-
I'm not sure this is actually UnLua which is a specific implementation of a Lua extension for UE, whereas this maybe just be a different (or even proprietary) implementation of the same idea. (But I don't know that much about UnLua anyway.) It just looks like a slightly non-standard header. It should be easy to edit the files to give them a standard header (or if you want, you could just modify unluac to expect it). To put the file in standard form, change the start from 1B 4C 4A 51 01 20 24 to 1B...
-
It looks like random data after the first ~16 bytes (which are just ASCII text). If it's Lua, I'd say it's probably encrypted. I don't break encryption (not that I would know what to do with this file anyway). If you need to figure it out, maybe consider reverse engineering the host application -- if it is Lua, the host application will probably decrypt it before it gets used.
-
I see this is a different account. I guess that's fine. These files have the same ___MOD thing going on as was discussed earlier in this thread. Otherwise, same caveats apply. .op 0 loadnil .op 1 not .op 2 getupval .op 3 sub .op 6 gettabup .op 11 loadk .op 13 div .op 14 move .op 15 loadbool .op 16 jmp .op 17 settabup .op 18 forloop .op 19 testset .op 20 setupval .op 21 closure .op 22 idiv .op 23 newtable .op 24 test .op 25 call .op 26 gettable .op 27 return .op 28 lt .op 29 concat .op 30 band .op...
-
Sure, that sounds like a good plan. Here's what I came up with. Same caveats as before. aaa: .op 2 setlist .op 3 len .op 4 le .op 5 self .op 6 unm .op 8 mul .op 9 eq .op 10 settable .op 11 mod .op 12 tforcall .op 13 tforloop .op 14 tailcall .op 15 forprep .op 32 sub .op 33 getupval .op 34 not .op 35 loadnil .op 36 shr .op 37 gettabup .op 39 shl .op 40 loadk .op 41 pow .op 42 bnot .op 43 bor .op 44 loadbool .op 45 move .op 46 div .op 47 bxor .op 48 testset .op 49 forloop .op 50 settabup .op 51 jmp...
-
Of course, feel free to ask questions. You're getting a different result because you didn't provide the opmap. I was using --opmap with an opmap file containing the three opcodes you decoded. If you don't provide an opmap, it will use the default one, which is wrong for these files.
-
Of course, feel free to ask questions. You're getting a different result because you didn't provide the opmap. I was using --opmap with an opmap file containing the three opcodes you decoded.
-
Right, I mean every file is different. I explained some of my reasoning before, but at some point it's just having a lot of familiarity with what all different kinds of compiled bytecode look like (which I already knew quite a lot about before the first time I ever tried to do this). If you get stuck trying to figure out one thing, maybe look at another. It's hard to offer more specific advice whether knowing more specifically what you were looking at. I mean, I don't mind if you want to ask me to...
-
Normal Lua 5.3 otherwise as far as I can tell. I'm using this partial opmap (via unluac's --opmap option): .op 1 move .op 2 loadk .op 6 getupval .op 8 gettabup .op 9 gettable .op 10 settabup .op 11 setupval .op 12 settable .op 13 newtable .op 15 self .op 34 jmp .op 35 eq .op 36 lt .op 37 le .op 38 test .op 39 testset .op 40 call .op 41 tailcall .op 42 return .op 43 forloop .op 44 forprep .op 45 tforcall .op 46 tforloop .op 47 setlist .op 48 closure .op 49 vararg .op 50 extraarg It's not shuffled...
-
Yeah weird. It parses if you change the version in the header to 0x53, so probably it is Lua 5.3 with the wrong version code in the header. There are a fair number of differences in parsing. It also looks like it's using a non-standard opmap, I'll have to decode it to see if there's anything weird in terms of 5.1 vs 5.3 in the bytecode (I guess it could still be more or less a 5.1 VM regardless of the binary format -- no number constants that I see so that isn't a factor.
-
I think this is everything. Feel free to let me know if I missed something. Mistakes are possible (particularly confusing similar operations like different comparisons or different math operations), so it would probably be reasonable to have a little suspicion around such things, but I felt pretty good about everything in general. I didn't actually double check that everything would decompile. A couple ops are still missing, which as I said, is generally to be expected. .op 0 pow .op 1 loadk .op...
-
.op 1 loadk .op 4 move .op 12 gettabup .op 16 gettable .op 17 return .op 19 call .op 26 jmp .op 31 closure .op 32 eq .op 44 self If you want to attach more files, I guess you can just zip them and attach that if the forum isn't letting you do it one at a time. Or if you can send me a private message on SourceForge if you like, and we can continue a private discussion via email if there's something you don't want to upload here.
-
Basically just looking at the codepoints and having a lot of experience with Lua bytecode. Some things have to happen in certain ways, and other things are just contextual. This chunk short, so I can go into more detail. First you have to recognize that an opmap is needed. In this case, you could notice something is wrong when try to decompile and get an error (and from the stack trace, I would know it's not a parse error). Then I would --disassemble to get more info about whatever is going wrong....
-
I attached something that works for me (still needing the --opmap if you want to decompile). I guess you can check what I did differently. Don't worry about asking questions.
1 >
