[C#] Eigen DLL beveiligen

[armageddon_2k1]

Waarschijnlijk is het heel simpel, maar ik kan het niet vinden.
Ik heb voor m'n werk een framework gebouwd waarmee een bepaald xml-bestand in te lezen is en vervolgens heb ik een complete DOM van een project van ons softwarepakket.

Nu wil een klant dat ik een custom-app ontwikkel. Geen probleem, daar had ik het framework ook op ontwikkeld, maar nu vroeg ik me het volgende af:
De klant krijgt een applicatie en ziet in z'n folder uiteindelijk iets staan als xmlframework.dll ofzo. Hij weet dat het een .NET applicatie is en een beetje programmeur kan die dll gewoon includen in z'n projecten en dan kunnen ze dus vanalles wat ons overbodig maakt

Ik kan me niet voorstellen dat hier geen oplossing voor is, maar ik kan het niet vinden..... Is er niet iets dat ie in de .exe include wordt of iets dergelijks?

[whoami]

\[.NET] StrongNameIdentityPersmission

[TeeDee]

http://gathering.tweakers...iligen&where=GoT#hitstart
en
Deze van whoami

[armageddon_2k1]

Bedankt! Hiermee kom ik een heel eind.

[LordLarry]

Ik ben bang dat het je weinig veiligheid geeft.

In the .NET Framework versions 1.0 and 1.1, demands on the identity permissions are effective, even when the calling assembly is fully trusted. That is, although the calling assembly has full trust, a demand for an identity permission fails if the assembly does not meet the demanded criteria. In the .NET Framework version 2.0, demands for identity permissions are ineffective if the calling assembly has full trust. This assures consistency for all permissions, eliminating the treatment of identity permissions as a special case.

Dus als de klant zijn applicatie lokaal draait (full trust) en jouw assembly laad doet StrongNameIdentityPermission helemaal niets.

Of heb ik het helemaal mis?

/edit

Misschien is http://msdn2.microsoft.co...rary/fe8b1eh9(vs.71).aspx wel een goed begin? Ondanks dat dit in eerste instantie bedoelt is voor controls.

[ Voor 9% gewijzigd door LordLarry op 10-09-2007 20:33 ]

[Hydra]

Je kunt dit beter in de contracten dichttimmeren dan proberen te voorkomen dat ze die assembly kunnen gebruiken. De enige manier om te voorkomen dat ze 'em kunnen gebruiken is 'em niet leveren.

[cspare]

Misschien dat je iets met Multifile assemblies kan.

[LordLarry]

Hoe zou dat moeten helpen dan?

[EfBe]

Check in je dll de public token van de assembly name van de CALLER (dus de assembly die jouw assembly aanroept). Is dat niet de public token die je krijgt als je de assembly signed met jouw eigen key, dan is de caller dus niet gebouwd door jou en weiger je dienst. Dit kun je op random plaatsen doen in je code en dan bv meteen returnen.

Om dit eruit te halen moeten ze jouw dll disassembleren en opnieuw assembleren met ildasm en ilasm. Ze moeten dan ook jouw signature eraf halen en de dll verliest dan dus OOK zn public token die alleen van jou afkomstig kan zijn.

Je gaat dan dus op andere random plekken dat token checken. Obfuscate je dll verder, zodat deze code niet echt zichtbaar is. Obfuscation kan erg goed werken: maak zoveel mogelijk classes en methods internal en protected, tenzij ze echt buiten je dll worden gebruikt. Hierdoor is de rename actie van een obfuscator erg succesvol.

[unclero]

cspare schreef op dinsdag 11 september 2007 @ 18:01:
Misschien dat je iets met Multifile assemblies kan.

Of je encrypt de dll en decrypt en laad het in het geheugen zodra de executing assembly erom zeurt..

[CumpsD]

EfBe schreef op dinsdag 11 september 2007 @ 18:51:
Check in je dll de public token van de assembly name van de CALLER (dus de assembly die jouw assembly aanroept). Is dat niet de public token die je krijgt als je de assembly signed met jouw eigen key, dan is de caller dus niet gebouwd door jou en weiger je dienst. Dit kun je op random plaatsen doen in je code en dan bv meteen returnen.

Om dit eruit te halen moeten ze jouw dll disassembleren en opnieuw assembleren met ildasm en ilasm. Ze moeten dan ook jouw signature eraf halen en de dll verliest dan dus OOK zn public token die alleen van jou afkomstig kan zijn.

Je gaat dan dus op andere random plekken dat token checken. Obfuscate je dll verder, zodat deze code niet echt zichtbaar is. Obfuscation kan erg goed werken: maak zoveel mogelijk classes en methods internal en protected, tenzij ze echt buiten je dll worden gebruikt. Hierdoor is de rename actie van een obfuscator erg succesvol.

Dit is volgens mij een goede oplossing, vooral die checks in combinatie met obfuscation. Afzonderlijk zijn ze beide nutteloos, maar samen kan het toch iets helpen. (Het is nooit 100% waterdicht, maar ja...)

Ik heb de voorbije week hier nog mee zitten spelen voor enkele zaken die we op mn werk doen, en verwerkt in enkele blog posts moest het je interesseren (engels echter, maar met screenshots):

• Reverse Engineering with Reflector and Reflexil.
• Code Signing as Reverse Engineering Protection.
• Obfuscation - Making Reverse Engineering Harder

[Serpie]

Ik was toevallig ook vandaag naar een stuk of wat obfuscators aan het kijken.

Ik denk ook dat dat een goede oplossing kan zijn, bij een aantal kun je ook de reference assemblies mergen met je applicatie. De klant ziet dan de gehele dll niet meer omdat deze geintregeerd is.

De dotfuscator die bij vs2005 zit is niet echt denderend, en de meest uitgebreide versie kost gelijk 1900 dollar. Net even gespeeld met "Net Reactor" en "{smartassembly}" en deze lijken het heel aardig te doen. Net reactor heeft nog mijn voorkeur aangezien deze wat goedkoper is.

Ook wrapt Net reactor de applicatie in een win32 jasje met wat extra beveiligingen, zodat decompilen moelijker wordt (zelf zeggen ze onmogelijk maar dat lijkt me sterk). Maar weer een extra bruggetje dus.

Moet er nog een aantal verder testen.

[ Voor 16% gewijzigd door Serpie op 29-09-2007 20:54 ]