« Flash MX 2004 Easter Egg | Main | JSFL: Arrange Library »

January 21, 2004

The SWF - Flash Decompilers Problem

Some people are really upset about them, some have accepted them as 'facts of life'... As the publisher of first ever swf - flash decompiler 'Action Script Viewer', ASV, back in May 2000, I'm quite aware of every argument for and against them.

Flash decompilers are legal, they have legit uses. The problem starts when someone uses them to rip-off others work. Is there a solution?

Flashguru had a post about it today. While I'm flattered the way he mentions ASV, at a first look, I'm not sure what he proposes is feasible and offers a real solution.

We never intended to have a hacker / cracker tool with ASV. So a solution to this problem will really make us happy. But what can we do? I'm asking for your ideas.

Please consider the following first:

  • ASV is not the only SWF - Flash decompiler available (In fact, there are too many, I'd say :) ). If we deliberately have some way to protect code from ASV, a competitor will surely jump for the opportunity and advertise his product like 'Even shows what ASV can not!' If we discontinued ASV today, considering what the status of Flash has become over the last few years, a competitor will fill in right away.
  • Believe me when I say, you won't think it will happen to you, until it happens to you. I'm talking about losing your FLA files. Don't say if someone didn't back-up his work, he should bear the consequences. You might be next! And when you are left with your SWF files, they'll be as protected as they can be.
  • We don't find making money off both the disease and the cure ethical (and what someone calls the cure might well be what another calls the disease). So, if ever, we manage to have a protection solution, it will be free (But we are ready to spend our resources for it).

I'm, of course, aware that ASV cannot show all the scripts in all SWF files and there are successful obfuscation methods, though some require manual hard work.

If there's anything we can do about the problem, we are willing to do it.

Let me know what you think. Is there anything we can do?

January 21, 2004 in Flash | Permalink

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/t/trackback/8749/396120

Listed below are links to weblogs that reference The SWF - Flash Decompilers Problem:

» ƒекомпил€ци€: продолжение темы from ‘лэш ѕотрошитель
Ѕурак  алайджи предлагает обсудить, как производитель декомпил€тора ASV может помочь в защите от несанкционированного просмотра. „итать здесь: The SWF - Flash Decompilers Problem.... [Read More]

Tracked on Jan 21, 2004 9:26:51 PM

Comments

Does anything truly need to be done?

Personally, I think it is Macromedia's responsibility to protect our work. Although I'm not familiar with the underlying source code, the SWF format is open-source; should we close it to protect our future work or is it already too late? At the very least, preventing the SWF format from being so open would relegate cracking to the highly-skilled, and would render 2advanced & Branden Hall decompiled SWF's on wareze sites... this assumes that it, again, isn't already too late.

Personally, I think SWC is step in the right direction. Even when someone has the source, they don't know what to do with it. But the other side of the coin, the SWF, is dynamic and open enough that it's easily read. Are we willing to give up some freedoms to make it more secure?

The whole mafia-payout solution is bs. I will not "pay" anyone to protect my work; I've already paid for software knowing that it is unsecure. The maker of the software is responsibile to protect my work, to a point.

Director came with DCR's; why can't Flash do the same?

DIR = FLA
DCR = ...? SWC sort of, but not yet.

I'm thinking built-in obfustication or something is the only way.

Posted by: JesterXL at Jan 21, 2004 6:08:25 AM

i think that when MM first released the SWF specs as "open", they certainly didn't foresee where Flash was going, and the desire/ability of third-party developers to try to sell commercial components and want a secure method of doing so... had MM known that even their own commercial components could be at the mercy of unscrupulous users, they might have thought differently about making it open.

Posted by: g.wygonik at Jan 21, 2004 7:06:03 AM

I really don't think it's the fault of the .swf format being open. Look at amfphp - the amf format is NOT open, yet it has been recreated. I don't think the Java .class file format is open, yet Java decompilers exist.

The problem lies in the fact that the Flash Player is a virtual machine and needs to be able to understand what's in the .swf format in order to play it. Java code has the same problem, and well as .NET. Flash developer's aren't the only ones who are "stuck" with decompiling issues.

The answer is just write bad, unreadable code that people won't want to bother with anyway. The easiest way to do this is write an obfuscator that renames variables to giberish on the bytecode level, restructures code where it can, inserts random code that doesn't do anything, etc.

That way, even if someone can read all of the actions, by the time they understand what's going on it would've been easier for them just to write it on their own to begin with.

Posted by: darron at Jan 21, 2004 2:54:47 PM

Don't get discouraged, I have also found it to be a great tool for learning about the swf format as well. I definately think my coding has improved due a better understanding of btyecode and I owe that to ASV and Flasm. As for peeking at code, I have done it at times for swf's that really intrigued me. Is it bad to want that knowledge? How many of you can say you have not once learned a piece of javascript or html thru a browser's source code viewer?

Anyways, it's just a tool. It's really too bad there's even an illegal connotation. A lockpicking set doesn't make a locksmith a burglar does it? Like any other thing there may be adverse purposes but it's the user who determines that. Certainly we hope that if someone wants to reuse something, they would contact the developer for permission and accredit then but there will always be thieves. The only way to truly prevent your code from prying eyes would be to not release your work but that of course isn't an option. It's worse too that with the anonymous nature of the net, thieves don't feel a sense of consequence for their acts. There is no criminal web record, web police, court, penalty, jail, etc. The only thing people can do for protection is a license and take action after a malicious act occurs. So what are some other measures we can take besides focusing on the technology's security?

Posted by: dchang at Jan 21, 2004 5:11:50 PM

Ahh.. ethics... i dont see anything wrong with Flash decompilers. If MM has made the format open then this is a fact of life. Frankly theres a lot of ethics involved in how ppl use ASV and the like. I have used ASV in my early Flash days to decompile others SWFs and see how they did things. I didnt steal i used it to learn. And not i hardly use it at all unless i see something insane, not to steal but out of curiosity.. the same cusiosity that made me learn flash in the first place.

It all depends how u use it and i dont see any fault in the ppl who make flash decompilers. Java has decompilers that work pretty well.. .net has them as well. In fact u can retrive every source and recompile the app is most cases for java and .net. It all depends how the user uses the tool.

If anyone can reduce stealing code (i dont see this as a major problem... ill mention why later on) it is MM. they can work something into the player they plays encrypted & unencrypted files but this would go against SWF being an open format so i think its unlikely.

I dont see the stealing as a problem . This is because im used to it, its been around since ASV came out... and its been 4 years since (ASV's dont a remarkable job.,...) Next anything really worth stealing is usually either difficult to debug if you have a problem (no documentation) or is customized to the original developers solution. Simple libraries ported to Flash and other small cool experiments suffer the most i think... but if you looked hard online you would find a source file for it anyway....
The people who steal are pretty lame anyway.... if they go to the extent to steal the look and feel... and all the code... i dont even know wat to say to them... it's so blatant and pathetic... but its a fact of life...

i can decompile most java programs and nearly ever .net program and recompile them. so SWF is another one... ok. next issue. we have known about this for a while and nothing has changed.

nik

Posted by: Nik Khilnani at Jan 21, 2004 6:22:03 PM

Practically speaking tho... obfuscation is a good way to go... but i havent used any of the tools... which ones are there now?

nik

Posted by: Nik Khilnani at Jan 21, 2004 6:24:06 PM

Why would you decompile a 2advanced swf? You can see everything it does. If you want to copy it - go ahead!

Anyone can copy somebody else's style, that is not going to make you a successful developer. Figuring out someone elses code is often more difficult than writing it yourself.

Posted by: felix at Jan 21, 2004 8:31:38 PM

imho, this topic is just plain old tired! as often as it comes up, whoever starts it knows it's just talk and that's where it ends.

Posted by: eokyere at Jan 21, 2004 8:58:06 PM

Hmm, I few years ago people had the same weary reason to attack javascript. Everyone realises after a while that as it is on the www and gets d/loaded to the viewers computer, there is always going to be ample opportunity to get the code be it hidden or not. You want to avoid it, stick to server side - that's the general j/s convention and I see no reason why flash should differ. If you absolutely can not allow others to see your code, don't go using flash - take it as a caveat to flash's use. You know what it is before you use it, so quit whinging when others use ASV to take a peek.
ASV provides a valuable service - making it easier to see the code that isn't protected anyway and 99% of programmers aren't unduly worried about people seeing. We have all had code 'stolen', but we have all borrowed/stolen/gained influence from other peoples code at some point. It's a learning thing - people seeing how you built it isn't going to devalue what you did - in fact most people give credit to any 'new' thing done in flash so you end up more respected once the code is picked over.
I have no idea how old flashguru is, but his 2 solutions certainly make him appear to be pretty damn naive - teenage solutions at best. As he has in the past appeared to be an advocat of code-sharing, it seems he hasn't given much more than a spoilt-brat approach to code protection. That isn't an attack on him - he is certainly a respected flash developer, it's just applying a little common sense to an irrational post.

JMTCW

M

Posted by: R at Jan 21, 2004 9:27:11 PM

I know it's a well beaten horse, but I've never thrown in my opinion, so here it is.

I'm just curious if anybody that has NOT stolen code is still supportive of ASV and other decompilers as they are. It seems that most the posts I've read in the past few days from supporters say things like "hey, we've ALL stolen code in the past. It's how we learn" -- an obviously poor generalization. Get yourself some good books or read through one of the hundreds of tutorials out there. If a Flash developer wants the world to know how he acheived something that might have taken him hundreds of hours to produce, he'll write a tutorial or make it open source.

As for:

"If we deliberately have some way to protect code from ASV, a competitor will surely jump for the opportunity and advertise his product like 'Even shows what ASV can not!"

I suppose a move like this might really show just how strongly the makers of ASV feel about it's legit uses ;)

-Jed

Posted by: Jed at Jan 21, 2004 10:49:34 PM

Just a quick answer to Jed,

If we say 'use this two lines of action in your movies and ASV won't open the files', a lot of people will have the code there to protect their work. But when they lose the FLA and have legit need to get their code back, they'll need a decompiler that can show their code. That's the dilemma.

Also, while we claim that we have strong ethics (you don't have to believe this of course), we certainly don't claim it for our competitors. If I, somehow, come to the understanding that what we are doing with ASV is not right at all; we'll discontinue ASV that moment. But the problem will still be there...

I can assure you that I have received many sincere emails thanking me, even some wrote 'for saving my life!', from respectful developers who used ASV to get their own code back. That's been what has kept us going all these years...

Posted by: Burak KALAYCI at Jan 21, 2004 11:13:59 PM

For context, the Flash world definitely isn't the first to have a lot of attention on this subject.... ;-)

(I'm serious, read the replies in those FAQs... they apply greatly to our situation as well.)

I definitely agree that restrictions on the abilities Burak provides would only increase the incentives for others to provide the same abilities. There's a parallel discussion PDF land too.

What to do? At first I thought it might help to publish each downloader's name, until I realized that would likely just lead to more of the low-integrity people stealing Burak's bits.

But what about a "Hall of Shame" approach, with code comparisons printed in plaintext? SWF is a clearly-written binary format, and websites are open to the public, and wide mindshare increases pagerank in a potential perp's search-engine-resume, so these facts-of-life can cut both ways...?

Hold it, maybe there's another idea that could be in ASV itself... suppose you could put a specially-named URL-holding variable in your scripts that ASV would read, and ping next time it came online? That could alert a creator that their file was opened. It would fail if someone uninstalled ASV before going online, or if they controlled their outgoing messages, or if they went to the trouble of getting a hacked (and potentially malware-enhanced) version from people without reputations, but all those paths seem expensive. It might also increase the incentives for competitors among the ethically-disenfranchised, but hey.... A built-in pinger which recognizes specially-named info in the file, might that help satisfy all concerns...?

Posted by: John Dowdell at Jan 22, 2004 12:05:27 AM

oh, gosh, my links were stripped:

"read those faqs"
http://www.google.com/search?q=%22protect%20my%20javascript%22%20faq

"acrobat evaders"
http://www-2.cs.cmu.edu/~dst/Adobe/Gallery/

Posted by: John Dowdell at Jan 22, 2004 12:07:04 AM

Dear JD,

Is your first link about 'JavaScript'? I'd have assumed 'Java' would be a more similar case. (And more recently the .NET).

Thanks for the input, appreciated.

Posted by: Burak KALAYCI at Jan 22, 2004 12:21:04 AM

I dont think ASV should be modified to track ppl who decompile using the app... OR prevent decompiling.

i think that would creating a problem to fix something that is not.

ASV and other decompilers are fine. work on you projects knowing that your swfs can be decompiled.


nik

Posted by: Nik Khilnani at Jan 22, 2004 12:53:25 AM

Burak, why don´t you add an obfuscator to your product range?
You probably know the best where the limits of decompilers are and
how to make their work more difficult ;)

Posted by: Florian Krüsch at Jan 22, 2004 3:29:01 PM

хуйня все это полнейшая

Posted by: asd at Jan 23, 2004 11:22:57 AM

Just a little quote, that sums up the situation, when it comes to making Burak liable for damages, for developing Actionscript Viewer:

"I think that technologies are morally neutral until we apply them. It's only when we use them for good or for evil that they become good or evil"

- William Gibson

Posted by: Guy Watson at Jan 25, 2004 4:21:13 AM

William Gibson,sorry but that sounds like an NRA promo slogan,like saying guns and weapons aren´t bad themselves..
anyway,i think the solution already mentioned might work:
burak adds somne fancy to asv which allows users to protect their stuff from asv (for a yearly fee or something they can get a special serial and asv recognises that in the swf and doesn´t rip it.if owners of such an swf loose their fla,they can contact burak or use asv with their serial to get the fla back.therefore its made sure that noone is allowed to use other software to unprotect the file as that special protection shows that the creator of that swf only wants to have it edited with asv and also only when he uses his serial (or other protection key or by contacting bnurak .)
other decompiler creators might come up with tools to get around that fancy trick but then everyone could sue them as its clear that this fancy was applied to protect ones property,so a software which has the explicit feature to break that protection would be illegal.
a similar example showing that this works in a way (and also shows the weaknesses of this attempt):
in germany cd ripping is sued badly nowadays.
software which copies cds isn´t illegal but software which also allows to break copy protection is illegal and is no longer allowed to be sold (and everyone can sue the developers of that software for the loss they have if someone steals their property.
the weakness of this attempt is of course that many may still rip the stuff but at least that way they can be sued and get punished.

Posted by: tom at Jan 30, 2004 10:16:50 PM

Its important to point out to people caught up in these thoughts: Theoretically, obfuscators are the ONLY solution. Virtual Machines can do _nothing_ to solve this dillemma;
squabbling over ASV or paying for this or that tool is just silly (unless its a damn good obfuscator).

Posted by: Seth at Feb 1, 2004 11:26:55 PM

Well... someone can build a de-obfuscator as well. Due to the fact that Actionscript always will be an interpreted format, there will always be a way to re-create what the Actionscript does via decompiling/recompiling. It's unavoidable.

I think JD's comments have some merit but they may introduce other problems.

The "Hall of Shame" approach actually seems pretty sweet. It might lead to Libel lawsuits though ... gotta be careful when barking up the public-eye approach. Sounds nice until someone gets mad (think Dunkin Doughnuts getting sued for hot coffee, or MickyD's for making someone fat).

Posted by: Jon Bradley at Feb 24, 2004 9:27:36 PM

Hi,
Don't know whether this is the right place to ask a question. But any help really appreciated. I have scene that ASV can safely save a bitmap resource to jpg/png format. What I need is modify that jpg/png and save back to swf. Is this possible? (I mean not using ASV, but directly changing the byte code) I have scene some similarity between the bitmap resource data and jpg. But couldn't figure out what is the relationship between the bitmap resource and jpg/png formats.

thanks in advance,

Ruwan

Posted by: Ruwan at Mar 5, 2004 7:06:31 PM

Ruwan,

SWF format is available at http://www.macromedia.com/software/flash/open/licensing/fileformat/ . If you are looking for a do-it-yourself low-level solution, you should spend some time on the specs.

Also, our application 'URL Action Editor' can change symbols in a SWF file, with symbols in other SWF files.

HTH.

Posted by: Burak KALAYCI at Mar 5, 2004 7:23:53 PM

Thanks a lot burak!

Posted by: Ruwan at Mar 5, 2004 7:27:30 PM

'Figuring out someone elses code is often more difficult than writing it yourself.'

got to agree with that - why bother?

Posted by: mushie at Apr 30, 2004 9:49:35 PM

Post a comment