Primer On Reversing Jail Broken Iphone Native Applications - by - Shub-Nigurrath

A che e
2008
Primer on Reversing Jailbroken
iPhone Native Applications
Shub-Nigurrath
ARTeam
May 2008
PRIMER ON REVERSING JAILBROKEN IPHONE NATIVE APPLICATIONS
DISCLAIMER
All code included with this tutorial is free to use and modify; we only ask that you mention where you found it.
This tutorial is also free to distribute in its current unaltered form, with all the included supplements.
All the commercial programs used within this tutorial have been used only for the purpose of
demonstrating the theories and methods described. No distribution of patched applications has been done
under any media or host. The applications used were most of the times already been patched by other
fellows, and cracked versions were available since a lot of time. ARTeam or the authors of the papers
shouldn’t be considered responsible for damages to the companies holding rights on those programs. The
scope of this document as well as any other ARTeam tutorial is of sharing knowledge and teaching how to
patch applications, how to bypass protections and generally speaking how to improve the RCE art. We are
not releasing any cracked application.
VERIFICATION
ARTeam.esfv can be opened in the ARTeamESFVChecker to verify all files have been released by ARTeam and
are unaltered. The ARTeamESFVChecker can be obtained in the release section of the ARTeam site:
http://releases.accessroot.com
Jailbreaking your iPhone power 2

TABLE OF CONTENTS
Disclaimer ........................................................................................................................................................ 2
Verification ...................................................................................................................................................... 2
Forewords ....................................................................................................................................................... 5
1 JAILBREAKING YOUR IPHONE POWER 6
1.1 Fast and practical jailbreaking procedure ............................................................................................. 7

1.1.1 Using iPlus to jailbreak ........................................................................................................................ 8
1.1.2 Using ZiPhone to jailbreak ................................................................................................................ 11
1.2 File system structure .......................................................................................................................... 13
2 DISASSEMBLING THE FIRST NATIVE PRE-INSTALLED APPLICATIONS 14
2.1 Essential Notes on the Mach-O file format ......................................................................................... 15
2.2 Essential Notes on the Objective-C Programming Model .................................................................... 19
2.3 Essential Notes on the reversing of objective-C: the role of objc_msgsend ........................................ 20
2.4 Where to go deeper ........................................................................................................................... 22
2.5 Continue to reverse our first application ............................................................................................ 22
2.6 CFStrings objects and normal strings .................................................................................................. 23
2.7 Selectors-handlers map ...................................................................................................................... 24
3 UNLOCKING FOR REAL THE IPHONE/IPOD TOUCH 27
3.1 ScreenShots........................................................................................................................................ 29
3.2 Connect your PC to the device ............................................................................................................ 29
4 REVERSING SOME APPLICATIONS 32
4.1 Go down with the first application: AcceleroLog ................................................................................ 32

4.1.1 Adjust the Application so as IDA can handle it correctly .................................................................. 33
4.1.2 Patching the Application ................................................................................................................... 37
4.1.3 How to calculate the opcode of a branch in ASM ............................................................................ 39
4.2 Going on with the second application: ShowTime .............................................................................. 41

4.2.1 Version 1.1b ...................................................................................................................................... 42

4.3 Going on with the third application: iSim ........................................................................................... 45

4.3.1 Find the correct installer URL through the .plist file ......................................................................... 46
4.3.2 Reversing the target ......................................................................................................................... 46
4.3.3 Changing the class of a Section from DATA to CODE ........................................................................ 47
4.4 Going on with the Fourth application: Camerapro ............................................................................. 50

4.4.1 Find the correct installer URL through the .plist file ......................................................................... 50
4.4.2 Reversing the target ......................................................................................................................... 51
4.5 Going on with the FIFTH application: PocketMoney ........................................................................... 51
4.6 Going on with the Sixth application: Softick Solitaire ......................................................................... 52

4.6.1 Approaching the Application ............................................................................................................ 53
4.6.2 Manually Finding the reference to a given string ............................................................................. 54
4.7 Where to find other native applications ............................................................................................. 57
5 CONCLUSIONS 58
5.1 References ......................................................................................................................................... 59
5.2 History................................................................................................................................................ 60

FOREWORDS
This tutorial is another primer I decided to write (similarly to what I

did for Symbian), following my early experiences in the
iPhone/iPood Touch world. We are talking of the iPhone (and the
little brother iPood Touch), the Apple telephone which doesn’t
support Java, nor Flash, cannot be used like a modem, do not fully
support Bluetooth, do not allow to install third party applications
(officially at least), which cost is very high and that you can only be
used with those telecom carriers chosen by Apple just with EDGE
network.
With all these limitations the iPhone should have disappeared from
the market, instead it is alive and kicking, collecting records: it
conquered in a very short timeframe about a third of the overall smartphones market and it is responsible of
about ¾ of the overall online traffic of the mobile devices. The iPhone is not only an iPood with advanced
multimedia features, equipped with WiFi, but it has a real powerful system under the wood, a complete
operative system with a full web browser (Safari) and applications, built to go on the Web 2.0.
Once unlocked (using techniques I will not explain with much in details) a new world opens up: a lot of native
programs (not web) are awaiting your patches and customizations. It’s a completely different world for those
of you already accustomed to the Win32 environment, but also has some differences for those already
reversing in the Mac world. The OS is an OSX, build up from FreeBSD, but it isn't the MAC OSX and the
processor is an ARM, then RISC assembler not easy to handle at all (like for Symbian phones). The
programming technologies are anyway the same already used for MAC: COCOA/Darwin and underneath
objective-C.
At the moment all the existing native applications are built using the unofficial SDK (but the official SDK is
announced soon) and are most of the times, but not always, completely free. Users must before jailbreak their
devices and it’s not a thing anyone could/would do. Most of the applications are just experiments meanwhile
the real SDK is not here, just few are donation-ware and even less are shareware.
I will assume you have already got the basics of the ARM disassembler and IDA things. If not I suggest to read
the “Primer on Reversing Symbian S60 Applications”[12] or the “Symbian Symphony For 4 Crackmes And A
Commercial Program”*13+ I already released, at least just about the details on the ARM platform and
assembler there explained.
All along the document I spread a lot of links to references and further readings, keep attention to them to
dive some aspects..
BTW Do you like the new tutorials look?
Your Favourite Neighbourhood Shubby

1 JAILBREAKING YOUR IPHONE POWER
When I did for the first time the jailbreak of the iPhone it was a quite complex and risky procedure: you had to
1
downgrade the firmware to version 1.1 and then break it, using a failure in the handing of TIFF images of that
firmware. Starting from this you had to upgrade backward (or forward) to the latest firmware. The procedure
was, theoretically simple: downgrade to firmware 1.1, exploit of a TIFF handling bug, which gave permission to
execute arbitrary code as native. The hole was large enough to be finally able to install any application.
Upgrade where done on an already compromised system, which was then able then to re-create the backdoor
on newest firmware too.
On the net you can find several guides which explain completely what you have to do.
As described in [1] the original procedure used for the first time to unlock the firmware was possible with
some collaboration of an Apple employee (rumours). Anyway what is sure is that the distribution file of the
firmware iPhone1,1_1.0.2_1C28 was incredibly easy to decrypt.
You should know that the firmware is downloaded from the apple site as files with the ipsw extension. These
2
files are indeed zip files which contains among other things an encrypted MAC disk image, in the dmg format .
This format was well encrypted using AES, and theoretically very hard to decrypt. What is the strange is that
the encryption key was clearly buried inside the dmg file as clear string. It was possible to run a bat file like the
3
following to find it :
strings -q %1|agrep "^[0-9a-fAF]*$"|awk "{ if (length($1) == 72) print; }"
which in other words finds a string made of literals and numbers long 72 chars then prints it.
Then this string was used to decrypt the file using vfdecrypt, using this line:
vfdecrypt.exe -i 694-5298-5.dmg -k
7d5962d0b582ec2557c2cade50de90f4353a1c1de07b74212513fef9cc71fb890574bfe5 -o
dmg_image_decrypted.dmg
The vfdecrypt sources are available on the net [2] and the early lines of the source code tell:
* Copyright (c) 2006

* Ralf-Philipp Weinmann <ralf@coderpunks.org>
* Jacob Appelbaum <jacob@appelbaum.net>
* Christian Fromme <kaner@strace.org>
* Decrypt a AES-128 encrypted disk image given the encryption key and
* the hmacsha1key of the image. These two keys can be found out by running
* hdiutil attach with -debug on the disk image.
This is a tool that was developed for Macs, not for iPhones! This makes me wondering that Apple was indeed
4
willing to have jailbroken iPhones
Anyway, using this procedure is even possible to decrypt the whole dmg file on a Windows PC (you must install
5
some dlls from the cgywin distribution and find some other things but it’s not difficult) .
1
http://blog.metasploit.com/2007/10/cracking-iphone-part-1.html
2
The ONLY tool I found able to read iPhone dmg files is TransMac 8.x (www.asy.com), all the others, including
PowerISO, fails.
3
To be precise, these files contain the string "encrcdsa" at the beginning then are Mac Encrypted Sparsedisk
4
http://iphonejtag.blogspot.com/2008/01/iphone-secret-key.html

What you get once you are able to look inside the dmg files is the complete control of the system files,
applications and so on.
Fortunately meanwhile, thanks to

ZiPhone [3] and most of all thanks to
iPlus [4], the whole procedure becomes
easier. Now, for example using iPlus you
can jailbreak the firmware 1.1.4 in a
snap, just using a single button. It’s
anyway an interesting thing because the
procedure is essentially the same I
explained before, just automated.
As I told I will not stop longer on this issue, even because this tutorial concentrates on reversing the iPhone
6
apps build using the unofficial SDK (for the moment the official SDK is only in beta).
1.1 FAST AND PRACTICAL JAILBREAKING PROCEDURE
Remember, unlocking is totally up to your responsibility, be sure to know what you are doing. I will ever never
provide help on this. Look in sites such this: http://www.iphonehacks.com
What follows is my personal very concise guide on unlocking an iPod Touch mainly (I do not have an iPhone).
The unlocking processes for iPod Touch or iPhone are a little different. First we must distinguish among the
different operations you can do.
 downgrading: the unlocking process uses some bugs of specific versions of the firmware. This bug is
used to inject code into the system that then runs natively. This first hole is then used as a trampoline
attack for the following patches. The result is that from a modded initial version you can return to the
original latest firmware. You must then downgrade your device which comes pre-equipped with the
latest firmware.
 jailbreaking: unlock the operative system so as you can install third party native applications. This
implies that you will get full control over the system, becoming able to do the following steps. This is
the basic operation for any other optimization you may want.
 activating: this operation activates back the jailbroken phone but doesn't patch the system in order to
operate with different carriers. Apple inserted some blocks which prevent unlocked phones from
doing some operations, activation skip these blocks.
 unlocking: given that your device has been jailbroken you can then modify the system either native or
installed applications. If you patch the native applications responsible of locking the device to a
specific carrier you are performing the “unlock” of your device.
5
You can find all the required steps and tools at [1, 2]
6
Unofficial SDK, http://www.iphoneatlas.com/2007/09/19/the-unofficial-iphone-sdk-guide-to-writing-native-
iphone-applications/

There are different tools you can use to unlock the system. As I told before I only did the jailbreaking
procedure on an iPod Touch. These tools anyway are almost completely automated and it's just a matter of
which button you will press.
The two most used are these:
 iPlus 2.0b (http://ipluspwns.blogspot.com/) but works only with firmware 1.1.4
 ZiPhone (http://www.ziphone.org/) and all its alternative interfaces (like the excellent eZiPhoneTools
http://eziphone.blogspot.com/). This one is now open-source so you can also write your own
interface and optimize it as you like. This is the ancestor of any other tool you may find around. All the
other tools are just repackaging or refinements of this one.
ZiPhone is a conglomerate of others work. It copies a new fstab for write access to system, runs
iPatcher to patch lockdown, copies installer, and runs my gunlock to unlock. It is a good way to restore
from most problems, and true jailbreak 1.1.3 My program is just patched to change the default
IMEI(0049) to the user entered IMEI; although I would strongly advise against changing your IMEI. The
7
exploit he uses runs an unsigned ramdisk with all these programs.
You can find other news in [14] and http://iphonejtag.blogspot.com/ and even here for all the problems you
may have: http://www.hackthatifone.com/forum/index.php?action=forum
Note
•You can find almost all the needed tools you may
need at: ftp://ftp.iphonefix.de/ or http://iphone-
dev.org/ [17,18]
1.1.1 USING IPLUS TO JAILBREAK
http://ipluspwns.blogspot.com/
All you need is to write: iplus -u
the result of the operation (on PC side) is something like the following:
C:\iPlus2.0>iplus -u
----------------------------------------------------------------------------
iPlus 2.0a by Aviegas starting...
----------------------------------------------------------------------------
Downloading payload to iPhone
----------------------------------------------------------------------------
Will now jailbreak, activate and optionally unlock the iPhone
The iPhone will reboot twice. One to jailbreak and another for all other operations
iPlus 2.0b for iPhone Firmware 1.1.4

RAMDisk bootstrap code (based on ziphone 2.4)
7
http://iphonejtag.blogspot.com/2008/02/11246unlock-good-enough-for-prize.html

Loading iplus.dat.
Searching for iPhone...
Entering recovery mode.
Working...
Please wait 2'30".
Done!
----------------------------------------------------------------------------
Pass 1: Jailbreak and setup for next pass completed.
----------------------------------------------------------------------------
Pass 2: unlock/downgrade, activatioan and package installation starting...
----------------------------------------------------------------------------
iPlus 2.0a Processing completed. Enjoy your iPhone!
The log file "iplus.log" was retrieved from the iPhone.
----------------------------------------------------------------------------
The program also generates a log file with the list of packages that are automatically installed on the device.
These packages are the most important ones, those which you usually would install anyway. (term-vt100,
openssh, installer.app, etc):
iPlus 2.0b - Pass 2 Starting

Unpacking main payload.
Please wait...
Unlocking phone...
Attempting unlock for BL3.9
Please wait...
Unlocking completed
iPhone fake activation...
Patching lockdownd...
Activating youtube...
Activation completed
Unpacking Brazil support kit...
Unpacking timezone fixes...
Unpacking pt_BR translations...
Patching files...
Installing BSD Subsystem
Please wait...
Applying fixes
Installing OpenSSH...
Applying fixes
Installing term VT-100...
Installing Installer :)
Applying fixes
Relocating Fonts and Ringtones
Please wait...
The iPhone will now reboot
iPlus 2.0 - Pass 2 Completed
8
When the program finishes the device is in the so called DFU mode .
You then need to exit from this mode. Manually or through a command sent by the PC (via USB cable)
I got used to this tool eZiPhoneTools1.3 (http://eziphone.blogspot.com/), Figure 1.
8
The DFU mode is a debug mode used by the device when it is upgrading the system, see
http://limitededitioniphone.com/how-to-put-the-iphone-into-dfu-mode/

Figure 1 – Main interface of eZiPhoneTools
This tool has some interesting functionalities really handy. Some of them are those to enter and exit from DFU
and recovery modes like "exit recovery mode - normal boot":

1.1.2 USING ZIPHONE TO JAILBREAK
Sometimes I got problems with iPlus, the unlocked device is somehow buggy, and one example which occurs
was that the device hangs whenever I try to use the virtual keyboard. Sometimes (depending on the device)
instead everything goes fine. Dunno why, but what is sure is that ZiPhone never gave such problems. The only
drawback is that this program doesn't automatically install any program on the unlocked device. You will have
to do it manually, despite this, on iPod at least, the whole jailbreaking process is faster.
•Sometimes the unlocking process hangs in loop and the patched bootloader
Note
stops repeating all the times a message like this:

•BSD root: md0, major 2, minor 0
•if this happens, set the device in DFU mode, restore the firmware using iTunes
and change unlocking tool.
Figure 2 – Main Interface of ZiPhone (version 2.5c)

As already said if you have an iPod Touch you must only use the jailbreak not the “unlock” (the modifications
done by the “unlock” applies to the iPod touch too, because that part of the system is still present, but are
useless because the telephony hardware is not).
After you finish the operation you will have to manually install the most useful packages:
 system/bsd subsystem - useful to install a subset of the BSD (freeBSD system) commands.
 system/openSSH - this installs the OpenSSH drivers used to connect to the device through ftps (ftp
secure)
 utilities\respring - useful to restart the springboard program (the main view, similar to windows
desktop). It refresh the list of applications only at the startup then if you install a new application,
springboard must be restarted in order to see it.
 utilities\shapshot – useful to take snapshots of programs you handle.
Reassuming:
Here some important notes:
1. It is impossible to permanently transform your iPod Touch into a brick (this isn't always true with iPhones),
the iPod can always be restored to its original status and you can do again the operation.
2. It is always possible to recover from a not terminated jailbreak process or a loop. You can enter in DFU
mode and:
- press the off and home buttons (the only two buttons present!) together till the device goes off
- connect the device to the USB port holding the home button till a connecting sync cable
animated icon appears.
- when iTunes warns that it detected a DFU mode device you can leave all the buttons
- then press on the "Restore" button of iTunes, pressing the shift key. This opens an openfile
dialogbox from where you can select the ipsw file you already downloaded before (for example
for the version 1.1.4 google some location of this file "iPod1,1_1.1.4_4A102_Restore.ipsw" and
9
download it to the PC disk)
- when process completes you can start again trying to jailbreak the device.
9
You can find all the firmware here: http://www.hackthatifone.com/forum/index.php?topic=60.0

1.2 FILE SYSTEM STRUCTURE
Suppose that you were able to unlock the iPhone or the iPod Touch
devices. What you have in hands is an OSX system, which is a customized
version of the already known MAC OSX. Indeed at Apple they call OSX the
general system which becomes iPhone OS if customized for iPhones or
MAX OSX if customized for MACs. Anyway it’s basically a FreebBSD
system with all the typical MAC programming interfaces: COCOA and most
of all everything has been built using Objective-C [5]. Being basically an
unix system, all the processes of the iPhone or iPod are running as root,
with full rights.
Reassuming
the jailbroken system reveals to be:
A FreeBSD system with all the processes running as root
All the applications were built using Objective-C
There is support for already known frameworks like COCOA
Figure 3 – file system of firmware The file system resembles one of an Unix system (actually FreeBSD)
1.1.x
Figure 3 shows that all the applications are stored under the Applications folder (system applications too, like
safari for example).
The “Usr” folder holds the home directory of the root user, the only user existing on these devices. The
complete structure is anyway quite complex and you can browse it just to understand what you might find
inside.
At the moment I will work on the PC, using a decrypted image of the firmware, simulating what we will find on
the unlocked device. This is handy because allows us to concentrate on the problem of reversing some
applications. We will learn how to install, copy to PC, patch the applications then move to the device.
What I want to start from is a simple pre-installed application, the calculator.app

2 DISASSEMBLING THE FIRST NATIVE PRE-INSTALLED APPLICATIONS
The Calculator.app is inside the folder Applications\Calculator.app. This folder contains these files:
English.lproj\
Calculator
CalculatorBackground.png
Default.png
icon.png
Info.plist
LCDBackground.png
PkgInfo
ring.png
The real application is Calculator, without extensions in the name. The png files are actually customized png
10
files and you cannot open them directly on the PC . The Info.plist is the Apple equivalent of the jad files of
mobile J2ME java installers.
The Calculator file is an executable stored in the MATCH-O format, the executable file format used on Macs.
Different syntax but same ancestor of the PE file format (both shares their origins from the Unix executable file
formats). Fortunately IDA 5.2 can read them (see Figure 4)! Just take care to switch the Processor type to ARM.
Figure 4 – IDA is about to open Calculator file
Leave this application to IDA and wait, when it is ready you can see what it found inside.
10
As you will see later the iPod PNG format is not really the PNG format, it requires a little program on PCs to
see them (see section 3.2).
Disassembling the first Native Pre-installed applications 14

2.1 ESSENTIAL NOTES ON THE MACH-O FILE FORMAT
The Mach-O file format is well documented on the net [6], it is organized in sections like PE files (see Figure 5).
A Mach-O file contains three major regions (as shown in Figure 1):
 At the beginning of every Mach-O file is a header structure that identifies the file as a Mach-O file.
The header also contains other basic file type information, indicates the target architecture, and
contains flags specifying options that affect the interpretation of the rest of the file.
 Directly following the header are a series of variable-size load commands that specify the layout and
linkage characteristics of the file. Among other information, the load commands can specify:
 The initial layout of the file in virtual memory
 The location of the symbol table (used for dynamic linking)
 The initial execution state of the main thread of the program
 The names of shared libraries that contain definitions for the main executable’s imported
symbols
 Following the load commands, all Mach-O files contain the data of one or more segments. Each
segment contains zero or more sections. The term ‘segment’ in Mach-O files is roughly equivalent to
the term ‘section’ in the Windows Portable Executable format. Each section of a segment contains
code or data of some particular type. Each segment defines a region of virtual memory that the
dynamic linker maps into the address space of the process. The exact number and layout of segments
and sections is specified by the load commands and the file type.
 In user-level fully linked Mach-O files, the last segment is the link edit segment. This segment contains
the tables of link edit information, such as the symbol table, string table, and so forth, used by the
dynamic loader to link an executable file or Mach-O bundle to its dependent libraries
Figure 5 – Mach-O file format basic structure
The segments have standard names: __PAGEZERO, __TEXT, __DATA, __OBJC, __IMPORT, __LINKEDIT

The static linker creates a __PAGEZERO segment as the first segment of an executable file. This
segment is located at virtual memory location 0 and has no protection rights assigned, the
combination of which causes accesses to NULL, a common C programming error, to immediately
crash. The __PAGEZERO segment is the size of one full VM page for the current architecture (for Intel-
based and PowerPC-based Macintosh computers, this is 4096 bytes or 0x1000 in hexadecimal).
Because there is no data in the __PAGEZERO segment, it occupies no space in the file (the file size in
the segment command is 0).
The __TEXT segment contains executable code and other read-only data. To allow the kernel to map
it directly from the executable into sharable memory, the static linker sets this segment’s virtual
memory permissions to disallow writing. When the segment is mapped into memory, it can be shared
among all processes interested in its contents. (This is primarily used with frameworks, bundles, and
shared libraries, but it is possible to run multiple copies of the same executable in Mac OS X, and this
applies in that case as well.) The read-only attribute also means that the pages that make up the
__TEXT segment never need to be written back to disk. When the kernel needs to free up physical
memory, it can simply discard one or more __TEXT pages and re-read them from disk when they are
next needed.
The __DATA segment contains writable data. The static linker sets the virtual memory permissions of
this segment to allow both reading and writing. Because it is writable, the __DATA segment of a
framework or other shared library is logically copied for each process linking with the library. When
memory pages such as those making up the __DATA segment are readable and writable, the kernel
marks them copy-on-write; therefore when a process writes to one of these pages, that process
receives its own private copy of the page.
The __OBJC segment contains data used by the Objective-C language runtime support library.
The __IMPORT segment contains symbol stubs and non-lazy pointers to symbols not defined in the
executable. This segment is generated only for executables targeted for the IA-32 architecture.
The __LINKEDIT segment contains raw data used by the dynamic linker, such as symbol, string, and
relocation table entries.
Each segment can have different sections which usually have standard names too [6]:
Table 1 - The sections of a __TEXT segment
Segment and section name Contents

__TEXT,__text Executable machine code. The compiler generally places only executable code in
this section, no tables or data of any sort.
__TEXT,__cstring Constant C strings. A C string is a sequence of non-null bytes that ends with a null
__TEXT,__cfstring
byte ('\0'). The static linker coalesces constant C string values, removing
duplicates, when building the final product.
__TEXT,__picsymbol_-stub Position-independent indirect symbol stubs.
__TEXT,__symbol_stub Indirect symbol stubs.
__TEXT,__const Initialized constant variables. The compiler places all non-relocatable data
declared const in this section. (The compiler typically places uninitialized constant
variables in a zero-filled section.)
__TEXT,__literal4 4-byte literal values. The compiler places single-precision floating point constants
in this section. The static linker coalesces these values, removing duplicates,
when building the final product. With some architectures, it’s more efficient for

the compiler to use immediate load instructions rather than adding to this
section.
__TEXT,__literal8 8-byte literal values. The compiler places double-precision floating point
constants in this section. The static linker coalesces these values, removing
duplicates, when building the final product. With some architectures, it’s more
efficient for the compiler to use immediate load instructions rather than adding
to this section.
Table 2 - The sections of a __DATA segment

__DATA,__data Initialized mutable variables, such as writable C strings and data arrays.
__DATA,__la_symbol_ptr Lazy symbol pointers, which are indirect references to functions imported from a
different file.
__DATA,__nl_symbol_ptr Non-lazy symbol pointers, which are indirect references to data items imported
from a different file.
__DATA,__dyld Placeholder section used by the dynamic linker.
__DATA,__const Initialized relocatable constant variables.
__DATA,__mod_init_func Module initialization functions. The C++ compiler places static constructors here.
__DATA,__mod_term_func Module termination functions.
__DATA,__bss Data for uninitialized static variables (for example, static int i;).
__DATA,__common Uninitialized imported symbol definitions (for example, int i;) located in the
global scope (outside of a function declaration).
Table 3 - The sections of a __IMPORT segment

__IMPORT,__jump_table Stubs for calls to functions in a dynamic library.
__IMPORT,__pointers Non-lazy symbol pointers, which are direct references to functions imported from
a different file.
Note
•Mac OS X uses Mach-O and not ELF simply because NEXTSTEP used
Mach-O. Apple had a large enough TODO list that moving to ELF for the
sake of mainstream conformity was not justified. Like NEXTSTEP, Mac OS
X supports "fat" binaries where an executable image contains binaries
for more than one platform (such as PowerPC and x86). Apple's port of
GNU CC allow for fat binaries to be produced (provided assemblers and
libraries are available for each specified architecture).
IDA can actually show the list of recognized sections into the application we are disassembling (calculator). You
can find several of the section names we introduced in previous tables.

Figure 6 – section names of the Calculator native application
Double click on the __cfstring section and you land where the strings are stored. Just for example follow the
first one:
Find its unique x-ref and you land here (the strings are referenced by pointers tables):
And finally you land where the string is referenced:
We meet here for the first time the function _objc_msgSend. This function is the real base of
any objective-C program.

2.2 ESSENTIAL NOTES ON THE OBJECTIVE-C PROGRAMMING MODEL
Like for the MACOSX programming model, also iPhone (which has an OSX system) uses objective-C as its main
programming language for the native applications. All the native applications on the iPhones or iPod Touch are
written using objective-C. It’s then useful to have a little understanding of what it is. I will only report the
things you mostly need to know to reverse the programs at a Primer level (for further reading, see [7,8,9]).
Objective-C, often referred to as ObjC and sometimes as Objective C or Obj-C, is a reflective, object-oriented
programming language which adds Smalltalk-style messaging to C. Today it is used primarily on Mac OS X and
OS X in general [8].
Objective-C is a very "thin" layer on top of C. Objective-C is a strict superset of C. That is, it is possible to
compile any C program with an Objective-C compiler. Objective-C derives its syntax from both C and Smalltalk.
Most of the syntax (including pre-processing, expressions, function declarations, and function calls) is inherited
from C, while the syntax for object-oriented features was created to enable Smalltalk-style message passing.
The core of this structure is the Message routing.
The added syntax is for built-in support of object-oriented programming. The Objective-C model of object-
oriented programming is based on sending messages to objects, similar to the model of Smalltalk. This is unlike
the Simula programming model, which is used by C++ among other programming languages. This distinction is
semantically important. The basic difference is that in Objective-C, one does not call a method; one sends a
message.
An object called obj whose class has a method doSomething implemented is said to respond to the message
doSomething. If we wish to send a doSomething message to obj, we write
[obj doSomething];
whereas in C++ we write
obj.doSomething();
This mechanism allows messages to be sent to an object even if the object is not able to respond to them. This
differs from statically typed languages such as C++ and Java in which all method calls to objects must be
predefined (see also dynamic typing concepts).
Objective-C requires the interface and implementation of a class to be in separately declared code blocks. By
convention, the interface is put in a header file and the implementation in a code file; the header files, suffixed
.h, are similar to C header files.
Objective-C is then an object Oriented language, like C++, having them functions and classes with methods.
Methods are written in a different way from C-style functions. For example, a function in both C and Objective-
C follows this general form:
int do_something(int i) {
return square_root(i);
with int do_something(int) as the prototype. When this is implemented as a method, this becomes:

- (int) do_something:(int) i {
return [self square_root: i];
Objective-C foresees the sending of a message to objects. These might not respond to it: an object has a
number of things it can do with the message, forward, ignore or handle. One of these things could be to
forward the message on to an object which can respond to it. Forwarding can be used to implement certain
design patterns, such as the Observer pattern or the Proxy pattern very simply.
2.3 ESSENTIAL NOTES ON THE REVERSING OF OBJECTIVE-C: THE ROLE OF

OBJC_MSGSEND
As you understood the structure of the objective-C programs, once complied is based on a continuous flow of
messages coming and going among the different classes and methods. This flow is handled by an unique
function, extremely important: _objC_msgSend(). As we said above the objC layer is a very thin layer on top
of C and then this is a normal C function.
The compiler turns the following method call:
[foo doIt];
Into this C-style function call, behind the scenes:
objc_msgSend(foo, @selector(doIt));
The compiler generates calls to the messaging function. You (as programmer) should never call it directly in the
code you write.
What is important here is that the selectors are just the names of the methods. Method
selectors are used to represent the name of a method at runtime. A method selector is a C
11
string that has been registered (or “mapped“) with the Objective-C runtime (in the _cstring or
_cfstring sections). Selectors generated by the compiler are automatically mapped by the
runtime when the class is loaded. You can anyway add new selectors at runtime and retrieve existing selectors
using the function sel_registerName (another interesting point).
Yes, you correctly understood: a string representing the name of the method is given as second argument of
the above call, the first if the address of the object.
The above call becomes:
objc_msgSend(foo, “doIt”);
The return value of the method doIt, is returned by objc_msgSend.
11
This somehow the same thing happening with Delphi programs, the handler of events (message handlers)
can be recognized through strings or labels.

Note that the objc_msgSend is documented only in the Objective-C 2.0 specifications [10] (but [11] too):
objc_msgSend
Sends a message with a simple return value to an instance of a class.
id objc_msgSend(id theReceiver, SEL theSelector, ...)
int objc_msgSend(DWORD theReceiver, DWORD theSelector, ...) using C
Parameters
 theReceiver, A pointer that points to the instance of the class that is to receive the message.
 theSelector, The selector of the method that handles the message.
 ... A variable argument list containing the arguments to the method.
Return Value
The return value of the method.
Discussion
When it encounters a method call, the compiler generates a call to one of the functions objc_msgSend,
objc_msgSend_stret, objc_msgSendSuper, or objc_msgSendSuper_stret. Messages sent to an object’s
superclass (using the super keyword) are sent using objc_msgSendSuper; other messages are sent
using objc_msgSend. Methods that have data structures as return values are sent using
objc_msgSendSuper_stret and objc_msgSend_stret.
Reassuming:
We can draw some interesting conclusions:
1. Since most (not all) message sends go through this single entry point, tracing and logging can be
implemented right here, in one central location.
2. The programmer usually don’t directly use the functions like objc_msgSend, them are placed by the
compiler.
3. The names of the methods are directly translated from the source code to the compiled code and you
can directly see them from IDA. Programmers will need to do some obfuscation of the sources before
compiling
4. Programmers can choose to dynamically add selectors but the usage of the function
sel_registerName can be used to detect these tentatives.
5. The unique exception to the objC_msgSend rule is the variant functions which receive a variable list
of parameters (like printf in C). In these cases the function used is objc_msgSendv.

2.4 WHERE TO GO DEEPER
What practically you can do is to start with the reference to objective-C here:
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html
and the objc runtime header files in /usr/include/objc. You can also download the runtime source if you want
to dig deeper, I did it for curiosity but in 99.99% of the cases you don't need more than the header files.
After you read the above, it becomes easy to understand disassembled code because the "selector" (passed to
every objc_mgSend()) is just a pointer to the string method name.
12
Some more links (mostly for Intel-based Objective-C applications):
 For tracing: http://www.dribin.org/dave/blog/archives/2006/04/22/tracing_objc/
 For debugging: http://developer.apple.com/technotes/tn2004/tn2124.html
 class-dump http://www.codethecode.com/projects/class-dump/
it is a great utility that will dump objective-c headers from the compiled app. This makes it great for
figuring out the structure of programs. For a decent overview check this out.
http://www.phrack.com/issues.html?issue=63&id=16&mode=txt
It applies just as well to x86. GDB might not be as nice as Olly but it has knowledge of objective-c so
once you dump the headers you can set breakpoints based on method names.
 HT Editor (http://hte.sf.net/). A really awesome binary viewer and editor forMach-O files. It allows to
modify also the file headers.
 otool and gdb. Shipped with MacOS X. Once you've learned how to use them, they are great!
Unfortunately as I said iPhone runs on ARM then most of these tools cannot be used (except ht editor), we’ll
have to manually find the way to go.
2.5 CONTINUE TO REVERSE OUR FIRST APPLICATION
In Section 2.1 I left calculator at this point:
LDR R1, =off_9028 ;(this offset points to the string "isEqualToString:”)

STR R5, [R4,#0xC]
MOV R0, R5
LDR R1, [R1]
LDR R2, =cfstr_Testname1
BL _objc_msgSend
TST R0, #0xFF
You should know (especially if you already had a look at [12] and [13] or if you already know ARM assembler)
that the calling convention of the ARM uses the registers as arguments:
12
Thanks to mkfeldman and scknight on woodmann for head-up with these links.

R0=_objc_msgSend(R0,R1,R2,R5,..);
Then the above assembler code is like this:
R0 = _objc_msgSend(R5, “isEqualToString:”, cfstr_Testname1);

if (Cond == -1) goto …
which, using objectiveC, is equal to:
R0 = [R5 isEqualToString:cfstr_Testname1];
if(R0==-1) …
The code is then is just a string comparison between the object hold in R5 (a string object, the object “self”)
and the string “testname1” (you can also find some other examples at [14])
2.6 CFSTRINGS OBJECTS AND NORMAL STRINGS
Being the Calculator one of the simpler applications of the iPhone we cannot say much more. Anyway we
clearly understood how important strings for the objective-C programs are. The strings are not only referenced
directly like I shown before, but are also contained into CFString objects. Simply, if the string is a constant or a
variable created by the programmer into the source code, the compiler insert it into a CFString object; if the
strings are inserted by the compiler during the compilation process (e.g. the parameters of the objC_msgSend)
are instead referenced as normal strings, like it happens with C.
For example the string “CalculatorBackground.png” is stored into a CFString object.
__cstring:00007A4C aCalculatorback DCB "CalculatorBackground.png",0
This string is referenced here:
13
The objects of type CFString (CoreFoundation Strings) are objects containing the string plus the length .
Looking into the program we can easily find that the object stores the file offset of the C string:
file offset of the string

is 7A4C, the length is
18h.
Let see the CFString Hex view:
The string is stored into the CFString as file offset. Simple!
13
You can look here:
http://www.krugle.org/kse/files/svn/svn.sourceforge.net/guliverkli/guliverkli/include/qt/CFString.h

The byte sequence that is characteristic of this object is: 4C 7A 00 00 18 (keep it in mind how we found it).
Following this object we find that it is referenced at the address 00005684, that I directly converted to a C-like
code:
00005684 R0 = _objc_msgSend(“UIImage”, “imageNamed:”, “CalculatorBackground.png”);
And to an objective-C like code:
CFString background= “CalculatorBackground.png”;
[UImage imageNamed:background]
Reassuming:
1. the strings explicitly used by the programmer are stored into CFString objects (like nags, warnings and
so on).
2. the strings added by the compiler are normal C strings not stored into any object (like the strings
passed to objc_msgsend as argument)
3. the CFString objects store the length of the string and the file offset pointer to the string: if the string
is at the offset AABB and is long CC then the object is represented by the sequence BB AA 00 00 CC
4. all these objects are stored into a __cfstring section of the program (it is the standard behavior,
according to Table 1, Table 2, Table 3)
2.7 SELECTORS-HANDLERS MAP
We already introduced that the selectors are actually strings, but the selectors are associated to message
handlers, which are in turn stored into the application into association arrays. An example is shown here:

Figure 7
The map of Figure 7 shows the association among strings and functions, which is what we are interested to
exploit. This structure is perfect for inline patching of applications, injecting code and changing the general
behaviour of a program (for example adding an extra handler before the real one, like rootkits are used to do).
For example we can see from Figure 7 that the selectors “_button0Press”, “_button1Press” and
“_button2Press”are associated to the routines sub_5174, sub_5100 and sub_5128. Each of these functions in
turn just sends out the event “_digitPress” with a different parameter each (Figure 8).
Figure 8 – handlers of selectors “_button0Press”, “_button1Press” and “_button2Press”
Further looking into the selector-handler map you can find that the “_digitPress:” selector is associated to the
handler sub_4CF0. A good exercise is to completely understand how the Calculator application works and
rebuild the messages flow...

Reassuming:
1. The selectors are associated to message handlers
2. The associations are stored into a selector-handler array which is fundamental to find the events
handlers
3. It is possible to inject code into these arrays to alter the messages flow inserting extra handler, for
example for patching the application or to do some sort of inline patch. It is clearly discussed here, for
the big Mac: http://www.felinemenace.org/~nemo/slides/mach-o_infection.ppt
4. This particular table is used for a well known infection method called “Method Swizzling”. Indeed it’s
an objective-C feature, but can be abused:
The Objective-C runtime lets you modify the mappings from a selector (method name) to an
implementation (the method code itself). This allows you to "patch" methods in code you don't have
the source to (AppKit, FoundationKit, etc). Unlike creating a category method with the same name as
the original method (effectively replacing the original method), MethodSwizzling lets your
replacement method make use of the original method, almost like subclassing.
5. This table is usually stored into the __inst_meth section

3 UNLOCKING FOR REAL THE IPHONE/IPOD TOUCH
Now it is time to unlock the iPhone or the iPod Touch (I did all with an iPod Touch) for real. With the iPod
Touch it is simpler because you only have to unlock the operative system and not to jailbreak the mobile
connectivity carrier in order to support your, but the process is not any different. My iPod Touch was updated
to firmware 1.1.4 (at time of writing is the latest). The process as I said consists of some different steps:
1. Downgrade to a firmware for which there’s an exploit (usually 1.1)
2. Use one of the known exploits (ram disk, tiff pictures and so) to inject some code at the system’s
level. Usually the code rewrite the boot loader of the system extending it so as it will allow a
“customized” upgrading process
3. Upgrade the system from the “compromised” one, one release after the other, up to the latest one
(1.1.4)
4. Jailbreak the system removing the lock to a single telecom provider. It’s just a system patch you can
do because you got control over the system, you will see that once you unlock the OS the control you
get is total and complete.
Fortunately these steps have been automated by some famous tools like
ZiPhone (which is opensource too) or iPlus 2.0b. This last works only for
firmware 1.1.4 but with a single button press does all the above steps and
gets you a completely unlocked and working iPhone or iPod Touch (all
you need is to run “iPlus –u” form a Dos window). It will downgrade the
bootloader, unlock, jailbreak and activate the iPhone. And even better, it
will also install the most important and common packages as well as
several fixes, with a custom payload for installing other packages.
14
Bootloader downgrading uses BL 3.9FakeBlank, so it is fully reversible .
I will not go further in details into this process because it’s not easy to
explain all the steps as I would, anyway you can find a lot of places where
to find explanations. Consider it as an excellent example of applied
reversing, well built software and a really working community.
What I am interested to have is an unlocked device where I can install my

applications or better start reversing the system or the applications.
What you will have then is a system where you can install native applications, some already there:
 Latest Installer: the program used to install programs from the web, through a standard web format. This
is a native application used to ease the installation process of new applications (see Figure 9).
 Latest Community Sources: latest online database of installable applications, you can extend it or just
browse.
 Pre-Installed Packages:
14
You look here: http://www.hackint0sh.org/forum/showthread.php?t=34155 or
http://forum.gsmhosting.com/vbb/showthread.php?t=514129
Unlocking for real the iPhone/iPod Touch 27

o BSD Subsystem: basic BSD Linux subsystem, useful for porting of Unix-like applications
o OpenSSH
o Term VT-100
These will come handy, especially the installer and the OpenSSH.
The underlying system is mainly a FreeBSD system where all the process are running as root, all the programs
are built using objective-C, the common MACOSX programming interfaces like COCOA are still present. Porting
of existing software like OpenSSH was simplified by all these elements.
Figure 9 – How the installer (left) and the community source (right) looks like.

3.1 SCREENSHOTS
The first application you need to install on your own (or that I needed to install) is a screenshot application.
There are two available:
 ScreeShoot is freeware and to install it you have to add this repository to the community sources
installs: iphone.robota.nl
 Capture is freeware too, you can install it using this link:

http://www.hackthatifone.com/forum/index.php?topic=77.0/
Figure 10 – ScreenShot and Capture utilities
3.2 CONNECT YOUR PC TO THE DEVICE
The next step is to connect to the device. There are several options..
 Through Secure FTP. You must install on the device the OpenSSH subsystem (but you should already
have it) and then do an ftps:// (ftp secure) connection the device. The device must be connected to
your same Wi-Fi of course and its IP must be visible from your PC. The login and password to be used
are always the same for all the Apple devices (“root/alpine” as username/password). You can use any
of the ftps clients for windows (for example is good WinSCP, http://winscp.net/eng/index.php), but
since I prefer using Total Commander I use the ftps plugin for this file manager:
On the PC
15
1. Install SFTP extension for Total Commander (available on the total commander’ site too)
2. create a profile to the IP of the device (on the WAN) using root/alpine as
username/password
15
Or directly here: http://developer.berlios.de/projects/sftp4tc/

3. Total Commander connects to the root home folder (as it happens with any unix system) and
you can go up to the root. When connecting for the first time it takes almost 45 seconds to
generate the keys pair.
4. Now you can fully manage file, rights and folders (also the file rights in the unix-way, with
separate rights for user, group and world).
On the device
1. install BSD Subsystem under system using installer
2. install OpenSSH under System using installer
3. Reboot it.
 Through iTunes hacked USB protocol. This other connection method is easier and is fine for those not
having a Wi-Fi, but has also some limitations, because you cannot for example handle the file rights.
Anyway I again suggest using Total Commander, but with a different plugin which uses the same
16 17
protocol iTunes uses to talk with the device (it has been reversed ). The plugin is called T-PoT and is
a plug-in for Total Commander allowing browsing the Apple iPod Touch and iPhone contents via USB.
What it allows is mainly to browse the unlocked iPhone/iPod like any other network file system.
Among the other things it can fix the modified PNG iPod file format automatically so as you can see
the images on the PC, it has too a stand-alone Windows program to fix the iPod PNG images and
convert them to true PNG files you can see with any viewer/graphics editor.
18
 Using iBrickr . This is a Windows tool that also offers the possibility to browse the device’s file
system. It comes handy to those of you not using Total Commander at all. Anyway what is nice with
this program is that it also allows installing programs on the device without having to use the installer,
directly launching the pxl files (look http://iphone.nullriver.com/beta/ section “How to make a
package - Draft documentation”, but you can consider it as an xml based installer). This will come
handy if you plan to release patched installer for some applications and want to do some tests before.
16
The iTunes API allows to access the iPod file system by the USB; unfortunately this API isn't publicly
documented yet. For the moment, some features are either not part of the API or were not discovered so far.
17
http://code.google.com/p/t-pot/
18
iBricks home page, http://cre.ations.net/creation/ibrickr

Figure 11 - iBricks main interface
Note that I am a Windows user then life for us is not so easy when using iPhone or iPod, the reason is simple
the two systems on a MAC and on the iPhone/iPod are two sides of the same coin, two version of the OSX
system. As a matter of facts it’s much easier for a MAC to talk with these gadgets. For example the equivalent
19 20
of iBrickr is iFuntastic or Breezy which works fine.
Just to finish this section, as I told guides are all around you, like the one at [15].
19
iFuntastic, http://bitsplit-enterprises.com/iFuntastic/
20
Breezy home page, http://code.google.com/p/pxl/

4 REVERSING SOME APPLICATIONS
4.1 GO DOWN WITH THE FIRST APPLICATION: ACCELEROLOG
21
AcceleroLog is the first application we will approach. It is relatively useless but at the same
time has some nags which we will remove, just to show how it can be done. We will not anyway
completely break it, just because it’s a free application.
What it does is to show the accelerometers graphs in real time and allows storing them into a file (see Figure
12).
After installation on the device (using installer or after addition of the robota community source link, see
above) you will find the following folder \Applications\AcceleroLog.app, inside the executable file is
“AcceleroLog”
Figure 12 - AcceleroLog main view.
Just run it and you will see two nags:
21
AcceleroLog, http://www.robota.nl/products/iPhone%20AcceleroLog.html
Reversing some Applications 32

"WE TRUST YOU DONATE! “We trust you donate
The green, red and blue graphs represent the Would you like to donate now?"
accelerometer's XYZ.
Move your iPhone to see the action.
Use Settings to change the sample rate.
Collected data contains timing information."
4.1.1 ADJUST THE APPLICATION SO AS IDA CAN HANDLE IT CORRECTLY
Ok, it’s enough, time to go! Open with IDA the file, wait, search the strings in the strings view and find where
are referenced on the code:
Fine, we found the strings and we can think about the code that handles them, but... but there’s a problem: if
you press X to find the references to the two strings you will not find anything. Some strings are referenced
but the only important ones are not instead. What happens then? Why IDA is not able to find references to
these strings?
We are using now the conclusions we came analyzing the Calculator app, in section 2.6.
1. The string are explicitly inserted by the programmer and not by the compilation process
2. The strings are stored into a CFString object which IDA cannot identify
3. The strings are as follows:
a. the first is at file offset 7BF0 and is long CF,
b. the second is at file offset 7D00 and is long 13,
c. the third is at file offset 7D20 and is long 1D
4. The byte sequence we must search for are respectively:
a. F0 7B 00 00 CF
b. 00 7D 00 00 13
c. 20 7D 00 00 1D
Let see where these strings are stored: go into the hex-view of the program and use the search binary
function, then search for all the occurrences of these patterns: the first one is found here:
Figure 13
Figure 13 reports the finding. The logical conclusions are the followings:
1. the value is supposed to be a CFString object and the memory pattern corresponds
2. the object is stored into a __const section instead of a __cfstring like it should be
3. The executable uses a non standard method to store cfstrings, placing then into the wrong section
What we will do is to change the name of the section using a Hex-Editor to the name the IDA Math-O loader
(and the standard) wants: see Figure 14 and Figure 15.
Figure 14 – original hex-view of the AcceleroLog sections’ names

Figure 15 - modded hex-view of the AcceleroLog sections’ names
Save the modified file as AcceleroLog_1 and open it with another istance of IDA. Go to the address we found
before (0x92B0) and you will magically see the following CFString objects:
The magic is now really complete, the CFString is correctly recognized and the references to the object too.
Figure 16 shows that the code is now as it should be!
Figure 16 – place in the code where the first nag is created.
Figure 16 reports just the portion of the function where the string is referenced, the whole function is named
as __2B__5B_AcceleroLogApp_20_singleton_5D_. The question is: how can IDA give a name to this
function?

The answer is simple: the message, handler, selectors, events associations are stored into an association map
into the executable. This table is clearly found using the cross-references of the strings. In this case it is stored
here:
The “askDonate” and the “alert:” selectors have handlers which are stored here:
Reassuming:
1. The applications built using the unofficial SDK stores the CFStrings into a __const section instead of
22
the standard __cfstring . This doesn’t imply anything for the device running the application, but the
IDA mach-o loader is then not able to correctly find the CFString objects, the reversing is not easy
then.
2. The association selectors-message-handler is stored into some maps which can be found into the
program.
3. If we change the __const section name to the standard __cfstring using an hex-editor IDA will be able
to correctly find all the things we need (see Figure 17) 
22
All the applications I saw have this characteristic

Figure 17 – section names of AcceleroLog application
4.1.2 PATCHING THE APPLICATION
The first half of the code shown in Figure 16 can be decompiled manually or using Desquirr (I explained it in
[12]). The result is the following:
ASM code:
__text:000044A8 LDR R0, [R7,#-0x1C] ; ///////////// start here
__text:000044AC STR R0, [R7,#-0x114]
__text:000044B0 LDR R3, =loc_6CA0
__text:000044B4 LDR R1, [PC,R3] ; "alert:"
__text:000044B8 LDR R3, =__2D__5B_AcceleroLogApp_20_initDefaults_5D_
__text:000044BC ADD R2, PC, R3 ; "WE TRUST YOU DONATE!
__text:000044BC ; The green, red and blue graphs represent
the accelerometer's XYZ.
__text:000044BC ; Move your iPhone to see the action.
__text:000044BC ; Use Settings to change the sample rate.
__text:000044BC ; Collected data contains timing
information."

__text:000044C0 BL _objc_msgSend
Desquirr result:
_objc_msgSend(R0, “alert:”, "WE TRUST YOU DONATE!...",

__2D__5B_AcceleroLogApp_20_initDefaults_5D_);
The “alert:” method receives also a function as parameter. This becomes evident if you try to do this
experiment (I did it): if you null this call the program won’t anymore draw the graphs. The function
__2D__5B_AcceleroLogApp_20_initDefaults_5D init the program graphical routine.
We will patch it then just to have a different message, skipping the “WE TRUST” part.
The string "WE TRUST..." is here:
__cstring:00007BF0 57 45 20 54+aWeTrustYouDona DCB "WE TRUST YOU DONATE!",0xA
I want to skip the first row, then the new beginning is at offset 7C05. The only thing to do is then to adjust the
offset in the CFString object:
__cfstring:000092A8 E8 FA 00 00+cfstr_WeTrustYouDona __CFString

<___CFConstantStringClassReference, 0x7C8, aWeTrustYouDona,\
__cfstring:000092A8 C8 07 00 00+
__cfstring:000092A8 05 7C 00 00+ 0xCF> ; The green, red
and blue graphs represent the accelerometer's XYZ.
__cfstring:000092A8 ; Move your
iPhone to see the action.
__cfstring:000092A8 ; Use Settings
to change the sample rate.
__cfstring:000092A8 ; Collected data
contains timing information."
Ok I am now able to go on to the second nag.
It is simple. Fortunately as we seen the parameter of the call functions in the ARM architecture are not stack
based, but rather registry based. This means that to skip a call it enough to skip the real call to the function
without much worries of the parameters. The program will not hang.
The patch is the simple this time:
__text:000044D4 4A 12 00 EB BL _objc_msgSend ; NOP = 00 00 A0 E1

Note
•Do not trust Desquirr results too much when working with
objectiveC applications. The plugin is not able to correctly
resolve the strings references, and the compiled code is
somehow confusing.

4.1.3 HOW TO CALCULATE THE OPCODE OF A BRANCH IN ASM
I previously mentioned about the first nag at __text:000044C0 which is used to display the remainder nag
dialog, but also to call the init function which inits the drawing system.
If you elaborate the first half of code shown in Figure 16 using Desquirr, you will get this code:
000044a8 R0 = * (R7 + 0xffffffe4);

000044ac * (R7 + 0xfffffeec) = R0;
000044b8 R3 = __2D__5B_AcceleroLogApp_20_initDefaults_5D_;
000044c0 _objc_msgSend(R0, * (PC + __2D__5B_TestView_20_tick_3A__5D_[316]), PC +
R3, R3);
This piece of code is equivalent to the following objc_msgsend call:
_objc_msgSend(receiver, selector, "WE TRUST YOU DONATE!...",

__2D__5B_AcceleroLogApp_20_initDefaults_5D_);
Where the selector is taken from an array of elements: __2D__5B_TestView_20_tick_3A__5D_[316] and

the two arguments are the following:
arg1="WE TRUST YOU DONATE!..."

arg2= __2D__5B_AcceleroLogApp_20_initDefaults_5D_
The second argument is the real problem patching this nag call, because if you NOP the call to objc_msgsend
the function used as arg2 is not called then the program won’t work correctly.
What I will do is then to switch the call to objc_msgSend() with a call to the function
__2D__5B_AcceleroLogApp_20_initDefaults_5D_.
The ARM assembler doesn’t have a real CALL among its instructions, rather only branches of different flavors
(conditions). You can then use the instruction BL (Branch Link) that is a branch without conditions (always
done), it can be used to emulate a call to a function (remember all the parameters are on registry, not on
stack).
What I want to have is then an instruction like the following:
BL __2D__5B_AcceleroLogApp_20_initDefaults_5D_
The new code should then be the following:
__text:000044A8 LDR R0, [R7,#-0x1C] ; ////////// start here

__text:000044AC STR R0, [R7,#-0x114]
__text:000044B0 LDR R3, =loc_6CA0
__text:000044B4 LDR R1, [PC,R3] ; "alert:"
__text:000044B8 BL __2D__5B_AcceleroLogApp_20_initDefaults_5D_
The problem is now, how to calculate the destination address of the branch, we do not have any assembler
like OllyDbg to use and then we must do everything manually, without any help. Interesting, isn’t?
Reading the specification manual we can draw this simple formula, which you can use onward for calculation
of the destination address of a jump or a call.

 InstrAfterBRANCHaddr = is the address of the instruction just after the instruction BL we are coding
(actually being 4 bytes the constant dimension of any ARM assembler bytecode, it is equal to the
address at which we are assembling + 4: BL_address + 4)
 JmpDestaddr = destination address of the jump or call
Given that all the instructions of any ARM processors are expressed using 4 bytes, you have this resulting
formula:
jump_opcode = (JmpDestaddr - InstrAfterBRANCHaddr)/4 - 1
-1 is present in the formula because the dimension of the BL opcode without the destination address is 1 byte,
and must not be considered in the jump address value.
Returning to the example of the application we are considering, applying the rule we have:
 JmpDestaddr = __2D__5B_AcceleroLogApp_20_initDefaults_5D_ = 4DE4
 InstrAfterBRANCHaddr = 44BC
then: jump_opcode = (4DE4-44BC)/4 -1 = 0249
The value 0249 is the value of the jump opcode, but must be converted using LSB and used as argument of the
BL instruction (opcode of BL is EB):
__text:000044B8 49 02 00 EB BL
__2D__5B_AcceleroLogApp_20_initDefaults_5D_
The almost final patch is then the following one (with opcodes too):
__text:000044A8 1C 00 17 E5 LDR R0, [R7,#-0x1C] ; ////////// start here

__text:000044AC 14 01 07 E5 STR R0, [R7,#-0x114]
__text:000044B0 F4 30 9F E5 LDR R3, =loc_6CA0
__text:000044B4 03 10 9F E7 LDR R1, [PC,R3] ; "alert:"
__text:000044B8 49 02 00 EB BL
__2D__5B_AcceleroLogApp_20_initDefaults_5D_
__text:000044BC 00 00 A0 E1 NOP
__text:000044C0 00 00 A0 E1 NOP
__text:000044C4 00 00 A0 E1 NOP
__text:000044C8 00 00 A0 E1 NOP
__text:000044CC 00 00 A0 E1 NOP
__text:000044D0 00 00 A0 E1 NOP
__text:000044D4 00 00 A0 E1 NOP
This, with some other refinements, adjusts the problem of the first nag and of the initialization done by that
call.

Reassuming:
Here are some important notes:
 Using branches to skip portions of code is always a good think, use the above formula to calculate the
opcodes of these jumps
 Given that objc_msgsend calls doesn’t involve parameters on stack (all are given through registry), a
very fast method to skip a call is to find the corresponding selector (see about the selectors-handlers
array) and comment the call to objc_msgsend. This avoid calling the handler and do not corrupt any
stack or the program status.
•all parameters on ARM asm are on registy

•the ARM assembler doesn't have the instruction CALL, just branches
Note
with different conditions. The branch always done (like calls) is BL,
which has no conditions set.
•The opcode of BL is EB (can be calculated using ARM specifications and I
already explained it in [13])
•The destination address of the BL is relative and can be calculated using
a simple formula.
•You generally speaking must pay attention to arguments of
objc_msgsend
•Desquirr helps speeding up things at the beginning. It gives a fast
decompilation which helps you out with ARM assembler.
•Fast patching can be done just NOPping out the call to objc_msgsend
wich is using the selector associated to the function you want to skip.
4.2 GOING ON WITH THE SECOND APPLICATION: SHOWTIME
This second application is a video recording suite which is quite useful; it’s a real retail application with a
registration schema and some limitations for unregistered users. Have no protection, no obfuscations and it’s
ideal then for steps two of this document.
Download link: http://www.polarbearfarm.com/example/ShowTime1_11b.zip
Limitation: recording of only 5 seconds, after which asks for registration and stops recording.
Notes:
This application changes frequently, so I will only stick to the version 1.1b, with some notes on version
1.2b.
The saved video files can be taken from this folder: \private\var\mobile\Media\PBFVideo\

It's, like all the iPhone native programs an objective C program. You can easily disassemble it using
IDA 5.2, selecting ARM processor.
To correctly resolve the references to the cfstring objects IDA requires the change of the sections
name from “__const” to “__cfstring”, like discussed in Section 4.1
Figure 18 – After 5 seconds a dialog appear, asking for a registration number.
4.2.1 VERSION 1.1B
Now the program has been updated then what I am reporting here doesn’t “exactly” apply anymore...
1. Change __const to __cfstring like done for all the other applications.
2. Search for string "You have entered an incorrect license key." you land at function
___LicenseTextView_webView_shouldInsertText_replacingDOMRange_givenAction__:
The string “Error:...” is referenced at:
And the landing part of code is the following one:
The branch that is responsible of the badboy vs goodboy paths is:

Which is:
LDR R0, [R7,#-0x10]

STR R0, [R7,#-0x40]
LDR R3, =(off_13100 - 0x3258)
LDR R1, [PC,R3] ; "text"
BL _objc_msgSend
STR R0, [R7,#-0x44]
LDR R3, =(off_130B4 - 0x3268)
LDR R1, [PC,R3] ; "isEqualToString:"
LDR R3, =_.str42
ADD R2, PC, R3 ; "PBF07-0110-8369-6582"
BL _objc_msgSend
TST R0, #0xFF
BEQ loc_32B4 ; branch to badboy if not equal to serial above.. NOP it
The solution should be to change the branch to loc_32B4 into a NOP, but it can be easily understood that the
serial check is just a test against a fixed string. The only serial accepted is "PBF07-0110-8369-6582" which is an
old blacklisted serial (note that there are some checks above you should remove too).
This patch removes the check forcing the registration dialog to accept any serial you enter. Unfortunately
when you go testing the so patched application on the device you’ll realize that there is also a start-up check
you should skip too. To complete the patch do this:
__text:0000721C A0 00 00 1A BNE loc_74A4 ; patch to a normal Branch

__text:000074E4 1E 00 00 0A BEQ loc_7564 ; NOP it
This also skips the initial dialog and overrides the limit, no real need to enter a fake serial number anymore.
The power of selectors come evident if you look at the following snapshot: can you realize how I found these
two branches? The first one (0000721C) is just above the second one (000074E4) that is clearly associated to
the initial check of the licence.

By the way a better look at the application clearly shows that near loc_36F there is an interesting instruction
which moves into R2 the value #0 or#1 setting or not the recording limit:
__text:000036B8 01 20 A0 E3 MOV R2, #1 ;Set to MOV R2, #0
Remember that the selectors-handlers array is really important when reversing these applications, like shown
in underneath picture all the relevant information are there, clearly visible.

Note
•"Functions" in Cocoa/Objective-C are a little different then C functions. Actually they
aren’t even called functions, they are called "Methods". Objective C calls these
functions, and then finally call the real methods. The calls to objc_msgSend and its
variants (99% of the total are just objc_msgsend) are really important.
•Obj-C ARM programs stored using Mach-O file format are generated by Apple’s
development tools. The result is an easy-to-analyze executable, in general it’s easy to
understand the code flow.
•To learn the basic conventions the best option is to start to reverse your own (simple)
programs, by comparing the source with the disassembly, you’ll soon understand how
things work.
•A good tutorial is at: http://george.zjlotto.com/index.php/2007/12/10/a-better-carrier-
logo-patch-for-springboard/
4.3 GOING ON WITH THE THIRD APPLICATION: ISIM
iSIM is a SIM card contacts copier. It can copy SIM contacts to iPhone and vice versa but with a limitation, you
cannot copy all contacts in one go. If you try it says “AVAILABLE IN REGISTERED VERSION ONLY” (Figure 19).
The interesting things of this program are a better registration routine (IMEI based), which also stores the
registration status somewhere in the system and an online check of the registration number. The patch is a
little more complex.
Figure 19 – iSIM welcome screen, the premium features are clearly shown.

4.3.1 FIND THE CORRECT INSTALLER URL THROUGH THE .PLIST FILE
The interesting thing is that we must also reverse a bit the installation procedure. As I said the .plist files are
installation xml files. The distribution site is available at this URL:
Dowload URL for iPhone: http://www.makayama.com/iphonesim.html
This page reports a tinyurl which you can use to directly download and install the application on the device.
http://tinyurl.com/3544mp
the URL actually redirects to this one http://www.makayama.net/r.plist
the r.plist file is an xml containing the final real URLs of all the programs distributed by makayama (see Section
23
2) and is one of the so called community sources which the Installer application handles .
http://www.makayama.net/iphone/iSIM.1.07.zip
4.3.2 REVERSING THE TARGET
These are the useful strings we find into the application:
__cstring:00051B40 _.str37 DCB "Success",0

__cstring:00051B48 ALIGN 0x10
__cstring:00051B50 _.str38 DCB "Thank you for purchasing iSIM application. All "
__cstring:00051B50 DCB "features are unlocked now.",0
__cstring:00051B9A ALIGN 0x10
__cstring:00051BA0 _.str39 DCB "Error",0
__cstring:00051BA6 ALIGN 0x10
__cstring:00051BB0 _.str40 DCB "Please check activation key and try again. “
__cstring:00051BB0 DCB "Activation requires n"
__cstring:00051BB0 DCB "etworking.",0
__cstring:00050920 aBtnorder DCB "btnOrder:",0 ; DATA XREF:
___iSIMApplication_showView_+78Cr
These strings are stored into CFString objects here:
As I said the serial number is checked online. The activation routine sends to a specific URL the data collected:
http://www.makayama.net/isim/%@.html
You can easily find where the online check is performed looking at the event “btnOrder:” and its handler:
23
The standard is specified by the NullRiver installer

Figure 20 - __iSIMApplication_btnOrder__ function
The function opens a connection sending an “openURL:” command with the url
http://www.imatrix.lt/app/iSIM.aspx concatenated with the following parametric string: %@?DEVICE=%@
Looking better into the selectors-handlers map you can see that one of the events is the most interesting:
0005D750 DCD aActivate, aC12048, ___iSIMApplication_Activate__ ; "c12@0:4@8"
The function ___iSIMApplication_Activate__ promises to be a good place where to patch.
4.3.3 CHANGING THE CLASS OF A SECTION FROM DATA TO CODE
There is a problem: IDA considers this function as _data and not _code ( ):
This is a problem only if you want to use the graphic view of the function, otherwise not.

Note
•You can select the function and then press ‘P’ to define the
selected code as a function, but the result IDA gives is wrong,
the function graph is not correctly drawn. The correct
method is the following, which also give us the possibility to
learn a little about Mach-O sections.
The function we want to analyze belongs to the section shown below:
If you look at it you can see that the problem is the “Class” of the section, which is DATA instead of CODE.
Editing the section from IDA doesn’t change things, because the Mach-O loader reads the section information
from the application headers only at the beginning, and then we need to change the executable using an Hex-
Editor.
We want to change the application header to transform this part of into a “CODE” Class.
First of all I must tell you how the sections are stored in the application file. Using the specification of [6] we
find the section “section” describing the structure of a section (contained into a segment):
struct section
{
char sectname[16]; //this
char segname[16]; //this
uint32_t addr; //this
uint32_t size; //this
uint32_t offset; //this
uint32_t align; //this
uint32_t reloff; //this
uint32_t nreloc; //this
uint32_t flags; //this
uint32_t reserved1; //this
uint32_t reserved2; //this
};
Then the structure looks like this in the hex-editor (I report also the first _text section which has the correct
Class):
5F5F 7465 7874 0000 0000 0000 0000 0000 5F5F 5445 5854 0000 0000 0000 0000 0000 2021 0000 90DC
0400 2011 0000 0400 0000 0000 0000 0000 0000 0000 0080 0000 0000 0000 0000
__text..........__TEXT.......... ! ..........................

The initial address of the section is 00002120 and the final address is 00002120+0004DC90=0004FDB0
5F5F 6373 7472 696E 6700 0000 0000 0000 5F5F 5445 5854 0000 0000 0000 0000 0000 B0FD 0400 3076
0000 B0ED 0400 0400 0000 0000 0000 0000 0000 0200 0000 0000 0000 0000 0000
__cfstring......__TEXT..............0v..................................
The document [6] describes the flags field as following:
An integer divided into two parts. The least significant 8 bits contain the section type, while the most
significant 24 bits contain a set of flags that specify other attributes of the section. These types and flags
are primarily used by the static linker and file analysis tools, such as otool, to determine how to
modify or display the section.
We are then interested in modifying only the section type from DATA to CODE; then the least significant 8 bits.
Modify the least significant 8 bits using the LSB notation means to modify the leftmost 8 bits. Consider anyway
that the remaining 24 bits must be set accordingly. The second example above has a new flags field value:
From 0200 0000 to 0000 0080.
Do this change using an hex-editor and write the result on a new file. Open it with IDA and you get the
following result:
Note: The same operation can also be done using the HT Editor (see Section Where to go deeper
Now we can continue with the analysis of the function function ___iSIMApplication_Activate__ which
is now a real function into a CODE segment.
Now you can select all the function from the end to the beginning and then press ‘P’ to transform this function
into a piece of code which is then transformed by IDA into a graph.
Now we have a really correct graph of the function which is responsible of activating the program. What we
have to do is just to force it to always return the goodboy message and skip the online activation. Quite simple
once you get there then I will only report the modifications without further comments.
__text:0000523C BEQ loc_5290 ; transform to an unconditional Branch
__text:00005314 BEQ loc_533C ; NOP it
__text:00005338 BNE loc_53F8 ; transform to an unconditional Branch
..and remember the online check..
The interesting is that you can even overwrite the patched application again with the original application, still
being registered.

Figure 21 – ZiPhone can also change the IMEI
Note: Having full control over the system means also you can change vital parts of the device such as for
example the IMEI (Figure 21).
4.4 GOING ON WITH THE FOURTH APPLICATION: CAMERAPRO
We are rapidly learning all the required things to patch normal (not obfuscated) applications, to show you how
well we are preceding this is a fast application that resembles what we just done with the previous one. I will
skip a lot of descriptions assuming you should have understood them.
4.4.1 FIND THE CORRECT INSTALLER URL THROUGH THE .PLIST FILE
Like already done with iSIM we must reverse a bit the installation procedure. As I said the .plist files are
installation xml files. The distribution site is available at this URL:
Dowload url for iPhone: http://www.makayama.com/iphonecamera.html
This page reports a tinyurl which you can use to directly download and install the applications on the device.
http://tinyurl.com/3544mp the url actually redirects to this one http://www.makayama.net/r.plist
The final real URL is then: http://www.imatrix.lt/makayama/CameraPro.1.11.zip

4.4.2 REVERSING THE TARGET
If you change the __const section name with __cfstring all the references to the strings are correctly
resolved by IDA.
The patch is, exactly like already shown with iSIM (the deepest registration routine is the same for all the
targets of this company), the following one:
__text:000036E0 2E 00 00 1A BNE GoodBoyHandler ; becomes normal Branch

__text:0000360C 5E 00 00 1A BNE loc_378C ; NOP this Branch
__text:00003624 2E 00 00 1A BNE BadBoyHandler ; NOP this Branch
__text:00003634 2A 00 00 EA B BadBoyHandler ; NOP This Branch
__text:000036BC 08 00 00 0A BEQ BadBoyHandler ; NOP this Branch
After registering with any serial number you will see that the application remains registered because it has
stored the registration details somewhere.
4.5 GOING ON WITH THE FIFTH APPLICATION: POCKETMONEY
This is another really simple application, at this stage of the document. I did this section very concise to
24
underline how much you know now .
1. download it from here:
http://www.catamount.com/packages/iPhone/PocketMoney/PocketMoney_10.zip
I used the same .plist “trick” described before.
2. Patch __const sections renaming them to _cfstring
3. Find the string "Your registration code was accepted. Thank you. ", and you land at the end at
function __2D__5B_RegistrationView_20_keyboardInputChanged_3A__5D_
4. This function is really simple, a classic two way good/bad boy function.
The key point is the following one:
BL _ValidRegistration ; return 0 or 1 into R0. Must return 1 if OK

STRB R0, [R7,#-0x81] ; Store byte from R0 to address at [R7 -0x81]
CMP R0, #0
BEQ loc_15DA8 ; if R0=1 then registration is OK
Clearly the R0 is set by the function I renamed as _ValidRegistration. If you go inside, the only
point where R0 is set to a value not 0 (actually R3 which is later moved to R0), is the following one:
loc_17154
MOV R3, #0 ; patch to MOV R3, #1
STR R3, [R7,#-0x24]
STR R3, [R7,#-0xC] ; the value [R7,#-0xC] is later moved to R0
24
The program has already been update then this patch doesn’t apply anymore. That’s fine, according to our
own rules..

Figure 22 – Original and patched registration screens
4.6 GOING ON WITH THE SIXTH APPLICATION: SOFTICK SOLITAIRE
This is the first roughly protected application I found. The events selector strings are obfuscated; selectors are
not recalling their scope and the only strings clearly visible are those inserted by the compilation process (not
stored into CFString objects then and not directly controlled by the programmer). The registration routine is on
the other hand also professional, being the registration number composed by fields. The limitation is 21 days
of free usage. The authors clearly used a source obfuscator which scrambled the selectors of the program; the
selectors-handlers array doesn’t give many hints.
A general call to objc_msgsend looks like this:
And the selector-handler array looks quite cryptic:

As you can see most of the selectors are replaced with random strings. The problem is that this process cannot
be undone.
4.6.1 APPROACHING THE APPLICATION
The main screen is shown in Figure 23.
Figure 23 – Main Screen of Solitaire
Luckily the obfuscation process cannot obfuscate also the strings returned to the users, and then we can find
the following interesting strings:
The problems is that no one of them is referenced (according to IDA) in the code! What a pity.

4.6.2 MANUALLY FINDING THE REFERENCE TO A GIVEN STRING
Finding the references to a string is not that easy, if you do it backward, starting from the address of the string,
because the references are relative, the PC is involved.
For example this piece of code:
__text:00005180 LDR R2, =(off_1D1A4 - 0x518C)

__text:00005184 LDR R1, [PC,R2] ; "objectForKey:"
__text:00005188 LDR R2, =loc_15704
__text:0000518C ADD R2, PC, R2 ; "PurchaseURL"
__text:00005190 MOV R0, R3
__text:00005194 BL _objc_msgSend
And especially this:
__text:00005180 LDR R2, =(off_1D1A4 - 0x518C)

__text:00005184 LDR R1, [PC,R2] ; "objectForKey:"
If you noticed the second instruction shows a reference to a string as a comment, instead of being part of the
instruction. This happens because in ARM the PC (program counter) is equal to the address of instruction plus
double the current instruction size (i.e. plus 8 in ARM mode and plus 4 in Thumb mode).
The address of the second LDR is 5184, the PC value becomes then 5184+8=518C.
The code at address 5184 is thus equal to this:
R1 = [PC+R2]  R1 = [0x518C + 0x1D1A4 - 0x518C]  R1=[0x1D1A4]
If you go to the address 0x1D1A4, you will likely see there an offset to the string "objectForKey:", which is
displayed in the comment. IDA just tried to be helpful showing you the actual final value loaded into R1 rather
than the raw intermediate delta loaded into R2.
If IDA miss some reference it’s not that easy to find the place where the string is referenced.
We cannot directly approach the registration routine, because we are not able to find the references to the
goodboy/badboy strings. We can anyway find the routine indirectly, using the string “Register”, which is one of
the two buttons of the registration dialog. This string is references into the function sub_41CC which I
renamed with “EnterRegistrationNumDlg”.

Figure 24 – Where Register and Back are referenced
This function is responsible of drawing the registration dialog and then, assuming that a registered program
25
won’t ask me to register, you must concentrate on the conditions driving this program to the function.
The EnterRegistrationNumDlg function just creates the two buttons (see Figure 23) and repeats 4 times the
same loop, in order to insert the four parts of any registration number.
This function is associated to a selector in the selectors-handlers map:
__inst_meth:0001DC20 DCD EnterRegistrationMsg, aV804,

EnterRegistrationNum ; "v8@0:4"
I just renamed the string as “EnterRegistrationMsg”:
__cstring:000177D0 EnterRegistrationMsg DCB "bTitx7RaM",0 ; DATA XREF:

sub_5558+124r
__cstring:000177D0 ; sub_BAB0+3FCr ...
Clearly this selector is obfuscated.
We can do now is to follow the references of this selector to find where the registration dialog is invoked and
understand from these places which are the conditions why such a dialog is hit and modify the program.
To proceed you must understand that this even is issues when the application wants to create the registration
dialog. Then problem is that the application shouldn’t will to do such thing, then to patch the application you
must instead navigate through the calling functions, or better the functions invoking the selector we identified.
25
The piece of code of Figure 24 implements what described at http://www.tuaw.com/2007/08/16/iphone-
coding-working-with-the-navigation-bar/

Reassuming:
There are some important aspects you must understand:
 objective-C programs do very few direct calls (in the C way), most of the calls are indirectly called
through calls to objc_msgsend, using the selectors associated to the function that must be called.
 Finding all the places where a specific function is called needs to find where the corresponding
selector strings are used (using the selectors-handlers array), this means to find each selector and all
its occurrences.
 A very fast explorative patch is to NOP just the call to objc_msgsend without worrying of the
surrounding code.
We can then briefly list the sequence I did to patch this program:
1. One of the places where the selector EnterRegistrationMsg is referenced is the sub_5558.
2. If you look this sub it comes evident that it is the menu handler, this is associated to the selector
0001DCC8 DCD aXxhlryqk1, aV804, sub_5558 ; "v8@0:4"
3. The selector is used in the very simple function sub_553C:
4. The function is associated to the selector aGgwj0rukg, aV804, sub_553C
5. And is called by the function sub_94B4 which is responsible of drawing the bottom buttons (it’s clear
if you see it).
6. Into the function sub_94B4 we find the first patch I can tell you about:
__text:00009840 BEQ loc_98A8 ; NOP it (0000A0E1)to extend trial
This patch simply skips the chain of events we just identified in the above steps.
7. This patch extends the trial forever, but the nag still remains.
8. The nag is shown a little below, at this stage you should be able to go down with IDA and complete
the process.

__text:00009890 MOV R2, R0

__text:00009894 LDR R3, =loc_1076C
__text:00009898 LDR R3, [PC,R3] ; "IbUvk0ueO"
__text:0000989C MOV R0, R6
__text:000098A0 MOV R1, R8
__text:000098A4 BL _objc_msgSend ; calls the Nag here, NOP it
This solves the program skipping all the annoying nags but the application is indeed still not registered. I will
leave finding of the registration routine for your own pleasure.
4.7 WHERE TO FIND OTHER NATIVE APPLICATIONS
There are a lot of applications you can install over you iPhone or your iPod, at the moment the marked is quite
closed and experimental, because to run them you must unlock the system. It is then a thing that not anyone
could or would do. These applications most of the times are just experiments. As a matter of facts most of the
applications you can find are free, under GPL license. Just some are donation-ware and very few are
shareware. At the moment the most interesting thing you can reverse is the operative system itself!
This will surely change in the future when the official SDK will be released, then a real market will open.
Reasonably the reversing approach will not be different, because the operative system running underneath is
always the same. Reasonably it will also be possible to have at the same time applications developed using the
official and not official SDKs. Meanwhile, to train yourself, take a look to these repositories:
 http://www.modmyifone.com/nativeapps/the-list/
 http://mac.softpedia.com/get/iPhone-Applications/
 http://modmyifone.com/forums/forumdisplay.php?f=29
 http://www.imatrix.lt
Other patches applied to the system are here:
 http://george.zjlotto.com/index.php/2008/02/05/patch-mobilesafari-to-open-local-file/
 http://george.zjlotto.com/

5 CONCLUSIONS
It should be evident that the system running under the hood of iPhone is quite complex and reveals to be an
interesting field for reversing.
The developers guide by Apple [19] reports this about the system of iPhones/iPoods:
If you are an existing Mac OS X developer, some aspects of iPhone OS should seem very familiar. Many
of the same underlying technologies used to build Mac OS X applications are also used to build iPhone
applications. iPhone OS leverages the maturity of the Mac OS X architecture and framework stack to
provide a reliable and already tested platform for developing applications. Even the newer
frameworks that do not have direct analogs in Mac OS X still borrow from the basic structure and
design methodologies that have already been proven on that platform.
Objective-C programs revealed to have a quite linear structure and to be generally speaking simpler than C
programs. This makes reversing of not protected programs (just as the compiler creates them) on the iPhone
simpler than, for example, Symbian. I also have shown how simple now is to jailbreak the system with the
mess of available tools.
Specifically, when you thing about the jailbreaking process, you must imagine it as a controlled exploitation,
controlled because the mean of this exploitation is to improve the system. But the same exploitation’s
techniques can be used by a malware.
As a matter of facts it comes evident how weak the security structure of the iPhone is:
 relatively easy to jailbreak the system (for some cases it’s even possible through some web sites),
26
o the Pwnage Project recently found really interesting things
 weak users policies (all the processes are running as root),
 unprotected applications, most are relatively easy to be reversed, and definitely all the system
applications are the easiest.
 possibility to modify all the parts of the system (i.e. even the browser) when you get into it (there are
no security zones or rings, to use a Windows terminology).
All these aspects have been used till now for good purposes: opening of a system to a community, developing
of interesting programs and generic improvements, but transforming all these efforts into malware production
27
is just here, behind the corner . I think there will not be much to wait before having some malware for
iPhones. Why iPhones? Simple: where there are moneys it is worth to create a malware.
26
http://www.modiphone.net/custom-firmware-images-jailbreak-and-more-through-itunes/ and
http://iphone-dev.org/
27
Just to give the idea: http://blog.metasploit.com/2007/10/cracking-iphone-part-1.html and
http://blog.washingtonpost.com/securityfix/2007/08/iphone_exploits_revealed.html
Conclusions 58
When the official SDK or the new OS 2.0 will be out I think it will not be different (beta of OS 2.0 has already
28
leaked out and exploited ), probably it will be a much improved system but native applications will still be
29,30
objective-C programs like it happens now .
So I wish to join the credits most of reversers worldwide are giving to Apple for creating a so wonderful
hackable toy. Already now a lot of reversing teams started to actively look at the MAC world (more than ever),
because of different facts.
First, this system is now out of the ghetto for enthusiastic-only where it was before, now the system is starting
to be used for different usage than graphic and multimedia.
Second, the MAC experience and sophistication of the system against exploits and security is far less than the
Windows one (which is under attack since years), resulting in a much more vulnerable system. Third, people
started to realize, following to the iPhone experiences, how simple/nice it is to reverse the OSX system and
starts to look at the bigger brother (the same applies for me).
As usual feel free to come to our forum for discussions and sharing of ideas. I also wish to thanks who read the
betas of this tutorial seeking for errors (Gunther, Y0shu4, ntoskrnl). This doesn’t mean that this is now error
free, but surely there are less 
5.1 REFERENCES
[1] Creating Native iPhone apps, http://www.lucasnewman.com/phonedev.pdf
[2] vfdecrypt sources, http://iphone.natetrue.com/vfdecrypt.c
[3] ZiPhone, http://www.ziphone.org/ or ftp://ftp.iphonefix.de/ZiPhone/
[4] iPlus2.0b, http://ipluspwns.blogspot.com/ or ftp://ftp.iphonefix.de/iPlus/
[5] Wikipedia on Objective-C, http://en.wikipedia.org/wiki/Objective-C
[6] ABI Mach-O file format

http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/
reference.html or http://en.wikipedia.org/wiki/Mach-O
[7] Introduction to The Objective-C Programming Language (Apple Developer Connection),

http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/
[8] Objective-C, http://en.wikipedia.org/wiki/Objective-C
[9] Beginner’s Guide to Objective-C, http://www.otierney.net/objective-c.html
28
http://gizmodo.com/366751/iphone-20-unlocked-runs-all-apps
29
[HOWTO] Use Apple SDK to build 1.1.4 apps, http://hackint0sh.org/forum/showthread.php?t=37998
30
winChain is really handy. Read “HowToUse, A quick walkthrough on winChain 1.0”,
http://code.google.com/p/winchain/wiki/HowToUse
Conclusions 59
[10] The objc_msgSend Function,

http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_8_sectio
n_2.html
[11] Reversing of the objC_msgSend, http://www.mulle-kybernetik.com/artikel/Optimization/opti-9.html
[12] Primer On Reversing Symbian S60 Applications, Shub-Nigurrath,

http://arteam.accessroot.com/tutorials.html?fid=194
[13] Symbian Symphony For 4 Crackmes And A Commercial Program, Shub-Nigurrath,

http://arteam.accessroot.com/tutorials.html?fid=207
[14] A Better Carrier Logo Patch for SpringBoard , http://george.zjlotto.com/index.php/2007/12/10/a-

better-carrier-logo-patch-for-springboard/
[15] How To: Install Apps on Your iPhone for Total Dummies (Mac OS X and Windows Edition),
http://gizmodo.com/gadgets/update/how-to-install-apps-on-your-iphone-for-total-dummies-mac-os-
x-and-windows-edition-292561.php
[16] Hackint0sh forum, http://www.hackint0sh.org/forum/indexpage.php
[17] ftp://ftp.iphonefix.de
[18] http://iphone-dev.org/
[19] iPhone OS Programming Guide (you must register, for free, into the developers site to get this file)
http://developer.apple.com/iPhone/library/documentation/iPhone/Conceptual/iPhoneOSProgrammi
ngGuide/iPhoneOSProgrammingGuide.pdf
5.2 HISTORY
Version 1.0
- Initial release
Conclusions 60

Primer On Reversing Jail Broken Iphone Native Applications - by - Shub-Nigurrath

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Primer On Reversing Jail Broken Iphone Native Applications - by - Shub-Nigurrath

Încărcat de

Drepturi de autor:

Formate disponibile

A che e

Jailbreaking your iPhone power 2

1 JAILBREAKING YOUR IPHONE POWER 6

1.1 Fast and practical jailbreaking procedure ............................................................................................. 7

1.2 File system structure .......................................................................................................................... 13

2 DISASSEMBLING THE FIRST NATIVE PRE-INSTALLED APPLICATIONS 14

2.1 Essential Notes on the Mach-O file format ......................................................................................... 15

2.2 Essential Notes on the Objective-C Programming Model .................................................................... 19

2.4 Where to go deeper ........................................................................................................................... 22

2.5 Continue to reverse our first application ............................................................................................ 22

2.6 CFStrings objects and normal strings .................................................................................................. 23

2.7 Selectors-handlers map ...................................................................................................................... 24

3 UNLOCKING FOR REAL THE IPHONE/IPOD TOUCH 27

3.2 Connect your PC to the device ............................................................................................................ 29

4 REVERSING SOME APPLICATIONS 32

4.1 Go down with the first application: AcceleroLog ................................................................................ 32

4.2 Going on with the second application: ShowTime .............................................................................. 41

Jailbreaking your iPhone power 3

4.3 Going on with the third application: iSim ........................................................................................... 45

4.4 Going on with the Fourth application: Camerapro ............................................................................. 50

4.5 Going on with the FIFTH application: PocketMoney ........................................................................... 51

4.6 Going on with the Sixth application: Softick Solitaire ......................................................................... 52

4.7 Where to find other native applications ............................................................................................. 57

5.1 References ......................................................................................................................................... 59

Jailbreaking your iPhone power 4

This tutorial is another primer I decided to write (similarly to what I

BTW Do you like the new tutorials look?

Your Favourite Neighbourhood Shubby

Jailbreaking your iPhone power 5

1 JAILBREAKING YOUR IPHONE POWER

strings -q %1|agrep "^[0-9a-fAF]*$"|awk "{ if (length($1) == 72) print; }"

* Copyright (c) 2006

Jailbreaking your iPhone power 6

Fortunately meanwhile, thanks to

1.1 FAST AND PRACTICAL JAILBREAKING PROCEDURE

Jailbreaking your iPhone power 7

The two most used are these:

 iPlus 2.0b (http://ipluspwns.blogspot.com/) but works only with firmware 1.1.4

1.1.1 USING IPLUS TO JAILBREAK

All you need is to write: iplus -u

iPlus 2.0b for iPhone Firmware 1.1.4

Jailbreaking your iPhone power 8

iPlus 2.0b - Pass 2 Starting

I got used to this tool eZiPhoneTools1.3 (http://eziphone.blogspot.com/), Figure 1.

Jailbreaking your iPhone power 9

Figure 1 – Main interface of eZiPhoneTools

Jailbreaking your iPhone power 10

1.1.2 USING ZIPHONE TO JAILBREAK

stops repeating all the times a message like this:

Figure 2 – Main Interface of ZiPhone (version 2.5c)

Jailbreaking your iPhone power 11

 utilities\shapshot – useful to take snapshots of programs you handle.

Here some important notes:

Jailbreaking your iPhone power 12

1.2 FILE SYSTEM STRUCTURE

the jailbroken system reveals to be:

A FreeBSD system with all the processes running as root

All the applications were built using Objective-C

There is support for already known frameworks like COCOA

What I want to start from is a simple pre-installed application, the calculator.app

Jailbreaking your iPhone power 13

2 DISASSEMBLING THE FIRST NATIVE PRE-INSTALLED APPLICATIONS