Can anyone tell me whether code on the timeline is harder or easier to steal/decompile?
Or is it all just the same?
There's no real difference. A dedicated programmer can always get to and reverse engineer your ActionScript. Bear in mind it's not just 3rd party apps like Sothink that can be used. Even Adobe have a tool for 'inspecting' a swf: http://labs.adobe.com/technologies/swfinvestigator/.
If your code is genuinely special enough to warrant stealing, then you would want to use a platform other than Flash (or put your sensitive code into an external C/C++ assembly and run that using something like Alchemy).
Are you really doing something so unique that people are going to try to steal it, though? Is it so special they couldn't just figure out what you've done and copy it?
The difference is essentially nil. In AS3, timeline code will end up inside classes anyway. The code for the main timeline will appear in *filename*_fla.MainTimeline. The code for Symbol1 will appear in *filename*_fla.Symbol1, and so on.
Timeline code can be slightly easily to understand, since variables not explicitly declared as local variables will become class variables. The names of class variables are preserved in a SWF, whereas local variables are not.
Check out my online ActionScript dissembler if you're curious about how your code is stored inside a SWF.
Related
Is there a way to de-obfuscate AS3? With de-obfuscation I mean making it compilable again. At this moment I lost some source code and only have the Flash file left. The problem I now face is that the compiler is not able to compile it as the class names contain illegal characters.
I could start manually naming all classes again however I'm not even certain if the de-compiler worked.
To compile the SWF again I use flash develop and the FlashSDK.
Regards.
This depends on how the code was obfuscated to begin with. If it was simply obfuscated by changing class/variable/function names, then you could use an IDE such as FlashDevelop which allows you to Refactor->Rename by right clicking the instance name which would rename it across the entire project. Or just do a simple find/replace using a text editor.
Knowing how the code was obfuscated is the most important thing though. Whichever program you used to obfuscate is probably going to provide you with the most information.
I would suggest, however, doing the bare minimum by removing all illegal characters first to see if it will compile.
I am trying to build the foundations for a platformer game in Actionscript 3. I'm still fairly novice at AS3, but I'm hoping this will help build my knowledge.
Anyway,
I understand that I can create Actionscript files that are associated with something such as a Sprite or a MovieClip by extending the Sprite/Movieclip class. I also know about Actionscript files that work as the 'Document class'.
Each level in my game will have different properties that vary such as gravity. Where should I store these variables? Obviously not in the player... Not sure if they're supposed to go in the timeline or the document class, or if they have a separate AS file of their own. I've been told that having global variables is generally bad, so I'm not sure what to do.
You can make levels as separate files that are even not Actionscript, but XML or JSON, since your levels are basically data structures with different starting values. And you can make a Level class that can take such a file, parse it and initialize an in-game level structure based on what's read. Yes, such data should not go to timeline, because should you need to change one piece of that data, it could implicitly affect other game processes. Also, one simple right click can ruin such a game :) I myself use JSON files as my level data holders, and I parse them at the initialization time, you can do like this or say when your level is being loaded.
In short, if something is different by initial data, but common in methods, it should reside separately from main code, or entire code, and be included as data.
I think this similar question and answers will help you somewhat:
As3 OOP game structure (class architecture)
Basically, "What you want to do is to separate what changes in your game from the game itself". So definitely do not include the code in the timeline.
I have a basic problem with knowing which classes to import for a given application, renderer, AS package, mxml component, etc. There seems to be hundreds of classes (both mx and flash) and I'm never sure which one(s) to import... so I just keep adding import statements until the errors go away. Is there a reference somewhere that I don't know about? Or does this just come with experience? Also... does importing a load of classes actually make the file size larger or does Flex only import the classes used nregardless of what I specify? If it only uses what is needed, why wouldn't everyone just do: import mx.*;
I would suggest that if you find yourself bringing in tons of imports, you should ask yourself: Does this class do to much?
It is less of a technical issue, and more of problem of object-oriented design -- maintainability, testability and stability.
I do my best to limit my external dependencies. I try to conform to SOLID principles that tell me that classes should exist for one reason. If a class does too much, it is a "code smell" and an indication that you should split it up.
How much is too much? It is tough to have a specific litmus test or limit... I just ask myself "What does this class do"? If my answer contains an "and" in it, then I consider splitting it up.
I think your problem is a not a real problem if you use any half decent IDE. If you're not using one, you probably should (even if it's not stricly necessary and you can write and compile with notepad and the command line).
If you are using Flex/Flash Builder, it will add the imports automatically (and remove the unneeded ones as well). Also, you can use Ctrl + SPACE to prompt autocomplete, which should add the necessary imports.
Flash Develop also manages this for you (the shortcut was Ctrl + Shift + 1 if I recall correctly, but I haven't used FD for a while).
There are other IDEs out there that I haven't personally used but also have this very basic feature.
If you're using the Flash IDE, well, it really sucks for writting code, so you should probably consider writting your code in some other less brain-dead editor if you plan to do anything more than a couple of lines of code here and there (again, you can write code in the Flash IDE but why not taking advantage of better tools when they're available?).
When you get an error, look at the API Reference for the class, and then either import the whole package or just the class you want. Highlighting the class and hitting F1 should also work (but I never search help this way).
As for file size, see my answer on Is it possible to dynamically create an instance of user-defined Class in Action Script 3?
As Juan pointed out, use FlashDevelop, it is a great (and free) IDE.
If you're using FlashDevelop with the Flex Compiler, you can compile straight from FlashDevelop, and use the refactoring tools they offer to slim down your imports.
Aside from that though, if you're not referencing them, they don't get compiled, so it's not like your compiled swf is any bigger.
Hi
Recently in actionscript it has been made possible to create Classes at runtime. Thi seems quite cool, but I am perplexed thinking of a situation in which this might be useful. Anyone have any ideas?
First of all, the uses for this in ActionScript is limited. So start of understanding what it actually is, and how other languages use it.
See Self-modifying code on wiki:
http://en.m.wikipedia.org/wiki/Self-modifying_code
Also see Reflection:
http://en.m.wikipedia.org/wiki/Reflection_(computer_science)
As an example of how it might be useful, I'm currently working with genetic algorithms to modify code at runtime. This way I can test every permutation (varying initial values and methods) without having to create classes for them, with the added bonus of exporting a .swf only containing the winning permutation.
hope you can help me with this question.
So, I've been working for a while with Flex, and had the crazy idea to create pure AS project.
If I compile a Flex app with the -keep flag, the generated actionscript gets generated.
Do you guys know of a way to make it compile, without going trough the code and gluing it all together?
Thanks.
Generated ActionScript is really only provided for reference; it's not really intended to be repurposed in that sense. Indeed, if you even have any, you've most likely compiled your project already anyway (unless you got it from somewhere else), so one might ask why you'd want to compile the generated stuff rather than your own source -- but nonetheless, although I haven't actually tried it, you should be able to point the Flex compiler mxmlc at your generated source to compile it, provided you're able to get all your dependencies to line up (which may be what you mean by "gluing it all together").
Just a thought, although again, I haven't actually tried it, so your results may vary. What is it you're trying to do, though? Just curious. :)
Like Christian mentioned, the generated AS code is pretty much there to serve as a reference. Just for fun, I tried compiling it from the command line using mxmlc, but part of the problem with doing that is that the class files generated don't match the classes they represent. So, you'd need to start renaming a bunch of your class files so that compiling those could even work. Many of the other classes in Flex won't be compiled in either, for the same reason.
As an example, the project I tested this with, had only one mxml file of source code in it. The generated output was 45 files. I'm sure that if you really wanted to do this, and were willing to invest the time in cleaning things up you could. But I'm curious too - why would you want to do this?
Actually it was just mere curiosity. I wanted to understand how the framework works and see how it merges it all together to make the final application, as I thought that the generated actionscript files were just a step in between the final SWF file, so I tought there should be a way for it to grab those files and generate the final application.
Eventually I would have tried to create a pure actionscript project just for the heck of it to see how complicated it was and what errors could happen when developing other stuff.
I know it sounds crazy, but I had some spare time, ha ha ha.