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

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

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

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

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.

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'd be willing to bet that one doesn't wrk in cf7/8 though.

Oops. Fixed now. Thanks.

Posted :-)
http://coldfused.blogspot.com/2008/01/encrypted-cf...

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

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

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.

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?