Tag Archives: AsereBln

[MacOS] Chameleon On USB: Mounting USB Stick Correctly

Leave a reply

Inserting USB sticks to your Mac OS X based system makes Mac OS X mount the stick without assigning certain permissions like owners, or groups.

I. How things get mounted on Mac OS

The mount command on the terminal returns most likely some lines, like that:

  • testuser$ mount
  • /dev/disk0s2 on / (hfs, local, journaled)
    devfs on /dev (devfs, local, nobrowse)
    map -hosts on /net (autofs, nosuid, automounted, nobrowse)
    map auto_home on /home (autofs, automounted, nobrowse)
    /dev/disk3s1 on /Volumes/CHAMBOOT (hfs, local, nodev, nosuid, journaled, noowners)
    /dev/disk1s4 on /Volumes/Mac OS X Install DVD (hfs, local, nodev, nosuid, noowners)

You can see quite a lot of slices (i.e. ~partitions) are mounted to that system I am running here. For instance disk1s4 is the forth slice of disk1 and it countains an image of a Mac OS X Install DVD. And you can see a CHAMBOOT named drive mounted with several options.

II. Mount Options/Permissions

Our beloved USB stick named CHAMBOOT (contains Chameleon and) is disk3s1 and is mounted to /Volumes/CHAMBOOT. Mac OS handles USB mounting for most of our every day life operations fairly reliable. But this comes at a cost, as this simplicity is achieved here by applying options like nosuid and noowners during the mount process.

For people willing to run Chameleon from a USB stick permissions are inevitable, as for instance an Extensions.mkext kextcache can only be generated with proper file permissions being set.

II. Mounting USB with permissions

This just requires some simple mount operations being performed manually on the terminal. Do the following:

  • testuser$ sudo -s
    Become ultimate root now.
  • testuser$ cd
    Get back to the home folder whereever you’ve been before.
  • testuser$ sync
    Force completion of pending disk writes.
  • testuser$ umount -f /Volumes/CHAMBOOT
    This unmounts the USB stick called CHAMBOOT
  • testuser$ mkdir chamboottemp
    Create a temporary folder for our mounting session
  • testuser$ mount_hfs /dev/disk3s1 chamboottemp/
    Mount the USB stick to the temporary folder
  • testuser$ mount
    See how the drives are mounted now
  • /dev/disk0s2 on / (hfs, local, journaled)
    devfs on /dev (devfs, local, nobrowse)
    map -hosts on /net (autofs, nosuid, automounted, nobrowse)
    map auto_home on /home (autofs, automounted, nobrowse)
    /dev/disk3s1 on /Users/admin/chamboottemp (hfs, local, journaled)
    /dev/disk1s4 on /Volumes/Mac OS X Install DVD (hfs, local, nodev, nosuid, noowners)    You can see the USB stick is now mounted without “extra” options.

Now you can apply changes to the USB stick’s files in the proper manner (like copying files, repairing permissions and creating a kextcache). After having performed all the changes, you can correctly unmount. Read here:

III. Manually Unmounting

  • testuser$ cd
    Get back to the home folder whereever you’ve been before.
  • testuser$ umount -f chamboottemp
    Force to unmount the device mounted to the chamboottemp folder now.
  • testuser$ rmdir chamboottemp
    It is safe to delete the chamboottemp folder now.

IV. Links

» Mac OS X Reference Library: Man Page for “sync”…
» Mac OS X Reference Library: Man Page for “mount”…
» AsereBln.BlogSpot.com: Some terminal work…

[MacOS] Is EFI-X illegally using 3rd Party Program Code?

Leave a reply

About a year ago a company called ASEM released a device called EFI-X. This device has been claimed to be capable of booting several Microsoft Windows versions and Mac OS X Leopard.

Legal concerns

From the beginning there were question regarding the legal status of the device. But ASEM claimed the device is legal, although it circumvents Apple’s binary protection using Apple’s copyrighted secret operating system keys (OSK1 and OSK2).

Technical issues

Anyway EFI-X devices had some issues. Many forums reported about problems with Bonjour and sharing in general. In the meantime articles from the official EFI-X support forums have been suddenly disappeared. Customers reporting issues or solutions and workaround to severe bugs have been banned from EFI-X support forums – our own help article to recover almost lost data was removed aswell and one of our members has been officially banned from their forums (the reason was this article in october 2008).

Examining EFI-X in deep

Now some frustrated customers who are on the other hand technologically very familiar have examined the EFI-X device in deep. One of the main points AsereBln found: in contrast to what EFI-X is stating: “Our approach is entirely different, (..) all our code and development is our own only” – they seem to be using program code that has been developed by the OSX86 community though. They seem to be using “Disabler.kext“. Moreover another user (RezRov) found out the EFI-X Windows update software seems to be violating the LGPL as it incorporates a modified USB device library (libusb-win32).

Use of possibly unlicensed 3rd party program code, possibly illegal use of Apple security keys, and customer support below grade for a 170€ (250US$) commercial product that seems to be the summary about a year after product launch.

Lessons learnt

We suppose end users should be aware of this possible hassle. Only an original Apple Mac is really hassle free and 100% compatible to a Mac. But if you are technologically interested and have the time and motivation search the OSX86 communities for setups. The OSX86 forums are full of knowledge and willing to help. But remember a PC won’t ever be 100% compatible to a real Mac.