Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
04-19-2011 02:53 PM
I'm thinking it's probably a good idea to obfuscate my swf before delivering it to App World. Is anyone doing this yet? There seems to be a lot about this on the Java Dev forum but nothing here.
I've never used obfuscation and don't know what the process would be to deliver a completely signed, sealed and delivered .bar to App World. Could you walk me through it?
Thank you in advance,
Solved! Go to Solution.
04-19-2011 03:00 PM
We've been told that there is no way a user can get to the SWF because of a secured sand box.
Now we do obfuscate SWF files for one of my clients and it can be a time consumer, pain in the b*t process to properly secure a SWF and allow it to work properly. It is a back and forth effort to change settings and then do testing to make certain it still works.
For me, I will not do it for the PB.
04-19-2011 04:46 PM
04-19-2011 04:53 PM
You cannot read the other application sandbox but bar file is not encrypted. So if somebody intercepting the network when file is uploading or get a hold of you bar file it is possible to read it.
Also it is not encryted in the playbook filesystem itself - so if you take playbook apart and extract the storage unit it is possible to read it from raw data blockes on the storage device (it has to be adavanced hacking though).
04-19-2011 05:45 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:
04-19-2011 05:56 PM
Okay, so assuming I want to do that, what are the steps I need to take, start to finish? I'm using Flash Builder 4 so...Export a signed .bar? Open it, obfuscate the swf, and...repackage/re-sign it using the command line?
What would the process be?
I'm looking at a code-level obfuscator like http://www.kindisoft.com/. A bit pricey, though.
04-19-2011 05:59 PM - edited 04-19-2011 06:03 PM
No I doubt that would work, once it's signed I don't think you can just open it... maybe, but I doubt it.
Your flow would basically be:
- Generate SWF from FlashBuilder (this is done automatically when you Build)
- Replace generated swf in bin-debug, with the obfuscated swf, making sure the name is exactly the same
That would work fine when packaging via command line. But I have no idea if it would work when you package a signed release build using the GUI in FlashBuilder.
The question is, when exporting a release build, does it regenerate the SWF, or does it use the one that's already there. I think it regenerates it... in which case I dunno, you might have to sign/[ackage via command line, which should allow you to specify any SWF you want.
If I were to do this, I would probably set up an ANT script that automated the whole process... assuming your chosen obfuscator has an executable you can run with command line...
04-19-2011 07:01 PM
i believe secureSWF is by far the most popular solution.
here's an interesting thread about it on SO
i use the command line to package and sign my apps (since i use Flash CS5) so i'm not familiar with how signing is executed with Flash Builder.
1. publish your swf
2. obfuscate the swf
3. package and sign the obfuscated swf using command line tools
04-19-2011 07:17 PM - edited 04-19-2011 07:23 PM
@shawnblais, where do you get this information? (Edit: The part about "You can literally FTP right into your playbook, user: root, pass:root".)
The original simulator was basically that open.
The real thing, and in fact recent simulators, are far more secure. Ignoring the fact that with the simulator, you can of course directly access the filesystem image, but I challenge you to get in any other way and extract a SWF file from any BAR that you load onto it, unless you're using the -devMode option during packaging.
Please correct what I believe is a gross misrepresentation of the facts, or provide a reference for the information if you believe it to be true.
04-19-2011 07:22 PM
So if somebody intercepting the network when file is uploading or get a hold of you bar file it is possible to read it.
Elena, can you confirm that the connection between the PlayBook and App World, for a download, is not using a secure socket (TLS/SSL/HTTPS)?
That would strike me as being a bit counterproductive to a lot of the security measures, but more importantly it does mean that even with the PlayBook, any licensing model except dynamic/pooled licensing is going to be prone to massive piracy, and may have other security implications as well. Furthermore, since there is as yet inadequate documentation for us to implement proper dynamic licensing support in our PlayBook apps, I'm at a loss to understand how anyone could yet protect their PlayBook apps in any effective manner.