Adobe AIR Development

[sergeh]

@peter, I have no doubt in my mind that they know about it but we need to pressure them into doing something about it.

I had a lot of updates I wanted to add into my app and I would like to release a paid version as well but if anyone can simply extract our apps then there's no way in hell I'm going to release anything else on the PlayBook.

Can someone test and see if they can actually sideload an extracted app? I'm guessing since they're already signed, the app will easily be loaded.

I can image someone creating a repository app that will load our apps into the playbook without any effort.

[kdittyr]

This is a little concerning, though, not truly a surprise.  I am disappointed that this seems to be so easy to pull off.  I hope that RIM pushes out a fix for this soon.

I wonder if putting specific air features in your application would break this hack from working in browser.  I believe SQLite only works with AIR.  That should mean that SQLite commands should, in theory, break the application.  It might help to lock down your application by catching errors and using those as a way of ejecting from a normal run cycle.  I am only speculating on this until it can be tested, but I think it should work.

I guess you could go simpler and test whether the app is running in the Air environment, or with the Flash Player in a browser.  You should be able to use this as your ejection check.  Again, just mulling possibilities.

I am in the testing phase with my paid app...  I wonder if I would better off just keeping that application to myself, or releasing in other markets until this is fixed by RIM.

[TheMarco]

obfuscation does nothing for javascript. Also: now the only thing left to try would be to rezip the .bbb files with packages in it you didn't buy but got from someone else. If that works the piracy floodgates have been opened in less than 2 weeks...

[KenSalmon]

It would appear from this that RIM puts its security efforts into the wrong places.

All the stuff that we have gone through in the past couple of weeks with the debug tokens, all the **bleep** that we put up with just to deploy our own apps to our own hardware for the sake of security...procedures that are just plain annoying and getting in the way of productivity. And then we find out this bit of news.

Amazing (I have other words instead of that one, but I suppose this is a family-friendly forum).

[kdittyr]

I'd like to hear a reply from RIM before I get too upset over this.

[agaripian]

Wow this is huge security issue RIM! No encryption or security at all!

[MauriceRice]

I feel violated! This is a ridiculous oversight.

DM backups should be disabled until they can be properly secured by encription. Or apps should not be backed up at all. They can be reinstallrd from AppWorld if necessary.

Is anybody at RIM listening?

[shism2]

This is a pretty big security flaw.........

It seems that they can be extracted from Desktop Manager backup files. Why aren't these backup files encrypted?

[KenSalmon]

kdittyr, I am all for giving the benefit of the doubt. After all bugs happen, security holes happen, these are things we always have to deal with in the industry.

Problem is, when it comes to RIM, it becomes increasingly hard as time goes by to see where they have earned the benefit of the doubt in any given situation.

[Acenet]

Well, knowing how swf are loaded, this is a normal behaviour I would say: extracting swf is part of the game, like extracting a simple jar file. Also reverse engineering is always possible in all technologies.

All the signing process is there only to protect the PlayBook: only signed stuff can be executed on the PB. But extracted content, as swf, can be run in any FlashPlayer.

-it's up to the dev. to put in place some check that forbid execution if not run on a PlayBook. => this should be provided as a QNX API.

-what also can be "fixed" (asap...) is the "exposing" of swf files in the .bbb files for sure.

-app. can also use "dynamic" license.

-and for reverse engineering... well, it's against the law.