Decrypting IOS app to access Class Information

The purpose of this post is to shed some light on the process of accessing the inner details of the source code of an IOS app, any third-party libraries it uses, and how it was designed.

You are probably asking yourself what could be gained from doing so and the answer may differ from one person to another, whether it is pure admiration of a cool app, checking if an app has any malicious or sketchy code that would warrant concern to the user, etc.

For the purpose of this tutorial, I will be using

To begin, we need the following:

A Jailbroken idevice

Cydia packages

BigBoss Recommended Tools (From BigBoss Repo)

classdumpz (From cydia.radare.org repo)

Core Utilities

GNU Debugger (From cydia.radare.org repo)

OpenSSH

OpenSSL

An FTP client on Windows or Mac OS X

If you do not have a jailbroken device, you will need to do so by visiting idownloadblog at the following link

Once you have jailbroken your device, head on to Cydia and install the packages included above, I faced several issues with the decrypting applications in IOS 7 due to some incompatibilities between IOS 7 and the debugging tools in the BigBoss repository which is why I included GNU Debugger from cydia.radare.org even though a version exists in BigBoss.

For example: The GNU Debugger installed with “BigBoss Recommended Tools” is at this moment 1518-12, however, the compatible version that works with IOS 7 is 1708.

Now let’s start decrypting the application:

The first step is to find the application of interest, usually it could be found in /Application but as you can see in the screenshot below, MaaS360 is nowhere to be found:

ls /Applications

So we will use the find command to locate the app in question:

find / -name "Gmail*"

Note: A more complex command but more accurate method of finding the application is:

find / -type d -iname "Gmail*.app"

Aha we found the directory, under /private/var/mobile/Applications/CAF8206F-8348-4AB4-B167-2FE77D15DDBB/GmailHybrid.app

For those wondering, the “CAF8206F-8348-4AB4-B167-2FE77D15DDBB” is the GUID for the MaaS360 application which is short for “Globally Unique Identifier”, a unique 128-bit number to represent that application.

We would then go into the directory and find what architectures are in the binary and whether the application uses “PIE” (Position Independent Executables) which means the app’s code, data, and stack memory addresses are changing every time you run the app using randomization. This provides an additional layer of security/protection as it makes Return Oriented Programming (ROP) attacks much more difficult to execute reliably and the decryption of these applications difficult as well.

otool -arch all -Vh GmailHybrid

Luckily the application was only built for one architecture (ARM), otherwise you would need to find and decrypt the architecture that matches the device you are running it on (Possibly a blog post for another day)

It does however show me that the application was packaged using PIE which will affect change how we get the base address later in this article.

Now we will need to find the base address by running “info sharedlibrary” but the output is rather large and will scroll off the screen so we will first set the pager to 20 lines

(gdb) set height 20
(gdb) info sharedlibrary

So how we know that the base address is 0xb000 (45056), we would then calculate the start and end section of the memory that has the unencrypted version of the application. Remember we had found the cryptoff to be 16384 and cryptsize to be 13828096.

Congrats, now you have a decrypted version of the application stored in that decrypted.bin file. Since we are done with the application, we can safely kill it and then quit the debugger

It is now a good idea to take a backup of your application file in case something went wrong, you can do so by opening up your favorite ftp client application and browsing the application directory then copying it locally on your PC.

The next step would be to overwrite the decrypted version over the encrypted one inside the application file.

Again remember the cryptoff is 16384 which means we will need to skip those number of bytes when writing back to the application

dd seek=16384 bs=1 conv=notrunc if=./decrypted.bin of=./GmailHybrid

If all goes well, you should be able to still use otool on the application, however, the cryptid is still 1 because the application still thinks it is encrypted.

To solve this problem, we will use the ftp client to copy the modified application to your desktop and load it in a hex editor, for the purpose of this part I used “Hex Workshop”.

We will then look for the following hexadecimal value “010000000C00000034” which should be right before “/usr/lib/libresolv.9.dylib” shown in the figures below:

Once found, we will replace the 01 with 00 and try rerunning the otool command

otool -l GmailHybrid | grep crypt

Now if we try to access the class information now, we will see a HUGE difference:

Now you can explore the class information of your application to find possible security exploits that you can use to your advantage.

If you have any problems, questions, or concerns please leave a comment below.

24 Responses to Decrypting IOS app to access Class Information

where can i found my zhit? all good but what is that We will then look for the following hexadecimal value “010000000C00000034″ which should be right before “/usr/lib/libresolv.9.dylib” shown in the figures below: ?? where u got it??

Not sure I understand the exact question but I listed my sources at the end of the article.

The 010000000C000000034 is a unique location in the hex code of the app file that stores the value for the cryptid (Status of encryption 1 for true and 0 for false) which is why we changed that 01 to 00. It is telling the operating system that the app is not encrypted anymore

Normally, that error is an incompatibility of gdb with the iOS device architecture.

What version of GNU Debugger do you have installed in cydia? In the beginning of the post, I recommended the one found on GNU Debugger from the cydia.radare.org repo (Version 1708 is the latest as of date)

If you have a version lower than 1708, I recommend updating to it first and try running gdb again.

Another possible reason you could be getting that error is due to having a device with A6/A6X Chip or higher (iPhone 5, 5C, and 5S) which supports only ARMv7 and not ARMv6 instruction sets so try running the gdb with the -arch flag (For example “-arch ARMv7”).

Let me know how it goes and if needed, you can contact me directly via email at tmrashed@gmail.com with the output of the following commands:

Hello Timour, i have the same problem and i’m searching for 3 days till now, i can’t decrypt any app cause i cannot dump anything, getting error “illegal instruction: 4”, my device is iPhone 5s which an 64-bit, so i think this is the probelm i don’t know, thanks in advance.

As far as I understood, the encrypted part of the application is decrypted before is loaded into memory, right? But how the application continues working when we replace the encrypted part with the decrypted?

Regarding your guide, I cannot seem to find the “010000000C00000034” value in the GmailHybrid (not even /usr/lib/libresolv).

I also noticed that the cryptsize is a lot smaller in my case (~2M, while yours is ~13M).

Also the first 2.423 bytes of the decrypted.bin is empty, does this make sense?

That’s right, the main idea is that the iphone itself can not work with the application until it is decrypted. So what we do is let the iphone do the heavy lifting of decrypting of the application which it then stores a copy of in the memory.

We then take the opportunity of having a decrypted out for grabs and dump it into a file (Take our own copy for later use)

We then replace the encrypted part with the decrypted one and then mark the application as not encrypted.

The reason why the application still works is that when it is loaded, the iphone looks at that 01 or 00 flag header in the value before “/usr/lib/libresolv.9.dylib” and figures out it is not encrypted and copies the application as is into the memory.

Regarding your concern with not finding the “010000000C00000034″ value in the GmailHybrid nor the /usr/lib/libresolv, please feel free to send me an email with the output of this command “dd seek=16384 bs=1 conv=notrunc if=./decrypted.bin of=./GmailHybrid” and I will take a look at it and resolve the issue.

Regarding the cyptsize, it doesn’t matter what the actual size is, however, it is important to take a note of it since it is used to calculate the end address as follows:

End Address =base address + cryptoff + cryptize

Which will then be used in the dumping of the memory
(gdb) dump memory decrypted.bin 61440 EndAddress Value

dd seek=16384 bs=1 conv=notrunc if=./decrypted.bin of=./GmailHybrid

Hope that helps and if you need to send me a direct email, you can reach me at tmrashed@gmail.com

for the value “010000000C00000034″ mine is “010000000C00000030″ I’m not sure if it’s the same value for all. keep an eye on “010000000C000000XX″ in the first few lines if u found anything similar change “01” to “00” and test it with otool.
I need help the decrypted file crash :@ ???!!!
otool -l GmailHybrid | grep crypt
cryptoff 16384
cryptsize 2129920
cryptid 0

I followed your steps, but got stuck on attaching gdb to my app. I always get an segmentation fault:11?!? Can you tell me how to avoid this and what this for an error is? Google says somthing about bad pointer adresses and so on.
Thanks for your help.

Luckily the application was only built for one architecture (ARM), otherwise you would need to find and decrypt the architecture that matches the device you are running it on (Possibly a blog post for another day)

For your effort. It was very helpful for me, as it helps me to get the answer to the question about the jailbreaking,
I may look forward to knowing more about your different articles as you update and keep writing good things
Thank You