I know that you can safely execute arbitrary code from Lua by whitelisting safe things with the Lua function setfenv. But if I do this through a script, not only is it untidy, but (user-moddable game) an unsuspecting user installing a mod could just click "replace all" or something when installing a mod into a folder, without thinking anything of it. I'm sure there are other ways it could be bypassed super-easily too.
Overall the safest way to be safe should be to do this with direct C calls, with no Lua code/strings involved in setting the sandbox. How can I do this?
Anything you code in a Lua script can also be performed in C via the Lua C API. But it's harder to follow in C than the equivalent Lua script. When I have wanted to have some protected Lua scripts for a host program I have done things like for example:
put them in a separate directory.
Encrypt them into an archive that only my C program knows the private key for.
Embedded them as multi-line strings in the C source code.
Embed the compiled scripts as binary strings in my C source code so that they not as easily hack-able via the binary edit of program's exe. (Sometimes I use a SHA of the scripts to prevent them from being edited within the exe)
...and so on.
You definitely want to protect the computer running your game from malicious scripts by using sandboxes. E.g no file system access. But note, that to also protect your host program from all forms of malicious scripts (e.g. hanging the game's Lua instance thread via a while 1 loop; or huge memory use, complex string.match calls for e.g.) you have to do more complex work and add more constraints to the environment given to mod scripts.
E.g. even a while 1 do end will still hang the WOW UI.
Hope that helps.
just don't use luaL_openlibs. Another option would be to have some lua code exist in your c program as a string or bytecode, that you execute before anything else.
Related
Recently I have been working with an open source simulator called Multi2Sim (M2S). I'm using the simulator to simulate heterogeneous processors to collect data that I'm using with my senior project that is aimed to test thew efficiency of different replacment policies with heterogeneous processors. The program is downloaded from the official site https://www.multi2sim.org.
After following the instruction, I successfully installed and ran the program on my Ubuntu 14.04 from the terminal by calling the "m2s" command. I used it to run the processors with LRU, FIFO, and Random cache replacement policies because they are the only policies M2S provides. The nature of my senior project demands that I use as many replacement policies as I can. I contacted a group of researchers who worked with M2S and were able to implement their own policies to the program. After sending an nice email inquiring about the process of implementing a policy to M2S, they nicely said that they can't tell me since their search is still ongoing.
After snooping around the M2S files that I downloaded before using "make" command, I found where the replacement policies are written in C in a file called "cache.c". I understand the overall mechanism of how the C program works now.
I don't have much knowledge with how
My question is: If I write the replacement policies to the the "cache.c" file, do I need to use the "make" command again in order for me to use them with the m2s command? or can I somehow implement the policies without having to remake the whole program? If I had to remake the program, is there a possible way to make it in a way that I will have the command in the terminal with a different name?
Thank you all in advance.
Yes. The whole point of make is that it will rebuild those parts of the program which need rebuilding (in fact it is designed to rebuild only those parts of the program that require rebuilding).
You might also want to consider putting the program under source control (git is worth learning) so that when you break it (as you inevitably will whilst learning) you can easily revert your mistakes, and see exactly what you changed.
I have a large code written in C, but I did not write all of it myself. I wish to create an overview of the call structure in the code for reference. That is: I wish to know what (non-standard) functions are called by the different functions in the code, and thus create a hierarchy or a tree of the different functions. Are there any free, Unix compatible programs (that means no Visual Studio, but a Vim plugin or such would be neat) that can do this, or will I have to write something that can do this myself?
Doxygen does that too, it has to be enabled though.
For an overview of available tools see
http://en.wikipedia.org/wiki/Call_graph
There is a Vim plugin C Call-Tree Explorer called CCTree
http://www.vim.org/scripts/script.php?script_id=2368
As you mentioned a Vim plug-in, check out http://sites.google.com/site/vimcctree/. It uses CScope to generate the tree, so you will need to first generate a CScope db of your source files.
Have a look at http://www.gson.org/egypt/ This uses GCC to process the code and extracts the interdependencies within the program from the AST it emits.
gprof will do that. It also generates an execution profile, but in doing so it creates a call tree.
I just downloaded SourceTrail (https://github.com/CoatiSoftware/Sourcetrail/releases) and it did what I wanted, which was pretty close to what I think you want.
(What I wanted was to find out what routines called the function I was considering changing, or needed to understand).
Note that it is no longer maintained, but it did exactly what I wanted. It runs under Windows and Linux, and made finding who calls a function pretty trivial (as well as following that function's call tree down as needed). If you care, it has a GUI (is a GUI? whatever).
It does the parsing itself, but it didn't take very long to run, perhaps about the same time or a little less than compiling the code.
But if you want text only, or don't want to use a gui, or don't want to have it scan the code, this isn't for you.
(Notes - in my case, I was hyper-focused on one or 2 functions, and didn't care what system functions were being called. I spent some time stubbing out all the include files that were needed (since I ran the parse on one machine (A Linux machine) that didn't have all the include files needed for the Windows program I was looking at, and then did the exploration on a different (Windows) machine. Which, I should mention, worked perfectly. I just copied the entire source tree from my Linux machine to my Windows machine (which included the Sourcetail project file), loaded Sourcetail and had it load the project - done.)
I would like to know if it is possible to include an executable file in another one, and then run it directly from there.
For example, if I am writing a GUI frontend to clprog.exe, I would want to have one file, guiprog.exe, that will run it's internal version of clprog.
Assume including the source of the wrapped program in the wrapper program is not an option.
I am more interested in this as a theoretical question, so answers applying to either windows or linux are fine (I am not familiar with other OSs), as well as using any language (C/Java/ASM/other, though I assume if it will be possible in any of these languages it will be ASM and maybe C, and obviously not Java)
First thought that comes to mind is a .NET solution.
If the external executable is a .NET assembly, you could embed it inside of your own project, and at run time load that into an in-memory assembly and execute using reflection.
If the embedded executable was built with .NET I think you would have to extract and temporarily save the executable, execute it as a separate process and then delete it, if you don't want to leave it's trace.
ive previously asked another questions about building my dll, but it seams like its heading in the wrong direction :) So I have reformulated and explained more her.
So what im trying to build is a dll that will work as an interface between my delphi program and some one else's C program.
What this dll must do is recive a String from the C program then send it to the delphi program where it will be combined with some data and stored, under the current user of my program.
How can i call a method in my Delphi program(running program) to store the message from the dll ?
Im using Delphi 5.
This is what ive got so far:
DLL:
//Parent application: MyDelphiApp
library MyDllLink;
uses
ShareMem,
SysUtils,
Classes,
Dialogs,
Main;// Main is a form from my delphi app. This is not allowed/recomended ?
{$R *.RES}
procedure Transfer(sMessage: PChar); stdcall;
begin
try
//If including Main in the uses clause, then this will also be wrong:
MainForm.StoreDllMessage(sMessage);
except
showmessage('Error');
end;
end;
exports
Transfer;
end.
Delphi app:
procedure TMainForm.StoreDllMessage(sMessage: String);
begin
//StoreMessage just stores it in a DB
StoreMessage(sMessage +' '+sCurrentUserName);
end;
I may be understanding this wrong but it seems like you want the same copy of the DLL to be loaded by both the C program and the Delphi program at the same time. You can't do that and can only really achieve it using a whole lot of work involving inter process communication. The applications will have separate process space and memory.
I would suggest a slightly different approach. In the DLL have a function called SendStringFromCApp and a function called GetStringIntoDelphiApp (or something suitable).
The C program will load a copy of the DLL as normal and call the SendStringFromCApp function. This function will store the passed in data in some common intermediate format (such as a simple database). It will treat the storage as a kind of queue and simply add data to this queue. A database is the most obvious choice but it could be as simple as a common directory and the data is stored as small text files with an increasing integer as the file name.
The Delphi program will load its own copy of the DLL and will call GetStringIntoDelphiApp which will read the first item from the queue/internal storage and process it as required and delete it from the store. Then it will read the next etc etc.
The benefit of this is that both the C and Delphi apps can run independently. Only the DLL needs a common config and the C program can continue to work even if the Delphi app isn't running and vice versa.
It's basically a producer-consumer queueing system for separate processes.
Like I said, I may have misunderstood the requirements!
For the easiest possible IPC try WM_COPYDATA with PostMessage or SendMessage
Microsoft doc:
http://msdn.microsoft.com/en-us/library/ms649011%28VS.85%29.aspx
Microsoft sample:
http://msdn.microsoft.com/en-us/library/ms649009%28v=VS.85%29.aspx
And much more info on google:
http://www.google.com/search?q=WM_COPYDATA&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:pt-BR:official&client=firefox-a
Try implementing an IPC (InterProcess Communication). You will have 3 separated processes.
The Delphi exe
Ths C program
A non windowed process (com service, exe, ...)
Use the non windowed as the server, the other 2 are clients.
See this for IPC in Delphi, and this for IPC in C. There is a lot of ways to do IPC. If you look for IPC in your favorite search engine I'm pretty sure that you will find a common way to do IPC for C and Delphi because it's just some win32 api ballet.
As loursonwinny says, IPC is the way to go.
You should understand that every DLL is loaded within the address space of a single application. Thus a DLL that is used by a Delphi and a C application will exist two times in memory. (Well, not completely, the code sections are shared, all data in the DLL exists twice.) So basically your DLL cannot simply share data between two processes.
There are exceptions, of course. For example, a keyboard hook could be created in a single DLL which is loaded in your Delphi application, then injected into the address space of the C process. Then the DLL can 'peek' into the memory space of the C application and capture some information. (Keyboard events with KeyHooks.) But KeyHooks and similar injectable DLL's will be noticed as "bad" by the average antivirus product. And for good reason, because this is behaviour you'd expect from a computer virus.
Another solution instead of IPC would be the use of a memory mapped file. There are several components available as open-source or commercially but you can also use the Windows API to create these.
The Windows API also provides techniques like Named Pipes and MailSlots, which can also be used for interprocess communication. It doesn't need to be TCP/IP but you will need some way for the two processes to communicate with one another. And this logic could indeed be build in a single DLL, where you'd define just two methods. One for the server, one for the client. It is a complicated technique, though. And Delphi 5 is a bit old so I don't know which solution would work best for you.
The DLL must callback to the Delphi program. When the Delphi program starts up, it'll register a callback function. Then the DLL knows what to call when it is invoked by the C program.
Example:
http://delphi.about.com/od/windowsshellapi/a/callback_delphi.htm
This example uses a callback to allow the windows API to call back into your delphi app. Same idea here, but instead of the Windows API, you're going to be called by your own DLL.
I am interested in calling SoX, an open source console application, from another Windows GUI program (written in Delphi naturally). Instead of dealing with scraping and hiding the console window, I would like to just convert the application to a DLL that I can call from my application.
Before I start down this path I am curious how much work I should expect to be in for? Are we talking a major undertaking, or is there a straight forward solution? I know some C, but am by no means an expert.
I am not expecting SoX specific details, just EXE console application conversion to DLL in general. If someone is familiar with SoX though, even better.
For the specific topic of turning a console executable into a library by modifying the C source code, it depends on how the command-line application is factored. If it's written in such a way that I/O is funneled through a small set of functions or even better function pointers, then obviously it will be trivial.
If it's all done with printf, scanf and friends, then you'll probably be best off by finding / creating an include file that all the source files include and adding a macro that redirects printf/scanf and friends to your own functions that are written so as to be amenable to DLL implementation. Things like printf can be built from vsnprintf (use the n-version for safety), so you don't need to reimplement the whole C RTL I/O subsystem. However, there is no vsscanf, but there are third-party implementations on the web.
If the code is using fprintf, fscanf, etc. to enable indirection between files and the console, you're still out of luck. The FILE structure is opaque, and unlike Pascal text files, a portable text file driver cannot be implemented. It might still be possible if you spelunk in your specific C RTL, but you'd be better advised going down the macro route and reimplementing your own renamed FILE type.
Finally, the "popen()" approach is possible in Delphi and made somewhat easier in Delphi 2009 with the TTextReader and TTextWriter classes. Combine these with TFileStream wrapped around pipes, and specify pipes for standard input, standard output and standard error in the new process and STARTF_USESTDHANDLES, etc., and it will work. If you don't feel like writing your own, there are third-party equivalents / samples on the web for Delphi too. Here's one.
In Windows, you just call CreateProcess with the SoX command line. I don't know the Delphi bindings for Win32, but I've done this exact thing in both Win32 and C#.
And now that you know CreateProcess is what you want to call, a google search on how to do that from Delphi should give you all the code you need.
Delphi Corner Article - Using CreateProcess to Execute Programs
Calling CreateProcess() the easy way
You might not even need a DLL, you can use the popen() function to run a console application and collect any output text.
Run the process, the way Indiv advised and capture the output like how Adam has shown.
However if you still want to do the DLL conversion, this will get you started
Configure SOX for windows and compile it
Create an empty DLL project using your C++ tool
Add the SOX files to be part of the project
Add a new Function called DLLMain
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID ) {return TRUE;}
Add a .DEF file (use the project name as the file name) that lists the exports in the DLL - Add the following content to it
LIBRARY "name.DLL"
EXPORTS
CallOldMain PRIVATE
Rename the main of SOX as CallOldMain
Write a CUSTOM function to log the output / return error etc.
Find all printfs / cout in the SOX application and replace it with calls to your custom function above
Once the DLL is compiled you can now call the function CallOldMain with the same parameters main programs of C expects. You could modify this signature to return the errors / output from above.
Disclaimer: I know nothing about SoX. It might be that the code is structured to make this easy, or it might be more hard. Either way, the process is the same:
First you want to find the functions in the SoX application that you want to call. Most likely the console app has code to parse the command line and call the appropriate functions. So first off, find the functions you want to use.
Next, check out the info on exporting functions in DLLs from C at this site: Creating And Using DLLs
Then make a new makefile or visual studio project file with the target being a DLL, and add the sourcefiles from the SoX program that you have modified to be exported.
You don't mention what your toolchain is, but if you configure gcc in Windows, you can use the normal config;make;make install to just compile sox. In the process, it will create a dll file, and the console app. Or, you can just specify the make target to only make the dll. This will compile a windows native library that only depends on the MS C runtime dll, and you can use this in your own app.
You can execute a console application and capture its output using pipes. You use une side of the pipe as stdout for the CreateProcess and you read from the other side like a common file.
You can see a working example written in delphi here: http://delphi.about.com/cs/adptips2001/a/bltip0201_2.htm