I've encrypted my CFML templates and lost the originals, now what?

This post is more than 2 years old.

Someone just asked in the CF IRC channel what they can do with set of encrypted templates. The developer on their team encrypted a bunch of code, deleted the originals, and left the company.

In the past, you could Google and download a tool to decrypt the files. Technically you were (as far as I know) breaking your license w/ Adobe. But apparently this tool doesn't work with recent servers.

I also heard rumors, and this was way back in the Allaire days, that you could call the company, explain the situation, send the files, and get the decrypted source back.

But what is the answer now? I don't want to promote any illegal hacks, so if someone knows the "official" answer, I'd like to know.

Of course, the best solution here is prevention. If your code was checked into a source control repository, and the developer didn't have admin rights to that machine, then your code would have been safe.

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA https://www.raymondcamden.com

Archived Comments

Comment 1 by Adrian J. Moreno posted on 12/29/2007 at 1:51 AM

Odds are, the developer that did that has copies of the unencrypted files at home. The threat of a lawsuit could help him "recover" the files for them.

If that doesn't work, a trip to his house with Mr. Louisville Slugger might do the trick. :)

Comment 2 by Ben Nadel posted on 12/29/2007 at 2:08 AM

I can understand a license issue if you got the encrypted files from Adobe, however, if your own developer encrypted files, I see nothing wrong with decrypting them??? That's like saying no one else can know the pass combo to a safe, even if you OWN the safe? That seems a bit silly to me.

Comment 3 by Raymond Camden posted on 12/29/2007 at 2:17 AM

I believe - stress - believe - it may be a DCMA violation.

I'm not a lawyer, so I could be wrong. We also have to separate between what we think is fair and what is legal. Yes, my files, I should be able to decrypt, but as we all know, just because we think we should be able to, doesn't mean we can. I mean heck - we can't even back up our own DVDs.

Comment 4 by Dan Russell posted on 12/29/2007 at 2:21 AM

This might be a stupid question... what was used to encrypt the files? Are they files hashed? Are they in a password-protected archive? I feel like I'm missing info.

Comment 5 by Ben Nadel posted on 12/29/2007 at 2:23 AM

How dare you try to back up your own DVDs :)

Comment 6 by Raymond Camden posted on 12/29/2007 at 2:28 AM

@Dan - CF, for a long time, has shipped with a utility to encrypt your files. It makes them unreadable, but they run just fine.

Comment 7 by Rob Brooks-Bilson posted on 12/29/2007 at 2:30 AM


I think the issue from Allaire/Macromedia/Adobe's point of view is how do you prove that the encrypted files do indeed belong to you. I think from a liability standpoint, if you handed them encrypted files that actually belonged to someone else (say you bought a commercial CMS that just happened to be encrypted), and they decrypted them for you, it could be an issue - regardless of intent. I'm sure they could make you sign something that transfers all liability to you, but that seems like it could be a big hassle. Probably the reason Allaire and Macromedia never advertised unencrypting files as a service.

@Dan, the algorithm used for the encryption was changed between CFMX 6.x and 7, I believe. It isn't a hash as that's a one way deal and the CF templates can be decrypted (and actually are by the CF engine).

Comment 8 by Ben Nadel posted on 12/29/2007 at 2:47 AM

Is this any different then when, say, someone breaks something like an MD5 hashing algorithm. I remember on NPR earlier this year, someone in China broke another hashing algorithm that was thought to be almost impossible (I think this is what I am remembering: http://en.epochtimes.com/ne... )?

Is doing something like that illegal? Is it even related? Or is MD5 not "owned" by anyone like the encryption algorithm might be "owned" by Adobe?

Security and encryption has always been mysterious to me.

Comment 9 by Rick O posted on 12/29/2007 at 3:56 AM

Way back in the heady days of CF4, there was a tool called CFDECRYPT written by a guy named Matt Chapman. He released the source, and I wrapped it up in a CFX named CFMEncrypt and submitted it to the Developer's Exchange. It took an inordinately long time for the tool to get listed (back in the days, each submission was manually verified before it was made downloadable), but eventually did.

But a few months later, a search for the tag revealed no hits. Inquiries to the DevEx people went ignored.

And then a few months after that, it was back, and seemed to have retained all of the download history from before it had been de-listed.

And then a while after that, it was gone again.

About once a year I get curious and go back and check to see if the current management likes it or doesn't like it.


Ben said: "Is this any different then when, say, someone breaks something like an MD5 hashing algorithm."

Nope. These are two totally and completely different things. A "break" for a hashing algorithm means that you've found a way to generate the same fingerprint (hash, signature, whatever) for any given input. This is bad because a lot of automagic-update functionality works off of hashes instead of full-blown digital signatures -- if the hash matches, we assume it hasn't been tampered with. But if someone "breaks" the hash, they can substitute another, malicious file in for the clean file, and no one would be able to tell just by looking at the hash.

This, on the other hand, is decryption, pure and simple. There's no real "breaking" to it, as you're not looking for the master key that CF uses to encrypt and decrypt files. You're not looking for it because it's known. In this particular case, the algorithm is 3DES and the encryption key is pretty clever:

Error: cannot open template file--"%s". Please, try again!\012\012

Sneaky, eh?

Ben also said: "Is doing something like that illegal?"

It could be considered illegal under the DMCA in the USA (and other countries with similar laws, such as Canada), if the source does not belong to you and could be considered an "anti-circumvention measure". I think cfcrypting files has long been established as an anti-circumvention measure, so really it comes down to ownership.

But, to be clear, it is not in any way illegal to figure out what the encryption algorithm or keys are. That's only the equivalent of walking up to a house and figuring out the brand of the lock. The illegal part comes in the application of that knowledge, and the circumstances of the application.

Be also said: "Or is MD5 not "owned" by anyone like the encryption algorithm might be "owned" by Adobe?"

Encryption algorithms generally aren't owned -- keys are owned. I AM NOT A LAWYER, but to the best of my understanding it is not illegal to figure out how to circumvent. (See previous paragraph.) And, as I mentioned, the algorithm that was used in CF4-6 (and I can't imagine that 7 and 8 wouldn't be backwards-compatible, even if they have taken on support for a new algorithm) was 3DES, a form of the DES algorithm, which was developed by the US government a ways back.

(This isn't to say that they algorithm cannot be owned -- it most certainly can. But again, figuring out how the algorithm works isn't in itself illegal, as the illegal part comes when you start applying that knowledge and breaking into things you shouldn't be.)

Comment 10 by Ben Nadel posted on 12/29/2007 at 4:18 AM


Tremendous explanation. Thanks for taking the time.

Comment 11 by Jeffry Houser posted on 12/29/2007 at 8:48 AM

A client once asked me to decrypt files for them. Unfortunately, most of the files had a copyright notice from the original developer of the application. I gave them the 1-2 files that did not have a copyright notice and told them they'd have to go back to the original developer.

They showed me "proof" of ownership, according to them, but that wasn't enough for me to do this...

However, if you do own the code appropriately, it should be easy enough to decrypt, as per Rick's post.

Comment 12 by Lola LB posted on 12/29/2007 at 8:21 PM

This certainly sounds familiar - a developer left a company i used to work for, and the files were password-protected somehow, and the developer never gave the password to the company. Hence, the move to a certain web scripting language. I guess I don't really have an answer to this, except that a good company should probably build in some insurance against this ever happening if a disgruntled employee leaves the company - maybe something like in the job offer have some sort of paperwork saying that if developer encrypts files belonging to the company without permission they're legally liable or whatever. Of course, run this by the lawyers first to make sure such paperwork stands up in court.

And maybe universities should have a "ethics in computer programming" course that is required for computer science degrees?

Comment 13 by Az posted on 12/29/2007 at 11:17 PM

If the files were encrypted using the utility that ships with ColdFusion then you can probably decrypt them using the utility that other people have mentioned. I don't know if ColdFusion 7+ changed the encryption routines that are used as I haven't personally tried to decrypt files that have been encrypted using the utility that ships with the latter versions of ColdFusion. It would be worth a try even if he had used the encryption utility shipped with a later version of ColdFusion, assuming you can find a copy.

If the developer in question compiled the source code into java byte code using the new utilities included with ColdFusion 7+ then I am not aware of any way to decompile the code back to the original source files. The compiled templates will also only run on the version of ColdFusion that it was compiled against if my understanding of the utility is correct.

Comment 14 by Roland Collins posted on 12/30/2007 at 1:05 AM

I'm guessing that Adobe isn't that concerned with decryption given that they have a tool available for download on their site that can decrypt cf templates for you.


It has actually saved me a couple of times in the past.

Comment 15 by Raymond Camden posted on 12/30/2007 at 2:48 AM

I'd be willing to bet that one doesn't wrk in cf7/8 though.

Comment 16 by Kyle Dodge posted on 12/31/2007 at 9:15 AM

Shouldn't the blog title be encrypted instead of decrypted?

Comment 17 by Raymond Camden posted on 12/31/2007 at 5:17 PM

Oops. Fixed now. Thanks.

Comment 18 by Rupesh Kumar posted on 1/2/2008 at 9:28 PM

There is no way to get the original source back from the encrypted cfm files because it is not encrypted in the first place. It is actually a class file. I am getting tempted to post a blog entry about this :-)

Comment 19 by Rupesh Kumar posted on 1/2/2008 at 9:51 PM
Comment 20 by Raymond Camden posted on 1/2/2008 at 9:55 PM

Rupesh, thank you very much for posting this. I don't believe this is really documented anywhere. Is it? It may be in the 10K PDFs we get with CF that not everyone reads completely. ;) Do you know offhand where/if this is in the official docs?

Comment 21 by Rob Brooks-Bilson posted on 1/2/2008 at 10:03 PM


Just to be clear, ColdFusion 8 still ships with the cfencode.exe utility. From the CF 8 docs:


"Note: You can also use the cfencode utility, located in the cf_root/bin directory, to obscure ColdFusion pages that you distribute. Although this technique cannot prevent persistent hackers from determining the contents of your pages, it does prevent inspection of the pages. The cfencode utility is not available on OS X."

So I think the question is, did this reader use the cfencode utility, and if so, does it use the same encryption algorithm as CF 6.x and earlier, or was it indeed updated for CF 7.x and up? It's been a while, but I remember discussion when CF 7 came out that the encryption algorithm had been updated.

Comment 22 by Raymond Camden posted on 1/2/2008 at 10:09 PM

So now I'm confused. I thought Rupush was saying cfencode was updated to work as he described, but I see he mentions cfcompile later in his blog entry.

Rupesh, what did you mean?

Comment 23 by Rupesh Kumar posted on 1/2/2008 at 11:58 PM

Sorry for creating the confusion :-)

cfencode and cfcompile both are separate and both work differently. cfencode is legacy from allaire days and hasnt been touched for a very long time. So if something is encrypted by cfencode, it will still work on CF8 and perhaps your utility can still decode it.

cfcompile is what I talked about in my post.

Hope that clears up the confusion.

Comment 24 by Rob Brooks-Bilson posted on 1/3/2008 at 1:03 AM

I just tested cfdecrypt.exe against code "encrypted" using the cfencode tool in CF 8. I was able to decrypt it. So, it looks like as Rupesh says, nothing has changed with the cfencode.exe utility that ships with CF8, and if your client has the tool, they should be able to decode the encoded templates.

Comment 25 by Raymond Camden posted on 1/3/2008 at 1:09 AM

Interesting. (And just to remind folks, this is not my code. It was someone in IRC.) But I'm curious - and maybe Rupesh can answer - what is the official Adobe answer? Ie, if I call right Support right now and ask, will they too tell me to Google for the decryptor?

Comment 26 by Rupesh Kumar posted on 1/3/2008 at 12:33 PM

I can't really comment anything on behalf of Support team but I don't see any reason why they should ask to 'google' for decryptor. Since we encode it, we of course know how to decode it :-). (We do it even now when you deploy the encoded script on CF server.)

This is apart from legal issues though.

Comment 27 by Mr Vebes posted on 11/26/2008 at 7:36 AM

On a related note, does anyone know of a way to decode the encrypted files within the CF Administrator? (I have honorable intentions ;) The problem is that /CFIDE/scripts/cfformhistory.cfm is encrypted and is called whenever a ColdFusion Flash form is displayed in a web page. This template contains the line:
codebase="http://download.macromedia...." width="100" height="50">');

Clearly it is not desirable that Flash version 7 is being specified as a minimum version. Even CF8 still uses this version of cfformhistory.cfm. It would be good to be able to decrypt the file, modify it and then encrypt it again.

To prevent cross site scripting attacks etc, I need my users to be on Flash version 9.0.28 as a minimum. Has anyone seen a workaround for this? Our strict corporate security has flagged this as a serious flaw and I do not have the time to convert all the ColdFusion Flash forms on the site to Flex (or create native Flash objects and use remoting for data transfer.)

Comment 28 by Mr Vebes posted on 11/26/2008 at 7:39 AM

Unfortunately, the important part of the embedded code above was truncated - the end of the link to the codebase should read:

Comment 29 by Mr Vebes posted on 11/26/2008 at 11:30 AM

OT: Found a solution to my problem, but does not help those looking for "legal" decryption of type 2 cfencoded templates.

To solve the "out of date" cfformhistory.cfm problem, rename the original file to cfformhistory_orig.cfm, then create a new cfformhistory.cfm file with the following contents:

<cfsavecontent variable="fh">
<cfinclude template="cfformhistory_orig.cfm">
#replacenocase(fh, "7,0,14,0", "9,0,28,0","ALL")#

Comment 30 by Don posted on 10/22/2009 at 9:17 PM

I have a client who is getting a cfformhistory error. This may be the problem. I find it interesting that I built his application on CFMX7 server, deployed it to a CFMX7 webserver, but when he put it on his CFMX7 server it broke the flash forms giving cfformhistory as the problem. So maybe there is a newer version of cfformhistory that he can install? Anybody know?