Posted on

Hackintoshing a Toshiba Satellite Pro L850-1UJ

While I am a technical person, the Hackintosh community is scores ahead of what I know. The work put in by the awesome community supporting the  movement for macOS/OS X on other machines is incredible. I’ve watched the progress since I was 11, but never branched into it. Recently, it all changed.

macOS High Sierra about screenshot, showing the version details
My Toshiba pretending to be a MacBook Pro

I write this now on a Hackintosh laptop. This isn’t any old laptop however… This is a laptop that is not technically supported. I googled for hours to see the achievements of other Satellite owners and found nothing. However, with trial and error (and years of configuring crap experience), I was graced with the Apple logo appearing on my non-Apple laptop.

Laptop Specification (PDF)

Back Story

I recently traded my trusty MacBook White mid-2010 for my girlfriend’s university laptop Toshiba Satellite Pro L850. Since leaving uni she no longer needed a laptop in general, and was happy to take a lower-spec Apple machine to compliment her iPhone. Receiving a much higher spec machine in return, we swapped. I immediately (no joke – first two hours of receiving it) turned it into a Linux machine, using Ubuntu and later, elementaryOS.

I then wished to contribute to a Windows extension development, in which I needed Windows again for. eyeing up the old trusty Mac again, I realised I was in the best position to Hackintosh – pre-existing Mac and a machine that can be clean-wiped. And so it began.

How?

I would like to take this moment to say this would not be possible without the amazing community work that goes into it. I simply configured this laptop to use Hackintosh, the real developers and hard-workers can all be found at the TonyMac86 community. If you’re impressed by this, or tried it yourself, please direct all the praise to those amazing people.

What Does & Doesn’t Work

Take this with a pinch of salt, as Apple never intended for you to install this. Whatever does work is an absolute miracle, and often smaller problems can be overcome with additional hardware.

Initial issues with graphics

Does Work

  • Main Display Graphics (Intel HD 4000) with Clover config.
  • Keyboard (set to ISO, keys don’t match up 100%) and trackpad.
  • Wireless Internet.
  • Battery status.
  • USB ports (you wouldn’t believe how problematic that can be).
  • CD/DVD drive.
  • Webcam.

Doesn’t Work

  • Laptop Detection, for power management (In Progress).
  • Brightness Controls (In Progress).
  • Standby (Kernel Panic).
  • Brightness controls (Lucky for me, seemingly defaults to mid brightness).
  • Sound (Untested, does seem to be fixable).

For most of the non-working elements, any USB peripherals claiming to be Mac-compliant should work in their place. Your experience may differ.

Quick Steps

  • Enabled UEFI, but disabled secure boot in BIOS.
  • Download the macOS High Sierra installer from the App Store, on the existing Mac.
  • Download and run Unibeast (set for UEFI).
    • Also copy Multibeast onto USB.
    • While EFI is apparently mounted, I copied over the neccessary kexts and this configuration file into the CLOVER directory (don’t replace the existing config.plist).
  • Make a cup of tea.
  • Drink said tea.
  • Plug USB Stick in Toshiba, repeatedly tap F12 on boot, and boot via USB.
  • In Clover, go to options, config, and select the configuration you copied earlier (most likely, the currently deselected one).
  • Select ‘Boot from Install macOS High Sierra’.
  • Wait (another tea moment) for macOS to start.
  • Open Disk Utility (click View > Show All Devices at the top).
  • Select TOSHIBA and click erase.
    • I erased the entire hard drive. If you wish to keep stuff or dual boot, please see a guide for dual booting as this will erase everything.
  • I chose single HFS+ partition (I named it the classic Macintosh HD), with a GUID partition map.
  • Once complete, run the installer.
  • Once finished, boot via USB stick again.
  • Same again with Clover, this time select ‘Boot from <partition name>’.
  • Congratulations – You’re running macOS!
    • You will be reliant on the USB key to boot. Check out Remove USB Reliance to stop doing this.
  • (Optional) Setup Windows dual boot.

Many, many, many steps to go through, but so long as everything is done correctly, this should be a completely rewarding experience afterwards.

Required Kexts

Kexts are basically driver packages used by macOS to understand what your various input devices are telling it. Without usable kexts, if macOS doesn’t know what a device does it will simply ignore it. There’s no Windows Update to grab them for you.

Clover and Unibeast does a Hell of a job packaging all the essentials in to your USB key, but especially for this laptop there are some missing essentials. Most notably, the keyboard and trackpad won’t work, which can make things slightly problematic.

The following are the kexts I have successfully added and used with my installation:

Instead of installing them on the system, I opted (and is not recommended) to install them into Clover. Clover will inject these on boot, so you never need to install them in Mac and risk update breakage. The big downside however is that you risk breaking the boot process, which can make things tricky to resolve. My personal approach is to try riskier kexts on the USB Clover first, and if successful I then copy them to the HD Clover. You can also tell Clover to boot without these kexts, but this may leave FakeSMC behind and refuse to boot.

If you wish to install kexts to Clover, then grab this utility to mount your EFI partition. Then you can whack your additional kext files into CLOVER > kexts > Other. Clover will then inject these into the boot process.

My Macintosh HD EFI layout

Boot via Hard Drive

If you haven’t already got frustrated about needing to boot via USB, then your patience knows no bounds. However, you can set up Clover to reside on your main hard drive EFI partition rather than just the USB drive.

Personally, if you can do so I would recommend either leaving the USB drive as it is or taking an image backup after successfully being able to boot via Hard Drive. The reason being is that you can use this memory stick as a rescue device, and boot your laptop again in case a faulty configuration or a software update kills the boot process. 

In the quick steps you would have a copy of Multibeast if followed to the letter. You can use this to modify your Hackintosh configuration, and one of the major features is the ability to install Clover on the working drive.

In Multibeast, click on Bootloader, and then Clover UEFI (Legacy if you did not enable UEFI). Then click build. Once finished, your EFI partition on your main disk will have its own bootable Clover. Don’t stop just yet though.

Plug in your bootable USB Installer drive and use the EFI Mounter utility to mount the EFI partition on your USB drive. Grab both the config.plist you select on boot and all the kexts from ‘Other’. Now eject the USB Drive, and run the utility again to mount the EFI partition of your hard drive. Simply copy these files to the same places they were at on your USB drive.

So far, on each boot up I currently go into Config and change the config selection. There are ways to modify the main config to boot straight into macOS, however all my config file modifications ended in disaster, so I’ve kept it operating this way.

Personal Verdict

Hackintosh deserves a new name. While originally it was a small list of supported machines, today the amount of eligible machines is insane. As long as the system remains stable to use, then I would absolutely continue to use macOS as my primary. 

If you have a spare laptop and technical expertise, I would totally recommend trying it out. The experience is rewarding, and slightly baffling at the same time. Nothing is weirder than seeing the macOS login appear without the use of virtualization technology.

Last Changed: 20th August 2018, 5:00pm (WiFi works, and Dual Boot).

Posted on

Chromeboard, an Experiment Killed by Security

Chomeboard git log showing three commits, with the focus being the last major commit being Mar 5, 2017.

You wouldn’t be wrong if you’ve come to the assumption that I’ve stopped supporting Chromeboard. You can see from the commit log that I haven’t made a significant change since March of last year. This was largely unintentional, but there was a main reason as to why I chose to unofficially abandon the extension – I call it ‘Issue 9 of Death‘.

This is the reason why a rough 5% of the internet websites actually work with this extension. I’ve stopped working on the plugin because simply, in the current approach it will soon become completely unsustainable.

In this general interest post, I’ll explain what SAMEORIGIN is, how it relates to browser security, why it killed my plugin and what the future for Chromeboard is.

What is SAMEORIGIN?

Let’s quickly cast back to the internet 1995-2005. Put your mental image of a phone away, because WAP was a horrific mess that nobody used. I particularly remember around ’02-04 being a hot spot for friends and family being frequently affected by online scams and such. Back then though, we weren’t aware of these as much as we are now.

A popular attack at the time was the ol’ classic, ‘YOU’VE WON A PRIZE!’ hoax. You’ve clicked it, realised it’s a hoax and left. However, the browser has used this to make a request to your banks’ website that you have an authentication cookie for, and make a payment. As far as your banks’ website cares, you made that request. This is just one example of many Cross-Site Scripting (XSS) attacks.

One approach is this SAMEORIGIN header. This lets the source server (the website you visited) specify how the content it provides is controlled. If the policy is specified to the current website, it means that attacker sites cannot use an IFrame to attack unsuspecting customers.

And that last sentence is the exact reason why the Chrome extension does not work on a majority of websites.

You’re Harvesting Our Data?!

Not at all. In fact, Chromeboard doesn’t really care what you’ve specified. However, in order to be able to switch tabs without taking full control of the web browser, it loads up all your specified cyclical tabs into one page. And the only way this can be feasibly achieved is through the use of IFrames.

If a website has a defined SAMEORIGIN policy, it will disallow Chromeboard to render it. The most common reason will be because the IFrame location is not the same URL as where the page is coming from. Ergo, the website deems the extension is trying to spoof attack you and thus blocks it.

So Chromeboard is effectively made redundant, but for a completely legitimate reason.

Chromeboard Future

For now I can confirm that the Chromeboard extension is abandoned, but the project is still ongoing. The progress has disappeared because an API is being developed to manage the websites.

My plans for Chromeboard going forward are:

  1. Chromeboard settings are definable via a stateless REST API.
  2. Chromeboard primarily becomes an Electron app (ARM focus).
  3. Chromeboard browser plugin pivots the approach.
  4. ???
  5. (Not-for) profit!

Electron being a full application instead of being just a browser allows me some flexibility in approach. I can keep the app as a Kiosk terminal, however it is able to run web instances which allows Chromeboard to be seen as a web browser instead of a spoofing client. Since wallboards mostly reside on the IoT, I will be ensuring that this works on the Raspberry Pi.

I will keep posted as things develop, but hopefully this will clear up as to why progress for the Chromeboard plugin has completely stopped.

Nutab? Oh my, that’s a completely different story.

Note: Since this article was published, Chromeboard was issued a takedown due to copyright infringement (Chrome in the name, and in the logo). It has since been rebranded as Wallboard Lite.

Posted on

Using PHP 7 on Ubuntu 14.04 with Codeanywhere

I am a big fan of online IDEs. For me this enables me to do web development pretty much anywhere, on any device. My particular favourites are Codeanywhere and Codenvy. While both have their pros and cons, I pretty much use Codeanywhere free for my day-to-day development. It gives you a temporary VPS for your code, easily accessible, great no-nonsense IDE and easy to use SSH access. Perfect, I simply fire up the container and get to work.

I do have a problem with it however, and it isn’t something you can fault them for – Ubuntu 14.04. I love every release of Ubuntu, but nobody should be running PHP 5.4, which has been EOL for a long while now. PHP has made some massive strides since then with PHP 7, with 7.2 being the currently latest iteration. So the first thing I do is get the container as up to date as I possibly can get it.

They do have a PHP 7 container available if you go down the CentOS route, but I personally encountered dependency issues running their version. However your milage may vary, so if you are a fan of CentOS, you don’t need to continue.

Container Creation and Update

Once you’ve logged in to Codeanywhere, it will ask you what container you want to setup (otherwise, File > New Connection > Container).  In this instance, we will select the Ubuntu 14.04 version of the PHP containers.

Screenshot of Codeanywhere container screen showing PHP options

Once finished, you’ll have your own personal VPS for your project(s). Before we do anything, we need to make sure your Ubuntu box is up-to-date. For this we need to run the commands that every Ubuntu sysadmin is familiar with:

sudo apt update && sudo apt upgrade -y

‘update’ will tell your VPS what new updates are available, and upgrade will upgrade said packages (-y stops it asking if you want to proceed, if you do want to check it before installation then remove this).

In my scenario, it asks if you want to replace some pre-existing system configuration files. You can simply press Enter and skip through these.

Once finished, you’ll have an up-to-date container. We can now move up to PHP 7.

Updating PHP 5.4 to PHP 7

The current repositories for 14.04 do not use PHP 7, supporting 5.4 as the maximum. So we need to add a new repository to do this. Now, for some reason certain system functionality from base Linux have been removed, so we need to re-add these features. Use the following command:

sudo apt install -y software-properties-common

We now need to add a repository that supports PHP 7 in 14.04. In comes Ondrej, a PPA repository that does just that!

sudo apt install -y language-pack-en-base
sudo LC_ALL=en_US.UTF-8 add-apt-repository ppa:ondrej/php
sudo apt update
sudo apt upgrade -y

Normally the LC_ALL line is not needed. However, in this repository some characters are used in the description which breaks with non-UTF8 languages. The extra command parts will make sure it uses UTF8 to process it, and go through fine.

Once all commands are run, your system will be running the latest available PHP version. However, Apache will still be using PHP 5.4. Command line PHP works great for tools such as Composer and PHPUnit, but our application will not use it until Apache knows it exists.

We need to install some additional PHP modules for Apache to recognise it, which can be done by this command:

sudo apt install php7.2 php7.2-mbstring

Add php7.2-mysql if you use MySQL, or add others for the extensions you need. Use sudo apt search php7.2 to find out what’s available)

Now we need to command Apache to ditch PHP 5 and use PHP 7.2, so run the following commands.

sudo a2dismod php5 && sudo a2enmod php7.2

Now restart Apache to make sure the changes are fully committed.

sudo service apache2 restart

Now you should be ready to develop using the latest version of PHP. With this repository, you should also receive the latest updates to PHP whenever you run the update command, so you should be good going forward!

Checking PHP Version

If you want to check which version of PHP you’re running, then you need to do it twice. PHP can often be used in command line as well as on a back-end server techonology like Apache or NGINX. It is possible for your Linux installation to use one version of PHP, and your web server application to use another.

To check your command line PHP version, simply run the following command:

php -v

To check the Apache version of PHP, create a new PHP file in the root of your workspace (say, info.php). Paste the following into the file.

<?php phpinfo();

Now browse to it in your browser (right click the container, and click run. Then, add /info.php at the end of the URL). It should give you a full dump of the server technology, with the version right at the top.

Bonus – Quick WordPress Installation

This will install WordPress to /wordpress directory of your cabox. Run this command first which will set up the brilliant WP-CLI on your container.

sudo wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar -O /usr/local/bin/wp && sudo chmod +x /usr/local/bin/wp

And this can be used to create our WordPress installation. Run in the workspace folder (Run cd ~/workspace if you’re unsure). Change theurlhere.com to the domain of your container, plus the /wordpress.

mysql -u root -e "CREATE DATABASE wordpress01;" && mkdir wordpress && cd wordpress && wp core download && wp config create --dbname=wordpress01 --dbuser=root && wp core install --url=theurlhere.com/wordpress --title="WordPress Development" --admin_user=admin --admin_password=password --admin_email=admin@example.com && sudo chown www-data:www-data *

This cuts down the famous 5 minute installation to about 15 seconds. Since this is development, I’ve kept things basic with the admin password simply being password.

Posted on

Smarting up my Car with a Raspberry Pi, Crankshaft & OpenAuto

I drive a 2014 Kia Rio. I have no legitimate complaints about it, as it works brilliantly as a daily driver. Sure, I would love an MX5 mk1 (Miata NA) but at my age (23) it serves a purpose of getting me around with no issue. However, it does come with a rather boring radio setup.

Kia did do an upgrade run to their 2014 and newer cars, however I wasn’t eligable as the run was for US cars only. I could get an aftermarket radio, but I currently don’t own the car, as it’s leased. I don’t feel like upsetting the existing working aesthetic.

In comes my Raspberry Pi 3. After a quick half-minded Google, I discovered that a fantastic team of developers had got Android Auto on the Raspberry Pi. OpenAuto runs an emulated version of Android Auto and is targeted for Raspberry Pi.

Now this is well and great, but ideally I don’t want to boot up Raspian every time my car ignition turns on – in comes Crankshaft. Crankshaft is pre-configured to run the Pi as a dedicated headunit system. This neatly combines OpenAuto and Raspbian into a nice, plug-and-play system.

The developer behind Crankshaft – Huan Truong – is especially involved in his project. He provides a fantastic, community-driven wiki on GitHub for newcomers and tinkers to the project. There is also a dedicated Subreddit For a rather niche market, it’s refreshing to see someone so heavily involved in a project concept rather than just the initial build and maintenance.

Author’s note – The project has since been moved into an organisation and has multiple developers now. See their GitHub.

The Equipment

For what sounds like a rather large uptake, the resources needed for the project are small. Especially in my case, I am not intending to hook the system up to the CAMBUS, or splice any of the current electrical wiring for power. Luckily, the Kia Rio I own comes with two 12V ports in the front.

  • Raspberry Pi 3.
  • MicroSD (64GB… All I had spare!).
  • Official 7″ Touch screen.
  • SmartPi enclosure.

Setting up the software was an absolute doddle. Simply grab the IMG file from the Crankshaft website, and install it to your Raspberry Pi’s MicroSD card (I recommend using Etcher). Configuration files are kept in the FAT partition, so if you need to change settings you can do so easily.

Once I had set the software up and put together the screen and Pi in a case, it was time to whack it in the car!

The Car

Placed the unit on the dashboard, hooked up a Micro USB cable to the power from a 12V USB adapter, connect up my phone and job done – working Android Auto, basically.

I can best describe this as basically operating as a dumb dual screen. My phone remains connected to the stereo, so my steering wheel controls work the same way they did before. The USB connection streams over visuals to the Raspberry Pi, which then displays the Android Auto interface.

Next Steps

While the whole system works pretty well as it does now, it does come with some bugs to fix. There are some things I would like to change as part of the ongoing project. These include:

  • Dedicated mic for OK Google.
  • Charge phone as well as connect to Raspberry Pi.

Both of the above need a way of providing power via USB, as the Raspberry Pi is not capable of doing so. I’m considering processes such as running a powered USB hub to power the Raspberry Pi, the Screen, the microphone setup and charging the phone all at once.

An idea to go forward with is in regards to the UK law. Here you can get a 6 point fine for distracted driving, mostly with regards to mobile phone use. This already borders on the law by how much it blocks the view (I fold this right down once I’m finished setting up, not got a Police confirmation on this), and I don’t feel like rustling an Officer’s jimmies by fiddling around with it while driving. So I would like to:

  • Consider a more efficient screen solution.
    • Mounting the screen below the dashboard (tricky without modifications).
    • Using a smaller, more satnav-sized screen.
    • Lay it flat and go off window reflections (screen is reversible via software).
  • Use a control form without screen interaction.

The latter got me considering a custom Arduino-based solution to making a rotary controller-based system to control the Pi without needing to physically touch the screen.

So this project is far from over in the current state. I’ll keep this blog updated on the progress of this in-car entertainment system, and how it fares.