SDK 3.0 / Xcode 3.1.3 Build and Go for jailbroken device

[gOdong]

Originally Posted by zim

#!/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 "\x8f\x2a\x00\x00" >> working
dd if=iPhoneOS\ Build\ System\ Support of=working bs=1 skip=127504 seek=127504
/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

Just saying, is all, that fussing about with two dev tool sets is a whole lot of bother when there's two bytes between you and personal freedom.

The code was magic. Thanks zim for the exellence work

Originally Posted by cberthe067

Ok, replying to myself ...

I found a way to deploy application to iphone, just use the iphone configuration utility found at Apple - Support - iPhone - Enterprise

Lauch it, Select Application on left panel and click on menu button Add, select the executable application situated in your project directory in build > Release-iphoneos and select the application package

Now, after adding the package, select your iPhone on the left panel and go to the application tab, find your application and click on install ! After that launch the application directly on your iphone, the icon should be on the dashboard !

It's working perfectly for me !

PS : Your iphone need to be connected to cable/cradle !

Thanks for the tip. Now I can deploy my apps easily

[alexwhittemore]

Zim, I think that's exactly the missing special sauce. There are two things: 1. When I use my 2.2 iPod touch 1G, I get a bunch of errors consistent with people who report that the binary was not properly codesigned with ldid on the phone. That is, it won't launch, and the debugger reports a communication failure. I haven't had success incorporating an ldid-mac build phase into it though. I'm less concerned since that's a 2.2 device. My iPhone 3G running 3.0, however, has the same problem as reported here (debugging doesn't actually work) so I'd love to try your build script to see if that takes care of it. Can you post it?

[Wardio]

Originally Posted by zim

I can build, go, and stop at breakpoints just fine. My project includes a script phase to codesign the binary with entitlements that include get-task-allow, perhaps that is the missing ingredient?

Ahha! This is indeed what I was missing to enable debugging on my iPod Touch. For those who hit the same errors when debugging on the device, simply add a post-build step to their solution that codesigns the binary with entitlements. The steps I followed were on 246tNt's corner of web - iPhone stuff

Cheers for the pointer Zim

[alexanderlonsky]

Hello!
I’ve deleted SDK 2.0(sudo /Developer/Library/uninstall-devtools –mode=all)
Installed SDK 3.0.
Applied successfully script.
Then added to my project my cert(MyDeveloperCert which I used for SDK2.0 also tried to create another cert - iPhone Debeloper) and got error – Code Sign error: no provisioning profile found matching certificate identity ‘MyDeveloperCert’
I’m not able to COMPILE my project without this error that called before compiling.
Restarted computer and Iphone – same! Try to compile without connected Iphone – same.
Why? Help me please..

[alexanderlonsky]

sorry, looked at folder in sdk which called as "3.0 (7A238j)", its @#$% beta!
two days without work due to my own stupidity =((

[zim]

Originally Posted by alexwhittemore

Zim, I think that's exactly the missing special sauce. There are two things: 1. When I use my 2.2 iPod touch 1G, I get a bunch of errors consistent with people who report that the binary was not properly codesigned with ldid on the phone. That is, it won't launch, and the debugger reports a communication failure. I haven't had success incorporating an ldid-mac build phase into it though. I'm less concerned since that's a 2.2 device. My iPhone 3G running 3.0, however, has the same problem as reported here (debugging doesn't actually work) so I'd love to try your build script to see if that takes care of it. Can you post it?

The post below yours by Wardio has the instructions I used.

In theory someone could put in the work to integrate that step into a new Xcode plugin, to provide a build setting for your projects to determine whether you target a jailbroken device or an Apple provisioned device. But probably not me, since it should be clear that I'm not a finisher, else I'd be a paid up developer with one or more apps in the store, right? :-)

[fallenfate]

Hey I'm a new commer to iphone development and to mac on the whole. This is the information I've been looking for the past 10 hrs!!!

Zim you rock! Now I can sleep with peace of mind .....thx man!

[jdbholmes]

Originally Posted by cberthe067

Ok, replying to myself ...

I found a way to deploy application to iphone, just use the iphone configuration utility found at Apple - Support - iPhone - Enterprise

Lauch it, Select Application on left panel and click on menu button Add, select the executable application situated in your project directory in build > Release-iphoneos and select the application package

Now, after adding the package, select your iPhone on the left panel and go to the application tab, find your application and click on install ! After that launch the application directly on your iphone, the icon should be on the dashboard !

It's working perfectly for me !

PS : Your iphone need to be connected to cable/cradle !

works perfect jailbroken phone running 3.0

[zim]

Originally Posted by jdbholmes

works perfect jailbroken phone running 3.0

Developing for a jailbroken iPhone, A to Z (iPhone 3.0) | alexwhittemore.com

Follow the instructions in that blog post for how to codesign your binary in Xcode via a shell script build phase, and you should be able to build, run and debug your app direct from Xcode (assuming, of course, you've patched installd on your device).

[reticon]

zim, THANK YOU!!!!!! It works! I was about to rip the hair out of my head. Even deployed to my iphone via XCode. If you have trouble be sure to follow the old instructions as this code just makes those work again. Thank you x100!!!

Originally Posted by zim

#!/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 "\x8f\x2a\x00\x00" >> working
dd if=iPhoneOS\ Build\ System\ Support of=working bs=1 skip=127504 seek=127504
/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

Just saying, is all, that fussing about with two dev tool sets is a whole lot of bother when there's two bytes between you and personal freedom.

[Cyril]

Hi all,

I tested this hack on Snow Leopard and SDK 3.0 and unfortunately, it does not work.

Anybody has a solution ?

Thanks in advance...

[zim]

Originally Posted by Cyril

Hi all,

I tested this hack on Snow Leopard and SDK 3.0 and unfortunately, it does not work.

Anybody has a solution ?

Thanks in advance...

I don't have my copy of Snow Leopard yet (apple fails to anticipate demand in Australia :-) but I suspect it's because Xcode is now a 64-bit app, and the patch is for the 32-bit jump locations. Use otool/otx to find the locations in the x86_64 partition of the image of the following two methods:

+[XCiPhoneOSPlatformPlugin pluginDidLoad:]
+[XCiPhoneOSCodeSignContext codeSignProductsInTargetBuildContext:]

Replace the pointer for codeSignProductsInTargetBuildContext: with the pointer for pluginDidLoad: (and perhaps check that pluginDidLoad: still just returns nil) and you'll be set.

I'll dump a new patch here when I do my upgrade (estimated shipping: 5 to 7 business days).

[Cyril]

Originally Posted by zim

I don't have my copy of Snow Leopard yet (apple fails to anticipate demand in Australia :-) but I suspect it's because Xcode is now a 64-bit app, and the patch is for the 32-bit jump locations. Use otool/otx to find the locations in the x86_64 partition of the image of the following two methods:

+[XCiPhoneOSPlatformPlugin pluginDidLoad:]
+[XCiPhoneOSCodeSignContext codeSignProductsInTargetBuildContext:]

Replace the pointer for codeSignProductsInTargetBuildContext: with the pointer for pluginDidLoad: (and perhaps check that pluginDidLoad: still just returns nil) and you'll be set.

I'll dump a new patch here when I do my upgrade (estimated shipping: 5 to 7 business days).

Thank you very much Zim for your help. I'll try that. I am a newbie in Mac but I have passed days of hacking on PC. I may succeed ...

If I do, I'll post a modified version of your script here.

BTW : It is the same exact file (I checked the md5 of it).

[Cyril]

I tried but failed. I'll wait till you Zim try to update your patch.

I hope you'll receive that Snow Leopard quickly

I am looking forward for your answer.

[puy0]

I'm not good at otool and such but here is what i can give you :

		      method_name 0x000093a8 pluginDidLoad:
		     method_types 0x000093b7 v12@0:4@8
		       method_imp 0x00002a8a 
----------------------------------------------------
		      method_name 0x0000b400 codeSignProductInTargetBuildContext:
		     method_types 0x0000b376 @12@0:4@8
		       method_imp 0x00008d26

If you want more just ask, I would like to help you, and why not, learn some tricks about patching stuff, i would love to be able to do what you do

[puy0]

Damn it, zim you were right, that's because of XCode running in 64bits...

Just run XCode in 32bits and the old patch works

Happy Build&Go

[Cyril]

I got it !!!

Here is the updated script to patch the 64bit part of the lib :

#!/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=1 count=300752
printf "\xc8\x2f\x00\x00" >> working
dd if=iPhoneOS\ Build\ System\ Support of=working bs=1 skip=300756 seek=300756
/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

[fpb]

Yes!!!

Thanks a lot!

Originally Posted by Cyril

I got it !!!

Here is the updated script to patch the 64bit part of the lib :

#!/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=1 count=300752
printf "\xc8\x2f\x00\x00" >> working
dd if=iPhoneOS\ Build\ System\ Support of=working bs=1 skip=300756 seek=300756
/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

[puy0]

Originally Posted by fpb

Yes!!!
Thanks a lot!

+1 Thanks a lot (even if I don't think 64bits > 32bits)
If you can give more detail on how you find the addresses tool / command lines I would really appreciate

[zim]

Originally Posted by puy0

+1 Thanks a lot (even if I don't think 64bits > 32bits)
If you can give more detail on how you find the addresses tool / command lines I would really appreciate

The excerpt below is for the 3.0 SDK with Xcode 3.1, it's good for showing you how to do it, but not for the final values :-)

$ otool -vf iPhoneOS\ Build\ System\ Support
...
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    capabilities 0x0
    offset 241664
    size 76896
    align 2^12 (4096)
$ otool -arch x86_64 -vt iPhoneOS\ Build\ System\ Support
...
0000000000002fc8        pushq   %rbp
0000000000002fc9        movq    %rsp,%rbp
0000000000002fcc        xorl    %eax,%eax
0000000000002fce        leave
0000000000002fcf        ret
...
$ otool -vo -arch x86_64 iPhoneOS\ Build\ System\ Support
... Class XCProductPackagingUtilityCommandInvocation
              baseMethods 0xe4e0 (struct method_list_t *)
                   entsize 24
                     count 6
                      name 0x9734 isRunning
                     types 0x973e c16@0:8
                       imp 0x2fc8 
... Meta-Class XCiPhoneOSCodeSignContext
              baseMethods 0xe640 (struct method_list_t *)
                   entsize 24
                     count 23
... skipping 5 methods
                      name 0xacf0 codeSignProductInTargetBuildContext:
                     types 0xac66 @24@0:8@16
                       imp 0x4e5b
...
$ hexdump -C iPhoneOS\ Build\ System\ Support | grep 496[cd]0
000496c0  f0 ac 00 00 00 00 00 00  66 ac 00 00 00 00 00 00  |?......f?......|
000496d0  5b 4e 00 00 00 00 00 00  15 ad 00 00 00 00 00 00  |[N.......?......|

Now we put the pieces together. The first command shows us the fat header, ie, where each architecture's image lies in the file. x86_64 is at offset 241664.

The second command disassembles the text segment (aka, the code segment). otool isn't ideal here, because it doesn't link the disassembly to methods. otx does, but regardless, what we want is easy to find: a method that returns nil. Entry and exit are easy to spot (pushq %rbp; movq %rsp,%rbp; leave; ret) which leaves us looking for something that also clears %eax to zero as its only other instruction. We easily see that occur in the second method, shown above, at offset 0x2fc8. otx tells us the method name, but it's not really important.

The third command now reveals the structure of the objective-c segments. otool does a pretty good job of this, following pointers out of the class segment and into the const and cstring segments to give us all the symbols. We see what method has its implementation at 0x2fc8 here, included for reference :-) More to the point, we see the method list pointer offset for the method we want (0xe640 = 58944), the entry size for the list (24), and the method number we want (#6). Its implementation is currently at 0x4e5b.

Taking all that together, we look in the file at offset 241664 (= 0x3b000) + 0x3640 (= 0x49640) + 8 (= 0x49648) + 5 * 24 (=0x496c0) as per the fourth command. There we see we're right on the money: 0xacf0, 0xac66, 0x4e5b, right what we expected from the Obj-C section dump. The address of 0x4e5b in the file ix 0x496c0, or 300736. Plug that into the script, and you're done.

Note that Cyril got a value of 300752, 16 bytes different. There's likely a minor change in the Plug-In object between Xcode 3.1 and Xcode 3.2 that accounts for those 16 bytes.

The story of how you find which method to replace is a longer one. :-)

[zim]

Also,

iPhone Software Development: Use XCode 3.1.2 to build SDK 3.0 app to 3.0 Device without provisioning profile

01 August, 2009 11:13
Anonymous said...

Much easier way: go to /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk and edit the SDKSetting.plist file so that "DefaultProperties/CODE_SIGNING_REQUIRED" and ENTITLEMENTS_REQUIRED are set to NO.

This may be a simpler overall solution, but I haven't tried it myself.

[puy0]

Thanks Zim for the method

I've installed 3.1 SDK + Xcode 3.2 released yesterday.

The previously mentioned trick editing plist works.
Just make sure you don't sign code in your targets.

Also removed the signing script from targets, still build&go!
EDIT: I finally re-added signing script build phase because even if it still build & go, gdb will fail without signing! no debug!

Much more clean

Thanks again.

[alexmullins]

hey guys. im on SL and xcode3.2 and sdk3.1 and tried following all of these steps and using the 64 bit script instead of the 32bit but still can't build for the device. i get

Code Sign error: a valid provisioning profile matching the application's Identifier 'com.alex.alex.Untitled' could not be found

error. Please can you help me.

[spasewalkr]

Originally Posted by puy0

Thanks Zim for the method

I've installed 3.1 SDK + Xcode 3.2 released yesterday.

The previously mentioned trick editing plist works.
Just make sure you don't sign code in your targets.

Also removed the signing script from targets, still build&go!
EDIT: I finally re-added signing script build phase because even if it still build & go, gdb will fail without signing! no debug!

Much more clean

Thanks again.

hey zim and puy0. i can confirm that with xcode 3.2 in snow leopard that this simple plist edit works. when i have time i will post about what was mentioned about gdb not working without the run script.

[vmunix]

Hi zim, What a great detailed explanation for that patch. There was however one typo in how you calculated the final location to patch within the binary that may confuse others that try to see where you're plugging numbers in from I think your reference to 0x3640 should have been 0xe640. Thanks again for the detailed explanation and tutorial on binary patching

-George

Originally Posted by zim

The excerpt below is for the 3.0 SDK with Xcode 3.1, it's good for showing you how to do it, but not for the final values :-)

$ otool -vf iPhoneOS\ Build\ System\ Support
...
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    capabilities 0x0
    offset 241664
    size 76896
    align 2^12 (4096)
$ otool -arch x86_64 -vt iPhoneOS\ Build\ System\ Support
...
0000000000002fc8        pushq   %rbp
0000000000002fc9        movq    %rsp,%rbp
0000000000002fcc        xorl    %eax,%eax
0000000000002fce        leave
0000000000002fcf        ret
...
$ otool -vo -arch x86_64 iPhoneOS\ Build\ System\ Support
... Class XCProductPackagingUtilityCommandInvocation
              baseMethods 0xe4e0 (struct method_list_t *)
                   entsize 24
                     count 6
                      name 0x9734 isRunning
                     types 0x973e c16@0:8
                       imp 0x2fc8 
... Meta-Class XCiPhoneOSCodeSignContext
              baseMethods 0xe640 (struct method_list_t *)
                   entsize 24
                     count 23
... skipping 5 methods
                      name 0xacf0 codeSignProductInTargetBuildContext:
                     types 0xac66 @24@0:8@16
                       imp 0x4e5b
...
$ hexdump -C iPhoneOS\ Build\ System\ Support | grep 496[cd]0
000496c0  f0 ac 00 00 00 00 00 00  66 ac 00 00 00 00 00 00  |?......f?......|
000496d0  5b 4e 00 00 00 00 00 00  15 ad 00 00 00 00 00 00  |[N.......?......|

Now we put the pieces together. The first command shows us the fat header, ie, where each architecture's image lies in the file. x86_64 is at offset 241664.

The second command disassembles the text segment (aka, the code segment). otool isn't ideal here, because it doesn't link the disassembly to methods. otx does, but regardless, what we want is easy to find: a method that returns nil. Entry and exit are easy to spot (pushq %rbp; movq %rsp,%rbp; leave; ret) which leaves us looking for something that also clears %eax to zero as its only other instruction. We easily see that occur in the second method, shown above, at offset 0x2fc8. otx tells us the method name, but it's not really important.

The third command now reveals the structure of the objective-c segments. otool does a pretty good job of this, following pointers out of the class segment and into the const and cstring segments to give us all the symbols. We see what method has its implementation at 0x2fc8 here, included for reference :-) More to the point, we see the method list pointer offset for the method we want (0xe640 = 58944), the entry size for the list (24), and the method number we want (#6). Its implementation is currently at 0x4e5b.

Taking all that together, we look in the file at offset 241664 (= 0x3b000) + 0x3640 (= 0x49640) + 8 (= 0x49648) + 5 * 24 (=0x496c0) as per the fourth command. There we see we're right on the money: 0xacf0, 0xac66, 0x4e5b, right what we expected from the Obj-C section dump. The address of 0x4e5b in the file ix 0x496c0, or 300736. Plug that into the script, and you're done.

Note that Cyril got a value of 300752, 16 bytes different. There's likely a minor change in the Plug-In object between Xcode 3.1 and Xcode 3.2 that accounts for those 16 bytes.

The story of how you find which method to replace is a longer one. :-)