This blog is a simple guide for performing runtime analysis on iOS apps using GDB. With use of GDB we can get an in-depth knowledge of the application and not restricting to that, it also allows us to set breakpoints and manipulate the values and completely change the execution flow of the application.
We have crafted a vulnerable iOS application for understanding and to learn to use GDB to perform runtime analysis, with our crafted vulnerable app known as ‘swizzle-me’.
Introduction to the app.
The app ‘swizzle-me’ is a simple authentication app, wherein the user is required to enter his/her valid credentials and get access to the application.
App’s challenge: Your task is to bypass this login mechanism of the application and access the authenticated page!
Screens of the application:
If wrong password is entered
The application shows an error message stating the “Entered Credentials are incorrect”.
Once, the correct credentials are entered the application greets the user with a ‘successful login page’
Now login to the device:
Now run the ‘swizzle-me’ app on your device. And attach GDB to the app’s running process. For this use the command attach gdb <pid_of_swizzle-me>, here we got the pid for the app as 780.
Now, lets attach the process.
Before going ahead lets take a look at the code, and identify the method which is responsible for performing the authentication in the app
You can use the class-dump-z to get the entire class dump of the application, there by gaining the knowledge of the methods of the application. Now, that we know the method responsible for authenticating the user, we shall put a breakpoint on this method. Method name “authenticate”.
As we have already set the breakpoint at the ‘authenticate’ method, lets enter any username and password in the app and press on check,
Now, use the disas to print the disassembly for this function.
And as it is known that the validation of the username and password is happening within this function (authenticate), and by looking at the disassembly we do not find any other interesting method related to our application.
Other way to look around for a method is to look for obj_msgSend function. Remember the obj_msgSend function is executed when an external function is called. Also, an app can have multiple obj_msgSend calls.
Considering our given scenario, we shall point out all the addresses of all those instructions who call the obj_msgSend, and put a breakpoint to it. A very simple way to do it is to look for the blx instruction, note its address and set a breakpoint for it and keep on pressing c (continue) until the next breakpoint is hit.
As we have set the breakpoint to our function, we now try to print out the values stored in it. Taking the advantage of objective-c, we understand that every object is a pointer.Thus providing pointer we will try to get inside the registers and see what value it has. To find out the value, we use ‘po’ command to print the value of the object.
With the use of ‘po’ command we could get the actual values of the objects.
As seen in the above image we have got the values ‘Hacker’ and ‘Theforceiswithyou’ , by looking at it we can surely tell that this must be the hardcoded username and password for the ‘swizzle-me’ app.
Our next step would be to try to enter the received values as app’s credentials.
Reference
https://blog.netspi.com/ios-tutorial-dumping-the-application-heap-from-memory/
http://resources.infosecinstitute.com/ios-application-security-part-22-runtime-analysis-manipulation-using-gdb/#gref
http://www.iicybersecurity.com/pentesting-cracking-analysis-ios-apps.html
