After having studied and used the latest mobile application development framework, PhoneGap and found it architecturally lacking I decided to put on my ‘reverse engineering hat’ and see what I could find in terms of the security and quality of an application build using this framework.
The goal of this activity was simply to assess whether I could find any concerns on how PhoneGap was deployed in a working application by trying to pull apart a deployed application.
I was rather surprised at the findings which are discussed next in this blog.
Firstly I began the process by determining how I could pull down the installed applications from my iPad. This was surprisingly easy, as they are stored within an application cache directory alongside iTunes. (on your PC in files with extension .ipa) From here it is possible to access each application’s code library that has been deployed to the iPad.
I discovered that the application archive was nothing more than a renamed zip file. No surprise to those of us that have been in the industry long enough.
Now with native iOS applications I hit a brick wall immediately. Native apps are not easy to reverse engineer any further than unzipping the application archive. Going beyond this point requires a real hacker not an architect on a mission of discovery. To do any real analysis beyond this point would require a jail broken device and a lot more time and effort, so I proceeded to ignore the distraction of investigating native apps and started to hunt around for applications that I suspected were built with PhoneGap, the real reason I started the investigation.
Having worked with PhoneGap I already knew the tell tail signs of a PhoneGap creation. They include issues such as:
- Very poor responsiveness with map functionality (due to the reliance on the Google web maps API and no caching)
- Large scrolling lists give away the use of HTTP requests being used to fetch images (unexpected slow load of images)
- General slowness of the application on lower speed devices
Using these tell tail indicators I guess that several of the Australian apps were built with PhoneGap.
One financial app and one fuel retailer app were in the forefront of my target list. I won’t name them at this.
I proceeded to unzip their apps and see what I could find and was rewarded with more information than I had hoped to find.
It was immediately obvious that the applications were built with PhoneGap. The archive was not encrypted and PhoneGap specific file artifacts could be seen and opened. The design of the app was clearly web based and much of the core application was exposed to anyone to download and steal. All the apps JavaScript, HTML, CSS and images were there for the taking.
Most intriguingly I began to notice silly mistakes in the application packaging. Copies of both debug (uncompressed) and production JavaScript libraries were included on the phone and images were stored in there full unoptimised quality. A massive waste on the phones resources. For those of us that really appreciate the limitations of a mobile environment this is an unforgivable mistake. Today these devices have a lot more capacity and speed than when the first java phones came out but they are still limited and this needs to be respected by application developers and framework designers.
It was clearly evident to me that the choice to use a framework such as PhoneGap has many architectural consequences including important indirect consequences.
Take a look at the video below, this shows what is inside the IPA application and shows the issues above.
The reason people choice PhoneGap is so that they can use cheap development resources (web developers) to build mobile applications. At this stage Web Developers are cheaper than iOS (iPhone) and Android developers. In many cases quite a lot cheaper plus frankly the big consultancies (that are responsible for many of these poor applications in the market place) cannot find iOS and Android people anyway. The problem is that mobile application design is “hard”, it was not meant to be easy and those expert developers actually usually are worth the extra money because they have invested in learning how to build quality apps on these devices.
By using developers that lack an understanding of why mobile developed is more challenging ultimately results in a poor quality mobile solution which for a company can be disastrous particularly given the social (feedback oriented) nature of the mobile app marketplace.
Web developers tend to forget (or just don’t know) how critically limited these devices are and how to work with those limits. Mobile devices are limited in not only memory capacity, processor speed (which also has a flow on effect to battery life) but also there are concerns on the speed of internet access, availability of internet and the extensive list of “different” configurations that are possible even with just android and iOS devices. This is far more involved with mobile development than with web development. From a technical viewpoint web developers mainly worry about browser compatibility. Although frameworks like PhoneGap could in theory be used to build “ok” applications, as a developer you still need to learn the nuts and bolts of the technology before touching a framework like this. This is a very new problem because with ordinary web development frameworks we could always throw more horsepower at the problem to solve issues. i.e. As it was with the birth of frameworks like Ruby and the popularity of PHP as a “real” language horse power solved everything. It is not so with mobile devices because your consumers will buy whatever they want.
In wrap up to this blog what I have discovered is as follows:
PhoneGap in the real world demonstrated:
- Security concerns (I should not have been able to pull apart their applications particularly with a financial app)
- Excessive use of phone resource concerns (duplicated libraries, uncompressed libraries, larger than necessary images)
- Performance and usability concerns (as a result of the technology being non-native in particular but also because the developers are trying to get the app done quick and dirty rather than designing it for good usability)
- A resulting attitude problem to mobile development. i.e. I’m seeing a high level of trivial mistakes, like assuming the GPS is always on and not catering for the event that its off or not available in the app. These aren’t so much a PhoneGap issue but the consequence of using less experienced developers for this technology.
The experience has strengthened my view that good architecture and strong process including strong testing practices is even more critical with mobile development than with ordinary web development.
Closing note: I’d like to thank Peter from mobiliser for his assistance on producing this article.