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)
- 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:
So we will use the find command to locate the app in question:
find / -name "Gmail*"
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.
Next we will display the status of the application’s encryption
cd /private/var/mobile/Applications/CAF8206F-8348-4AB4-B167-2FE77D15DDBB/GmailHybrid.app otool -l GmailHybrid | grep crypt
The cryptsize shows 13828096 bytes is the size of the file that is encrypted after the offset defined by the cryptoff
The cryptid shows that the application is indeed encrypted (1 is encrypted, 0 is unencrypted).
If we try to access the class information now, we wouldn’t get much
Now we will need to determine the base address which we will do by running the application and seeing where it gets loaded into the memory
# Look for running processes that have GmailHybrid in their name ps -ax | grep GmailHybrid
This showed that MaaS360 is running under process id 336
336 ?? 0:07.74 /var/mobile/Applications/CAF8206F-8348-4AB4-B167-2FE77D15DDBB/GmailHybrid.app/GmailHybrid
478 ttys003 0:00.01 grep GmailHybrid
# Load the process with process id 336 into the debugger tool gdb -p 336
(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.
Start address = base address + cryptoff = 45056+16384=61440
End Address =base address + cryptoff + cryptize = 45056+16384+13828096= 13889536
Now we need to dump that memory section:
(gdb) dump memory decrypted.bin 61440 13889536
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.