SmartAssembly and InishTech SLP

ApocDev

I've been trying to get SA and InishTech SLP Code Protector (basically a licensing tool, with code-protection aspects) to play nice together.

The SLP Code Protector requires the names not change, which is fine, as we run our assembly through SA first, then through the SLP CP afterwards.

I have been able to use Dotfuscator (for renaming only) and the SLP CP successfully. But as soon as I turn SA's renaming on, it breaks the SLP CP protection process.

We have a 'bunch' of DLLs being merged into our main exe. I can turn the settings on for nearly everything in SA without the Code Protector complaining (or breaking our app). As soon as I turn 'Obfuscation' on for any assembly, no matter at what level, it causes the SL CP to not be able to insert the required licensing and protection code due to the names used by SA.


My question is very simple: does SA make any 'odd' changes to the assembly when it does it's renaming?

And is there a way to change what character sets SA uses aside from the #aa notation, and Unicode unprintable chars?

Edit: just to clarify, it seems I can't do any form of post-processing that involves ILDASM if I turn obfuscation on at all.

Brian Donahue

It's hard to say why it doesn't work without knowing what the SLP tool does or specifically what error it throws out when you try to use it. In my mind, ASCII obfuscation should be okay -- it should allow the third-party tool to at least get the method names and so forth.

Maybe a combination of obfuscation and "something else" is the issue. For instance, string encoding, pruning, or anything that would pooch the metadata in the assembly may be the actual cause.

Pretty much the point of an obfuscator is to prevent things like IL Disassembly.

ApocDev

Brian Donahue wrote:

It's hard to say why it doesn't work without knowing what the SLP tool does or specifically what error it throws out when you try to use it. In my mind, ASCII obfuscation should be okay -- it should allow the third-party tool to at least get the method names and so forth.

Maybe a combination of obfuscation and "something else" is the issue. For instance, string encoding, pruning, or anything that would pooch the metadata in the assembly may be the actual cause.

Pretty much the point of an obfuscator is to prevent things like IL Disassembly.

That was the first thing I thought of as well. However, I made sure to test with absolutely everything 'off'. Then I turned on obfuscation at the lowest settings possible, and the error popped up.

I've also tried the complete opposite. Everything on, with settings as high as they can go. Not a single problem with that.

It only pops up when I turn obfuscation on.

(Obviously false metadata and ILDASM suppression were off for these tests)