Giter Club home page Giter Club logo

unicorn-lua's People

Contributors

dargueta avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

unicorn-lua's Issues

64-bit integers broken on <5.3

Lua 5.1 and 5.2 exclusively use floating-point numbers, which means that anything over 53 bits can't be represented accurately and will get truncated.

Reading MSRs on x86 is broken

When reading a model-specific register on an x86 machine, uc_reg_read() expects the register ID to be present in the buffer. There is currently no way to pass the ID of the MSR you want to read, so this always returns the machine check exception address register (judging from this).

We need to modify this to allow specifying a model.

No support for ST or SSE2+ registers

Maximum supported register size is 64 bits. This means we can't read 80-bit floating-point registers, nor the XMMX (128-bit), YMMX (256-bit) or ZMMX (512-bit) registers. Reading these registers will result in a buffer overflow (see #3) and garbage return values.

Add support for Windows

I've been trying to get this to work off and on for two years, but just getting Unicorn and Lua to build is proving much more difficult than I thought. I would really like to get this working if possible.

So far my major problem is building and installing Lua and Unicorn properly. I'm fairly sure the code itself is cross-platform, but we'll see.

Can't read/write 80-bit floating-point registers

The library is incapable of reading or writing the 80-bit floating-point ST(x) registers on x86 architectures. The encoding and decoding code is buggy so it currently throws an exception rather than give an incorrect answer.

Reading/writing floating-point registers gives garbage values

Everything is read as an integer so you're going to get back whatever the binary representation of a floating-point integer is on your machine, which can differ between architectures.

This is fixable, but is going to be tedious and error-prone for architectures other than x86 and MIPS because I'm not as familiar with those.

Buffer overflow when reading large registers

The current code for reading a register looks like this:

lua_Unsigned value = 0;
error = uc_reg_read(engine, register_id, &value);

On Lua 5.3, integers are 64 bits, so this will result in a buffer overflow when reading the 128-bit XMMX/YMMX etc. registers on an Intel machine. Similarly, reading a 64-bit register on any 32-bit Lua installation will also result in a buffer overflow.

Big-endian host support?

Reading from/writing to registers on a big-endian host system won't work for registers that aren't the same size as a Lua integer. This is because the library currently has no concept of register sizes and thus doesn't know how to do typecasts.

Due to how byte order works this doesn't matter on a little-endian host, but on a big-endian host it'll result in things like a 16-bit register getting returned to Lua as 0x7fff000000000000 instead of 0x7fff.

Compilation fails on GCC 12

Running luarocks build fails to compile.

Update: It compiles fine if the -Wall flag is removed. I really don't want to do this.

The command Make runs (reformatted, paths are slightly modified to remove personal info)

gcc -std=c++11 -DIS_LUAJIT=0  -Wall -Wextra -Werror -Wpedantic -pedantic-errors \
    -I./include               \
    -I./.luaenv-5.4.6/include \
    -I./.luaenv-5.4.6/include \
    -I/usr/local/include      \
    -I/usr/local/include      \
    -O2 -fPIC -c              \
    -o src/control_functions.o src/control_functions.cpp

GCC barfs:

In file included from /usr/include/c++/12/memory:75,
                 from src/control_functions.cpp:15:
In member function ‘void std::default_delete<_Tp>::operator()(_Tp*) const [with _Tp = long unsigned int]’,
    inlined from ‘std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp = long unsigned int; _Dp = std::default_delete<long unsigned int>]’ at /usr/include/c++/12/bits/unique_ptr.h:396:17,
    inlined from ‘int ul_ctl_get_exits(lua_State*)’ at src/control_functions.cpp:47:1:
/usr/include/c++/12/bits/unique_ptr.h:95:9: error: ‘void operator delete(void*)’ called on pointer returned from a mismatched allocation function [-Werror=mismatched-new-delete]
   95 |         delete __ptr;
      |         ^~~~~~~~~~~~
src/control_functions.cpp: In function ‘int ul_ctl_get_exits(lua_State*)’:
src/control_functions.cpp:34:55: note: returned from ‘void* operator new [](std::size_t)’
   34 |     std::unique_ptr<uint64_t> array(new uint64_t[count]);
      |                                                       ^
In member function ‘void std::default_delete<_Tp>::operator()(_Tp*) const [with _Tp = long unsigned int]’,
    inlined from ‘std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp = long unsigned int; _Dp = std::default_delete<long unsigned int>]’ at /usr/include/c++/12/bits/unique_ptr.h:396:17,
    inlined from ‘int ul_ctl_get_exits(lua_State*)’ at src/control_functions.cpp:47:1:
/usr/include/c++/12/bits/unique_ptr.h:95:9: error: ‘void operator delete(void*)’ called on pointer returned from a mismatched allocation function [-Werror=mismatched-new-delete]
   95 |         delete __ptr;
      |         ^~~~~~~~~~~~
src/control_functions.cpp: In function ‘int ul_ctl_get_exits(lua_State*)’:
src/control_functions.cpp:34:55: note: returned from ‘void* operator new [](std::size_t)’
   34 |     std::unique_ptr<uint64_t> array(new uint64_t[count]);
      |                                                       ^
In member function ‘void std::default_delete<_Tp>::operator()(_Tp*) const [with _Tp = long unsigned int]’,
    inlined from ‘std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp = long unsigned int; _Dp = std::default_delete<long unsigned int>]’ at /usr/include/c++/12/bits/unique_ptr.h:396:17,
    inlined from ‘int ul_ctl_set_exits(lua_State*)’ at src/control_functions.cpp:88:1:
/usr/include/c++/12/bits/unique_ptr.h:95:9: error: ‘void operator delete(void*)’ called on pointer returned from a mismatched allocation function [-Werror=mismatched-new-delete]
   95 |         delete __ptr;
      |         ^~~~~~~~~~~~
src/control_functions.cpp: In function ‘int ul_ctl_set_exits(lua_State*)’:
src/control_functions.cpp:74:61: note: returned from ‘void* operator new [](std::size_t)’
   74 |     std::unique_ptr<uint64_t> entries(new uint64_t[n_entries]);
      |                                                             ^
In member function ‘void std::default_delete<_Tp>::operator()(_Tp*) const [with _Tp = long unsigned int]’,
    inlined from ‘std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp = long unsigned int; _Dp = std::default_delete<long unsigned int>]’ at /usr/include/c++/12/bits/unique_ptr.h:396:17,
    inlined from ‘int ul_ctl_set_exits(lua_State*)’ at src/control_functions.cpp:88:1:
/usr/include/c++/12/bits/unique_ptr.h:95:9: error: ‘void operator delete(void*)’ called on pointer returned from a mismatched allocation function [-Werror=mismatched-new-delete]
   95 |         delete __ptr;
      |         ^~~~~~~~~~~~
src/control_functions.cpp: In function ‘int ul_ctl_set_exits(lua_State*)’:
src/control_functions.cpp:74:61: note: returned from ‘void* operator new [](std::size_t)’
   74 |     std::unique_ptr<uint64_t> entries(new uint64_t[n_entries]);
      |                                                             ^
cc1plus: all warnings being treated as errors
make: *** [Makefile:194: src/control_functions.o] Error 1

Error: Build error: Failed building.

Add to Luarocks

Need to add a rockspec file and make it easily installable. The major problem we have here is that we currently rely on Python scripts to process the Unicorn header files, meaning the user has to have Python installed. We need to

  • Rewrite the header processing scripts in Lua
  • Write a rockspec
  • (Possibly) switch to a regular Makefile since LuaRocks passes us many variables we need

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.