Re: Detecting native .NET types by Leon
Leon
Mon Jul 21 23:13:06 CDT 2008
how about checking the public key token?
it's not foolproof, but assembly.GetName().GetPublicKeyToken() will be a
byte array : b77a5c561934e089 for Microsoft signed assemblies.
I don't think there is a foolproof method for all the reasons everyone else
has given. I suspect the best answer is as already given - to just grit your
teeth and write up a big list of all the assemblies you need to identify,
and consider some other heuristics to make a good guess as to the origin of
the assembly in question.
you could check the copyright and company too...eg
object[] atts =
assembly.GetCustomAttributes(typeof(AssemblyProductAttribute), false);
if (atts != null && atts.Length == 1)
{
if(false == String.Equals(
((AssemblyProductAttribute)atts[0]).Product,
"Microsoft® .NET Framework"))
{
return false;
}
}
// passed product attribute test...
and the AssemblyCompanyAttribute.Company will be Microsoft Corporation.
Now I suspect all of this could be bluffed somehow, but somebody would have
to be seriously trying hard to mess with your product to achieve it - this
won't happen by accident - it depends how big a deal it is if you get a
false positive because somebody's trying to hack your software.
L
"Michael D. Ober" <obermd.@.alum.mit.edu.nospam.> wrote in message
news:eqqdnWmUcezezxjVnZ2dnUVZ_uudnZ2d@earthlink.com...
> "John W." <no_spam@_nospam.com> wrote in message
> news:%23j%23vQ756IHA.1200@TK2MSFTNGP04.phx.gbl...
>>>> Thanks for the suggestion. I don't think it will fly unfortunately.
>>>> It's too
>>>> imprecise and therefore subject to failure (anyone can apply "System"
>>>> or any
>>>> other namespace to their type and nothing's stopping them from
>>>> installing a
>>>> 3rd-party assembly in the system folder - rare as this might be).
>>>
>>> Well, I think the latter is actually more likely. It seems like a
>>> legitimate installation behavior for certain kinds of software.
>>>
>>> But the former seems very unlikely except in the case of willful
>>> impersonation. And if you're concerned about that, then there's not
>>> really anything you can do to avoid someone bypassing your check.
>>
>> The real issue to me is that both techniques are hacks. While the
>> namespace suggestion would probably work in practice, it's cleaner and
>> safer to rely on "legitimate" techniques. I do appreciate his suggestions
>> however :)
>>
>>> Unfortunately, your unwillingness to describe the problem further makes
>>> it difficult to offer suggestions.
>>
>> I can't for reasons beyond my control.
>>
>>> If this is a tool to aid the user, I think that there are things like
>>> what Arne suggests as well as just looking at what the input to the
>>> tool is (i.e. types that are part of assemblies the user doesn't
>>> specifically provide to the tool are inferred to be .NET types).
>>
>> There's more to the story which is why I can't just use a "process of
>> elimination" technique. All I really need is a clean way to make the
>> determination given the "System.Type" itself (or even its
>> assembly-qualified name).
>>
>>> If you're looking for some sort of secure analysis of the code, then I
>>> think the best you can do is build your own "white list" of .NET
>>> assemblies and base the analysis on that. And even in that case,
>>> someone who wants to would be able to hack your tool in order to get it
>>> to produce whatever results _they_ want rather than the results you
>>> wanted.
>>
>> I'm not going to worry about hackers. That's always an issue but my code
>> is already reasonably secure (very painful to hack anyway).
>>
>
> You're making this too hard. Simply install the framework and then take a
> look at the DLLs installed. If it's not from one of those DLLs it's not a
> "native" class. You will need to do this for every version of the
> framework that you want to target.
>
> Mike.
>
>