Does Flash Builder 4.6 create LZMA compressed SWFs and also are the RSL framework LZMA compressed?
No. Falcon may add support for this. There are supposed to be programs out there that can compress the file after the fact. Though I don't know what those are.
The entire SWF file is not compressed, though elements within the file - images, ActionScript bytecode, sounds etc - are individually compressed in blocks (I believe zlib is used). This is important for the flash player to be able to decompress parts of the swf as it loads, in order to get it playing quickly.
Usually you won't get a lot of extra compression by compressing the entire SWF file, since most of the data inside is already compressed.
Related
I'm a little bit confused about the qtquickcompiler, the JIT qml caching and what is available (and what is not) in the open source version of qt 5.8 (respectively 5.9).
Basically, I want to protect my .qml and .js files from being readable in my release build. I started a new example QtQuick project without editing any code. I followed these instructions and added the CONFIG += qtquickcompiler in the .pro file, but it has no effect.
My .qml files are built into the .exe (on Windows), but if look in the executable, e.g. with notepad++, I can still see the source code of the .qml files.
On the other hand, if I don't use the QRC for my .qml files, .qmlc files are created for every of my .qml at runtime. These files are not (easily?) readable. But I don't find a way to use only the .qmlc files without shipping the .qml files in my build (and I don't think it was meant to be like that).
Coming to my question: Is there a way to protect my .qml and .js files with the open source version of qt? And what is the difference between the qtquickcompiler and the new JIT .qmlc?
Updated answer:
Since Qt 5.11, the qt quick compiler is also available in the open source version:
CONFIG += qtquickcompiler
See https://wiki.qt.io/New_Features_in_Qt_5.11
No, it was going to be, but then they gave up on those plans for the time being and replaced it with the caching thing.
I don't think you will be able to reuse .qmlc files on another computer, as IIRC they are not architecture portable.
In the future, it should be possible to pre-compile .qml to .qmlc ahead of time and bundle those into the application binary.
If your files are on the file system, then there is no way to protect them, from being read, reverse engineered, or tampered with.
With the compiler, the QML code is translated to C++ code, which is then compiled to a native binary. Also, last time I checked, if you go for the compiler, it is an "either / or" situation, if you use compiled qml you can only use compiled qml, so no mixing with regular qml files. It is also ahead of time, and requires a commercial license.
The qml caching in contrast is just-in-time (possibly ahead of time in the future), doesn't require a commercial license and doesn't come with the limitation that prevents you from using regular qml files. I am not aware of the implementation details, but it certainly is not qml code translated to C++ and then compiled, as it happens on the client side and doesn't require having Qt or even a C++ compiler installed. It doesn't really sound like bytecode either, as IIRC it is not binary compatible between platforms, it is more like caching the qml file processing result to avoid on doing it every time.
As outlined in this answer, with some extra work it might be possible to implement a decent amount of protection, for example encrypted QML files or binary resources, but I still haven't dug into it.
Lastly, if you set compression for the qrc file with a low threshold, it will somewhat obfuscate the QML code in the executable binary, but even so, it is regular zip compression, so if your code is really worth stealing, it will not really prevent that, just make it a tad less trivial.
Is there a way to protect my .qml and .js files with the open source version of qt?
Not yet. Up to (and including) 5.8 you'll need to buy a license in order to use the QML compiler.
And what is the difference between the qtquickcompiler and the new JIT .qmlc?
That the compiler will turn QML into C++, which gets then compiled into your application. The .qmlc files are a cache generated by the engine to avoid parsing / optimizing / etc. the same files all over again. Yet, they're a cache -- you'll need to original source around in case they don't get used. At the Qt Contributors' Summit 2016 there have been some discussions about how to streamline and integrate the compiler with the cache, but so far nothing exists.
Coming to my question: Is there a way to protect my .qml and .js files
with the open source version of qt?
Yes, of course,
look at my answer:
https://stackoverflow.com/a/40861056
You can use an encripted resource file, an decrypt it in execution time...
I do that in all my projects ...
Is not a trivial job, but works fine.
In my project we have swf file that is 4 mb in size. When we open the application in browser it is taking 3-5 seconds to load the swf file at client side. Is there any way to compress the swf file and send so that it will take less time? Or is there any other options to minimise the load time?
Thanks
Sachin
By default swf files are already compressed when compiled. Try zipping an swf file for example it will hardly change in size.
If you find a compression method to do decrease the size of the swf and this compression method is supported by flash, you can compress the swf file for download and decompress it at runtime and then load it.
Read "Reducing SWF file sizes"
Use the bytecode optimizer
Disable debugging
Use strict mode
Avoid initializing unused classes
Externalize assets
Use character ranges for embedded fonts
Read "Reducing module size"
Change the application that a module is optimized for in Flash Builder
Create and use a linker report with the command-line compiler
Modularize your module
Compress your assets (higher jpg compression, lower color depth, etc)
As mentioned in release notes to Flash Player 11, developers added LZMA compression support.
Question is how can one enable this support? Maybe there's an mxmlc option? Or more steps?
Simply setting -swf-version=13 and switching playerglobal.swc in sdk didn't work for me.
SWFs compiled with the -swf-version=13 parameter automatically support LZMA compression, meaning that LZMA compressed SWF files can be loaded at runtime, however the SWFs output by Flash Builder (as of 4.5.1) are still compressed with the default zlib compression.
Tinic Uro, one of developers of Flash, wrote a utility to convert SWF files from the default zlib compression into lzma. This would need to be done as additional step after compiling, at least until Flash Builder starts supporting LZMA output.
Update (clarification):
The flex SDK does not yet output LZMA compressed SWF files no matter what options you use, which is why the utility is needed. The 'swf-version' compile parameter tells the SDK to output a Flash 11 SWF. This is does not mean that the SWF is compressed with LZMA compression, just that it is able to use it. The gist of this is Flash 11 is able to support LZMA compressed SWFs, but you need to do additional work to actually make a LZMA SWF.
I wrote a Python script that will do this conversion based on Tinic's code. It's a little easier to use if you're not on Windows.
it is possible to protect a .swf file from decompilation?
i've been reading about compiling class libraries in a .swc file for distribution without revealing the code - possibly selling it. however, there are .swf decompilers you can use to expose the code, and a .swc file is simply a .zip archive, so changing myswc.swc to myswc.zip will reveal the .swf files of the library.
just curious, mostly.
You can't. Don't believe those swf protector/encryptors. Both the content of a swf and a swc need to be readable by the AVM2 so it can't be compressed or encrypted or anything. Bottom line is that you can't really protect your as3 code from being reverse engineered.
I am flash game developer i use Flash Secure Optimizer from http://www.eramsoft.com
I wanted an animation to dispatch custom events as it cycled. It became apparent that not even trace() was running. After some searching, I found the following at Adobe:
http://livedocs.adobe.com/flex/3/html/help.html?content=embed_4.html
"If the SWF file contains any ActionScript code, Flex prints a warning during compilation and then strips out the ActionScript from the embed symbol. This means that you can only embed the symbol itself."
I also found a work-around by Grant Skinner at:
http://gskinner.com/blog/archives/2007/03/using_flash_sym.html
So, I can proceed, but I'm still wondering. Why does mxmlc strip ActionScript from Flash compiled resources when embedding their symbols into Flex apps using metatags?
Sorry for the very late response, but since I wrote that code, I can answer. :-)
Basically, there are two answers.
For old SWF assets that contain AS2 bytecode, it was far too much work to try to convert the bytecode to AS3. I'm assuming this isn't theuse case you care about anyway.
For SWF assets linked to AS3 bytecode, the basic problem is that there is no dependency information any more, so when we clone the asset, we have no idea what else we would need to pull. Because Flash can export a SWC, I decided that this was a far more robust workflow for getting assets with code from Flash to Flex. (Take a peek inside a SWC file, and you'll see an XML file that describes the dependencies used by the linker.)
It's probably a performance issue. To load a swf resource without stripping it, load it dynamically using SWFLoader or Loader instead of embedding it.