Printable View
In the vein of what Flax said earlier, you (like the RIAA and MPAA and video game industry) need to come to grips with the idea that if people want something digital, theres not much that will stop them, and then use that to your advantage. It's a goofy world we live in where success is measured by keeping your product out of the hands of people who want it.
If it's pay-software, make a demo version, if not, give your users (law students?) some links to embed it in blogs and social networks.
I think TonyPA's bytearray idea seems to make sense.
I'm estimating my final file to be around 6MB, so I'm gonna have a go at writing a flash app which converts SWFs into bytearray filled data files.
I'll keep you guys updated on how it goes.
I gave the .png idea a shot and made a post about it if you wanna check it out:Quote:
Originally Posted by f-zero
http://board.flashkit.com/board/show....php?p=4065461
Although it will probably be of limited effect, you can essentially compress your swf three times when storing it as an image. The first time is the compilation to .swf, the second time can be a deflate zip of the bytearray and the final time is the pngs built in compression. I am doubtful that it will have much impact but it is somewhat funny.
Thats pretty impressive! :)Quote:
Originally Posted by Schfifty Five
http://madbunnymedia.com/GuardBunny.as
That's an AS3 class that I made this morning to break decompilers. You use either a FlashVar or a String that should be in the URL, if that FlashVar is missing (as it would be in a decompiler, no HTML embedding) or if it's not at a url you said for it to be at (like a hacker's computer) the swf will commit suicide, fairly effectively. It will even work if they just try to play it normally where they shouldn't.
I've only ever tested on so- think SWF Decompiler 4, if you convert to an .fla, it's just blank, and if you open it with the program, it crashes. Lemme know if you get any different results.
Since the idea is to stop piracy, I would appreciate it if you guys left my ASCII logo in it, and kept the class name, go ahead and change the package to fit into your class packages though.
It's got some documentation in the file, if you have questions post them here, if it fails, give me some details so that I can find a way around it, I haven't tested or used this much, so you guys can be my beta testers.
I just took a look at that. Throwing it into an infinite recursion when stolen is pretty funny, but it should just trigger the "A script has gone on longer than 15 seconds" error instead of actually crashing anything, and I don't see how that's supposed to defeat decompilers. If it does (and I believe you), that's a bug in the decompiler rather than anything intrinsically awesome with that approach.
Still, thanks for sharing, and it is pretty cool.
It catches the 15 second error and restarts the recursion, It also catches stack overflow errors and restarts the recursion. Trust me, I've crashed SWF Decompiler 4 about 50 times today, and have about 20 blank .fla files on my desktop. The logic works at least on SWF Decompiler 4, the only one I have.
Those are catchable?! 15 second error I can see, but stack overflow really shouldn't be, for just this reason.
SWF Decompiler 4 must attempt to execute code or build a call-tree or something. That seems even more exploitable :) I still think it's a decompiler bug, but that's great.
Wow, that's really cool... I can't believe it even crashes SWF Decompiler 4 :D
And I had no idea that stack overflow errors could be caught..
they are all catchable :)
Decompilers take the path of least resistance, at runtime, Flash registers all it's classes to an ApplicationDomain class, the best way for a decompiler to grab code is simply start the thread running in the VM, and strip out the data from the ApplicationDomain, at least that's how I'd do it :) From there it would be much easier to convert to readable script.
By crashing the VM, either A: the decompiler shuts down before anything is seen, or B: the blank .fla is written without being filled with anything, because the VM never gave out any info about the classes.
So yes, a decompiler that ran without running the VM, just pure conversion, would bypass this method... BUT, then you're leaving your decompiler open to all sorts of other attacks at messing with it in the raw conversion process, while if you do it via the VM, if the swf runs, the decompiler runs. Not to mention it would be a lot more time and effort (and dev. money) to decrypt the swf, so few (if any) decompilers go that route.
Will there be decompilers will bypass this some day (or maybe now)? Yeah. Will someone else find a way to break those too... Yeah :) the back and forth of weapon and defense continues.
I believe that in theory, Tamarin based decompilers should be able to decompile without executing the actionscript. I could be wrong on that though.
http://www.5etdemi.com/blog/archives...s3-decompiler/
Your probably right, if it straight converts it without the VM being initialized, it won't work. It's not perfect, but it is a big step in the right direction.
But it will mess with whoever decompiles it. It will crash Flash just as easily as it crashes the decompiler if you run it locally if you don't remove the code first :)
I figure breaking so- think is a pretty good step for one day though, I'll get to Tamarin later.
This is like my favorite thread ever!
I just noticed Tamarin just goes to bytecode, not pure AS3, so I think we're safe for the moment, but I'm sure they'll get it to pure AS3 sometime, if they haven't already, but everything is breakable with a little effort :)
That one would be a bit tougher, prolly take more than one morning, but I'm sure the flash community can pull together, fight fire with fire!
Tamarin is how we go from AS3 to bytecode in the first place, so I'm in no hurry to sabotage it. Apparently Haxe also includes a partial decompiler in order to produce haxe-linkable external classes from compiled as3. I really don't think that it's necessary to try to prevent decompilers any more than we've already demonstrated in this thread, but the technical wizardry is still tons of fun.
haha, sorry, I didn't mean sabotage the engine, just the decompilation process, leading to a corrupt fla.
I agree with what people are saying, it's best to base a business model around your stuff being stolen not being a big deal. If that's not the case though, I think taking whatever measures are necessary to stop people from taking it is a great idea.
Personally, I think the main advantage of decompilation protection is not protection of the program itself, but individual classes. I've been building a library of classes for about a year that do everything from color manipulation, to taking screenshots, writing bitmaps, burning the edges of photos, 3D object manipulation, search engines, reflections, etc etc.
These classes are a gigantic advantage my company has over local competitors, because they mean I can accomplish very complex things in very little time, and our direct competitors can't. They also mean when I create one of them, my company eats the time necessary for me to do so, so if our competitors can just grab my classes and use them themselves, our advantage turns into a disadvantage. And while open source is great for a lot of things, if my company loses all advantages and could go out of business (very small company) from all our competitors grabbing our hard earned and paid for classes, then selling their projects for cheaper (they've done it before), I draw the line of open source there.
I feel there is probably others in similar situations, so protection from decompilation is a very good thing, and I'm giving this class away out of kindness (I'm a nice guy). While you can never protect your classes fully, I at least want to know that the person stealing them was good enough at what they do to get past some serious resistance, and probably could have written it themselves, and most likely took as much time to decompile mine as it would have taken for them to write it themselves.
I found a way to counter the Tamarin abc dump, it has a pretty crucial difference between the actual VM, the AVM2 reads files with their binary header altered in certain ways, while the decompiler for the abc dump cannot. I tested it in Flash 9 and Flash 10 and the header changes proved no problem, and the Tamarin abc dump couldn't even run on it. An executable could easily be written to do it, but I'm tired, and going home now, and since the abc dump isn't really decompiling, just rearranging the byte code to be more readable, I don't think anyone should lose sleep over it. But I still might write up the .exe tomorrow, cuz it's pretty neat stuff.
I suppose someone could still use HaXe to view the byte-code, remove the decompiler-protection, and then decompile it as usual.
Still, this is really cool, great work :thumbsup:
Exactly, there will always be someone that can hack whatever you put out there.
All I can say is that at that point, they were able to read the byte code to find what was killing the decompiler, able to manipulate the byte code well enough to understand how to remove the protection without destroying the program, then decompile.
I figure if they can pull that off without a hitch, they're pretty good, and seeing my classes prolly won't reveal any great secrets they don't already know about, and they are definitely not from any of the places I compete with regularly. :)