L’annuncio degli iBeacon sembra aver scosso un po’ il mercato mobile, come se questi oggetti fossero un qualcosa di magico che consente di fare un po’ tutto, dalla geolocalizzazione indoor, ai pagamenti, dalla casa intelligente, a retail experience. Il limite è sempre la fantasia, basta che questa sia poi effettivamente supportata da una sufficiente conoscenza del dispositivo in questione per capire cosa è effettivamente realizzabile.
Diversi “esperti” di marketing si sono cimentati nello spiegare cosa è un iBeacon e voglio provarci anche io, dato che a tempo perso ci sto giochicchiando.

Read more!

La pirateria – e forse dico una cosa scontata – è un grosso problema anche per iOS.

Nel mondo del Jailbreak esistono AppStore fittizi dove è possibile scaricare gratuitamente copie di app che normalmente si trovano a pagamento.

Il tipo di utenza che usufruisce di questo servizio è divisibile in due macro-categorie:

a. persone che non compreranno mai la tua app

b. persone intenzionate all’acquisto, ma che desiderano provarla prima di investire i loro soldi nel tuo prodotto 

Riguardo al successivo pagamento da parte degli utenti tipo b. non bisogna farsi molte illusioni: sono davvero pochi coloro che regolarizzano la loro posizione andando sullo store virtuale di Apple.

Lo scenario è, dunque, tutt’altro che roseo. Un’ulteriore complicazione viene anche dalla natura stessa delle applicazioni. Questo genere di prodotti ha, infatti, una vita brevissima di utilizzo-medio, con il tangibile rischio che la ”prova” gratuita coincida perfettamente con il termine di utilizzo. Detto questo le app hanno anche costi rappresentativi del loro effettivo utilizzo. Apple, inoltre, non fornisce alcun periodo di trial sui prodotti distribuiti attraverso l’AppStore.

Come accade per altri settori, anche le tecniche per evitare la pirateria sulle app sono molto complesse, facilmente aggirabili e dall’elevata possibilità di creare un danno anche a chi l’applicazione l’ha regolarmente acquistata. Questo a causa di falsi positivi che possono essere causati anche per una semplice sostituzione del device. Non dimentichiamoci, poi, che Apple non vincola l’applicazione al dispositivo sul quale è stata scaricata, ma all’account dell’utente che l’ha acquistata.

Esistono soluzioni al problema? Una tecnica ottimale sarebbe quella di verificare se effettivamente l’utente ha effettuato l’acquisto, richiedendo una sorta di ricevuta digitale. Con iOS7 è stato introdotto un set di nuove API che consentono di ottenerla (anche se – a dire il vero – il sistema era comunque disponibile già con Lion). La classe è in oggetto SKReceiptRefreshRequest , interessante vero? Peccato che la verifica dello scontrino digitale sia ancora una procedura particolarmente complessa.

La ricevuta digitale sarebbe anche utilizzabile nel passaggio da applicazione a pagamento ad applicazione con modello freemium, in questo modo sarebbe possibile fornire a chi ha già pagato un set superiore di risorse.

La speranza è che venga rilasciata una qualche utility che renda l’analisi più snella (esiste già una lib su GitHub, che comunque richiede diverse conoscenze nell’ambito di certificati etc). O il danno economico diventerà sempre meno gestibile.

Ci siamo lasciati dall’ultimo evento di Apple con alcune previsioni sensate (articolo keynote Apple 10 settembre).

Successivamente ho espresso il mio disappunto (riflessioni sulla presentazione dei nuovi iPhone) di fronte al fatto che tutti i prodotti mostrati (ottimi prodotti) non avessero suscitato in me un particolare stupore o sorpresa anche a causa dei continui leaks da parte dei produttori cinesi.

Domani presteremo nuovamente la nostra attenzione all’evento organizzato da Cupertino, con il suo “We still have a lot to cover”. Dunque, cosa dobbiamo aspettarci dalla presentazione di Apple? Ci sarà una sorpresa?

Partiamo dal keynote precedente, quello del 10 settembre. Se la linea iPhone è stata rinnovata, sono, invece, mancati all’appello gli iPad. Per questi sono previsti aggiornamenti hardware e nel caso della versione “grande” è previsto un cambio abbastanza radicale dello chassis che lo renderà molto più simile al mini. Riguardo a quest’ultimo, è altamente probabile che la speranza di molti di veder integrato un display retina verrà frustrata.

Il nome dato all’evento ha un che di sibillino: “We still have a lot to cover”. Come è noto, “cover” in inglese significa anche custodia… Per associazione potremmo ipotizzare che si sia di fronte a una produzione multicolore come per l’iPhone C. In fondo – come è accaduto il 10 settembre – anche questa volta il manifesto di lancio dell’evento è supercolorato…

Tutto qui? Assolutamente no!

Apple dovrà stupirci ancora con lo splendido Mac Pro rivelandone – fra le altre cose – il costo e con la nuova release di OSX che dopo anni abbandona la famiglia dei felini per trasformarsi in Mavericks (come uno dei luoghi californiani più amati dai surfisti).

Sono, inoltre, previsti aggiornamenti hardware per i MacBook Pro con i nuovi processori Haswell di Intel (più potenti e dal minor consumo di batteria), per i MacMini e per Apple TV

Insomma, tutto procederà da piano o avremo qualche (bella) sorpresa?

Ma sopratutto: che il mio pendolino sia davvero migliore di quello del compianto Maurizio Mosca

iEtiquette si è finalmente rifatta il look, pronta per il nuovo sistema operativo iOS7.

Cos’è cambiato? Ora a dominare sono i colori flat e un’immagine iniziale che ci riporta ai divertenti e forti accostamenti cromatici degli anni 80. Abbandonato il serissimo Black&White, la nuova iEtiquette si prende poco sul serio, almeno all’apparenza: ora è possibile scegliere il colore dominante in base all’umore, all’abbigliamento o alla scocca del proprio iPhone (in attesa dell’arrivo del nuovo – giocoso e supercolorato – iPhone C). L’utente potrà, dunque, provare il tema che più gli piace fra i 9 disponibili.

 

temi ietiquette

 

Cosa resta del passato? Sicuramente quegli elementi che le hanno permesso di arrivare a quota 100mila download: una guida approfondita di buone maniere e di galateo e la navigazione pratica e intuitiva.

Per festeggiare questo sostanzioso update, iEtiquette rimarrà gratuita per 9 giorni a partire da domani.

 

IOS7 è uscito, lo sappiamo e molti di noi lo hanno già installato. Il nuovo sistema operativo rappresenta un cambiamento radicale rispetto al 6, un cambiamento necessario per svecchiare un prodotto che rischiava di essere visto come “datato”, specie se confrontato con quelli proposti da concorrenti che, con il trascorrere degli anni, hanno saputo produrre sistemi operativi molto accattivanti.

Non parlerò delle funzioni di iOS7, delle quali è stato detto già abbastanza. Voglio guardare “il dietro le quinte” e ripercorrere le trasformazioni che iOS7 ha subito negli ultimi mesi, dalla developer preview 1 fino al rilascio ufficiale odierno. Un’altra maniera per capire il modus operandi di Apple, fra tentativi, certezze e modifiche dell’ultima ora.

Per noi sviluppatori iOS7 rappresenta “un problema” anzi, due problemi. Il primo è il missmatch creativo che si è creato tra sistema operativo e applicazioni “vecchie” che per lo più utilizzavano lo scheumorfismo.

Il secondo sono le API e il nuovo modo di “vedere” le applicazioni.

La questione ha due risvolti, entrambi da considerare.

Senza dubbio per innovare, è necessario guardare avanti e, nel caso, prendere decisioni unilaterali, di forza, in maniera che tutti vi si adeguino senza negoziare. Lasciando troppa libertà si corre il rischio che ognuno continui sulla sua vecchia strada, implementando API vecchie. Una nota personale: è da tempo che mi riprometto di imparare bene il linguaggio “Ruby”, ma ad ogni rilascio di sistema operativo mi vedo costretto a ricominciare a studiare tutto daccapo.

Apple è decisamente coerente con quello che dice e fa; alcuni elementi dell’interfaccia grafica standard sono stati macellati da diversi sviluppatori (me compreso) per accontentare le richieste di clienti a cui non piaceva il pop up bluetto perché non in linea con i colori aziendali. Da Cupertino, infatti, non si smetteva di sconsigliare modifiche a tali componenti, avvertendo che release future avrebbero potuto generare cambiamenti, con il rischio di dare vita a comportamenti inaspettati con l’applicazione di questi hack… Insomma tutti ne erano consapevoli tanto ieri come oggi.

 

Tuttavia, se la filosofia che sta dietro a determinate scelte è comprensibile, le vie che propone per renderla operativa sono talvolta meno limpide.

Parliamo del minimalismo dell’interfaccia grafica di iOS7. È chiaro che questa scelta non è fine a sé stessa come su altri sistemi (una pura questione estetica, di gusto), ma propedeutica al contenuto e al contesto presentato, animazioni incluse.

Meno chiaro, invece, la maniera attraverso la quale trasformare il concetto in qualcosa di reale, attraverso la programmazione. Infatti, benché iOS7 preveda che tutte le app compilate debbano utilizzare come area lo schermo intero, ad oggi sembra non esistere un modo semplice per cambiare questa azione e renderla simile ad iOS6. Una scelta che ha fatto letteralmente impazzire un certo numero di sviluppatori. Capita che le “vecchie” applicazioni ricompilate vengano visualizzate con un layout diverso e con i contenuti che “scivolano” sotto la status bar. Un problema non da poco per chi come me sta lavorando per implementare animazioni di transizione diverse da quelle standard tra una sezione e un’altra senza usare gli strumenti forniti da Apple.

Non c’è dunque da stupirsi se il forum ufficiale della Mela morsicata è animato da discussioni visitate da migliaia di persone. In pratica, con questa scelta, si obbliga lo sviluppatore da una parte a “ridisegnare” gran parte del layout e dall’altra a tenere sempre presente la bicompatibilità con il vecchio sistema.

Gli stessi ingegneri Apple si sono dimostrati non esattamente all’altezza: le loro risposte ancora latitano e quando arrivano, non sono del tutto esaustive, soffermandosi su un solo modo di programmare , talvolta utilizzato da una percentuale minima dei programmatori. Intanto anch’io mi sono cimentato, proponendo una soluzione che riduca l’impatto sulle ore di lavoro e mantenga la retrocompatibilità con il 6. La speranza è che funzioni.

 

Il confronto con i programmatori ha portato Apple ha fare alcuni importanti correttivi. Dai primi giorni di settembre è possibile scaricare anche le versioni vecchie per quelle app che hanno interrotto la compatibilità con i precedenti sistemi operativi.

Nel nostro caso stiamo sviluppando un update per un nostro prodotto, iEtiquette che sarà compatibile solo con iOS7. Mentre per chi non avesse o potesse aggiornare sarà comunque possibile scaricare la versione precedente. Questa è una scelta di importanza enorme perché favorisce sia sviluppatori che utenti.

Il cambiamento, come dicevo all’inizio di questo post è radicale. Sicuramente qualcuno si lamenterà. Negli ultimi giorni ho letto di diverse polemiche riguardo ad aggiornamenti  di applicazioni a pagamento che – con il pretesto del passaggio al sistema 7 – dovranno essere pagate di nuovo dagli utenti che le avevano a suo tempo scaricate. Un caso eclatante – notizia di oggi – riguarda il task manager CLEAR che nella nuova versione iOS7 compatibile richiede ben 3 euro.

L’effort per rendere una app compatibile con iOS7 è molto elevato e per applicazioni complicate (CLEAR non è tra queste) è abbastanza normale che gli sviluppatori richiedano un pagamento. Il problema è che non è possibile fissare un prezzo di update, o gratis o tutto. D’altra parte ritengo che sia normale che un’applicazione supporti gratuitamente un solo sistema operativo. È una situazione che nel mondo desktop viviamo tutti i giorni (è probabile che qualcuno se ne approfitti, avvelenando il mercato).

 

Altre sorprese passate in sordina sono la possibilità di scaricare app in 3G fino a 100MB (prima il limite era di 50MB) e che un’applicazione per iPhone su iPad userà le risorse per retina display e verrà visualizzata a quasi tutto schermo, con un miglioramento sull’usabilità davvero notevole.

 

Ieri sera sono state presentate ufficialmente le novità di Apple.

iphone-5s-5c_cloud_in_touch La curiosità era sicuramente per il 5C, modello che secondo i rumors dei mesi scorsi sarebbe diventato l’iPhone “low cost”. Oggi riviste, giornali e blog non risparmiano sulle “virgolette” quando parlano del basso costo del nuovo 5C. Infatti, l’azienda di Cupertino non ha smentito sé stessa e né la propria natura. Va bene competere sul mercato e uscire dall’isolamento dorato degli anni Ottanta e Novanta, ma con i modi che le sono propri, ovvero qualità e innovazione. Costerà 599 euro. Il nuovo telefono è in 5 colori, ha una scocca in policarbonato a prova di graffio e appare decisamente accattivante. Arriverà sui mercati di Francia, Germania e UK entro il 20 settembre. Noi italiani, invece, dovremo pazientare ancora qualche mese (si dice fino a dicembre).

Molto interessanti anche le novità che riguardano il prodotto top, l’iPhone 5S. Al di là della possibilità di scegliere fra diversi colori (molto luxury come oro, argento e grigio), a colpire sono le innovazioni tecnologiche introdotte. Tra le quali:

 

  • Touch ID, il lettore di impronte digitali, in grado di riconoscere il suo “padrone”, accelerando e rendendo più sicure alcune operazioni
  • una fotocamera rinnovata
  • un processore a 64bit

Tutto ciò all’interno del nuovo sistema operativo iOS7, disponibile gratuitamente dal 18 settembre (per iPhone, dal 4 in su; per iPad, dal 2 in su e per iPod Touch 5th gen).

Per saperne di più su quanto presentato alla conferenza di ieri, segnaliamo gli articoli pubblicati da:

TheVerge.com

TechCrunch.com

CorrieredellaSera.it

LaRepubblica.it

 

 

In attesa delle novità Apple, alcune previsioni e un paio di riflessioni.

Sono passati 3 mesi circa dalla presentazione di iOS7 e OSX Mavericks e in questo periodo si sono susseguite un’infinità di immagini inerenti al fantomatico iPhone low cost e all’ iPhone 5S. In realtà niente di sorprendente. I primi leak di questi modelli risalgono già ai primi mesi del 2014. È possibile che Apple non sia più in grado di stupirci? (come si è detto nel precedente articolo http://cloudintouch.it/2013/09/05/apple-e-la-capacita-di-inventare-il-futuro/). Senza dubbio l’ufficio marketing di Cupertino è abile a creare un “clima di attesa” intorno ai nuovi prodotti attraverso un gioco di mezze verità e un po’ di smentite. Tuttavia, è anche evidente un grosso problema di sicurezza interna. Basti pensare che  le immagini dei primi iPhone 5 furono mostrate prima della presentazione del 4s.

Read more!

I clienti di iPhone sono più fedeli al loro dispositivo rispetto a coloro che possiedono un telefono con sistema operativo Android.

i love apple-200x200_cloud_in_touchQuesto quanto emerge dallo studio del Consumer Intelligence Research Partners. Considerando il periodo giugno 2012-giugno 2013, si nota come l’81% di coloro che utilizzavano un iPhone hanno continuato a farlo anche quando è stato il momento di acquistare un nuovo dispositivo. La percentuale di fedeltà degli utenti Android scende, invece, al 67%. Tuttavia è interessante notare come siano decisamente più numerosi coloro che abbandonano Android per iPhone piuttosto che il contrario (27% contro 14%). Se poi si guarda all’ex re del mercato BlackBerry si scopre che il 48% dei suoi vecchi clienti ha acquistato un iPhone e il 34% un telefono Android.

Sono dati interessanti, che tuttavia non sorprendono, soprattutto se si considera l’impegno che Apple ha sempre profuso per ottenere la reale e duratura “fedeltà” dei propri clienti. Una Customer Loyalty che – nonostante il passare del tempo – continua a restare alta e che va oltre la semplice “fidelizzazione”. Senza dubbio il legame tra Mela Morsicata e consumatori poggia su elementi tangibili e solidi come: a) la qualità dei prodotti venduti e b) la puntualità  nel venire incontro alle esigenze della clientela. Ma non solo. Esiste anche una sfera di “percepito non tangibile” sviluppatasi nel corso degli anni. L’abilità degli strateghi di Cupertino è stata – ed è tuttora – quella di immaginare oltre il semplice e singolo consumatore per dare origine, invece, a una comunità di persone legate da un senso di appartenenza molto forte. Insomma, la certezza di  far parte di una minoranza “non conforme al resto del mondo” che sceglie e usa prodotti “belli e giusti”. Chi usa Apple lo vuole far sapere, lo rivendica. Con la conseguente soddisfazione psicologica che deriva dall’essere convinti  di possedere qualcosa di esclusivo, non massificato (e non importa se intorno a noi milioni persone hanno un iPad o un iPhone…).

Ma osserviamo questi dati pensando al mondo delle applicazioni mobile. Questa maggiore fedeltà dei consumatori Apple comporta anche una maggiore frequentazione degli stessi dell’AppStore (rispetto a quanto i possessori di Android fanno con il Google Play)?

Io ritengo di sì. La più decisa customer loyalty degli Apple user è evidente anche osservando la maggiore frequentazione e la più profonda familiarità di utilizzo delle applicazioni mobile presenti sull’AppStore. Ciò è confortato anche da recenti dati che mostrano come il negozio Apple 1) sia 4 volte più redditizio rispetto a quello di Google Play e 2) sia di gran lunga preferito da chi investe in advertising nel settore mobile.

Un altro paio di riflessioni prima di chiudere.

Apple, iPhone ed il sistema operativo iOS sono legati in maniera indissolubile. Se sei fedele a uno lo sei anche agli altri. Diverso per il frammentassimo universo Android, fatto di aziende, marchi e dispositivi differenti. È possibile che – almeno in parte – questa parcellizzazione influisca negativamente sulla customer loyalty. Così com’è possibile che il consumatore Android si limiti a passare da un brand all’altro (da Samsung a Motorola, per esempio), acquistando dispositivi con il medesimo sistema operativo.

Infine, non bisogna dimenticarsi il fattore prezzo. È più facile che un consumatore che abbia sborsato una cifra consistente per un Samsung Galaxy S4 passi a un iPhone. Mentre è più difficile che lo faccia un consumatore che ha comprato uno dei tanti telefoni con sistema Android di fascia medio-bassa.

Tutto ciò, rimanendo in attesa del probabile iPhone low-cost, futuro 5C.

Sicurezza e inviolabilità. Da sempre due dei punti di forza di Apple e dei suoi sistemi operativi installati tanto sui computer desktop che su iPhone e iPad. Ora alcune applicazioni presenti sull’AppStore potrebbero nascondere intenzioni poco nobili, divenendo una minaccia per i nostri dispositivi. Si tratta delle cosiddette Jekyll Apps, ovvero applicazioni che sembrano del tutto normali in quanto hanno regolarmente passato le fasi di valutazione/approvazione necessarie per essere pubblicate sullo Store, ma la cui normalità è, tuttavia, solo di facciata. Come il protagonista del famoso romanzo di Robert Louis Stevenson, queste app passano dall’essere innocue dottor Jekyll pronte al download a malvagie e pericolose Mr. Hyde.

dr-jekyll_and_mr-hyde_applicazioni_malvagie

Siamo comunque di fronte a un fenomeno molto marginale che rende l’epidemia di malware nel negozio di Apple qualcosa di davvero improbabile. Inoltre, molte delle “armi” in mano alle Jekyll app non produrrebbero alcun effetto sul nuovo sistema iOS7. A Cupertino tengono ugualmente gli occhi ben aperti per evitare che ciò si trasformi in un problema reale.

Ce ne parla in modo approfondito Nick Arnott in un suo articolo per iMore.com

 

Jekyll apps: How they attack iOS security and what you need to know about them

Today researchers Tielei Wang, Kangjie Lu, Long Lu, Simon Chung, and Wenke Lee from Georgia Tech gave a talk at the 22nd USENIX Security Symposium and revealed the details of how they got a so-called “Jekyll app” through the App Store approval process and into a position where it could perform malicious tasks. Their methods highlight several challenges to the effectiveness of the Apple’s App Store review process as well as security in iOS. The researchers immediately pulled their app from the App Store after downloading it to their test devices, but demonstrated techniques that could be used by others to also sneak malware past Apple’s reviewers.

The details of Apple’s app review process are not publicly known, but aside from a few notable exceptions it has been largely successful in keeping malware away from iOS devices. The basic premise of a Jekyll app is to submit a seemingly harmless app to Apple for approval that, once published to the App Store, can be exploited to exhibit malicious behavior. The concept is fairly straightforward, but let’s dig in to the details.

The App Store review process

When a developer submits their app to Apple for review the app is already compiled, meaning that Apple does not have the ability to view the actual source code. It is believed that two primary components of Apple’s review process are a hands-on review of the app and static analysis of the application binary. The hands-on review consists of Apple actually putting the app on a device and using it to make sure that it meets the App Review Guidelines and does not violate any of Apple’s policies. The static analysis portion is likely an automated process which looks for any indications of linking to private frameworks of use of private APIs in the compiled code. Apple has a number of private frameworks and APIs that are necessary for the functionality of iOS and are used for system apps and functions, but for one reason or another are not permitted for use by developers. If an app links to a private framework or calls a private API, the static analysis will usually detect this and the app will be rejected from the App Store.

A Jekyll app begins like any normal app that you can find in the App Store. In this particular case, the researchers used an open source Hacker News app as their starting point. Under normal conditions, this app connects to a remote server, downloads news articles, and displays them to the user. This is exactly the functionality that Apple would see during the review process. Apple would see a functioning app that meets their guidelines, static analysis would reveal no use of private frameworks or APIs and the app would likely be approved for the App Store. Once a Jekyll app has been approved and released into the App Store, that’s when things take a devious turn.

Inside of the Jekyll app, the researchers planted vulnerabilities in their code, providing an intentional backdoor. After the app had made it on to the App Store and they were able to download it to their test devices, the researchers placed specially crafted data on their news server for the apps to download, which would exploit the vulnerabilities that they had planted in the app. By exploiting a buffer overflow vulnerability in the app, the researchers are able to alter the execution of the apps logic. One of the ways the researchers utilize this is by loading numerous “gadgets” that are spread throughout their code. Each gadget is just a small piece of code that does something. With the ability to alter the execution of the code, the researchers can chain together multiple gadgets which will cause the app to perform tasks that it could not perform originally. But in order to locate these gadgets and call the desired pieces of codes the researchers need to know be able to reliably call the memory location of these pieces of code. In order to do this they would need to be able to determine the layout of their apps memory on a given device.

iOS employs two notable security methods for hampering buffer overflow attacks: Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP). ASLR works by randomizing the allocation of memory for processes and their various components. By randomizing where these components are loaded into memory, it makes it very difficult for an attacker to reliably predict the memory addresses that will be used for any various piece of code that they might want to call. DEP strengthens the protection against buffer overflow attacks by ensuring that pieces of memory that can be written to and pieces of memory that can be executed remain separate. This means that if an attacker is able to write to a piece of memory, for instance to insert a maliciuos piece of their own code, they should never be able to execute it. And if they were able to execute what was in a particular piece of memory, that piece of memory would be one that they are not permitted to write to.

The researchers noted a weakness in the iOS implementation of ASLR. iOS only enforces module level randomization. This means that each executable file, the app, a library, etc., is assigned a random location in memory in which to operate. However, within each of these modules, the memory layout will remain the same, making it predictable. As a result, if you can get the memory address of a single piece of code, you can then infer the memory layout for the entire module, allowing you to call to any other piece of code within that module. To acquire a memory address for this, the researchers plant information disclosure vulnerabilities into their app which leak memory information about modules in their app. This information is then sent back to the server which is able to determine the memory layout of the entire app, allowing it to determine the memory address of any pieces of code it is interested in running and arbitrarily execute them.

As for DEP, this is generally intended to prevent an attacker from exploiting a buffer overflow in an app that they have limited control over. A Jekyll app is a much different scenario in that the attacker is also the developer of the app being exploited. In this situation, they don’t need to control writing to memory andexecuting it. Any sort of payload or malicious code that an attacker would normally need to write to memory as part of their buffer overflow exploit, a Jekyll app developer can just include in the code of their original app. They can then use the buffer overflow to alter the execution of memory in order to load the gadgets that they want. DEP on other systems has been demonstrated to be susceptible to what is called return-oriented programming. The idea is that an attacker can bypass DEP by reusing code that already exists in memory. In a Jekyll app, the developer can plant whatever code that will later need, and effectively bypass DEP by reusing their own code that they’ve put in place.

At this point, the researchers have an app in which they have embedded a number of code gadgets which they can now call and chain together at will, and they are able to alter the flow of the app’s logic without any user knowledge. They could use this to perform behavior that would normally get an app rejected from the App Store, such as uploading a user’s address book to their server (after first convincing the user to grant access to their contacts). But iOS restricts apps to their own sandbox and Apple won’t allow apps that use private APIs so the impact of a Jekyll app is still fairly limited, right?

Private parts

As mentioned previously, Apple will generally reject any apps that link to private frameworks or call private APIs. Due to the lack of transparency we can only guess at how exactly Apple goes about detecting these, but the most likely answer is Apple uses static analysis tools to detect any private frameworks that have been linked to or any private methods that have explicitly been used in the code. But with a Jekyll app, we’ve seen that the researchers have the ability to dynamically alter code, so how does that affect private APIs?

There are two private APIs of particular interest here: dlopen() and dlsym(). dlopen() allows you to load and link a dynamic library by just its filename. It just so happens that private frameworks always reside in the same location on a device, so that’s easy enough to figure out. dlsym() allows you to look up the memory address of a specified method for a framework loaded by dlopen(), which is exactly what you would need to to call a private method in a Jekyll app. So if the researchers can manage to locate dlopen() and dlsym(), they can use those private methods to easily load any other private APIs on the device.

Fortunately for the researchers, these two APIs are commonly used in public frameworks. Public frameworks use these APIs through what are called trampoline functions. Through the use of a debugger, the researchers were able to identify the offsets of these trampoline functions relative to the beginning of some public frameworks. Using the information disclosure vulnerabilities discussed above that allow the researchers to leak information about the memory layout of any given module, the researchers can use these known offsets to point to the trampoline functions for dlopen() and dlsym() with their app. Pointing to those functions, the researchers can now dynamically load any private framework and call any private API in their app. And remember, none of this is happening when Apple is reviewing the app. This only gets triggered after the app has been approved.

The attack

Now that we see how the researchers can alter the flow of their app and call private APIs, let’s see what that amounts to in terms of malicious behavior in a Jekyll app.

The researchers noted a number of different attack possibilities (though it should not be taken as a complete list of possible attacks) for both iOS 5 and 6. In iOS 5 they are able to send SMS and email without any user interaction or notification. By using private APIs to send SMS and emails directly to the iOS processes responsible for actually sending these messages from the device, the Jekyll app was able to send these out without showing anything to the user. Fortunately, the way these operations work has since changed and these attacks do not work as of iOS 6.

In iOS 5 and 6, the researchers have been able to access private APIs for posting tweets, accessing the camera, dialing phone numbers, manipulating Bluetooth and stealing device information, all without user intervention. While posting unauthorized tweets may not be the end of the world, the others are cause for a little more concern. Access to your camera would mean an attacker could covertly take photos and send them back to their server. Dialing phone numbers without user knowledge could be used to make toll calls, or even to set up call forwarding to have all of a victim’s incoming phone calls forwarded on to another number. Clearly when an app can access private methods, things can get creepy and it’s apparent why Apple restricts access to these functions.

Addressing the problem

Unfortunately, Apple’s current review process isn’t set up to detect this type of behavior. Apple only reviews the app’s behavior as it is at the time of review. If its behavior is altered once it is live in the App Store, Apple is not at all equipped to detect these changes and monitor the real-time behavior of apps after they have gone live. Apple could require developers to submit their source code as well, but it would be infeasible for Apple to go through and inspect the source code of every application submitted to the App Store. Even if they could inspect every line of code either manually (not even close to possible) or with automated tools, bugs are often times not easy to visually spot in code, especially if you have a malicious developer determined to hide bugs intentionally. The researchers did say that Apple responded to their findings with appreciation, but the researchers do not know what, if anything, Apple plans to do about the issues. It’s also worth noting that these challenges are not unique to Apple.

There also isn’t much that users can do for themselves in this case. While you could proxy your device’s traffic to try and see what it’s doing, a developer intent on hiding what they’re up to could easily encrypt the app’s traffic. They could also use certificate pinning to ensure that nobody is able to perform a man-in-the-middle attack to decrypt the traffic. If a user had a jailbroken device, it’s possible that they could perform real-time debugging while the app is running to determine what it’s doing, but this is well beyond the capabilities of most users. A Jekyll app could also be set up to only attack certain users, so even if a person knowledgable enough to perform such debugging installed the app on their device, there would still be no guarantee that they could easily get it to exhibit the malicious behavior.

iOS 7 and what is there left to do?

One piece of information the researchers were able to share with iMore is that many of the attacks they placed in their Jekyll app did not work on iOS 7. While we don’t know specifically which ones still worked and which didn’t, it’s possible that Apple mitigated some of the threats in a similar fashion to how they broke the ability to send SMS and email without user interaction in iOS 6. While this doesn’t directly address underlying issues in iOS that allow for dynamic code execution, it’s not entirely clear if that’s something Apple could, or even should do.

Altering the behavior of an app based on responses from a server is nothing new, it’s just usually not employed with malicious intent. Many perfectly legitimate apps in the App Store make use of remote configuration files to determine how they should behave. As an example, a TV network might make an app that behaves differently during the slow Summer than it would in the Fall when everybody’s favorite shows are starting back up. It would be reasonable and perfectly legitimate for the app to periodically check with the server to find out if it should be in summer or fall mode so that it knows how to display what content.

There are also legitimate reasons for apps to obfuscate and discretely hide pieces of code in their app. A developer of a news app might embed authentication credentials in the app to allow it to authenticate with their server, but might obfuscate that information in the app to make it difficult for somebody to retrieve them through analyzing their app.

The bottom line

The team at Georgia Tech has provided some very interesting research. In evaluating Apple’s security mechanisms in iOS and practices in their App Store review process, they were able to uncover weaknesses that could be exploited to get malicious apps onto users’ devices. However, the same result can be accomplished through simpler means.

A malicious developer could obfuscate calls to private APIs by breaking them up across multiple variables that would later be combined together into a single string of text that could call the API. The developer could use a value in a simple configuration hosted on their server to tell the app whether or not to run that code. With the flag disabled during the review process, the malicious behavior would go undetected by Apple and once approved, the attacker could change the flag on the server and the app could begin its assault.

These types of attacks are definitely possible on iOS and have been for some time. So why don’t we see them exploited in the wild more often? There’s likely a multitude of reasons:

  • Even legitimate developers with great apps struggle to get noticed. - With over 900,000 apps in the App Store, it’s easy to have your apps go unnoticed by users. Legitimate developers who put their heart and soul into developer apps that believe will be truly delightful to use often struggle with getting any significant number of people to download their app. A Jekyll app could used to target particular individuals that you might be able to convince to install the app, but getting any significant portion of Apple’s user base to install or even notice your app is no small undertaking.
  • There’s much lower hanging fruit out there. - The Google Play store has struggled with keeping malware out since its debut as the Android Market in 2008. You also have unofficial app stores used by jailbreakers as well as pirates that don’t have the same review process as Apple, where it would be much easier to get a malicious app hosted. The bottom line is, there are many places other than the App Store to spread malware that could do far more damage while requiring much less effort. To keep your house safe from burglars it doesn’t need to be completely secure, it just has to be more secure than your neighbor’s house.
  • Apple can easily pull apps from the App Store at any time and revoke developer accounts. - As we’ve seen on numerous occasions, if an app manages to sneak through Apple’s gates that doesn’t conform to their guidelines, it quickly gets removed from the App Store once Apple realizes their mistake. Additionally, for larger offenses, Apple can and has terminated developer accounts. A developer could sign up for another developer account with different information, but they would have to pay another $99 each time.
  • Once malware makes it past the gate, it’s still playing in a sandbox. - Apple has employed multiple layers of security in iOS. There is no single point of failure in iOS that renders all other security mechanisms broken. One of the security measures that iOS employes is sandboxing. Sandboxing restricts all apps to their own area on the system. Even an app run amok is very constrained in how it can interact with others apps and their data. Some apps allow for other apps to interact with them through use of customer URL schemes, but this communication is very limited and many apps do not have them. With each app restricted to its own sandbox, its ability to carry out malicious tasks is quite limited.

This certainly isn’t an exhaustive list, but shows some of the reasons that, while its technically possible to distribute malicious iOS apps, we don’t see a more rampant problem with malware on iOS. This is not to say that Apple should shrug and do nothing of course. As mentioned earlier, Apple is ware of the research that has been done here and is likely looking at their options for mitigating the threat. In the meantime, users should try not to worry too much. It is extremely unlikely that this research will lead to an outbreak of malware for iOS.

(Immagine copyright Paramount)