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. :)

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.

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.

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.

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

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

@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).

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.

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/Cold...

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.)

@Rick,

Tremendous explanation. Thanks for taking the time.

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.

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?

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.

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/cfusio...

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

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

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

Oops. Fixed now. Thanks.

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 :-)

Posted :-)
http://coldfused.blogspot.c...

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?

Ray/Rupesh,

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

http://livedocs.adobe.com/c...

"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.

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?

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.

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.

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?

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.

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.)

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

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">
<cfoutput>
<cfinclude template="cfformhistory_orig.cfm">
</cfoutput>
</cfsavecontent>
<cfoutput>
#replacenocase(fh, "7,0,14,0", "9,0,28,0","ALL")#
</cfoutput>

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?