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?
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.
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.
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.
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.
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.
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.
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:
