[Solved] W: GPG error: http://coredev.nl iphone Release

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.

References:

• http://imho.nu/iMHo/resize-root-partition/

iOS SSH over USB

Introduction:

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.

Detailed Steps:

Step 1: Make sure you have python installed on your machine. Download latest copy of “usbmuxd” using the command “git clone http://git.sukimashita.com/usbmuxd.git”.

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. 

References:

• http://marcansoft.com/blog/iphonelinux/usbmuxd/
• http://www.libimobiledevice.org/

Adding custom certificate to Android Trusted certificate store

Introduction

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.

Solution: Add the proxy certificate to android trusted store.

How:

Step 1: Download the latest copy of bouncycastle lib from http://www.bouncycastle.org/latest_releases.html into a folder called “lib”. During the making of this document, the latest version of the lib was v1.47.

Step 2: Extract a copy of the current certificate file ie. “cacerts.bks” from the android device using:

adb pull /system/etc/security/cacerts.bks

Step 3:Download a copy of the Charles Proxy certificate from the Charles website http://charlesproxy.com/charles.crt

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 

sudo keytool --keystore cacerts.bks --storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath "bcprov-jdk15on-147.jar" --storepass "" --importcert --trustcacerts --alias newalias --file charles.crt

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.

References:

• Android Guardian Project
• Persitent Trusted CA on Android Emulator

Decompiling Encrypted iOS binaries

Introduction:

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.

weak_classdump_bundle([NSBundle mainBundle],"/tmp/3847_decrypted_application")

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.

References:

• Weak Classdump by Elias Limneos.
• Ryan Petrich patches for Weak_Classdump

Reverse Engineering an iOS application

Introduction:

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. 

References:

• OS X Mac-O File format references

Reverse Engineering an Android application

Introduction:

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 DalvikVM which 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 Androidmarket via Google's website from where the user can download these APK files and install them on the Android device.

Requirements:

• Tool to unpack the .apk file : 7zip
• Tool to convert the .dex to a .jar file : dex2jar
• GUI tool for Java decompilation : JD-GUI
• The android apk file.

Detailed Steps:

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 apk file 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:

• Demystifying The Android Malware
• http://code.google.com/p/android-apktool/
• Detailed Guide to Android apk reversing

Back to Life

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 ;)