I am using .NET reflector to debug a console application calling a WSE3.0 service which requires signing & encrypting the message using username token element. Our service provider uses WSE so I need to use that or replicate that same logic of signing and encrypting if I need to use non .net client. To find out how that actual message signing happens (so that I can replicate that using NON .NET clients) I used .NET reflector to debug the code.
MessageSignature.BuildSignedInfo calls HMACSHA1SignatureFormatter.Sign which actually signs the message and returns the hmac, which is a byte[] array, to MessageSignature.BuildSignedInfo. Below are the 2 methods
private byte[] BuildSignedInfo(SignatureFormatter formatter)
{
this.SignedInfo.SignatureMethod = formatter.AlgorithmURI;
return formatter.Sign(this.CanonicalizeSignedInfo());
}
public override byte[] Sign(Stream data)
{
HMACSHA1 hmacsha = new HMACSHA1(this._key);
return hmacsha.ComputeHash(data);
}
This is how the byte array looks like in watch windows.
Watch window in sign method of HMACSHA1SignatureFormatter
Watch window of that returned byte[] array in MessageSignature.BuildSignedInfo (this calls that sign method to get byte[] array)
I am stepping through the code and there are no intermediate methods which gets called in between them. Would there be any reason why that would happen?
A few possibilities:
Maybe ComputeHash
is not rewinding the stream, so the second call from the QuickWatch window hashes a different portion of the stream? Check the stream.Position before and after each call.
If you are stepping through decompiled Microsoft code, then that code is likely optimized, which can sometimes reorder calls. It may be that the hash function actually has not been called yet, or the result is not where you think it is, as you step through the method.