Open SwazLord opened 4 months ago
I'm curious what you do differently to generate the SWF files .. why is there a different SWF for Android vs for iOS?
The reason for asking is that I'd expect the Android one is using the later ABC2 format, whereas the iOS one presumably is using the earlier one. And I can't really think what you could do differently to make the compiler generate different ABC versions for the same source code..
Sadly, decompiler tools would need to be updated in order to support the "float" data type that was introduced in AIR 51.. this increased the ABC format version and added a new section to the constant pool which would then break any parsers that didn't take this into account...
If you view the SWFs using SWF Investigator, you should be able to see the abc version codes (and I think their tool already was prepared for the 'float' update..)
thanks
I'm curious what you do differently to generate the SWF files .. why is there a different SWF for Android vs for iOS?
I am sorry that was a mistake, I forgot to update the iOS project's SDK version as for this project we use separate modules for both the platforms. Hence the confusion, my bad.
If you view the SWFs using SWF Investigator where can I get this ?
I think SWFInvestigator is now only available on SourceForge: https://sourceforge.net/projects/swfinvestigator.adobe/
It used to be on Adobe Labs..
You probably want the latest (trunk = r19) version. But I'm not sure now whether this does have float support.. was just assuming so since I've never seen it fail..!
Sadly, decompiler tools would need to be updated in order to support the "float" data type that was introduced in AIR 51.. this increased the ABC format version and added a new section to the constant pool which would then break any parsers that didn't take this into account...
so this means that with AIRSDK version 51 we wont be able to use those Obfuscators & Decompiles, unless they get updated
Possibly I guess.. I thought it would only bump up the ABC version code if these were actually some float
usage in the code? We could check that, and potentially even provide a way to disable that from user-based code, if that would be helpful?
Possibly I guess.
I just tried secureSWF and this is what we get when we try to add the swf file :
We could check that, and potentially even provide a way to disable that from user-based code, if that would be helpful?
@ajwfrost I would like to have the ability to control this change, is it possible turn it off ?
My favorite option here would be Harman acquiring the license/source code for SecureSWF and make it their own tool and/or strip out the main parts of their encryption methods to add them directly to adt.. But I think the makers of SecureSWF (Kindi) were out of business and former tries to contact them from Harman failed. Referring to this post here: https://github.com/airsdk/Adobe-Runtime-Support/issues/494
@2jfw that would be nice :-)
@Shaunmax we'll push this out in the AIR 51.1 build but in case you want it early, zipped up below is the "compiler.jar" that can be put into the AIR SDK "lib" folder. This adds a compiler option -compiler.float
that can be set to true or false (default is true).
If you set it to false, the output SWF will be forced to the older version information without the float
entries in the constant pool, which is what would be screwing up those other tools. But if you have any code that actually uses float (specifically, the pushfloat
ABC code) then it will throw a compiler error...
compiler.zip
Hope that's useful!
-compiler.float
thanks a lot, I was able to compile it with no issues
I just updated my project's
AIR SDK
from50.2.4.4
to51.0.1.4
and generated swf for both Android & iOS Builds. When I checked both the swfs in JPEXS FF Decompiler , the android swf is showing a strange issue with no script folder and with anError - DoABC2
compared to that the iOS swf looks clean : -
is this expected in
AIR SDK 51.0.1.4
? I can confirm that theapk
is working fine with no issues.