ActiveX controls can be found in many Window's 95/98/NT applications, from web pages to programming languages such as Visual Basic 4 and above. My Essay No 3 dealt with one such ActiveX control, Videosoft's VSOCX6.OCX control, an add-on for Visual Basic 4/5/6 which is by far, the most useful add-on I've ever seen!. It's a shame though, that the developers have decided to use such a weak protection system for their industry leading controls! 
 

By and large, ActiveX controls, especially those used in Visual Basic do *not* require any patching to their code, that was where I went wrong. I tried to crack a nut with a sledge hammer instead of trying to understand exactly -how- an ActiveX control operates under Windows. 
 

Now install this control on your system as normal. Our ActiveX control (VSOCX6.OCX) can be found in our C:\Windows\System folder with a file size of 232K.  

Now fire up Visual Basic and via the Tools Menu then Custom Controls select the "Videosoft vsOcx Controls' option. 

We're now ready to use this control in our program..:) 

Now insert this control onto a form, if you've started with a new project then Form1 will already be opened for you. 

So far so good, no nag or error message..:) 

Now Run our project.  As expected, we are presented with a runtime nag screen, clicking on the OK button clears this nag for the duration of the running program.  

So what is happening here?.  

What we have is a control that when executed performs a check on our computer to see if it has been registered, this can be via one of a number of ways.  

The two most common/standard methods used are:- 

1. Performing a check in the User's Registry file for a valid license key. 

If you open up your Registry File using RegEdit and go to this location: HKEY_CLASSES_ROOT\Licenses  you will see a number of CLSID's keys, these keys usually contain an encrypted string that identifies it as being a valid license key for a particular OCX control. This is the standard way that license keys are formatted and stored in the Registry file. 
 

2. Locating a valid .lic file of the same filename used for the control itself in the User's \Windows\System directory. So if our control is called VSOCX6.OCX then the .lic file will usually be be named VSOCX6.LIC 
  
  
Since our control is unregistered, whatever checks it makes for the presence of a valid key/.lic will fail, thereby triggering our nag screen. 

The weakest of the two protection systems described above is the reliance on finding a key within our System Registry file, so we will begin work examining what checks, if any, our control makes to this file. 

FileMon is an excellent utility that records all accesses made to our Registry file, although it's pretty much useless when used on VXD's, but this is not a worry to us since our control is not a VXD. 

Right, lets us begin... 

Save your VB project with our control still on the form and then re-load it. This is necessary in order to clear the nag screen display flag. The nag screen doesn't always show when you re-run the program so we will start a fresh.  

Before running our program fire up RegMon and set it's Process filter to Include only Vb32 or whatever development version of VB you are currently using. Already RegMon has started to record a number of events to our Registry File. Now run our program again, our Control should already be on our form. 

When the nag screen appears go directly into RegMon and click on the Icon to prevent any further Registry recordings being made.  

Now look closely at RegMon's output, you are looking for a line that looks like this:- 

OpenKey HKCR\Licenses\30A04360-A239-11d1-BAA2-444553540000 NOTFOUND  

Bingo!. We have found such an entry but what does it all mean and how do we make use of it?. 
  
  
  

As already explained, most ActiveX/OCX controls that uses the System Registry to store it's license keys will, 99 times out-of-a-100 use the  HKCR\Licenses\ folder to store it's license keys in.  Any line ending with SUCCESS instead of NOTFOUND can be ignored, since we're looking for something that the control is looking for but cannot find, our license key for instance..:)   Armed with this knowledge tells us what we must look for in Regmon's output. 

So how do we make use of this knowledge? 

Easy, simply fire up RegEdit and go into HKEY_CLASSES_ROOT folder then scroll down until you come across the \Licenses folder. 

From here create a new Key. 

Give this Key the same 36 character name being searched for by our control. In this example our new Key would be called "30A04360-A239-11d1-BAA2-444553540000". 

Now when you re-run our VB program there will be no nag screen reminding us to register the control. 

Job Done..:) 
 
 

If your in a hurry or, you don't yet have Visual Basic installed then open up the file: 
c:\windows\system\vsocx6.ocx using Hex Workshop and perform a ASCII search on it, using "Licenses" as your search string.