[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AW: [DotGNU] Introduction

From: Rhys Weatherley
Subject: Re: AW: [DotGNU] Introduction
Date: Wed, 27 Mar 2002 22:59:09 +1000

Carsten Kuckuk wrote:

> (1) Each .NET module (hello.exe) contains a small piece of 80386 code known
> as the PE stub that simply calls ta function named _CorExeMain() exported by
> the mscoree.dll. [...]

Auto-launching pnet by way of a replacement mscoree.dll
is doable, certainly.  However, it may not be the best idea.

The PE stub is the reason why there are now .NET viruses
such as Win32.Donut.  If we did what you suggest, then
GNU/Linux would become vulnerable to these same viruses.

A better approach may be to modify Wine to recognise the
IL header fields, and then hand off the entire binary to
Portable.NET for execution.  i.e. it doesn't execute the
PE binary directly, and hence prevents virus code in the
stub from activating.

It's easy to detect if a PE binary is actually IL.  There is
a field in the PE header that is present in IL binaries, but
not in regular PE binaries.  There shouldn't be much code
needed in Wine to handle this.

Wine usually hooks itself into the Linux kernel using the
binfmt extension.  i.e. it tells the kernel to hand off PE
binaries to the "wine" executable.  The scenario above
describes Wine handing off PE binaries to pnet that are
actually IL.

But we can also do the same in reverse.  Portable.NET
is installed as the primary binfmt handler with the kernel.
If it is given an IL binary, it processes it itself.  If it detects
a regular PE binary, it hands it off to Wine.  No modifications
are needed to Wine in this scenario.

There is currently some support for binfmt in ilrun, but it
isn't working for some reason.  Barry has been looking
into this, but we need a Linux kernel expert to help us
figure out why it doesn't work.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]