- Make sure you use a kernel with console enabled
- Confirm that your serial tty's are detected with
dmesg | grep tty:[ 0.000000] console [tty0] enabled
[ 1.323949] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 1.568561] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 1.592267] 00:0c: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 1.614293] 00:10: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A - Edit
/etc/securettyand uncomment the lines matching thettySyou got fromdmesg. Else you won't be able to logon as root. - Edit your
/etc/inittaband uncomment the lines:s1:12345:respawn:/sbin/agetty -L ttyS0 9600 vt100
While you're at it, you probably want to change the
s2:12345:respawn:/sbin/agetty -L ttyS1 9600 vt1009600 vt100to115200 linux, if you use putty in serial mode to connect for instance. - If you want the boot messages on serial as well (recommended!), make sure you append a
console=line to your kernel. For instance, if using LILO and for 115200 bauds, you would add a line:append = "console=ttyS0,115200"
2011-08-31
Enabling serial console on Linux Slackware
I'm doing this frequently enough to warrant a post.
2011-08-03
Extracting a single DTS/AC3 channel from an MKV file as a PCM WAV
Well, since audio and video software editors are still not there yet, a quick recepy.
Say you have a H264/DTS MKV video file and you want to extract the center channel, as WAV, for easy editing.
Say you have a H264/DTS MKV video file and you want to extract the center channel, as WAV, for easy editing.
- Download tsMuxeR and extract the audio stream as a .dts (eg. "multichannel.dts"), using the GUI
- Download eac3to and run the following command to convert to a multichannel PCM WAV:
eac3to.exe multichannel.dts multichannel.wav - Download wavosaur and open the multichannel WAV. Then kill the channels you don't need, edit the file, etc.
2011-06-30
Slackware 13.37 and minicom
Doesn't work by default. Wanna know why? /etc/minirc.dfl is missing a Line Feed. Yes, really, all you need to do is add an extra blank like there.
2011-05-25
Installing OSX (Snow Leopard) + Linux (Slackware 13.37 x86_64) on a GUID/GPT disk, with Software RAID enabled (ICH8R) - Part 5
Focusing on Linux + LILO setup, to (hopefully) conclude this series.
At this stage, you are supposed to have a standalone GPT/GUID disk, with a bootable OSX (Chameleon, Chimera), as well as free space for a Linux installation.
More disk partitioning
First order of the day is to pick up the latest Slackware distro (13.37 at the time of this post) and fire it up. Earlier versions of Slackware cannot handle GPT disks, and I don't believe they include gdisk either, so make sure you pick the very latest.
Now, since we seeded the partitioning from OSX and left some free space, when firing up gdisk (using sdc here as sda+sdb are used by Windows 7 in ICH8R RAID1) you'll be greeted with the following:
Slackware and LILO setup
The Slackware install is as straightforward as usual, so I'm not going to comment on it. At the end, just install LILO on the MBR of your standalone OSX/Slackware disk (here
So how about we add OSX boot to our
Off we go then and add the following at the end of
LILO troubles
Now, with the Windows RAID issue being sorted, let's try again, shall we:
Booting GPT partitions using MBR tools
I'll cut to the chase, our actual problem here is that LILO (as well as GRUB) is an MBR bootloader, not a GPT one. Therefore it actually uses the MBR partition table, and if you look at this table, you'll see that as far as MBR is concerned, /dev/sdc2 is nowehere to be found:
Aha! Well, the trick here is that, when booting the system, LILO doesn't need to know how the partition or filesystem is setup. Since the kernel file is always available to the Linux system you want to run LILO from (duh!), LILO can point to the actual kernel image sectors directly, so it actually bypasses the whole partition table (as well the filesystem), and just provides a list of raw blocks to read. Haven't you learned something interesting today? And that is why even a non GPT aware bootloader like LILO is able to boot from a kernel residing on a GPT Linux system partition. But of course, as soon as you leave the system partition, then LILO needs an MBR reference, to know where the start of the target partition is located, which it cannot find.
gptsync to the rescue!
At first glance it looks like we may have to abandon LILO. As far as I know, GRUB is unlikely to perform any better though (it's also an MBR based bootloader), but there exist projects targeted at GPT such as eLILO, though these may also require an EFI platform as well, which may also render them useless for our usage scenario.
Now, remember what I said about protective MBR tables for GPT disks and how both MBR and GPT could coexist? How about we created an MBR table that contains the same partition information as our GPT one then? Well, that's exactly what the rEFIt's gptsync tool is all about. This is a tool that can take a GPT partition table and create an exact MBR clone of it, so that MBR aware tools get the relevant information about the partitions.
Of course, this can only work if the GPT partition doesn't deviate too much from MBR compatibility requirements, which in most case (if your HDD is less than 2 TB as this is the hard limit for maximum MBR), shouldn't be a problem.
At this stage you have two options: pick up the binary gptsync executable for OSX from the Mac disk image or recompile your own from source in Linux. If you want a precompiled gptsync for OSX you can find one here (direct mirror), but considering that we're in Linux right now, we'll go the recompilation route. After having downloaded and extracted the latest refit package, just navigate to the
Final LILO tuning
Alrighty. Time for a new run at LILO:
NB: if you get an "invalid block" error on your OSX partition in LILO, this means that your OSX bootloader (Chameleon, Chimera) has not been properly installed, so you will need to fix that first.
With LILO in place, you should find that you now have multiboot between Linux, Windows and OSX, and you didn't have to forfeit your ICH8R Windows partition in the slightest.
As is obvious from the length of these posts, this whole process took some fairly heavy lifting, but I hope that was worth it!
At this stage, you are supposed to have a standalone GPT/GUID disk, with a bootable OSX (Chameleon, Chimera), as well as free space for a Linux installation.
More disk partitioning
First order of the day is to pick up the latest Slackware distro (13.37 at the time of this post) and fire it up. Earlier versions of Slackware cannot handle GPT disks, and I don't believe they include gdisk either, so make sure you pick the very latest.
Now, since we seeded the partitioning from OSX and left some free space, when firing up gdisk (using sdc here as sda+sdb are used by Windows 7 in ICH8R RAID1) you'll be greeted with the following:
# gdisk /dev/sdc
GPT fdisk (gdisk) version 0.6.14
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/sdc: 234441648 sectors, 111.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 592CD063-7F0A-4F52-81EC-A58C5D3F859C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 8-sector boundaries
Total free space is 175418693 sectors (83.6 GiB)
Number Start (sector) End (sector) Size Code Name
1 40 409639 200.0 MiB EF00 EFI System Partition
2 409640 59022927 27.9 GiB AF00 Snow Leopard
Command (? for help): n
Partition number (3-128, default 3):
First sector (34-234441614, default = 59022928) or {+-}size{KMGTP}:
Last sector (59022928-234441614, default = 59022928) or {+-}size{KMGTP}: +30G
Current type is 'Linux/Windows data'
Hex code or GUID (L to show codes, Enter = 0700):
Changed type of partition to 'Linux/Windows data'
Command (? for help): p
Disk /dev/sdc: 234441648 sectors, 111.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 592CD063-7F0A-4F52-81EC-A58C5D3F859C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 8-sector boundaries
Total free space is 112504133 sectors (53.6 GiB)
Number Start (sector) End (sector) Size Code Name
1 40 409639 200.0 MiB EF00 EFI System Partition
2 409640 59022927 27.9 GiB AF00 Snow Leopard
3 59022928 121937487 30.0 GiB 0700 Linux/Windows data
Command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
Do you want to proceed, possibly destroying your data? (Y/N): y
OK; writing new GUID partition table (GPT).
The operation has completed successfully.
- Note 1: You'll notice that there's a 200 MB EFI System Partition. If you want OSX to be happy, even if the OSX bootloader shouldn't need it, better leave it alone.
- Note 2: You'll have noticed that when firing gdisk, it mentioned something about a "protective MBR". This is because GPT and MBR can coexist on the same disk, and therefore an MBR-only aware utility could potentially destroy data. We'll put the MBR+GPT coexistence to good use later on in this post.
- Note 3: If you leave OSX's disk utility create the partition for the Linux system and try to change the type in gdisk, the installer might not see your Linux system partition as a valid target. If that occurs, you should delete the non OSX/EFI System partitions in gdisk (d command), and recreate them.
Slackware and LILO setup
The Slackware install is as straightforward as usual, so I'm not going to comment on it. At the end, just install LILO on the MBR of your standalone OSX/Slackware disk (here
/dev/sdc) as you'd normally do. Reboot, and you oughta be able to access your newly installed Linux system.So how about we add OSX boot to our
etc/lilo.conf and be done with this whole exercise then? The OSX bootloader (Chameleon, etc.) should be able to take the relay after LILO handoff. And while we're at it, we'll also add Windows boot from /dev/sda.Off we go then and add the following at the end of
/etc/lilo.conf:other = /dev/sdaAnd now the fun begins...
label = Windows
other = /dev/sdc2
label = OSX
LILO troubles
# liloHell to the no! What on earth is going on here? Well, a little googling around tells you that LILO is unhappy because our mirrored disks (
Reference: disk "/dev/sdb" (8,16) 0810
LILO wants to assign a new Volume ID to this disk drive. However, changing
the Volume ID of a Windows NT, 2000, or XP boot disk is a fatal Windows error.
This caution does not apply to Windows 95 or 98, or to NT data disks.
Is the above disk an NT boot disk? [Y/n]
/dev/sda and /dev/sdb) bear the same volume ID. Two solutions there:- Solution 1: add a section:
disk = /dev/sdb
to lilo.conf to make it ignore the second mirrored disk altogether. In this case LILO will issue the warning
inaccessibleWarning: bypassing VolumeID scan of drive flagged INACCESSIBLE: /dev/sdbbut proceed. - Solution 2 (better): enable dmraid access to your drive. The thing is that the Slackware installer actually saw our mirrored volume alright (it listed our device automatically as
/dev/md126*) but when booting our newly installed Slackware, the dm volume was no longer there. In case you wonder, this is because the Slackware installer rc.S script issues a/sbin/mdadm -A -safter fuse has been launched, which enables autodetection of mirrored drives.
Therefore, if you just run that same command, the RAID 1 array will be detected and LILO won't complain about Volume IDs.# /sbin/mdadm -A -s
Probably a good idea to add that line in your system's rc.S script as well.
mdadm: Container /dev/md/imsm0 has been assembled with 2 drives
mdadm: Started /dev/md/WindowsRAID1_0 with 2 devices
Now, with the Windows RAID issue being sorted, let's try again, shall we:
# liloSon of a "£$%^&!! What's going on there?
Added Linux *
Added Windows
Warning: Device 0x0820: Inconsistent partition table, 2nd entry
CHS address in PT: 0:0:0 --> LBA (-1)
LBA address in PT: 0 --> CHS (0:0:1)
Fatal: Either FIX-TABLE or IGNORE-TABLE must be specified
If not sure, first try IGNORE-TABLE (-P ignore)
Booting GPT partitions using MBR tools
I'll cut to the chase, our actual problem here is that LILO (as well as GRUB) is an MBR bootloader, not a GPT one. Therefore it actually uses the MBR partition table, and if you look at this table, you'll see that as far as MBR is concerned, /dev/sdc2 is nowehere to be found:
# fdisk -l /dev/sdcWait a minute, if that's the case, how comes LILO was able to boot our Linux GPT partition then? Isn't that one GPT too?
WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sdc: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x41b82465
Device Boot Start End Blocks Id System
/dev/sdc1 1 234441647 117220823+ ee GPT
Aha! Well, the trick here is that, when booting the system, LILO doesn't need to know how the partition or filesystem is setup. Since the kernel file is always available to the Linux system you want to run LILO from (duh!), LILO can point to the actual kernel image sectors directly, so it actually bypasses the whole partition table (as well the filesystem), and just provides a list of raw blocks to read. Haven't you learned something interesting today? And that is why even a non GPT aware bootloader like LILO is able to boot from a kernel residing on a GPT Linux system partition. But of course, as soon as you leave the system partition, then LILO needs an MBR reference, to know where the start of the target partition is located, which it cannot find.
gptsync to the rescue!
At first glance it looks like we may have to abandon LILO. As far as I know, GRUB is unlikely to perform any better though (it's also an MBR based bootloader), but there exist projects targeted at GPT such as eLILO, though these may also require an EFI platform as well, which may also render them useless for our usage scenario.
Now, remember what I said about protective MBR tables for GPT disks and how both MBR and GPT could coexist? How about we created an MBR table that contains the same partition information as our GPT one then? Well, that's exactly what the rEFIt's gptsync tool is all about. This is a tool that can take a GPT partition table and create an exact MBR clone of it, so that MBR aware tools get the relevant information about the partitions.
Of course, this can only work if the GPT partition doesn't deviate too much from MBR compatibility requirements, which in most case (if your HDD is less than 2 TB as this is the hard limit for maximum MBR), shouldn't be a problem.
At this stage you have two options: pick up the binary gptsync executable for OSX from the Mac disk image or recompile your own from source in Linux. If you want a precompiled gptsync for OSX you can find one here (direct mirror), but considering that we're in Linux right now, we'll go the recompilation route. After having downloaded and extracted the latest refit package, just navigate to the
gptsync directory and run make -f Makefile.unix. As these utilities are fairly simple, this should produce a gptsync and showpart executable in the same directory. Might be a good idea to see what showpart reports before going further, right?# ./showpart /dev/sdcDammit! Does no single tool work as expected out of the box these days, or is it just that I'm always one step ahead in trying cutting edge stuff? Long story short, you get this error on 64 bit Linux environments because the tools use
Current GPT partition table:
Warning: Unknown GPT spec revision 0x00010000
Floating point exception
unsigned long for 32 bit unsigned, and unsigned long is not 32 bit on x86_64. Easiest way I found to fix this is to include <stdint.h> in gptsync.h and then change the UINT8, UINT16, UINT32, UINT64 typedefs to use uint8_t, uint16_t, etc.... Once this is done:# ./showpart /dev/sdcMuch better! Off we go then:
Current GPT partition table:
# Start LBA End LBA Type
1 40 409639 EFI System (FAT)
2 409640 59022927 Mac OS X HFS+
3 59022928 121937487 Basic Data
Current MBR partition table:
# A Start LBA End LBA Type
1 1 234441647 ee EFI Protective
MBR contents:
Boot Code: LILO
Partition at LBA 40:
Boot Code: None (Non-system disk message)
File System: FAT32
Listed in GPT as partition 1, type EFI System (FAT)
Partition at LBA 409640:
Boot Code: None
File System: Unknown
Listed in GPT as partition 2, type Mac OS X HFS+
Partition at LBA 59022928:
Boot Code: None
File System: ext4
Listed in GPT as partition 3, type Basic Data
# ./gptsync /dev/sdc
Current GPT partition table:
# Start LBA End LBA Type
1 40 409639 EFI System (FAT)
2 409640 59022927 Mac OS X HFS+
3 59022928 121937487 Basic Data
Current MBR partition table:
# A Start LBA End LBA Type
1 1 234441647 ee EFI Protective
Status: MBR table must be updated.
Proposed new MBR partition table:
# A Start LBA End LBA Type
1 1 409639 ee EFI Protective
2 409640 59022927 af Mac OS X HFS+
3 * 59022928 121937487 83 Linux
May I update the MBR as printed above? [y/N] y
Yes
Writing new MBR...
MBR updated successfully!
Final LILO tuning
Alrighty. Time for a new run at LILO:
# liloWell, actually this is not entirely unexpected considering that GPT does away with the MBR requirements of having partitions starting and ending on a cylinder boundary, so of course, if you don't fine tune your GPT partition, you're likely to have an MBR partition table that doesn't meet the MBR specs. However, in this case, we can safely ignore that issue, by making sure we have the following at the top of our /etc/lilo.conf
Added Linux *
Added Windows
Warning: Device 0x0820: Inconsistent partition table, 2nd entry
CHS address in PT: 1023:254:63 --> LBA (16450559)
LBA address in PT: 409640 --> CHS (25:127:15)
Fatal: Either FIX-TABLE or IGNORE-TABLE must be specified
If not sure, first try IGNORE-TABLE (-P ignore)
lba32 # LBA addressing should be default anywayThis time:
ignore-table # ignore CHS vs LBA conflicts in the MBR
# liloYay, at long last, our bootloader installed!
Added Linux *
Added Windows
Warning: Device 0x0820: Inconsistent partition table, 2nd entry
CHS address in PT: 1023:254:63 --> LBA (16450559)
LBA address in PT: 409640 --> CHS (25:127:15)
Warning: The partition table is *NOT* being adjusted.
Added OSX
2 warnings were issued.
NB: if you get an "invalid block" error on your OSX partition in LILO, this means that your OSX bootloader (Chameleon, Chimera) has not been properly installed, so you will need to fix that first.
With LILO in place, you should find that you now have multiboot between Linux, Windows and OSX, and you didn't have to forfeit your ICH8R Windows partition in the slightest.
As is obvious from the length of these posts, this whole process took some fairly heavy lifting, but I hope that was worth it!
Installing OSX (Snow Leopard) + Linux (Slackware 13.37 x86_64) on a GUID/GPT disk, with Software RAID enabled (ICH8R) - Part 4
Tuning the OSX installation
Just a placeholder for now, as I still need for figure a few things. This will encompass removing the need to update AHCI for RAID everytime the system performs an update, making OSX bootable on its own, installing additiona drivers, etc.
All of the above doesn't really need to be performed before the Linux installation, but it looks tidier to keep all the OSX related posts in the same breadth... Stay tuned.
Just a placeholder for now, as I still need for figure a few things. This will encompass removing the need to update AHCI for RAID everytime the system performs an update, making OSX bootable on its own, installing additiona drivers, etc.
All of the above doesn't really need to be performed before the Linux installation, but it looks tidier to keep all the OSX related posts in the same breadth... Stay tuned.
2011-05-24
Installing OSX (Snow Leopard) + Linux (Slackware 13.37 x86_64) on a GUID/GPT disk, with Software RAID enabled (ICH8R) - Part 3
Alright, on to the actual OSX installation. This assumes that you have sorted out the matter of getting your SATA controllers detetected, and have booted your USB installation media with iBoot
Disk partitioning
From there on, this is the regular OSX installation process. After selecting your language and graciously ignoring the EULA, you should be greeted by a list of all the disks that the installation process is able to handle.
Unless you did something wrong in the previous process, you should have all your disks (though some of those may not appear until you run the disk utility - see next step). If you can't see them here at all, then you either screwed up your kext modification or your kext cache rebuilding. Shame on you!
In our case, we're going to use a new drive for the OSX + Linux installation, so the first order of business is to partition our HDD in GPT/GUID mode, using the OSX disk utility, which we prefer over using Linux's gdisk as OSX seems to have some installation quirks that gdisk alone doesn't seem to be able to address. I found out that if you use gdisk to modify the GPT partition, you're likely to have the OSX installer complaining that it cannot boot from it.
To parition the disk, simply launch "Disk Utility" from the Utilities menu at the top. Then select the destination disk and click the "Partition" button.
Now if anyone knows how one can make the OSX Disk Utility to accept user specified sizes, I'd like to hear from you as any attempt I tried to create a 40 GB single partition for OSX, while leaving the rest of the disk unused have failed. Gotta wonder what the point of providing a "Size" field is when it is blatantly ignored. The trick I used then was to go through the various "n-partitions" options, and pick the one that creates a first partition (for OSX) that is as close as possible to the size I actually want. Then just go through all the extra paritions and change their Format to "Free Space".
The points you want to pay attention to are:
Once your partitioning is set double check that you are partitioning the right disk, click Apply and quit the Disk Utility program. The newly created partition should now appear as a valid destination target for the installation process, so just select it and click "Install" (or click Customize then install, as it may be a good idea to remove additional languages or printer support if you don't have use for it). You can now go grab a cup of your favorite beverage and come back when the installation process has completed.
Dude, where's my boot?
So the install process completed successfully, the machine rebooted (more or less as the reboot process can be a bit flaky), and iBoot sees the new OSX installation alright. "VICT..., oh wait, this doesn't boot at ALL! AGHHH!!!".
Of course it doesn't you silly! To reiterate what I pointed out at the end of the previous post, the OSX installation process installs a clean, unmodified set of kexts, therefore all our good work about supporting the RAID controller on the USB key has been ignored. For the time being, we'll just fix that as we previously did, but instead of accessing the USB key, we'll do it on the OSX target drive:
Disk partitioning
From there on, this is the regular OSX installation process. After selecting your language and graciously ignoring the EULA, you should be greeted by a list of all the disks that the installation process is able to handle.
Unless you did something wrong in the previous process, you should have all your disks (though some of those may not appear until you run the disk utility - see next step). If you can't see them here at all, then you either screwed up your kext modification or your kext cache rebuilding. Shame on you!
In our case, we're going to use a new drive for the OSX + Linux installation, so the first order of business is to partition our HDD in GPT/GUID mode, using the OSX disk utility, which we prefer over using Linux's gdisk as OSX seems to have some installation quirks that gdisk alone doesn't seem to be able to address. I found out that if you use gdisk to modify the GPT partition, you're likely to have the OSX installer complaining that it cannot boot from it.
To parition the disk, simply launch "Disk Utility" from the Utilities menu at the top. Then select the destination disk and click the "Partition" button.
Now if anyone knows how one can make the OSX Disk Utility to accept user specified sizes, I'd like to hear from you as any attempt I tried to create a 40 GB single partition for OSX, while leaving the rest of the disk unused have failed. Gotta wonder what the point of providing a "Size" field is when it is blatantly ignored. The trick I used then was to go through the various "n-partitions" options, and pick the one that creates a first partition (for OSX) that is as close as possible to the size I actually want. Then just go through all the extra paritions and change their Format to "Free Space".
The points you want to pay attention to are:
- Label your OSX partition with something descriptive - don't keep "Untitled 1" (though you can change that later)
- Select "Mac OS Extended (Case-sensitive, Journaled)" for the Format (it's an UNIX based OS, it IS case sensitive dammit!). Now, if you ever plan to modify your OS files from Linux, then you may want to select a non Journaled filesystem, as the current HFS driver from Linux does not offer write access on Journaled.
- MAKE SURE "GUID Partition Table" (a.k.a. GPT) is used by clicking the "Options" button. Though you should be able to get away with MBR, the whole point of this exercise is to have a GPT disk to play with, so that's what we're gonna use.
Once your partitioning is set double check that you are partitioning the right disk, click Apply and quit the Disk Utility program. The newly created partition should now appear as a valid destination target for the installation process, so just select it and click "Install" (or click Customize then install, as it may be a good idea to remove additional languages or printer support if you don't have use for it). You can now go grab a cup of your favorite beverage and come back when the installation process has completed.
Dude, where's my boot?
So the install process completed successfully, the machine rebooted (more or less as the reboot process can be a bit flaky), and iBoot sees the new OSX installation alright. "VICT..., oh wait, this doesn't boot at ALL! AGHHH!!!".
Of course it doesn't you silly! To reiterate what I pointed out at the end of the previous post, the OSX installation process installs a clean, unmodified set of kexts, therefore all our good work about supporting the RAID controller on the USB key has been ignored. For the time being, we'll just fix that as we previously did, but instead of accessing the USB key, we'll do it on the OSX target drive:
- Boot once more into your USB installation media with iBoot
- go to Utilities→Terminal
- issue the command "mount". It should list your OSX partition, indicate that it has write acces, and tell you where it is mounted (should be in /Volumes/Something)
cd /Volumes/<your_osx_partition>/System/Library/Extensions/AppleAHCIPort/Contents- Issue
nano Info.plist(you do have nano on your installation key, right? If not, see the first post in this series). - Apply the same change as we did in previous post, namely change the
<string>0x01060100&0xffffff00</string>part to<string>0x01060100&0xffffff00 0x01040000&0xffff0000</string>and save the file. - Now, as previously, we need to rebuild the kext cache. The only difference is that unlike the installation media, the cache for Snow Leopard is located at
System/Library/Caches/com.apple.kext.caches/Startup, so the command you want to issue is:kextcache -v 1 -t -l -a i386 -a x86_64 -m /Volumes/<your_osx_partition>/System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext /Volumes/<your_osx_partition>/System/Library/Extensions
- Quit the installer and restart the machine
- Remove the USB key and boot into iBoot. Then select your OSX partition. This time it should boot alright and finalize the installation process. Wilkommen, Bienvenue, Welcome to cabaret indeed! But keep that USB installation media handy, as you are likely to need it again very soon.
Installing OSX (Snow Leopard) + Linux (Slackware 13.37 x86_64) on a GUID/GPT disk, with Software RAID enabled (ICH8R) - Part 2
With both the iBoot CD and the OSX installation USB key rearing to go (see previous post), it's time to insert them both, and reboot, while making sure the CD/DVD drive is selected as your boot device. After a while, the iBoot boot selection screen should pop up, and provide you with the option to select "Mac OSX Install DVD" to boot from (which is actually our USB key) to start the installation process. NB: the name may be truncated, but if this is your first OSX install, just make sure you pick up the icon wit the Apple logo, as there should be only one.
Now, if your SATA controller was set to AHCI, or if you were using a JMicron SATA port, your target hard drive would likely be detected by the installer and you could actually proceed with the installation.
But of course, that wouldn't teach you how to add support for custom hardware on the fly, such as RAID SATA controller, would it, so where's the fun in that? Plus if you're reading this guide, you're trying to get an ICH controller in RAID mode supported.
In our case, if we try to iBoot our USB key, the installer won't see our target disk at all, so we need to address that on the USB key. The nice thing about our USB key procedure is that we can add AHCI support on the fly, and the producedure highlighted below should actually work for any SATA RAID controller (ICH9R, nVidia, whatever) that supports AHCI passthrough, not just ICH8R.
What's the big deal with AHCI vs RAID anyway?
As it turns out not much. The thing is, even in RAID mode, an ICH controller such as the one we use does AHCI passthrough. So why does the OSX installer see the disk in AHCI mode, but not in RAID mode?
Glad you asked. This is best illustrated by looking at the output from Linux's
For the P5B Deluxe, here is what
As it turns out, the 0x0106 class ID is what the Apple AHCI driver uses to find out if a SATA controller is one it should support through AHCI (well, it actually uses 0x01060100 with a 0xffffff00 mask as we will see shortly), so that's the reason why, as soon as our class ID changes to 0x0104, OSX says "Hey, I don't know how to access this type of controller!" and gives up.
That's all very well, but that doesn't tell me how to get my RAID SATA controller recognized
Patience my friend... The key to achieving anything is understanding how it actually works, which we've done, so now is the time to get to the good part.
As you may already be aware, getting hardware recognized on OSX is done through the addition or modification of kexts. A kext, which stands for Kernel Exttension is pretty much the OSX equivalent of a driver or a Linux module. Therefore, to make our RAID controller recognized by the AHCI driver Apple uses, we will need to modify the kexts from our USB installation media to trick the installer into recognizing our non-officially unsupported hardware.
The kext of interest to us is the
If you look at this file you see that it contains a section:
Great, then we just need to change the
Rebuidling the kext cache
Not so fast! If you just edit and save the Info.plist on the USB key, your RAID controller still will not be detected.
The reason for that is that kexts are executed at the kernel level, so Apple doesn't simply let you load a modified kext like this. Instead, an additional step is needed, which is the rebuilding of what is known as the kext cache. This cache is the
Note that the procedure I am highlighting below can be done from an existing Snow Leopard OS, rather than on the USB key itself, but if you do so, be midnful that there's a whole business going on with regards to permissions and ownership, which, if you mount your USB key as anybody but root (not a problem when using the OSX from the key), may result in an error message such as:
With all the above completed, on the second iBoot/USB installer run, you should now see all hard drives recognized, including the ones connected in a SATA connector in RAID mode, with the ability to use them as installation destination. Neat!
Before shouting "victory" though, you should be aware that:
Now, if your SATA controller was set to AHCI, or if you were using a JMicron SATA port, your target hard drive would likely be detected by the installer and you could actually proceed with the installation.
But of course, that wouldn't teach you how to add support for custom hardware on the fly, such as RAID SATA controller, would it, so where's the fun in that? Plus if you're reading this guide, you're trying to get an ICH controller in RAID mode supported.
In our case, if we try to iBoot our USB key, the installer won't see our target disk at all, so we need to address that on the USB key. The nice thing about our USB key procedure is that we can add AHCI support on the fly, and the producedure highlighted below should actually work for any SATA RAID controller (ICH9R, nVidia, whatever) that supports AHCI passthrough, not just ICH8R.
What's the big deal with AHCI vs RAID anyway?
As it turns out not much. The thing is, even in RAID mode, an ICH controller such as the one we use does AHCI passthrough. So why does the OSX installer see the disk in AHCI mode, but not in RAID mode?
Glad you asked. This is best illustrated by looking at the output from Linux's
lspci both in BIOS AHCI mode and in BIOS RAID mode.For the P5B Deluxe, here is what
lspci -nn reports for our SATA ICH8R controller in AHCI mode:00:1f.2 SATA controller [0106]: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) 6 port SATA AHCI Controller [8086:2821] (rev 02)And here is the same, but in RAID mode:
00:1f.2 RAID bus controller [0104]: Intel Corporation 82801 SATA RAID Controller [8086:2822] (rev 02)The important things to notice is that both the class ID and the controller VID:PID have changed, from (0106, 8086:2821) to (0104, 8086:2822) respectively.
As it turns out, the 0x0106 class ID is what the Apple AHCI driver uses to find out if a SATA controller is one it should support through AHCI (well, it actually uses 0x01060100 with a 0xffffff00 mask as we will see shortly), so that's the reason why, as soon as our class ID changes to 0x0104, OSX says "Hey, I don't know how to access this type of controller!" and gives up.
That's all very well, but that doesn't tell me how to get my RAID SATA controller recognized
Patience my friend... The key to achieving anything is understanding how it actually works, which we've done, so now is the time to get to the good part.
As you may already be aware, getting hardware recognized on OSX is done through the addition or modification of kexts. A kext, which stands for Kernel Exttension is pretty much the OSX equivalent of a driver or a Linux module. Therefore, to make our RAID controller recognized by the AHCI driver Apple uses, we will need to modify the kexts from our USB installation media to trick the installer into recognizing our non-officially unsupported hardware.
The kext of interest to us is the
AppleAHCIPort.kext (makes sense), that resides in /System/Library/Extensions/ (which you will often see abbreviated as S/L/E on hackintosh forums). Most specifically, what we will want to edit is the Info.plist file found in /System/Library/Extensions/AppleAHCIPort.kext/Contents.If you look at this file you see that it contains a section:
<key>GenericAHCI</key>Well, well, well, is that our 0x0106 generic AHCI class right there?
<dict>
<key>CFBundeIdentifier</key>
<string>com.apple.driver.AppleAHCIPort</string>
<key>Chipset Name</key>
<string>AHCI Standard Controller</string>
<key>IOClass</key>
<string>AppleAHCI</string>
<key>IOPCIClassMatch</key>
<string>0x01060100&0xffffff00</string>
<key>IOProbeScore</key>
<integer>800</integer>
<key>IOProviderClass</key>
<string>IOPCIDevice</string>
<key>Vendor Name</key>
<string>Unknown</string>
</dict>
Great, then we just need to change the
<string>0x01060100&0xffffff00</string> part to <string>0x01060100&0xffffff00 0x01040000&0xffff0000</string> to add AHCI passthrough support to any RAID controller (if you do have an actual dedicated non SATA RAID controller on your platform, you probably shouldn't use such a blanket approach, but instead duplicate one of the later sections), save the file, reboot, and be done with it, right?Rebuidling the kext cache
Not so fast! If you just edit and save the Info.plist on the USB key, your RAID controller still will not be detected.
The reason for that is that kexts are executed at the kernel level, so Apple doesn't simply let you load a modified kext like this. Instead, an additional step is needed, which is the rebuilding of what is known as the kext cache. This cache is the
Extensions.mkext file located in your /System/Library/ directory (where the Extensions/ directory also resides).Note that the procedure I am highlighting below can be done from an existing Snow Leopard OS, rather than on the USB key itself, but if you do so, be midnful that there's a whole business going on with regards to permissions and ownership, which, if you mount your USB key as anybody but root (not a problem when using the OSX from the key), may result in an error message such as:
AppleAHCIPort.kext is not authentic; omitting from mkext.In our case, we'll run everything from the key, and the default execution level is that of the root user, so it should be fairly simple:
Authentication Failures:
File owner/permissions are incorrect (must be root:wheel, nonwritable by group/other):
/Volumes/Mac OS X Install DVD/System/Library/Extensions/AppleAHCIPort.kext/Contents/Info.plist
- Open a terminal window by selecting Utilities→Terminal in the top menu (notice that we haven't had to accept any EULA to do so, so you are free to edit your OSX installation media from the embedded Terminal in any way you like)
- Remount the USB key as read/write (by default it is mounted read only) by issuing the command:
mount -u -o rw /
Note: Make sure you don't close your terminal session after you do that, as Terminal will not launch if the system is already r/w (which is also the reason why we do it manually). You should be able to check that the USB file system is now mounted r/w by issuingmount - If you haven't done so already, copy the nano text editor, which you should have copied into the root directory to /usr/bin with the command:
cp /nano /usr/bin
Or you can just leave it in root and issue/nanowhenever you need to edit a file. - Navigate to the Info.plist file we want to edit with
cd /System/Library/Extensions/AppleAHCIPort.kext/Contents/and run nanonano Info.plist - Change the
<string>0x01060100&0xffffff00</string>line in the<key>GenericAHCI</key>section to<string>0x01060100&0xffffff00 0x01040000&0xffff0000</string> - Save the file (Ctrl-X then 'y' to save it)
- navigate to the /System/Library/ directory with
cd /System/Library/. This is the directory that contains the Extensions.mkext file - Rebuild the kext cache with:
kextcache -v 1 -t -l -a i386 -a x86_64 -m Extensions.mkext Extensions
It should complete without errors (or a benign warning about the JMicronATA.kext) but if there are any issues reported about the AppleAHCIPort.kext, they should be explicitly listed. - Close terminal and leave the installer (Mac OS X Installer→Quit Mac OS X Installer) then select Restart. You must restart the installation process completely (i.e. reboot) for our changes to be applied.
With all the above completed, on the second iBoot/USB installer run, you should now see all hard drives recognized, including the ones connected in a SATA connector in RAID mode, with the ability to use them as installation destination. Neat!
Before shouting "victory" though, you should be aware that:
- When OSX installs, it will extract and install its own unmodified AppleAHCIPort kext (from the
Essentials.pkgfound inSystem/Installation/Packages/directory on the installation media, so what we have done will only work during installation, but the installed OSX will not actually be able to see its disk and we'll have to work around that - bummer! - iBoot offers the option to ignore the cache during bootup (press the down key on the OS you want to boot, and then select "Boot Ignore Caches"), so we probably could have gotten away with simply modifying the Info.plist file and used that iBoot option instead of going through this whole cache rebuilding exercise...
2011-05-23
Installing OSX (Snow Leopard) + Linux (Slackware 13.37 x86_64) on a GUID/GPT disk, with Software RAID enabled (ICH8R) - Part 1
Now that's quite a mouthful of a title. And considering that there is much to discuss, I will break this whole thing into a multipart post, so here is the first part of our series.
Introduction & Requirements
First of all, I gotta start with the disappointing news that, despite what you might anticipate from the title, this is not a guide to setup motherboard RAID (a.k.a. fakeRAID) support in either OSX or Linux (though the later is no biggie - see previous posts here for various options). The mention of RAID here is to indicate that we want to do an OSX and Linux that coexists nicely with a previous fakeRAID installation, by NOT requiring you to disable RAID settings in BIOS if they are already enabled.
In practice here, the goal is to add OSX and Linux on a separate non-RAID disk to an existing Windows 7 installation that was set to use fakeRAID (RAID 1 from ICH8R), without touching the BIOS settings.
Basically, what happened is that I recently upgraded my good old Asus P5B Deluxe based rig to a dual Samsung F3 1TB, installed Windows 7 ontop of the ICH8R RAID 1 array which I created in BIOS as a result, and since that left me with a bunch of unused SATA drives, I thought I would put one of these to good use by installing both OSX and Slackware on it (that Slackware 13.37 sure IS nice!), and use it to boot the whole lot. Sounds easy, but it actually presents a nice set of challenges, some of which include:
My kingdom for AHCI? Surely you are jesting!
Question: What do all the hackintosh installation guides you find on the internet have in common?
Answer: They all begin with "You MUST change your BIOS settings and set your SATA controller to AHCI before you begin the installation"
Of course, this is utter nonsense. If a guide begins with "You MUST change your BIOS settings to something potentially incompatible with what you want, and risk destroying existing data as a result" (by disabling RAID mode from ICHR), then it's a lousy guide and you should stop right there. For having been a fakeRAID/motherboard RAID user for some years now, with both Intel and nVidia solutions, I'll tell you frankly: all those who say "Don't use fakeRAID: buy a dedicated RAID controller instead" are idiots. First of all, money to buy a separate controller doesn't grow on tree and secondly, with all these cores lying around, the idea that one should spend extra, when all they want is add fault tolerance to consumer grade hardware is ludicrous. We're not building an enterprise grade server here dammit! Besides, most of these solutions are rather well supported in Linux now, which means that if you screw up your fakeRAID array, you may just be able to do something about it. With a hardware proprietary non reverse engineered RAID solution on the other hand, you might not be so lucky...
Therefore, the hell with changing your BIOS settings to AHCI! If Linux doesn't bat an eyelid about accessing SATA HDDs with an ICH controller in RAID mode, why should OSX be the exception? Therefore, we'll keep our ICH BIOS settings to RAID, thank you very much, and ignore all this AHCI brainwashing.
Now, since the OSX installation media has not been designed to support ICH8 in RAID mode, if you try something like iBoot and an unmodified OSX installation media, then unless your HD is plugged on a JMicron SATA controller (which is an actual possibility on the P5B Deluxe), the OSX installer will not see it. This basically means we're gonna have to modify the OSX installation system so that it sees our ICH8R controller as AHCI ICH8 and that's also where doing the install from an 8GB (or more) USB key, that we can modify on the fly, will come real handy.
But first, we gotta create the base vanilla installer on our key.
Creating a vanilla OSX installation USB key
To do that, you need to be in your existing OSX system (VMWare, soon-to-be-ex-friend's machine, etc.). I'm going to assume that you have the vanilla OSX disk as a .dmg. The steps to create the key then are as follow:
The restore process will take a few minutes (15-30 mins), but, once completed, will give you the ability to install OSX from USB using iBoot.
Installing a text editor
Because we're going to do it the hard way, a must have for our USB key is a text editor, so that we can tune the USB key to our needs during the installation process (more about this in the next post). As a UNIX veteran, I swear by vi, but I do understand that not everybody is confortable with vi sequences, so to alleviate the editing process, we'll go with the more intuitive GNU nano.
One might wonder why there is no default editor on the vanilla OSX installation media, but the answer is that Apple obviously considered an installer to be read-only affair, so it made little sense adding vi or nano to the installation utilities. On the other hand, we will very much require the ability to edit files on USB, so we need a text editor for OSX. Of course, since GNU nano is GPL and therefore, anybody can legally publish a nano OSX binary to copy onto an USB key, I'm not going think twice about putting the one I conveniently recompiled from source (using Xcode 3.2) and that I am putting online here.
Once downloaded, just drag and drop the "nano" file onto your USB stick folder (where you'll see the OSX installation paraphernalia). As long as it's on the key, we're good - no need to worry about placing it into bin/ or usr/bin/ just yet. Once it's copied, you can eject the USB, as at this stage, we won't need to access another OSX system: we'll just do everything we need from USB.
iBoot
Finally, the last piece we need for the installation is the latest iBoot CD (bugmenot). And while on the iBoot download page, you might as well download MultiBeast, as it will come handy to finalize our installation.
The iBoot zip basically contains an ISO which you should burn to a CD. Note that if you can't use a CD, you should be able to use that ISO image to produce an alternate iBoot loader (eg use a second USB key or TFTP), but I'm not going to detail that.
Introduction & Requirements
First of all, I gotta start with the disappointing news that, despite what you might anticipate from the title, this is not a guide to setup motherboard RAID (a.k.a. fakeRAID) support in either OSX or Linux (though the later is no biggie - see previous posts here for various options). The mention of RAID here is to indicate that we want to do an OSX and Linux that coexists nicely with a previous fakeRAID installation, by NOT requiring you to disable RAID settings in BIOS if they are already enabled.
In practice here, the goal is to add OSX and Linux on a separate non-RAID disk to an existing Windows 7 installation that was set to use fakeRAID (RAID 1 from ICH8R), without touching the BIOS settings.
Basically, what happened is that I recently upgraded my good old Asus P5B Deluxe based rig to a dual Samsung F3 1TB, installed Windows 7 ontop of the ICH8R RAID 1 array which I created in BIOS as a result, and since that left me with a bunch of unused SATA drives, I thought I would put one of these to good use by installing both OSX and Slackware on it (that Slackware 13.37 sure IS nice!), and use it to boot the whole lot. Sounds easy, but it actually presents a nice set of challenges, some of which include:
- Adding extra drivers to a vanilla OSX installation media, so that it recognizes our AHCI controller even in RAID mode
- Allow LILO (or GRUB) to boot OSes other than the main Linux system on a GPT/GUID partitioned disk (with a BIOS that is NOT EFI)
- Installing OSX Snow Leopard from scratch, including updates and necessary drivers for your rig, but WITHOUT having to spend one's life endlessly browsing the OSX86 forums. Yes, the effort is much appreciated guys, but I have better things to do then become an expert on kexts, Chameleon, DSDT, iBoot and whatnot.
- Asus P5B Deluxe with 2x 1TB SATA HDDs in RAID mode (ICH8R) and 1x 320GB HDD (non RAID)
- nVidia GPU (7950GT)
- PS/2 keyboard, USB mouse + IDE DVD (the DVD is only going to be used for iBoot, so SATA or IDE won't matter one bit)
- OSX Snow Leopard official installation DVD or .dmg image (build 10A421A)
- One 8 GB (or bigger) USB key
- An existing Snow Leopard installation. Yeah, I know it sucks, but hey.
My kingdom for AHCI? Surely you are jesting!
Question: What do all the hackintosh installation guides you find on the internet have in common?
Answer: They all begin with "You MUST change your BIOS settings and set your SATA controller to AHCI before you begin the installation"
Of course, this is utter nonsense. If a guide begins with "You MUST change your BIOS settings to something potentially incompatible with what you want, and risk destroying existing data as a result" (by disabling RAID mode from ICHR), then it's a lousy guide and you should stop right there. For having been a fakeRAID/motherboard RAID user for some years now, with both Intel and nVidia solutions, I'll tell you frankly: all those who say "Don't use fakeRAID: buy a dedicated RAID controller instead" are idiots. First of all, money to buy a separate controller doesn't grow on tree and secondly, with all these cores lying around, the idea that one should spend extra, when all they want is add fault tolerance to consumer grade hardware is ludicrous. We're not building an enterprise grade server here dammit! Besides, most of these solutions are rather well supported in Linux now, which means that if you screw up your fakeRAID array, you may just be able to do something about it. With a hardware proprietary non reverse engineered RAID solution on the other hand, you might not be so lucky...
Therefore, the hell with changing your BIOS settings to AHCI! If Linux doesn't bat an eyelid about accessing SATA HDDs with an ICH controller in RAID mode, why should OSX be the exception? Therefore, we'll keep our ICH BIOS settings to RAID, thank you very much, and ignore all this AHCI brainwashing.
Now, since the OSX installation media has not been designed to support ICH8 in RAID mode, if you try something like iBoot and an unmodified OSX installation media, then unless your HD is plugged on a JMicron SATA controller (which is an actual possibility on the P5B Deluxe), the OSX installer will not see it. This basically means we're gonna have to modify the OSX installation system so that it sees our ICH8R controller as AHCI ICH8 and that's also where doing the install from an 8GB (or more) USB key, that we can modify on the fly, will come real handy.
But first, we gotta create the base vanilla installer on our key.
Creating a vanilla OSX installation USB key
To do that, you need to be in your existing OSX system (VMWare, soon-to-be-ex-friend's machine, etc.). I'm going to assume that you have the vanilla OSX disk as a .dmg. The steps to create the key then are as follow:
- Plug in your USB key. Don't worry if it automounts.
- Open the OSX disk utility (Applications -> Utilities ->Disk Utilities). You should see something like "8.02 GB Generic STORAGE DEVICE Media" or something, as your USB volume
- Click on the "Partition" button on the left, to access the partition tab, then click on the "Current" Volume Scheme button so that you get a dropdown, and select 1 partition
- In options, under the partition diagram, make sure you select "GUID Partition Table". For the Format, you select "Mac OS Extended" (though it shouldn't matter)
- Click Apply to partition & format the USB key
- Once formatting is complete, select the Restore button
- Now double click on your OSX .dmg image to mount it (or insert your OSX DVD). A "Mac OS X Install DVD" icon should appear on your desktop
- Drag that icon onto the Source field of the Restore parameters in Disk Utility until a green '+' sign appears, and then drop it there
- For the Destination field, just drag and drop the "Untitled 1" partition, or whatever you called it, from your newly formatted USB stick
- Click the "Restore" button. You will be prompted for the system's administrative password.
The restore process will take a few minutes (15-30 mins), but, once completed, will give you the ability to install OSX from USB using iBoot.
Installing a text editor
Because we're going to do it the hard way, a must have for our USB key is a text editor, so that we can tune the USB key to our needs during the installation process (more about this in the next post). As a UNIX veteran, I swear by vi, but I do understand that not everybody is confortable with vi sequences, so to alleviate the editing process, we'll go with the more intuitive GNU nano.
One might wonder why there is no default editor on the vanilla OSX installation media, but the answer is that Apple obviously considered an installer to be read-only affair, so it made little sense adding vi or nano to the installation utilities. On the other hand, we will very much require the ability to edit files on USB, so we need a text editor for OSX. Of course, since GNU nano is GPL and therefore, anybody can legally publish a nano OSX binary to copy onto an USB key, I'm not going think twice about putting the one I conveniently recompiled from source (using Xcode 3.2) and that I am putting online here.
Once downloaded, just drag and drop the "nano" file onto your USB stick folder (where you'll see the OSX installation paraphernalia). As long as it's on the key, we're good - no need to worry about placing it into bin/ or usr/bin/ just yet. Once it's copied, you can eject the USB, as at this stage, we won't need to access another OSX system: we'll just do everything we need from USB.
iBoot
Finally, the last piece we need for the installation is the latest iBoot CD (bugmenot). And while on the iBoot download page, you might as well download MultiBeast, as it will come handy to finalize our installation.
The iBoot zip basically contains an ISO which you should burn to a CD. Note that if you can't use a CD, you should be able to use that ISO image to produce an alternate iBoot loader (eg use a second USB key or TFTP), but I'm not going to detail that.
2011-01-21
Why encrypted firmware is bad
A simple example will suffice.
Let's say I own a digital camera, or a device that contains a digital camera, that uses encrypted firmware.
Now let's say that this firmware has been written in such way that, at regular intervals, and without any form of notification to the user (like a LED blinking or a tell-tale shutter noise), it takes low resolution pictures of what it sees, and stores these unrequited pictures into its embedded storage (which too would be encrypted).
Then, when the user takes a normal high res picture using the digital camera, the firmware adds "noise" to it that contains encrypted image(s) from the hidden low-res pictures it has in memory.
With hi-res image files in the MB range or even better: digital video, it has become exceedingly easy to add "meaningful noise" and play a little steganography on digital photography. There are also ways to ensure sure that an useful data payload can still be recovered, even if the user downsizes the images.
Blissfully unaware of this, the user then uploads some of these high res picture to a public website, as one does. Then malicious entities/government agencies can just run a search on EXIF (if the user didn't remove this data, but even then, with the proper resources, parsing images all day to check for known steganographic payload is not that big a feat) and spy on you at length, provided you keep sharing pictures with friends, etc, and without your knowledge...
Of course, this kind of far fetched scenario would never happen... just like printer manufacturers would never add hidden marks to every page printed, that would uniquely identify what printer (and by extension who) printed some data.
Let's say I own a digital camera, or a device that contains a digital camera, that uses encrypted firmware.
Now let's say that this firmware has been written in such way that, at regular intervals, and without any form of notification to the user (like a LED blinking or a tell-tale shutter noise), it takes low resolution pictures of what it sees, and stores these unrequited pictures into its embedded storage (which too would be encrypted).
Then, when the user takes a normal high res picture using the digital camera, the firmware adds "noise" to it that contains encrypted image(s) from the hidden low-res pictures it has in memory.
With hi-res image files in the MB range or even better: digital video, it has become exceedingly easy to add "meaningful noise" and play a little steganography on digital photography. There are also ways to ensure sure that an useful data payload can still be recovered, even if the user downsizes the images.
Blissfully unaware of this, the user then uploads some of these high res picture to a public website, as one does. Then malicious entities/government agencies can just run a search on EXIF (if the user didn't remove this data, but even then, with the proper resources, parsing images all day to check for known steganographic payload is not that big a feat) and spy on you at length, provided you keep sharing pictures with friends, etc, and without your knowledge...
Of course, this kind of far fetched scenario would never happen... just like printer manufacturers would never add hidden marks to every page printed, that would uniquely identify what printer (and by extension who) printed some data.
Subscribe to:
Posts (Atom)