I was checking some Lua source, trying to get and learn from them, but it seems there are encoded & obsfuscated.
I decoded it using base64 decode, but still unreadable.
Is there any ways to desobfuscate it?
LuaR“
æÆì~>o¢by„A#€ÁÀAA†AÅÂAFB„K¥Jƒƒ„JÃB…¥CJƒ†¥ƒJƒƒ†ŒCÀC€‹ÀÝ€EÀ À…ŠÃ
âƒcþåÃ%eD‹Á„…AÅEÁFA†ÆÁGA‡ŠÄÅ Š„ÅŠF
ŠDÆ
Š„FŠÄÆŠGŠDÇŠ„G
ŠÄÇ
ŠH‹Á‡ˆAÈHÁIA‰ÉÁ JAŠ
ÁJ‹AËKÁ L AŒ Ì Á
M
A
Í
Á
ÁJ‹AËKÁ L AŒ Ì Á
M
A
Í
Á
This is a precompiled Lua 5.2 script.
You can see its contents with luac -l -p foo.
Make sure you use luac from Lua 5.2. If in doubt, try luac -v.
Sure: luadec
Just curious, why did you tried base64? That chunk you provided is a simple lua code, translated to lua vm bytecodes. it is not even obfuscated.
This is compiled lua source. You can use this tool to decompile. It isn't actually obfuscated.
Related
When I start an interactive Lua shell, io.write() adds unwanted material after the string I want it to print. print(), however does not:
[user#manjaro lua]$ lua
Lua 5.4.2 Copyright (C) 1994-2020 Lua.org, PUC-Rio
> io.write('hello world')
hello worldfile (0x7fcc979d4520)
> print('hello world')
hello world
And when I use io.write() in a program it works fine too:
--hello.lua
io.write('hello world\n')
print ('hello world')
Output:
[user#manjaro lua]$ lua hello.lua
hello world
hello world
I'm using Manjaro Linux on a Dell desktop. Can anyone tell me what's going on here? Thanks in advance.
EDIT: I should add, perhaps, that the unwanted material is always something like this:
file (0x7f346234d520)
It's always 'file' followed by what looks like a large hexadecimal number in parentheses. The exact number stays constant within one shell session but varies between different shell sessions.
"file (0x7fcc979d4520)" (or whatever address) is the return value of the io.write call, with an implicit tostring.
The lua(1) man page says
In interactive mode, lua prompts the user, reads lines from the standard input, and executes them as they are read. If the line contains an expression or list of expressions, then the line is evaluated and the results are printed.
The trouble here is that io.write('hello world') could be either an expression or a statement. Since it's a valid expression, the interpreter outputs that unwanted return value.
As a workaround, try adding a semicolon:
> io.write('hello world\n');
hello world
Although Lua usually doesn't require a semicolon for each statement if it's at the end of a line, it does allow it. And important here, it means the syntax can't be an expression, only a statement which calls the function. So the interpreter won't output the returned value.
You are just seeing the return value of io.write when you call io.write manually, interactively. When using the Lua, uh, shell, if you want to call it that, it almost always prints the return value of any function(s) you call.
file(blabblah) is the internal representation of the file you are writing to (probably just a hex memory address, but who knows?)
I have a text file with unknown character formatting, below is a snapshot
\216\175\217\133\217\136\216\185 \216\167\217\132\217\133\216\177\216\163\216\169 \216\163\217\130\217\136\217\137 \217\134\217\129\217\136\216\176\216\167\217\139 \217\133\217\134 \216\167\217\132\217\130\217\136\216\167\217\134\217\138\217\134
Anyone has an idea how can I convert it to normal text?
This is apparently how Lua stores strings. Each \nnn represents a single byte where nnn is the byte's value in decimal. (A similar notation is commonly used for octal, which threw me off for longer than I would like to admit. I should have noticed that there were digits 8 and 9 in the data!) This particular string is just plain old UTF-8.
$ perl -ple 's/\\(\d{3})/chr($1)/ge' <<<'\216\175\217\133\217\136\216\185 \216\167\217\132\217\133\216\177\216\163\216\169 \216\163\217\130\217\136\217\137 \217\134\217\129\217\136\216\176\216\167\217\139 \217\133\217\134 \216\167\217\132\217\130\217\136\216\167\217\134\217\138\217\134'
دموع المرأة أقوى نفوذاً من القوانين
You would obviously get a similar result simply by printing the string from Lua, though I'm not familiar enough with the language to tell you how exactly to do that.
Post scriptum: I had to look this up for other reasons, so here's how to execute Lua from the command line.
lua -e 'print("\216\175\217\133\217\136\216\185 \216\167\217\132\217\133\216\177\216\163\216\169 \216\163\217\130\217\136\217\137 \217\134\217\129\217\136\216\176\216\167\217\139 \217\133\217\134 \216\167\217\132\217\130\217\136\216\167\217\134\217\138\217\134")'
How can I search for control characters in unix ed(1)?
For example
ed somefile.log <<EOF
1,$s/.*\015//
w
q
EOF
doesn't work. Neither does \r. Obviously sed(1), awk(1) and other editors can do this, however ed has the very useful line move (m) command which is all I need within the bash script I am using.
I am able to accomplish what I want within the script by entering the control character directly (escaping it with C-v in vi, C-q in emacs for example), but this means that binary characters must be present in my otherwise printable text script.
ed Transport2SVN-W0177.log <<EOF
g/^M/s/.*^M//p
w
q
EOF
The ^M is actually character 0x0d.
ed doesn't provide any support for converting control characters.
The way you have found of inserting control-characters directly into the script (using Ctrl-V at the keyboard) is portable and it works.
It's possible that particular implementations of ed might support this, but it would not be portable.
Which Ansi escape sequence is the most portable and/or simply best and why?
1. "\u001B[32;1mThis is bright green\u001B[0m"
2. "\x1B[33;1mThis is bright yellow\x1B[0m"
3. "\e[35;4;1mThis is bright purple underlined\e[0m"
I have been using printf "\x1B[32;1mgreen\x1B[0m" (that's an example in unix bash script for example) out of habit, but I was wondering if there were any reasons to use one over the other. Is one more portable than the others? That would be my assumption.
Also, if you know of any other Ansi Escape sequence feel free to share it in the comments or at the end of your answer.
If you don't know what an Ansi Escape sequence is or want to become more familiar with it, then here you go: http://en.wikipedia.org/wiki/ANSI_escape_code
NOTE:
All of the escape sequences above have worked on all of the Unix systems I have been on, however one must still rely on the system itself to interpret the escape codes. Windows, for example, does not permit any sort of escape codes except four (BEL, L-F or linefeed, C-R or carriage return and, of course, BS or backspace), so Ansi escape sequences will not work.
Short answer: It depends on the host string parser.
Long answer:
It depends on the string parser; that is, the piece of code that actually takes in your string ("\x1b[1mSome string\x1b[0m") as a literal and parses the escape characters using the backslash ANSI escape sequence.
For parsers that support hexadecimal escapes (\x), then \x1b (character 0x1B) should work.
For parsers that support octal escapes (\ddd), then \033 (octal 33) should work.
For parsers that support unicode escapes (\u), then \u001B should work.
Quick elaboration: \x and \u are similar; \x usually refers to a single character, 0-255, in hexadecimal radix. \u means the same (as it is represented in hexadecimal), but supports two bytes (in most parsers) and generally refers to 16-bit unicode characters.
A lesser used/supported escape character, as you mentioned, is \e. This escape is most commonly used with parsers/languages that expect a lot of ANSI escaping to happen, such as bash (and most other shells).
For instance, Node.js does not support \e:
> console.log("\x1b[31mhello\x1b[0m")
hello
undefined
> console.log("\e[31mhello\e[0m")
e[31mhelloe[0m
undefined
Neither does Lua:
> print('\x1b[31mhello\x1b[0m')
hello
> print('\e[31mhello\e[0m')
stdin:1: invalid escape sequence near '\e'
Or even Python:
>>> print("\x1b[31mhello\x1b[0m")
hello
>>> print("\e[31mhello\e[0m")
\e[31mhello\e[0m
>>>
Though PHP does:
<?php
echo "\x1b[31mhello\x1b[0m\n"; // hello
echo "\e[31mhello\e[0m\n"; // hello
I am trying to implement a function to differentiate between french vowels and consonnants. It should be trivial, let's see what I wrote down :
-define(vowels,"aeiouyàâéèêëôù").
is_vowel(Char) -> C = string:to_lower(Char),
lists:member(C,?vowels).
It's pretty simple, but it behaves incorrectly :
2> char:is_vowel($â).
false
While the interpreted version works well :
3> C = string:to_lower($â), lists:member(C,"aeiouyàâéèêëôù").
true
What's going on ?
The most likely thing here is a conflict of encodings. Your vowels list in the compiled code is using different character values for the accented characters. You should be able to see this by defining acirc() -> $â. in your compiled code and looking at the number output by calling char:acirc(). versus $â. in the interpreter. I think that the compiler assumes that source files are in ISO-Latin-1 encoding, but the interpreter will consult your locale settings and use that encoding, probably UTF-8 if you're on a modern linux distro. See Using Unicode in Erlang for more information.