Adding native code to .Net-file

[Daniel Dünker]

Hello.

I was screwing around a bit with the exe-files produced by .Net
Compilers and trying to understand how they work... so i ended up at the
6 Byte stub, which calls the _CorExeMain in mscoree.dll ... so i thought
"Hey, thats how it tells the Framework, that it shall load it as .Net
programm...". So i build some native code into it which should have been
executed before the .Net programm itself gets loaded. Trying that on a
XP-Machine, i realized, that it did not work quite the way i expected it
to. So after some research i found out, that it would possibly work on
any other system than XP, because of the executable-loader, which was
designed with .Net in mind. So the XP executable-loader does realize by
himself that the programm is designed for .Net and it becomes loaded
immediatly, without the native code in it being executed. Also i read,
that the loader knows that by reading the 14. directory in the
PE-Header, and thinks it is .Net, when the 14. directory exists and is
not 0. So i tried to replace both the offset and size in the 14.dir.
with 0 and my native code got loaded.... but then the .Net-Part of the
programm did not get loaded, so i was pretty much staring at my screen
and not knowing what to do then. So i finally end up here and ask the
question: Is there actually a way to burry my native code in a .Net
programm and have both of the code loaded (.Net AND native) ?

Thanks in advance,
Daniel

[William DePalo [MVP VC++]]

"Daniel Dünker" <dd******@uni-koblenz.de> wrote in message
news:dq******** **@cache.uni-koblenz.de...

So i finally end up here and ask the question: Is there actually a way to
burry my native code in a .Net programm and have both of the code loaded
(.Net AND native) ?

Both Managed C++ (VS2003) and C++/CLI (VS2005) allow you to mix native and
managed code in the same executable. In fact you can mix modes in the same
module.

As far as I know, there is no other .Net language of MS that allows you to
do that.

Regards,
Will

[rossum]

On Sat, 14 Jan 2006 01:17:05 +0100, Daniel Dünker
<dd******@uni-koblenz.de> wrote:

So i finally end up here and ask the
question: Is there actually a way to burry my native code in a .Net
programm and have both of the code loaded (.Net AND native) ?

William has given a very good answer. For a more hacker-type answer
just put something on the end of your native code to start off the
..NET code.

rossum

--

The ultimate truth is that there is no ultimate truth

[Daniel Dünker]

William DePalo [MVP VC++] wrote:

"Daniel Dünker" <dd******@uni-koblenz.de> wrote in message
news:dq******** **@cache.uni-koblenz.de...

So i finally end up here and ask the question: Is there actually a way to
burry my native code in a .Net programm and have both of the code loaded
(.Net AND native) ?

Both Managed C++ (VS2003) and C++/CLI (VS2005) allow you to mix native and
managed code in the same executable. In fact you can mix modes in the same
module.

As far as I know, there is no other .Net language of MS that allows you to
do that.

Regards,
Will

My intention was to to alter the executable after compilation, because
the compiler leaves some space in which i could burry lots of native
code after the 6 byte stub which loads the mscoree.dll

-Daniel

[William DePalo [MVP VC++]]

"Daniel Dünker" <dd******@uni-koblenz.de> wrote in message
news:dq******** **@cache.uni-koblenz.de...

My intention was to to alter the executable after compilation, because the
compiler leaves some space in which i could burry lots of native code
after the 6 byte stub which loads the mscoree.dll

Why do you feel the ned to resort to hackery?

Regards,
Will

[Richard Grimes]

Daniel Dünker wrote:

Hello.

the executable-loader, which was designed with .Net in mind. So the
XP executable-loader does realize by himself that the programm is
designed for .Net and it becomes loaded immediatly, without the
native code in it being executed. Also i read, that the loader knows
that by reading the 14. directory in the PE-Header, and thinks it is
.Net, when the 14. directory exists and is not 0. So i tried to
Yup location 14 is the 'COM Descriptor Directory' which actually means
that the file is managed, you get the table pointed to by this directory
with dumpbin /clrheader.
replace both the offset and size in the 14.dir. with 0 and my native
code got loaded.... but then the .Net-Part of the programm did not
get loaded, so i was pretty much staring at my screen and not knowing
what to do then.
Naughty. You have become a virus by injecting your own code into the
process. It is for this very reason that on XP and later the unmanaged
entry point is not used. When a managed file is loaded there is no way
that native code will be run outside of .NET security.
So i finally end up here and ask the question: Is
there actually a way to burry my native code in a .Net programm and
have both of the code loaded (.Net AND native) ?

Not really. You could write your own host, but that will mean that your
users will have to run your host process instead of the process you are
trying to hijack. If the assembly calls native code through managed C++
IJW it is possible for you to change the address held in metadata to
point to your code, but any code that runs IJW must have code access
security full trust.

If an assembly has a strong name then as a side affect the hash of the
assembly is checked against the strong name and this will detect any
alterations you have done to the metadata (however on 1.0 and 1.1 it is
possible to further alter an assembly to prevent this check).

Richard
--
Fusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm
Security Tutorial:
http://www.grimes.demon.co.uk/workshops/securityWS.htm

[Daniel Dünker]

William DePalo [MVP VC++] wrote:

"Daniel Dünker" <dd******@uni-koblenz.de> wrote in message
news:dq******** **@cache.uni-koblenz.de...

My intention was to to alter the executable after compilation, because the
compiler leaves some space in which i could burry lots of native code
after the 6 byte stub which loads the mscoree.dll

Why do you feel the ned to resort to hackery?

Regards,
Will

Well, i saw all the free space in it, and wondered, if it could be of
any use :)

-Daniel

[Daniel Dünker]

Richard Grimes wrote:

Daniel Dünker wrote:

Hello.

the executable-loader, which was designed with .Net in mind. So the
XP executable-loader does realize by himself that the programm is
designed for .Net and it becomes loaded immediatly, without the
native code in it being executed. Also i read, that the loader knows
that by reading the 14. directory in the PE-Header, and thinks it is
.Net, when the 14. directory exists and is not 0. So i tried to

Yup location 14 is the 'COM Descriptor Directory' which actually means
that the file is managed, you get the table pointed to by this directory
with dumpbin /clrheader.

replace both the offset and size in the 14.dir. with 0 and my native
code got loaded.... but then the .Net-Part of the programm did not
get loaded, so i was pretty much staring at my screen and not knowing
what to do then.

Naughty. You have become a virus by injecting your own code into the
process. It is for this very reason that on XP and later the unmanaged
entry point is not used. When a managed file is loaded there is no way
that native code will be run outside of .NET security.

So i finally end up here and ask the question: Is
there actually a way to burry my native code in a .Net programm and
have both of the code loaded (.Net AND native) ?

Not really. You could write your own host, but that will mean that your
users will have to run your host process instead of the process you are
trying to hijack. If the assembly calls native code through managed C++
IJW it is possible for you to change the address held in metadata to
point to your code, but any code that runs IJW must have code access
security full trust.

If an assembly has a strong name then as a side affect the hash of the
assembly is checked against the strong name and this will detect any
alterations you have done to the metadata (however on 1.0 and 1.1 it is
possible to further alter an assembly to prevent this check).

Richard

Wow, thats quite a satisying answer. Thanks for the work you had with
this one. Sad, that all this space seems to be wasted. Also it seems,
that because of the things you mentioned the usual executable packers
are not able to get rid of this waste...

Thank you very much for your answer
-Daniel