04-21-2011 11:40 PM
I tried "litterally" FTP'ing into my PlayBook it does not work. I get the connection refused error.
There's no way that information is current. Only the first one or two versions of the simulator allowed it.
These days, the only "backdoor" access of any kind is to run the blackberry-connect utility, which opens up an SSH channel that you then connect to using regular SSH clients. On such a connection you can run sftp (secure FTP) which is really not FTP at all, in the sense of the protocol called FTP, though it gives much the same functionality. You can also do scp to copy files, execute commands remotely, or log into a shell. The userid is "devuser", and you have fairly limited permissions when you log in that way.
04-21-2011 11:44 PM - edited 04-21-2011 11:48 PM
Yep. Sorry, I've been using a dev unit, and despite the latest firmware updates I guess security is not the same as the retail units. I haven't touched the simulator since .92.
Anyways, that's really good news for developers, but kind crappy as a consumer, being able to browse the entire system with FTP is fun
04-22-2011 03:42 PM
Have you tried running your obfuscated swf through a decompiler? I'm curious how secureSWF would stack up to simply renaming identifiers (which seems to be what irrFuscator does, except useless encryption). How high did you turn the control flow obfuscation up? Any performance decrease in the final application?
04-22-2011 03:55 PM - edited 04-22-2011 03:58 PM
Yes, see message 16 of this thread
Control Flow Obfuscation was at 100%; Dynamic Code Wrapping was at 100%
No appreciable difference in the speed of the app but as I've mentioned, the code (at least for this particular app) is pretty simplistic.
04-23-2011 12:11 AM - edited 04-23-2011 12:26 AM
@blueinc: Thanks for the info.
I had the chance to try the demo of secureSWF and compare it to the sothink decompiler. I did so in a virtual machine and would encourage anyone else wanting to perform similar tests to do so as well. After running an obfuscated SWF through the sothink decompiler demo, it either crashed or produced uncompilable output. That said, I did find a piece of software that purports to be able to remove all the protections added by secureSWF, called swf reader. It would also be possible to manually go through the code and remove all the protections added - the extra instructions added are clearly nonsensical to anyone with a passing knowledge of AS3, and secureSWF does not add any plausible looking instructions alongside your actual code, even at maximum settings. Thus, it is relatively easy to pick out the real code from an obfuscated block. In theory, with a language such as AS3 there is no way to prevent effective decompilation, so this is not surprising. I would argue that it is also not a good ROI to spend time troubleshooting the problems that may appear when using control flow obfuscation and dynamic code wrapping and also not good practice to harm your legitimate users by the performance reduction that these obfuscations may cause on more complex applications.
It is a shame that a program is so readily available for reversing these protections. I do find it rather amusing, though, that the author of swf reader charges for his program, neglecting the fact that those who want to use his program to steal someone elses code will likely seek to do the same to him. No honor among theives and all that.
Not to mention the fact that no matter how locked down your SWF, all your UI assets can be replaced easily and your application redistributed without even touching the code. Code obfuscation does nothing to make this harder. That said, secureSWF still holds some value (but not $199+ worth, if you ask me), as it does rename identifiers and make the task of understanding and modifying the actual functionality of your application more difficult. I would encourage anyone seeking such functionality to investigate alternatives - I found an open source python script that obfuscates as3 source by removing comments, identifiers and hex encoding strings on github (https://github.com/shapedbyregret/actionscript-3-o
Even Apple has had an incident where a counterfit app was accepted onto the Mac App Store (http://thenextweb.com/apple/2011/02/03/counterfeit
I know I will be moving to the native sdk as soon as it is available. Not only because the above will become a non issue, but also because the lack of multithreading in flex is a serious detriment to the user experience.
04-23-2011 10:06 AM - edited 04-23-2011 10:10 AM
this is excellent, rhgills! i've spent some time looking around for a descent and free AS3 obfuscator in the past and just couldn't find anything worth using. this Python script looks very useful.
i was ridiculed on some forums for requesting information about an open source AS3 code obfuscator. sure, it's certainly hypocritical, but perhaps C++ devs would feel differently if all of their code was naturally exposed like it is with the Flash platform.