You can iterate through the evidence collection of a loaded assembly which gives you the hash. see the code attached.



---
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

try

{

Assembly a = Assembly.LoadFrom(args[0]);

IEnumerator it = a.Evidence.GetEnumerator();

while (it.MoveNext())

{

Console.WriteLine(it.Current);

}

}

catch (Exception ex)

{

Console.WriteLine(ex.Message);

}

nntp://news.microsoft.com/microsoft.public.dotnet.security/<3211D764-E2EC-454A-A067-D46F6451E742 (AT) microsoft (DOT) com>

Hi,

I'm not able to find any API to retrieve at runtime the hash of an assembly.

1/ is there any existing API (I might not have looked in the correct
namespaces/classes) ?

2/ if not, why is'nt there any ? any security implication ? is it planned to
have one in .Net 2.0 ?

Note: I know that I can compute the hash manually (using interop or not).

[microsoft.public.dotnet.security]

As with other evidence items, this is pretty trivial for a sufficiently
privileged caller to spoof. Obviously, in your example, the target assembly
doesn't get a chance to do this. However, if the goal is to validate the
identity of calling code (which it often is with this sort of thing), this
approach will not work against callers with a sufficient CAS permissions to
forge evidence.




"Dominick Baier [DevelopMentor]" <dbaier (AT) pleasepleasenospamdevelop (DOT) com>
wrote in message news:%23L1zzqnFFHA.1348 (AT) TK2MSFTNGP14 (DOT) phx.gbl...

Thanks Dominick. Based from that, here is how to get the sha1 hash.
Assembly a = Assembly.GetExecutingAssembly();
foreach(object o in a.Evidence)
{
Hash aHash = o as Hash;
if ( aHash == null )
continue;
byte[] sha1Hash = aHash.SHA1;
string base64 = Convert.ToBase64String(sha1Hash);
Console.WriteLine("SHA1 Hash:{0}", base64);
}

I have one question. Is this doing a sha1 hash over the assembly bytes as
they exist or some other metadata stored in the Evidence?

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Dominick Baier [DevelopMentor]" <dbaier (AT) pleasepleasenospamdevelop (DOT) com>
wrote in message news:#L1zzqnFFHA.1348 (AT) TK2MSFTNGP14 (DOT) phx.gbl...

It's stored separately in runtime evidence and is subject to spoofing in the
same way as the strong name public key used in evidence. If you're trying
to use it to verify code identity, it would be at least somewhat safer to
read it directly out of the PE file. However, if it's possible to fake the
assembly load path, that won't be particularly reliable either since you
could end up reading the data from the wrong (or, actually, the right <g>)
file.



"William Stacey [MVP]" <staceywREMOVE (AT) mvps (DOT) org> wrote

Based on some tests, it would seem the GetRawData() internal method returns
the data from the assembly that is used to sign the assem. So it seems it
read directly from the file so changing the file will change the rawdata and
hence a md5 or sha1 hash. Are you seeing something different?

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote

Yes, but only when I deliberately spoof the hash. <g>

The path that uses GetRawData is only taken when the m_rawData field has not
been otherwise populated. There are, however, other ways that the field's
value can be set, and one of these paths is used when the hash is populated
from evidence. If the evidence provides a hash different from the actual
assembly's, the evidence hash will be retrieved with no indication that it
is incorrect.

That said, it would appear that initializing the hash from the assembly
(e.g.: new Hash(targetAssembly)), as opposed to reading the hash from
evidence, isn't subject to the same trivial evidence spoofing. However, it
may be subject to other spoofing techniques that I haven't tried.




"William Stacey [MVP]" <staceywREMOVE (AT) mvps (DOT) org> wrote

How would you spoof data in my Hash object (other then debugger). You could
load an assem in your appdomain and update private vars in your Hash object,
but wouldn't you need to ref my Hash object to spoof anything? tia

--
William Stacey, MVP
http://mvp.support.microsoft.com

By setting evidence (e.g.: via AppDomain.Load overload that takes evidence
argument), one assembly can cause another assembly's hash to appear
different than it actually is. No debugging or reflection into low
accessibility members is required.

Spoofing of the non-evidence approach would depend on how the private
GetRawData method is implemented. For example, if it reads the data from
the assembly file on disk, it may be possible to spoof the hash by either
faking the assembly path or swapping out the source file after the assembly
has already been loaded. Either way, the lower level API would not be
reading the hash data from the file that was the actual source of the loaded
assembly. This is the same sort of thing I was suggesting might be possible
wrt your public key comparison a couple of weeks ago.



"William Stacey [MVP]" <staceywREMOVE (AT) mvps (DOT) org> wrote

Yeh, I guess we need to see how GetRawData is implemented. Cheers.

--
William Stacey, MVP
http://mvp.support.microsoft.com

I've got this planned for another blog entry down the line, but you'll find
that hashing all of the bytes of an assembly isn't going to get you the
same hash that is in the signature. There are various parts of the PE file
that we skip over when creating that hash, so you'll need to do the same
when calculating yours.

-Shawn
http://blogs.msdn.com/shawnfa
--
This posting is provided "AS IS" with no warranties, and confers no rights.


Note:
For the benefit of the community-at-large, all responses to this message
are best directed to the newsgroup/thread from which they originated.
--------------------
<uj7qaxzFFHA.3608 (AT) TK2MSFTNGP14 (DOT) phx.gbl>
<emGLCRKGFHA.4088 (AT) TK2MSFTNGP09 (DOT) phx.gbl>
<urbtLqNGFHA.3504 (AT) TK2MSFTNGP12 (DOT) phx.gbl>
<#n3E1sOGFHA.2032 (AT) tk2msftngp13 (DOT) phx.gbl>
<#ydBwBPGFHA.1264 (AT) TK2MSFTNGP12 (DOT) phx.gbl>
2.phx.gbl