If Adobe were smart, they’d modify their Flash ▶ iPhone code to just output Obj-C source code. Not much Apple could do.”

I’m sure Adobe is smart. And that’s why they aren’t getting into a battle they can’t possibly win. Let’s explore a what-if scenario of Adobe going down this path. How would Apple react in this cat and mouse game? Could they create a tool to automatically filter Flash created apps without the sourcecode to your program?

Step 1: Class dump executable.

For those of you that don’t know, you can get all Objective-C symbols out of a Mach-O binary with a wonderful tool called class-dump. If they aren’t there, you’ve already detected it’s a possible obfuscated build.

Step 2: Search class-dump output.

Look for suspicious symbols. Because anything outputted by a source generating engine is um, source, you can see exactly what pops out of a typical compile. It isn’t as though Apple can’t afford a copy of CS5. You can search for “CS5FlashView”¹ or any myriad of classes/symbols that would be put into the boilerplate output. This necessitates something way more devious as suggested by rentzsch: polymorphic code.

Step 3: Search for patterns.

After Adobe had spent a good chunk of time creating an Objective-C polymorphic coder, Adobe could now distribute a code generation engine that produces binaries that looks like it’s a home-made animation and application framework. But wait, if all the binaries produce the same obfuscated code, that is trivial to detect. Just look for “ER0GlashView.” This necessitates a nondeterministic Objective-C polymorphic coder. A perfect Ph.D topic, but nothing that’s been done to my knowledge. If it existed, this contest would be utterly pointless.

And you’re not just dealing with hiding a 200 line C function. Imagine randomizing the following:

• Class Names

  If you produce class names like “QTi3uigejr” dictionary attacks can trivially red flag programs.

• Symbols

  It isn’t enough to generate random symbol names. You have to randomize the structure of your classes so signatures of symbols don’t resemble the original versions. It would be fairly easy to create a JavaScript like obfuscater which converted your classnames/symbols to meaningless letter combinations. Now imagine running that on two trees of headers outputted from class-dump. One from a known Flash generated app and the other from an unknown. A significant chunk would turn out to be the exact same as the headers would be distilled into their underlying structure.

• Class hierarchy

  Ok, so now you use perfectly hidden class names, but every class hierarchy produces a recognizable fingerprint for a library. Without knowing anything about the classes, you can see relative relationships between them. The bigger the code-base, the easier this is. I’d assume the flash support structure is fairly large and its interdependency very complicated.

Prohibitively hard.

Let’s say you find an awesome little UIView subclass, but Apple has banned anyone from using it on the store. It wouldn’t be too hard to get around. Copy/paste, rename some methods, change a few method names around, etc. You then would have plausible deniability and you could say it wasn’t the banned UIView.

Imagine me asking you to incorporate three20 into your app and obfuscate it in a way where I couldn’t tell you were using it. And assuming the code-generator produces deterministic output, access to all your source code.² How hard would that be? You aren’t just dealing with changing the names of things. You are tasked with changing the fundamental structure of internal APIs and preserving assumptions that were undoubtedly made when making the code work with itself.

Now imagine making a program that could produce unique obfuscations of three20 and in a way that made it look from the outside like it was redesigned and rewritten from scratch by a human.³ Brain. Explode.

Consequences.

What if Adobe successfully can hide its entire Flash subsystem and so it debuts CS5.1 with the feature turned back on? Hundreds of apps get onto the store by tricking Apple gatekeepers. What do you think will happen when Apple figures out a way to detect with 99% accuracy that an app was generated with Flash?⁴ Yep, they’ll pull those apps faster than Brian J. Hogan picked up that phone.

The point is, there is no reason for Adobe to take that chance with their customers.

How can we fix this?

UIPasteboard of course!

Apple introduced an excellent and oft overlooked addition to the iPhone SDK when it gave developers the same power that they have on the desktop for sharing large chunks of data between applications. But Zac, you say, you of all people should know you can’t share data between apps…they’re sandboxed! Not true! Think of UIPasteboard as those little paper airplanes you used to send notes in back in school. No sandbox can hold UIPasteboard…

Method 1

This first method is fairly straightforward and easy for small data sets: Keep custom pasteboard filled with data you’d want users to import into your paid app.

UIPasteboard *sharedPasteboard = [UIPasteboard pasteboardWithName:@"com.mydomain.myapplite.sharedpasteboard" create:YES];
sharedPasteboard.persistent = YES;

By executing that on launch and keeping your sharedPasteboard up to date, you’ll always be able to request that from your paid app and auto-discover data from the lite version. The nicest thing about this method is most people won’t notice you did anything. Maybe you want users to notice your work…but sometimes the best features are the ones users don’t notice.

Method 2

This is for apps that have lots of content to put on the pasteboard and updating it all the time wouldn’t necessarily be so great. It’s a little weird but bear with me.

First, make sure you app can respond to the MyAppLite-export:// scheme. The parameters to this don’t really matter, but you could use them to specify some subset of data to export. You could also make this a little more generic and perhaps a little more secure by specifying a pasteboard name to the URL.

When MyAppLite is launched using this scheme, the users is presented with an “Exporting…” screen or something of the sort while MyAppLite puts everything requested on a special, one time use, pasteboard. After the pasteboard has been filled, MyAppLite opens MyApp-import://NAME_OF_PASTEBOARD. Now the paid app knows where to look to get all the necessary MyAppLite data off of the temporary pasteboard.

Security Concerns

Method 2 definitely has some security risks which possibly could be worked around. For one, if someone finds out your schemes they can read users data from a lite version and overwrite data in the paid version. With some obfuscated keys, this might not be much of an issue. Also, you wouldn’t want to send passwords or sensitive data using this method. That kind of data should be stored in the keychain anyway that is already available across your apps.

I hope this gives you some ideas on how to transfer data with UIPasteboard. I’ll try and post some sample code illustrating some of these concepts soon.

http://thatswh.at/

It’s juvenile and hilarious. My two favorite things. It looks at every tweet on Twitter and finds tweets that tell other people “That’s what she said.” It then finds the tweet that was in response to and puts it on a list.

This produces some of the following gems:

“my hands smell like meat”

and

“@mikejarrell @Jabrown85 Haha, thanks. I think he’s a little crooked but it was hard since he is the same height as me.”

Classics.

Enjoy!

Simi-useful but more importantly…free!

Download Memo 1.0

I will have some more news on OpenClip in the next couple days. I will also be traveling to Chicago for C4[2], so drop me a line if you would like to meet up.

Let me first explain how OpenClip works:

How it works is relatively simple and doesn’t break the SDK agreement. OpenClip works by looking into the Documents folder of other applications to get their pastes. Applications are allowed to write all they want to their own Documents directory (for copy), so no foul there.
Applications are also allowed to read outside their sandbox into the Documents directories for other apps (for paste), so no foul there.

How could that ever go wrong? What’s the problem?

The problem is Apple is probably going to shut down reading into other application’s boxes. I’m all for that as long as one of two things happens before:

• Apple ports NSPasteboard to the iPhone SDK (radar://6158362)

NSPasteboard is what I modeled OpenClip after. It allows copy and paste between applications, but more than that, it adds communication between applications. Porting NSPasteboard would make OpenClip moot and developers could easily respond by changing all references to OCPasteboard to NSPasteboard. Easy for everyone involved.

• Apple shuts down sandbox reading but creates a public folder for apps to write to. (radar://6156881)

If Apple does this, inter-app communication would still be possible through OpenClip or some other file communication method.

Applications need to work together. That’s the Apple Way®. I don’t know what you think, but to me the smaller and simpler an app is on the iPhone, the better it is. To make apps that are simple but powerful, developers need to make applications that can communicate.

What happens if Apple shuts it down?

Here’s what happens if a new version of the iPhone OS comes out and OpenClip can’t communicate anymore:

• Developers who implement OpenClip to either *only* copy or *only* paste can easily check if that will work before displaying any UI. If it breaks, those options just disappear.
• Developers who implement to do both copy and paste retain copy and paste within their application. That means that when and if the next update breaks OpenClip, applications won’t stop launching, they won’t crash when you try and copy and they won’t get garbage data. All that will happen is the app will only be able to copy and paste in the application. Not a horrible way to degrade if you ask me.

What about the UI? There are going to be like 20 implementations for copy/paste!

UI is a hard problem to solve. One of OpenClips goals is to provide examples of UIs for copy and paste. But to be honest, the best thing you can do with OpenClip is use it only for simple data. Only copy interesting data that a user would want to copy and present UI similar to Apple’s push to save image UI. Doing what MagicPad does and providing a whole way to select text is not what 90% of apps need. Look at what Twittelator did with copy in the video on GeekBrief.tv (http://www.geekbrief.tv/copy-and-paste-for-iphone). Press and hold needs to be the way most apps utilize copy and paste.

You can check out Proximi’s MagicPad UI proposal video here. It’s worth a look.

Lets face it. Hardly anyone is not buying an iPhone because it doesn’t copy and paste. It’s useful, but not necessary. Apple knows this so they put it at the bottom of their to-do list. If Apple were to implement NSPasteboard, however, 90% of apps could gain some really great functionality. Until then, maybe OpenClip can serve as a sneak peek to Apple, developers and users that this kind of framework would benefit the iPhone greatly.

Basically, all you have to do to get the benefits is include a few classes and use the very simple API to copy data or paste data. The special part is cross application. Copy a cocktail in Cocktails and paste it into MagicPad (Video of this in action).

There are some limitations. This technically complies with all Apple agreements. It is completely possible that apps that use this wouldn’t get on the App Store. Not for any real reason other than it will eventually step on Apple’s toes. It is also conceivable that the technology this is built on will break in the future. The hope is that the update that breaks this also brings copy and paste support.

If you are interested in looking at some code, send me an email to zacwhite+copypaste@@at@@gmail..dot..com.

Ignore all that.

Update 3: Site is up. Check out OpenClip.org.

I’m aware that this probably will get replace by Apple at some point. Duh, people need to search for stuff on their phone. But until then, I’ll get some iPhone practice.

Email me if you would like to know when it gets released: Zac White

Basically what I did was write a little cocoa app that lives up in your menu bar and takes a shot with the iSight ever 5 minutes.

The reasoning being that if you are the victim of conspiracy the best way to uncover it all is to set up this “nanny cam” type thing. Basically the built in web server serves up an iPhone specific web page with all the images on it. Check it out:

SpiPhone

Just run it, make sure your isight’s plugged in, and then go to http://localhost:9138/ and test it out.

If you want to check out how I wrote it (it isn’t anything super special), the source is here.

I unfortunately didn’t win (my presentation lacked flash and generally sucked), but I did get 4 votes and I didn’t even vote for myself…

By the way, C4[1] was amazing. I will blog about it shortly.

When I try and add a “Voicemail” label to GMail, it won’t let me…

Interesting…