Home - Forums-.NET - Spices.Net - TamperProof(TP) not working correctly?


NET code security, tools to protect, obfuscate, tamper defense, code and data safety, recover, convert, optimize, explore, browse and analyze .Net software.

This forum related to following products: Spices.Net Suite, Spices.Net Obfuscator, Spices.Net Decompiler

TamperProof(TP) not working correctly?
Link Posted: 10-May-2008 01:53

my name is Alcem and currently I'm evaluation the spices obfuscator.

However, there seems to be a problem, either with my settings or my understanding of your TP-Technology.

As I understand TP, it should prevent any attempt to run a signed and changed assembly.

My procedure is as follows:

1) Obfuscating my project with a strong name key file (so TP should be in place) and then opening it with .net Reflector.

2) Change something with Reflexil plugin.

3) Removing strong name (or change it to a  new one) with Reflexil Strong Name Remover.

-> Result: My Assembly won't run.

So up to this point everything is alright.

However, on my second attempt I didn't change or remove the strong name. Instead I registered the Assembly for 'registration skipping' and although even the assembly size has changed it runs perfectly fine with modifications.

In my understanding TP should prevent the use of such an easy counter-method, because it builds a second checking instance that recongnises that the actual key is invalid. So please tell me if I did something wrong or if TP simply can't prevent from altering with applied verification skipping.

Thank you!

Link Posted: 17-May-2008 09:05
One week now since I postet my querry and in the meantime two other questions popped up and none got answered.

Is spices.net dying or are the developers on vacation  

Hope we get some answers soon....  


Link Posted: 22-May-2008 10:14
I'm sorry for delays with answer, we've restructured our team.
To use TamperProof technology you should use following features:
1. You should use some of the string-encryption of resource protection modes.
2. Your assembly should signed.

The strong-name removal procedure makes any assembly workable, but when string-encryption uses parts of assembly identity it makes assembly work incorrectly even assembly is resigned with other key, because strings used in that assembly ain't encrypted correctly, resources can't be loaded correctly. Protected by that way assembly is able to work only when it is resigned with original key.