19 replies to this topic

[Nick]

Hi all,

I was wondering whether this C++ code has any C# equivalent:

void main()

{

    unsigned char function[] = {0x90,    // NOP (no operation)

                                0xC3};   // RET (return)


    typedef void(*VoidFunction)();


    ((VoidFunction)&function)();

}

This is the first step towards run-time code generation. I've read about delegates and unsafe pointers, but this would require a real function pointer to native code. Any ideas?

Thanks!

Nick

[Axel]

I don't think that's possible. C# is a purely managed language.

If you want to do something like that from C# you likely need a C++/CLI class.

[Ed Mack]

Would something like this not do the job (albeit with a huge overhead compared to c++) scroll a bit down to 'high-level assembler':
http://www.codeproje...egenruntime.asp

[kariem2k]

Hi Nick
I don't think that there is inline assembly nor function pointers in c# so this is a solution that came to my mind you can write your unmanged c++ code , assembly or shellcode in unmanaged DLL and call functions in it using Interop Services in C#.
i hope i have helped.

[Nick]

Thanks! Would it be possible to pass a C# memory buffer filled with x86 binary code to a native DLL and execute it there?

[dave_]

You can do whatever you want once you're in the DLL

Search for "C# DLLimport"

Of course windows wont let you run arbitary code.
You have to allocate a buffer and change the protection on it.
I cant remember the particular code

[kariem2k]

Sure
see this article from microsoft
http://msdn2.microso...y/bd99e6zt.aspx
Also see
http://www.pinvoke.net/ for listing of most Windows API for using with c#'s pinvoke.
and like dave said you should reallocate the buffer in the native DLL and copy the passed contents to that new buffer to use it.

[Axel]

Nick said:

Thanks! Would it be possible to pass a C# memory buffer filled with x86 binary code to a native DLL and execute it there?

I would really recommend using C++/CLI for such things. Its much easier to handle. Since .NET allows to mix languages freely you can do that stuff in a C++/CLI class (C++/CLI allows to mix managed and unmanaged code) and use that one in C#.

[roel]

Axel said:

I would really recommend using C++/CLI for such things. Its much easier to handle. Since .NET allows to mix languages freely you can do that stuff in a C++/CLI class (C++/CLI allows to mix managed and unmanaged code) and use that one in C#.

Well, I have the feeling that Nick is aiming for a softwire-alike system for c# :) (which isn't a bad idea at all, imho)

[Nick]

roel said:

Well, I have the feeling that Nick is aiming for a softwire-alike system for c# :) (which isn't a bad idea at all, imho)

Exactly. I wish to combine the nice language that is C# with the incredible power offered by soft-wiring technology. C++ is great too but it has clear flaws and stopped evolving...

[.oisyn]

C++ hasn't stopped evolving, but besides that, C++/CLI has a lot of new features that can be used on the unmanaged side as well

[juhnu]

.oisyn said:

C++ hasn't stopped evolving, but besides that, C++/CLI has a lot of new features that can be used on the unmanaged side as well :)

I would do a thin wrapper with the C++/CLI, which then uses a native dll. C++/CLI is definitely a real improvement compared to the Managed C++, but as it being a new technology there might be some bugs and not sure the quality of the compiled code either. At least the Managed C++ is almost useless for a real production use because of that (like calling destructors twice for an object in some cases...).

[Prozac]

kariem2k said:

Hi Nick
I don't think that there is inline assembly nor function pointers in c# so this is a solution that came to my mind you can write your unmanged c++ code , assembly or shellcode in unmanaged DLL and call functions in it using Interop Services in C#.
i hope i have helped.

C# can use the reflection classes to use MSIL inline generally speaking and
I do believe C# has function pointers but I'm not entirely sure (unsafe code is so much fun!!)

As for the main question, NO you CANNOT use native assembly in managed
languages since the binaries are compiled to a high-level assembler which in
turn are compiled to native assembler by the JIT engine upon execution.

You can probably use C++ with Managed Extensions to use assembler but
for most projects I wouldn't recommend it since you'll be breaking that wonderful
cross-platformness that C# has (assuming you have an environment on that platform such as .NET, ROTOR, DotGnu, or Mono).

[kariem2k]

Prozac:
I am afraid you did not understand me.
inline assembly is machine asm not the MSIL that can be written inside your c,c++ code directly.

Quote

As for the main question, NO you CANNOT use native assembly in managed
languages since the binaries are compiled to a high-level assembler which in
turn are compiled to native assembler by the JIT engine upon execution.

You can use(not include) native(unmanged) Dlls in c# just with DllImport attribute you can call any function from any Unmanaged dll,Microsoft has to do that to enable the programmers to use windows API.

Quote

You can probably use C++ with Managed Extensions to use assembler but
for most projects I wouldn't recommend it since you'll be breaking that wonderful
cross-platformness that C# has (assuming you have an environment on that platform such as .NET, ROTOR, DotGnu, or Mono).

I don't think he want to make his app cross-platform because of a simple thing shellcodes are not portable like any low level assembly application,you need much work to make it portable.

[Axel]

juhnu said:

I would do a thin wrapper with the C++/CLI, which then uses a native dll.

You don't need the native DLL. C++/CLI allows switching from managed to unmanaged code on the function level (the compiler will do that for you).

[juhnu]

Axel said:

You don't need the native DLL. C++/CLI allows switching from managed to unmanaged code on the function level (the compiler will do that for you).

Yeah I know that, but you have to do marshalling between .NET and native C++ types at some point anyway. If you separate your code for different dlls it's pretty easy to know what is actually compiled to IL and what not. Also as the C++/CLI is really new technology it probably has some bugs, which might make a larger use unpractical for the time being - it's predecessor the Managed C++ suffered from this very problem.

[.oisyn]

Quote

Also as the C++/CLI is really new technology it probably has some bugs

Well it's not that new, technically it's just managed C++ with a revised syntax. The fundamentals are basically the same.

[juhnu]

.oisyn said:

Well it's not that new, technically it's just managed C++ with a revised syntax. The fundamentals are basically the same.

So are the bugs too? ;) Seriously C++/CLI is a language on it's own right and addresses many shortcomings of the Managed C++. You are making it sound
merely like a face-lift.

[Nick]

Axel said:

You don't need the native DLL. C++/CLI allows switching from managed to unmanaged code on the function level (the compiler will do that for you).

Interesting! I haven't looked at C++/CLI yet.

So is C++/CLI undisputably better than unmanaged C++? I mean, could it replace it completely? Does it inherit unmanaged C++'s flaws or is it more like C# with unmanaged support?

Thanks. :happy:

[.oisyn]

juhnu said:

So are the bugs too? Seriously C++/CLI is a language on it's own right and addresses many shortcomings of the Managed C++.

Well most of the shortcomings were actually in the syntax itself. And sure it's new, as it also targets .Net 2.0 while Managed C++ only targets 1.1, and it has some more interesting new features. And it's a language on it's own because MS took the liberty to standardize it at ECMA, but that has got nothing to do with the actual implementation of course .

But under the hood, like pinning pointers for example and the rest of the interface with .Net itself, they're very similar.