Delen via

A Few Observations about Raw Signatures

  • Artikel

Finishing up this week's strong name theme, here's a few observations to make about the raw signatures that we figured out how to dump on Wednesday:

  • You can figure out the size of the key used to sign an assembly based upon the size of the signature blob.

Simply multiply the number of bytes in the signature by 8, and you'll arrive at the size of the signing key.  For instance, the signature of mscorlib from v1.1 of the CLR is:

Strong name signature (128 bytes):
25 3a 91 3c 93 58 f5 7c dd 5c 23 da  9 90 89 f4
b5 13 cc 38 2a 33 b1 bb eb 41 18 c4 e9 15 a5 6e
bf ea 9b 6a c4 81 a2  6 21 1e 17 23 d1 8b 19 a4
79 33 97 5f ae c5 ea 22 22 f7 98 86 59 b8 de 19
8e 13 53 7b  e  2 d3 78 ed a6 90 2d 67 23 32 af
a4 c6 45 c7 1a 73 4f a1 ef 6b ff d4 18 9b 29 58
d3 9b 66 bb eb ba 94 ef 44 d4 b0 2b 57 e9 5b  8
a8  f 99 4e 95 79 b3 b8 50 32 be 39 36 78 de 8d

Since its signature is 128 bytes, we know that the key Microsoft uses as its ECMA key is 128 * 8 = 1024 bits in size.  If we use sn to create a 2048 bit key, we'd expect a 2048 / 8 = 256 byte signature, and that's exactly what we get:

Strong name signature (256 bytes):
1f 4d a8 74 12 ed e7 d1 74 4e 9e b6 f5 d3 49 a2
db 3f 74 d6  3 82 d6 4a c8 98 6e 21 54 37 d3 4d
ce bc 8a 61 95 87 6f cf c1 e8 9f e3 58 ae c5 19
98 20 d8 9d  9 d5 f5 7a 41 d1 de 36 33 56 50 66
 3 98 c4 81 d3 96 88 ad 77 e0 60 58 98 6c 23 79
e9 af b7 db a4 6d  e 48 4e 1d 3c 2c 8a f9 5a 96
d0 77 6a  6 eb b7 1d fb 40  6 c6 53  8 da b3 30
72  f a7 b3 99 98 77 23 2e 55 3f  e 94 e0 74 fc
5c 44 d3 5a e9 f2 14 c1 e1 b5 54 60 74  7 3a 2d
20 d2 81 83 55 7a 50 1b d3 61 b5 d7 b2 c6 f0 d4
cf ab fe b6 98 85 ff 91 5e 6e 76 e0 e9 fd c2 fb
13 70 a0 38  5  6 de e9 68 2f 9f b0 c0 dc 16 e8
ff dd 2f 99 a5 fd 76 2c 4e  e 46 7a 7b 1a  1  b
e5 5e bc 7d 3b  2 4e 19 17 f7 79 d4 a9 15 fc 7c
94 65 fc  2 91 b7 b6 37 94 c6 ce de cd 97  8 77
5e fc fe 12 77 4e 7a 7b 94 a7 74 a9 d8 b3  a 59

  • Delay signed assemblies have the same size signature as the signature they would receive if they had been fully signed, however that signature consists entirely of zeros.

That validates what we learned last year about the delay signing process.  Here's an example of a signature blob from a delay signed  assembly:

Strong name signature (128 bytes):
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

Comments

  • Anonymous
    February 06, 2005
    Hi Shawn. Would it be possible to just change all the signature bytes to zeros on a fully signed assembly to skip verification checking? If so, that would be a bit disturbing. Cheers.
    --William
  • Anonymous
    February 07, 2005
    Hi William,

    If you want to read up on skipping strong name verification, check out my posts on it here: http://blogs.msdn.com/shawnfa/archive/2004/03/17/91575.aspx and http://blogs.msdn.com/shawnfa/archive/2004/08/20/218049.aspx.

    However, digging a bit deeper into your scenario, if I have control over the assembly so that I can rewrite the signature and make it all zeros, than you can't stop me from doing whatever I want with that assembly. For instance, I could simply ildasm it, remove the signature from the IL file, then ILAsm it back again. Now I've got an unsigned version of your assembly.

    The reason that's not as scary as it first sounds is that in order for me to pull it off, I need to be able to replace your assembly on the target machine. And that means I need write access to its disks. And if I have write access to its disks, I can do a lot more scary things than replace an assembly with an unsigned version of itself.

    -Shawn
  • Anonymous
    February 10, 2005
    "The reason that's not as scary as it first sounds is that in order for me to pull it off, I need to be able to replace your assembly on the target machine. And that means I need write access to its disks. And if I have write access to its disks, I can do a lot more scary things than replace an assembly with an unsigned version of itself."

    That makes perfect sense Shawn. Thanks for the reply.
    --William