How to get CLR from CPP

Rhino Developer
21

I’m still not sure I understand the use case, since bongo already has an sdk, with headers and libs, which you would need to wrap for dotnet access, if that is what you are after. Before even getting into the dotnet stuff, you would probably want to create a working c++ rhino plugin that makes use of the bongo sdk. With that working, you could then proceed to wrap the bongo interfaces you need for dotnet, and from there, try using your wrapper from a dotnet rhino plugin.

Regarding LoadLibrary, it works just like all the examples you will find: you make the call, and check GetLastError in case of failure. Upon success, it is assumed that you have special knowledge of the functions exported by the dll, and will obtain pointers to call them, via GetProcAddress.

22

Ok, forget the Bongo example, I guess it was bad example since McNeel are very generous to allow us to write plugins without paying extra.

The application I’m trying to extend with dotnet isn’t. You pay very high price for developer license. I am have good ideas on extending the software but I do not agree one should pay that much to extend whatever software. Given the fact that a software almost never meets all industry requirements.

Anyways, so far I’ve done this:

  • I was able to run the CLR showing that msg from native application.
  • I was able to use pinvoke with c#.
  • I was able to create a c# wrapper of a c++ dll using pinvoke and using that wrapper with IronPython.
  • I managed to LoadLibrary a c++ dll and call a function from inside it, printing the result. I found the name of the function using
    image

The dll I loaded was created by me funny how the name I gave to that function wasn’t the same when I got it from DLL Export Viewer. I had to use the name from DLL Export Viewer to call it from the memory address.

I assume now, I have to create some sort of c# wrapper of that function and pass it somehow to the CLR.

Is there C++ and C# way of args*, kwargs** - create a universal wrapper no matter of the number of arguments?

PS: for calling the function I used an example I’ve found does the * by any chance mean an instance in c++?
I understood that ~ in front of a name of a class means abstract class or something like that.

// runtime_dynamic_linking.cpp : This file contains the 'main' function. Program execution begins and ends there.
//

#include "pch.h"
#include <iostream>
// A simple program that uses LoadLibrary and 
// GetProcAddress to access myPuts from Myputs.dll. 

#include <windows.h> 
#include <stdio.h> 

#include <string>
using namespace std;

typedef int(__cdecl *MYPROC)(LPCWSTR);

int main(void)
{
	HINSTANCE hinstLib;
	MYPROC ProcAdd;
	BOOL fFreeResult, fRunTimeLinkSuccess = FALSE;

	// Get a handle to the DLL module.
	//Z:\\zooid\\Cpp\\NativeLib_FAIL\\NativeLib_FAIL.dll
	hinstLib = LoadLibrary(TEXT("Z:\\zooid\\Cpp\\NativeLib_FAIL\\NativeLib_FAIL.dll"));

	// If the handle is valid, try to get the function address.

	if (hinstLib != NULL)
	{
		ProcAdd = (MYPROC)GetProcAddress(hinstLib, "_Z5z_sumdd");

		// If the function address is valid, call the function.

		if (NULL != ProcAdd)
		{
			fRunTimeLinkSuccess = TRUE;

			// calling the function
			typedef double func(double, double);
			func* f = (func*)ProcAdd;
			double i = f(1, 2);

			printf("%f",i); //using "%f" to print a float

			//(ProcAdd)(L"1,2");
			printf("we're in!");
		}
		// Free the DLL module.

		fFreeResult = FreeLibrary(hinstLib);
	}

	// If unable to call the DLL function, use an alternative.
	if (!fRunTimeLinkSuccess)
	{
		printf("Message printed from executable\n");
	}
	return 0;

}

NativeLib_Fail.7z (27.6 KB)

23

Yes, the name of your function was mangled – since c++ supports namespaces, classes, and overloaded functions, it cannot use a function name as-is in object code, so mangles it according to some internal rules. This is also why we use extern “C” on functions we wish to export for pinvoke (c does not support overloading, so mangling is not done).

This is going to provide your first big hurdle, since if the software company is not giving you any headers or libs, then while you may be able to retrieve the mangled function names using a tool like that, you will still not know the function signatures. For trivial cases it may be possible to correctly determine the signature, but we don’t know that, especially as the library in question is not your own (see here for a taste of what you’re up against)

However, let’s say for sake of argument that you are able to demangle all functions you want to call, with their signatures. Well, with those in hand, you may as well directly pinvoke them, and use your native dll solely for hosting the clr – you know the dll they come from, since that’s the same one from which you just retreived and demangled names, so you can make the pinvoke declarations. Your native dll is only the hook you need to get injected into the process, and spin up the clr.

I must say at this point, for you or anyone reading this, that this is all completely unsuitable (for reasons which should be obvious by now) for anything but personal toy code. You don’t own the dll, and even if you could decode all its functions, you cannot know when they may change. Depending, it may also be risky in the sense that it could be against the non-developer license, to reverse-engineer an API that is otherwise officially provided under an available developer license.

Regarding something like args*,kwargs** in c/c++, there is indeed support for something like this (variadic functions), for example as you see with printf(const char*,…). However it is not something that will just magically do what you want here. When we talk about writing wrapper functions, we mean, using pinvoke to take a native function and expose it in dotnet, carefully and correctly translating (marshalling, we say) data between the two worlds. This is hard work, and there is not as yet any silver bullet I’m aware of, except in cases where it is acceptable to use c++/cli.

The * in c and c++ means pointer to. So you may have an int, and then also an int* that points to it. In the code you have above, you have used typedef to delcare a function signature named func, and then you have cast the result of GetProcAddress to func*, or pointer to func, and then called it.

And a tilde in front of a class name marks the class destructor method:

class MyClass
{
public:
    MyClass() { /* constructor */ }
   ~MyClass() { /* destructor */ }
};
2 Likes
24

Thanks a lot @jdhill,

This is how books should be written. In a simple language.

Btw, how is what I am trying to do reverse engineering? I am not disassembing anything. I am also not injecting my dll, since it is automatically added to the scope by referencing one of app’s original dlls. I am not running the application and “invading” its “memory address”.

I tried using COM but that is a total nightmare to work with. Everything I try is either abstract or not callable. I have to recreate the whole API which for a single person with limited knowledge of programming would take (a) decade(s).

25

Whether you are reverse-engineering would be in the eye of the beholder, so I am just saying that given the company charges money for a developer license, it’s not inconceivable they might react badly (whatever that may mean, say, refuse to renew your non-developer license) to your efforts, were you to make them public.