Slashdot Mirror
EFI Modifications Leaves iMac Unbootable?
jerbare writes "In attempting to run Linux and Windows on the new iMac Core Duo, people experimenting with configuring the EFI Console/Boot loader have found they can no longer boot the machine at all. Dave Schroeder of appleintelfaq.com comments, 'We have already irreversibly lost a couple of iMacs trying to load various EFI modules'. Instructions for breaking the iMac's are presently located at the bottom of the comments."
I might have been living under a rock, but how is the state of Linux on these new Intel Macs? Just being curious here, because I havent seen any real talks about it here (maybe I haven't fine read threshold -1 yet).
Dvorak on Doomtech
Six Months? How about right now. OpenOSX has released their "Wintel" package updated for MacOS X on Intel. It features the BOCHS 'emulator' that will run all manner of Windows, Linux, etc. MacNN has the scoop It's $25 to download.
I’ve done the exact same thing to bypass security features on SPARCstations. Try it sometime—it’s fun!
Tangent: you don’t need to understand Chinese to understand the instructions on that page. ;)
Join Tor today!
Dunno why no one in this thread seems to be talking about vanderpool. Maybe y'all should just wait to hear from someone who knows what they're talking about. (Not me, for example.)
There are no trails. There are no trees out here.
Substitute "user" with Malware.
Download the EFI software from Intel: Or include an copy in the malware.
a sudo command: Or use an escalation of privilege vulnerability
and reboot : Err, not that difficult to achive in software.
It's a fairly well known trick, although you're correct that it's a little bit dangerous. But when you fiddle around with BIOS mods, it comes in handy to have a removable BIOS chip for just that reason.
http://www.google.com/search?q=bios+hot+swapping
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
When the iMac is in this broken state, it doesn't boot, chime, show anything on the screen, or read from media.
;-)
Can't exactly "reinstall from the 10.4.4 media".
Zapping NVRAM (still supported with cmd-opt-P-R), removing the motherboard battery and letting it sit with AC for an extended period, and disconnecting the hard drive all do not revive the machine.
Hello. Just to give a bit of an update on this issue...
The iMacs in question were rendered unbootable by trying to load additional modules from Intel's EFI Sample Implementation. It is not known which module is at fault currently.
Once the iMac is unbootable, it doesn't chime, boot, attempt to access media, or display an image on the screen. Attempts to zap NVRAM (cmd-opt-P-R is still supported for this task on Intel-based Macs), remove the motherboard battery and leave the AC power disconnected for an extended period of time, and disconnecting the hard disk do not resolve the issue.
At present, we seem to have a number of difficult situations that prevent the installation of Windows directly on Intel-based Macs:
1. Apple did not include its own EFI shell or other tools to access the EFI with the Intel-based Macs, so the tools used have consisted of Intel's EFI Sample Implementation, and Tianocore's EFI Developer Kit.
2. Apple's EFI implementation does not include CSM (Compatibility Support Module), the BIOS backward compatibility layer necessary for booting 32-bit versions of Windows (pre-Vista), such as Windows XP.
3. 32-bit versions of Windows do not currently support booting an EFI machine. (And the Gateway Media Center machine with EFI people keep talking about boots Windows XP Media Center Edition 2005 in BIOS compatibility mode, not with EFI.)
4. Windows XP 64-bit and Windows Server 2003 64-bit support EFI, but the Intel Core Duo is a 32-bit architecture.
5. Windows Vista does support EFI, but the EFI booter (cdboot.efi) currently does not appear to be functioning, and/or it is looking for, and not finding, information that it is looking for on the installation DVD. It does display the typical Windows "Please press any key to boot from the CD..." message. However, the DVD does not appear to contain the necessary EFI boot partition, and EFI does not support UDF volumes and El Torito booting. (Yes, this is a DVD obtained via official channels.)
6. Mac OS X's startup disk control panel presents a Windows Vista installation on a FAT/FAT32 volume as a valid bootable volume, but Windows Vista does not support booting from a FAT/FAT32 partition, only NTFS. Mac OS X can read NTFS volumes, but not write to them. This is currently the stage we're at now. No, I haven't tried "just hooking up a drive with Vista installed" (as many have asked elsewhere) or forcibly creating an NTFS partition whose contents are an already-installed instance of Vista.
7. grub, elilo, etc., all do not work on the Intel-based Macs at this time.
Eventually, whatever method boots Windows natively will have to have a nice wrapper put around it to make it easy for a normal person to do so, and easily dual boot in addition.
To regurgitate what I've said a bit elsewhere, the real benefit to most people will come from running Windows alongside Mac OS X in a "virtual machine" environment, in a window or even full screen, with, for example, a hotkey to switch back and forth between Mac OS X and Windows. To many users who prefer Mac OS X, particularly in enterprise, academic, and research environments, but who also have the occasional applications (usually administrative) that require Windows, this configuration would be a holy grail of sorts. And in this configuration, Windows wouldn't be running in emulation, but it would be running at essentially the native speed of the underlying hardware (with the exception of graphics and disk I/O performance). It will be *much* faster than any emulation ever has been, and there will no doubt be several open source (qemu, xen, wine) and commercial (vmware, Virtual PC) that will allow running Windows (or Windows software) in various capacities. Intel's Virtualization Technology (VT), allowing multiple operating systems to run in separate hardware "partitions" on one
Actually, if you RTFC (RTF Comments) which are at the end of the article (as it says in the story) you'll find that you can completely screw your new Intel Mac into not booting. Not even running the OS X install CD will fix it. Here's one of the comments describing the problem:
infested with jello like fishes no melotron wishes
As recently as the G4 towers, a firmware update required the user to physically depress the Programmer's button (the hardware interrupt button) on the computer itself. This may be different now, although I doubt it. The whole point was to make software-only firmware updates impossible in order to avoid this very threat. The hardware simply will not re-flash the firmware without that button being pressed. So at least some social engineering is required to get users to press that button.
I always assumed all computers worked that way. Otherwise, it would be trivial to get people to ruin their firmware -- just trojan horse the thing.
Six Months? How about right now. OpenOSX has released their "Wintel" package updated for MacOS X on Intel. It features the BOCHS 'emulator' that will run all manner of Windows, Linux, etc. MacNN has the scoop It's $25 to download.
Bochs? It's great if you want a full, perfect emulation of PC hardware done completely in software, but it's horribly slow. Oh, and it's both free and open source - that $25 is solely for some crappy third-party GUI. The 'native to Intel' thing just means you're doing a full PC emulation without going through Rosetta as well...
If you do want to emulate a PC in a slightly faster manner, try QEMU. I've no idea if it can be compiled on an Intel-powered Mac yet, but an emulated Windows 98 was just about usable for website testing on my 933MHz iBook G4.
Tedious Bloggy Stuff - hooray?
IBM are lying assholes. Anybody, with $20 worth of equipment can wire up a simple adapter for a thinkpad and read the EEPROM, where the password is stored in the clear. I was one of the people who helped figure out the requisite information that made it's way onto this site: http://www.ja.axxs.net/unlock/
What can I say? Read it and weep. I wouldn't be surprised if IBM was selling new systems to customers, then turning around and clearing the passwords on the old ones and reselling them as "refurbished".
That's ridiculous. First of all, the power-on password has nothing to do with the hard drive password, except that most notebooks typically tie them together. IBM could easily have the hard drive passworded, but make the notebook perfectly usable once the drive has been swapped.
Additionally, it's trivially easy to read files off of a passworded hard drive. The password is stored in an EEPROM on the board, so all you have to do is buy an nearly identical drive and swap the circuit board to read all the documents.
If they were smart, they would store the password in sector 0 on the platters. Then, swaping the board wouldn't work. Also, running a strong magnet over the hard drive would erase the password as it erased the files, keeping the files safe, but also allowing you to erase the whole drive, and use it again without knowing the password.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
somewhere in this thread are various instructions on how to fix it.
No, that would also erase the servo patterns, leaving the hard drive completely dead.
Unlike floppy disk drives, which position the read/write heads with a stepper motor and are capable of reformatting blank media in the field, hard drives use special patterns encoded onto the platters to locate tracks and position the read/write heads over them. These servo patterns are written in the factory using very specialized and expensive equipment (not like a PROM burner that can be built cheaply; servo writers cost hundreds of thousands of dollars IIRC), and they can't be rewritten in the field.
Strictly speaking, using the Programmer's button wasn't required to update the firmware. You can instead use option-apple-O-F to boot to the OpenFirmware prompt, then use the boot command and the path of the OpenFirmware updater (having used devalias, dev device , cd dir , and ls to browse around and find that image); when you do this, the system boots from the standalone OpenFirmware update image instead of loading the regular bootloader, and when that code runs, it updates the firmware. I'm 90% sure it doesn't require you to hit the Programmer's button either, and instead the Programmer's button thing just triggers the system to load the same executable that you can load manually with the boot command.
So, the point is, on a G4 tower at least, although the Programmer's button is involved in the process, it isn't actually required and doesn't provide any security, as far as I can tell.
If you're wondering how I figured this out, let's just say I was trying to get a Mac working that failed to autoboot, dumping me at the OpenFirmware prompt every time. I thought it was a problem with OpenFirmware settings, so I aimed to find a way to upgrade the OpenFirmware on the assumption that doing this would force the system to also reset every setting related to it (more thoroughly than just "zap the PRAM"). I couldn't use the normal method because the failure to autoboot prevented that method from working.
On a side note, I succeeded in updating the OpenFirmware to a newer version, and it didn't help at all. I eventually discovered that the machine was a Frankstein computer that had the wrong Front Panel Board in it, and THAT was why the OpenFirmware wouldn't boot -- it knew something was wrong with its hardware. I finally traded this Front Panel Board with someone else for the right one, and now my friend who bought the G4 tower for half price because of the fact that it wouldn't autoboot is happily using it.
On another side note, isn't the flash chip on the iMac Core Duo socketed, and can't they get an identical chip and make a copy of its contents BEFORE they go messing with it, thus allowing them to monkey with the copy and revert to the original if needed?
Because most bioses shadow themselves into ram in order to run faster...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
From Dave Schroeder posted 01/23/06
By following these steps, the iMacs that had difficulty with certain EFI modules appear to have been restored to a functioning state:
- Disconnect the internal hard disk
- Disconnect the iMac from AC power
- Plug in AC while holding the power button
- Power up the iMac and zap NVRAM (cmd-opt-P-R)
The hard disk can be reformatted and the operating system restored.Hello,
:))
If everything else fails you may try this: http://www.cgsecurity.org/cmospwd.txt Find your notebook in the list. If it is there just remember what to change in 24C0X eeprom. If it is not there then you can try to corrupt random places in the rom (of course you need backup first, It seems to unlock the HP when the checksum is incorrect). To do the changes you need to hook the eeprom. Solder SDA SCL and GND (maybe also the adr pins?) you can use lm-sensors i2c-pport driver and i2cdump i2cset commands to manipulate the ROM. I did it once and it worked (I was a hinting some guy on IRC
Ruik