[Mono-dev] mkbundle & Assembly.GetEntryAssembly()
rtillerywork at gmail.com
Tue May 16 00:48:57 UTC 2017
Thanks! That looks like it might work in C# (we don't really have any C in
this project). I'll give it a try.
However, I respectfully disagree that the path to the assembly is a good
choice. I understand that the Linux binary isn't the same as the .Net
assembly, but the EXE file is not there at all.
Worse, if I place the properly signed EXE in the directory on the target
machine with the Linux binary (at the path provided by GetEntryAssembly()),
the validation passes. This occurs even if the Linux binary has no code
from the EXE (just the same name at mkbundle time). That's not really a
very good validation.
Given that I can identify which platform I'm on, I can modify the
validation code to recognize the container/binary differences. But that has
to start with being able to locate the actual file that is the entry point.
(Your suggestion may get us there. Thanks again.)
With a path to the actual entry point, I'm guessing I'll have the choice of
locating the embedded EXE PE/COFF within the ELF & checking it as usual, or
introducing a new signing/validation approach on the Linux ELF binary
level. (Not sure of the implications of these two approaches yet.)
On May 15, 2017 7:17 PM, "Robert Jordan" <robertj at gmx.net> wrote:
> On 15.05.2017 21:14, Rick Tillery wrote:
>> The problem is that this means the entry assembly being returned is not
>> the actual entry point, and I don't see a way to determine the assembly
>> that is the correct entry point.
> This is by design. From the point of view of the Mono runtime,
> the entry assembly is actually that one that was passed to mkbundle.
> It would make little sense to modify the code base of the
> main assembly to point to the native executable of the bundle,
> because you won't be able to load this file anyway, as
> it isn't an assembly anymore.
> If you're only interested in the code base path you may want to
> look how it's done natively:
> Mono-devel-list mailing list
> Mono-devel-list at lists.dot.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list