Good morning, I'm trying to decipher a code of Moon bytecode, but i can not in any way, does anyone could help me with this?
I have this, example:
code = '\27\76\117\97\81\0\1\4\4\4\8\0\'
How I decrypt this bytecode to text?
I already search here: http://www.asciitable.com/
But find result, because some of it does not exist in the table
Please help me with this...
I'm trying to several days and nothing
This seems to be bytecode for Lua 5.1. It is not encrypted cryptographically and be easily read with luac -l -p (not in source form but in VM instructions, which are probably enough to reconstruct the source). If you want to reconstruct the source, try LuaDec for Lua 5.1.
have this, example:
code = '\27\76\117\97\81\0\1\4\4\4\8\0\'
How I decrypt this bytecode to text?
The sequence above is what Lua bytecode looks like, if the first character '\27' tells lua that the file is bytecode or text. The sequence is \27 followed by Lua '\76\117\97' followed by \81 which tells that this is a Lua 5.1 bytecode, etc. for details have a look at this link http://howto.oz-apps.com/2012/04/delve-deeper-into-lua-and-compilation.html
A very good resource can be found at http://chunkspy.luaforge.net/ and a wonderful detailed PDF from Kein Hong Man
Like others have said, you can use LuaDec for Lua 5.1
but what I would do, for bytecodes like this, is use this number extractor, getting all the numbers only, then using this numbers to utf8 converter
and paste them there. It may look like random words at first, but you need to align them in 1 single line, but make a space every time you go back a line, like this.
27 76 117 97 81 0 1 4 4 4 8 0
and NOT like this.
27
76
117
97
81
etc, and you should get the answer, but this might not work on different bytecodes, but this is pretty much just the manual way, It's better to use LuaDec for Lua 5.1, however if you still wanna try this, you will not get the exact source string, and if you do then good job, but that would be very bad encryption.
You can't turn bytecode into text. It's not text but instructions to the Lua interpreter.
Related
I have stumbled upon a Lua script which I am trying to decompile. So far I have tried all different versions of standard Lua decompilers such as unluac and luadec. I either get a "not a precompiled chunk" or "bad header in precompiled chunk" errors.
I have also tried different Lua versions and 32-bit and 64-bit architectures for the decompilers.
I have looked at the header and it reads something like this - 1b 4c 4a 01 02 52 20 20 in hex. Looks almost correct but it seems to me like the signature starts with one extra byte and the 6th and 7th byte are wrong. Also, there is 52 in there which I assume is the Lua's version.
As the signature is one byte too long, the normal decompilers don't work. I have a suspicion that this might me a LuaJIT bytecode as if you convert that string to ANSI you will notice ESC, L, J sequence which is a function header for LuaJIT.
In case this is a LuaJIT binary, where do I start about decompiling it? I have tried some decompilers but they all seem to be extremely out of date or fail at some point within the execution (I am talking about LJD and its derivatives).
Any suggestions on how to analyze, view opcodes or decompile it would be greatly appreciated.
Here is the file I am talking about (apologies, too long to post here in case someone wants to have a go):
https://pastebin.com/eeLHsiXk
https://filebin.net/r0hszoeh8zscp8dh
Today I decrypted some Lua 5.3 Bytecode, but I'm wondering why there are random letters coming up.
AH���U��H�D#�#�A�H��E#F������#�\��H�A ����U�G�E# F����I���E# F���I���E# F#���I����*p#�� 640#0stringformat%X�o#��#0#��# �####�#8�#��#��#��#��#<�#��#��##�#p�#n�#p�#��#n�#��#>�#��#`�##�#getRainbow0x00HacksHacksBackgroundColor CEPanel2Hacks 84itle��A�A�#A��disableMenuHacksdragNow���#ƀ��� ���PictureHacksHacksClose_On��E#F��F� #��PictureHacksHacksClose_Off���#ƀ��� ���Pictu 114eHacks
HacksLock_On��E#F��F� #��PictureHacksHacksLock_Off���#ƀ��� ���PictureHacksMenu_On��E#F��F� #��PictureHacks Menu_Off��EF#�F��#��#� #A 130��EF#���##��#��AI���Hacks CEPanel1Heighti#Enabled$#��EF#�F������EF�I�#�EF#�F������EF#�I�#��HacksPage2CheckedPage3Page1��EF#�F������EF�I�#�EF#�F������EF#�I 192#��HacksPage2CheckedPage1Page3��EF#�I�#�EF�I#A�EF��I#A�EF��I#B�EF��IÅEF#�I�Å�HacksHacksPage1visibleHacksPage2HacksPage3
HacksPageCaptionPage 1 of 3HacksPageDownColor
I got the bytecode from my friend. I decrypted it fast but I'd like to know if there's any way to fix those random letters or decrypt them. Any ideas? Thanks.
The � symbol is used when Unicode runs into "an unknown, unrecognizable or unrepresentable character." So either your decryption isn't working properly and is getting some corrupted characters, your friend's encryption isn't working properly and when he encrypted it, the data was corrupted, or somewhere in-between the bytecode was corrupted or altered in some way that is affecting the decryption.
I haven't done much messing around in Lua with bytecode, but I would suggest having a look at the Lua Unicode library page, or look into this module which provides support for UTF-8 for Lua and LuaJIT. Finally, this Stack Overflow question has a good explanation of how Lua's support for Unicode works.
Go back to your friend and double-triple check that the bytecode you decrypted is exactly identical to the bytecode after he encrypted it, and make sure that both your method of decryption and his method of encryption are working correctly.
I wrote the following code in the file "orgin.lua"
if test==nil then
print(aa["bb"]["cc"]) -- to produce a crash
end
print(1120)
when it crash ,it will generate the following information:
lua: origin.lua:3: attempt to index global 'aa' (a nil value)
In order to prevent decompilation and make sure the code is safe,I use the following command to convert my code:
luac -o -s test.lua origin.lua
I know the argument -s is strip debug information, then it do not show the number of rows when crash:
lua: ?:0: attempt to index global 'aa' (a nil value)
but how to bring debugging information when encryption then lua code use luac?Is there any solution?
There is no way to do this built into Lua, but there are some work-arounds.
If you only need line numbers, then one option is to leave the line numbers in the chunk. Line numbers are not that useful for reverse engineering (unluac currently doesn't use them at all), so it shouldn't affect security. Lua doesn't provide an option for this, but it is easy to modify Lua to leave them in when stripping. From ldump.c
n = (D->strip) ? 0 : f->sizelineinfo;
can be changed to
n = f->sizelineinfo;
(Disclaimer: untested)
A more complicated option would be to modify the Lua runtime to output the virtual machine program counter instead of the line number, and also output information describing the location of the current function in the chunk (e.g. top level, first function, second function nested in third function, etc). Then the line number could be looked up by the developer in a non-stripped version of the chunk. (Here is a reference to someone using this approach on lua-l -- no source code was provided, though.)
Note that preventing decompilation is not true security. It may help against casual attacks, but Lua bytecode is not hard to read.
luac does not encrypt the output. It compiles your Lua source code to bytecode, that's all. The code is neither encrypted nor does it run any faster, only the loadtime is shorter since the compilation step is not needed.
If you want your code to be encrypted, I suggest to encrypt the bytecode using e.g. AES-256 and then decode it in memory just before handing it to the Lua state. This way the bytecode is encrypted on disk, but decripted in memory.
The overhead is low. We use this technique since years.
I am preparing overall knowledge on building a Forth interpreter and want to disassemble some of the generic Forth code words such as +, -, *, etc.
My Gforth (I currently have version 0.7.3, installed on Ubuntu Linux) will allow me to disassemble colon definitions that I make with the command see, as well as the single code word .. But when I try it with other code words, see + or see /, I get an error that says, Code +, and then I'm not able to type in my terminal anymore, even when I press control-c.
I should be able to decompile/disassemble the code words, as shown by the Gforth manual: https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Decompilation-Tutorial.html
Has anyone else had this issue, and do you know how to fix it?
Reverting to the old ptrace method did it for me.
First, from the command line as user root run:
echo 0 >/proc/sys/kernel/yama/ptrace_scope
After which see should disassemble whatever it can't decompile. Command line example (need not be root):
gforth -e "see + bye"
Output:
Code +
0x000055a9bf6dad66 <gforth_engine+2454>: mov %r14,0x21abf3(%rip) # 0x55a9bf8f5960 <saved_ip>
0x000055a9bf6dad6d <gforth_engine+2461>: lea 0x8(%r13),%rax
0x000055a9bf6dad71 <gforth_engine+2465>: mov 0x0(%r13),%rdx
0x000055a9bf6dad75 <gforth_engine+2469>: add $0x8,%r14
0x000055a9bf6dad79 <gforth_engine+2473>: add %rdx,(%rax)
0x000055a9bf6dad7c <gforth_engine+2476>: mov %rax,%r13
0x000055a9bf6dad7f <gforth_engine+2479>: mov -0x8(%r14),%rcx
0x000055a9bf6dad83 <gforth_engine+2483>: jmpq *%rcx
end-code
Credit: Anton Ertl
Most versions of SEE that I've seen are meant only for decompiling colon definitions. + and / and other arithmetic operations are usually written in assembly code and SEE doesn't know what to do with them. That's why you were getting the CODE error message: they're written in code, not Forth. There are several Forth implementations I've seen that have built in assemblers, but I don't think I've ever seen a dis-assembler. Your best bet for seeing the inner workings of + or / or other such words might be to use DUMP or another such word to get a list of the bytes in the word and either disassemble the word by hand or feed the data into an external disassembler. Or see if you can find the source code for your implementation or a similar one.
SEE is a word that has not a tightly controlled behaviour. It is a kind of best effort to show the code of a word X if invoked as
SEE X
It behaves slightly different according how difficult it is to do this. If you defined the word yourself in the session, you're pretty much guaranteed to get your code back. If it is a built in word, especially if it is a very elementary word like + , it is harder. It may look nothing much like the original definition, because of optimisation or compilation into machine code.
Specifically for gforth, if it gets hard gforth invokes the standard tools that are present on the system to analyse object files. So it may be necessary to install gdb and/or investigate how gforth tries to connect to it. For the concrete example of Ubuntu and gforth 0.7.3 Lutz Mueller gives a recipee.
.
I think SEE does it's job as designed.
There are words in FORTH defined in machine code (often called as primitives) and also there is a possibility to define machine code via assembler by the user ie.:
: MYCODE assembler memonics ;CODE
So the output of SEE shows not Code error, but that (ie.) + word was defined as machine code and one can see the disassembled mnenonics on the right of it's output.
In Java, when I do following left shift operation, I get a negative result due to integer / long overflow:
0xAAAAAAAA << 7 gives me -183251938048
But, In Lua since everything is a Lua number which is 52 bit float; I am not able to trigger overflow upon left shift:
bit_lshift(0xAAAAAAAA,7) gives me 1431655680
How do I simulate 32bit signed integer in Lua??
You write some C functions that handle this and then export them to Lua.
Though generally, Lua code shouldn't be touching things this low-level.
You are looking for bit manipulating libraries in Lua. One such library is bitop from the author of LuaJIT, which directly contains it without the need for installation. You can also install it in standard Lua.
Another library is the bit32 library, which is contained in Lua 5.2.
Both libraries let you manipulate 32-bit numbers. For example with bitop:
local bit = require 'bit
print(bit.lshift(0xAAAAAAAA, 7)) --> 1431655680
I do not know how you got the negative number, since 1431655680 is what I get by doing (0xAAAAAAAA<<7)&0xFFFFFFFF in C (and also doing that in a "programming calculator").
I hope I'm not seen as trolling for saying this, but the best way to simulate Java from Lua would be to use Java from Lua.
If you need to emulate Java, chances are that your Lua is already embedded in it. Just expose Java's binary operations to the Lua program, so it can use them.