[iPhone SDK] Running SDK compiled apps without a certificate

[nfotx]

Update: SDK compiled binaries run on 1.1.4, but we need to find a way to dynamically load 1.2 frameworks when needed. If anyone wants to help, please do! :)

Allright, this should be possible in some way or another. So let's see if it can be done. I'm not an expert, but on the other hand, i don't accept an "you need an official certificate" for an answer. As it seems right now, it's not the certificate that's blocking us, but framework versions.

I compiled the standard "Hello World" code example from ADC. It's running fine in the simulator of course. Set active sdk to "Device - Aspen 1.2", set active build configuration to "Release". Build the application, transferred to iPhone over AFP. SSH in and chmod +x the executable (no .lproj files). Application shows up on springboard, opens and crashes after a few seconds, interestingly displays backgorund, but not the icon. The icon can be made to show up on the springboard by renaming it to "icon.png" instead of "Icon.png" in the application bundle. Running the application from terminal produces:

dyld: Symbol not found: _OBJC_CLASS_$_NSAutoreleasePool
Referenced from: /Applications/HelloWorldClassic.app/./HelloWorldClassic
Expected in: /System/Library/Frameworks/Foundation.framework/Foundation

zsh: trace trap ./HelloWorldClassic

Also tried commenting out the setting up of an autoreleasepool in the source, which produces similar results, just another framework it couldn't load (CoreFoundation). So we are left with the fact that dyld can't load the frameworks needed for the application to run, probably because it is expecting 1.2 version frameworks.

Is there any framework experts out there that could think of a way to either patch or replace the frameworks? Or maybe even patch the SDK, so it would link the application to current version frameworks?

[nfotx]

Also, in a vain attempt, i tried replacing the frameworks on the iPhone with the ones from the SDK, no luck :(

[Former Bender]

Tried exactly what nfotx did.

Without certificate when you try to "build and go" your app in debug mode and SDK set to Device - Aspen 1.2, it says build failed.
It is completely wrong, the app is really built but can't be sent.
The certificate is just needed to authorize xCode to send it into the Phone nothing else.

Let's find the 2.0 Beta Firmware and Jailbreak it to send the apps and give a try. :)

[CycloneFr]

so u can build .app XianLi?

[Former Bender]

Yes, but because my iPhone is not running on 2.0.0 Beta, i can't test it out.

[ChronicProductions]

Try looking at the binaries for Aspen1.2.sdk, maybe we'll find something that we can patch

[netkas]

/* NSAutoreleasePool.h
Copyright (c) 1994-2007, Apple Inc. All rights reserved.
*/

#import <Foundation/NSObject.h>

@interface NSAutoreleasePool : NSObject {
@private
void *_token;
void *_reserved3;
void *_reserved2;
void *_reserved;
}

any ideas ?

[appleguru]

For anyone still playing with this.. I replaced all of the frameworks, system files, apps, and libraries on the iPhone with those from the Aspen SDK (I relinnked all of the binaries that needed it and added the appropriate plists and filestructure mainly from the 1.1.4 framework counterparts.. There are a few files that are likely missing/different, but it still should work!). I then merged the /usr/* folders, replacing the old files with the new ones.. And I got a nice shiny iPhone that hangs at the apple logo.

In an effort to not have to replace everything, I made a dependency list for the new Foundation.framework and came up with the list in this pdf here: http://appleguru.org/dependencies.pdf Every independent file is listed once in bold.

Presumably it's hanging because the phone doesn't like the new dyld or something to that nature... but given that it has all shiny new files, I don't know why.

BTW, graphics apps require a few additional frameworks, namely QuartzCore.framework and OpenAL.framework. Replacing those on the phone goes well, but replacing Foundation.framework makes it so that no apps boot (presumably including crash reporter, hence no crash logs to see what is needed that's not there :/)

[nfotx]

appleguru, what you did makes your iPhone hang, because all the binaries on your phone are compiled and linked against 1.1.4 frameworks (assuming that is what you run). So when you boot your phone, any binary that is run will crash because it can't load required frameworks.

What we need, it would seem, is the ability to install the 1.2 frameworks seperately on the iPhone, and then patch the SDK to link independently against these files, so that dyld doesn't confuse the version, eg allowing it to load all the old apps against 1.1.4 frameworks, and SDK compiled apps against 1.2. I don't know if this is the only required step, and I don't even know if the frameworks in the SDK are architecture independent, which they probably aren't, but please correct me if i'm wrong.

As a side note, it is quite interesting that the a SDK compiled binary actually runs. There seems to be no encryption, or certificate signing needed, at least on 1.1.4.

For the fun of it, i will try writing a binary tonight that doesn't link against any frameworks, and see if it runs flawlessly on the iPhone. My theory is that it does, since the build output seems to be actual, unencrypted ARM6 code (but i will need to verify that, disassembler here i come).

We need to figure out a way to either link against 1.1.4 frameworks, or to patch the 1.2 frameworks in one way or another. The most feasible probably being linking against 1.1.4.

[nfotx]

Whoops, maybe i misunderstood you, did you also replace the binaries on the iPhone with the ones from the SDK? Did you check what architecture they're compiled for? If they are i386 (eg simulator), then they won't work. If you have AFPd and OpenSSH on your iPhone, you can easily play around with replacing frameworks and binaries without having to restart your phone or anything, and then just revert to the original files when you're done. It would be interesting if played around a little more with this and shared your results. As i said, i will dig deeper tonight, when i get home.

Cheers!

[flek]

Aspen simulator works only on Intel Macs - which means it is dependent (together with its frameworks) to x86 processors (when compiling in Xcode, there is an option - compile for ARM(the iPhone processor) or Aspen simulator (x86 processor)).

The point is: when you replace original frameworks on your iPhone with those copied from SDK folder, they won't work (and will render your iPhone unable to boot), because they're compiled for different processor architecture.

If I am wrong, then someone please correct me :)

Cheers!

[NeoPheus]

Just look at your Developers/Platform folder....
There are 2:
AspenSimulator
Aspen

AspenSimulator contains frameworks and Apps compiled for x86 and Aspen contains binarys for ARM...

cYa ~Neo

[nfotx]

Okay, i am toying around with the SDK now, and found some strange and interesting stuff. When i try to build a new framework-clean binary, using the "Debug" build configuration, Xcode spits out:

"Codesign error: no certificate for identifier "iPhone Developer" was found in your keychain"

And the build "fails", however, the binary is actually produced. There is little difference between the release build (which builds without any errors) and the debug build. I looked at them both in a hex editor (unfortunately i don't have an ARM disassembler :(), and there is practically no difference, apart from some extra code i would guess, that allows breakpoints, and GDB to connect to the process and such.

Now here comes the fun part, the binary is actually running perfectly on the iPhone. There is no encryption, whatsoever. It is a perfectly fine ARM6 binary, that can be executed without problems. Of course this was to be suspected, but you never know ;)

So, that leaves us at having to find simple way to load the 1.2 frameworks from the SDK dynamically when a SDK compiled application is loaded.

By the way, does someone know an ARM disassembler for OS X?

Just to sum up: A binary compiled using the official SDK can run on 1.1.4

Cheers!

[nfotx]

Oh, and if anyone knows some good resources on how OS X/iPhone handles frameworks, please give me a shout. I'm pretty shure it must be relatively simple to make a seperate copy of the 1.2 frameworks and binaries that the a pre 1.2 iphone can use for running SDK compiled apps.

[radical]

I assume they are handled just like any other dynamically loaded library. Not sure this applies to the iPhone, but you can change the path's for OS X.

From "man dyld" :

DYLD_FRAMEWORK_PATH
This is a colon separated list of directories that contain
frameworks. The dynamic linker searches these directories
before it searches for the framework by its install name. It
allows you to test new versions of existing frameworks. (A
framework is a library install name that ends in the form
XXX.framework/Versions/YYY/XXX or XXX.framework/XXX, where XXX
and YYY are any name.)

For each framework that a program uses, the dynamic linker looks
for the framework in each directory in DYLD_FRAMEWORK_PATH in
turn. If it looks in all the directories and can't find the
framework, it searches the directories in DYLD_LIBRARY_PATH in
turn. If it still can't find the framework, it then searches
DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH in
turn.

Is it possible to do a static link when compiling from xcode? I would guess not :)

rad

[windrago]

Just to sum up: A binary compiled using the official SDK can run on 1.1.4


This is a great piece of information. I have 1.1.3 on my Touch and the sample app that I have built doesn't run.

Questions:
- do I need to upgrade at 1.1.4 to run my own apps?
- where do you get the exe? Under the build folder by default 2 folders are produced and only one seems to have the .app file.

thx for your post, it shed some light in my dark brain.

[Shirk]

I assume they are handled just like any other dynamically loaded library. Not sure this applies to the iPhone, but you can change the path's for OS X.

From "man dyld" :
...
Is it possible to do a static link when compiling from xcode? I would guess not :)
rad

I can report a partial success using the specified environment variables.
I copied the files from Aspen1.2.sdk/System/Library und Aspen1.2.sdk/usr/lib to
/var/root/Aspen/{Library,usr}. In addition I hat do symlink all *.dylb's in the Frameworks to usr/lib because dyld was unable to locate them inside the frameworks.
Then I did the following:

# export DYLD_FRAMEWORK_PATH=/var/root/Aspen/Library
# export DYLD_LIBRARY_PATH=/var/root/Aspen/usr/lib
# /Applications/hello.app/hello
dyld: Symbol not found: ___kCFVolatileDomainCallBacks
Referenced from: /System/Library/Frameworks/Foundation.framework/Foundation
Expected in: /var/root/Aspen/Library/Frameworks/CoreFoundation.framework/CoreFoundation

zsh: trace trap /Applications/hello.app/hello


As you can see dyld gets past the ObjC part but encounters some relocation error in the core Frameworks.
This may also be a result of my quick-hack-style testing attempt but at least it looks like running 1.2.0 apps with a seperate library and framework root is not totally impossible :D

[chrisc9867]

nfotx, are you planning to write a little tutorial? I also know this is pushing it, but did the debug build run properly with the debugger on the computer?

[windrago]

True, a mini tutorial would be just great!
I'm comfortable with code, but totally new to the mac development world. However your post has very good hints!

[ChronicProductions]

Also, in a vain attempt, i tried replacing the frameworks on the iPhone with the ones from the SDK, no luck :(

This may somehow work. A lot of the frameoworks are now in PrivateFrameworks but symlinked to Frameworks, and I assume you didn't do the symlink nor chmod 777 the new frameworks

[nfotx]

Well, i've gotten pretty "far", sort of. Creating a faux 1.2 root on the iPhone and instructing dyld to load libraries and framework from this path. This is practically what Shirk has also done, and we get the same results. The problem is this:

Referenced from: /System/Library/Frameworks/Foundation.framework/Foundation
Expected in: /var/root/Aspen/Library/Frameworks/CoreFoundation.framework/CoreFoundation

What happens is that 1.1.4 dyld can't load the 1.2 Foundation framework, and thus reverts back to 1.1.4, which in turn is totally different symbol-wise from 1.2, and therefore shuts down. Eg, it doesn't find the 1.1.4 symbols defined in Foundation in the new frameworks. When trying to force dyld to only load 1.2 Foundation, it spits out something like "Unknown required load command: 0x800000F". I'm not entirely sure, since resources on dyld are scarce, but i would guess this means that the 1.2 dyld supports some new load commands that 1.1.4 dyld doesn't understand. Getting through this hassle would probably require patching the frameworks to allow 1.1.4 dyld to load them. I spent alot of time in a hex editor trying to figure out what to patch, but right now, for me at least, this is nearly impossible, since i haven't been able to find any detailed specifications for the frameworks binary structure, or an ARM dissasembler, both would make everything a lot easier. I know the theoretical structure of the frameworks and libraries (Apple has this documented on ADC under mach-o binary format), but this doesn't really translate into actual code for the different load commands, so i'm stuck at looking at hex code i haven't got a clue to what means.

On the subject of tutorials, i would love to do that, but until we have an actual tap-and-the-SDK-compiled-app-just-runs solution it's not much fun.

If you wan't to mess around and help, here's a few pointers:

Create a copy of the 1.2 frameworks and other files on the iPhone, these files are found in the Aspen-1.2 SDK. I put mine under /var/FauxRoot.

Instruct dyld to use these libraries and frameworks when loading an application. You can do this at runtime by using the env command, like this:

env DYLD_ROOT_PATH=/var/FauxRoot /Applications/Some1.2App.app/Some1.2app

But as i said, this isn't much fun yet, since we need to either patch up the frameworks, or figure out how to use the 1.2 dyld under 1.1.4. I did try using the new dyld to load the frameworks, but it simply refuses to run, i guess that it is in some way incompatible to the 1.1.4 kernel.

Anyone sitting around with a reference sheet for ARM6 binary code?

[Shirk]

nfotx: looks like a got another one..

I'm now using two scripts to setup and leave my 1.2 environment. They just consist of a few export and unset directives but they got me past my last error.

My settings so far:

export DYLD_FRAMEWORK_PATH=/var/root/Aspen/System/Library
export DYLD_LIBRARY_PATH=/var/root/Aspen/usr/lib:/var/root/Aspen/System/Library
export DYLD_FORCE_FLAT_NAMESPACE=yes

Adding System/Library to DYLD_LIBRARY_PATH solved the need to create symlinks for all dylib's contained in the frameworks.
What I got was this:

# cd Aspen
# source set_paths.sh
# /tmp/hello2.app/hello2
dyld: Symbol not found: __dealloc
Referenced from: /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
Expected in: flat namespace

zsh: trace trap /tmp/hello2.app/hello2
#


So I tried to export my own version of __dealloc (which seem to be called _dealloc in 1.1.4) by adding this to my code:

void dealloc()
{
return;
}

After this I'm left without relocation errors but the app still terminates with a:

zsh: bus error /tmp/hello2.app/hello2
#

Still way to go.. but where progressing ;)

[sugokuGENKI]

I can't be of much use but i'd love to see this project go somewhere.
I went in to the apple shop and bought a iPod touch expressly to do development work, but the people in the shop never mentioned that there isn't a developer program in the UK yet (nor that there's a waiting list for the US programme)
kerwank!

[Cone]

but the people in the shop never mentioned that there isn't a developer program in the UK yet (nor that there's a waiting list for the US programme)
Why would clerks in a consumer store know anything about development?

[sugokuGENKI]

Why would clerks in a consumer store know anything about development?

yeah, dumb me,. :(