New style of AppleHDA.kext patching for Yosemite

In Januari I blogged about a New style of AppleHDA.kext patching (take III) for Mavericks, and today I changed AppleHDA8Series.sh for Yosemite – tested with 14A261i.

Download

AppleHDA8Series.sh v2.8 is now available for download and here is a one liner how-to:

curl -o AppleHDA8Series.sh https://raw.githubusercontent.com/Piker-Alpha/AppleHDA8Series.sh/master/AppleHDA8Series.sh

Bugs

Please report bugs here: https://github.com/Piker-Alpha/AppleHDA8Series.sh/issues
Not here. Thank you!

Edit

HDMI audio is not yet functional, but I am working on a new update that should, hopefully, eliminate manual patching altogether. At least for people who use my AppleHDA8Series.sh script. And you know what. It may even be better than what Clover offers today, because with Clover you still need to know the exact data pattern that you want to alter. Not something you should have to deal with, with every OS update, and that is why I like to introduce something new. Something so simple that it makes me wonder why nobody, including me, ever thought about it.

Advertisements

iMac14,4 Geekbench result / SMBIOS data

Here is the Geekbench score of the brand new entry-level iMac with the Intel Core i5-4260U processor running @ 1.40 GHz.

Geekbench_iMac144

New model identifier

The new iMac has a new Mac model identifier (iMac14,4) so now we have these four:

iMac14,1
iMac14,2
iMac14,3 (Build-to-order)
iMac14,4

New board-id

The new iMac also uses one of the previously discovered board-id’s and thus now we have these:

Mac-031B6874CF7F642A (iMac14,1)
Mac-27ADBB7B4CEE8E61 (iMac14,2)
Mac-77EB7D7DAF985301 (Build-to-order iMac14,3)
Mac-81E3E92DD6088272 (iMac14,4)

RevoBoot SMBIOS data

Here is the new SMBIOS data for RevoBoot, but you can easily adapt it to Chameleon, Chimera or Clover.

#define SMB_BIOS_VERSION	"IM144.88Z.0179.B03.1405241029"
#define SMB_PRODUCT_NAME	"iMac14,4"
#define SMB_BOARD_PRODUCT	"Mac-81E3E92DD6088272"
#define EFI_MODEL_NAME		{ 'i', 'M', 'a', 'c', '1', '4', ',', '4' }

Serial numbers

And to make the data complete… here are some serial numbers for you 😉

G56K – iMac (21.5-inch, Mid 2014)
G56J – iMac (21.5-inch, Mid 2014)

The page is not there right now, but should soon be made (Edit: Done. Available right now).

OS X v10.10 Yosemite Update 1 (Build 14A261i)

Update 1 of the OS X Yosemite Beta was released to developers earlier today. The first update using the new name. This to me is only a logical move, to stop confusion among future OS X Beta Seed Program members – interested end-users without a (paid) Mac developer membership.

CatalogURL

You may have used this command

defaults read /Library/Preferences/com.apple.SoftwareUpdate CatalogURL

From a previous blog article about the CatalogURL, but this one errors out on Yosemite with:

The domain/default pair of (/Library/Preferences/com.apple.SoftwareUpdate, CatalogURL) does not exist.

Luckily we have this file: /private/var/db/SUPrefOverrides.plist

And that leads to the following URL:

https://swscan.apple.com/content/catalogs/others/index-10.10seed-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz

Add this in front of the URL and you are ready to receive Yosemite updates. Even without SUPrefOverrides.plist

sudo /usr/sbin/softwareupdate --set-catalog

Yosemite DP1 Includes new EFI images/sound files

Sam’s efires-xtract (Perl script) was already a handy tool, but it needed a few tweaks here and there. For example. Version 0.5 adds support for Yosemite. In fact. It should support all future version of OS X, this because it no longer use hard-coded filenames. Nope. Now it reads: /use/standalone/i386/EfiLoginUI/ and get the target file names automatically. No more tweaking. Ok. Let’s run ./efires-xtract and see what we get:

1) appleLogo.efires (4 images) NEW
– appleLogo_apple.png (84 x 103 pixels)
– appleLogo_apple@2x.png (168 x 206 pixels)
– appleLogo_apple_gray.png (90 x 95 pixels)
– appleLogo_apple_gray@2x.png (160 x 190 pixels)

2) battery.efires (430 images)

3) disk_passwordUI.efires (20 images)

4) flag_picker.efires (698 images)

5) guest_userUI.efires (20 images)

6) loginui.efires (116 images)

7) Lucida13.efires (892 images)

8) recovery_user.efires (2 images)

9) recoveryUI.efires (10 images)

10) sound.efires (6 images) NEW

– sound_SCREFIAudio.Beep
– sound_SCREFIAudio.Password
– sound_SCREFIAudio.Username
– sound_SCREFIAudio.UsernameOrPasswordIncorrect
– sound_SCREFIAudio.VoiceOverOff
– sound_SCREFIAudio.VoiceOverOn

11) unknown_userUI.efires (22 images)

Ok. So the Yosemite Developer Preview 1 includes two new files called: appleLogo.efires and sound.efires Wait what. Sound?

Let’s have a look at the header data. For this we use: xxd -l 144 sound_SCREFIAudio.caf

0000000: 6361 6666 0001 0000 6465 7363 0000 0000 caff....desc....
0000010: 0000 0020 40e5 8880 0000 0000 696d 6134 ... @.......ima4
0000020: 0000 0000 0000 0022 0000 0040 0000 0001 ......."...@....
0000030: 0000 0000 696e 666f 0000 0000 0000 003f ....info.......?
0000040: 0000 0002 6170 7072 6f78 696d 6174 6520 ....approximate
0000050: 6475 7261 7469 6f6e 2069 6e20 7365 636f duration in seco
0000060: 6e64 7300 302e 3034 3600 736f 7572 6365 nds.0.046.source
0000070: 2062 6974 2064 6570 7468 0049 3136 0070 bit depth.I16.p
0000080: 616b 7400 0000 0000 0000 1800 0000 0000 akt.............

Cool. So this is actually a file in Apple Core Audio Format. And adding a .caf file extension should change the icon and then we should be able to play it with the QuickTime Player. Yup. That worked. Perfect.

Note: run sudo chmod +x efires-xtract before running it.

Expect an update after my coffee break!

Edit

Crap. I used an old HDD for my Yosemite installation and it started to make funny noises. Like tick tick tick. Won’t boot up anymore. Had to re-install Yosemite and get stuff going again, which was why my coffee break went on forever.

I now also added the PNG image sizes, and here is a cool new find. Add “meter=0” under ‘Kernel Flags’ in /Library/Preferences/SystemConfiguration/com.Apple.Boot.plist and the good old throbber is back. This setting also removes IODeviceTree:/chosen/IOProgressColorTheme (Number) 01.

I also changed RevoBoot, in my local repository, and now it loads: /usr/standalone/appleLogo.efires to get the Apple logos – gray or white, and scaling (1x or 2x) also works. Just like Boot.efi does.

For your info. The new BlackMode loads the white Apple logo, instead of the gray Apple logo, on a black background.

Update

Here is a proof of concept, showing you how to load and show the new Apple logo images in Yosemite.

//==============================================================================

typedef struct
{
	uint16_t	revision;
	uint16_t	imageCount;
} __attribute__((packed)) EFIRES_HEADER;

typedef struct
{
	char		filename[64];
	uint32_t	offset;
	uint32_t	imageSize;
} __attribute__((packed)) EFIRES_IMAGE_HEADER;

//==============================================================================

void showBootLogo()
{
	setVideoMode(GRAPHICS_MODE);

	long backGroundColor = 0xbfbfbf;

	char targetLogoName[30] = "appleLogo_apple";

	// bootArgs->flags |= kBootArgsFlagBlack is set by boot.efi (EFI var 'BlackMode')
	if (bootArgs->flags & kBootArgsFlagBlack)
	{
		backGroundColor = 0x030000;
	}
	else
	{
		sprintf(targetLogoName, "%s%s", targetLogoName, "_gray");
	}

	// bootArgs->flags |= kBootArgsFlagHiDPI is set by boot.efi (EFI var 'UIScale')
	sprintf(targetLogoName, "%s%s.png", targetLogoName, (bootArgs->flags & kBootArgsFlagHiDPI) ? "@2x" : "");

	setBackgroundColor(backGroundColor);
	
	void *imageLoadBuffer = (void *)kLoadAddr;

	int EFIResourceFile = open("/usr/standalone/i386/EfiLoginUI/appleLogo.efires", 0);
	
	if (EFIResourceFile >= 0)
	{
		int filesize = file_size(EFIResourceFile);
		
		if (read(EFIResourceFile, (char *) kLoadAddr, filesize) == filesize)
		{
			EFIRES_HEADER * header = (EFIRES_HEADER *) imageLoadBuffer;
#if DEBUG
			printf("\nheader->revision..: %d\n", header->revision);
			printf("header->imageCount: %d\n", header->imageCount);
#endif
			int pos = sizeof(header);

			for (int index = 0; index < header->imageCount; index++)
			{
				EFIRES_IMAGE_HEADER * imageHeader = (EFIRES_IMAGE_HEADER *) (imageLoadBuffer + pos);
#if DEBUG
				printf("imageHeader->filename.: %s\n", imageHeader->filename);
				printf("imageHeader->offset...: %d\n", imageHeader->offset);
				printf("imageHeader->imageSize: %d\n", imageHeader->imageSize);
#endif
				if (strncmp((char *)imageHeader->filename, targetLogoName, strlen(targetLogoName)) == 0)
				{
					PNG_info_t *info = PNG_decode((imageLoadBuffer + imageHeader->offset), imageHeader->imageSize);
#if DEBUG
					printf("Apple logo image found!\n");
					printf("Image width...........: %d\n", info->width);
					printf("Image height..........: %d\n", info->height);
					sleep(3);
#endif
					uint8_t *bootImage = malloc((info->width * 4) * info->height);
					memcpy(bootImage, info->image->data, ((info->width * 4) * info->height));
	
					uint16_t x = (VIDEO(width) - MIN(info->width, VIDEO(width)) ) / 2;
					uint16_t y = (VIDEO(height) - MIN(info->height, VIDEO(height)) ) / 2;
	
					blendImage(x, y, info->width, info->height, bootImage);
					png_alloc_free_all();
					free(bootImage);
					close(EFIResourceFile);
					return;
				}
				else
				{
					pos += sizeof(EFIRES_IMAGE_HEADER);
				}
			}
		}

		close(EFIResourceFile);
	}
	else
	{
		setVideoMode(FB_TEXT_MODE);
		error("showBootLogo(Error)");
	}
}

It should be fairly easy to port the code to Chameleon/Chimera.

Edit Typo fixed in logo scaling (@2X -> @2x).

Edit 2 The same (efires) image files can be found on the Recovery HD partition in the directory: com.apple.boot.P/usr/standalone/i386/EfiLoginUI/

OS X Mavericks 10.9.4 (Build 13E16) Seeded

Apple seeded Build 13E16 of OS X 10.9.4 to developers. Made available through their Software Update mechanism in the Mac App Store, as well as through the Mac Dev Center. An almost forgotten update due to our focus on the first developer preview of OS X 10.10 (Yosemite). Sorry about that.

Anyway. I blogged about newly discovered power management resource files in the first developer preview of 10.9.4 like two weeks ago but things have changed a little since then.

Changes

Apple removed these two files:

Mac-42FD25EABCABB274.plist / iMac15,n (IGPU/GFX0/Apple display with id 0xAE03)
Mac-FA842E06C61E91C5.plist / iMac15,n (IGPU/GFX0/Apple Retina display with id 0xAE03)

But this one is still there.

Mac-81E3E92DD6088272.plist / iMac14,4 (IGPU only)

We’ve learned that the latest MacBook Air is using the same board-id as the previous model, it was after all only a minor spec-bumb, so guess what. The new iMacs may also be using the same board-id, because only a minor spec-bumb is to be expected. That is if the rumours are true. Which unfortunately also means that the new Retina iMac won’t make it before Q4. Sounds plausible to me.

The IGPU only power management resource file could either be used for a new iMac, or for a new Mac mini. Whatever happens, happens, but my guess is that Apple will drop the price for non-retina iMacs and add a new Retina iMac for few hundred dollar more. Add a new Mac mini and a lot of people will be happy. Very happy indeed.

Changes

Config2 with the EDID data has also been removed from:
AppleGraphicsControl.kext/C*/P*/AppleGraphicsDevicePolicy.kext/C*/

New

/usr/libexec/gkbisd
/System/Library/LaunchDaemons/com.apple.gkbisd.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>com.apple.gkbisd</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/libexec/gkbisd</string>
	</array>
	<key>Umask</key>
	<integer>54</integer>
	<key>ProcessType</key>
	<string>Background</string>
	<key>LowPriorityIO</key>
	<true/>
	<key>MachServices</key>
	<dict>
		<key>com.apple.gkbisd</key>
		<true/>
	</dict>
	<key>LaunchEvents</key>
	<dict>
		<key>com.apple.xpc.activity</key>
		<dict>
			<key>com.apple.gkbisd.worker</key>
			<dict>
				<key>Delay</key>
				<integer>86400</integer>
				<key>GracePeriod</key>
				<integer>3600</integer>
				<key>Priority</key>
				<string>Maintenance</string>
				<key>Repeating</key>
				<true/>
			</dict>
		</dict>
	</dict>
</dict>
</plist>

Ok. These are the SQlite3 statements I found in this daemon:

BEGIN EXCLUSIVE
SELECT id, path FROM object WHERE collected = 0 ORDER BY id ASC LIMIT 1
DELETE FROM object WHERE id = ?
COMMIT
ROLLBACK
SELECT 1 FROM object WHERE path = ? AND collected = 0
SELECT 1 FROM object WHERE current_cdhash = ?
INSERT INTO object (path, collected, identifier, signature_version, current_cdhash, opaque_cdhash) VALUES (?, ?, ?, ?, ?, ?)
CREATE TABLE IF NOT EXISTS object (id INTEGER PRIMARY KEY AUTOINCREMENT, path TEXT NOT NULL, collected INTEGER, identifier TEXT, signature_version INTEGER, current_cdhash TEXT UNIQUE ON CONFLICT REPLACE, opaque_cdhash TEXT)

Data stored in: /private/var/db/gkbis.db

Yosemite DP1 Removes SystemStarter

This was to be expected, but Yosemite DP1 no longer includes:

/System/Library/LaunchDaemons/com.apple.SystemStarter.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>KeepAlive</key>
	<dict>
		<key>PathState</key>
		<dict>
			<key>/etc/rc.local</key>
			<true/>
			<key>/etc/rc.shutdown.local</key>
			<true/>
		</dict>
	</dict>
	<key>Label</key>
	<string>com.apple.SystemStarter</string>
	<key>Program</key>
	<string>/sbin/SystemStarter</string>
	<key>QueueDirectories</key>
	<array>
		<string>/Library/StartupItems</string>
		<string>/System/Library/StartupItems</string>
	</array>
</dict>
</plist>

The executable /sbin/SystemStarter is also removed, of course, and thus now you have to write LaunchAgents (per-user session) or LaunchDaemons (system-wide) scripts/applications because /etc/rc.local and /etc/rc.shutdown.local are no longer executed. I like this cleanup. Fully in line with Apple’s plan to depreciate StartupItems:

Deprecation Note: Startup items are a deprecated technology. Launching of daemons through this process may be removed or eliminated in a future release of OS X.

Maybe this is just a start and can we expect more cleanups, but for now… let’s just wait and see what the next developer preview brings. At least now you know why your rc.local and/or rc.shutdown.local scripts aren’t working anymore. Time to write that plist.

Tip
See man launchd and man launchctl for tips like where to put your plist.

~/Library/LaunchAgents Per-user agents provided by the user.
/Library/LaunchAgents Per-user agents provided by the administrator.
/Library/LaunchDaemons System wide daemons provided by the administrator.
/System/Library/LaunchAgents Mac OS X Per-user agents.
/System/Library/LaunchDaemons Mac OS X System wide daemons.

Yosemite DP1 adds AppleMobileFileIntegrity.kext to OS X

Crap. This might be bad news. AppleMobileFileIntegrity.kext aka AMFI a sworn enemy of Jailbreakers on this planet… is now also part of OS X 10.10 Yosemite. I have no idea what Apple is up to, but it might mean trouble is ahead of us. More trouble that is.

Edit: I also found /System/Library/LaunchDaemons/com.apple.MobileFileIntegrity.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Label</key>
        <string>com.apple.MobileFileIntegrity</string>
        <key>MachServices</key>
        <dict>
                <key>com.apple.MobileFileIntegrity</key>
                <dict>
                    <key>HostSpecialPort</key>
                    <integer>18</integer>
                </dict>
        </dict>
        <key>ProgramArguments</key>
        <array>
                <string>/usr/libexec/amfid</string>
        </array>
        <key>POSIXSpawnType</key>
        <string>Interactive</string>
</dict>
</plist>

The daemon is there already: /usr/libexec/amfid but it may require some sort of argument, which may be added in a future developer preview/release.

Update

I checked: /var/log/system.log in Yosemite Update 1 and found an interesting piece of text:

calling mpo_policy_init for AMFI
Security policy loaded: Apple Mobile File Integrity (AMFI)

Seems like the new security scrutiny went life in DP2. Time to debug this…

Ok. Code signing debug data can be enabled by setting a boot argument called cs_debug=[value] where value can be 0x1 up to 0xb.

With 0x1 I got two lines. One for each instance (file/process):

AMFI: <key><com.apple.security.get-task-allow> not found
AMFI: <key><com.apple.rootless.installer> not found

With 0xb you get a lot more data. Here are a few examples:

AMFI: in mmap but not enforcing library validation
[deny-mmap] mapped file has no team identifier and is not a platform binary
[deny-mmap] mapped process has no team identifier and is not a platform binary
AMFI: failed to get file path
[deny-mmap] mapped process is a platform binary, but mapped file is not
[deny-mmap] mapped file does not have a matching team identifier
[deny-mmap] mapped process has team identifier %s
[deny-mmap] mapped file has team identifier %s

Another interesting boot argument is amfi=[value] where value can be used to disable certain parts, like 0x2, 0x4 and 0x80 – or a combination of the values.

kern_return_t _initializeAppleMobileFileIntegrity(): signature enforcement disabled by boot-arg
kern_return_t _initializeAppleMobileFileIntegrity(): signature enforcement disabled by boot-arg
kern_return_t _initializeAppleMobileFileIntegrity(): library validation will not mark external binaries as platform

I may be wrong, but it looks like there are two more new boot arguments: amfi_allow_any_signature and amfi_get_out_of_my_way
Let me verify this after a cup of coffee…

Yes. Setting amfi_get_out_of_my_way=0x1 also gives me the:

kern_return_t _initializeAppleMobileFileIntegrity(): signature enforcement disabled by boot-arg

Adding cs_enforcement_disable=0x1 to the boot arguments gave me one more line:

kern_return_t _initializeAppleMobileFileIntegrity(): cs_enforcement disabled by boot-arg

And there are two more boot arguments that you may want to give a go: cs__enforcement_panic and panic_on_cs_killed

Now I really want my Latte Macchiato 😉