Analyzing iOS application files to manipulate objective C functions is not a trivial process. The most common way to perform reverse engineering is by class dumping ipa files to discover all the class names and methods present in an application. This can be done using Cycript. Cycript is present within Cydia, and Cydia is installed by default when we jailbreak an iOS device.
A common way to manipulate the run time environment is by calling methods present within an application. Any process can be hooked with Cycript using the following steps:
Attach to the process using Cycript
Print all the method and class names
Replacing existing Objective-C methods using MobileSubstrate framework.
A more technical and step by step process to perform the above process is given on the iPhone Dev Wiki.
The most difficult and time consuming part is recognizing the classes and the objects used to call required methods. The traditional approach is to perform a class dump of the binary to get the methods that can be invoked.
We can use ‘Crackulous‘ to dump out the unencrypted version of the application and use ‘class-dump-z‘ to spit out the method names present in the _OBJC segment. There are also a couple of tools (iNalyzer and Snoop-it) that save a lot of time and perform reverse engineering and function hooking for the entire application.
I have analyzed the TWCSportsNet application in this blog. The reason why I choose this application is because it has two security controls implemented. It does not work if the following conditions are not met:
The device is a non jailbroken device.
The live streaming option is not available for any other region except Southern California and Nevada.
We will bypass those restrictions by using two modern tools called iNalyzer and Snoop-it.
iNalyzer is a handy tool developed by AppSec Labs. It creates an entire mapping of the application and dumps outs a doxygen script which is used to create an html page that shows all the method and class names. It also creates a graphical view of classes and functions using Graphviz.
In order to use this, we have to download a client side application on a jailbroken device. When the application is started, it will create a web listener on port 5544. We can connect to the port through our laptop by visiting https://iphoneIPaddress:5544.
Next we point iNalyzer to the application that we want to reverse engineer. iNalyzer will extract the entire application and create a zip file. After unzipping the file, there is a dox.template file present in appname/ Payload/Doxygen/ folder. This file can be given as an input to Doxygen and it will output an html file that consists of the mapping of the entire application.
Limits of iNalyzer:
It does not let us dynamically analyze the work flow of the application. For example, if we click a send button on an iOS application, we do not get to see the classes and the various methods that will be invoked.
Fig 1: Showing iNalyzer output for the TWCSportsNet application.
iNalyzer helps in interacting with applications by dynamically and invoking methods. It uses Cycript as the base to do so. However, I was not able to perform any dynamic interaction with the application using iNalyzer. I used a different tool called Snoop-It to interact and invoke different methods.
Snoop-it is an amazing tool developed by Neso Labs. It is used to perform comprehensive dynamic analysis. We can trace and manipulate internal state and the processing logic of iOS application. We can install Snoop-it by adding the https://repo.nesolabs.de/ repository via Cydia on a Jailbroken device.
Snoop-it has various features within it such as avoiding detection of a jailbroken iOS device.
Most of the applications detect jailbroken devices by looking for common paths like the Cydia installation directory (/Applications/Cydia.app) or /private/var/stash. Normal methodology without using any new tools like iNalyzer or Snoop-it would consist of identifying the functionality which detects jailbroken devices, and then performs function hooking using MobileSubstrate tweak.
Bypass jailbreak detection:
Fig. 2: Before and After using Snoop-It
Analyzing Objective-C Classes.
Fig 3: BestEffortLocation method contains my actual latitude and longitude
When I looked at the class LocationServicesManager there is a BestEffortLocation method which stores my current location.
Fig 4: Function which sets a Boolean flag depending on user’s current location.
Monitor application activity via Method Tracing.
The location has been updated and sent to the server through an HTTP request which sends my current latitude and longitude. We can trace the calls and corresponding methods when any kind of activity is performed by enabling the Method Tracing functionality.
Fig 5: Longitude and latitude been send via footprint service.
Intercept the request and change the location via Burp.
Fig 6: Intercepted and modified request using burp.
Fig. 7: Before and After changing the location
The request can be intercepted and by changing the longitude and latitude to a location in Los Angeles, we can view live television and bypass the location restriction. Although this could be performed directly via manipulation of parameters via a proxy, Snoop-it and iNalyzer gives us an in-depth view about the inner functionality of the application.
Spoof location and Fake UDID, Mac address of the device.
Fig 8: Fake location and fake UDID.
There are various other functionalities like monitoring the file system, checking out stored values in keychains and looking at the network traffic which can come in handy to save time during penetration testing of iOS applications.
Conclusion:
To conclude, Snoop-it and iNalyzer make reverse engineering fun and less time consuming. It gives a gray box approach to penetration testing of iOS applications.
I have taken a look at a lot of Mobile Device Management (MDM) solutions lately to figure out how they are detecting rooted Android devices. Through some research I have discovered that many of these MDM solutions use similar methods to detect rooted devices. This usually involves looking for specific packages and files, directory permissions, and running certain commands. I won’t be disclosing which MDMs use which methods, but I will provide a list of packages, files, folders, and commands that I have found to be used in root detection. All the commands I will be running are on a stock rooted Nexus 4 running Android 4.2.2.
Default Files & Configurations
The first root detection checks are for default files and configurations that should be present on a non-rooted device. These may also be present in rooted devices with non-custom roms.
Checking the BUILD tag for test-keys. By default, stock Android ROMs from Google are built with release-keys tags. If test-keys are present, this can mean that the Android build on the device is either a developer build or an unofficial Google build. My Nexus 4 is running stock Android from Google’s (Android Open Source Project) AOSP. This is why my build tags show release-keys.
Checking for Over The Air (OTA) certs. By default, Android is updated OTA using public certs from Google. If the certs are not there, this usually means that there is a custom ROM installed which is updated through other means. My Nexus 4 has no custom ROM and is updated through Google. Updating my device however, will probably break root.
root@android:/ # ls -l /etc/security/otacerts.zip
ls -l /etc/security/otacerts.zip
-rw-r--r-- root root 1733 2008-08-01 07:00 otacerts.zip
Installed Files & Packages
There are many files and packages that MDMs look for when detecting if a device is rooted. I have compiled a list of ones that I know for sure are being detected.
Superuser.apk. This package is most often looked for on rooted devices. Superuser allows the user to authorize applications to run as root on the device.
Other packages. The following list of packages are often looked for as well. The last two facilitate in temporarily hiding the su binary and disabling installed applications.
The following command lists packages that are currently installed on your device.
root@android:/ # pm list packages
package:com.android.backupconfirm
package:com.android.bluetooth
package:com.android.browser.provider
package:com.android.calculator2
package:eu.chainfire.supersu
Any chainfire package. One MDM looks for any package that is developed by chainfire. The most notable one being SuperSU.
Cyanogenmod.superuser. If the Cyanogenmod ROM is installed, the cyanogenmod.superuser activity may be in the com.android.settings package. This can be detected by listing the activities within com.android.settings.
Su Binaries. The following list of Su binaries are often looked for on rooted devices.
Can we read files in /data. The /data directory contains all the installed application files. By default, /data is not readable.
Commands
A few MDMs execute common commands to detect if a device is rooted.
Su. Execute su and then id to check if the current user has a uid of 0 or if it contains (root).
shell@android:/ $ su
shell@android:/ # id
uid=0(root) gid=0(root) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r)
Busybox. If a device has been rooted, more often then not Busybox has been installed as well. Busybox is a binary that provides many common linux commands. Running Busybox is a good indication that a device has been rooted.
This is probably no where near a complete list, but it does show the many different ways root can be detected on Android devices. Blacklisting packages and binaries seems to be the simplest and most effective way to detect root. This is especially true if your device is running a stock ROM from Google that has been rooted like mine where the only difference is the addition of su and a couple packages. At some point in the future I would like to create an app that will provide all these checks before installing an MDM. I touch on bypassing AirWatch root detection in my blog here: https://www.netspi.com/blog/entryid/192/bypassing-airwatch-root-restriction, however, AirWatch has made some changes so it may not work anymore depending on your environment.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
Name
Domain
Purpose
Expiry
Type
YSC
youtube.com
YouTube session cookie.
52 years
HTTP
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Name
Domain
Purpose
Expiry
Type
VISITOR_INFO1_LIVE
youtube.com
YouTube cookie.
6 months
HTTP
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
We do not use cookies of this type.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
We do not use cookies of this type.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
We do not use cookies of this type.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.