Over a million developers have joined DZone.

Anatomy of an Exploit: Get the Binary

DZone's Guide to

Anatomy of an Exploit: Get the Binary

In this part of Christopher Lamb's series, he takes us through a couple of ways that you can grab the jailbreak code.

· Mobile Zone
Free Resource

Launching an app doesn’t need to be daunting. Whether you’re just getting started or need a refresher on mobile app testing best practices, this guide is your resource! Brought to you in partnership with Perfecto

 find . -name -print  Alright, so if you've followed along this far, you have a mac with a disassembler and static binary analysis tools. You also have an iPhone that's been jailbroken, and you have static analysis tools installed there too.

Now, we're going to grab the jailbreak code. There are two ways to do this — I'll show you both of them.

Method #1: Grab From the Phone

This is what you'll usually do, using clutch. Clutch is one of the tools you can download from the iPhone Wiki reverse engineering tools page from the last article. iPhones are remarkably secure computers - the most secure I've ever worked with personally. The original and current designers widely used encryption to protect code and isolate execution. Clutch allows you to decrypt and save an executable image from an application you've installed from the app store. This is required if you're penetration testing a third party application, as they're all encrypted. Stock iPhone applications aren't, interestingly.

In this case, though, we don't need to use clutch as the jailbreaking code is unencrypted. Which makes sense, we didn't download it from the app store after all. We side-loaded it through XCode.

Anyway, let's take a look at the application and see what we can find.

Side-loaded Apps in 9.3.3 are installed in /private/var/containers/Bundle/Application. I found this by side loading the original application I created for the provisioning certificate and searching for the executable name (e.g.  find . -name -print  , if you're curious). So let's head over there. After I removed my provisioning app, only the jailbreak remains. A good thing too, because the apps are organized by UUID. As I only have one directory, I cd into it and see this: 

# ls

Well, that looks promising! Let's check it out. 

# ls PPJailbreakCarrier.app                                                                                                                    
AppIcon29x29\@2x.png       AppIcon60x60\@3x.png           LaunchImage-800-Portrait-736h\@3x.png                       
AppIcon29x29\@2x~ipad.png  AppIcon76x76\@2x~ipad.png      PPJailbreakCarrier*                                         
AppIcon29x29\@3x.png       AppIcon76x76~ipad.png          PkgInfo                                                     
AppIcon29x29~ipad.png      AppIcon83.5x83.5\@2x~ipad.png  WeiboSDK.bundle/                                            
AppIcon40x40\@2x.png       Assets.car                     _CodeSignature/                                             
AppIcon40x40\@2x~ipad.png  Base.lproj/                    embedded.mobileprovision                                    
AppIcon40x40\@3x.png       Info.plist                     helper.dat                                                  
AppIcon40x40~ipad.png      LaunchImage-568h\@2x.png       mer.db                                                      
AppIcon60x60\@2x.png       LaunchImage-700-568h\@2x.png   nvwa.dat

...and look, there to the right we see PPJailbreakCarrier*. That is the actual executable the bundle runs, and it's what we're looking for. Let's do a couple quick checks first:

# otool -h PPJailbreakCarrier                                                                                            
Mach header                                                                                                           
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags                                          
 0xfeedfacf 16777228          0  0x00           2    30       3888 0x00210085                              

Excellent! 0xfeedfacf is the magic number for an arm64 Mach-O executable, and 16777228 is the CPU type for arm64. One more check:

$ xxd PPJailbreakContainer | less
0000000: cffa edfe 0c00 0001 0000 0000 0200 0000  ................                                                    │
0000010: 1e00 0000 300f 0000 8500 2100 0000 0000  ....0.....!.....                                                    │
0000020: 1900 0000 4800 0000 5f5f 5041 4745 5a45  ....H...__PAGEZE                                                    │
(...much more omitted...)

See those first bytes? cffaedfe? ARM is little-endian, so these bytes align to be 0xFEEDFACF, the magic number for a 64-bit Mach file. Excellent! Let's get this over to our workstation.

On your Mac, do this:

$ scp -P <port for USBMUX SSH> root@localhost:/private/var/containers/Bundle/Application/0150E158-0B30-4964-A21E-3BED6C3B292D/PPJailbreakCarrier.app/PPJailbreakCarrier .

Now you have the executable on your system.

Method #2: Grab from IPA file

Okay, so the first method is much more involved, but I wanted to go through it so you had some idea of how to get executables off your iPhone in general. In this case, though, we have an unencrypted IPA file, remember? and IPA files are just ZIP archives.

So unzip the IPA, and look in the top folder. You'll find the PPJailbreakContainer executable there too. Go ahead and check it with otool, you'll get the same results.

We have an executable! Next time, let's start to take a close look at it.

Keep up with the latest DevTest Jargon with the latest Mobile DevTest Dictionary. Brought to you in partnership with Perfecto.

iphone ,jailbreak ,analysis

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}