Would it be possible to call an application from somewhere other than /Applications. All applications have an info.plist that includes the "com.apple.MobilePhone" or whatever the desination may be. Is there a way to put an application elsewhere yet still call it from an Apple Link.

Where am I going with this?

A user posted something on Erica Sadun's site that said that after he updated to 1.1.3, his iPhoneHome double click setting was still in place. He was using it to open mail, which is not one of the iPhone's default options. This means that Apple does not screen out settings other than theirs in 1.1.3 for the com.apple.springboard.plist file.

What If?

We could hide Installer.app somewhere else, say, in the DCIM/100Apple folder where the camera roll points, setup the doubleclick to open it, update, and maybe apple wouldn't overwrite that folder during the upgrade because it is the camera roll folder????

Anyone else see where I am going?

If I can make the double click see the app somewhere else, I will be the brave one to try it.

Any suggestions or anyone wanting to shoot me down before I get started?

Try it but maybe somewhere we KNOW does not get deleted. Other issue is the permissions of the folder and the file. If you can't get root access you're screwed.

Originally Posted by iphonedev

Try it but maybe somewhere we KNOW does not get deleted. Other issue is the permissions of the folder and the file. If you can't get root access you're screwed.

But how do I call it from a folder other than /Applications in the first place? Forgive me but I work mainly in Windows and so windows makes sense to me. I work secondariliy in Linux which I somewhat understand, but Apple is all new to me.

The com.apple.springboard.plist file has: <string>doubletap://com.apptapp.Installer</string>
How would I make that instead
<string>doubletap://private/var/root/Media/DCIM/100APPLE/Installer.app/Installer</string>
And make it work?

See what I am talking about?

Hello,

Unfortunately, "hiding" an application in the DCIM folder most likely won't help you, since by default the iphone firmware sets the "noexecute" flag in /etc/fstab for the /private/var filesystem. So, while your hidden app might survive the upgrade, the upgrade will almost definitely reset your /private/var filesystem back to "noexecute" in newly-created /etc/fstab file. With the "noexecute" option set, you can't launch any programs that are sitting in that filesystem...

best regards,

tom

Originally Posted by tfischer

Hello,

Unfortunately, "hiding" an application in the DCIM folder most likely won't help you, since by default the iphone firmware sets the "noexecute" flag in /etc/fstab for the /private/var filesystem. So, while your hidden app might survive the upgrade, the upgrade will almost definitely reset your /private/var filesystem back to "noexecute" in newly-created /etc/fstab file. With the "noexecute" option set, you can't launch any programs that are sitting in that filesystem...

best regards,

tom

Phuck! Well, it was a good thought. I assume that's why the old TIFF exploit worked because the phone allowed TIFF files to execute.

It seems like at worst case, someone could release a "patched" version of 1.1.3 that would have installer included in it. What do I know? I'm just a Windows guy, but hey, having a bad idea is better than not having one at all.

Also publish your idea is better than keep it to your self..
Even if your idea can not work.. but at least it may open the door for another idea that can work..

Originally Posted by iTarek

Also publish your idea is better than keep it to your self..
Even if your idea can not work.. but at least it may open the door for another idea that can work..

I agree with you fully, iTarek. This idea may still have merit, as I'm curious to how Apple will actually handle installation of official native third-party apps on the iPhone. Putting all executables into / could run you out of space pretty quickly - I think that with 1.1.2 firmware there is only ~20MB free as it is. With all of the new features in 1.1.3, I would assume that there would be even less space available in that filesystem. To avoid this, the easy solution would be to have iTunes install these 3rd party apps in /var/private somewhere. However, if they are going to do that, then they will need to get rid of the "noexecute" option on this filesystem themselves... So, if 1.1.3 is ready to accept 3rd party apps, perhaps /var/private is already open to executables???

Like many in these forums, I really don't know what I'm talking about - I'm just an iPhone enthusiast with nearly 20 years of unix admin experience, and who enjoys discovering how this gadget works...

best regards,

tom

I guess my biggest thing is that if they're releasing an SDK, then developers must have a way to upload apps to the phone. What is going to keep anyone with the SDK from uploading Installer or any other app out there?

My guess is that there will be code signing involved with the iPhone SDK along with restrictions on what apps can and cant do. For example, its likely that apps will be prohibited from talking to the baseband, prohibited from making calls and prohibited from accessing any "sensitive" file (e.g. system files, any ITMS DRM protected content or keys or any "private" data like email storage, phone book files etc). It may be that SDK apps cannot even make TCP/IP connections except to very limited locations (such as http:// back to a fixed server stored with the app).

It may also be that there are multiple levels of code signing with different devs getting access to different features (e.g. a big company wanting to build an app to access their internal business-specific system may be able to get a certificate that lets them make TCP/IP connections whereas a small developer wanting to make an IM or VoIP client for free distribution to any iPhone or iPod Touch owner anywhere in the world may not be able to get such a certificate)

If you want to see an example of how the iPhone SDK apps may work, look at how BREW works (BREW is a native C++ environment found on CDMA phones sold by carriers like Verizon). Read http://en.wikipedia.org/wiki/BREW for more about BREW and how much work (and money) it takes to get a BREW application "out into the world"