Pimskeks is an IT expert from Germany, and CEO of a company he founded, samaraIT. He also got his first iPhone in 2008, and develops on Linux but switched over to Mac. He has developed some tweaks since 2010, and joined the Chronic Dev Team in 2010 as well. He has since been developing exploits for iOS.
@planetbeing started to look for kernel vulnerabilities in late 2012, and found a dyld vulnerability allowing for execution of unsigned code, but not all of the required jailbreak elements had been discovered yet.
When Apple moved from iOS 5 to 6, they implemented a security feature to disallow access userland memory from the kernel. The added KASLR also obfuscated objects and calling functions making it harder to reverse engineer the programming. LaunchDaemons are loaded from signed dyld and daemons on the filesystem are ignored.
/etc/launchd.conf weakness: used for jailbreaks since Corona untether (that’s a pretty long time ago) able to execute launchd command.
@pimskeks states that to run unsigned code, the dylibs have to be signed so long as they have ‘executable pages’ (A.K.A code). Although, you can trick dyld with a special dylib containing a second Mach-O header to load a dylib with no executable pages or signature.
Another weakness in iOS 6 is its code signing weakness, which makes kernel calls to the daemon amdif to verify code signatures. Since amfid uses libmis.dylib to verify MISValidateSignature, it can be overridden to return 0 which essentially disables signature checking, allowing unsigned code to be executed. This is what we all know as part of the iOS 6.1.2 exploit, fixed in 6.1.3.
@planetbeing found two separate vulnerabilities in IOSBDeviceInterface, allowing for the creating of ‘primitives’ to initiate other kernel exploits. This exploit was also fixed in iOS 6.1.3. He also attempted to leak memory through iOS panic logs but it wasn’t working correctly on the iPad Mini, so he jumped to what is known as the ARM data abort handler, leaking the kernel thread register state, effectively bypassing KASLR.
iOS’s filesystem is mounted as a read-only, so it has to be be re-rooted will full permissions. Instead, launchctl is used to run commands through root, using the shebang:
This allows applications to be run. To add the evasi0n icon, com.apple.mobile.installation.plist must be modified to have it show up on your SpringBoard. Rather than adding their own entry, they modified the plist data in Apple’s hidden video-looping DemoApp to trick iOS into allowing access to the evasi0n installer. To overwrite DemoApp.app, the directory Media/Recordings is used to hold the files temporarily, and then iOS is tricked into overwriting the original app.
Furthermore, there were flaws in lockdownd through socket exploits allowing for a _chmod, a command used to change permissions. He went ahead and changed the permissions of /private/var/db/timezone to 777, which represents full file access. Using exploited symlinks, iOS can be tricked to do many file reading and writing, but many of such exploits have been fixed in iOS 7.
@pimskeks did a great job during his conference! He went above and beyond, probably answered many questions that security developers may have had.
Since I probably missed some things due to the large amount of information, included below are the slides used during @pimskeks’ presentation: