Greetz from academe: No place to Hyde


John Aycock

University of Calgary, Canada
Editor: Helen Martin


In the latest of his ‘Greetz from Academe’ series, highlighting some of the work going on in academic circles, John Aycock looks at a paper that describes how malicious apps can be slipped past Apple’s app review process.

The beginning of a new year brings with it a bit of a lull in academic conferences. Control over academics’ lives tends to be Kidnapped by the unrelenting schedule of the school semester, and as a result many conferences occur in the summer, when teaching demands are fewer. These academic doldrums present a problem for me, in that there’s relatively little new work to write about. So this month, I’ll take another dip in the suspiciously warm waters of USENIX Security, a veritable Treasure Island of interesting research. Having now exhausted my complete set of Robert Louis Stevenson references, I turn to the strange case of ‘Jekyll on iOS: When benign apps become evil’ [1].

Spoiler alert: the premise of the paper is that malicious apps can be slipped past Apple’s app review process. The last sentence was written with dollops of sarcasm, because it’s really not much of a surprise at all. Back in 1936, Turing tackled the ever-vexing Entscheidungsproblem [2] – a term to work into casual conversation if ever there was one – and proved that what came to be called the Halting problem is in fact undecidable. Skipping forward a bit, Fred Cohen added his own undecidability results, proving that it’s not generally possible to detect viruses by their appearance or behaviour [3]. So when Apple or anyone else announces that they’ll be sifting out bad software from good, it’s essentially guaranteed to be a fool’s errand. But it’s not like anyone’s going to base a multi-billion-dollar industry on this premise. I mean, get real.

The question is thus more how malicious apps can be slipped past Apple, rather than if they can be slipped past. Therein lies the clever part. Normally, an evil-doer takes one of two approaches: create an overtly malicious app, or find bugs in an existing benign app to exploit. Jekyll attackers lean towards the latter approach, but where they control both sides of the equation. In other words, a ‘Jekyll app’ is created by an attacker, is a legitimate app (hence will pass Apple’s app review), but is also flawed and exploitable in known ways. Once the app arrives in the App Store and makes its way onto people’s devices, it can easily be repurposed for less than noble tasks. Depending on iOS version, the Jekyll proof of concept detailed in [1] was able to tweet, email, text, dial, take videos, toggle Bluetooth, and exploit the kernel and other apps.

The mechanism for a Jekyll app’s transformation is the potion of return-oriented programming (ROP) [4]. ROP gadgets, later to be strung together, are embedded purposely into the Jekyll app in a hard-to-detect fashion, along with a buffer overflow vulnerability that can be exploited to inject the ROP code. Conceptually simple, but the devil is in the detail, and the paper does not shy away from details, explaining how the researchers bypassed ASLR and performed iOS analysis to find private, but oh-so-useful APIs.

One nice feature of the Jekyll paper is that it does a good job of summarizing scattered work on the security architecture of iOS and how it can be circumvented. The authors draw on references from academic sources, but also Hack in the Box, ProCon, Black Hat, SyScan, POC and WrathofCon – an impressive list even when you consider that I made two of the names up myself. They also did a commendable job of ensuring that their work was carried out responsibly, an important point since their app had to exist at least temporarily in the App Store, where anyone potentially could have downloaded it. The researchers pulled their Jekyll app once they had downloaded it from the App Store, verifying that no one else had downloaded it, and disclosed the attack to Apple months before their paper was published.

Interestingly, Stevenson describes Jekyll as ‘the noted professor’ in his story [5], and he must have been an odd academic indeed; the only potion in my cup is the coffee that transforms me from Hyde into Jekyll.


[1] Wang, T.; Lu, K.; Lu, L.; Chung, S.; Lee, W. Jekyll on iOS: When benign apps become evil. 22nd USENIX Security Symposium, 2013, pp.559–572.

[2] Turing, A.M. On computable numbers, with an application to the Entscheidungsproblem. Proceedings of the London Mathematical Society 42(2), 1937, pp.230–265.

[3] Cohen, F. Computer viruses: Theory and experiments. Computers & Security 6(1), 1987, pp.22–35.

[4] Shacham, H. The geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86). 14th ACM Conference on Computer and Communications Security, 2007, pp.552–561.

[5] Stevenson, R.L. Strange case of Dr Jekyll and Mr Hyde. 1886. Available at



Latest articles:

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…

Dissecting the design and vulnerabilities in AZORult C&C panels

Aditya K Sood looks at the command-and-control (C&C) design of the AZORult malware, discussing his team's findings related to the C&C design and some security issues they identified during the research.

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.