Exploit tool reveals inner working of the iPhone

An iPhone debugging tool has been released that reveals the inner workings of Apple's popular gadget.
Written by Liam Tung, Contributing Writer

An iPhone debugging and hacking tool has been released that reveals the inner workings of Apple's popular gadget.

Exploit writer, Nicolas Economou of Core Security Technologies, this month released several tools designed to allow developers to analyse and remove bugs from native code running on the iPhone. This includes Apple's own iPhone libraries and is something the Cupertino-based firm is not likely to ever provide to the public. Economou says the debugger was inspired by a previously released debugger called "weasel", developed by Patrick Walton, which fellow exploit writer H D Moore recently released an update for.

ZDNet.com.au asked Core Technologies' chief technology officer, Ivan Arce about the iPhone debugger.

What is the purpose of the iPhone debugger?

Ivan Arce: The purpose of the project is simply to improve on the currently available tools for debugging and development of iPhone programs.

Naturally, as the iPhone becomes more prevalent, any potential security issues in the mobile device will become more relevant to the IT security risk equation — particularly in the case of adoption of the iPhone at the enterprise level.

Also, to be able to identify and investigate potential issues it is necessary to have the proper tools (such as a debugger) and to familiarise yourself with the quirks and idiosyncrasies of debugging iPhone programs, and hence developing these tools seemed to be a good idea.

Why did you develop this and what can you do with it? Why would you want to debug an iPhone library?

Ivan Arce: Large portions of an iPhone's program functionality are implemented in base library components of the iPhone OS. These are usually referred to as shared libraries and are the UNIX-world equivalents to MS Windows' DLL files. A basic component of the OS loads these shared libraries on demand, during a program's execution, when a given library functionality is needed to be run by the iPhone program.

This basic OS component that loads shared libraries is the dynamic loader which is a fundamental part of the OS and the iPhone, like all other OSes, has one.

To be able to properly debug a program it is necessary not just to monitor and alter the execution of the program's code, but also of these general purpose shared libraries that the programs use. In order to do that, it is in turn necessary to be able to monitor and alter the execution of the Dynamic Loader component of the iPhone OS itself. That is exactly the purpose of the dyld_patcher component in Nico's project.

There's also another tool called the iphone_tunnel. What's the point of the tunnel between a PC and iPhone?

Ivan Arce: Currently the way to establish an IP (TCP or UDP) connection with an iPhone is to connect to it over Wi-Fi by having your PC on the same wireless network as the iPhone; or by having your iPhone connect to your PC over the internet using the provider's EDGE network.

Yet, the iPhone also comes with a USB cable to connect it directly to a USB port on your PC/Mac for synchronisation purposes. Unfortunately it does not let you establish TCP or UDP connections and only works if you use iTunes.

The tunnel program that Nicolas developed lets an iPhone user establish a direct IP connection from the PC/Mac to any TCP or UDP network service on the iPhone using the standard serial cable included for synchronisation.

This makes it much easier to develop, monitor, communicate with and debug network-facing programs that run on the iPhone.

Is it something you expect Apple to try to prevent in future firmware updates?

Ivan Arce: No, not really. I don't see a good reason for Apple to want to prevent developers from debugging iPhone applications or use their own tools to do so. There are several security and interoperability reasons that justify not preventing it from happening.

That being said, Nico's iPhoneDbg toolkit may become deprecated or even irrelevant if Apple provided a robust, interoperable, platform-independent tool to debug iPhone programs. But even if that happened, the whole exercise of using and further developing the toolkit may be worth doing for educational purposes.

Editorial standards