Caged Spelunking

You can learn a lot by exploring an application’s ipa. Details like how it’s built, how it tracks its users and whether it has any obvious security vulnerabilities. This is all good information to know if you are looking to take a new job where they have existing apps. In this post I’m going to show how you can get some insights into existing apps without having to venture into jailbreaking.


Getting an ipa from the App Store

This is annoyingly fiddly but can be done like this:

  • Download the app you want to investigate onto your device.
  • Install Apple Configurator 2 from the app store and launch it.
  • Sign into your Apple account in Apple Configurator 2.
  • Connect a device.
  • Right click on your device and select Add > Apps....
  • Select the app you want to investigate and click Add.
  • After some time you should be presented with an error dialog along the lines of:
    The app named "Some App" already exists on "Your iPhone".
  • Use terminal (or navigate manually) to find the downloaded file in the following directory:
    open ~/Library/Group\ Containers/K36BKF7T3D.group.com.apple.configurator/Library/Caches/Assets/TemporaryItems/MobileApps
  • Locate the ipa for the app you are interested in and copy it somewhere else.
    NB: You must copy before accepting the error dialog or the ipa will be deleted.

Preparation

Now you have the ipa you can start to explore. Start by renaming the .ipa suffix to .zip and then double click the file to unzip. Inside the zip you should find a file with a .app suffix, go ahead and remove the suffix to make exploration a little simpler.

To help visualise the structure of an app I recommend using a tool like Grand Perspective, which will generate an interactive map of the used disk space. Here’s what the diagram looks like for VLC for iOS:

Disk usage for VLC for iOS


Investigation

Now it’s just a case of poking around and seeing what is there. If you are exploring in preparation for an interview, then you should really be taking note of what you find and considering if you need to do any research into these things. Here’s some stuff that you might see and what it might mean:


*.car files

Indicates that this app uses Asset catalogues - these have been around for a while now but to brush up here’s the reference.


Frameworks directory

You can learn a lot about how an app is built by examining the contents of this folder. Questions to ask in here are:

  • Are there too many dependencies?
  • Are dependencies well maintained?
    • The frameworks generally show their version information in their plist.
    • This can be worrying especially if you can see a framework version being used that is known to be vulnerable.
  • Are there creepy analytics SDKs?
  • Is the app built using some Swift? The presence of libraries of the format libSwift* indicates Swift is used.

Info.plist file

The Info.plist file contains all kinds of useful information:

It’s always worth looking in this file as it defines a lot of the app’s capabilities - here’s the reference. It’s also an easy place for developers to dump information (sometimes incorrectly) to use within the app, so there could be some secrets being exposed.


*.lproj directories

These folders are present in localised apps - the more folders there are the more territories that the app has been localised to. If you want to read the contents of the *.strings files within these directories then go ahead and rename the extension from .strings to .plist.


*.momd directories

This directory shows that the app is using CoreData - here’s the reference. To get a sense of what data is being stored you can peek in the *.mom files by renaming the the extension from .mom to .plist.


*.nib or *.storyboardc files

Not everyone is a fan of using interface builder so seeing a load of these in the ipa will either raise red flags or finally give you a reason to conquer that fear and give them another chance.


Settings.bundle directory

You can explore this by right clicking the file and selecting Show Package Contents. Here’s the reference for settings bundles.


Dynamic Analysis

Doing the above is great for getting a look at how the app might be built but it’s also worth looking at how the app runs. This is where I would be loading up Charles Proxy on my device and running the app to see what network requests are being made.

Once you have some network data you can ask questions like:

  • Are they using https?
  • Do the API requests being made look reasonable?
  • Is the app quite chatty on the network?
  • Are there any security issues or data being leaked within the requests?

Conclusion

You don’t have to go straight to jailbreaking devices to get a rough idea of how an app is built. I personally find this exploration interesting and really helpful when looking at potential career moves e.g. doing a bit of due diligence to make sure I’m not stepping into a burning app.

Git apply-edit - improving `git edit`

In my last post I discussed the creation of a git helper called git-edit. The subcommand is really helpful but in this short post I’m going to look at a slightly different way of adding new git functionality that is built on top of git-edit.


Problem outline

When working on a feature I often find myself writing code and thinking “this should really be in an earlier commit”. There are many reasons for doing this:

  • It might logically makes more sense for some work to appear in a certain order
  • I might opt to move some work earlier and cut a shorter branch so other features can use code earlier
    • e.g. I might aim to get a few commits merged quickly whilst the rest of the feature is being fleshed out
  • I might want to add a “REMOVE ME” commit
    • If I need to add a temporary hack to allow some feature work I put it in an isolated commit as soon as possible. Being in a different commit makes it really simple to delete the commit before pushing for code review

These are all good uses for git-edit. A repeating usage pattern I see in my own work is that I will create the new work and then realise that I don’t want to target head, instead I want to target an earlier commit. So to perform a git-edit I often need to stash my changes, then run git-edit followed by git stash pop. Looking in my zsh history it appears that I do this a lot so it would be useful to automate it a bit.


git alias

For a simple chain of commands like this I don’t really need to make a separate executable script as I can just leverage git’s ability to add aliases.

~/.gitconfig

[alias]
  apply-edit = !sh -c 'git stash && git edit $1 && git stash pop' -

With this alias added to my .gitconfig I can now run git apply-edit <some-sha> from my current position.

I like this flow and the fact that the pop will fail if the working directory can not be reproduced cleanly just reminds me that if I had just used a --fixup this would have been more painful and less immediate to resolve.

Git edit - improving --fixup

I’m a big fan of attempting to make my git history useful. This often means reworking my commits so that work is done in a sensible order and in small logical units. There are many ways to rework your history in git but one I’ve used a lot for the past year is the --fixup flag when committing. This has often led to annoying problems, in this post I’ll look at:


Using --fixup

The --fixup flag is a bit like the --amend flag except you can specify the commit you want to squash your work into rather than it just being squashed into the most recent commit.

When given the following history:

* 0230dcb (HEAD -> master) Add git-edit post
* 4564152 Add testing tips post
* 9051216 Add tying things together post

If I stage some changes and run git commit --amend then the last commit Add git-edit post will be rewritten to include my staged changes.

If instead I want my changes to go into a commit that is not the most recent then I can use the following command git commit --fixup 4564152. In this example I would end up with the following

* a5f2563 (HEAD -> master) fixup! Add testing tips post
* 0230dcb Add git-edit post
* 4564152 Add testing tips post
* 9051216 Add tying things together post

Once I have this I can run git rebase --interactive 9051216 and accept the todo list to have git squash the new changes into the target commit.


Problems with --fixup

I love --fixup but it doesn’t quite do so well when you have heavy churn in your files (possibly a sign that the work could be reordered). The issue you run into a lot is that when you make your changes to fix up a commit you are potentially looking at a source file that has been changed in multiple steps. Any changes you make may only make sense in the current state of the file, this can lead to conflicts when targeting an earlier revision of the file.


A solution git-edit

We can avoid the issues above by:

  • rolling back our repo to the target commit
  • applying the changes we want
  • reapply the remaining commits

This is achievable by using our friend git rebase --interactive <commitish>. Going back to our earlier example

* 0230dcb (HEAD -> master) Add git-edit post
* 4564152 Add testing tips post
* 9051216 Add tying things together post

If I want to make changes to the commit 4564152 then I can run git rebase --interactive 4564152~1 to be presented with a todo-list in an editor.

pick·4564152·Add·testing·tips·post¬
pick·0230dcb·Add·git-edit·post¬
¬
#·Rebase·9051216..0230dcb·onto·9051216·(2·commands)¬

#·Commands:¬
#·p,·pick·<commit>·=·use·commit¬
#·r,·reword·<commit>·=·use·commit,·but·edit·the·commit·message¬
#·e,·edit·<commit>·=·use·commit,·but·stop·for·amending¬
#·s,·squash·<commit>·=·use·commit,·but·meld·into·previous·commit¬
#·f,·fixup·<commit>·=·like·"squash",·but·discard·this·commit's·log·message¬
#·x,·exec·<command>·=·run·command·(the·rest·of·the·line)·using·shell¬
#·b,·break·=·stop·here·(continue·rebase·later·with·'git·rebase·--continue')¬
#·d,·drop·<commit>·=·remove·commit¬
#·l,·label·<label>·=·label·current·HEAD·with·a·name¬
#·t,·reset·<label>·=·reset·HEAD·to·a·label¬
#·m,·merge·[-C·<commit>·|·-c·<commit>]·<label>·[#·<oneline>]¬
#·.·······create·a·merge·commit·using·the·original·merge·commit's¬
#·.·······message·(or·the·oneline,·if·no·original·merge·commit·was¬
#·.·······specified).·Use·-c·<commit>·to·reword·the·commit·message.¬

#·These·lines·can·be·re-ordered;·they·are·executed·from·top·to·bottom.¬

#·If·you·remove·a·line·here·THAT·COMMIT·WILL·BE·LOST.¬

#·However,·if·you·remove·everything,·the·rebase·will·be·aborted.¬

#·Note·that·empty·commits·are·commented·out¬

I can now change the first pick line (which is for the commit we passed in) to say edit instead e.g.

- pick·4564152·Add·testing·tips·post¬
+ edit 4564152·Add·testing·tips·post

After saving this file I’ll be placed on the commit 4564152 where I can make my edits, add changes and finish up by calling git rebase --continue.

The above is fine but it’s a little manual so it would be nice if we could automate away some of these steps. Let’s see how we can do that.


Creating your own git commands

The first piece of the puzzle is creating a git command. I’d like the command to work as if it was a git subcommand by typing git edit <commitish>. This is actually not too difficult to do - add an executable command somewhere on your path with the name git-edit. Now when I call git edit <commitish> git will invoke my script. Let’s test it

~/bin/git-edit

echo "hey"

zsh

> git edit aabbcc
hey

GIT_SEQUENCE_EDITOR

The next challenge is how do I automate editing the todo list that you get when you call git edit? Again git has a nice seam for us to work with - we can set the environment variable for GIT_SEQUENCE_EDITOR to our own command. Our command will be invoked with one argument, the path to the todo-list file.


With this knowledge we can write a script that will:

  • read a todo-list file
  • update the correct todo-list item to be edit instead of pick
  • save the file

Let’s do this in ruby:

 1 #!/usr/bin/env ruby
 2 
 3 if ENV['GIT_SEQUENCE_EDITOR'] != __FILE__
 4   exec "GIT_SEQUENCE_EDITOR='#{__FILE__}' git rebase --interactive #{ARGV.first}~1"
 5 end
 6 
 7 todo_list = ARGV.first
 8 
 9 lines = File.readlines(todo_list)
10   .lazy
11   .take_while { |line| line != "\n" }
12   .map        { |line| line.gsub("fixup", "pick") }
13   .to_a
14 
15 lines[0] = lines[0].gsub("pick", "edit")
16 
17 File.write(todo_list, lines.join)
  • Lines 3-5 allow me to use a single script to handle editing the todo-list and creating my personal git edit subcommand
    • When I call git edit <commitish> the GIT_SEQUENCE_EDITOR will not be equal to this executable script’s name so it will execute the interactive rebase command on line 4 and set the GIT_SEQUENCE_EDITOR to the current file
  • Lines 9-13 handle reading in the todo-list, stripping all comments from the file and replacing any fixup lines with pick
    • It’s important for my usage to leave the fixup lines in place until I choose to squash things later
  • Line 15 edits the line for the commit we passed to the original command to put it in edit mode
  • Line 17 finishes the process off by writing the todo-list back to disk

With all of this in place we can now run a git subcommand that automates the process of rewinding us back to a particular commit to allow us to make changes and then reapply all subsequent commits in order.


Conclusion

There’s a few handy things to take away here around adding your own scripts to git. Knowing that it’s actually not too painful to add quite complex automation means that I’ll really pay attention more to manual tasks that I repeat and look at automating these tasks in future.