Developing for a Jailbroken iPhone A to Z (iOS 4.0.1)

Vital Stats:
iOS 4.0.1
Xcode 3.2.3
Mac OSX 10.6.4 Snow Leopard
iPhones 3G, 3GS, 4 (I finally have the whole lineup!)

PROBLEM: I still can’t get iPhone 4 working. If you have one, please try it and help me out! UPDATE: Found the cause of the problem to be certain status bar libraries installed alongside other apps. I’m not sure why they cause the problem, but see full notes at the bottom of the post.

The Goal: As usual, we want to be able to click “build and go” in Xcode and get the app we’re working on to load to the phone and start up. Also, we want to be able to debug from within Xcode itself. After all, Xcode is cool, and terminal+makefiles+gcc+gdb is lame.

Abstract: The plan remains unchanged from the 3.x method. In fact, you commenters practically wrote this one for me. This time we’re going to tell Xcode that it doesn’t need to codesign for iPhoneOS targets, then we’re going to tell it don’tcodesign for iPhoneOS targets, then we’re going to tell it, well, actually, codesign but do it using our script, not your built in method.

The Process: With Xcode closed and your device unplugged from the computer,

1. If you’ve done this step before for previous guides, you may ignore it. You’ll need a code signing identity in order to sign code to run on the device. Normally, this would be issued by Apple, but later on we’ll break the signature check so you can make a “Self-Signing Identity” using this guide from apple (coral). Note that you should name the identity “iPhone Developer” EXACTLY to avoid having to change a bunch of the steps below.
2. On your jailbroken iPhone, install the app AppSync. Add the source http://cydia.hackulo.us to cydia. You’ll get a warning about pirating software: this patch, by virtue of breaking Apple’s DRM so that we can install our own app, also enables us to install cracked App Store apps. Don’t do that. It’s immoral, fails to support legitimate developers who should be rewarded for their effort, and perhaps above all, pirating $2 cell phone apps is just ultra lame. But since our purposes are not nefarious, dismiss the warning. From this repo, install the package AppSync for OS 4.0, and for good measure, reboot the device.
3. Make some Plist adjustments, starting with SDKSettings.plist:

   cd /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.0.sdk
   sudo cp SDKSettings.plist SDKSettings.plist.orig
   sudo vi SDKSettings.plist

   Find

   CODE_SIGNING_REQUIRED
   YES

   and change YES to NO
   then find

   ENTITLEMENTS_REQUIRED
   YES

   and change YES to NO again. HINT: in vi, you can type the ‘/’ key in order to “Cmd-F”

4. Now, move on to the platform Info.plist

   cd /Developer/Platforms/iPhoneOS.platform/
   sudo cp Info.plist Info.plist.orig
   sudo vi Info.plist

   Two times, the following appears:

   CODE_SIGN_CONTEXT_CLASS
   XCiPhoneOSCodeSignContext

   Find each occurrence and replace the block

   XCiPhoneOSCodeSignContext

   with

   XCCodeSignContext

5. And now the real bad boy, some binary patching of Xcode:

   cd ~/Desktop
   vi script

   hit the “i” key and copy/paste:

   #!/bin/bash
   cd /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneOS\ Build\ System\ Support.xcplugin/Contents/MacOS/
   dd if=iPhoneOS\ Build\ System\ Support of=working bs=500 count=255
   printf "\xc3\x26\x00\x00" >> working
   /bin/mv -n iPhoneOS\ Build\ System\ Support iPhoneOS\ Build\ System\ Support.original
   /bin/mv working iPhoneOS\ Build\ System\ Support
   chmod a+x iPhoneOS\ Build\ System\ Support

   type the keys, in order: “:” “x” “enter”

   chmod 777 script
   ./script

   If it works right, you should see something like

   $ ./script
   223+1 records in
   223+1 records out
   111648 bytes transferred in 0.002678 secs (41692099 bytes/sec)

At this point, you’re done telling Xcode it doesn’t need to codesign. Now, we tell it don’t codesign:

1. With a new project open and ready to go (presumably you want to debug this one, though once you change these settings once, they’ll persist from project to project) open Project>Edit Project Settings (from the menu). Click on the “Build” tab.
   Find “Code Signing Identity” and its child “Any iPhoneOS Device” in the list, and set both to the entry “don’t code sign”

   

   Now you’ve told Xcode “don’t codesign.”

1. Almost done: time to tell Xcode “well, actually you should codesign.”

   mkdir /Developer/iphoneentitlements401
   cd /Developer/iphoneentitlements401
   curl -O http://www.alexwhittemore.com/iphone/gen_entitlements.txt
   mv gen_entitlements.txt gen_entitlements.py
   chmod 777 gen_entitlements.py

2. 

   And finally, to link the device and computer. Plug your iPhone in and open Xcode. Open Window>Organizer. Select the device from the list on the left hand side, and click “Use for development.” You’ll be prompted for a provisioning website login, click cancel. It’s there to make legitimate provisioning easier, but doesn’t make illegitimate not-provisioning more difficult.

Now you’re good to go! But there’s just one last thing. You have to do this last part for every new project you make. Go to the menu Project > New Build Phase > New Run Script Build Phase. In the window, copy/paste this:

export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate
if [ "${PLATFORM_NAME}" == "iphoneos" ]; then
/Developer/iphoneentitlements401/gen_entitlements.py "my.company.${PROJECT_NAME}" "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/${PROJECT_NAME}.xcent";
codesign -f -s "iPhone Developer" --entitlements "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/${PROJECT_NAME}.xcent" "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/"
fi

That will call the script you just downloaded in step 5 to sign our app with a fake signature. This is important only for debugging. If you do build and go otherwise, the app will load to the phone, but the app will fail to launch and you’ll get:

Error from debugger: The program being debugged is not being run

That should do it. Take all those steps and you should be home free for JBDev without paying $99.

CREDITS: Once again, credit for this process goes to various posters in this forum thread at iphonedevsdk.com. All of these steps are there somewhere, it just took a while to re piece them together in the right combination.

iPhone 4 Issue (UPDATE see below): So the method above has been tested working for my 3G and my 3GS. I don’t have my 2G right with me, but I expect it’s no different from the previous method, given that it can’t run iOS4.

The problem that I run into is this:

[Session started at 2010-08-04 20:35:02 -0400.]
//GDB stuff
Program loaded.
target remote-mobile /tmp/.XcodeGDBRemote-93925-69
Switching to remote-macosx protocol
mem 0x1000 0x3fffffff cache
mem 0x40000000 0xffffffff none
mem 0x00000000 0x0fff none
run
Running…
[Switching to thread 11523]
[Switching to thread 11523]
continue
warning: Unable to read symbols for "/Library/MobileSubstrate/MobileSubstrate.dylib" (file not found).
// A bunch of other lib load warnings like this here...
warning: Unable to read symbols for "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0.1/Symbols/usr/lib/libcrypto.0.9.8.dylib" (file not found).

Debugger stopped.
Program exited with status value:45.

The killer is that the app installs, launches, crashes, and then launches fine manually. But I also can’t connect GDB to the running process after the fact either, GDB claims the process isn’t running. I have no idea what’s going on. Anyone?

UPDATE (8/3/10): Totally by chance I happened to read this article on TUAW today about FaceTime. I didn’t pay much attention until about half way down something caught my eye:

…rather significant My3G bug — when installed, you cannot use your iPhone for native software development….

I had initially thought that maybe third party software was to blame but I meticulously disabled each MobileSubstrate extension I had one at a time and ruled them all out. Turns out that wasn’t good enough. The (since fixed) My3G bug was exactly the source of this issue, but I had actually uninstalled My3G and the problem persisted. The issue, it turns out, is with the status bar library Intelliborn uses in their products, IntelliStatusBarIcons. BUT, it doesn’t stop there. By individually uninstalling apps, I’ve found that Backgrounder (and NOT libstatusbar) also cause a dealbreaking bug. Instead of the program exiting with status:45, the new error is “Program received signal: “SIGUSR1”. at which point the application hangs. Conveniently, the workaround is easy, if annoying: For your particular project title, add an Override in Backgrounder. Hopefully this IS a bug in Backgrounder and not a byproduct of its function. But at least now you can debug again!

So partly I’m dumb and partly this is just a bummer. Full story in this post, but the general idea is that gdb catches a SIGUSR1 from Backgrounder and you have to ‘continue’ through it. And obviously, disabling Backgrounder for your app prevents the signal from getting sent.