I am using the MEX interface to run C++ code in MATLAB. I would like to add several functions to MATLAB for handling a System object:
sysInit()
sysRefresh()
sysSetAttribute(name, value)
String = sysGetAttribute(value)
sysExit()
Since each MEX dll can contain one function, I need to find a way to store the pointer to the global System object which will exist until deleted by a call to sysExit.
How can I do this in MATLAB properly? Are there any ways to store global pointers across calls to MEX functions?
One common approach is to have several m-file functions that provide the public interface, e.g. sysInit.m, sysRefresh.m, etc.
Each of these m-files calls the mex function with some kind of handle, a string (or number) identifying the function to call, and any extra args. For example, sysRefresh.m might look like:
function sysRefresh(handle)
return sysMex(handle, 'refresh')
In your sysMex mex function, you can either have the handle be a raw heap pointer (easy, but not very safe), or you can maintain a mapping in C/C++ from the handle ID to the actual object pointers. This solution requires a little extra work, but it's much safer. This way someone can't accidentally pass an arbitrary number as a handle, which acts as a dangling pointer. Also, you can do fancier things like use an onCleanup function to release all memory and resources when you unload the mex function (e.g. so you don't have to restart matlab when you recompile the mex function).
You can go a bit further if you like and hide the handle behind a Matlab class. Read up on the OO features for Matlab in the docs if you're interested. If you're using a recent version, you can take advantage of their much cleaner handle objects.
Alternatively, you may get away with not using MEX at all. In matlab (on Windows) you can load any generic dll with loadlibrary and call any of its functions with callib. This is probably not portable across operating systems, though.
Related
I have a pretty large application which holds most of the program data in a large container object called system.
So I access things all the time, e.g. printf("%s\n",system.constants.jobname);, and changing the name of system is undesirable.
I learned later that the function system exists as a native C function for running terminal commands, e.g. system("rm *.txt");
My problem is that I get compilation errors trying to use system as a function because it's already defined as an object.
Is there any way one can call a native C function explicitly ignoring programmatically defined variables? Or give the native system function an alias? (I'm using C++ so using it would be fine)
If you're using C++, system is in the global namespace. Assuming you've put your stuff in a proper namespace (you have, right?) you can refer to it as ::system.
Assuming using shared libraries is an acceptable solution, you can do this.
Create another C file which will not use your system container. Now write a function my_system that is a wrapper to system.
By wrapper I mean, it takes the same argument and calls system and returns what system returns.
Don't forget to export my_system
Now compile this as a dll (or .so on *NIX).
In your main project, load the dll and get a handle. Now query for address of my_system on the handle and make the call using function pointer.
I am trying to interface this C++ code -- which implements functions necessary to calculate a Voigt line shape -- with LabVIEW (I'm currently running LV2009). I successfully compiled the code into a DLL, and I set up the Call Library Function Node to point to the DLL. However, the function expects a vector of type complex double and returns a vector of type complex double. Complex double is not, however, one of my choices for data type when setting up the function prototype.
Unfortunately, I do not speak C/C++, so I don't have any idea how I would go about modifying the code to get and return real doubles only. I have compiled the code into a MEX file to use with MATLAB, and pass complex numbers in and out with no problem, so I know the code works.
Is there a way to trick LabVIEW 2009 into passing complex numbers in and out of DLL functions? If not, will I gain this ability if I upgrade to the newest release? If not, is there a good basic guide to C++ that will teach me how to modify the function to accept and return the real and imaginary parts as separate vectors?
LabVIEW doesn't allow interfacing with C++ code, only C (or if it's C++, it has to have the extern "C" declaration and use Plain Old Types).
I see that your library has C wrappers, but they use the new C99 complex type, which LabVIEW doesn't understand.
However LabVIEW can pass complex data type to a function, to see how it's done open the example named "Call DLL.vi" and select complex data-type to see function prototype and VI. Your chance might be that the C99 complex has the same binary representation than the LabVIEW one. I didn't dig for the info, but it might be very possible.
If it's the case, go to church and be grateful to your Lord, and use the C wrapper to interface to it.
If it's not, find a tutorial about making a DLL for your compiler, it's not difficult, just takes time. The DLLÂ will take two double for each complex, and make the appropriate call to the real function.
I have a c++ program that updates a system. When I wrote everything in C++ it looked a little something like this
System S; //initialize a System object 'S'
while (notFinished)
{
S.update1(inputVars1);
S.update2(inputVars2);
}
Now I would like to call the individual update functions from matlab and be able to use access functions (written in c++) to view the state of the program at any time when debugging in matlab.
So matlab will need to call something to instantiate a "System" object, and then it will need to call individual System methods from the original system object.
Suppose I compile separate mex files to Initialize update1 update2 and some that get information about the current state getState. And then write some matlab code...
%matlab main
S = Initalize(); %mex file
while (notFinished)
update1(S); %mex file
keyboard; % access state information using "getState" mex function
update2(S); %mex file
keyboard; % access state information using "getState" mex function
end
Will this essentially allow me to call and debug my C++ program algorithms in Matlab, or is there another way to go about this whole problem?
The way I would do it is by creating a pointer for System in C++ in the Initialize mex function using "new". If you are on a 64 bit platform then cast this pointer to a 64-bit integer and create an mxArray with that type and value. Return this mxArray from your Initialize function.
For later calls to your other mex files you should pass this mxArray as an input. Inside those files you can cast it back as a pointer and call methods on the object.
I also would take one more step to wrap this whole thing inside a MATLAB System object or a regular object and not expose the pointer value S outside the object. You need methods on the object which would call your mex files. This is especially needed if you are planning to give this to other people for use. Others might accidentally overwrite or modify S causing crashes.
Finally you need a delete mex function which would delete the pointer S. If you create a handle class then you can do this in the destructor.
I have been playing around with pointers and function pointers in c/c++. As you can get the adress of a function, can you change where a function call actually ends?
I tried getting the memory adress of a function, then writing a second functions adress to that location, but it gave me a access violation error.
Regards,
Function pointers are variables, just like ints and doubles. The address of a function is something different. It is the location of the beginning of the function in the .text section of the binary. You can assign the address of a function to a function pointer of the same type however the .text section is read only and therefore you can't modify it. Writing to the address of a function would attempt to overwrite the code at the beginning of the function and is therefore not allowed.
Note:
If you want to change, at runtime, where function calls end up you can create something called a vritual dispatch table, or vtable. This is a structure containing function pointers and is used in languages such as c++ for polymorphism.
e.g.:
struct VTable {
int (*foo)(void);
int (*bar)(int);
} vTbl;
At runtime you can change the values of vTbl.foo and vTbl.bar to point to different functions and any calls made to vTbl.foo() or .bar will be directed to the new functions.
If the function you're trying to call is inlined, then you're pretty much out of luck. However, if it's not inlined, then there may be a way:
On Unix systems there's a common feature of the dynamic linker called LD_PRELOAD which allows you to override functions in shared libraries with your own versions. See the question What is the LD_PRELOAD trick? for some discussion of this. If the function you're trying to hijack is not loaded from a shared library (i.e. if it's part of the executable or if it's coming from a statically linked library), you're probably out of luck.
On Windows, there are other attack vectors. If the function to be hooked is exported by some DLL, you could use Import Address Table Patching to hijack it without tinkering with the code of the function. If it's not exported by the DLL but you can get the address of it (i.e. by taking the address of a function) you could use something like the free (and highly recommended) N-CodeHook project.
In some environments, it is possible to "patch" the beginning instructions of a function to make the call go somewhere else. This is an unusual technique and is not used for normal programming. It is sometimes used if you have an existing compiled program and need to change how it interacts with the operating system.
Microsoft Detours is an example of a library that has the ability to this.
You can change what a function pointer points to, but you can't change a normal function nor can you change what the function contains.
You generally can't find where a function ends. There's no such standard functionality in the language and the compiler can optimize code in such ways that the function's code isn't contiguous and really has not a single point of end and in order to find where the code ends one would need to either use some non-standard tools or disassemble the code and make sense of it, which isn't something you can easily write a program for to do automatically.
if kernel32.dll is guaranteed to loaded into a process virtual memory,why couldn't i call function such as Sleep without including windows.h?
the below is an excerpt quoting from vividmachine.com
5. So, what about windows? How do I find the addresses of my needed DLL functions? Don't these addresses change with every service pack upgrade?
There are multitudes of ways to find the addresses of the functions that you need to use in your shellcode. There are two methods for addressing functions; you can find the desired function at runtime or use hard coded addresses. This tutorial will mostly discuss the hard coded method. The only DLL that is guaranteed to be mapped into the shellcode's address space is kernel32.dll. This DLL will hold LoadLibrary and GetProcAddress, the two functions needed to obtain any functions address that can be mapped into the exploits process space. There is a problem with this method though, the address offsets will change with every new release of Windows (service packs, patches etc.). So, if you use this method your shellcode will ONLY work for a specific version of Windows. Further dynamic addressing will be referenced at the end of the paper in the Further Reading section.
The article you quoted focuses on getting the address of the function. You still need the function prototype of the function (which doesn't change across versions), in order to generate the code for calling the function - with appropriate handling of input and output arguments, register values, and stack.
The windows.h header provides the function prototype that you wish to call to the C/C++ compiler, so that the code for calling the function (the passing of arguments via register or stack, and getting the function's return value) can be generated.
After knowing the function prototype by reading windows.h, a skillful assembly programmer may also be able to write the assembly code to call the Sleep function. Together with the function's address, these are all you need to make the function call.
With some black magic you can ;). there have been many custom implementations of GetProcAddress, which would allow you to get away with not needing windows.h, this however isn't be all and end all and could probably end up with problems due to internal windows changes. Another method is using toolhlp to enumerate the modules in the process to get kernel.dll's base, then spelunks its PE for the EAT and grab the address of GetProcAddress. from there you just need function pointer prototypes to call the addresses correctly(and any structure defs needed), which isn't too hard meerly labour intensive(if you have many functions), infact under windows xp this is required to disable DEP due to service pack differencing, ofc you need windows.h as a reference to get this, you just don't need to include it.
You'd still need to declare the function in order to call it, and you'd need to link with kernel32.lib. The header file isn't anything magic, it's basically just a lot of function declarations.
I can do it with 1 line of assembly and then some helper functions to walk the PEB
file by hard coding the correct offsets to different members.
You'll have to start here:
static void*
JMIM_ASM_GetBaseAddr_PEB_x64()
{
void* base_address = 0;
unsigned long long var_out = 0;
__asm__(
" movq %%gs:0x60, %[sym_out] ; \n\t"
:[sym_out] "=r" (var_out) //:OUTPUTS
);
//: printf("[var_out]:%d\n", (int)var_out);
base_address=(void*)var_out;
return( base_address );
}
Then use windbg on an executable file to inspect the data structures on your machine.
A lot of the values you'll be needing are hard to find and only really documented by random hackers. You'll find yourself on a lot of malware writing sites digging for answers.
dt nt!_PEB -r #$peb
Was pretty useful in windbg to get information on the PEB file.
There is a full working implementation of this in my game engine.
Just look in: /DEP/PEB2020 for the code.
https://github.com/KanjiCoder/AAC2020
I don't include <windows.h> in my game engine. Yet I use "GetProcAddress"
and "LoadLibraryA". Might be in-advisable to do this. But my thought was the more
moving parts, the more that can go wrong. So figured I'd take the "#define WIN32_LEAN_AND_MEAN" to it's absurd conclusion and not include <windows.h> at all.