Monday, 28 January 2013

Many times when i was installing "Theos"
on my iOS device everything went well till the last step which is "apt-get
update". When i ran the command, it would always give me an error "W: GPG error: http://coredev.nl iphone
Release: The following signatures couldn’t be verified because the public key
is not available: NO_PUBKEY" as shown in the below screenshot.

After much googling, i found this link which explains
the solution to this issue. Though the scenario in the link is different than
mine, however it seemed to work well for me :)

The solution was, navigate to the sources.list.d folder and add
the "public key" to
that folder. This can be done wither by using "lynx" or by using "wget".

A shown in the above screenshot, apt-get works well after the
above steps were followed.

Many a
times, at client side we are not provided with Wifi access and
connecting to our iOS device to read local data can be a real pain.
At such a period, we can use a tool called as “usbmuxd” to
connect to the Jailbroken iOS device running OpenSSH over the USB.

Step
2: Navigate to the “python-client” folder and run the command
“chmod +x tcprelay.py” and then run the tool using the command
“./tcprelay.py -t 22:2222”

The
“t” basically allows multiple threads to run so that multiple
simultaneous ssh connections can be established.

Step
3: Now, once the tcprelay starts its work, we use the command “ssh
root@localhost -p 2222” to forward the local port 2222 to remote
port 22. Use the credentials “root/alpine” to connect to the OpenSSH server running on the device.

Now,
all the commands which can be used over SSH can be run on the prompt
provided.

Android
maintains a list of trusted certificates any deviance in the
certificate would result in a error in connection. Below screenshot
shows how the browser gives a popup when we set the Android device to
forward the traffic to Burp Proxy instead of the actual server.

Once,
the user clicks on “Continue”, the user can continue to use the
application as per his requirement. However, in case of native
applications there is no “popup” and the connection is directly
rejected.

Step 4: Add the BouncyCastle library to your
machines existing Java. Once that is complete, use the below command
to add Charles certificate to the certificate store downloaded from
the device and sign it using the BouncyCastle library jar

Step 5: Now,
adb into the device and run the “mount” command to see where the
“system” directory is mounted.

In our
case, it was found to be mounted at “/dev/block/stl9”. Knowing
this, remount the system directory in read/write mode so as to push
the certificate store back on to the device. Then, run the command as
“mount -o remount,rw -t yaffs2 /dev/block/stl9 /system”
inside adb shell as root user.

Step 6: Then,
change the permissions set on the certicate store to world writeable
using “chmod 777 /system/etc/security/cacerts.bks” as root
user and the push the new cacerts.bks into the device using “adb
push cacerts.bks /system/etc/security/cacerts.bks”

Step 7: Now,
change the permissions back on the cacerts.bks file using “chmod
644 /system/etc/security/cacerts.bks” as root user.

Now,
restart the device and after that you can see that all the traffic
from the Android device can be intercepted on charles proxy without
any issue.

Similar
method can be applied to add Burp certificate on Android trusted
certificate store.

Sunday, 27 January 2013

In my previous article, i had described how you would normally go about decompiling an iOS application. That method would be working for a majority of applications. However, many a times the developers push in security feature to prevent the attackers from decompiling/debugging the application.In our case, though we are the developers friends and are testing the application, it would be good if we actually follow the same route as an attacker would. That way, we can understand what exact information is disclosed and how the application can be compromised.Requirements:

iOS device must be jailbroken.

OpenSSH should be installed on the iOS device.

SSH Client on your machine.

"Class Dump" should be installed on the iOS device via "Cydia"

"Cycript" should be installed on the iOS device via "Cydia".

Detailed Steps:

First we will try and use the same step as used in our previous post to dump the class file information via "class dump".

Below screenshot shows
one of such an instances when we use classdump to decompile an
application. The command run is of the same syntax as used earlier
but the content is unreadable.

In
such a case, using class dump alone would not be fruitful. We have to
use a tool called as "Cycript" along with “weak_classdump”
by Elias Limneos which is Cycript script that generates a header file
for the class passed to the function.

It can be used as
follows.

Step 1: Get the process
id of the running application to be decryped and decompiled using the
command "ps -ax | grep "App"".

The
above screenshot shows that the process id was "3785".

Step 2: Download the
latest copy of "weak_classdump.cy" from "weak_classdump" on to the working folder.

Then, use the below
command to inject weak_classdump into the application to be decrypted
and decompiled:

cycript -p
3785 weak_classdump.cy; cycript -p 3785

If, the injection was
successfull, you will get the message as 'Added weak_classdump to
"TWCTV" (3785)' where "TWCTV" is the application to
be decrypted and decompiled.

Step 3: Now, you will
get cy# where you will have to enter the below command to do the
actual decompilation and to dump the required info.

This step takes a lot
of time and you would get somthing like the screenbelow when the
process is complete.

Step
4: Now, exit cycript and you can access the complete decompiled
cleartext source at "/tmp/3847_decrypted_application".

The above screenshot
shows that the source code is in cleartext and can be easily
analysed and the function names and values can be hooked in the runtime using Mobile Substrate or Cycript to force the application to perform various malicious activities.

When you are PenTesting an iOS application, you would want to read the code of the provided application and understand the backend classes and hidden information. Using this, you can try and exploit the application to gain access to sensitive information or to redirect the flow of the application in an malicious manner.

Reverse Engineering an
iOS application is completely different as compared to an Android
apk. The complete original source code cannot be revivied from an
existing iOS application. Only, declarations for the classes,
categories and protocols can be decompiled from an given application.

Requirements:

iOS device must be jailbroken.

OpenSSH should be installed on the
iOS device.

SSH Client on your machine.

"Class Dump" should be installed on the iOS device via "Cydia"

Detailed
Steps:

Step
1: SSH in to your iOS device using credentials as root:alpine.

Step
2: Launch the application on your device and note down the
application location on your device using the "ps -ax |
grep "App"" command.

As shown in the above
diagram, the application is running from location “
/Applications/Stocks.app/Stocks”

Step 3: Navigate to
that location “/Applications/Stocks.app/” via the shell.

We will use “Class
dump” to reverse engineer this application. It is a command-line
utility for examining the Objective-C runtime information stored in
Mach-O files. It generates declarations for the classes, categories
and protocols. We will do
this using the command

class-dump Stocks >
/tmp/dinesh/Stockreversed.txt

As
shown in the below screenshot, the application was decompiled
properly and the header and implementation files are copied to
location /tmp/dinesh/
in the file Stockreversed.txt

Below screenshot shows
the contents of the file “Stockreversed.txt” is clearly readable
and all kinds of hidden secrets and logical flaws can be understood
from here.

The above screenshot
shows that the source code is in cleartext and can be easily
analysed.

Now that you have the declarations of the classes and the protocols you can go ahead an debug the application using GDB or, hook on to the functions present in the application via MobileSubstrate and try to change its behavior.

However, many a times this process is not so straight forward and the developers put in additional security feature to prevent the attackers from reversing the applications by using debugging techniques. The ways by which, we can bypass this restrictions and try and dump the class declarations in an encrypted iOS application would be explained in the next blog post.

The
Android compiler suite compiles the developer's Java files into class
files, and then the class files are converted into dex files. Dex
files are bytecode for the DalvikVMwhich
is a non-standard JVM that runs on Android applications. The XML
files are converted into a binary format that is optimized to create
small files. The dex files, binary XML files, and other resources,
which are required to run an application, are packaged into an
Android package file. These files have the .apk extension, but they
are just ZIP files. Once the APK package is generated, it is signed
with a developer's key and uploaded onto the Androidmarketvia
Google's website from where the user can download these APK files and
install them on the Android device.

Step 1: You can get the apk file matching your application to be reversed from the location /data/app/<application-name>. If you want, you can even use the tool AppSender from GooglePlay on your device which allows you to export any apk mapped to your application on your device as per your choice.

Step 2: Extract
the apkfile
using 7zip to view the contents of the .apk file. The .dex and the
.xml files that were discussed earlier in the article are shown in
below figure.

Step 3: The
next step will render a better view of the code using the 'dex2jar'
tool. A dex2jar tool kit converts the Dalvik executable .dex files
into Java .class files.

The
'classes.dex' file from our application is dropped into the dex2jar's
directory and converted using the command, dex2jar.bat classes.dex.

This
creates the 'classes.dex.dex2jar.jar' file in the same directory as
shown in below figure.

Step 4: To
view the readable format of the class files, we use the tool, JD-GUI.
Open the 'classes.dex.dex2jar.jar' file using JD-GUI.

This
depicts a systematic view of the complete source code of the
Android application.

Step 5: After
obtaining the complete source of the application, you can perform the
actual analysis of the source and check whether something is amiss.References and Good Reads:

Sunday, 20 January 2013

So I've been quite busy with work lately and could not complete the actual task which i had started this blog for. I had many long random posts on Kernel Exploitation here on this blog for some time before i finally decided to delete all of them.

I could not see myself making much progress on the topic and the cycle mentioned in my first blog post was failing miserably so i've moved on to better topics which i would actually be using in my day to day life :)

I've worked on a huge number of topics ranging from xmlhttp scripts, python codes, mobile testing methodologies to blah blah blah so it would not be possible to blog all of them but i'll try and keep this blog updated from now on.

Chao guys and hope i do not have to delete my blog again coz of some stoopid decisions :D

Ohh btw i am a fan of Dilbert and i just noticed that we both share some similar thoughts ;)