Sniffing iOS traffic using remote virtual interface...

Today I learned something new =)

It is possible to sniff the traffic from an iOS device without the need for a proxy or jailbreak!

If you have a mac there is a command "rvictl" that allows you to capture any traffic for an attached mobile device.

Simply attach a device via the USB cable and run the command rvictl with -s to start the capture and the udid of the device attached.

rvictl -s <udid> 

This will create a virtual interface:

You can now use tcpdump or wireshark to capture the traffic.

 sudo tcpdump -i rvi0 -n -vv

Handy little trick for troubleshooting and sniffing traffic that I didn't know existed. I think it will only capture WiFi traffic, I haven't played to see if it will grab mobile network traffic.

Every day's a skool day!

class-dump-z armv7 & armv7s

I recently tried to class dump from an iPhone application that was running on an iPhone5s (7.0.4). After firing up class-dump-z and running, nothing seemed to happen, class-dump-z just hung.

Wondering if this was something to do with 64bit and the iPhone5s I decided to run lipo on the binary to check it out:

lipo -info Prometheus

Hmm, armv7 & armv7s. Had a look at the help options on class-dump-z and noticed that there was an option to select the architecture using -u. I tried the following:

class-dump-z -u armv7 Prometheus

class-dump-z -u armv7s Prometheus

Aagain, nothing.

Next option was to extract armv7 & armv7s from the binary using lipo as below:

lipo Prometheus -extract armv7 -output Prometheus-armv7

lipo Prometheus -extract armv7s -output Prometheus-armv7s

I then ran class-dump-z against each, for some reason the armv7 binary didn't dump...

But armv7s did which was enough for now, why it doesn't work using the -u option I'm not sure...

Get lucky... #CES2014 iBeacon Scavenger Hunt

Last week the consumer electronics show (CES2014) was on in Las Vegas. A lot of new tech was on show from 4k ultra hd TVs to e-ciggs! To accompany the show an iPhone app was released to help delegates find stands, each other, talks and panel discussions. As well as all this a scavenger hunt was built into the app using the new iBeacon technology available iOS7. The purpose of the hunt was to find each the beacons located around the show, when you are in range of a beacon you get notified and then the beacon is marked as found in the application. First to find all the beacons gets a prize.... W00t! 

As I have been looking into blue tooth low energy and iBeacons for a customer I decided to reverse the application and see if I could "find" all the beacons from the comfort of my seat :)

So what is an iBeacon?

The Apple web site describes them as….

"iBeacon is a new technology that extends Location Services in iOS. Your iOS device can alert apps when you approach or leave a location with an iBeacon. In addition to monitoring location, an app can estimate your proximity to an iBeacon (for example, a display or checkout counter in a retail store). Instead of using latitude and longitude to define the location, iBeacon uses a Bluetooth low energy signal, which iOS devices detect. To learn more about Bluetooth technology, see the official Bluetooth website."

Basically an iBeacon is a BTLE chip that is emitting a UUID, a major location, and a minor location. You end up having something like:

UUID: 3D481CE6-DAC4-48E1-AA8C-8BACD8C24557
Major: 1
Minor: 65001

This is broadcast and the iOS application is scanning for the UUID, you can also include the major if this is not likely to change. When they are found by the application it does something, e.g. calculate proximity let the user know they are close by or have just left the area. A better technical write up is available here. Also the Apple developer documentation is available here.

There is a lot of hype starting to surround them and that seems to have gained since CES2014, I guess many of the journalists at the event saw the scavenger hunt. (See links below).

http://www.cultofmac.com/261988/apples-ibeacon-hyped/

http://9to5mac.com/2014/01/02/ces-2014-to-host-ibeacon-scavenger-hunt-w-official-mobile-apps/

http://blogs.computerworld.com/ios/23344/apple-ibeacon-tech-lights-ces-2014 

How was I going to win the competition without moving to far?

I installed the CES application on my jailbroken iPhone and had a nose around. I used libimobiledevice  to start pulling back the syslog to my laptop, you can also do this using the iPhone configuration utility too. I prefer idevicesyslog in libimobiledevice a it doesn’t jump around so much on the terminal when you are looking at the console/log.

When I fired the application up and started the scavenger hunt I noticed what looked like the UUID and some minor numbers:

Now I had these all I needed to find was the Major and I could spoof beacons.

I ssh’d onto the device and located the application, dumped it and decrypted it using clutch. Clutch is a favourite of crackers but also very handy for hackers / pen testers to dump and application to be read in IDApro, hopper, class-dump-z or whatever. I ran strings on the binary, which showed up a few references to beacon and UUID but nothing to concrete. No major found here.

I continued to look around the sub directories of the application and found a few SQLite databases which looked promising, the names of the tables sounded like they would hold the details of iBeacons that were found. I looked inside each of the tables but again, nothing.

I then found a plist that looked like a default preferences file which had some interesting stuff in it and some reference to sh_targets. I assumed this was scavenger hunt targets. The data inside the key sh_target_list was all hex: 

I grabbed it and chucked it into a hex 2 ASCII converter available on the internets... Hmm looked a lot like a binary plist. 

I copied the hex from the original plist into a file and converted from hex into a binary file using xxd as below:

xxd -r -p ces.hex ces.plist

I could now convert this into xml using plutil

plutil -convert xml1 ces.plist

Now I had a plist I could look at in Xcode or any other text editor. Once opened, it was easy to see the dev had embedded the details of a found beacon inside the plist and also the minor id’s, which matched up with what I had found in the log. 

This left me with two options, I keep looking for the major and spoof each beacon or I see if I can set the individual beacons to found = YES in the plist.

After hunting around a little bit longer for the major I decided the quickest route to success would be by trying to set the found key to = YES.

To get everything back into the right order I would need to do the following:

• Edit the plist with the keys ‘found' and ‘i_beacon_minor' in and set the found key to YES
• Use plutil to convert the plist back to binary
• Grab a hex dump of the modified plist and copy hex back into the default preferences plist.
• Convert the default preferences plist back to binary and then copy over to my device and replace the old file.

Set key value to true:

Convert back to binary plist:

plutil -convert binary ces.plist

I then used hexfiend to dump the hex, I guess I could of used hex dump or xxd but hexfeind forted the hex nicely and didn’t grab the offset when doing cut and paste:

Once pasted into the default preferences post I now had all I needed to win.

I SCP'd it over to the device and fired up the application… WINNER

I’m not sure what would have happened if I had tried to claim the prize remotely? I’m guessing that they may have had some metrics that could have identified how quickly I found each beacon, making it physically impossible to have visited each beacon individually. However with some further digging I‘m sure I could have found the major ID and spoofed each beacon with a raspberry Pi or another iOS device. Setting some reasonable times between each it could have been believable.... A free 4K UHD curved TV would have been good =D

If you are planning to use iBeacons for prizes or some kind of promotion code then I would suggest you use a web server backend with reasonable protection to stop this kind of hack, it wasn’t that hard and could be done pretty quickly. 

If you believe the hype iBeacons have a big future, it will be interesting to see the implementations and how people secure them properly.

Decrypting iOS Kernel Cache (A4 CPU Devices)

Decrypting the iOS kernel cache on devices with an A4 or lower CPU is relatively straight forward thanks to the limera1n boot exploit. This allows the extraction of the IV & Keys for each file within the IPSW software bundle which are published on the iPhone Wiki. Each time new firmware package is released the keys are updated.

I believe it is possible to dump the kernel cache from a device with an A5 and greater chip but so far I haven't played with this. This has to be done from memory rather than extracting from the IPSW which is more complex.

To decrypt your kernel  you first need to download a copy of the IPSW package for your device, I'm going to use the iPhone 4 GSM 7.0.4 firmware available here:

http://appldnld.apple.com/iOS7/031-1831.20131114.P3wE4/iPhone3,1_7.0.4_11B554a_Restore.ipsw

Once the firmware has downloaded you can simply unzip the IPSW file and extract the contents, you should have the following:

The file you are interested in is kernelcache.release.xx. In this instance, the file we want is kernelcache.release.n90. n90 is specific device identifier for the iPhone 4, each device will have it's own identifier. If you are using an iPad or iPod then the identifier here will be different.

The kernel is an img3 format file that is encrypted and also compressed using lzss so we need to decrypt it then decompress it.

To decrypt you can use either xpwn or decodeimg3, I opted for decodeimg3 as it was a single perl script! You can download decodeimg3 from here:

http://nah6.com/~itsme/cvs-xdadevtools/iphone/tools/decodeimg3.pl

I had a couple of issues running the script first off as I didn't have "Crypt::Rijndael" perl module installed (info on installing perl modules here). Once this was installed it worked fine.

To decrypt the kernelcache you will also need the IV and Key from the iPhone wiki for the specific firmware build you are interested in. The iPhone 4 GSM IV & Key can be found here:

http://theiphonewiki.com/wiki/InnsbruckTaos_11B554a_(iPhone_4_GSM)

Once you are on that page locate the IV & Key for kernelcache.release.n90 as below, you will need them in a minute:

To decrypt your extracted kernel use the following command:

$ ./decodeimg3 <YOUR KERNEL> -v -o <DECRYPTED KERNEL> -k <KEY FROM WIKI> -iv <IV FROM WIKI> 

• <YOUR KERNEL> = kernelcache.release.n90 we extracted from IPSW earlier.
• -v = Verbose
• -o = Output file, I use the same file name and append .lzss as it is easy to see it's lzss for decompressing.
• -k = Key from wiki
• -iv = IV from wiki

Below is the output from decrypting the kernel:

Next step is to decompress the kernel using lzssdec, the source code can be found here:

http://nah6.com/~itsme/cvs-xdadevtools/iphone/tools/lzssdec.cpp

You will need to compile this, I used the following command to compile it on OSX:

$ g++ lzssdec.cpp -o lzssdec

Now you need to know the offset at where the lzss section starts. Opening the decrypted and uncompressed kernel in a hex editor and looking for 0xFEEDFACE should show you the offset. The screen shot below shows this:

The offset we need is 0x0180 to decompress our kernelcache.release.n90.lzss file.

Using the lzssdec tool we compiled earlier, the correct offset and our decrypted kernel, we can now decompress to give us a mach-0 arm binary using the command below: 

$ lzssdec -o 0x0180 < kernelcache.release.n90.lzss > kernelcache.release.n90.cleartext

To check you have a decrypted and decompressed mach-o ARM binary use the following:

$ file kernelcache.release.n90.cleartext 

 The binary should open up in IDAPro or Hopper so you can disassemble and reverse the kernel further :)

Thanks...

1.  Willem Hengeveld for his scripts and tools (decodeimg3 & lzssdec).
2. Jonathan Levin for the book OSX & iOS Internals, an excellent reference.
3. The iPhoneWiki, best iOS resource on the www!