[VB] ActiveX Dll beveiligen

[Verwijderd]

Hoe kan ik een eigen gemaakte DLL beveiligen voor anderen??

Een met VB gemaakte "ActiveX dll" kan middels de project->references aan een ander project gekoppeld worden. Vervolgens kunnen de objecten die in de dll gedefinieerd worden gebruikt worden.

Als iemand niet weet hoe de DLL aan te spreken is dat uiteraard heel erg lastig. VB echter met object browser en code completion, in combinatie met de door mij bedachte "GOEDE" property, method namen, en input output variabelen. Vergemakkelijken dit wel enorm.

Op deze manier kan iemand anders gebruik maken van mijn DLL, en dat wil ik liever niet. Is er een manier waardoor de DLL alleen door mij gebruikt kan worden??

Bijvoorbeeld door:
- Het afschermen van de namen waardoor alleen iemand die weet hoe de dll in elkaar zit deze kan gebruiken.
- Het afsluiten van een dll voor ontwikkeldoeleinden. Bijvoorbeeld zodat alleen gecompileerde code de dll aankan?? of is dat een vreemde onmogelijke gedachten

Weet iemand hier meer van?

[Verwijderd]

als het niet open-source word:

dan schrijf je zelf een functie die aan hand van een 'interne identificatie code' (ofzo) de andere (niet ge-exporteerde) functies, doormiddel van pointers, doorgeeft.

een soort van request code aan een publieke functie in de dll. Als die request code (aanmelding) geaccepteerd word, dan kan je de rest van de objecten teruggeven...

(ik hoop dat ik een beetje duidelijk ben)

[Gerco]

Er bestaat zoiets als een "licence" voor een ActiveX Control/Dll, hiermee kun je bepalen of het alleen runtime of ook design-time gebruikt mag worden.

Kijk hier voor meer info: Licensing Issues for Controls

edit:

Blijkbaar is licensing alleen voor ActiveX Controls (*.ocx) en niet voor ActiveX DLL's en EXE's.

MSDN over de "Require License Key" optie in Project Properties:[quote]
Require License Key
Enables licensing for ActiveX Control projects (projects that compile to .ocx files), not to .exe or .dll files. A Visual Basic license file (*.vbl) will be created when you build the project. The *.vbl must be registered on the user's machine for the components to be used in the design environment. The Package and Deployment Wizard will build a setup program that properly registers the information in the *.vbl file on the end user's machine when that setup program is run.
[/quote]

[Verwijderd]

Alleen beetje jammer dat dit alleen in ActiveX controls geimplementeerd is door vb en niet in activeX dll's waar de topicstarter het over heeft.

[baskabas]

Op maandag 08 april 2002 10:57 schreef KingLois het volgende:
Is er een manier waardoor de DLL alleen door mij gebruikt kan worden??

Je zou code kunnen schrijven die de username checkt en deze afvuren in het "Initialize" event van de class... als er dan niet de juiste user aangelogd zit moet je een runtime error genereren (bijv. de gereserveerde ""Error 429. ActiveX component can't create object").

Op die manier worden ze op een dwaalspoor gezet... Waarom werkt die DLL niet?

[Verwijderd]

Ik zou de dll een extra functie meegeven die je eerst moet aanroepen met een bepaald argument (bijvoorbeeld: myFirstDll.GeefWachtwoord("*****")). Deze functie zet in je dll een boolean op true als het goede wachtwoord wordt gegeven. Vervolgens start je elke andere functie met controleren of de boolean op true staat. Maar het zal ongetwijfeld beter kunnen...

[blackbit]

Bij VB is het doorgeven van een GUID naar de libary de meest gebruikte methode; zoiets als :

<LIBRARY_DLL>.<GlobalMultiUseObject>.setLicense("{76b8d02c-e68c-4b19-9745-55f85efb2cee}")

Intern zet je dan een variabele op 'True' die gechecked wordt in de volgende calls. Zorg wel dat die variabele enkel zichtbaar is in 1 instance van de DLL (in-process).

Een andere mogelijkheid is het checken van de Process-ID dmv. een aantal Win32 API calls. Zo kan je kijken of je inderdaad binnen het proces van je eigen app. draait. Indien dit NIET zo is, doe je iets als While True ...
Nadeel van deze methode is dat je op voorhand moet weten welke applicaties van je DLL mogen gebruik maken...

[Verwijderd]

Bedankt voor jullie reacties!

Als ik het goed begrijp dan kan wat ik wil niet standaard met VB. Ik zal dus zelf een beveiliging in mijn Dll moeten bouwen.

Zelf aan het programmeren dan maar weer