Hi, I'm Jeremy Foo.
I write software to make lazy people lazier.

Background

Recently an app was posted to the App Store that had exactly similar functionality to my first foray into proper iOS development, Traversity.

Initially, I welcomed the new entrant. That lasted until I actually saw the app for myself. Right off the bat within the App Store, I could clearly seem some form of plagiarism (or flattery, but that would require some credit where its due). The icon looked a little familiar in its general idea, but I suppose one can’t really knock that. Reading the App Store Description was what got to me. It was similar to what I’ve written, down to the form of the paragraphs with just slight modifications for poor grammar. At least the UI was different but I’ll get to that in a bit.

To add to that, these people also posted flyers at all the bus stops around the campus. While there’s nothing wrong with that, there are strict campus rules with regards to what sort of notices you can post. Prior approval to post such notices are also required or they will be taken down.

Astute readers will be able to figure out for themselves how effective their ad is.

Technical

Naturally, I was curious how they pulled it off considering I did place my code on Github along with a liberal open source license. I wanted to know if people were even using my code to do something.

Getting a rough idea as to how an app was written is not a difficult process. In fact, OS X provides a built in command line app to give you some basic information about your binary. This wonderful tool is otool. Provided the code is not obfuscated to begin with.

wellhello:~ jeremy$ otool
Usage: otool [-fahlLDtdorSTMRIHvVcXm] <object file> ...
    -f print the fat headers
    -a print the archive header
    -h print the mach header
    -l print the load commands
    -L print shared libraries used
    -D print shared library id name
    -t print the text section (disassemble with -v)
    -p <routine name>  start dissassemble from routine name
    -s <segname> <sectname> print contents of section
    -d print the data section
    -o print the Objective-C segment
    -r print the relocation entries
    -S print the table of contents of a library
    -T print the table of contents of a dynamic shared library
    -M print the module table of a dynamic shared library
    -R print the reference table of a dynamic shared library
    -I print the indirect symbol table
    -H print the two-level hints table
    -v print verbosely (symbolically) when possible
    -V print disassembled operands symbolically
    -c print argument strings of a core file
    -X print no leading addresses or headers
    -m don't use archive(member) syntax
    -B force Thumb disassembly (ARM objects only)

Before you do that, you have to unpack the iPhone application file itself (*.ipa), but running it through unzip (Yes, the .ipa file is actually a zip file that has been renamed). Once that’s done, the app should be in a Payload directory in its own directory with a .app extension. Get in there.

First obvious place to look is the libraries that are linked to the binary. This only involves dynamic libraries, but it does give a good idea as to the OS specific features that are used.

otool -L

Calling otool -l will get you the load commands that are used by the binary to load the specific sections of code into address space once its loaded. It also will get you the libraries that are loaded along with other tidbits of low level OS related information.

The next thing you can pull out of a binary are all the Objective-C related information. In this case we’re interested in Objective-C classes. Remember to add the -B flag in order to force Thumb disassembly. Most iOS apps are not compiled with Thumb mode.

otool -Bo | grep OBJC

Good enough to tell you about what’s used and what’s not.

Finally, if you are really keen, a full disassembly is what will get you a good idea of how the app actually works. For this if you have access to IDA Pro, you are golden, if not otool also does provide for some form of disassembly that lets you take a look at what commands are called.

otool -BVvt

If you are just concerned with the methods that get are available in the binary you can just do simple pattern matching using grep.

otool -BVvt | grep ^.*:$

You can grab the otool output here.

Analysis

From the disassembly, the binary doesn’t seem to use any of my open source code, which means the plagiarism stopped at the App store. However, the usage of RegexKitLite (not credited) did seem interesting to me because from the contents of the app, the data used is held in static plist files while the only dynamic content that is available (in the form of bus arrival timings) would not require regular expression matching. There is a web service you can query via POST for such information.

I was curious enough to run the app through Wireshark to sniff the traffic that was sent. Steps to work that are as follows,

1. Share your Mac’s internet connection via Airport
2. Have your iPhone connect to that airport connect
3. Start Wireshark and have it sniff packets with a filter to prevent excessive information overload
4. Run app, capture data
5. Analyse

Basically, calls were being made to the mobile version of the shuttle bus timings site. From there, they would parse the HTML files using regular expressions to figure out the details of such timings.

While I applaud the hard work, I am a tad disappointed that they did not bother to even do more research and realise that there was an open source project that specifically grabs the same data they want and does it in a better way.

Still all in all, having a competitor did bring some good. The number of downloads for Traversity spiked by a little from the usual amount the day their app launched. So all’s not that bad after all.