I debug a code, and I use _set_purecall_handler to set function that be called when pure call virtual function happened. This exemple from MSDN work nice for me and do what I want: code from msdn
So, you can see the declaration of the function
void myPurecallHandler(void)
{
printf("In _purecall_handler.");
exit(0);
}
this function MUST return a void value and don't have any arguments, this function is called when a pure call virtuall function happened. I have trying to overload this function to passe it a parameters (The line number where pure call virtuall function happened ), but can't success.
If you see, there is another function there: _set_purecall_handler_m
What is the difference between this function and _set_purecall_handler?
Thanks a lot,
_set_purecall_handler_m is for use with mixed mode CRT when using C++ and C++-CLI. If you are not working with C++-CLI you really don't need to use it. If however you are creating say a DLL that may be used with C++-CLi applications you might want to consider using it.
Related
I have a DLL I was handed down by a device manufacturer.
I can effortlessly call all its functions from a MS Console application (not from Qt or C++ Builder) but not from an MFC/WinAPI application? In an effort to work around the problem, I'm exploring the LoadLibrary() route. I am experimenting with this code, in VS2019 :
HINSTANCE hInstance = LoadLibrary(L"DEVICE.dll");
int(*fnDLLFuncAddress)(void) = (int(*)(void))GetProcAddress(hInstance2, "Device_RegisterDeviceEventHandler");
I have the impression that the code is working since this is the fnDLLFunAddress content :
fnDLLFuncAddress = DEVICE.dll!0x00007ffa66adda20 (load symbols for additional information)
Two questions, if I may. First, where would I look for "load symbols for additional information"? And the second, less obvious, is, once I have the Function address, in the form of a pointer, do I simply use the explicitely linked function name in lieu of the original function call to the DLL?
To start the program, I need to launch the following Event Handler, defined this way :
DEVICE_ERROR_TYPES __stdcall FPtr_Device_RegisterDeviceEventHandler(const FPtr_DeviceEventHandler inHandler);
In main(), the way I'm expected to launch the DeviceHandler is with this call :
deviceError = fnDLLFuncAddress(EventNotice);
Where "deviceError" is defined in DEVICE_ERROR_TYPES enum.
The EventNotice function is defined this way :
void EventNotice(EventCode outEventCode, uint32 outRAWDataCount, DEVICE_ERROR_TYPES outError);
When I try to execute the call, the compiler complains with E0140 "Too many arguments in function call" and E0513 "a value of type "int" cannot be assigned to an entity of type "DEVICE_ERROR_TYPES".
My intuition tells me I should try supplying the "EventNotice" function address in the function call? Is it simply a matter of "dereferencing" the function name like "*EventNotice"?
If this was to work, I guess I'd still have to resolve the "incompatible" return type of the RegisterDeviceHandler call?
Any help is appreciated.
=== additional note ===================
The reason I'm having difficulty, I think, is because I am unable to replicate the original "RegisterDeviceHandler" function prototype?
With GetProAddress(), I'm able to get a pointer to the function address in the DLL but that does not give me the corresponding "function declaration"?
I'm working on creating a user-level thread library and what I want to do is run a function inside a stub and so I would like to pass the function pointer to the stub function.
Here is my stub function:
void _ut_function_stub(void (*f)(void), int id)
{
(*f)();
DeleteThread(id);
}
This is what the user calls. What I want to do is get pointer of _ut_function_stub to assign to pc and I've tried various different options including casting but the compiler keeps saying "invalid use of void expression".
int CreateThread (void (*f) (void), int weight)
{
... more code
pc = (address_t)(_ut_function_stub(f, tcb->id));
... more code
}
Any help is appreciated. Thanks!
If you're interested in implementing your own user-level-threads library, I'd suggest looking into the (now deprecated) ucontext implementation. Specifically, looking at the definitions for the structs used in ucontext.h will help you see all the stuff you actually need to capture to get a valid snapshot of the thread state.
What you're really trying to capture with the erroneous (address_t) cast in your example is the current continuation. Unfortunately, C doesn't support first-class continuations, so you're going to be stuck doing something much more low-level, like swapping stacks and dumping registers (hence why I pointed you to ucontext as a reference—it's going to be kind of complicated if you really want to get this right).
I have a DLL given named Lib.ddl. In the dll i have a function named add that takes an integer as a parameter.
Using the windows API and by using the following class.
class WindoswAPI
{
public:
WindowsAPI();//constructor
//helper functions
~WindowsAPI();
private:
}
How do I load this library in the constructor of the class. Extract the function via helper functions, and unload the function in the destructor?
I have looked on the internet for solutions and help but i cant find any.
You should first look at LoadLibraryEx() in order to load the dll in your process, then you can use GetProcAddress() to obtain a pointer to a function by name. Note the HMODULE parameter requested from the second function is returned by the first. You have to carefully know the function signature to invoke it without causing GPFs, so don't be surprised if you have to do some debug before having it working.
First easy thing to check anyway are the return values of both functions: the first one should return something different from zero ( it actually returns the virtual address where the dll is loaded ), if it returns NULL, use GetLastError to have some hints.
The same for GetProcAddress, if it return zero something didn't work, and usually is the incorrect spelling of the function name. As I said before having back an address from GetProcAddress does not guarantee you have finished: you must know perfectly how to call the function. If you need help in discovering which name are exposed from the dll, you will find useful DUMPBIN.EXE, you should have it already available from the Visual Studio Tools command prompt.
When your code finish with the dll, you can try to unload it by using FreeLibrary().
Look at POCO C++ Libraries, it contains very nice crossplatfrom DLL-Loader to avoid hand-written workarounds and boilerplate.
I've recently been working on detouring functions (only in Linux) and so far I've had great success. I was developing my own detouring class until I found this. I modernized the code a bit and converted it to C++ (as a class of course). That code is just like any other detour implementation, it replaces the original function address with a JMP to my own specified 'hook' function. It also creates a 'trampoline' for the original function.
Everything works flawlessly but I'd like to do one simple adjustement. I program in pure C++, I use no global functions and everything is enclosed in classes (just like Java/C#). The problem is that this detouring method breaks my pattern. The 'hook' function needs to be a static/non-class function.
What I want to do is to implement support for _thiscall hooks (which should be pretty simple with the GCC _thiscall convention). I've had no success modifying this code to work with _thiscall hooks. What I want as an end result is something just as simple as this; PatchAddress(void * target, void * hook, void * class);. I'm not asking anyone to do this for me, but I would like to know how to solve/approach my problem?
From what I know, I should only need to increase the 'patch' size (i.e it's now 5 bytes, and I should require an additional 5 bytes?), and then before I use the JMP call (to my hook function), I push my 'this' pointer to the stack (which should be as if I called it as a member function). To illustrate:
push 'my class pointer'
jmp <my hook function>
Instead of just having the 'jmp' call directly/only. Is that the correct approach or is there something else beneath that needs to be taken into account (note: I do not care about support for VC++ _thiscall)?
NOTE: here's is my implementation of the above mentioned code: header : source, uses libudis86
I tried several different methods and among these were JIT compile (using libjit) which proved successful but the method did not provide enough performance for it to be usable. Instead I turned to libffi, which is used for calling functions dynamically at run-time. The libffi library had a closure API (ffi_prep_closure_loc) which enabled me to supply my 'this' pointer to each closure generated. So I used a static callback function and converted the void pointer to my object type and from there I could call any non-static function I wished!
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.