This is *exactly* why we do Flash Encryption using Nitro-LM.

We actually demonstrated a decompiler at the 360|Flex in Milan, Italy a few weeks ago (used Discovery.com's Earth Flash Application as a live example). The attendees at the keynote were "wowed" with how well the decryption worked and how much information was at your finger tips with just a little bit of digging.

We then showed how to encrypt that same application, and license using Nitro-LM. That was also well recieved.

We have seen several of these come out (some free, some costing). It is a trend that is unfortuantely growing.

Dave

From what I understand, Flash Encryption is not effective. My Adobe user group discussed the issue and the conclusion was that Flash Encryption was sort of a scam.

Can anyone shed more light on this?

Alan,

I'm not sure how your user group reached that conclusion. Encryption as a technique has been used in the Java world for many years as a means of code protection. Encryption's success largely depends on how you handle the key management. If the key is stored server-side and requires a valid user authentication before an application can be unlocked, encryption becomes a very viable alternative to other techniques such as obfuscation. Obfuscation has the limitations that it 1.) could introduce bugs into your code and 2.)becomes difficult to debug runtime issues

There are some vendors out there doing obfuscation or "encrypted obfuscation" and calling it encryption. Other than that possibility, I'm not sure how the label "scam" applies to encryption.

See my earlier articles on encryption in flex applications:
http://www.insideria.com/andrew_westberg/

-Andrew

I also feel encryption is a scam. We all know there's no 100% safe encryption. It's just a battle between encryption software and decompilers. SoThink can quickly dispatch an update that claims can decompile files encrypted by Nitro-LM.

Obfuscation is really a good way to go. But the problem is Obfuscation for complicated codes tends to end up dysfunction. Yet, if the codes are simple the user still can read it after obfuscation. At the level of AS3 and OOP, if the codes are well organised I don't see there's a problem of reading a obfuscated class.

What do you think?

That previous comment seems like bad argument for Obfuscation. Using a tool that results in something that could be well organized and interpreted by a developer practicing "ethical" decryption (what an oxymoron that is) does not sounds like a good tool for protecting your Intellectual Property.

Your comment about SoThink in relation to Nitro-LM is *not* factual.

Obfuscation is like putting a different color of paint on the building and calling it done. With encryption, you can't tell if it is even a building.

We demonstrated a AS3 Decompilers in Milan, Italy (live) on Nitro-LM encrypted applications that we encrypted (also live) - the decompilers did not work after encrypted with Nitro-LM...

In the end, Obfuscation vs Encryption is a preference that is tied to how secure you want to be, your level of understanding in the subject(s), and comfort level in the application of either of them. Not many people understand the details and process of encryption, and that is OK. But I think fewer understand the workload (re-testing and validation) required to truly make sure Obfuscated code works as the original code does.

As Andrew pointed out earlier, if you do choose encryption, and do not take the most basic steps to properly implement and manage it, your just asking for trouble. This is part of why Nitro-LM's approach is unique and specialized. Andrew's articles on the subject of encryption in general explains this issue very well - I recommend anyone interested take a look at them and consider the dramatic differences in effort and quality of the results.

My $0.02

Dave

Unless a user has a unique key to access the encrypted content, there is no way to properly secure a flash application. If the browser can interpret it so can a human.

And unless you have the most advanced code in your SWFs, I see no reason to go beyond obfuscation and/or simple encryption.

I can see the need to protect your SWF from being stolen and used outside the framework it was created for, but somebody with the know-how to break into an obfuscated file is just trying to learn, no to steal.

I've recently posted my thoughts about Flash Pirates and SWF Hackers which I think are two completely different animals to be aware of.

I just had a funny thought.

If one person takes a bit of code from another, it might be considered "theft", if 1000 people do it, it becomes a technique.

heh

Alan - Excellent Observation!!!

My view of the world:

"If you give customers control - they will steal!"

For this reason, we do our best to prevent this from happening. In the real world, where real-money is involved for the development of applications, people paying for it don't want it stolen (it is not just about the code, its the process and techniques also).

There is no such thing "ethical" hacking.

Products like SoThink make money by casting impressions of "ethical" hacking when in actually, your breaking into someone's house and looking around. "Breaking and Entering" is still a crime, even if you do not take anything.

Products like the SoThink SWF Decompiler and others have no other purpose or benefit.

Do you go to the book store, and read as much of the book as you can each day then leave without buying it?

Sometimes its just better to buy the book or go to a class!

Just noticed this:

http://www.insideria.com/2008/05/learning-from-others.html

Excellent, and timely post.

Sometimes people are just interested, how did they do that, how does that work, and what code made it do that ?

Not everyone is out to steal your work.

We have various applications, till software, website software, cctv software. And yes within certain sections there is heavy encryption.

Most secure encryption revolves around only a handful of people actually knowing whats being done.

And applications that use a simple if its correct then go on method find that there software is very quickly in the public domain.

Instead use varying methods witin your applications, so at one point just check a self generated file exists during install, check the date at some point, do varying other methods, if theres an internet connection, just fire off a message to a server with the license key in it.

Another really good option is to simply wait 10 minutes into the application and then check the key.

Within websites, its very hard to do these things, not impossible but hard.

Within flash files, pretty damn impossible me thinks.

As someone else has already said, if a reader can read the file, then so can we all.

www.anywheresupport.co.uk
www.hestor.com

Dave

I don't understand the controversy here. A binary, or swf for that matter, is merely a set of instructions to be executed by a computer. Decompilation is simply parsing those instructions into human readable format; its not _theft_ any more than reading a book is. Would you consider it unethical to read raw html, as opposed to rendered through a browser? Thought not.

SWF-Decompiler? Hm, i tested ca. 8 SWF-Decompiler Software and can say: Many mistakes at almost every :(

PS: Tutorial video ist not more aviable.

Best Regards
Freeware Eugen

John you're spot on

Does the encryption work by essentially hashing the swf and the user needs to decrypt it by getting the key from the authorized server? If that's the case, once the user decrypts it, it will be in readable format to his machine in RAM. Therefore, he can simply extract the swf data from RAM and it would be like it was never encrypted. It's easy to run it through SoThink at that point and decompile it.