lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Thanks for the info, I guess I will stick with reverse engineering. This is just a fun project, nothing important. Besides, people have done it before, so it is definitely possible.

On 03.09.2017 11:20, 彭 书呆 wrote:

在 2017/9/2 21:51, unky 写道:
I have a windows x64 executable with embedded lua interpreter and I want to load my own C module into it. There is no source code of this application; interpreter is 64bit and it's version is 5.1.5, statically compiled (there is no lua5.1.dll or any dlls at all).

How am I supposed to build the dll so it would be able to access lua state in application?>
I think I need to tell the compiler that lua functions are defined in executable with the interpreter; is it possible with gcc? It should also be noted that executable exports no functions: dumpbin.exe /exports myapp.exe from visual studio returns nothing.
I have tried to build and use proxy dll ( , all variants) and all of them failed on different stages.

it is possible only if the executable file exports the Lua C API, in which case the
.exe file simply acts like a dynamic library to your module using the C API.

to link to a exe file, you need what is called an import library. it is needed by msvc
tool chain and is by default produced by automatically when you build a dll(exe) file.
the gcc (i.e. mingw) tool chain generally don't need an import library and can link
directly against a dll file, but you can generate an import libray if you need it,
using the dlltool utility. see [1] for instructions.

if the executable exports nothing, then there is nothing you can do with it, legitimately.

_IN THEORY_ you can reverse engineer the executable and recognize the addresses
of the needed functions, but it is absolutely not worth the efforts.

besides, it is not guaranteed to work. the fact that the executable is statically linked
with no exported functions, means there is no guarantee the code for all the API functions
even exist (as callable entry) in the binary file, because the compiler and linker can do
aggressive optimizations to remove or transform the code.