Cum să împiedic pe ceilalți să folosească asamblarea .Net?

Am un ansamblu care ar trebui nu utilizat de nicio altă aplicație decât executabilul desemnat. Dați-mi niște instrucțiuni pentru a face acest lucru.

0
adăugat autor Darren Kopp, sursa

13 răspunsuri

100% complet imposibil, fără a sări prin niște cercuri.

Unul dintre avantajele utilizării .NET este capacitatea de a folosi reflecția, care este încărcarea unui ansamblu și inspectarea acestuia, metodele de apelare dinamic etc. Acest lucru face posibilă interopul între VB.NET și F #.

Cu toate acestea, deoarece codul dvs. este într-un ansamblu gestionat, înseamnă că oricine poate adăuga o referință la codul dvs. și poate invoca metodele sale publice sau le poate încărca utilizând metode de reflecție și apeluri private . Chiar dacă "obfuscați" codul, oamenii vor putea totuși să folosească reflecția și să vă invite codul. Cu toate acestea, deoarece toate numele vor fi mascate făcând ceva este prohibitiv dificil.

Dacă trebuie să expediați codul .NET într-o manieră care împiedică alți utilizatori să-l execute, este posibil să aveți posibilitatea să GNEN binar (compilați-l la x86) și să expediați aceste fișiere binare.

Nu cunosc specificul situației tale, dar obfuscația ar trebui să fie suficient de bună.

0
adăugat
Da, puteți încărca dinamic un DLL neangajat și executați acest lucru - cu toate acestea trebuie să știți: adresa de memorie a codului, numărul/tipul de parametri, modul de marcare a acestor parametri etc. Apel în codul neangajat pentru a face lucrurile este practic imposibil fără a avea sursa.
adăugat autor Chris Smith, sursa
Nu sunt sigur cum mă va ajuta, fie că este vorba de un ansamblu .net sau de un ansamblu nativ, oricine ar trebui să fie capabil să-l încarce bine ..
adăugat autor cathy, sursa

Trebuie doar să cereți un cod de trecere care să fie trimis utilizând apelul funcției și dacă nu a fost autorizat, atunci nimic nu funcționează, cum ar fi .setAuthorizeCode ('123456'), apoi în fiecare loc care poate fi folosit trebuie să verifice dacă autorizeCode! = 123456 apoi aruncați eroare sau doar ieșiți din ... Nu sună ca un răspuns bun pentru reutilizare, dar acesta este exact punctul.

Singura dată când ar putea fi folosită este de dvs. și când codificați cu greu codul de autorizare în program.

Doar un gând, ar putea fi ceea ce căutați sau vă poate inspira la ceva mai bun.

0
adăugat

Nu sunt sigur dacă aceasta este o cale disponibilă pentru dvs., dar poate aveți posibilitatea să găzduiți ansamblul utilizând serviciile Web WCF sau ASP.NET și să utilizați un anumit tip de schemă de autentificare (LDAP, perechi de chei publice/rpivate etc.) pentru a vă asigura numai clienții autorizați se conectează. Acest lucru va ține adunarea fizică din mâinile oricui altcuiva și puteți controla cine se conectează la ea. Doar un gand.

0
adăugat

Puteți folosi obfuscation.

Aceasta se va transforma:

int MySecretPrimeDetectionAlgorithm(int lastPrimeNumber);

În ceva necitit ca:

int Asdfasdfasdfasdfasdfasdfasdf(int qwerqwerqwerqwerqwerqwer);

Altele vor putea să-ți folosească ansamblul, dar va fi dificil să faci orice lucru sensibil.

0
adăugat

Puteți semna ansamblul și executabilul cu aceeași cheie și apoi puneți o verificare în constructorul claselor pe care doriți să le protejați:

public class NotForAnyoneElse {
  public NotForAnyoneElse() {
    if (typeof(NotForAnyoneElse).Assembly.GetName().GetPublicKeyToken() != Assembly.GetEntryAssembly().GetName().GetPublicKeyToken()) {
      throw new SomeException(...);
    }
  }
}
0
adăugat
Am reușit doar să reușesc să lucrez după transformarea token-urilor într-un șir, de ex. BitConverter.ToString (typeof (NotForAnyoneElse) .Assembly.GetN & zwnj;. Ame() GetPublicKeyTo & zwnj; ken ())
adăugat autor JohnZaj, sursa
Cred că opțiunea InternalsVisibleTo menționată mai jos este mai bună. Este același lucru ca și acest răspuns, fără codificare. Trebuie să semnați ansamblurile pentru a putea lucra la InternalsVisibleTo. Cu ambele tehnici, ceilalți utilizatori pot vedea metodele și le pot folosi prin reflecție; dar ambele tehnici vor eșua dacă ansamblul de apel nu are aceeași cheie.
adăugat autor Rob Kraft, sursa

Ar trebui să puteți face totul intern, iar apoi utilizați InternalsVisibleTo Atribut pentru a acorda doar acelui acces la metode interne.

0
adăugat
poate bate reflecția?
adăugat autor cathy, sursa

The Code Access Security attribute that @Charles Graham mentions is StrongNameIdentityPermissionAttribute

0
adăugat
din această legătură - În versiunea 2.0 și ulterioară .NET Framework, solicitările pentru permisiuni de identitate sunt ineficiente dacă asamblarea de asistare are încredere deplină.
adăugat autor cathy, sursa

În .Net 2.0 sau mai bine, faceți totul intern, apoi utilizați Ansambluri de prieteni

http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx

Acest lucru nu va opri reflecția. Vreau să încorporez câteva din informațiile de mai jos. Dacă aveți absolut nevoie să opriți pe cineva să sune, probabil cea mai bună soluție este:

  1. ILMergeți fișierele .exe și .dll
  2. obfuscate finalul .exe

De asemenea, puteți să verificați stiva de apel și să obțineți ansamblul pentru fiecare apelant și asigurați-vă că toate acestea sunt semnate cu aceeași cheie ca și ansamblul.

0
adăugat
va reflecta acest lucru?
adăugat autor cathy, sursa
Nu, să învingi reflecția pe care trebuie să o încurci.
adăugat autor Rick Minerich, sursa

S-ar putea să setați acest lucru în politicile de securitate a accesului la coduri din ansamblu.

0
adăugat

După cum au menționat unii oameni, folosiți atributul InternalsVisibleTo și marcați totul ca fiind intern. Desigur, acest lucru nu se va opune reflecției.

One thing that hasnt been mentioned is to ilmerge your assemblies into your main .exe/.dll/whatever, this will up the barrier for entry a bit (people won't be able to see your assemby sitting on its own asking to be referenced), but wont stop the reflection route..

UPDATE: De asemenea, IIRC, ilmerge are o trăsătură în care poate internaliza automat ansamblurile care au fuzionat, ceea ce înseamnă că nu trebuie să utilizați InternalsVisibleTo deloc

0
adăugat
în mod ironic, același ansamblu este încărcat la cerere prin reflexie. Cred că nu există nici un mod de a preveni acest lucru.
adăugat autor cathy, sursa

De asemenea, puteți să vă uitați la utilizarea ambalatorului și a compresorului executabil Netz .

Acest lucru ia ansamblurile dvs. și fișierul .exe și le împachetează într-un singur executabil, astfel încât acestea să nu fie vizibile pentru lumea exterioară fără să se sapă în jur.

Cred că acest lucru este suficient pentru a împiedica accesul pentru majoritatea programatorilor .net.

Un mare beneficiu al abordării .netz este că nu necesită schimbarea codului. Un alt avantaj este că simplifică cu adevărat procesul de instalare.

0
adăugat

Dacă asamblarea a fost un serviciu web, de exemplu, ați putea asigura că executabilul desemnat trece o valoare secretă în mesajul SOAP.

0
adăugat

Se pare că sunteți în căutarea unui instrument de protecție sau de obfuscare. Deși nu există un glonț de argint, instrumentul de protecție recomandat este smartassembly . Unele alternative sunt Salamander Obfuscator , dotfuscator și Xenocode .

Din păcate, dacă dai octeții cuiva pentru a fi citit ... dacă au suficient timp și efort, ei pot găsi modalitatea de a încărca și apela codul. Pentru a răspunde în mod preemptiv la un comentariu pe care îl văd întrebați frecvent: Salamander vă va împiedica încărcarea directă a codului în instrumentul Reflector, dar am avut mai bine (de exemplu, mai fiabile) experiențe cu smartassembly.

Sper că acest lucru vă ajută. :)

0
adăugat