Adobe’s C:\Program Files\Common Files\Adobe\Adobe PCD\cache\cache.db file contains important information including licensing. I’ll go through ways to view and modify this file.
Adobe in recent times have taken to keeping licenses and other information like EULA acceptances in a file called cache.db. This file is located in C:\Program Files\Common Files\Adobe\Adobe PCD\cache. Deleting this file and then letting the relevant programs re-create the file is a common method of dealing with issues with serial numbers, EULA, language information but this isn’t always ideal. If your product is legitimately licensed but you don’t have the key handy, then you’ll be back to trial mode. If you’re still getting EULA messages the information is in here. I’ll go through a few things I’ve found about how to investigate and modify this file.
Opening the cache.db file with notepad doesn’t show a lot, but it should start with SQLite format 3. This was enough to lead me to investigate SQLite and to find something else to view the file. SQLite Browser will enable you to open and view the cache.db file. Once you open it up then navigate to the cache.db file (maybe take a copy) you’ll see the database structure which is basically 2 tables: pcd_meta and domain_data. Choose the Browser Data tab, then select the Table domain_data.
You should see 4 columns, domain (which is always 1), subDomain, key and value. Most of the entries in the subDomain column will be one of three types: a GUID, a serial or a LEID.
The GUID entries are standard Microsoft 32 character GUIDs and these should match with an entry in the registry inside HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.
For instance {A1BC7068-C1BA-410F-8B9A-DB807C803DE2} would correspond to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{A1BC7068-C1BA-410F-8B9A-DB807C803DE2} which would show you DisplayName = Adobe Creative Suite 5 Design Premium. So you’ll be able to see which product these relate to. For these entries if there is a key named EncryptedSerial, the value column would show you just that, the serial number that Adobe has encrypted.
In some cases these encrypted serials will also appear in the subDomain column and for these values you might see some keys called things like PPAID, PPCGO, PPAPP, PPSUITE and so on. In particular PPAPP might show something like Acrobat X Pro, so you could decuce that those entries would relate to Acrobat.
The third type of entry in the subDomain column is a LEID (licensing identifier). These will look like ElementsOrganizer-EMT11- Win-GM or AcrobatPro-AS1-Win-GM{|}ALL. The first part before {|} is the LEID and afterwards is the language. These entries were the ones I was most concerned with and they have entries in the key field like EULA_ACCEPTED, IsProductActivation, LineCU 2 or Acrobat_Base_10.0. The value fields for these rows will contain values relevant to that key.
From looking at this table you might be able to guess quite accurately if a EULA has been accepted, if a serial has been entered, which suites or applications are installed. Adobe’s installers seem to use the information here to detect if a product is already installed and other information about it.
So after that explanation, what can you do now that you know this? Well using SQLite Browser, you can modify the database directly. Change, remove or add the entries you like, then MAKE SURE you save the database. You can also compact the database from the File menu if you like.
If you’re like me and you administer large numbers of systems, you may be looking for ways you can manipulate this database in an automated way. There are a couple of main methods for this.
The Adobe Provisioning Toolkit provides an executable which can do plenty of things you may be interested in. Ultimately it modifies the cache.db file and if you use APTEE you could observer what it changes in cache.db. In my case this didn’t help because I wanted to accept EULAs and couldn’t work out what a DriverLEID was compared to a LEID.
Another option, which is what I went with is to use SQLite and to get the command-line shell. This gives you the option to complete SQL commands on the file and you can read up about SQLite. You can complete your typical database operations to select, modify, delete and all of that. For my purposes, I worked out the entries in cache.db I wanted to change (or create if they weren’t there) by comparing a before and after cache.db with SQLite Browser and created the list of commands I wanted. Then I used a command line with SQLite to run all of these.
So a SQLite commands file might look like:
insert or replace into domain_data values (1,”AcrobatPro-AS1-Win-GM”,”EULA_ACCEPTED”,0);
insert or replace into domain_data values (1,”ElementsOrganizer-EMT11-Win-GM”,”EULA_ACCEPTED”,0);
.quit
and the command to run this in a Windows command prompt would look like:
sqlite3.exe “path\to\cache.db” < mycommands.txt
Thanks for your informative post! I have looked into my cache.db file but the ‘SN’ key is unreadable, then I get my serial number back with the Product Key Finder program from top-password.com. This program can decode the serial number flawlessly.
This no longer works, as the cache.db file now is full of dummy info and the serial is elsewhere. I don’t know where.
Having revisited this today, my cache.db still looks like it contains an SN key
Which versions of Adobe software do you have installed? I haven’t looked at this recently
Hi,
I know this is an “old” post, but it has usefull info… In my case I have a customer which is using CS6 suite from adobe and has no volumen licence. We are trying to implement their enviroment into an VDI enviroment… When a user logs on a virtual desktop he can licence its adobe without problems. However if this virtual desktop is regenerated then this user will lost its licencing and then he must actívate the licence again…
I think that a possible solution could be to make some redirection folder rule to store cache.db into a remote (external) forlder… So each time a user logs on its VDI desktop, the virtual desktop will read a cache.db file which is actualy stored remotely.
Could this work?
Thanks