2

The problem seems to be in the source address calculation: &ImportDescriptor.Name + (uintptr_t)ModuleBase This adds the address of a local variable (which is on the stack) to the image base, so the result is probably some non-existent address. You should add its value, which is an RVA, to the image base. I.e. something like this: memcpy(&LibraryName,...


1

So, it turns out that if you're testing an IAT hook on a driver, the driver must be compiled in the release mode rather than in the debug one. If the driver is compiled in the debug mode, the RVA for the Import Descriptor seems to be wrong. But the issue is resolved with compiling in the release rather than in the debug mode. Thanks to all for the help.


1

This is unfortunately not going to be an answer, because you don't give enough information. If I end up writing an answer, it will be a different one. So long I'll make this non-answer a community wiki, attempting to give clues, ask for details and point to resources. Correct me if I'm wrong but since kernel drivers share the same address space I can just ...


1

Here is the solution: The constructor can be called like this: gladius::GameStruct* thisptr = (gladius::GameStruct*)malloc(sizeof(gladius::GameStruct)); gladius::get().gameConstructor(thisptr); where sizeof(GameStruct) must match the size of the original constructor. In my case the Game structure should be re-written to have something like: struct ...


1

This is been resolved here: Link So, the solution is to introduce the class structure functionally the same as the original one and then use the original constructor function to populate it. If the objects of the other classes, i.e. GUI object as a 5th element of the above structure needs to be initialised, then GUI object has to have a proper class ...


Only top voted, non community-wiki answers of a minimum length are eligible