Hi. I’m Prateek Gianchandani.

Om Mani Padme Hum

iOS Application Security Part 35 – Auditing iOS Applications With iDB

In this article, we will look at another cool utility named iDB for pentesting iOS applications.

Before that, i would like to apologize for coming up late with this article. A lot of you have been requesting articles on different topics and i promise that i will write on them soon :). So since we are best friends again, let’s dive into this tool.

iDB is open source and you can download it from its Github page. You can then follow the tutorial here to know how to install it. Installation might take some time as there might be some dependencies you will have to install, so have some patience. Also, please note that it works with ruby versions 1.9 and 2.1 so make sure you set that version of ruby. You can use rvm list to list the versions of ruby installed on your system and then use rvm use followed by the version of ruby that you want to use.

Read on →

iOS Application Security Part 34 - Tracing Method calls using Logify

In the previous articles, we have seen how applications like Snoop-it can trace method calls specific to the application at runtime. This is very important in deducing the flow of the application. The same process can be performed by using a perl script named Logify.pl that comes installed with Theos. The script takes input as a header file and generates the hooking code that we can add in our tweak. We can also specify the classes we want to check. Once the tweak is installed on the device, whenever a method for that particular class is called, the tweak logs out the method along with the arguments to syslog. The first step here is to get the header files for a particular application. You can get the header files by using the -H option in class-dump-z. Once the headers folder is generated, you can copy it to your system.


Read on →

iOS Application Security Part 33 - Writing tweaks using Theos (Cydia Substrate)

In some of the previous articles in this series, we have looked at how we can modify the behaviour of an application by patching it using IDA Pro, Hopper etc. However, doing this hasn’t been quite straightforward always. We can also use Cycript to modify the behaviour of an application by changing some of the method implementations, but the change isn’t permanent. This is where writing tweaks for an application comes in handy. A tweak is nothing but a run-time patch to an application using the Cydia Substrate framework. Cydia Substrate consists of 3 major components: MobileHooker, MobileLoader and safe mode. You can read about these 3 major components here. Saurik has also written a complete series of documentation here. Our main focus here would be not to go in depth and learn how to write tweaks for jailbroken devices but to understand there relevance to application security so we can quickly write our own tweaks when necessary.

Read on →

iOS Application Security Part 32 - Automating tasks with iOS Reverse Engineering Toolkit (iRET)

While doing security audit of iOS apps, there are a lot of tasks that we have to repeat every time. This includes finding out the class information for the app, checking if the application stores any important data in plist files, analyzing the content in the database files etc. These tasks can be a little time consuming every time and so it doesn’t make quite a lot of sense to repeat them over and over again for every app. We have also looked at some tools like Snoop-it and iNalyzer that make our job easier by automating some of these tasks. In this article, we will talk about a new tool named iOS Reverse Engineering Toolkit (iRET) that has just been released to assist penetration testers in automating most of the tasks involved in a iOS penetration test. The project is developed and maintained by @S3Jensen.

In the author’s own words, here is what the toolkit does.

It’s a toolkit that allows you to automate many of the manual tasks an iOS penetration tester would need to perform in order to analyze and reverse engineering iOS applications. And the bonus is this can all be performed right on the device.

Read on →

iOS Application Security Part 31 - The problem with using third party libraries for securing your apps

In this article, we will talk about why we shouldn’t completely rely on using third party libraries for securing our apps. Usually, some of the things we try to do in our application are adding checks to detect piracy, jailbroken device etc. It is such a pain to write all the code from scratch which is why we usually resort to using third party libraries that can get the job done for us. In this example, we will be looking at a library named AntiPiracy which can be found on this url that aims to solve our problem.

On a first glance, it looks amazing .. here is a snippet of the description from it’s github page

The Full Shmoopi Anti-Piracy Library utilizes over a dozen algorithms to detect piracy, (not just four) including:

Signer Identity Checks Process ID Checks Plist Checks Bundled Item Checks (CodeRules, Resources, Etc) Encryption Checks Anti-Debugging Encryption Checks Anti-Tampering Binary Checks Integrity Checks CRC Checks MD5/SHA1 Hashing Checks *And much, much more…

Looks great. Here is a screenshot from its Github page that explains the implementation.

Read on →

How to distribute IPA file for jailbroken devices

So i have been getting a few queries on how to create an IPA file from Xcode and distribute it for jailbroken devices. Here is how i did it for Damn Vulnerable iOS App.

First we need to run the application using Xcode on the device. This requires a valid provisioning profile. I am doing this on Xcode 5.x but on the previous versions of Xcode, it was possible to run the application on the device without a valid provisioning profile.

Once the application is installed on the device, copy the .app folder from the device on your system.


Read on →

iOS Application Security Part 30 - Attacking URL schemes

In this article, we will look at how we can use a feature in iOS named url schemes to exploit an application. URL schemes are used by applications to communicate with each other. Every application can register for a particular url scheme. For e.g, the Damn Vulnerable iOS application registers for the url scheme dvia. This means that any url starting with dvia:// protocol will open up the dvia application. Depending on the parameters and the endpoint in this url, the dvia application can decide what to do it. Another example is the phone application in iOS. It registers for the url scheme tel and a url like tel://1-393-222-2222 will invoke the phone application and call a number. The problem arises when the url is not validated or the user is not prompted for confirmation in the application before making a particular decision.

The first step is to find the actual url scheme an application is registered to. This information can be found by looking at the info.plist file in the application sandbox folder using any file explorer utility like iExplorer.


Read on →

GDB segmentation fault issue fix with jailbroken device

If you have been experiencing segmentation fault issues with GDB while attaching to a process on a jailbroken iOS device, it is because the GDB that comes with Cydia is broken and you need to install a proper version.

You can download a proper working version of GDB from here.

You need to copy this executable into /usr/bin on your jailbroken iOS device and give it executable permissions.

If it still doesn’t work, let me know what issue you are facing by writing a comment below.

iOS Application Security Part 29 - Insecure or Broken Cryptography

In this article we will look at an example of Insecure or Broken Cryptography which is a common vulnerability found in most iOS applications. This vulnerability occurs when the data stored on the device is not encrypted properly thereby allowing a malicious user to gain access to that information. There could be many reasons for an improper implementaion of encrytption, using hardcoded keys for encryption, bad algorithms etc can all be the cause for an implementation that is not secure.

I would recommend you have a look at Apple’s documentation on Encrypting and hashing data.

In this article, we will look at an example of how we can spot and break an incorrectly implemented encrytion technique. For this article, we will be testing on the application InsecureCryptography-Demo that you can download from my Github profile. Download it and run on the simulator or on the device. Let’s look at what this application does. Once you start the application for the first time, it asks you to set up a new password to get started.


Read on →

iOS Application Security Part 28 - Patching iOS Application with Hopper

In Part 26 of this series, we looked at how we can use IDA Pro and Hex Fiend to patch an iOS application and modify its implementation. Patching an application has the specific advantage that once a change has been made, it is permanent. However, if you look back at the article on IDA Pro, you will realize that the process of patching the application was a bit tedious, mainly because we didn’t have a licensed version of IDA Pro which costs a lot. In this article, we will look at a utility named Hopper which we can use as an alternative to IDA Pro. It is less costly than IDA Pro and also provides a sleek interface to work with.

According to Hopperapp.com ..

Hopper is a reverse engineering tool for OS X, Linux and Windows, that lets you disassemble, decompile and debug (OS X only) your 32/64bits Intel Mac, Windows and iOS (ARM) executables! Take a look at the feature list below!

Read on →

iOS Application Security Part 27 - Setting up a mobile pentesting environment with iOS 7 Jailbreak

In this article we will look at how we can set up a mobile pentesting platform on our device with the new iOS 7 jailbreak. There has been quite a lot of discussion on the web about whether it is safe for a user to jailbreak their devices yet. However, if you are really interested in iOS pentesting then there is no absolutely no reason now why you shouldn’t jailbreak your device. Since this jailbreak was launched by the evasi0n team without any prior notice to the developers, most of the tweaks didn’t work with iOS 7 when the jailbreak was first made public. One of the most critical pieces of software Mobile Substrate which is used in many tweaks initially didn’t work on iOS 7. However, things have settled down since then. An update for Mobile Substrate (named Cydia Substrate) was released a few weeks back and many tweaks were also updated for iOS 7. Some things however don’t work well on iOS 7 devices. In this article, we will look at all those things which we need to do to set up a proper pentesting platform on a device running iOS 7.

Read on →

iOS Application Security Part 26 – Patching iOS Applications using IDA Pro and Hex Fiend

In the previous applications we have looked at how we can hijack method implementations during runtime using Cycript, and even change the logic of the code rather than changing the complete implementation using GDB. All of these things have been done to serve a purpose, which is to make the application do what we want. However, using Cycript or GDB is a bit of a pain as one has to do repeat the same process everytime after you restart the application. This is where patching the application is useful. Once a change has been made in the application’s binary, its permanent. So you don’t have to repeat the same process over and over again. Once the binary is patched, you can then run it on a jailbroken device with the changed logic.

In this article, we will be using the same application GDB-Demo that we had used in Part 22 of this series. If you remember, we had found a way to change the logic of the method that gets called when Login was tapped and hence bypassed the login authentication check. In this article, we are going to permanently patch this check so we are always authenticated.

Read on →

iOS Application Security Part 25 – Secure Coding Practices for iOS Development

In this article, we will look at some of the best practices an iOS developer should follow in order to make sure that their application is not easily exploitable by hackers.

Local Data Storage

It is extremely important for developers to know what kind of data they should be storing locally in their application. Frankly speaking, no data is secure when stored locally in the application. In part 20 of this series, we have looked at Local Data Storage in great detail.

Read on →

iOS Application Security Part 24 – Jailbreak Detection and Evasion

In this article, we will look at the checks a developer can incorporate in his application to check whether the device on which the application is running is jailbroken or not. Checking whether a device is jailbroken or not can have many advantages for your application. As we have already seen, an attacker can run tools like Cycript, GDB, Snoop-it etc to perform runtime analysis and steal sensitive data from within your application. If you are really looking to add an extra layer of security for your application, you should not allow your application to be run on a jailbroken device. Please note that millions of users jailbreak their devices and hence not allowing an application to be run on a jailbroken device could have a significant impact on your user base. Another thing you can do is instead block some of the features in your application rather than disabing it entirely. We will also look at how hackers can bypass the check for jailbreak detection in your application using Cycript.

Once a device is jailbroken, a lot of other files and applications are installed on the devcice. Checking for these files in the filesystem can help us identify whether the device is jailbroken or not. For e.g, most of the jailbreak softwares install Cydia on the device after jailbreaking. Hence just a simple check for the file path of Cydia can determine whether the device is jailbroken or not.

Read on →

iOS Application Security Part 23 – Defending against runtime analysis and manipulation

In the previous articles, we have looked at how we can use debuggers and tools like Cycript to do runtime analysis and manipulation of iOS Applications. We have looked at how we can modify the actual implementation of a method during runtime by changing the values in the registers using GDB, and also looked at how we can completely swizzle method implementations using tools like Cycript. With tools like Cycript and GDB in his arsenal and with a copy of your application’s binary, the attacker is is complete control. However, there are certain techniques a developer can use to make the job of the hacker much more difficult. In this article, we will look at the techniques a developer can use in his application to defend it against runtime analysis and manipulation.

In Xcode, there are certain checks that an attacker can use to determine whether an application is being debugged or not. In Xcode, use the following piece of code wherever you want to put a check for a debugger.

    #ifndef DEBUG
Read on →

iOS Application Security Part 22 – Runtime Analysis and Manipulation using GDB

In this article, we will look at how we can use GDB to perform runtime analysis of iOS applications. In the previous articles, we have looked at how we can use Cycript to analyze and manipulate the runtime behaviour of iOS applications. We have learnt how we can perform method swizzling and have our own methods being called instead of the original implementations. So why we do need GDB ? Well, what Cycript doesn’t allow us to do yet is set breakpoints and alter the values of variables and registers after a particular instruction. With GDB, we can dive deep into the application, observe the low level assembly instructions, manipulate the values in the registers and hence change the application flow completely.

Read on →

iOS Application Security Part 21 – ARM and GDB Basics

All the iOS devices released uptil now are based on the ARM architecture. All the Objective-C code that we write while developing iOS applications is first converted into ARM assembly before being converted to machine code (1s and 0s). With good understanding of the ARM assembly language and with good knowledge of debugging using GDB, it is possible for a hacker to decipher the Objective-C code during runtime and even modify it.

For this article, we will be using a sample application GDB-Demo from my github account. Make sure to install and run it on your iOS device. If you don’t have a registered developer account to run this on your device, you can follow the instructions mentioned here


Now let’s SSH into the device.


Read on →

iOS Application Security Part 20 – Local Data Storage (NSUserDefaults

In this article, we will look at the different ways in which applicatons can store data locally on the device and look at how secure these methods are.

We will be performing some of these demonstrations in a sample app that you can download from my github account. For the CoreData example, you can download the sample app from here

One of the other things that we will doing different in this example is that we will be running the application on the iOS simulator using Xcode rather than on the device and hence will be analyzing the application on our computer rather than on the device. This is just to demonstrate that you can perform all the steps performed before in previous articles on your system as well by running the application via Xcode. Optionally, you can simply run the application on your device using the steps mentioned here.


One of the most common ways of saving user preferences and properties in an application is by using NSUserDefaults. Read on →

iOS Application Security Part 19 – Programmatical Usage of Introspy

In this article, we will look at how we can Introspy as a python module in our scripts.

The first thing to do is to import the introspy module and Namespace from argparse module.


We then create an instance of the Introspy class. The arguments that we need to provide are the database name, the group name, the subgroup name and the list. Now, for this case, lets provide all the parameters as None except the database path. Introspy will hence include all the groups rather than just including a particular group.

Read on →


IOS Dev - Encrypting images and saving them in App Sandbox

One of the requirements in my latest project was to encrypt an image and save it on the device in the application’s sandbox, then decrypt is during runtime and upload it to the server. I looked at the documentation for Apple’s CommonCrypto Framework, but it was taking me plenty of time to implement it so instead i decided to use some wrappers that would get the job done for me. I found the RNCryptor library on Github that uses AES encrypton. It was pretty simple to implement it. First, download the files from its github url and include all the files that are relevant to you present inside the RNCryptor folder on your project. In my case, i just imported all of them for now.


Then use the following code to encrypt the image.

//  Code for encrypting and saveing image 
    UIImage *imageToEncrypt = [UIImage imageNamed:@"SomeImage"];
    NSString  *imagePath = [NSHomeDirectory() stringByAppendingPathComponent:@"Documents/encryptedImage.png"];

    NSData *data = UIImagePNGRepresentation(fetchedImage);
    NSError *error;
    NSData *encryptedData = [RNEncryptor encryptData:data
   [encryptedData writeToFile:imagePath atomically:YES];

Note that encryting and decrypting the image requires a passcode (ABC123). To decrypt the image, use the following code ..

 //  Code for loading image by decryption
    NSString  *imagePath = [NSHomeDirectory() stringByAppendingPathComponent:@"Documents/encryptedImage.png"];
    NSData *encryptedData = [NSData dataWithContentsOfFile:imagePath];
    NSData *decryptedData = [RNDecryptor decryptData:encryptedData
    UIImage *image = [UIImage imageWithData:decryptedData];

See, its pretty simple. If you have any questions, let me know in the comments secton below and i will get back to you.