a class variable like this:

@property (strong, nonatomic) NSString *privateValue;

Can someone read the value of that variable while it´s in memory? I can´t find anything about this on the apple docs and I also lack the understanding. Can someone give me hints for possible attacks?

  • Do you want to store something forbidden? Maybe keychain is the thing you're searching for. – ott-- Feb 24 '16 at 19:10

Yes, it is possible to read iOS class variables from outside of an app. Depending on your perspective and proclivity towards jailed or jailbroken devices, you may find a few ways to read them at runtime or in-memory.

Via runtime, on a jailbroken device, a tool such as NCC Group Introspy is a developer-friendly tool that doesn't require any formal reverse engineering exposure or experience.

For accessing memory in the iOS Simulator or on an iOS device, lldb and gdb can be utilized to dump an app's current memory state. One would need to identify the process to be dumped and perhaps overcome any self-modifying or self-checking code that would include process dumping. This typically requires either a Unix or a reverse engineering background. As a lighter approach, Xcode does provide a debugger, notification spy, and a DTrace interface. One common way of accessing memory without a debugger is to get an app to crash and then go through the artifacts found via the Xcode Organizer. Another way in the iOS Simulator is to go into the menu option Hardware and select the Simulate Memory Warning option.

For those who do have reverse engineering experience and a jailbroken device, be sure to check out Snoop-IT as a first-rate tool to go deeper than what Introspy above provides. Snoop-IT is also heavily covered in the books The Mobile Application Hacker's Handbook as well as Learning iOS Penetration Testing. However, my top recommendation for those who have gdb experience is to follow the techniques outlined by NetSPI to get access to the full app heap. Other techniques include using lldb on a jailbroken device by using a debugserver, which is even more-detailed on the mSecLab blog, but also covered on versprite, isa56k, and a bit on lldbpy via lifeform-labs. The last technique I might mention for jailbroken devices (or for any OS X install) is the kdv tool which utilizes the KDebug mechanism, although certainly other kernel memory dumping options are available such as readkmem. MEMSCAN and Radare (see the NetSPI blog post about adding the Radare repo to Cydia) can also be used to search through or dump process memory on an iOS jailbroken device.

There are a few techniques that can be accomplished while in the iOS Simulator. The recent book iOS Application Security covers many of these in-depth. I might also recommend that you check out some anti-anti-reversing techniques such as the ones typically done on OS X, as they will also apply to iOS. For example, a game trainer for OS X called Bit Slicer and its underlying techniques can be mapped. Basic problems with debugging (e.g., if the NetSPI gdb technique above does not work) can be worked out with idapython as seen when this author ran into a problem with anti-debugging during a MyWi reversing effort. As this article on anti-anti-debugging suggests, a catalog of techniques formalized as a GitHub project called pangu can be bypassed by another GitHub project named Onyx-the-Black-Cat. There are many other reversing challenges, so I suggest you check out the ReverseEngineering.StackExchange tagset for iOS or similar resource.

For jailed devices, I suggest you look into repackaging apps with cycript and/or Frida. If you can get a remote cycript shell, then you can use the mSecLab methods for analyzing memory of an app as one would do on a jailbroken device.


So there are a few actions you can take in general. I am not an Apple iOS developer, so I don't know if all these attacks are feasible. I'm merely trying to provide an overview of reverse engineering tactics.

  1. Debugger. Attaching a debugger like the one that comes standard with XCode (LLDBG) or another debugger can allow an attacker to view program values. Of course, without debug symbols and the like, it's a lot harder to find meaningful information. But, with enough time, patience, and resolve you can find this value. Of course, this means the app would be running in a development environment like an emulation environment, not a phone. But that can be arranged easily with Apple's dev toolchain.

  2. Source Code/binary modification. This is similar to the debugger. There are people out there that can unravel assembly and bytecode easily. Once that happens, it would be well within their means to modify a binary to print your private value. To retrieve a .ipa file (the app binary), you simply look in the iTunes library of the device, as detailed in this Think Different Answer.

  3. Memory Editors. These programs can look into the memory addresses allocated to a process. These tools usually require system-level access, but "jailbreaks" exist for Apple devices. It is possible that someone could create a memory editor app that looks at the memory space assigned to your app and looks for your private variable. This does require an advanced level of technical knowledge to pull off.

  4. Looking in device storage. If you cache that variable to disk at any point, you can use forensic techniques to read device storage and look at the cached data. Here's a sample photograph of someone using this technique to look at the data cached by Signal, a popular messaging app. Link to full tweet.

SANS has put a highly informative forensics guide for iPhones on their website. I will reproduce the relevant portion (Section 1.1.6) here, but I highly recommend reading it for more information and personal development.

When an application is obtained from the iTunes store, a new directory is automatically created in the Mobile/Application folder. This directory will hold the files associated with each application and will be assigned a 32 character alphanumeric unique identifier by Apple (Example: GA07A3WW- 0E39-33OJ-B947-9CAA16688G22). This unique id will be consistent across all iOS devices. Each application folder will typically have several common subfolders: documents folder for relevant files to that application, temp folder for temporary runtime files, library folder for preferences, and cached data. Common files are found within most applications folders such as info.plist, resourcerules.plist and applestores.db. Depending on the application, varying configuration files, plist files and XML data will be found. The examiner can occasionally find username and password data, cookies, or images that will help provide evidence for the investigation. ©2012 TheSANSInstitute

Further reading for technical implementations of #1 and #2:

  • The first 3 all require jail-breaking on iOS unless you are the developer, with 1 being done with GDB (or LLDB?), not XCode and Olly. – Alexander O'Mara Feb 24 '16 at 20:31
  • LLDB is the debugger in XCode. It comes standard with XCode 5+. #2 and #4 do not require root on your device, because #2 works directly on a copy of the .ipa file that can be retrieved trivially, and #4 does not require you to use iOS to access the cache. – Ohnana Feb 24 '16 at 20:52
  • #1 True, but AFAIK XCode's debugger is only useful for developers. Jail-breakers need to install the debugger on the device itself. I knew I guy who used GDB for this, not sure if LLDB is available in this way. – Alexander O'Mara Feb 24 '16 at 21:03
  • #2 Yes, you can obtain the IPA without jailbreaking, but how are you going to decrypt or re-codesign it? Last I knew, at least the main executable in the IPA is encrypted using Apple's DRM per-user, and only properly code-signed IPA's can be run. – Alexander O'Mara Feb 24 '16 at 21:05
  • @ Alexander: iOS apps (i.e., IPA files) can be decrypted and repackaged with an Apple dev cert (and in iOS 9, this is even less-so a requirement) to a non-jailbroken device. Please see this Security.StackExchange question and answer -- security.stackexchange.com/a/98326/140 – atdre Feb 24 '16 at 22:39

All the variables that are used by an application are stored in the memory. But the memory is not a part of the things that are affected by the iOS app sandbox. The app sandbox cares about the files you can access to limit the impact a breach can have.

Anyway one application can't access the memory of another application. This is not possible because the operation system manages the memory and provides a virtual address space to every process. This means every process looks at the memory as if there were no other processes but itself.

To access the memory of another process the user needs root (UNIX) or administrative (Windows) privileges. A user with these privilges can use methods provided by the OS to dump the memory of any process. If the attacker wants to dump the whole memory there are no such tools in place by default but it's possible to inject drivers (Windows) or to install a kernel module (UNIX) to access the memory directly.

  • You shouldn't need a kernel module to access the memory of another process, just root access to run certain functions like task_for_pid. – Alexander O'Mara Feb 24 '16 at 20:27
  • Okay you are right but what I ment was ways to dump the whole memory to examine it... – davidb Feb 24 '16 at 22:14
  • The last sentence is not true. Unix-derived systems have ptrace and Windows has ReadProcessMemory. – immibis Feb 25 '16 at 0:52
  • @immibis Apple's ptrace also isn't quite as capable as other Unix system, hence the need for task_for_pid etc. – Alexander O'Mara Feb 25 '16 at 1:08
  • Edited post to make the point clear... – davidb Feb 25 '16 at 8:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.