Adding native code to .Net-file

  • Thread starter Thread starter =?ISO-8859-1?Q?Daniel_D=FCnker?=
  • Start date Start date
?

=?ISO-8859-1?Q?Daniel_D=FCnker?=

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
 
Daniel Dünker said:
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) ?
Click to expand...

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
 
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) ?
Click to expand...
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
 
William said:
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
Click to expand...
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
 
Daniel Dünker said:
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
Click to expand...

Why do you feel the ned to resort to hackery?

Regards,
Will
 
Daniel said:
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
Click to expand...

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.
Click to expand...

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) ?
Click to expand...

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
 
William said:
Why do you feel the ned to resort to hackery?

Regards,
Will
Click to expand...

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

-Daniel
 
Richard said:
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.




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.




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
Click to expand...

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
 
Back
Top