Twitter: raymondcamden


Address: Lafayette, LA, USA

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

12-28-2007 10,592 views ColdFusion 30 Comments

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.

30 Comments

  • Commented on 12-28-2007 at 2:51 PM
    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. :)
  • Commented on 12-28-2007 at 3:08 PM
    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.
  • Commented on 12-28-2007 at 3:17 PM
    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.
  • Commented on 12-28-2007 at 3:21 PM
    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.
  • Commented on 12-28-2007 at 3:23 PM
    How dare you try to back up your own DVDs :)
  • Commented on 12-28-2007 at 3:28 PM
    @Dan - CF, for a long time, has shipped with a utility to encrypt your files. It makes them unreadable, but they run just fine.
  • Commented on 12-28-2007 at 3:30 PM
    @Ben,

    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).
  • Commented on 12-28-2007 at 3:47 PM
    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/news/7-1-11/50336.html )?

    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.
  • Commented on 12-28-2007 at 4:56 PM
    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.

    http://www.rixsoft.com/ColdFusion/CFX/CFMEncrypt/

    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.)
  • Commented on 12-28-2007 at 5:18 PM
    @Rick,

    Tremendous explanation. Thanks for taking the time.
  • Commented on 12-28-2007 at 9:48 PM
    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.
  • Lola LB #
    Commented on 12-29-2007 at 9:21 AM
    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?
  • Az #
    Commented on 12-29-2007 at 12: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.
  • Roland Collins #
    Commented on 12-29-2007 at 2:05 PM
    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.

    http://www.adobe.com/cfusion/exchange/index.cfm?ev...

    It has actually saved me a couple of times in the past.
  • Commented on 12-29-2007 at 3:48 PM
    I'd be willing to bet that one doesn't wrk in cf7/8 though.
  • Commented on 12-30-2007 at 10:15 PM
    Shouldn't the blog title be encrypted instead of decrypted?
  • Commented on 12-31-2007 at 6:17 AM
    Oops. Fixed now. Thanks.
  • Commented on 01-02-2008 at 10:28 AM
    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 :-)
  • Commented on 01-02-2008 at 10:51 AM
    Posted :-)
    http://coldfused.blogspot.com/2008/01/encrypted-cf...
  • Commented on 01-02-2008 at 10:55 AM
    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?
  • Commented on 01-02-2008 at 11:03 AM
    Ray/Rupesh,

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

    http://livedocs.adobe.com/coldfusion/8/htmldocs/he...02.html

    "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.
  • Commented on 01-02-2008 at 11:09 AM
    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?
  • Commented on 01-02-2008 at 12: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.
  • Commented on 01-02-2008 at 2:03 PM
    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.
  • Commented on 01-02-2008 at 2:09 PM
    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?
  • Commented on 01-03-2008 at 1:33 AM
    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.
  • Commented on 11-25-2008 at 8:36 PM
    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.com/pub/shockwave/cabs/...; 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.)
  • Commented on 11-25-2008 at 8:39 PM
    Unfortunately, the important part of the embedded code above was truncated - the end of the link to the codebase should read:
    .../cabs/flash/swflash.cab#version=7,0,14,0
  • Commented on 11-26-2008 at 12: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 cfformhistoryorig.cfm, then create a new cfformhistory.cfm file with the following contents:

    <cfsavecontent variable="fh">
    <cfoutput>
    <cfinclude template="cfformhistory
    orig.cfm">
    </cfoutput>
    </cfsavecontent>
    <cfoutput>
    #replacenocase(fh, "7,0,14,0", "9,0,28,0","ALL")#
    </cfoutput>
  • Commented on 10-22-2009 at 12: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?

Post Reply

Please refrain from posting large blocks of code as a comment. Use Pastebin or Gists instead. Text wrapped in asterisks (*) will be bold and text wrapped in underscores (_) will be italicized.

Leave this field empty