Removing Assembly Metadata

[i]

Hi,

Is there a simple way to strip or otherwise disrupt/break the metadata
present in my .NET assembly? I understand there are $500 per
developer solutions out there that will change symbol names, obfuscate
control flow, encrypt string names, and so on. That's a bit more than
I'm looking for, though - I just want to find a way to prevent ildasm
from being able to parse through my programs. A hackish way would be
fine - ie, replacing several bytes in a hex editor or assembler. Any
ideas would be great.

Thanks!

 

[Marc Gravell]

Is there a simple way to strip or otherwise disrupt/break the metadata

present in my .NET assembly?

Erm no - this pretty much *is* your app. You can obfuscate, but the de-
obfuscatorswill always be only a few steps behind the obfuscators.

I'm looking for, though - I just want to find a way to prevent ildasm
from being able to parse through my programs.

Well, you can make it hard to understand (in any language) without too
much bother; "dotfuscator community edition" would be the first place
to look.

Marc

 

[Jon Skeet [C# MVP]]

Is there a simple way to strip or otherwise disrupt/break the metadata
present in my .NET assembly? I understand there are $500 per
developer solutions out there that will change symbol names, obfuscate
control flow, encrypt string names, and so on. That's a bit more than
I'm looking for, though - I just want to find a way to prevent ildasm
from being able to parse through my programs. A hackish way would be
fine - ie, replacing several bytes in a hex editor or assembler. Any
ideas would be great.

How do you expect the runtime to cope with your assembly if ILDASM
can't? They're loading from the same specification, effectively.

 

[i]

How do you expect the runtime to cope with your assembly if ILDASM
can't? They're loading from the same specification, effectively.

Many commercial protection solutions advertise that metadata can be
made unreadable - obviously not to the .NET runtime, but to the
average person curious enough to look in it with something like
ildasm. There is a way to do this beyond renaming my methods, seeing
as there is software available that I have used that does this
automatically...

Code obfuscation doesn't cut it because even if all my methods,
fields, and classes are named 'A' or something equally as meaningless,
flipping a "brfalse" instruction in ILASM doesn't require knowledge of
what anything is actually named. String encryption has a similar
issue - I've implemented polymorphic string encryption, but in some
cases encryption can be circumvented in ILASM by inserting a "ldstr"
instruction with whatever I want and ignoring the call to encryption
altogether. It seems to me that the solution, or at least a very
helpful step in protecting my code, would be to stop ildasm from
opening my assembly. My question was not whether or not it could be
done, but rather how it IS done.

 

[Guest]

The problem you have here is that no matter what you do to an assembly
(obfuscation, etc) it can still be disassembled, altered and then
reassembled.
Even with obfuscators that claim to be able to thwart ILDASM, a loaded
assembly can be grabbed out of memory and disassembled. The only way I know
to have almost complete protection of your intellectual property is to
convert the assembly into a native code image - Remotesoft, among others,
have products that will do this.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

 

[Chris Dunaway]

Many commercial protection solutions advertise that metadata can be
made unreadable - obviously not to the .NET runtime, but to the
average person curious enough to look in it with something like
ildasm. There is a way to do this beyond renaming my methods, seeing
as there is software available that I have used that does this
automatically...

Perhaps this will interest you:

http://www.softwarepotential.com/code-protection.html

Chris

 

[Jon Skeet [C# MVP]]

Many commercial protection solutions advertise that metadata can be
made unreadable - obviously not to the .NET runtime, but to the
average person curious enough to look in it with something like
ildasm. There is a way to do this beyond renaming my methods, seeing
as there is software available that I have used that does this
automatically...

They advertise that, certainly - but have you checked up on their
claims?

Code obfuscation doesn't cut it because even if all my methods,
fields, and classes are named 'A' or something equally as meaningless,
flipping a "brfalse" instruction in ILASM doesn't require knowledge of
what anything is actually named.

It requires knowing which one to flip though, doesn't it?

String encryption has a similar
issue - I've implemented polymorphic string encryption, but in some
cases encryption can be circumvented in ILASM by inserting a "ldstr"
instruction with whatever I want and ignoring the call to encryption
altogether. It seems to me that the solution, or at least a very
helpful step in protecting my code, would be to stop ildasm from
opening my assembly. My question was not whether or not it could be
done, but rather how it IS done.

I suspect you'll find that although some commercial solutions *may*
work at the moment, they're probably violating the specifications in
order to do so - which means they may break if the runtime becomes
stricter about compliance. If ildasm can open any compliant assembly,
it's hard to see how you could prevent it from opening without risking
failing to run too.