Strong named assemblies - Tamper Proof ?

[Softwaremaker]

Dear Fellows,

i have been playing around with strong-naming my assemblies for the past
couple of days and I must say I found out something that is rather
disturbing.

Here are my questions :-

1) I want my assemblies to be called and referenced by my client apps only.
What is the proper way to do it ?

2) After I signed off my assembly with a strong name...I actually can
reverse-engineer the IL code out from the assembly with ILDASM, then what i
did was changed some IL code within the assembly and then take out the
public key token from the IL File
.publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 ....) // Delete
this value

Once i do that, i re-assemble it with ILASM Command and then deploy it. The
calling client app can then reference the tampered-with assembly as if
nothing has happened. Of couse, if i do not delete the .publickey string
value as shown above, an exception will occur during loading...

So, what is the proper way to tamper-proof the assembly ? Or this is by
design and the only way is to obfuscate the code ?

Any advice is appreciated. Thank you.


--
Thank you very much

Warmest Regards,
Softwaremaker (WilliamT)
Software Architect
+++++++++++++++++++

 

[Dmitriy Lapshin [C# / .NET MVP]]

Hi,

1) I want my assemblies to be called and referenced by my client apps only.
What is the proper way to do it ?

Code Access Security should be a good choice - and it uses strong names, by
the way.

So, what is the proper way to tamper-proof the assembly ? Or this is by
design and the only way is to obfuscate the code ?

Does your application specifies a full name for the referenced assembly
(including public key token, full version etc.)? With Code Access Security,
you can require that only assemblies having a certain public key can call
methods of classes contained in the protected assembly.

In general, the sad truth is that there is no ideal protection. Even
unmanaged applications that are much harder to disassemble and modify are
successfully "cracked" - you probably know how many "key generators" and
"patches" exist on the Internet for virtually any kind of software. Strong
naming and Code Access Security should prevent your assembly from being
tampered with, but one could theoretically disassemble the whole application
and remove all the Code Acceess Security presence.

 

[MSFT]

Hi William,

Only strong name is not enough to secure an assembly, .NET provides an code
security architeucre based on Code Access Security and Evidence. Before an
assembly was executed, we can determine if it has can be executed from
various evidence. For example, you can make an assembly can only be load
your client app. For detail information on this, you may refer to this
article:


Secure Coding Guidelines for the .NET Framework
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/ht
ml/seccodeguide.asp

For more information on Code Access Security:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconcodeaccesssecurity.asp

Hope this help,


Luke
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Jon Skeet [C# MVP]]

i have been playing around with strong-naming my assemblies for the past
couple of days and I must say I found out something that is rather
disturbing.

Here are my questions :-

1) I want my assemblies to be called and referenced by my client apps only.
What is the proper way to do it ?

Essentially, you can't. Even if you put some access controls in it,
they could be taken out.

2) After I signed off my assembly with a strong name...I actually can
reverse-engineer the IL code out from the assembly with ILDASM, then what i
did was changed some IL code within the assembly and then take out the
public key token from the IL File
.publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 ....) // Delete
this value

Once i do that, i re-assemble it with ILASM Command and then deploy it. The
calling client app can then reference the tampered-with assembly as if
nothing has happened. Of couse, if i do not delete the .publickey string
value as shown above, an exception will occur during loading...

So, what is the proper way to tamper-proof the assembly ? Or this is by
design and the only way is to obfuscate the code ?

You could make the client application require a strongly-named version
with a specific public key... but that only punts the problem back one
further, as someone could then reverse engineer the client app to get
rid of that requirement too.

Basically, tamper-proof software is impossible without more hardware-
oriented protection. If someone can change the file, they can change it
to another file which does similar things.

 

[Softwaremaker]

Hi Dmitriy,

Thanks for responding. Code Access Security is interesting. Could you point
me to some useful links ?

My concern is that if I am deploying a (strong-named) assembly to a remote
PC for use with some other client application. Now, my name is on the
metadata of the assembly. Say, if some other author comes along to that
remote PC and ILDASM it, changes the code logic in it to become malicious
or/and introduces profanity, then removes the .publickey token from the IL,
ILASM back to an assembly again.

Aside from telling all clients who referenced my assembly to look for a
strong-named one (which is impossible to do), all client apps will
referenced my assembly, (this time - weak-named) but client apps wont be
looking and wont know whether its a signed one anyway. This tampered
assembly will still have my name on it and in the end, now it seems like I
am the one who has introduced malicious content into the metadata.

Aside from obfuscating the code (which is a viable alternative), how do I
ensure that all client apps MUST use a strong-named version of my assembly ?

Thank You.

--
Thank you very much

Warmest Regards,
Softwaremaker (WilliamT)
Software Architect
+++++++++++++++++++

Hi,

1) I want my assemblies to be called and referenced by my client apps only.
What is the proper way to do it ?

Code Access Security should be a good choice - and it uses strong names, by
the way.

So, what is the proper way to tamper-proof the assembly ? Or this is by
design and the only way is to obfuscate the code ?

Does your application specifies a full name for the referenced assembly
(including public key token, full version etc.)? With Code Access Security,
you can require that only assemblies having a certain public key can call
methods of classes contained in the protected assembly.

In general, the sad truth is that there is no ideal protection. Even
unmanaged applications that are much harder to disassemble and modify are
successfully "cracked" - you probably know how many "key generators" and
"patches" exist on the Internet for virtually any kind of software. Strong
naming and Code Access Security should prevent your assembly from being
tampered with, but one could theoretically disassemble the whole application
and remove all the Code Acceess Security presence.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Dear Fellows,

i have been playing around with strong-naming my assemblies for the past
couple of days and I must say I found out something that is rather
disturbing.

Here are my questions :-

1) I want my assemblies to be called and referenced by my client apps only.
What is the proper way to do it ?

2) After I signed off my assembly with a strong name...I actually can
reverse-engineer the IL code out from the assembly with ILDASM, then

what

i
did was changed some IL code within the assembly and then take out the
public key token from the IL File
.publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 ....) // Delete
this value

Once i do that, i re-assemble it with ILASM Command and then deploy it. The
calling client app can then reference the tampered-with assembly as if
nothing has happened. Of couse, if i do not delete the .publickey string
value as shown above, an exception will occur during loading...

So, what is the proper way to tamper-proof the assembly ? Or this is by
design and the only way is to obfuscate the code ?

Any advice is appreciated. Thank you.


--
Thank you very much

Warmest Regards,
Softwaremaker (WilliamT)
Software Architect
+++++++++++++++++++

 

[Dmitriy Lapshin [C# / .NET MVP]]

Thanks for responding. Code Access Security is interesting. Could you
point

me to some useful links ?

You could start with the StrongNameIdentityPermissionAttribute class
documentation.

Aside from obfuscating the code (which is a viable alternative), how do I
ensure that all client apps MUST use a strong-named version of my assembly

?

I'm afraid this is close to impossible. But what's the problem with asking
your clients to reference the assembly with a strong-name only? You could
tell them they are in danger otherwise as a malicious person could have
replaced a well-behaved assembly with, say, a trojan.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Hi Dmitriy,

Thanks for responding. Code Access Security is interesting. Could you point
me to some useful links ?

My concern is that if I am deploying a (strong-named) assembly to a remote
PC for use with some other client application. Now, my name is on the
metadata of the assembly. Say, if some other author comes along to that
remote PC and ILDASM it, changes the code logic in it to become malicious
or/and introduces profanity, then removes the .publickey token from the IL,
ILASM back to an assembly again.

Aside from telling all clients who referenced my assembly to look for a
strong-named one (which is impossible to do), all client apps will
referenced my assembly, (this time - weak-named) but client apps wont be
looking and wont know whether its a signed one anyway. This tampered
assembly will still have my name on it and in the end, now it seems like I
am the one who has introduced malicious content into the metadata.

Aside from obfuscating the code (which is a viable alternative), how do I
ensure that all client apps MUST use a strong-named version of my assembly ?

Thank You.

--
Thank you very much

Warmest Regards,
Softwaremaker (WilliamT)
Software Architect
+++++++++++++++++++

Hi,

1) I want my assemblies to be called and referenced by my client apps only.
What is the proper way to do it ?

Code Access Security should be a good choice - and it uses strong names, by
the way.

So, what is the proper way to tamper-proof the assembly ? Or this is by
design and the only way is to obfuscate the code ?

Does your application specifies a full name for the referenced assembly
(including public key token, full version etc.)? With Code Access Security,
you can require that only assemblies having a certain public key can call
methods of classes contained in the protected assembly.

In general, the sad truth is that there is no ideal protection. Even
unmanaged applications that are much harder to disassemble and modify are
successfully "cracked" - you probably know how many "key generators" and
"patches" exist on the Internet for virtually any kind of software. Strong
naming and Code Access Security should prevent your assembly from being
tampered with, but one could theoretically disassemble the whole application
and remove all the Code Acceess Security presence.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Dear Fellows,

i have been playing around with strong-naming my assemblies for the past
couple of days and I must say I found out something that is rather
disturbing.

Here are my questions :-

1) I want my assemblies to be called and referenced by my client apps only.
What is the proper way to do it ?

2) After I signed off my assembly with a strong name...I actually can
reverse-engineer the IL code out from the assembly with ILDASM, then

what

i
did was changed some IL code within the assembly and then take out the
public key token from the IL File
.publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 ....) // Delete
this value

Once i do that, i re-assemble it with ILASM Command and then deploy

it.
The

calling client app can then reference the tampered-with assembly as if
nothing has happened. Of couse, if i do not delete the .publickey string
value as shown above, an exception will occur during loading...

So, what is the proper way to tamper-proof the assembly ? Or this is by
design and the only way is to obfuscate the code ?

Any advice is appreciated. Thank you.


--
Thank you very much

Warmest Regards,
Softwaremaker (WilliamT)
Software Architect
+++++++++++++++++++

 

[Softwaremaker]

Cool...

Thanks a lot, MVPs, for all your wonderful responses.

p/s : I am hoping to get mine soon...

Thanks again.

--
Thank you very much

Warmest Regards,
Softwaremaker (WilliamT)
Software Architect
+++++++++++++++++++

Thanks for responding. Code Access Security is interesting. Could you point
me to some useful links ?

You could start with the StrongNameIdentityPermissionAttribute class
documentation.

Aside from obfuscating the code (which is a viable alternative), how do I
ensure that all client apps MUST use a strong-named version of my

assembly
?

I'm afraid this is close to impossible. But what's the problem with asking
your clients to reference the assembly with a strong-name only? You could
tell them they are in danger otherwise as a malicious person could have
replaced a well-behaved assembly with, say, a trojan.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Hi Dmitriy,

Thanks for responding. Code Access Security is interesting. Could you point
me to some useful links ?

My concern is that if I am deploying a (strong-named) assembly to a remote
PC for use with some other client application. Now, my name is on the
metadata of the assembly. Say, if some other author comes along to that
remote PC and ILDASM it, changes the code logic in it to become malicious
or/and introduces profanity, then removes the .publickey token from the IL,
ILASM back to an assembly again.

Aside from telling all clients who referenced my assembly to look for a
strong-named one (which is impossible to do), all client apps will
referenced my assembly, (this time - weak-named) but client apps wont be
looking and wont know whether its a signed one anyway. This tampered
assembly will still have my name on it and in the end, now it seems like I
am the one who has introduced malicious content into the metadata.

Aside from obfuscating the code (which is a viable alternative), how do I
ensure that all client apps MUST use a strong-named version of my

assembly

?

Thank You.

--
Thank you very much

Warmest Regards,
Softwaremaker (WilliamT)
Software Architect
+++++++++++++++++++


in message news:[email protected]...

Hi,

1) I want my assemblies to be called and referenced by my client apps
only.
What is the proper way to do it ?

Code Access Security should be a good choice - and it uses strong

names,
by

the way.

So, what is the proper way to tamper-proof the assembly ? Or this is by
design and the only way is to obfuscate the code ?

Does your application specifies a full name for the referenced assembly
(including public key token, full version etc.)? With Code Access Security,
you can require that only assemblies having a certain public key can call
methods of classes contained in the protected assembly.

In general, the sad truth is that there is no ideal protection. Even
unmanaged applications that are much harder to disassemble and modify are
successfully "cracked" - you probably know how many "key generators" and
"patches" exist on the Internet for virtually any kind of software. Strong
naming and Code Access Security should prevent your assembly from being
tampered with, but one could theoretically disassemble the whole application
and remove all the Code Acceess Security presence.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Dear Fellows,

i have been playing around with strong-naming my assemblies for the past
couple of days and I must say I found out something that is rather
disturbing.

Here are my questions :-

1) I want my assemblies to be called and referenced by my client apps
only.
What is the proper way to do it ?

2) After I signed off my assembly with a strong name...I actually can
reverse-engineer the IL code out from the assembly with ILDASM, then what
i
did was changed some IL code within the assembly and then take out the
public key token from the IL File
.publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 ....) //
Delete
this value

Once i do that, i re-assemble it with ILASM Command and then deploy it.
The
calling client app can then reference the tampered-with assembly as if
nothing has happened. Of couse, if i do not delete the .publickey string
value as shown above, an exception will occur during loading...

So, what is the proper way to tamper-proof the assembly ? Or this is by
design and the only way is to obfuscate the code ?

Any advice is appreciated. Thank you.


--
Thank you very much

Warmest Regards,
Softwaremaker (WilliamT)
Software Architect
+++++++++++++++++++

 

[Softwaremaker]

Cool...

Thanks a lot, MVPs, for all your wonderful responses.

p/s : I am hoping to get mine soon...

Thanks again.

--
Thank you very much

Warmest Regards,
Softwaremaker (WilliamT)
Software Architect
+++++++++++++++++++

 

[Softwaremaker]

Hi,

1) I want my assemblies to be called and referenced by my client apps only.
What is the proper way to do it ?

Code Access Security should be a good choice - and it uses strong names, by
the way.

So, what is the proper way to tamper-proof the assembly ? Or this is by
design and the only way is to obfuscate the code ?

Does your application specifies a full name for the referenced assembly
(including public key token, full version etc.)? With Code Access Security,
you can require that only assemblies having a certain public key can call
methods of classes contained in the protected assembly.

In general, the sad truth is that there is no ideal protection. Even
unmanaged applications that are much harder to disassemble and modify are
successfully "cracked" - you probably know how many "key generators" and
"patches" exist on the Internet for virtually any kind of software. Strong
naming and Code Access Security should prevent your assembly from being
tampered with, but one could theoretically disassemble the whole application
and remove all the Code Acceess Security presence.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Dear Fellows,

i have been playing around with strong-naming my assemblies for the past
couple of days and I must say I found out something that is rather
disturbing.

Here are my questions :-

1) I want my assemblies to be called and referenced by my client apps only.
What is the proper way to do it ?

2) After I signed off my assembly with a strong name...I actually can
reverse-engineer the IL code out from the assembly with ILDASM, then

what

i
did was changed some IL code within the assembly and then take out the
public key token from the IL File
.publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 ....) // Delete
this value

Once i do that, i re-assemble it with ILASM Command and then deploy it. The
calling client app can then reference the tampered-with assembly as if
nothing has happened. Of couse, if i do not delete the .publickey string
value as shown above, an exception will occur during loading...

So, what is the proper way to tamper-proof the assembly ? Or this is by
design and the only way is to obfuscate the code ?

Any advice is appreciated. Thank you.


--
Thank you very much

Warmest Regards,
Softwaremaker (WilliamT)
Software Architect
+++++++++++++++++++