04-20-2011 01:02 AM
I got trial versions of Irrlicht Obfuscator and ameyeta (or whatever it's called), installed Irrlicht, and quickly determined that, while reasonable protection of my app may be possible, it was going to require tons of effort, tweaking and regression testing. For example, obfuscation and late-binding do not play well together.
Given that the PlayBook is supposed to be generally secure... etc., etc.
04-20-2011 07:54 AM
04-20-2011 10:51 AM
The reasons are perhaps two-fold for me: I tend to err on the side of caution and BB has said that they're moving the smartphone over to qnx as well. http://www.intomobile.com/2010/09/28/blackberry-os
So, doesn't that mean our smartphone apps will eventually need some sort of protection? It's probably better to bite the bullet now and work the process out.
04-21-2011 03:25 PM
our solution is the one that seems to have worked for me though I have left jtegen's kudo in place because he's right too: it *can* be onerous.
I decided to go ahead and try protecting my SWF using secureSWF. I purchased the Pro edition, registered it and then, poking, prodding and generally fumbling my way through, used the following steps:
1. Exported from FB4:
If you've previously signed the app, open app.xml and increment either the version numbers or the buildID or both. or auto-increment the buildID like they do here)
Right-click project, choose Export > Export BlackBerry Tablet OS Release Build
2. Protect the swf with secureSWF: it comes with a bunch of presets so I used the default 'Standard - best balance between protection, performance and file size.
On the 'Identifiers Renaming' tab, I didn't obfuscate anything other than my own package i.e. I deselected qnx.* classes and selected com.blueinc.*
Unchecked Break Function calls
Unchecked Randomize Results. This gave consistent obfuscation needed for testing.
Literal String Encryption:
Went through the alphabetized list of found Strings (680 in my case) and checked the ones to be encrypted i.e. anything with 'license' or 'activation' in it. It doesn't take long but could use a Search function :-). This will encrypt the Strings in the SWF file using 'a very secure symmetric encryption algorithm, and decrypt them only when needed at runtime. Please note that this entails an added overhead each time the string is accessed.'
Encrypted Domain Locking:
Clicked 'Protect SWF Files' button upper right corner. Progress bar dialog runs for 10 - 15 seconds. Clicked OK when done.
3.Created and tested: created the BAR using command line. Launched the simulator 1.0.1 and tested the BAR. Tried some changes in 2. Repeat 3. Tried some changes in 2. Repeat 3.Tried some changes in 2. Repeat 3.
4. Once testing was done, THEN signed the bar using command line. Tested the signed BAR on the simulator. Good-to-go it seems.
5. Posted new Release in BBAW.
Waiting for approval. We'll see how it goes.
Thank you all for your helpful advice and comments.
Out of the box, I think it worked reasonably well for me, considering I'm a relative newbie to AS3 so my code is quite ... simplistic. jtegen and willfarnaby are right though: for anything more complex, you'd have to go slowly and test everything often.
04-21-2011 05:33 PM
if you're curious about the results of the obfuscation you can try opening your obfuscated .swf file in a Flash decompiler. you can download the free, limited version of Trillix, which allows anyone to view a .swf's ActionScript code and assets. if you've never used a Flash decompiler before, open your non-obfuscated .swf first to get a feeling for what would normally be exposed.
04-21-2011 07:19 PM
Thanks for the link; I WAS curious.
I downloaded the trial version of Trillix. It would only decompile the scripts in the full version but said it could show me the different components so I installed and ran it. When I pointed it at the file, it threw up an error that the SWF was not in the proper format. It would try to fix it but correct decompilation was not guaranteed.
It then showed the file in the sidebar with a lot of images and sprites (all my qnx button images mostly) and 1 item under Frame. When I clicked that 1 item, Trillix froze and I had to kill the process to get rid of it.
I restarted Trillix and pointed it to the file again, highlighted it and chose Convert Current. It said it had detected that the file was built with Flex Builder and it would create a project. It got about halfway on its 'Converting...' progress bar and then hung for a long time. Like, a long time. I'm not sure exactly how long because I had a nap waiting for it.
Then it spat out something like: "Conversion failed. Please, send us the file.'
Ya. I don't think so.
So...my guess is that it's all good... at least with that decompiler.
04-21-2011 10:05 PM
Ha, there's no security at all...
You can literally FTP right into your playbook, user: root, pass:root, and browse every single SWF on there, decompiling them to your hearts content.
Yes, this is a big topic, unfortunately it is WAY to easy for people to rip your source code.
It would be awesome if RIM could provide this, but for now your best option is something like this, which will run you $150-$200:
I tried "litterally" FTP'ing into my PlayBook it does not work. I get the connection refused error.
04-21-2011 10:57 PM