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
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?
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
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..
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? :-)
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 !
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).
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!!!
Quote:
Originally Posted by zim
Code:
#!/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.
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:
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).
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:
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).
+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
+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 :-)
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. :-)
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.
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!
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
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.
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
Quote:
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 :-)
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. :-)
Does not work with xcode 3.2
Thanks!
Linear Mode
