Thireus' Bl0g

Android and iOS devices are today a prime target for hackers, and for good reason, two of the main factors of the perfect attack are joined here while exceeding any of the attacker’s expectations.

This article is about the ironha1l Tool Suite I have created. This article is intended to provide an understandable explanation about the problematic I faced during my researches to develop ironha1l. You will also find in this article a lot of relevant information if you are a jailbreak beginner. Most of the information here are part of my own research but also comes from external sources. I tried to remain as reliable as possible. Feel free to comment my work!

Updates: (subscribe to my twitter to get notified)

• 10/10/2012 – ironha1l sources available!

Why attacking smartphones with smartphones?

The primary factor is the quality and relevance of the information available on iOS and Android devices. Smartphones like the iPhone and the Galaxy SIII to name but a few, have been created to assist a large majority of our daily activities. Consequently, they contain a huge amount of data about our life and habits such as address book, pictures, emails, text messages, GPS location data history and much more. We can also find web browser history and all cache, credentials and data of third party applications such as online banking applications.

The second factor is accessibility, and even more so, the huge amount of attack vectors. These operating systems are mainly used in mobile phone devices and provide many access points for potential attacks. First of all, the mobile aspect of these devices can be used for data injections via the baseband, meaning injections via 3G/Edge/GSM protocols with text messages and voice calls. And even further, some attacks can be made on SIM cards, for example spoofing adapters are mainly used today for unlocking. More wireless access points such as WiFi, Bluetooth, IrDa, NFC constitute a large part of the vector attack panel and can be used to remote access the targeted device. Finally, some last attack vectors such as USB, serial port, SD card reader, audio port, touchscreen and camera provide to the attacker some physical and potentially vulnerable access points.

About the PoC scenario and its limitations

The main idea I had about a smartphone security related scenario was to show the two aspects described in this foreword. The revolutionary aspect of these mobile operating systems in term of functionality versus their incredible weakness in term of security. Therefore, the attacker is equipped with an Android 4.0 (Ice Cream Sandwich) smartphone in the aim to access sensitive data of an iOS unjailbroken device such as iPhone 3GS/4, iPod Touch 3G/4G or iPad according to the limera1n exploit limitations. The iOS version does not matter here, as the limera1n exploit does not depend of the operating system version running on the device. The attacker has only one constraint, which is to use the USB port of both devices to inject data and proceed to the data theft from Android. The aim of the attacker is to get the maximum amount of sensitive data available on the iOS device, such as pictures, emails, contacts, etc. The attack must be fast and discreet (a few minutes), and must be cancellable at any time. The use of an Android smartphone as been preferred for these reasons, due to its discretion, offensive functionalities and performances.

In this article, the term iDevice is used to refer to any iOS devices vulnerable to the limera1n exploit.

Bypassing iOS security

Before going further it is important to enumerate some of the main security features available on iOS. The same goes for the architecture security features, particularly the boot process and partitioning system.

iOS partitioning system and its biggest security feature

All iDevices have the particularity to contains a 8GB to 64GB flash memory split in two distinct partitions. The first one in read only contains the operating system iOS while the other one is dedicated to user data and have read and write permissions. The data partition contains user documents, applications, pictures, and other various user files. This flash memory is hardware encrypted using an AES-256 crypto-processor soldered on the iDevice motherboard right on the path between flash memory and RAM. Meaning that anything that comes from the flash memory to go in RAM is decrypted and anything that comes from RAM to go in the flash memory is encrypted. Nothing can transit without being encrypted/decrypted by the crypto-processor, thus you cannot manually extract the flash memory and read data from it, because anything is encrypted with AES-256.

UID (Unique ID) and GID (Group ID) are two keys soldered inside the crypto-processor and used to encrypt or decrypt. These keys are only accessible by the crypto-processor itself, they cannot be software requested or dumped (hypothetically a covert channel attack could do the trick). The UID key is unique for any iDevice and is not registered in Apple Databases (but we do not have proof for that), the GID key is the same for iDevices of the same class, meaning for example that any iPhone 3GS will have  the same GID key but each one will have a unique UID key. On top of that, these keys can be combined in addition to the passcode key (derived from the user passcode to unlock the iDevice) or any other external key, which creates various protection classes.

These protection classes are then used to encrypt some user data on top of the already hardware encrypted flash memory. Thus, if you successfully access the data partition, some files will remain encrypted with either the passcode key or other external keys combined to the UID key, which is the case for emails for example. So once the iDevice is locked, files are completely secured due to the missing passcode key. And brute-forcing the passcode key can only be achieved on the iDevice, because the decrypt function is called inside the crypto-processor which combine the given key with the UID key.

According to iOS Hacker’s Handbook it takes about 18 minutes in the worst case scenario to bruteforce a 4 digits passcode (iOS default scheme), which is even worse if the user change his passcode for a alphanumerical passcode (in that case it can take years to bruteforce ). There are no time limitations in case you bruteforce the passcode directly by calling the decrypt function of the crypto-processor. But in the case you attempt to manually bruteforce the passcode directly from the iOS unlock screen you will face these limitations that exponentially increase when a wrong passcode is entered.

Fortunately for attackers, only a few amount of data files are encrypted using the passcode key. Most of the files remain unencrypted, and some protections I talked about here were implemented during the iOS development. Meaning that old iOS versions are less protected that the newest ones, unfortunately the ones I presented here are all integrated to iOS 5.

Various exploits but only one goal

There are three categories of exploits on iOS, each one refers to a particular boot module of iOS.

• Bootrom (also called SecureROM by Apple) Exploits
• iBoot Exploits
• Userland Exploits

Bootrom exploits are the most powerful, because the bootrom is the first piece of code executed on the iDevice boot process. This bootrom is read only and cannot be updated nor modified, it is soldered on the iDevice. Thus a bootrom vulnerability cannot be fixed by Apple on existing and already sold devices. Actually there are only one bootrom exploit, which is called limera1n and created by George Hotz. This bootrom vulnerability has not been patched by Apple until the next hardware revision with Apple A5 processors and upper (meaning iPhone 4S, iPad 2, etc.) only  iPhone 3GS/4, iPod Touch 3G/4G and iPad are vulnerable. The limera1n exploit breaks the signature check for any elements of the boot process, meaning you can boot with an alternated or custom boot chain. In addition to that a bootrom exploit can be used to decrypt Apple GID encrypted files contained in IPSW archives (used to restore or upgrade iDevices). IPSW contains iOS and various GID encrypted data, that can be decrypted using with such an exploit by calling the crypto-processor function that uses the GID key. Attackers can then patch and alter these decrypted files for their own purpose, inject and boot with these files by the use of limera1n.

iBoot is the boot process part that launches the iOS kernel. These kind of vulnerabilities can lead to an untethered Jailbreak. Finding a vulnerability at this level is as powerful as a bootrom vulnerability in term of functionalities. Unfortunately such a vulnerability can be quickly patched by Apple in a next iOS update. iBoot vulnerabilities are not used in ironha1l, but it is important to have in mind the entire boot process for the next part of this article.

Finally, userland vulnerabilities are at the top level of iOS at the same level of running iOS applications. Exploiting such a vulnerability is very hard, and only allows the attacker to access mobile (or root) privileges. But yet, the attacker needs first to get out of the sandboxed application where the vulnerability was exploited. I will not talk more about this kind of exploit here.

DFU mode

The DFU mode (Device Firmware Update) is a special mode in which the device loads a specific code from the bootrom. This mode is also available in the Nintendo DS for example, and is not Apple property. This executed code allows the device to accept boot elements from the sync port of the iDevice (I prefer calling it the USB port). This DFU mode is mainly used when the device is software bricked, and even if the classic restore mode of the iDevice is broken. The DFU mode once detected by iTunes will receive boot elements from it. Those elements are from the IPSW archive, and are composed of iBSS, iBEC, DeviceTree, KernelCache and Ramdisk. The ramdisk file is a container which contains a very basic version of iOS only used to flash the device with a new iOS version sent by iTunes. This ramdisk is a very good basis for an attacker to access the iDevice partitions.

To put your iDevice in DFU mode, you first need to connect it to a USB host device, to boot the iDevice while maintaining the HOME and POWER button pressed during 8 seconds, then release the POWER button only while maintaining the HOME button still pressed. After some seconds, the iDevice should be in DFU mode. This mode is visually indistinguishable, only the host device knows if the connected iDevice is in DFU mode as it receives a DFU notification.

In 2012, George Hotz publish his limera1n exploit which allows the use of unsigned boot elements on vulnerable iDevices. This vulnerability is a memory overflow in the bootrom. With such an exploit, jailbreakers are able to modify the iOS ramdisk used in DFU mode, for example by editing the /sbin/launchd binary which is used to launch other binaries and scripts at boot, such as mounting partitions in read and write mode. This launchd binary will be used for example to execute sshd on our ramdisk.

Tumbling down the rabbit hole

 This part is dedicated to the development and creation of the ironha1l and DFOwn tools. Those tools were created to inject and execute a custom ramdisk containing a SSH server on a targeted iDevice using an Android device.

USB reverse

As previously described, what is interesting for us is to exploit the bootrom vulnerability with limera1n in order to inject a custom boot chain on the targeted iDevice. Actually, jailbreak software such as Redsn0w can do that, but our aim here is quite different as we intend to do it with an Android phone, and there are no such existing tools for this operating system.

We have two choices. The first one is to modify existing and open source jailbreak tools and port them for Android platform. The second choice is to create a totally new tool optimized for Android. Given the aim to have a mastered full tool suite, and because I had time to learn and I love challenges, I decided to give a try to the second alternative. Consequently, USB reverse engineering in DFU mode was required to establish how data is sent to the iDevice and what are the USB transfer modes, headers and commands used for all the steps of the boot chain.

It is first necessary to create an USB debug environment or as I like to call it, a Man In The Middle USB. There are several ways to do this, either you can directly reverse each element of the boot chain to understand how the following elements must be injected, or you can modify the Mac OS or Windows USB driver to activate the USB debug mode, you can also use a sniffer device between attached to your USB cable, or you can even directly use a Windows Virtual Machine on your Linux system. In this last case the use of Wireshark running on Linux will do the trick, as it can sniff USB communications, especially in our case the USB communications between iTunes running in the Windows VM with our attached USB iDevice. This last method is quite buggy, but allows us to see the USB communication protocol quite easily.

The full description of the DFU mode is in the meantime available in the Universal Serial Bus Device Class Specification for Device Firmware Upgrade publication. With the help of this documentation and various USB headers and requests sniffed with Wireshark, the exact iTunes behavior for data transfer in DFU mode has been established. It is important to note that all communications are in clear text, same apply for commands sent to the iDevice which are associated to each part of the boot process. Another observation, is that header values are specific to Apple and not documented.

Development of libironha1l and ironha1l

The biggest step in this project was to create the ironha1l tool and its library libironha1l. This library provides functions to inject data to the iDevice in DFU mode and is strictly based on libusb. The principal advantage of this last point is the portability of libusb, and its compatibility with Android. ironha1l is the application that coordinates all the various injections of our custom boot chain, based on the DFU protocol reverse established previously. Meaning the injection of iBSS, iBEC, DeviceTree, KernelCache and Ramdisk modified files. These custom files can be extracted and automatically created using the iPhone-dataprotection tool suite of Sogeti.

The development of ironha1l and libironha1l lasted 3 months and contains more than 1000 lines of code. ironha1l and libironha1l are written in C. The ironha1l tool also comes with the limera1n exploit and payload (sources available on the Jailbreak community Wiki).

During the development, a number of difficulties came to light. The first one and the most difficult was the ramdisk size. During the first attempts to inject a custom ramdisk it has been established that a ramdisk size higher than ~10 MB could not be executed on the iDevice, unfortunately a ramdisk containing a SSH server cannot handle such a limited size. The solution was in fact, to alter a bit in the control transfer header specific to the ramdisk. This solution was established after many days by testing ramdom and various header values. Unfortunately it is still unknown why does this bit value bypass the size limitation.

Two more issues, this time related to limera1n, came to light during the libironha1l development. The first one is that limera1n consists of two elements, the source code and the payload. The limera1n payload is unfortunately not documented and is not open source, but it is easily extractable from Jailbreak tools such as RedSn0w. To extract this payload you need to apply the same reverse process as describer in the USB reverse part of this article. Meaning using Redsn0w in a Windows Virtual Machine on your Linux platform and dump all USB transmissions with Wireshark in Man In The Middle. Once the payload dumped, it has been tested and once again came another problem.

The limera1n exploit is based on the principal buffer overflow vulnerability of the bootrom, but unfortunately a USB control command must be sent to the iDevice during the injection process of the payload, so that the payload can be executed. If the control command reaches the iDevice too late, the payload is not executed. Le biggest problem is that generally the USB commands cannot overlap with one another with libusb, and this it is not possible to send the specific USB control command without interrupting the previous injection. The trick and the solution is to play with reception timeouts (acknowledgment replies), the payload is sent to the iDevice with a big timeout and due to its big size the iDevice will take a certain amount of time to deal with it. During this short amount of time (1 to 10 milliseconds), the control command that executes the payload must be sent, this time with a timeout lower than 10 milliseconds to match the iDevice process timing (ideally 1 millisecond).

Here is the prototype of ironha1l:

usage: ./ironha1l -h (help)
	[-v verbose_level{0,1,2,3}] [-d libusb_debug_level{0,1,2,3}]
	[-l limera1n_file] [-i iBSS_file] [-b iBEC_file]
	[-t DeviceTree_file] [-r Ramdisk_file] [-k KernelCache_file]
	[-c iBSS_command]
	[-z idBus]

Once our tool working and injecting correctly all elements of our customized boot chain, the iDevice boots on our ramdisk containing a SSH server. Meanwhile, on the client side we need to find a way to connect to this SSH server via USB. Fortunately this task is not a real big deal. The MobileDevice framework of Apple (included in iTunes for Windows) contains a daemon called usbmuxd. This daemon is typically what we need as it creates a TCP tunnel over USB to communicate with the iDevice services (in our case the ssh server). Of course, the usbmuxd used by Apple is not open source, but a bunch of great developers have created a usbmuxd version open source that comes with iproxy which is used for port forwarding. So combining usbmuxd with iproxy creates a local port that communicate through USB directly with the SSH socket in listening mode on the iDevice. It was not a big deal to port usbmuxd and iproxy for Android, as these tools are working under Linux. It should also be noted that this open source project is not maintained by Apple, thus each time a new device comes out usbmuxd must be updated by developers and apparently this is not an easy task. In our case our targeted iDevices are all working and supported by the latest version of usbmuxd.

The application portability is a very important aspect, it has been decided to directly integrate libusb and usbmuxd in ironha1l. Before compiling, a script downloads, patches and configures the latest libusb and usbmuxd version. The ironha1l tool suite is compatible with Linux, UNIX, BSD, Mac OS and Android.

Android port and GUI application DFOwn

Since the ICS version, Android supports USB host, which allows to connect to the USB port a USB device such as USB storage, mouse, etc. using a micro USB to USB host adaptor.

The first thing to do with Android was to root the OS, which is the easiest hacking task ever. The second step was to make sure DFU mode is well detected by Android. For this task either we can use lsusb ported on Android using Android SDK, or we can also use the devices tool contained in the ironha1l tool suite. The USB enumeration has been made on two devices, a SAMSUNG Galaxy SII and a SAMSUNG Galaxy Nexus, both under Android 4.0.3. It appeared that the Galaxy SII could not detect any iDevice in DFU mode (other modes were successfully detected). Even after multiple testings using different USB devices, even with a self-powered USB HUB the problem was still there and was not identified. Fortunately the Galaxy Nexus was working perfectly well under Android 4.0.3. Thus for the next part of the development this smartphone was used.

Android is a Linux based operating system, the compilation of ironha1l tool suite with Android SDK was almost instantaneous. There was only some very basic problems such as the creation of specific Makefiles for Android. The ironha1l binaries were thus sent to the Galaxy Nexus device to be used later with the JAVA GUI application DFOwn. The tools ironha1l, usbmuxd and iproxy have been manually tested and were working perfectly well. The custom boot chain was injected and the Android device can communicate with the SSH server of the Android loaded ramdisk. The iDevice partitions were accessible after mounting in read and/or write, it is thus possible to alter or download files from them directly from our Android smartphone. As described previously, some files such as email database are encrypted and cannot be decrypted without knowing the iDevice passcode, which is not the case for pictures and movies for example, or text message database and contact database.

The DFOwn JAVA application was created to provide a easy and fast way to use ironha1l and pwn (understand limera1n exploit + custom boot chain injection) the attached iDevice in DFU mode. DFOwn does not currently integrate a SFTP client which thus require the user to use its own SFTP client such as AndFTP to access the iDevice data.

Conclusion

DFOwn and ironha1l are Proof of Concept applications, their goal is to prove an attacker can gain access to your iDevice smartphone files easily with minimal hardware such as an Android smartphone. DFOwn takes about 1 minute to complete the ironha1l boot process on an iDevice. The application is fast, quiet and easy to use. Transfers can go up to 1.5 Mo/s depending of the iDevice and Android device used, which allows the attacker to get a large amount of files very quickly.

Sources Available HERE!

References

Incoming search terms:

• usbmuxd windows (18)
• openiBoot (15)
• android libusb (14)
• ironha1l (10)
• libusb android (6)
• limera1n verbose boot (4)
• ios usbmuxd tutorial (4)
• openiboot for samsung galaxy (4)
• limera1n explits verbose mode (3)
• iphone 4 gsm dfu usb drivers portable (3)

How to build a HackinTosh with Mountain Lion (10.8), the latest version of MacOS X.

During this very hot summer (about 37°C outside), I spent about 20 hours in an entire weekend to install MacOS 10.8 Mountain Lion on my Asus Sabertooth P67. Really, there’s no best time for that… And because I love you my readers, I wrote this little GUIDE in the hope you’ll find useful information in it.

This article will be updated continuously. So come back here time to time or follow me on twitter!

What’s not working:

• Nothing

Updates: (subscribe to my twitter to get notified)

• 08/20/2012 – ExtraThi updated to v1.1! (ExtraThi v1.0 was broken)
• 08/20/2012 – Added USB 3.0 support explanations in STEP #3.
• 08/23/2012 – Updated information relative to Extensions.mkext creation.
• 08/23/2012 – Original ExtraThi_v1.1 renamed to ExtraThi_v1.1_10.8.
• 08/23/2012 – 10.8.1 update procedure with ExtraThi_v1.1_10.8.1.
• 08/23/2012 – Chameleon 2.1 r2048 replaced by r2050.
• 08/24/2012 - 10.8.1 update procedure [ TESTING... ] -> [ GOOD ]
• 09/22/2012 – Fixed a mistake in AppleGraphicsPowerManagement.kext plist modification (IOCFUnserialize: syntax error near line 2995). Please download the new kext or apply the new modifications!
• 09/22/2012 – Chameleon 2.1 r2050 replaced by r2060.
• 09/22/2012 - 10.8.2 update procedure [ GOOD ]
• 01/11/2013 – Minor changes.
• 01/11/2013 – USB 3.0 working, added a note about it for SaberTooth P67 users.
• 03/18/2013 – Chameleon 2.1 r2060 replaced by Chameleon 2.2 r2187.
• 03/18/2013 – iMessage fix with FileNVRAM from xZeneu LLC.
• 03/18/2013 – New version of AGPM.kext for MacOS X 10.8.3.
• 03/18/2013 - 10.8.3 update procedure [ TESTING... ] -> [ GOOD ]
• 03/18/2013 – Minor changes.
• 03/29/2013 - Fixed a mistake in AppleGraphicsPowerManagement.kext plist modification for 10.8.3. Please download the new kext!
• 05/04/2013 – New Audio kext instructions, which fix “With DSDT” Audio kext issues under 10.8.3. (MultiBeast has been updated with new audio kexts: Updated toleda’s patched AppleHDAs to the 10.8.3 versions)
• 05/04/2013 – USB 3.0 support is now UNIVERSAL! New USB 3.0 Instructions. (Make sure to delete any CalDigit*.kext and PXHCD.kext drivers from your /System/Library/Extensions folder). Fix USB 3.0 not properly working under 10.8.3. You should now use RehabMan’s branch of Zenith432′s GenericUSBXHCI.kext to enable USB 3.0.
• 05/04/2013 - ExtraThi updated to v1.2! (New Preboot image with new additional and updated kexts. Thanks to Artistus!)

TODO:

• Better AGPM.kext for NVIDIA GTX 480 to avoid lags of 1st speedstep layer. (in fact the plist modification was broken due to syntax error… so the kext was not loaded! It is now fixed!)
• Extra checks regarding STEP #3 additional kexts.
• Better patch for AppleIntelCPUPowerManagement (boot kext mode) so it can be added to Extensions.mkext and will not require to be removed from /S/L/E.
• Test betstu settings for AGPM.kext GTX480 iMac12,2 10.8

Before we start…

This is not an universal/generic GUIDE. All tips, files and patches provided in this article are designed to work for my own computer specs. In the meantime, I think people with a similar configuration will find this guide interesting and useful to achieve their installation of MacOS X Mountain Lion.

This guide was not made for beginners, also if you have any questions, I recommend you to ask on various HackinTosh forum communities before, such as tonymacx86 or InsanelyMac.

About my specs

Let’s see what we have here…

• CPU: Intel – Processeur – Intel Core i7 2600K / 3,4 GHz – LGA1155 Socket – L3 8 Mo
• RAM: G.Skill Kit Extreme3 4 x 4 Go PC15000 Sniper CAS 9
• MotherBoard: ASUS SABERTOOTH P67 (rev. B3) – Socket 1155 – Chipset P67 – ATX - BIOS VERSION 2302 official*
• GPU: SAPPHIRE ATI Radeon HD6870 Toxic | 1024 Mo DDR5 – PCI Express – DUAL DVI / HDMI / mini DP
• GPU: ASUS ENGTX480/2DI/1536MD5 GeForce GTX 480 (Fermi) 1536MB 384-bit GDDR5 PCI Express 2.0 x16 HDCP Ready SLI Support Video Card
• Power Supply: OCZ Z Series Gold OCZZ1000M 1000W
• CPU Cooler: COOLER MASTER HYPER 212 PLUS
• Case: Lian Li PC-K63

* Some people reported issues with SATA controller for the latest 3302 version (link). Do not upgrade your BIOS unless you know what you’re doing. By the way, it is possible to patch your BIOS to avoid some issues with MacOS, such as AppleIntelCPUPowerManagement problems related to Intel SpeedStep. 

 What do you need

Basically it is better to already have a working version of MacOS installed on your HackinTosh. It is always possible to achieve all steps of this GUIDE with an external MacOS system, but it will be more difficult. Also, I recommend you to have the following stuffs:

• 1 x USB/SD card of 8GB minimum.
• 1 x Original Mountain Lion Install DVD (InstallESD.dmg, md5 checksum = 8b4869920cd740414fe6b7e3f0b1be3e).
• 8GB of available space minimum to install Mountain Lion.
• 1 x Human Brain.
• 30 minutes up to 3 hours spare time.

 HackinTosh common issues… Warning!

In case some of you might think dealing with a HackinTosh is quite easy, here is a quick list of common issues you can face while attempting to build your HackinTosh. These issues CAN ALSO be faced after every OS X update!

• Speedstep not working, which causes Kernel Panic at startup (related to AppleIntelCPUPowerManagement.kext).
• SATA controller not working properly.
• Some ACPI tables not recognized (in this case you have to deal with DSDT or/and SSDT).
• Graphics cards not natively supported can lead to Kernel Panics, bad power management (altered performances), black/blank screens, freezes, video output not recognized (DVI/HMDI/VGA), etc.
• USB not recognized, including both USB 2.0 and 3.0.
• Network cards not working or stuck at a certain speed.
• Audio output/input not working.
• Sleep/Wake/Reboot not working.

Most of these issues can be solved by patching Apple drivers, or installing custom drivers. Some of them, such as DSDT and SSDT tables require advanced knowledge and hacks.

STEP 1 – Creating USB/SD Mountain Lion Installation Drive

For this part, you need to force Finder to show all hidden files (link).

1. Right Click “Install OS X Mountain Lion” -> Show Package Contents.
2. Contents -> Shared Support -> InstallESD.dmg.
3. Open InstallESD.dmg (this will popup the “Mac OS X Install ESD” volume).
4. In ”Mac OS X Install ESD” volume open BaseSystem.dmg (this will popup the “Mac OS X Base System” volume).
5. Open the Disk Utility application.

Now we will create our USB/SD Mountain Lion installation DVD volume.

1. Partition your USB/SD device to match two partition, GUID Partition Scheme, both must be Mac OS Extended (Journaled).
2. The first partition must be around 500MB, and the second one the remaining free space.
3. Call the first partition CHAMELEON (500MB), and the second one INSTALLDVD (more than 6GB).
4. Restore “Mac OS X Base System” volume (source) to INSTALLDVD (desination).
5. Once done, your INSTALLDVD partition should now popup with the name Mac OS X Base System.
6. Replace “Mac OS X Base System“/System/Installation/Packages (must be removed) by ”Mac OS X Install ESD”/Packages (copy/paste)*
7. “Mac OS X Base System” is now your installation DVD volume.

* A more detailed and illustrated guide about this process can be found on this link.

At the end, this is how your USB/SD drive should look like:

Now we must create the bootloader.

1. Download Chameleon 2.2 r2187 or newer version (from source or package).
2. Install Chameleon on your CHAMELEON volume (default install, no extra options checked).
3. Open CHAMELEON, unzip and copy the following Extra folder into it:

ExtraThi_v1.1_10.8.zip
ExtraThi_v1.1_10.8.zip
Version: 1.1_10.8

Chameleon 2.1 Extra folder created by Thireus.
Works only MacOS X Mountain Lion 10.8 and ASUS Sabertooth P67 + Intel Core i7-2600k.

Author:	Thireus
Date:	August 19, 2012

54.9 MB
2576 Downloads
Details...

In this Extra folder you will find:

• DSDT.aml/dsl files are specific to ASUS Sabertooth P67 AND Intel Core i7-2600k! If you have a different configuration you can create and patch your own DSDT, or you can find pre-patched DSDT on this database.
• SSDT patches for CPU Speedstep have been directly integrated to DSDT (ASUS motherboards does not deal with SSDT for that). If you have a different configuration other than ASUS Sabertooth P67 AND Intel Core i7-2600k, YOU MUST follow these instructions to create your own SSDT or find some help in this forum. If you do not create any SSDT file or patch your DSDT file (for your custom configuration) you will be stuck at some CPU speed (16x for example).
• Preboot.dmg contains all generic kexts you need to boot, including patched AppleIntelCPUPowerManagement.kext. It also contains the Darwin kernel (12.0.0) for MacOS X 10.8. This Preboot.dmg image should be generic but is dependent of the OS X version.
• Other files are generic and related to Chameleon configuration.

Once done, eject your drive and boot your computer with it. Chameleon should display a list of bootable drives, you must select “Mac OS X Base System“.

STEP 2 – Install MacOS X Mountain Lion 10.8

Boot your ”Mac OS X Base System” drive (which is Mountain Lion Installation DVD) in verbose mode (-v).

Now comes the hard part . If you are lucky enough and if you use the same configuration as me, Mountain Lion Installation DVD will load without any issues. If not, issues can be related to the ones listed in the HackinTosh common issues… Warning! section of this GUIDE. Most issues can be related to your Graphic Card and can be solved with some tricks like GraphicsEnabler=Yes/No. For this reason, I will not list here all issues and solutions, it really depends of your Graphic Card model. By the way, if you plan to buy a new Graphic Card, I recommend you to have a look at this list and buy a “Working Out Of the Box” Graphic Card.

Some people are facing an issue with ATI/AMD Graphics Cards, when the Installation DVD is loaded they see a blank screen and their mouse but nothing else. To fix this issue you have two solutions.

1. You can press the power button to make your computer sleep, and then press the power button again to wake it. Once awoken you should see the normal Installation screen and no more blank screen. This works only if you have sleep/wake working. It was working for me with my ATI Radeon HD6870 Toxic.
2. According to this topic, you can delete/backup ATI6000controller.kext which is located in your “Mac OS X Base System“/System/Library/Extensions folder. This step is only for the installation process. Once on Mountain Lion you must put this file back in your /System/Library/Extensions folder.

In case everything works well, you must be able to install Mountain Lion.

RAID0 (optional part)

Those who don’t want to use RAID0 might find this tip useful too, because this tip provide an easy way to backup the Extensions.mkext file to prevent any stuck OS. For example, if you install a bad kext in your /System/Library/Extensions folder that crashes your OS on the next boot, you can easily rollback to one of your previous Extensions.mkext files which does not contain this bad kext

If you want to install Mountain Lion on a RAID0 software partition you’ll also be interested to read my old post regarding RAID 0 Apple Software + x86_64 kernel + GUID + Dual Boot Seven. Note that if you are planing to install your OS on a RAID0 partition it is way better to have an external chameleon bootloader (located on another drive), because you will face a big issue regarding kexts. Chameleon will not be able to access your RAID0 drive to load Extensions.mkext nor extensions located in the /System/Library/Extensions folder (in case you try to boot without cache -f). For this reason, you need to create the Extensions.mkext cache file in your Chameleon Extra folder BEFORE you try to boot Mountain Lion and AFTER any changes in your /System/Library/Extensions folder. YOU SHOULD FIRST DELETE AppleIntelCPUPowerManagement.kext from your /System/Library/Extensions folder!

Use the following commands everytime you update your OS or update your Extensions folder:

mv /Volumes/CHAMELEON/Extra/Extensions.mkext /Volumes/CHAMELEON/Extra/Extensions.mkext.bak
cd /Volumes/CHAMELEON/Extra/
sudo kextcache -v -l -m Extensions.mkext /System/Library/Extensions

If you have multiple Extensions folders:

mv /Volumes/CHAMELEON/Extra/Extensions.mkext /Volumes/CHAMELEON/Extra/Extensions.mkext.bak
cd /Volumes/CHAMELEON/Extra/
sudo kextcache -v -l -m Extensions.mkext /Extra/Extensions ... /System/Library/Extensions ... /AndAnyOtherFolderContainingkexts

STEP 3 – Boot Mountain Lion 10.8 and install additional kexts

Use your Chameleon USB/SD drive to boot Mountain Lion. When the list of bootable OS popup you just have to choose the name of the OS X partition where you have installed Mountain Lion. Once done… Welcome in Mountain Lion

YOU SHOULD FIRST DELETE AppleIntelCPUPowerManagement.kext from your /System/Library/Extensions folder!
DELETE THIS KEXT AFTER ANY UPDATE OF MOUNTAIN LION, BEFORE REBOOT!

You might want to do is install Chameleon Bootloader to get rid of your USB/SD bootable device. Follow once again the steps to install Chameleon with Extra folder, but this time either select your Mountain Lion partition or another bootable device (if you have installed OSX on a Raid0 partition I recommend you the second option). Then in your BIOS, change settings to boot on the drive where you have installed Chameleon!

About additional kexts…

Audio, USB 3.0 and Ethernet drivers can be found in MultiBeast – Mountain Lion. The reason why I prefer not to use such tools for a fresh install is because most of the time we don’t know what exactly these applications install. So I prefer creating my own bootloader with my own kexts, which is better in case you need to debug your bootloader.

• Audio* - If you use my DSDT you must select ALC892 from the “Drivers & Bootloaders -> Drivers -> Audio -> Realtek ALC8xx -> With/Without DSDT” section (use ‘Without DSDT’ if you have not patched your DSDT). Otherwise, you must select the audio driver for your own configuration in case Audio does not work out of the box.
• USB 3.0 - Install USB 3.0 – Universal from the ”Drivers & Bootloaders -> Drivers -> Miscellaneous” section. Make sure you do not have any CalDigit*.kext and PXHCD.kext drivers from your /System/Library/Extensions folder, otherwise you must delete them (and rebuild your cache).
• Ethernet* – Install hnak’s AppleIntelE1000e Ethernet (from MultiBeast – Mountain Lion) or AppleIntelE1000e.kext (I prefer this method).

* Note that these drivers depend of your motherboard!

Before each reboot make sure to Repair Permissions with Disk Utility.

Hopefully my NVIDIA GTX 480 and AMD HD6870 Graphics Cards were working out of the box on Mountain Lion. OpenCL, OpenGL and Quartz Extreme are working without any patch . In case you need to patch OpenCL you’ll find more information on this topic. The only issue I faced on Mountain Lion was bad GPU power management of my NVIDIA GTX 480. To fix this issue you need to patch the Infos.plist file contained in the AppleGraphicsPowerManagement.kext folder.

Here are the lines you need to add, right after <key>iMac12,2</key> <dict>. This patch only works for iMac12,2 model and NVIDIA GTX 480!

<key>Vendor10deDevice06c0</key>
<dict>
   <key>BoostPState</key>
   <array>
      <integer>0</integer>
      <integer>1</integer>
      <integer>2</integer>
      <integer>3</integer>
   </array>
   <key>BoostTime</key>
   <array>
      <integer>3</integer>
      <integer>3</integer>
      <integer>3</integer>
      <integer>3</integer>
   </array>
   <key>Heuristic</key>
   <dict>
      <key>ID</key>
      <integer>0</integer>
      <key>IdleInterval</key>
      <integer>250</integer>
      <key>SensorOption</key>
      <integer>1</integer>
      <key>SensorSampleRate</key>
      <integer>4</integer>
      <key>TargetCount</key>
      <integer>5</integer>
      <key>Threshold_High</key>
      <array>
         <integer>47</integer>
         <integer>75</integer>
         <integer>93</integer>
         <integer>100</integer>
      </array>
      <key>Threshold_Low</key>
      <array>
         <integer>0</integer>
         <integer>72</integer>
         <integer>90</integer>
         <integer>99</integer>
      </array>
   </dict>
   <key>control-id</key>
   <integer>17</integer>
   <key>LogControl</key>
   <integer>0</integer>
</dict>

If you still need the full kext, here it is:

AGPM.kext GTX480 iMac12,2 10.8 [FIXED!]
AppleGraphicsPowerManagement.kext(2).zip
Version: 1.1

NEW FIXED version! There was an error in the previous version preventing the kext to load! This new version is fixed!

AppleGraphicsPowerManagement.kext patched by Thireus for enabling controlled and soft throttle for GTX480. This modified version makes your GTX480 throttle with no freeze, no lags, no KP. This modified version only works if you have iMac12,2 model set for your HackinTosh. Throttle settings have been set after research and GPU analysis. These are my own settings, do not blame me if this modified version do not work for you (but you can thank me if it works ^^).
Confirmed working under MacOS 10.8 with NVIDIA ENGTX480.

Author:	Thireus
Date:	September 22, 2012

44.4 KB
637 Downloads
Details...

IF YOU ARE UNDER 10.8.3 YOU NEED THIS VERSION OF THE KEXT (you can still patch the original kext manually):

AGPM.kext GTX480 iMac12,2 10.8.3 ONLY [v1.2]
AppleGraphicsPowerManagement.kext.10.8.3ONLY_FIXED.zip
Version: 1.2

ONLY FOR MAC OS X 10.8.3!!!
AppleGraphicsPowerManagement.kext patched by Thireus for enabling controlled and soft throttle for GTX480. This modified version makes your GTX480 throttle with no freeze, no lags, no KP. This modified version only works if you have iMac12,2 model set for your HackinTosh. Throttle settings have been set after research and GPU analysis. These are my own settings, do not blame me if this modified version do not work for you (but you can thank me if it works ^^).
Confirmed working under MacOS 10.8.3 with NVIDIA ENGTX480.

Author:	Thireus
Date:	March 29, 2013

46.3 KB
175 Downloads
Details...

About iMessage…

HackinTosh computers may have this bad behavior with iMessage, that when you try to sign in to iMessage it fails with an error displaying “Could not sign in to iMessage.“. Fortunately ‘xZeneu LLC‘ released a module for Chameleon r2181 or newer named FileNVRAM.dylib that fixes this issue (download the 1.1.3 version or newer). Make sure that you have the latest version of Chameleon and put the FileNVRAM.dylib module to your /Extra/modules/ folder. Reboot and enjoy iMessage.

Final thoughts…

I’m writing these last lines from my new Mountain Lion OS . I hope you enjoyed this tutorial. Feel free to thank anyone who helped you in this painful task.
Never forget that this hard work was made during spare time and if you need help you’d better ask on hackintosh forums, such as tonymacx86 or InsanelyMac.

And as always, feel free to share the knowledge my friends!

OSX Updates:

10.8.1 UPDATE PROCEDURE [ GOOD ] - Update, reboot, enjoy!

1. Eitheir update from App Store or direct link.
2. Use the following updated ExtraThi_v1.1 to boot Mountain Lion, it contains the new OS X Darwin kernel (12.1.0 for MacOS 10.8.1) included in Preboot.dmg.
3. (Optional) Users who have installed Chameleon 2.1 r2048 (previous version of this GUIDE) can upgrade their CHAMELEON bootloader with Chameleon 2.1 r2050 (from source or package).

ExtraThi_v1.1_10.8.1.zip
ExtraThi_v1.1_10.8.1.zip
Version: 1.1_10.8.1

ONLY FOR 10.8.1 USERS!
Chameleon 2.1 Extra folder created by Thireus.
Works only MacOS X Mountain Lion 10.8 and ASUS Sabertooth P67 + Intel Core i7-2600k.

Author:	Thireus
Date:	August 23, 2012

50.1 MB
530 Downloads
Details...

10.8.2 UPDATE PROCEDURE [ GOOD ] - Update, reboot, enjoy!

1. Eitheir update from App Store or direct link.
2. Use the following updated ExtraThi_v1.1 to boot Mountain Lion, it contains the new OS X Darwin kernel (12.2.0 for MacOS 10.8.2) included in Preboot.dmg.
3. (Optional) Users who have installed Chameleon 2.1 r2050 (previous version of this GUIDE) can upgrade their CHAMELEON bootloader with Chameleon 2.1 r2060 (from source or package).

ExtraThi_v1.1_10.8.2.zip
ExtraThi_v1.1_10.8.2.zip
Version: 1.1_10.8.2

ONLY FOR 10.8.2 USERS!
Chameleon 2.1 Extra folder created by Thireus.
Works only MacOS X Mountain Lion 10.8 and ASUS Sabertooth P67 + Intel Core i7-2600k.

Author:	Thireus
Date:	September 22, 2012

50.1 MB
1377 Downloads
Details...

10.8.3 UPDATE PROCEDURE [ GOOD ] - Update, patch, reboot, enjoy!

1. Update using the OS X Mountain Lion Update v10.8.3 (Combo) from direct link.
2. Patch your AppleGraphicsPowerManagement.kext if needed (Apple updated this kext in this 10.8.3 version, so you need to patch it again).
3. Use the following updated ExtraThi_v1.1 to boot Mountain Lion, it contains the new OS X Darwin kernel (12.3.0 for MacOS 10.8.3) included in Preboot.dmg.
4. Users who have installed Chameleon 2.1 r2060 (previous version of this GUIDE) must upgrade their CHAMELEON bootloader with Chameleon 2.2 r2187 or newer version (from source or package).
5. Apply fixes for Audio/USB3.0/Ethernet/iMessage/etc.

ExtraThi_v1.2_10.8.3.zip
ExtraThi_v1.1_10.8.3.zip
Version: 1.2_10.8.3

ONLY FOR 10.8.3 USERS!
Chameleon 2.2 Extra folder created by Thireus.
Works only MacOS X Mountain Lion 10.8 and ASUS Sabertooth P67 + Intel Core i7-2600k.

Author:	Thireus
Date:	May 4, 2013

38.7 MB
543 Downloads
Details...

Please note that after each update Audio/USB3.0/Ethernet/etc. might be broken. Make sure to fix them right after the update.

RAID0 users: After each update do not forget to rebuild your Extensions.mkext!

Incoming search terms:

• chameleon hackintosh (202)
• hackintosh chameleon (87)
• hackintosh 10 8 2 (85)
• chameleon mountain lion (79)
• hackintosh mountain lion 10 8 2 (77)
• mountain lion 10 8 2 hackintosh (73)
• hackintosh 10 8 download (70)
• 10 8 usb boot chameleon (63)
• chameleon bootloader mountain lion (48)
• chameleon 10 8 2 (46)

The famous Linux-based penetration testing arsenal can run in VirtualBox. In the meanwhile, some tricks are needed to have the latest version fully functional with VirtualBox.

For the ST’HACK Ethical Hacking Contest tonight in Bordeaux (France), everything must be ready for the battle. MacBooks are armed, scripts are ready to be launched and beers are waiting in the fridge. During the preparation, BackTrack 5 R2 was installed on every teammate computers.

VirtualBox is of course the most suitable virtualization solution to run BackTrack. Unfortunately, with this latest version of BackTrack, the VirtualBox Guest Additions cannot be installed on a fresh new install. Fortunately after some modifications, everything can be fixed to compile these additions for the 3.2.6 Linux Kernel of BackTrack 5 R2.

Edit: VirtualBox Guest Additions solution updated with new fixes.

Download and Install

• BackTrack: http://www.backtrack-linux.org/downloads/
• VirtualBox + Oracle VM Extension Pack: https://www.virtualbox.org/wiki/Downloads

If you want support for USB 2.0 devices you must download and install Oracle VM Extension Pack for VirtualBox!

I will not describe the steps to install BackTrack on VirtualBox. A lot of tutorials can be found on the Internet to upgrade to BackTrack 5 R2 or to make a fresh install. But here are some screenshots about the VirtualBox configuration for my MacBook Air i7 1.8Ghz.

Issue #1 (solved): USB device descriptor error

usb 1-1: Device descriptor read/8, error -110
usb 1-1: Device descriptor read/64, error -110

Solution

Number of Processor for the Guest OS must be set to 1 or eventually 2…
For example, my MacBook Air has a Core i7 inside, multithreading displays 4 virtual cores. So I have to set a maximum of 2 cores to BackTrack VM Guest to fix this issue. (Even if the recommended number of cores VirtualBox displays is 4).

Issue #2 (solved): VirtualBox Guest Additions

After a fresh new install of BackTrack 5 R2, you should have no issues installing VirtualBox Guest Additions… So, before applying these patches, make sure the installation of VirtualBox Guest Additions fails.

After upgraded from an old version of BackTrack to BackTrack 5 R2, you can face issues installing VirtualBox Guest Additions. These two kinds of errors can occur and lead to a vboxguest kernel extension impossible to load.

The headers for the current running kernel were not found. If the following
module compilation fails then this could be the reason.

and

Building the main Guest Additions module ...fail!
(Look at /var/log/vboxadd-install.log to find out what went wrong)

Both issues result to:

Starting the VirtualBox Guest Additions ...fail!
(modprobe vboxguest failed)

Solution

apt-get install linux-headers-$(uname -r) linux-headers xserver-xorg xserver-xorg-core file-roller # file-roller not needed
cd /usr/src/
tar jxf /usr/src/linux-source-3.2.6.tar.bz2
rm /usr/src/linux
ln -s /usr/src/linux-source-3.2.6 /usr/src/linux
rm /usr/src/linux-headers-3.2.6/include/asm
ln -s /usr/src/linux-source-3.2.6/arch/x86/include/asm /usr/src/linux-headers-3.2.6/include/asm
ln -s /usr/src/linux-headers-3.2.6 /lib/modules/3.2.6/build
ln -s /usr/src/linux-source-3.2.6/arch/x86/Makefile_32.cpu /usr/src/linux-headers-3.2.6/arch/x86/Makefile_32.cpu # Solution required for BackTrack x86 version by SphaZ

Please make sure you have linux-source-3.2.6.tar.bz2 into your /usr/src/ directory… Just in case you need it:

linux-source-3.2.6.tar.bz2
linux-source-3.2.6.tar.bz2

BackTrack 5 R2 linux-source-3.2.6.tar.bz2

Platforms:	Linux
Date:	March 27, 2012

79.9 MB
971 Downloads
Details...

Ready to install VBOXADDITIONS

Verifying archive integrity... All good.
Uncompressing VirtualBox 4.1.10 Guest Additions for Linux..........
VirtualBox Guest Additions installer
Removing installed version 4.1.10 of VirtualBox Guest Additions...
tar: Record size = 8 blocks
Removing existing VirtualBox DKMS kernel modules ...done.
Removing existing VirtualBox non-DKMS kernel modules ...done.
Building the VirtualBox Guest Additions kernel modules
Building the main Guest Additions module ...done.
Building the shared folder support module ...done.
Building the OpenGL support module ...done.
Doing non-kernel setup of the Guest Additions ...done.
You should restart your guest to make sure the new modules are actually used
Installing the Window System drivers
Installing X.Org Server 1.7 modules ...done.
Setting up the Window System to use the Guest Additions ...done.
You may need to restart the hal service and the Window System (or just restart
the guest system) to enable the Guest Additions.
Installing graphics libraries and desktop services components ...done.
Press Return to close this window...

Incoming search terms:

• backtrack virtualbox (102)
• Error! Bad return status for module build on kernel: 3 2 6 (i686) (89)
• /var/log/vboxadd-install log (61)
• backtrack 5 virtualbox (58)
• backtrack macbook air (58)
• backtrack 5 r2 virtualbox guest additions (48)
• error! bad return status for module build on kernel: 3 2 6 (x86_64) (43)
• backtrack virtualbox guest additions (37)
• backtrack 5 virtualbox guest additions (35)
• backtrack on macbook air (33)