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.
Related
I’m using lua + luajit 2.0.4 and I’m wondering - Is it possible to restore the original parts of the code from the dumps of lua functions?
function a(l)
if l > 3 then
print(l*l)
end
end
local b = string.dump(a)
In this example, I am doing the string.dump of the 'a' function, and here I come to the questions like:
Is it possible to write this dump into a .txt file?
Is it possible to get the original names of functions, variables, and upvalues?
Is it possible to get strings, numbers, tables?
Is it possible to restore it to the full code, and if not, is it possible to get a disassembled listing?
"Yes" to all questions with a couple of caveats. For (1), make sure that "b" is used as part of the "mode" parameter in io.open on Windows, as the output of string.dump will have some binary content. For (2), it's only true when string.dump is used without the strip option, which was added in LuaJIT:
string.dump(f [,strip])
An extra argument has been added to string.dump(). If set to true,
'stripped' bytecode without debug information is generated. This
speeds up later bytecode loading and reduces memory usage.
For (4), I found this document to be very useful: http://files.catwell.info/misc/mirror/lua-5.2-bytecode-vm-dirk-laurie/lua52vm.html (it's for Lua 5.2, but most of the content applies to LuaJIT as well); it also include a section on the difference between full and stripped bytecode that may answer some of your questions.
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 run Lua on a CPU without dedicated floating point HW, depending on SW emulation.
From luaopt.h I can see that some macros are set to double, but it does not clearly state when floats are used and its a little hard to track it.
If my script does simple stuff like:
a=0
a=a+1
for...
Would that involve a floating point operations at any level?
If no that's fine, but what is then the benefit to change macros to long?
(I tried of course but did not work....)
All numeric operations in Lua are performed (according to the default configuration) in floating point. There is no distinction made between floating point and integer, all values are simply numbers.
The actual C type used to store a Lua number is set in luaconf.h, and it is both allowed and even practical to change that to a suitable integral type. You start by changing LUA_NUMBER from double to int, long, or perhaps ptrdiff_t. Then you will find you need to tweak the related macros that control the conversions between strings and numbers. And, of course, you will likely need to eliminate most or all of the base math library since math.sin() and its friends and neighbors are not particularly useful over integers.
The result will be a Lua interpreter where all numbers are integers. The language will still allow you to type 3.14, but it will be stored as 3. Your code will likely not be completely portable to a Lua interpreter built with the standard configuration since a huge amount of Lua code casually assumes that floating point arithmetic is permitted, and remember that your compiled byte code will definitely not be compatible since byte code will store numbers as LUA_NUMBER.
There is LNUM patch (used, for example, by OpenWrt project which relies heavily on Lua for providing Web UI on hardware without FPU) that allows dual integer/floating point representation of numbers in Lua with conversions happening behind the scenes when required. With it most integer computations will be performed without resorting to FPU. Unfortunately, it's only applicable to Lua 5.1; 5.2 is not supported.
Why does Erlang not include arbitrary precision for math functions? I recently had to use math:pow(2,4333), and it throws an error. Why does Erlang not use libraries like GMP? Are there any plans to include it in the standard library? (Haskell uses it, [strike]even Java has bignums[strike]).
Thanks.
Update:
To add more perspective, I understand that it can be done using NIFs. I was solving problems from hackerrank in which the input uses larger numbers. pow/2 can be easily written in Erlang and it worked, but for larger computations, it would be slow.
Java returns double for pow so it does not work for Math.pow(2, 1024) which gives Infinity.
Erlang has bignums for integers but uses 64-bit IEEE standard floating point numbers. So while you can happily compute factorial(10000) with integers by default the math library uses floating point so math:pow(2, 4333) does not work.
I need to handle large numbers in Lua which goes with Redis. Normally you would do that like:
require"bc"
bc.mul(...)
bc.mod(...)
etc.
But unfortunately Redis Lua doesn't support "require". The only approach I've found is inserting a large numbers library written in lua itself directly into the script.
The only such library I could get my hands on: oss.digirati.com.br/luabignum/index.htm
I can strip the library for the purposes of a concrete script but it still remains huge. Is there any way to handle large numbers in Redis Lua more efficiently?
UPDATE1: What if I save the whole library into a key and then access it like:
local BigNumLib = KEYS[1];
BigNumLib.BigNum.mul(KEYS[2],KEYS[3]);
I'm not sure of the syntax and perhaps I'll need to enclose all the library in a lua table {}.
I'm not familiar with how Redis handles Lua code, but why is inserting the library itself into your code is a problem? you should be able to do something like this:
local bc = function()
-- insert the code of BigNum.lua here
return BigNum
end
bc.mul(....)
The code has probably been written before Lua 5.1, so I don't know if there are any compatibility issues, but this should at least give you a start.