[C#] Eigen DLL's beschermen tegen gebruik door anderen

[Verwijderd]

Hoi,

Ik ben een applicatie aan het schrijven, waarbij ik zelfgeschreven DLL's als plugins gebruik.
Gelukkig is daarover veel info te vinden op internet, maar op 1 vraag heb ik nog geen antwoord gekregen:
Is het mogelijk om je eigen DLL's te 'protecten', zodat ze alleen in mijn applicatie bruikbaar zijn? Want je wilt niet dat andere programmeurs jou DLL's in hun projecten gaan plaatsen.. Ik heb dat even getest, als ik een DLL van een andere applicatie in mijn project hang, krijg ik een foutmelding. Dus het lijkt me dat het mogelijk is..

In AssemblyInfo.cs staat wel iets over key's/signing, maar het is me niet helemaal duidelijk wat dat precies in houd. Kan ik daar iets mee?

Iemand suggesties?

[Zoijar]

Je kan een globale var zetten in je .dll, die moet je client dan initialiseren, en al je functies in je dll kijken of deze de juiste waarde heeft. Dat is wel weer te hacken natuurlijk, maar is een begin. En je exports vreemde namen geven, of nummers.

[whoami]

Je kunt een assembly protecten door 'm te signen.
Een applicatie kan dan enkel die assembly gebruiken, als die applicatie de juiste key weet.

Ik denk dat je hier wel wat aan hebt:

klik

klik

[Zoijar]

whoami schreef op vrijdag 18 maart 2005 @ 14:25:
Je kunt een assembly protecten door 'm te signen.
Een applicatie kan dan enkel die assembly gebruiken, als die applicatie de juiste key weet.

Ik denk dat je hier wel wat aan hebt:

klik

klik

Dat is niet echt beveiliging, toch? Hetzelfde idee als 'private' en name mangling; het is een design beveiliging, bedoeld om andere programmeurs te laten weten dat je de dll/functie niet direct moet gebruiken en zo voorkomt dat ze dat toch doen. Als ze kwaad willen, en per se je code gebruiken, dan is het simpel te omzeilen. Als dat het punt is, moet je een encrypted dll loader oid schrijven. Het is altijd te omzeilen door naar de originele code te kijken.

[Verwijderd]

Je kunt toch gewoon sealed classes maken? Of mis ik hier nu iets?

[Rickets]

Verwijderd schreef op vrijdag 18 maart 2005 @ 14:39:
Je kunt toch gewoon sealed classes maken? Of mis ik hier nu iets?

Die kan je enkel niet inheriten. Je kan ze echter nog wel gebruiken.

[whoami]

een sealed class betekent dat je niet meer van die class kunt inheriten, het verhinderd andere applicaties echter niet om er instanties van te maken.

De topicstarter kan eens kijken naar de StrongNameIdentityPermissionAttribute in .NET

klik

klik

[EfBe]

Dat is er in 20 seconden afgehaald met ildasm -> file -> notepad -> ilasm -> klaar. Dat kan echter alleen als de signature erafgehaald wordt of wordt vervangen door een andere signature.

Je moet dus NAAST de strongnameidentitypermission ook IN je code checken of de public token van de plugin assembly degene is die bij jouw public key hoort. Dit kun je dus lukraak in je code doen (niet een routine van maken, gewoon veelvuldig die code erin stoppen, beetje obscuur wegprogrammeren) en dan wanneer je een fout vindt (i.e.: de signature is gewijzigd) zet je een random variable op null of haal je essentiele info weg waardoor de app later crashed. het is dan nauwelijks te achterhalen wat er aan de hand is en waar het gebeurd.

Daarnaast moet je je dll obfuscaten om het nog lastiger te maken. Dit kan goed met de dotfuscator community edition die bij vs.net zit. Om obfuscation zo effectief mogelijk te laten plaatsvinden moet je je public interface methods (die je exposed omdat het een plugin is) eigenlijk gebruiken als wrappers die direct een private method aanroepen. De public methods worden dan niet geobfuscate, maar de private methods wel. Et voila.

[victorv]

Zoals "Generator.CoolTool()" (heee, hallo Frans!) al zei: Het kost niet zoveel moeite om de voorgestelde beveiligingen te verwijderen. Uberhaupt zijn .NET assemblies nauwelijks te beveiligen; ook de code in je assembly is heel eenvoudig te bekijken met Reflector.

Beste optie: maak 'm open source, dan hebben je gebruikers veel meer plezier aan je applicatie.

Ook Frans heeft een eenvoudige versie van LLBLGen als open source beschikbaar.

[whoami]

Sonii schreef op vrijdag 18 maart 2005 @ 15:27:


Beste optie: maak 'm open source, dan hebben je gebruikers veel meer plezier aan je applicatie.

Open source is voor hippies, en trouwens, daar gaat 't em niet om.
Het gaat erom dat de TS wil voorkomen dat iemand anders gebruik gaat maken van zijn DLL's.

Trouwens, met de reflector kan je enkel zien welke methods / types / etc... er in een assebly zitten; de source zelf kan je afaik niet zien.

Sonii schreef op vrijdag 18 maart 2005 @ 15:27:
Uberhaupt zijn .NET assemblies nauwelijks te beveiligen;

Hoezo dan ? Het voordeel van managed code is juist dat je veel beter restricties kunt opleggen aan wie er welke code mag uitvoeren , etc...

[ Voor 44% gewijzigd door whoami op 18-03-2005 15:37 ]

[PrisonerOfPain]

whoami schreef op vrijdag 18 maart 2005 @ 15:34:
Trouwens, met de reflector kan je enkel zien welke methods / types / etc... er in een assebly zitten; de source zelf kan je afaik niet zien.

View -> Dissambler en dan kun je bij je opties instellen in welke taal je het wilt zien (IL, VB.Net, C# of Delphi.Net)

[whoami]

PrisonerOfPain schreef op vrijdag 18 maart 2005 @ 16:08:
[...]

View -> Dissambler en dan kun je bij je opties instellen in welke taal je het wilt zien (IL, VB.Net, C# of Delphi.Net)

Hmm, indeed.....
Da's wel ruk zeg. Ik heb het net ff bij een release build geprobeerd, en dat lukt ook.

[Verwijderd]

Bij grote methods gaat ie over z'n nek

-> toch niet Ik heb mijn cpu op 800mhz lopen dan duurt het alleen te lang. Op 1800Mhz is het zo bekeken..

[ Voor 82% gewijzigd door Verwijderd op 18-03-2005 16:41 ]

[Verwijderd]

Hmm da's best kut.. dus als iemand echt wil, lukt het zoiezo wel?

Dus eigenlijk is het veel beter om met C++ aan de gang te gaan? Als ik het zo zie, is .Net niet echt een taal voor 'echte' applicaties..?

[Verwijderd]

Een DLL is bedoelt om gedeeld te worden.Ook als je met C++ dll's maakt is het eenvoudig om achter de functie's van die DLL te komen. Encrypten of het uitwisselen van unieke keys is de enige manier om DLLs te beveiligen, maar alles is hacken.

Vraag is, waarom zouden mensen die DLLs hacken (en hoe komen ze in de eerste plaats aan die DLLs) Ook is het de vraag hoe belangrijk die DLLs zijn in relatie tot het hoofdprogramma.

[Verwijderd]

De applicatie waar ik mee bezig ben, wordt een MDI applicatie, waarin ik met een plugin-model wil gaan werken. Zodat ik makkelijk uitbreidingen kan programmeren, of updates kan leveren, die daar dan zonder problemen in te hangen zijn.

De enige manier om dat te doen is, voor zover ik weet, met DLL's.. dus vandaar dat ik het me af vroeg

[Gerco]

Verwijderd schreef op vrijdag 18 maart 2005 @ 16:59:
Dus eigenlijk is het veel beter om met C++ aan de gang te gaan? Als ik het zo zie, is .Net niet echt een taal voor 'echte' applicaties..?

Als dat waar zou zijn, zou MS dan .NET pushen als HET Windows development platform van de toekomst ?

On-topic:
Wat voor beveiliging je ook toepast, zo lang je code uitvoerbaar blijft, blijft 'ie kraakbaar. Dat is met .NET code zo, maar ook met native code (kijk maar naar de enorme hoeveelheid cracks voor alle soorten software). Je moet gewoon iets kiezen waardoor het meer moeite gaat kosten om de beveiliging te omzeilen dat de cracker er aan wil besteden, die StrongNameIdentityPermission lijkt me in dat opzicht een goede optie.

Als je bovendien je dll's en exe allemaal gesigned hebt, kun je ze beiden laten controleren of die signature nog aanwezig is (en valide). Op die manier kun je alleen je componenten van elkaar loskrijgen door ze allemaal te decompilen, de controle eruit te halen en te recompilen. Resultaat is dat het werkt, maar jouw signatures krijg je er niet meer in terug en support kunnen ze dan dus wel vergeten.

[ Voor 22% gewijzigd door Gerco op 18-03-2005 22:11 ]

[EfBe]

Sonii schreef op vrijdag 18 maart 2005 @ 15:27:
Zoals "Generator.CoolTool()" (heee, hallo Frans!) al zei: Het kost niet zoveel moeite om de voorgestelde beveiligingen te verwijderen. Uberhaupt zijn .NET assemblies nauwelijks te beveiligen; ook de code in je assembly is heel eenvoudig te bekijken met Reflector.

Heeee Victor!

Het beveiligen gaat heel goed hoor, mits je maar bereid bent wat ranzigheid toe te voegen aan de code. Hoe meer obscurity hoe beter.

Beste optie: maak 'm open source, dan hebben je gebruikers veel meer plezier aan je applicatie.
Ook Frans heeft een eenvoudige versie van LLBLGen als open source beschikbaar.

[/quote]
Mja, maar als je geld wilt verdienen met het verkopen van licenses, is open source niet echt de oplossing.

de TS heeft op zich goede dingen in handen als hij dat security attribute toevoegt, hij moet daarnaast dan alleen zorgen dat het niet verwijderd wordt, dus dll signen en checken of de signature nog klopt. That's it.

[MrBucket]

Gerco schreef op vrijdag 18 maart 2005 @ 22:07:
Op die manier kun je alleen je componenten van elkaar loskrijgen door ze allemaal te decompilen, de controle eruit te halen en te recompilen. Resultaat is dat het werkt, maar jouw signatures krijg je er niet meer in terug en support kunnen ze dan dus wel vergeten.

Is dat wel zo? Ik ben verder niet bekend met die techniek, dus het zou heel goed kunnen dat ik het mis heb, maar als je wist hoeveel checks er omzeild kunnen worden door een JE of JNE (resp. Jump Equal en Jump Not Equal) te vervangen door een JMP instructie...

[Gerco]

MrBucket schreef op zaterdag 19 maart 2005 @ 00:53:
Is dat wel zo? Ik ben verder niet bekend met die techniek, dus het zou heel goed kunnen dat ik het mis heb, maar als je wist hoeveel checks er omzeild kunnen worden door een JE of JNE (resp. Jump Equal en Jump Not Equal) te vervangen door een JMP instructie...

Toevallig weet ik dat inderdaad, ik heb een klein aantal 1-byte patches op mijn naam staan uit het aloude DOS tijdperk Ik moet echter wel toegeven sindsdien niets meer gedaan te hebben met die (en aanverwantte) technieken, dus ik kan "iets" achterlopen.

Als je de binary verandert, zelfs al is het maar 1 byte, klopt de signature niet meer en die kun je niet repareren zonder de bijhorende private key, dat is het hele punt. Als je dan bij een klant een binary zonder de goede signature tegenkomt, is die ten eerste zijn licentie kwijt en ten tweede een rechtszaak rijker.

[ Voor 9% gewijzigd door Gerco op 19-03-2005 14:19 ]

[whoami]

Verwijderd schreef op vrijdag 18 maart 2005 @ 16:59:
Hmm da's best kut.. dus als iemand echt wil, lukt het zoiezo wel?

Dus eigenlijk is het veel beter om met C++ aan de gang te gaan? Als ik het zo zie, is .Net niet echt een taal voor 'echte' applicaties..?

Da's nu ook weer overdreven, met een goeie obfuscater kan je er al veel aan doen; en trouwens, C++ app's kan je ook decompilen.

MrBucket schreef op zaterdag 19 maart 2005 @ 00:53:
[...]

Is dat wel zo? Ik ben verder niet bekend met die techniek, dus het zou heel goed kunnen dat ik het mis heb, maar als je wist hoeveel checks er omzeild kunnen worden door een JE of JNE (resp. Jump Equal en Jump Not Equal) te vervangen door een JMP instructie...

Als je jouw .NET assembly met 'gesigned' hebt (dus een strong name gegeven hebt dmv een key die je genereerd via sn.exe), dan zou het .NET framework (de CLR), AFAIK toch moeten 'zien' (opmerken) dat er geknoeid is met die assembly en moeten weigeren om 'm uit te voeren.

[ Voor 45% gewijzigd door whoami op 19-03-2005 14:28 ]

[MrBucket]

--edit--
@whoami: Ah, op die manier. Ok, ik snap 'm

Voor TS: wat je evt. wel kunt doen is het volgende. Giet alle public methods, die je normaal gesproken rechtstreeks door de dll zou laten exporteren, in een interface (of abstract base class). Laat je dll 1 functie exporteren, die een implementatie van deze interface terug geeft.

Het idee is dat, zolang je de definitie van die interface niet bekend maakt, men zelf de vtable van die interface moet gaan navlooien en aan de hand van de implementaties van zijn methods de functie-signatures moet gaan terugherleiden. Dit is een ontzettend takkewerkje

[ Voor 38% gewijzigd door MrBucket op 19-03-2005 14:36 ]

[Martin Sturm]

Uhm, zijn licenties, copyright enzo niet bedoeld om dit soort zake niet te hoeven doen? Bijna alles wat hier genoemd wordt komt wel erg 'ranzig' over vindt ik. Zijn het zulkje speciale dll's dat die dermate moeten worden beveiligd?

[misfire]

Het beveiligen van het uitvoeren van je code is moeilijk. Men is altijd in staat om eventuele beveiligingen te omzeilen door de assembly aan te passen. Overigens geldt dit niet alleen voor je DLL's, ook EXE bestanden zijn gewoon assemblies en kunnen gewoon gedeeld worden.

Het probleem dat jij nu beschrijft is dat andere partijen gebruik gaan maken van jouw DLL's om eigen oplossingen te maken. Als je dit niet wilt dan moet je dit dichttimmeren in je licentie, en als een andere partij het dan toch doet en op die manier geld gaat verdienen dan start je een rechtzaak. Daar zijn licenties voor, en daar hoef je niet moeilijk voor te doen in je code.

Code-beveiligingen kunnen een hele klasse aan nieuwe bugs introduceren in je code. Als je zelf crashes e.d. gaat introduceren zodra de beveiliging merkt dat er iets niet klopt, zoals hierboven gesuggereerd wordt, wordt het helemaal een vaag plaatje. In beide gevallen wordt het imago van je product beschadigd, omdat door de beveiliging het product minder goed werkt. Als je toch zoiets overweegt dan zijn er wel wat oplossingen te koop, kijk maar eens op google. Die bedrijven kunnen waarschijnlijk veel breder testen, hebben meer ervaring en meer opties dan dat je zelf zou kunnen maken. De beste beveiligingen zijn helaas echter nog steeeds dongels en zo masochistisch zou ik niet zijn tov mijn klanten...

Als partijen je DLL's gaan gebruiken omdat ze dit zelf willen en niet voor commerciële doeleinden dan zou je dit juist moeten stimuleren. Dit is namelijk gratis extra lock-in voor je product. Je zou bijvoorbeeld ook kun overwegen om een extra licentie te introduceren waarin je het toestaat, en waarbij je ook documentatie en broncode meelevert. Dan verdien je er nog extra geld mee ook!

[ Voor 9% gewijzigd door misfire op 19-03-2005 14:51 ]

[Verwijderd]

Uhm, zijn licenties, copyright enzo niet bedoeld om dit soort zake niet te hoeven doen? Bijna alles wat hier genoemd wordt komt wel erg 'ranzig' over vindt ik. Zijn het zulkje speciale dll's dat die dermate moeten worden beveiligd?

Ja, het wordt wel een flinke applicatie.. wil zelfs de mogelijkheid van dongel beveiliging bekijken (had daarover al wat interessante topics gevonden)

Voor zover je 't kunt beveiligen moet je 't wel doen als het een applicatie is waarvoor betaald wordt. Ook voor je betalende klanten, die willen ook niet dat de software waar zij geld voor neerleggen, opeens gekraakt op internet staat.

'T moet natuurlijk niet teveel tijd gaan kosten, moet geen weken-project zijn, maar voor zover beveiliging binnen de mogelijkheden ligt.. waarom niet?

De tip van MrBucket vind ik ook wel een mooie

Ik heb nu de DLL's nog zonder interface erin hangen (als test), ik heb wat linkjes gevonden over hoe dat werkt met interfaces (voor de geinteresseerde, linkje 1 link 2). Dus die ga ik morgen maar eens doorlezen.

[ Voor 17% gewijzigd door Verwijderd op 19-03-2005 14:54 ]

[MrBucket]

Verwijderd schreef op zaterdag 19 maart 2005 @ 14:52:
De tip van MrBucket vind ik ook wel een mooie

Ik heb nu de DLL's nog zonder interface erin hangen (als test), ik heb wat linkjes gevonden over hoe dat werkt met interfaces (voor de geinteresseerde, linkje 1 link 2). Dus die ga ik morgen maar eens doorlezen.

Ik ben niet zo bekend met .NET, dus ik zou als ik jou was alleen nog even nagaan of interface-definities niet ook gewoon uit een dll gedestilleerd kunnen worden, net zoals dat met die methods kon.

Ik weet van C++ dat als je het op deze manier aanpakt, dat je een redelijke hobbel hebt ingebouwd die niet zo makkelijk te nemen is, maar voor .NET durf ik dit niet te zeggen.

[whoami]

Tuurlijk kan je met Reflector e.d. de interface definities uit je assembly halen:



Zoals je hier kunt zien kan je gewoon alle interfaces zien, de interface definties, en ook de code dus v/d implementaties

[whoami]

Ik heb net ff een testje gedaan met die StrongNameIdentityPermission en dat geeft wel het gewenste resultaat:

Je genereert een key, signed assembly B met die key, decoreer een class uit assembly B met het STrongName.... attribute.
Als je dan die class uit assembly B benadert vanuit een assembly die niet gesigned is met diezelfde key, dan krijg je een security exception.
Als je 't doet vanuit een assembly die wel gesigned is, dan werkt het wel.

Echter, als ik die walkthrough bekijk die ik eerder postte, dan zie ik dat je een public key moet meegeven aan die StrongNameIdentityPermission attribute.
In .NET 1.1 kan je dat echter niet doen, daar neemt die attribute slechts 1 argument, nl. de SecurityAction.

Wat ik dus wel vreemd vind, is dat je nu dus niet meer kunt opgeven welke key de 'aanroepende' assembly moet kennen.

[ Voor 31% gewijzigd door whoami op 19-03-2005 21:33 ]