Beveiligen van dotnet dll's

[ZaZ]

We zijn bezig met een vrij forse win32 applicatie te migreren naar dotnet.
Omdat een rewrite niet mogelijk is, is er gekozen voor het afscheiden en abstraheren van code en die o.a in dotnet classes te zetten die te benaderen zijn via COM interop.
So far so good. Nu is het zo dat je dan al je interfaces ook exposed. Dat is nog niet zo heel erg, maar die kun je natuurlijk via elke andere app ook makkelijk aanroepen.
Dit willen wij niet omdat derden dan hun eigen tooling kunnen gaan maken met onze business logic.

Nu heeft MS wel verschillende methoden om het wat strakker te maken allemaal, maar dan moet je alles strongnamed gaan maken en daar heb je met win32 binaries niet zo heel veel aan.
Eerste gedachtenkronkel die ik heb is dat voor het buildproces de source wordt aangepast. Daar is intern al tooling voor aanwezig, dus dat is niet zo'n heel groot probleem.
En dan dus een authenticatie systeem toevoegen een beetje in de geest van "hoi ik ben de echte app!" en dat dan de classes geinstantieerd mogen worden adhv een boolean die in elke class komt.
Daarna een obfuscater erover en dan klaar.
Het is een beetje houtje touwtje oplossing en het lijkt me niet dat wij de enige zijn met dit probleem.
Er zal waarschijnlijk al iets voor zijn alleen kan ik het niet vinden.

Mocht dit wel de manier worden, weet dan iemand of je bijvoorbeeld een COM/dotnet file na het obfuscaten nog werkt met SxS?
We zitten nog redelijk vroeg in het deployment proces, dus alle suggesties zijn welkom.

[Sebazzz]

ZaZ schreef op vrijdag 26 maart 2010 @ 15:32:
En dan dus een authenticatie systeem toevoegen een beetje in de geest van "hoi ik ben de echte app!" en dat dan de classes geinstantieerd mogen worden adhv een boolean die in elke class komt.
Daarna een obfuscater erover en dan klaar.
Het is een beetje houtje touwtje oplossing en het lijkt me niet dat wij de enige zijn met dit probleem.
Er zal waarschijnlijk al iets voor zijn alleen kan ik het niet vinden.

Ik denk niet dat een obfuscator daarbij gaat helpen, tenminste, je maakt het moeilijk, maar niet onmogelijk. Met een obfuscator maak je zowieso het aanroepen van je methodes voor de externe partij al lastig, dus daar zit al genoeg beveiliging in. Methodes of classes die je niet obfuscated wil hebben kan je bij iedere zelfrespecterende obfuscator wel markeren. Er zijn ook obfuscators die componenten aan je programma toevoegen die het internet contacteren als er aan je programma geknoeid wordt, maar ik heb geen idee hoe en of dat werkt.

[ Voor 25% gewijzigd door Sebazzz op 26-03-2010 16:10 ]

[ZaZ]

Sebazzz schreef op vrijdag 26 maart 2010 @ 16:08:
[...]

Ik denk niet dat een obfuscator daarbij gaat helpen, tenminste, je maakt het moeilijk, maar niet onmogelijk. Met een obfuscator maak je zowieso het aanroepen van je methodes voor de externe partij al lastig, dus daar zit al genoeg beveiliging in. Methodes of classes die je niet obfuscated wil hebben kan je bij iedere zelfrespecterende obfuscator wel markeren. Er zijn ook obfuscators die componenten aan je programma toevoegen die het internet contacteren als er aan je programma geknoeid wordt, maar ik heb geen idee hoe en of dat werkt.

Maar met alleen een obfuscator kun je gewoon een regasm /tlb:boe.tlb doen en alles is aan te roepen.
Ik weet ook dat het niet waterdicht kan, maar het gaat erom dat het niet gemakkelijk gaat.
We werken alleen met grote vendors, dus een serieuse implementatie zullen ze niet zomaar gaan doen, maar sommige afdelingen maken wel tooling, dus die wil je het niet te makkelijk maken.

Dus de obfuscator is niet zozeer om de dll niet aanroepbaar te maken voor externe.
Maar als je bijvoorbeeld een authenticatie systeem schrijft, dat je dan niet heel gemakkelijk met een met een reflector de boel kan uitschakelen.
Dus die komt er bovenop zeg maar...

[Haan]

Maar is het zonder documentatie sowieso al niet erg lastig om de functies in een dll aan te roepen? Je moet dan toch al met Reflector o.i.d. aan de slag om naar de code te kijken en uit te pluizen hoe e.e.a. gebouwd is. Als de code door een obfuscator is gehaald, wordt dat alleen nog maar lastiger.

[ZaZ]

obfuscator of niet, met een willekeurige object browser zie je al je classes en functies met de parameters die verwacht worden.
Dan is het vrij simpel om die te gaan gebruiken.

[naam]

Kan je niet zorgen dat je apps een API key mee moeten geven? die controleer je dan intern in je library.

[Sebazzz]

ZaZ schreef op vrijdag 26 maart 2010 @ 16:42:
obfuscator of niet, met een willekeurige object browser zie je al je classes en functies met de parameters die verwacht worden.
Dan is het vrij simpel om die te gaan gebruiken.

Klopt, immers als ik in klasse Йم๗ de methode 叶葉 zie met parameters Δ en 叶 dan zie ik het. Sommige obfuscators bieden ook het wrappen van .NET classes in hun eigen classes.

[leuk_he]

Eeeh, wat dacht je om het financieel aantrekkelijk te maken dat extra tooling door jullie gemaakt wordt ipv door (hobbyisten) bij de klant?

En om dat duidelijk te maken iets erin zetten dat als een aanroep gedaan wordt zonder API key een boodschap tonen (En mailen?hmm, twijfelachtig) dat dat niet mag volgens licentie voorwaarden, maar dat jullie dat graag doen en dat een sales contact gaat opnemen hierover?

[ZaZ]

marabunta2048 schreef op vrijdag 26 maart 2010 @ 17:27:
Kan je niet zorgen dat je apps een API key mee moeten geven? die controleer je dan intern in je library.

Is dat niet ongeveer wat ik zelf al bedacht had?

Sebazzz schreef op vrijdag 26 maart 2010 @ 17:47:
[...]

Klopt, immers als ik in klasse Йم๗ de methode 叶葉 zie met parameters Δ en 叶 dan zie ik het. Sommige obfuscators bieden ook het wrappen van .NET classes in hun eigen classes.

Hmm, proef ik wat sarcasme? Als het een COM dll is wordt er helemaal niets van dat geobfuscate.. Misschien als je 'm als een .net assembly benadert, maar niet als COM. Dat zou volgens mij ook meteen namelijk het hele COM gebeuren om zeep helpen.
Je ziet in een obfuscated dll na een typelib export gewoon bijvoorbeeld iets van
HRESULT LoadFromFile([in] BSTR File);
en dat soort dingen. Maar goed.. Ik zal me nog iets meer in de obfuscators verdiepen. [smartassembly] lijkt iig niet in staat om te helpen helaas.

leuk_he schreef op vrijdag 26 maart 2010 @ 18:05:
Eeeh, wat dacht je om het financieel aantrekkelijk te maken dat extra tooling door jullie gemaakt wordt ipv door (hobbyisten) bij de klant?

En om dat duidelijk te maken iets erin zetten dat als een aanroep gedaan wordt zonder API key een boodschap tonen (En mailen?hmm, twijfelachtig) dat dat niet mag volgens licentie voorwaarden, maar dat jullie dat graag doen en dat een sales contact gaat opnemen hierover?

De klanten zijn vrij grote jongens en dit is vrij moeilijk. We zijn erg op de gebruikers gericht en willen die zoveel mogelijk tevreden houden. Da's de bedrijfsfilosofie zeg maar.
Nu wil het zo, dat bijvoorbeeld een bedrijf soms is opgedeeld in bedrijven per land en dat je nog een overkoepelend gebeuren eromheen hebt. Dan zijn de gebruikers tevreden, maar hebben een verzoek voor nieuwe functionaliteit. Komt erdoorheen, maar het globale bedrijf maakt geen budget vrij voor bedrijf land X.

Dan zit je dus met een lastige situatie. Wij maken weinig tot niets als we geen geld krijgen. Afdeling X of Land X zelfs krijgt geen budget vrij, maar willen wel en het globale bedrijf is helemaal niet meer 'in touch' met hetgeen waar het nou helemaal omgaat.
Dat is misschien voornamelijk hun probleem dat organisatie in internationale bedrijven niet altijd gemakkelijk is, maar niemand is nog ook maar 1 stap verder.

Dan krijg je dus dat Joost op afdeling X heeft wel eens wat met programmeren gedaan. En Klaas was vroeger flink in de weer geweest met Delphi, dat die zelf maar effe wat gaan automatiseren. Alleen om eigen werk uit handen te nemen.
Dat soort tooltjes worden groter en groter en kunnen intern een eigen leven gaan leiden. etc.
Wanneer je het moeilijker maakt hebben Joost en Klaas in de baas zijn tijd niet echt de tijd om iets op poten te zetten.

[Soultaker]

Kun je die COM DLLs eigenlijk niet statisch in je executable linken? Want het lijkt er op dat je die functies eigenlijk helemaal niet in aparte DLLs wil hebben, maar dat alleen doet omdat dat de enige manier lijkt te zijn om .NET assemblies te kunnen benaderen vanuit C...

[ZaZ]

Soultaker schreef op vrijdag 26 maart 2010 @ 23:18:
Kun je die COM DLLs eigenlijk niet statisch in je executable linken? Want het lijkt er op dat je die functies eigenlijk helemaal niet in aparte DLLs wil hebben, maar dat alleen doet omdat dat de enige manier lijkt te zijn om .NET assemblies te kunnen benaderen vanuit C...

Dat lijkt alleen te werken als de dotnet dll's al geregistreerd zijn. Daarna kun je ze verwijderen als ze ook statisch gelinked zijn. De SxS engine leeft buiten je eigen proces dus die kan dan de 'dll's' dan niet initialiseren.
Onze updates gaan zonder full admin rechten, dus dat zou het hele update proces in de war schoppen.

[Soultaker]

Mja, ik weet eigenlijk te weinig van .NET om hier wat zinnigs over te zeggen. Normale Win32 DLLs kun je met wat goede wil wel in je .exe hacken (er zijn ook tooltjes om dlls naar statische libs te converteren bijvoorbeeld) maar of dat ook met .NET kan, zou ik niet weten. Als die libraries niet in je eigen proces geladen worden is 't sowieso lastig...

[pedorus]

Met c++ interop kun je desnoods nog in hetzelfde bestand managed en unmanaged code mixen. Maar eigenlijk snap ik niet helemaal wat het probleem nu is:

ZaZ schreef op vrijdag 26 maart 2010 @ 15:32:
Dit willen wij niet omdat derden dan hun eigen tooling kunnen gaan maken met onze business logic.

Want? Waarom zou je tijd gaan besteden om dit tegen te gaan? Je zou het zelfs als een beter product kunnen zien (technisch is er ook daadwerkelijk meer functionaliteit).