Beskytte assembly

Det er meget svært at beskytte kode biblioteker mod brug i andre sammenhænge
end tilsigtet.

Jeg har købt noget kode, der tjekker for en site-specifik nøgle, der skal ligge i web.config. Det virker rimelig sikkert.

Hvad med at inkludere en procedure som skal kaldes før at de andre procedure/funktioner i din assebly vil fungere korrekt?

Denne procedure kaldes med et password, og hvis passwordet ikke er korrekt giver de andre funktions-kald bare garbage tilbage. Passwordet kan være et unikt et for hver af dine kunder (du ændre det bare i koden og compiler påny).

Yup. Nøgle i en config config er en mulighed. Men når denne assembly skal distribueres, skal den distribueres med f.eks. noget shareware på tucows.... Så alle der er bare lidt snilde vil være i stand til at pille denne assembly ud, og genbruge den.
Nøglen kunne selvf. ligge som et metodekald der skal laves fra den kode der bruger assemblien.. Så har man da gjort et eller andet for at man ikke 'bare' kan pille assemblien ud og bruge de funktionaliteter der ligger i den.....
Gad vide om det bliver er problem ;-)

nielle ->  :-)

Ok, hvis du vil distribuere via tucows så kan du ikke recompile hver gang.

I stedet laver du det sådan at kunden skal registrere det. Kunden sender dig sin e-mail adresse og du generere så en kode ud fra denne (efter behørig afregning). Det funktionskald som kunden skal kalde for at løse op, skal så have to parametre: e-mail adressen og den kode du genererede. Proceduren sammenligner de to (efter den samme algoritme som du brugte til at generere koden i første omgang). Hvis de stemmet så løses der op. Hvis ikke...

Det forhindrer jo strengt taget ikke brug koden.

Enten kan køber selv videre-distribuere koden.

Eller så kan nogen af hans kunder fiske den ud af hans program uden hans viden.

Nej, det giver ingen garanti.

Til gengæld ved man hvem det er som har gjort i bukserne - man har hans e-mail adresse.

Men hvis han siger at nogen må have decompilet hans kode, så kan man
ingenting gøre.

Jeg ved at man kan decompile, og lure på logikken... Det ved jeg at man ikke rigtig kan gøre andet ved end at obfuscate.
Jeg kom dog på en anden måde at ordne tingene på. Kan bare ikke se om det holder:
Hvis man laver contructoren for klasserne i assemblierne protectet, så SKAL dem der bruger klasserne override....
Hvis en klasse bliver overridet, har man (via C#: GetType()) adgang til hvilken klasse der overrider... DEN kan der tjekkes på, om er den aftalte! (tjek på public key, og fuldt Class-name)
Så er assemblien jo egentlig 'bundet' til den klasse der overrider, og hvis det ikke er den klasse.... gøres noget andet
Holder det?

Nu er det jo aldrig muligt at få en 100% garanti når det gælder software!

En alternativ metode... Hvis du altså er indstillet på at programmet kun kan køre fra en bestemt maskine! ...er denne:

Sammen med din compilede assembly leverer du et lille program. Kunden starter dette op og indtaster sin e-mail adresse. Programmet kombinere dette med harddiskens serienummer og spytter en kode ud. Denne sender kunden til just4fun som så bruger den til at kombinere en ny kode som sendes til kunden (efter behørig betaling).

Den procedure som løser op, skal så stadig have e-mail adressen og koden fra just4fun. Den kombinere disse to med harddiskens serienummer og låser op hvis alle tre stemmer. Hvis ikke...

Hard diskens serienummer, net-kortets MAC adresse har alle sammen en
ting til fælles:
  det er en pestilens for brugerne når de laver en uskyldig hardware
  upgrade

Enig!

Vi taler algoritmer og logik til f.eks. et tegneprogram. Det betyder, at det er tegneprogrammet det skal låses til.

Den er vist ikke længere, end at hvis han er i stand til at binde nogle klasser på den klasse der bruger den, er det vist det.

Men 1000 tak for inputs. Jeg lade den stå til i morgen i tilfælde af at nogen har 'LØSNINGEN'.

regards
/J

Brug dotfuscator. Den kan "sløre" koden så den ikke kan decompiles. Der følger en lite-version med til VS.NET 2003.

odegaard -> Det der skal forhindres er at man 'bare' tager og bruger assemblien andre steder.

Jeg er selv i stand til at flytte obfustated kode over i en anden assembly hvis det er det jeg vil... De interfaces man skal bruge kan jo ikke obfuscates (da de jo så ikke kan kaldes!). Men det jeg tænker er bare, at hvis man er så snu så man kan det, kan man sku også tænke sig til hvad der sker i filtrene, og så er det lige gyldigt med obfuscated kode!

Men jeg prøvede at implementere en lidt mere avanceret version af mit eget forslag: lave hovedklasserne protectede, og når de så bliver overloadede, tjekkes på den kaldene klasses navn's hash.

Som sagt: Nemt nok at omgå hvis man har en decompiler og lidt viden om hvad der foregår, men det betyder, at man ikke umiddelbart kan bruge klasserne andre steder uden at skulle bøvle med det først.

Hvis nogen kommer på en mere snedig måde er der stadig 60Pts.
regards

/J